中台架构设计

1 中台架构

1.1 双中台模式

数据已经成为企业级服务能力的标配，所以中台一般包括业务中台、数据中台两部分。

中台架构的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的、单一职责的领域模型，让业务和应用具有更强的扩展和复用能力。在业务拆分完毕以后，我们需要对这些拆分的、稳定的、单一职责的领域能力进行组合、编排、融合，从而灵活快速的适配外部业务。例如：电商平台的中台可以包括数十个微服务，但是对于用户而言，从商品浏览、加购物车、下单、支付、查看订单信息等是一个完整的业务流程，对用户而言就是一体的。

1.2 DDD VS 中台 VS 微服务

• 中台架构
  中台的本质是提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的、可服用的业务模型，打造组件化产品，供前台部门使用。
  中台形成的过程实际上是业务领域不断细分和功能不断沉淀，在这个过程中根据界限上下文、业务内聚的原则，落地成各个领域的微服务；具有共用服务能力的微服务聚合在一起就形成业务中台。

• DDD
  DDD本质是按照一定的规则将业务领域进行细分，将要解决的问题限定在边界内，在这个边界内构建领域模型。

• 微服务
  将领域内要解决的问题落地后就是微服务，一般和系统对应。

2 设计原则

2.1 系统设计原则

• 稳定性原则
  核心服务、非核心服务要分离；给核心服务足够的buffer、严谨性以确保系统稳定可靠。
  系统的实现不能有单点。
  系统要做到无状态，无状态的服务是可伸缩、高可用性的基础。
• 模块原则
  同一个领域业务，不要放到多个系统中。多个领域的业务尽量不要混在一起，通过包、模块或系统分开。
• 防腐原则
  隔离服务内部的变化原则：对外提供服务、消费他人服务时，在领域层外要加一层防腐层，隔离外部变化对当前系统的影响，也防止当前系统升级对上游的影响。
• 冗余性原则
  实体、模型中减少字段冗余，尽量实时查询，否则数据不一致会变成大坑。
  注意：单据类型的实体，一般来说必须冗余，因为单据落地哪一个数据就不会再变了。

2.2 依赖&调用原则

• 服务依赖原则
  重要的服务不能依赖非重要服务。
  上可依赖下，下不可依赖上；上可跨级依赖下。
  平级可允许单向调用。
  坚决禁止循环依赖，上游通过RPC调用下游，下游通过MQ通知上游。

• 服务调用原则
  服务调用都要设定超时时间。
  遵循fast-fail原则，避免服务调用时间过长，导致性能下降。fast-fail原则是只要发生错误，则调用立即返回。
  服务的调用结果只有三种可能：成功、失败或未知。
  能异步调用的服务尽量使用异步调用；提高系统响应速度，降低系统之间的耦合性。

2.3 接口设计原则

• 命名原则
  系统、接口、方法、实体等命名要具有业务含义；使用名词命名服务，使用动词命名操作；看到名字就应该能大概知道其负责的内容。
• 开闭原则
  服务要能够向下兼容，不能随便修改或重构，务必遵守开闭原则。
• 抽象&通用原则
  提供通用型接口：接口尽量具有通用性，不要为每一个场景设计一个接口。尽可能让服务消费方根据自己的需要组合接口数据；否则时间久了系统接口维护起来很崩溃。
  接口粒度原则：一个接口应该拥有独立且完整的功能，尽量避免多个接口组合起来完成一个操作；最好对应前端一个功能，或者一个用例；对外尽可能避免提供零散的接口。
• 接口耦合原则
  面向接口编程是基本要求。要面向接口编程，不能面向实现编程。
• 接口先行原则
  详细规定服务与客户端双方对接的内容与形式等，对双方形成强有力的约束和保障。

2.4 其他原则

静态资源与动态资源分离，从而提高性能。
所有请求都应该有日志，日志要能反映调用链路。
方法入口、出口测最好都有日志，方便定位问题。

3 实践

3.1 中台架构图

这是目前我们使用的系统架构。

• 应用
  这是我们对外提供服务的站点，对外提供完整的解决方案。这些服务他们使用同一套业务中台、数据中台，在经过前端的编排、组合后，对用户提供完善的服务。

• 中台

  • 业务中台
    包括了公司的核心业务领域，沉淀了公司核心的业务流程。
  • 数据中台
    包含了对数据的采集、清洗、计算等业务，数据从业务中台来，同时服务于业务中台。
  • 风控中心
    一般而言风控也属于业务中台的一部分，不过他更多起到的是辅助业务、安全防护的目的，防止业务失控，对公司造成损失。一般而言和数据中台交互比较深入。
  • 辅助业务模块
    起辅助作用，让业务、数据中台关注自己领域内的核心业务。例如：任务系统、日志平台等。
  • 分布式中间件
    深入中台服务的各个角落，帮助中台做好自己领域职责。

• 基础设置
  偏运维，用户管理容器、服务器、代码等。

3.2 业务中台

将业务中台拆解后，各个微服务的交互如下图所示：

• 网关
  API网关针对内部服务提供API接口；开封平台针对外部公司提供服务能力。

• 业务

  • 平台型业务领域
    指的是电商平台、撮合平台。公司作为平台方，撮合买卖双方达成交易，并为交易提供履约和担保。
  • SaaS型业务领域
    指的是ERP服务，需要帮助客户管理其采销存、钱货票。
  • 通用型业务领域
    平台型业务和SaaS型业务他们有很多差异，例如：SaaS关注的是一个公司的经营活动管理，平台型业务更多关注交易、履约等；他们也有很多相似性，例如都需要物流、发票、费用等领域。在项目进行领域拆分、边界划分的时候就要考虑好那些服务是通用型的，那些是某个业务个性化的，将通用的服务沉淀到底层，避免重复造轮子。
  • 基础业务领域
    属于业务领域的范畴，为所有业务领域提供服务的领域。例如：短信服务、IM服务，一般来说任何业务都可能会用到他们，这些服务中可以是抽象的、共用的，甚至不同公司这些服务基本都相同。
  • 基础领域
    不属于业务范畴，为所有业务领域提供服务的领域。例如：Id生成器为所有系统提供生成id的能力。

• 风控领域
  围绕数据和业务，为业务保驾护航。根据业务规则，抽象风控规则；将风控规则、业务数据传递给风控引擎进行计算，判定业务是否安全。

• 业务辅助领域
  起辅助作用，让业务中台关注自己领域内的核心业务。例如：很多时候业务经常需要在某一个时间点触发某些任务，而任务的执行又要考虑失败重试、任务降级等内容，超时系统就可以将所有失败重试、任务降级、执行时间、执行结果等功能涵盖，并在准确的时间点触发业务执行对应的逻辑。

4 中台建设

4.1 企业是否需要中台

• 是否大型复杂生态系统
  企业业务简单、团队规模较小时不太适合中台架构。
• 是否业务具备不确定性
  市场环境变化快，如互联网行业、产业互联网等相关行业，都属于这类型行业。
• 是否存在大量重复建设
  重复建设多的系统，系统维护成本高、迭代速度慢，也更容易出现故障。
• 是否存在数据互联互通问题
  由于事业部制的组织架构，形成了部门墙，数据和系统也是烟囱式的，中台架构比较适合这种公司。
• 是否信息技术制约企业发展
  项目迭代速度慢，制约业务发展；新业务建设难、复杂度高，制约企业发展，等等。

任意满足3个及以上，适合做中台战略升级；否则需要保持谨慎，因为中台架构的开发成本、系统复杂性都会较高。

4.2 中台注意事项

• 中台架构
  中台架构的目标：通过技术的抽象和沉淀，让企业降低成本，提升协作效率，加快迭代速度。
  中台架构是一套方法论，解决复杂、多变业务的方法论，不能奢望中台架构能包治百病。

• 组织架构匹配
  中台的目标是将业务做抽象和沉淀，服务于集团所有业务；而实际中每个团队的业务、目标不同，很容易造成重复造轮子的事情。如果组织架构不匹配，中台建设中会有很多阻力。

• 团队能力匹配
  团队中应该有架构师能把控各个服务的领域边界，让相同领域的服务沉淀到一个系统中；团队成员要能面向领域开发，而不是面向数据库开发；产品也应该具有抽象能力，产品、研发一起共建中台，避免业务之间复杂的相互纠缠。
  其实：DDD的战略设计落地的过程就是中台架构落地的过程。

5 参考文档

《中台架构与实践-基于DDD和微服务》

中台战略：业务中台的8个设计原则

中台研究（一）：阿里的“数据+业务”双中台架构