微服务和业务中台设计分享
一、业务中台
通用特征
业务中台是一种集约化的建设方式
业务中台是一种面向领域的架构体系
业务中台是一种按需使用的产品形态，必要时也可以变成按量计费的商业模式
独有特征
业务中台在技术上是微服务的架构
业务中台在业务上是面向创新的架构
业务中台应该具备一种接受业务驱动，而又能支撑业务发展的正向反馈机制
核心竞争力
快速的业务响应能力
规模化的创新能力
更低的试错成本
如何做
领域驱动设计 (DDD)
通过分析问题空间和业务逻辑，将应用程序定义为域
域由多个子域组成，每个子域对应于业务的不同部分
设计与子域相对应的服务
子域分类
核心类 - 业务的关键差异化因素和应用程序中最有价值的部分。 (业务中台服务的候选)
支持类 - 与业务有关，但与差异化无关。 (业务前台服务的候选)
通用类 - 与业务无关，理想情况下可以使用现成的软件实现。
哪些不是业务中台
业务中台所提供的能力无法被共享，不是业务中台
如果出现新的业务需求或者需求变更，就要修改业务中台，不是严格的业务中台
如果出现前台调用中台，中台又调用前台的调用链路，不是合理的业务中台
二、微服务
微服务拆分方法
(1)按业务边界将业务域划分为多个业务子域(对应多个微服务)
(2)将业务子域分解为多个领域对象 (对应某个微服务下的多个Service)
(3)识别出领域对象的多个领域活动，覆盖到该领域对象所涉及的业务活动(一个领域活动对应Service下的一个方法
(4)识别出领域活动所涉及的聚合、实体和值对象(对应微服务的实体对象和数据对象)
(5)比较不同子域。分析类似的领域对象，领域活动，聚合、实体和值对象，根据一定相似度闽值，合并去重
(6)分析同一个子域，如果不同Service之间没有任何交互，可进一步拆分成不同微服务
(7)迭代执行1-6步骤，持续提高拆分合理度
举例分析
所有业务用例，从应用和技术架构视角，都可以分为人机交互，逻辑处理，数据存储3个层面;
前台和中台的划分，重点在于“远辑处理和数据存储”的细分
故：
(1)在微服务纵向拆分的成果基础上，做进一步的横向划分
(2)人机交互的，属于业务应用
(3)多变的、交易类的逻辑处理和数据存储，属于业务应用
(4)稳定的、基础的逻辑处理和数据存储，属于业务支撑
哪些不是微服务
仅仅为了不同团队并行开发而拆分的，不是微服务
没有拆分数据库的不是微服务
经验反馈
每个微服务对应一个数据库，但如果存在关联查询需求的，尽可能保存在同一个实例中
业务中台服务不是越多越好，关键是能洞察到业务本质，始终保持面向资源的设计，而不是面向过程的设计
业务中台服务提供的功能颗粒度通常都是比前台服务的功能颗粒度更细
业务中台，是适用于业务逻辑比较复杂，业务变化和创新比较频繁的业务场景
业务中台一定要提前开发调试，不能和业务前台并行。业务前台开始开发时，业务中台API必须要是稳定的
业务前台和业务中台通过API网关来交互，很多非业务功能，例如路由，限流，认证，监控都由API网关来提供
不要把业务管控当作业务中台来建设，管控意味着处理逻辑和处理过程，这应该是业务前台利用业务中台的能力，组合/编排来实现
三、总结
一定要前端和后端分离
后端做微服务拆分，形成一组微服务
通过划分原则，识别出中人台服务和前台服务
前端和前台服务共同组成了“业务前台”
中台服务共同组成“业务中台”
持续迭代步骤3~5