中台架构设计

1 中台架构

1.1 双中台模式

中台架构设计_第1张图片

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

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

1.2 DDD VS 中台 VS 微服务

中台架构设计_第2张图片

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

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

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

2 设计原则

2.1 系统设计原则

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

2.2 依赖&调用原则

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

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

2.3 接口设计原则

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

2.4 其他原则

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

3 实践

3.1 中台架构图

中台架构设计_第3张图片

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

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

  • 中台

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

3.2 业务中台

将业务中台拆解后,各个微服务的交互如下图所示:
中台架构设计_第4张图片

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

  • 业务

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

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

4 中台建设

4.1 企业是否需要中台

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

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

4.2 中台注意事项

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

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

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

5 参考文档

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

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

中台研究(一):阿里的“数据+业务”双中台架构

你可能感兴趣的:(架构设计,架构,中台)