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

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

业务中台是一个充满生命力的个体,它承载业务逻辑、沉淀业务数据、产生业务价值,并随着业务不断发展进化。它的设计遵循如下图所示的8个原则。


image.png


01 服务松耦合原则


1)面向接口实现

这是服务松耦合的基本要求,即每一个服务都按接口的定义进行实现。服务的消费方不需要依赖某个特定的服务实现,避免服务提供方的内部变更影响到消费方。另外,在服务提供方切换到其他系统时,不影响服务消费方的正常运行。(2)异步事件解耦

服务间的事件通信采用异步消息队列来实现。由于有消息队列这个中介,因此生产者和消费者不必在同一时间都保持实时处理能力,而且消费生产者也不需要马上等到回复。(3)服务提供者位置解耦

服务消费者不需要直接了解服务提供者的具体位置信息,例如IP地址、端口。典型解决方法是服务注册中心,服务提供者启动时将自己注册到服务注册中心,服务消费者通过服务注册中心查找具体服务提供者来访问。同时,服务注册中心可以提供负载均衡及fail-over的能力。 (4)版本松耦合

消费端不需要依赖服务契约的某个特定版本来工作,这就要求服务契约在升级时尽可能提供向下兼容性。

02 服务依赖原则


(1)有价值的领域模型

  • 价值导向:确保业务中心的服务都与企业的商业理想保持一致,相关联。 
  • 简捷为美:业务逻辑和流程避免复杂化。 
  • 领域洞察:紧贴业务的核心目的,从业务原则指导业务逻辑的设计。

 (2)服务间最小依赖

  • 高内聚:同一类服务应归在一起。
  • 低耦合:服务间保持最小联系。
  • 能力与接口:业务流程和业务逻辑的操作都作为中心服务实现,而提供给外部调用的接口数据模型都会转化为服务。
  • 识别通用性:识别出每个通用能力的可扩展的类型,从设计上支持它不断扩展,并在接口定义上满足其不断升级的需求。

(3)能力实体具有层次性

  • 能力与接口:分离接口实体与能力实体。
  • 接口实体与限定元素:将接口实体核心元素与接口操作的限定元素分离。
  • 接口实体的层次结构:建设接口实体和上下文限定元素的层次结构。

(4)延迟对技术组件的依赖

  • 捆绑依赖:
    避免在无关的组件技术之间引入新的依赖。
  • 延迟绑定:
    在使用点才捆绑依赖关系。



03 服务设计原则


(1)优化远程调用

服务间的远程调用分为同步调用和异步调用两种模式。应当分析服务调用场景,选择较优的调用模式。(2)去掉冗余数据

尽量去掉接口实体中客户端不需要的冗余字段,既能减少网络开销,又能避免给前端解析带去复杂性。(3)设计粗粒度的服务接口

服务接口若能与前端一个用例或一个业务场景相对应(粒度较粗)则既能减少远程调用次数,又能降低学习成本。(4)识别并设计通用的服务接口

由于中心服务不限定应用范围,因此一般要支持不同的应用。但不同应用在功能丰富性上有很大差异,这就决定了服务接口需要尽可能保证广泛兼容性。譬如,服务接口的参数和返回值必须是被广泛支持的较简单的数据类型。(5)隔离服务内部的变化

避免服务内部的领域模型直接传导给客户端。如未能提供合理的隔离措施,则当服务进行内部重构时,势必导致客户端频繁变化。(6)服务接口先行

详细规定服务与客户端双方对接的内容与形式等,对双方形成强有力的约束和保障。(7)服务接口向下兼容

由于应用的广泛性,在服务公开发布之后就要保证相当的稳定性,不能随便重构,即使升级也要尽可能考虑向下兼容性。


04 服务命名原则


强烈建议使用服务使用者专业领域内有意义的名称,优先选用业务概念而不是技术概念。 使用名词命名服务,使用动词命名操作。


05 服务颗粒度原则


服务应是内聚而完整的,能够独立完成一个职责。在服务内部可以是由多个逻辑上密切相关的代码块共同组成。


06 服务的无状态性原则


微服务体系的基本要求是服务无状态。无状态的服务是可伸缩、高可用性的基础。


07 服务操作设计原则


操作表示业务动作,应当使用具体的业务含义而不是泛型操作来定义操作。相关的最佳实践如下:

  • 重要的服务不能依赖非重要服务。
  • 任何服务调用都要设定超时时间。
  • 任何服务的调用结果只有三种可能:成功、失败或未知。
  • 能异步调用的服务尽量使用异步调用,从而提高系统响应速度,降低系统之间的耦合性。
  • 系统拆分时,粒度大小以一个系统3~8个开发人员维护为宜。
  • 系统拆分时,往往先拆分数据服务层,因为数据服务层通常是复用性高的一层。
  • 服务的实现不能有单点。
  • 线上遵循fast-fail原则,避免服务调用时间过长,导致性能下降。fast-fail原则是只要发生错误,则调用立即返回。
  • 需要对高压场景下的服务调用链路进行特殊处理,可采用将链路缩短、预热等方式。
  • 服务设计过程中,要避免同类服务由不同服务单元提供。
  • 服务要做到向后兼容,如果无法做到,则需要采取管控机制确保服务消费者升级服务。
  • 服务化架构的变化要使组织的架构能适应这种变化。
  • 在部署服务单元时,要将读服务和写服务分离,将核心服务和非核心服务分离,以保证整个服务单元的稳定性和可靠性。
  • 服务化时,要同时考虑安全。
  • 静态资源也可以实现服务化,实现静态资源与动态资源分离,从而提高性能。
  • 通过在外层系统埋点,可以实现面向终端用户服务的精细管理,比如服务的容量、服务的性能等。
  • 需要将每个业务领域的通用规则沉淀成服务。



08 服务约束原则


  • 上可依赖下;
  • 下不可依赖上;
  • 上可跨级依赖下;
  • 平级可允许单向调用,坚决禁止循环依赖;
  • 高级别不可依赖低级别;
  • 简单就是美;


重要的服务不能依赖非重要服务。

相关文章
|
7月前
|
存储 敏捷开发 缓存
中台架构介绍和应用价值
中台架构介绍和应用价值
302 0
|
架构师 Java 网络安全
阿里拆中台?从架构师角度理解中台
“中台”概念的提出,一个明显的效果是提升了非IT专业人士的“架构理论”水平,所以似乎人人都“言必提中台”。但是对于IT架构专业人士来说,中台理念本属于架构持续演变中一个合理的阶段性小目标而已,在不同的环境下本应有不同的存在形式。
阿里拆中台?从架构师角度理解中台
|
9月前
|
人工智能 安全 前端开发
中台的演变和理解
中台的演变和理解
56 0
|
9月前
|
存储 数据采集 监控
我为什么要搭建的数字中台而不仅是单一中台架构
数字中台在运营过程中需要关注监控和维护、数据更新和迭代、服务管理和支持、数据治理和隐私保护、市场推广和宣传以及业务拓展和合作等多个方面,以确保数字中台的稳定性、安全性和发展性。
|
9月前
|
机器学习/深度学习 存储 运维
我对目前中台架构使用的的思考理解
我需要的是解决我的问题,而中台架构并不代表说它是一个死的架构,这个可以根据过程不断的调整和优化的,这个概念和架构的提出,会更加明确搭建和建设的思路和方向,但是怎么实现,需要架构师根据团队来进行优化处理。 在这个过程中的感觉好比别人送给你一个屠龙刀,会使用的人可以扫四方,但是不会使用的,可能会惹火上身,伤到自己,甚至会发现,还不会以前菜刀方便,关键是怎么使用。
|
存储 Web App开发 运维
一种业务中台建设的方法
## 一、中台建设的复杂性 ### 1.1 中心、平台、中台的演进 应用架构一般演进的规律是,从中心应用演进成平台应用,然后从平台应用演进成中台应用,演进背后的底层逻辑就是"降本增效",降本增效在软件架构中经常被提到,本是成本的意思,效是效率的意思,连起来就是降低成本提升效率,仅仅回答到这一层,还是有些抽象,这里"本"包含了哪些成本?"效"又包含了哪些效率? 软件开发的成本包含了:分析成本、沟通
1856 0
一种业务中台建设的方法
|
运维 Cloud Native 安全
1900万!阿里中标南航业务中台(2022)应用及技术架构设计项目
9月21日,南航业务中台(2022)应用及技术架构设计项目成交结果公示
367 0
|
存储 JSON 前端开发
如何设计支持快速交付的技术中台战略?
快速交付的技术中台的设计原则
333 0
如何设计支持快速交付的技术中台战略?
|
消息中间件 运维 供应链
业务中台的职责思考
业务中台应该要沉淀什么样的能力?如何让需求收敛?如何让不了解你系统的人,能以较低的成本参与到你系统的共建?如何做到系统防腐?
355 0
业务中台的职责思考
|
运维 架构师 API
​前阿里中台架构师:基于中台架构的新业务建设原则
​前阿里中台架构师:基于中台架构的新业务建设原则
242 0