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和微服务》
