中台架构设计
中台架构的主要目标是通过业务领域边界划分和微服务拆分,建立稳定的、单一职责的领域模型,让业务和应用具有更强的扩展和复用能力。
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和微服务》
更多推荐
所有评论(0)