从业务到中台，必须经历抽象建模的过程。这个过程分为两个阶段，分别是 0 级抽象中心建模的阶段和 1 级抽象组件建模的阶段。每个阶段采用的建模抽象机制都是实体抽象法。下面以 0 级阶段建模抽象为例进行说明。
首先，我们梳理出企业功能需求，如某饮料企业的功能需求汇总表如图 6-1 所示。
图 6-1 功能需求汇总表
其次，找出每一个功能需求所对应的业务对象或实体。这一步需要剥离功能的差异性，抽象功能的共同点，才能保证定义合理。实体分为两类：业务实体（叫“静态实体”更容易理解）和过程实体。实体性质相同或者实体结构相似度较高，都可归纳为同一实体。在实体基础上，为了满足当前功能需求，我们需要定义出系统需要提供的能力。能力就是对实体施加的操作或发出的命令，这里的能力我们称为领域能力。
最后，根据能力的主题、实体的密切关系，定义出主题域（也可以称为“业务域”）。业务域的命名一般由资深业务架构师来定义，以避免出现二义性。基于功能需求的抽象，输出的产物见表 6-1。
划分出多个主题域后，技术架构师需要结合技术的实现，将领域进行组合规划出中心。中心的划分标准主要从实体的聚合度、中心的职责、中心颗粒度、能否独立运营等方面来权衡。确定中心的过程也就是划定功能边界的过程。图 6-2 是某企业的中心划分结果。
##业务中台的 8 个设计原则
业务中台是一个充满生命力的个体，它承载业务逻辑、沉淀业务数据、产生业务价值，并随着业务不断发展进化。它的设计遵循如图 6-3 所示的 8 个原则。
1. 服务松耦合原则
（1）面向接口实现
表 6-1 功能需求抽象表
图 6-2 中心规划
图 6-3 业务中台设计的 8 大原则
这是服务松耦合的基本要求，即每一个服务都按接口的定义进行实现。服务的消费方不需要依赖某个特定的服务实现，避免服务提供方的内部变更影响到消费方。另外，在服务提供方切换到其他系统时，不影响服务消费方的正常运行。
（2）异步事件解耦
服务间的事件通信采用异步消息队列来实现。由于有消息队列这个中介，因此生产者和消费者不必在同一时间都保持实时处理能力，而且消费生产者也不需要马上等到回复。
（3）服务提供者位置解耦
服务消费者不需要直接了解服务提供者的具体位置信息，例如 IP 地址、端口。典型解决方法是服务注册中心，服务提供者启动时将自己注册到服务注册中心，服务消费者通过服务注册中心查找具体服务提供者来访问。同时，服务注册中心可以提供负载均衡及 fail-over 的能力。
（4）版本松耦合
消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务契约在升级时尽可能提供向下兼容性。
2. 服务依赖原则
（1）有价值的领域模型
- 价值导向：确保业务中心的服务都与企业的商业理想保持一致，相关联。
- 简捷为美：业务逻辑和流程避免复杂化。
- 领域洞察：紧贴业务的核心目的，从业务原则指导业务逻辑的设计。
（2）服务间最小依赖
- 高内聚：同一类服务应归在一起。
- 低耦合：服务间保持最小联系。
- 能力与接口：业务流程和业务逻辑的操作都作为中心服务实现，而提供给外部调用的接口数据模型都会转化为服务。
- 识别通用性：识别出每个通用能力的可扩展的类型，从设计上支持它不断扩展，并在接口定义上满足其不断升级的需求。
（3）能力实体具有层次性
- 能力与接口：分离接口实体与能力实体。
- 接口实体与限定元素：将接口实体核心元素与接口操作的限定元素分离。
- 接口实体的层次结构：建设接口实体和上下文限定元素的层次结构。
（4）延迟对技术组件的依赖 - 捆绑依赖：避免在无关的技术组件之间引入新的依赖。 - 延迟绑定：在使用点才捆绑依赖关系。
3. 服务设计原则
（1）优化远程调用 服务间的远程调用分为同步调用和异步调用两种模式。应当分析服务调用场景，选择较优的调用模式。 （2）去掉冗余数据 尽量去掉接口实体中客户端不需要的冗余字段，既能减少网络开销，又能避免给前端解析带去复杂性。 （3）设计粗粒度的服务接口 服务接口若能与前端一个用例或一个业务场景相对应（粒度较粗），则既能减少远程调用次数，又能降低学习成本。 （4）识别并设计通用的服务接口 由于中心服务不限定应用范围，因此一般要支持不同的应用。但不同应用在功能丰富性上有很大差异，这就决定了服务接口需要尽可能保证广泛兼容性。譬如，服务接口的参数和返回值必须是被广泛支持的较简单的数据类型。 （5）隔离服务内部的变化 避免服务内部的领域模型直接传导给客户端。如未能提供合理的隔离措施，则当服务进行内部重构时，势必导致客户端频繁变化。 （6）服务接口先行 详细规定服务与客户端双方对接的内容与形式等，对双方形成强有力的约束和保障。 （7）服务接口向下兼容 由于应用的广泛性，在服务公开发布之后就要保证相当的稳定性，不能随便重构，即使升级也要尽可能考虑向下兼容性。
4. 服务命名原则
强烈建议使用服务使用者专业领域内有意义的名称，优先选用业务概念而不是技术概念。 使用名词命名服务，使用动词命名操作。
5. 服务颗粒度原则
服务应是内聚而完整的，能够独立完成一个职责。在服务内部可以是由多个逻辑上密切相关的代码块共同组成。
6. 服务的无状态性原则
微服务体系的基本要求是服务无状态。无状态的服务是可伸缩、高可用性的基础。
7. 服务操作设计原则
操作表示业务动作，应当使用具体的业务含义而不是泛型操作来定义操作。相关的最佳实践如下：
- 重要的服务不能依赖非重要服务。
- 任何服务调用都要设定超时时间。
- 任何服务的调用结果只有三种可能：成功、失败或未知。
- 能异步调用的服务尽量使用异步调用，从而提高系统响应速度，降低系统之间的耦合性。
- 系统拆分时，粒度大小以一个系统 3～8 个开发人员维护为宜。
- 系统拆分时，往往先拆分数据服务层，因为数据服务层通常是复用性高的一层。
- 服务的实现不能有单点。
- 线上遵循 fast-fail 原则，避免服务调用时间过长，导致性能下降。fast-fail 原则是只要发生错误，则调用立即返回。
- 需要对高压场景下的服务调用链路进行特殊处理，可采用将链路缩短、预热等方式。
- 服务设计过程中，要避免同类服务由不同服务单元提供。
- 服务要做到向后兼容，如果无法做到，则需要采取管控机制确保服务消费者升级服务。
- 服务化架构的变化要使组织的架构能适应这种变化。
- 在部署服务单元时，要将读服务和写服务分离，将核心服务和非核心服务分离，以保证整个服务单元的稳定性和可靠性。
- 服务化时，要同时考虑安全。
- 静态资源也可以实现服务化，实现静态资源与动态资源分离，从而提高性能。
- 通过在外层系统埋点，可以实现面向终端用户服务的精细管理，比如服务的容量、服务的性能等。
- 需要将每个业务领域的通用规则沉淀成服务。
8. 服务约束原则
- 上可依赖下；
- 下不可依赖上；
- 上可跨级依赖下；
- 平级可允许单向调用，坚决禁止循环依赖；
- 高级别不可依赖低级别；
- 简单就是美；
- 重要的服务不能依赖非重要服务。
分布式运行机制
中台采用微服务风格进行建设，每一个业务中心都是独立部署的，因此分布式运行机制是保障业务中台正常运行的基础。无状态的微服务易于扩展和部署，对弹性伸缩、灰度发布等互联网场景有良好的支持。同时微服务架构也带来了复杂性，一个微服务应用一般由多个服务组成，每个服务又有多个实例，因此一套中台系统部署上线后，至少有几十个节点提供服务。为了管理众多的微服务，我们需要解决诸如如何使配置一致、如何实时监控、如何发现新服务、错误如何定位等问题。
1. 服务注册与发现
服务注册是服务发现机制的核心，服务实例将自己的服务信息（包括网络 IP、端口、服务名）注册到服务注册中心，服务注册中心将服务信息以及服务健康状态通过 API 暴露出来。服务消费方通过注册中心获取到服务实例信息，并通过 IP、端口、服务名的组合去请求服务提供方提供的服务。
除了完成以上核心功能外，服务注册与发现还需要实时监控服务实例的健康状态，一旦服务实例不可用，将通知各服务消费方移除无效服务实例。另外，一个服务可能存在多个服务实例，需要根据不同的负载均衡算法来保持服务调用的均衡。
2. 弹性伸缩
在分布式集群里通过服务探针，可以监控应用和服务容器的状态，自动调整服务实例的数量。扩容，在监控到服务容器出现瓶颈，包括负载、CPU、RT 指标都出现紧张时，能够自动增加应用实例到集群中。缩容，在监控到服务容器负载减少出现资源浪费时，自动释放服务实例减少成本。调整弹性伸缩的规则支持用户灵活配置。
3. 限流降级
在互联网应用场景下，用户的访问并不总是均匀平稳的，时常会出现瞬时的高峰，比如活动期间。分布式应用服务需要提供限流功能，时刻感知流量的变化，并做出相应调整。限流的策略可分为限制访问的绝对数量和控制流速（整流）。整流的算法有令牌桶算法，限制总数可通过设置规则来实现。 降级是指某个服务被调低级别后，本服务的消费者在调用时即刻返回失败，这样服务实例将不会被调用。当然，也可以设置一个默认返回值。降级的规则支持用户灵活配置。
4. 灰度发布
灰度发布的技术用于两个不同版本同时在线上并行的情形，既可用于业务试错，也可用于版本发布。一旦确认新版本达到目的，就可以平滑地从旧版本切换到新版本上。灰度发布需要解决两个方面的问题，才能顺利达成目的。 （1）多版本部署 多版本部署分为客户端部署和服务端部署两个方面。客户端如果是原生系统，可以用热更新技术实现，比如 Android 的 CodePush。客户端如果是 H5，则需要在服务器端部署一套 CSS 和页面。服务端部署要求应用服务、中台服务都要单独部署一套，通过版本来区分。如果需要对 MQ 的数据消费进行隔离，则需要重新定义 Topic 或 Tag。 （2）流量切分 流量切分包括入口流量切分和中台服务流量切分。入口流量的切分策略通常包括按服务器权重、IP 地址段或用户标签等来切分流量。中台服务流量切分通过分布式服务发现机制，植入流量切分规则，控制流量的方向。
5. 消息队列服务
消息队列服务是互联网应用场景下非常重要的一个技术中间件。在业务上，通过消息队列既可以提高用户体验，又可以支撑 IM 业务等；在技术上既可以解耦系统，又可以削峰填谷等。消息队列具有高性能、高可用、最终一致性等技术特点，是技术架构的重要组成部分。
（1）异步通信 消息发送方将耗时较长且无须实时处理的操作封装为消息，发送给消息队列服务。发送方无须等待消息被消费方处理完成，可以继续做其他事情。消费方则可以按自己的节奏完成消息的消费。异步通信可用于系统间的解耦，各系统独立自主，互不影响；也可用于减少请求响应时间，提升用户体验。
（2）高可用 消息队列服务以集群的方式部署，常见的有 1 主多备或 2 主 2 备等。消息服务接收到消息后，会同时分发给多个备份服务各自创建一个备份。当一台消息队列服务挂掉后，另一台消息备份服务可以无缝对接，及时提供服务。在 RPC 调用方面，提供了负载均衡、服务注册与发现功能，保证了消息队列服务在高并发场景下的高可用。
（3）高可靠 消息队列服务提供了极高的可靠性，不过应用开发时还需要统一提供 retry 机制，进一步提高可靠性，降低应用开发的复杂性。消息队列服务在收到消息后，会立即执行消息的持久化处理。比较常见的持久化方式包括存储到文件和存储到数据库两种。持久化机制包括同步双写和异步复制，保证了数据的高可靠性。
（4）基于消息的最终一致性 使用半消息技术，保证只要一个事件发生后，关联的结果事件一定会发生。半消息解决了如下问题： 事件发生后，事件消息发送却失败； 事件消息发送成功后，消息代理推送给消息消费方却失败； 消费方重复消费此消息。
使用半消息技术，在事件发生前，先成功发送一个半消息，这样就保证了事件发生的消息一定能够发送成功。消息代理增加了事件结果查询功能，保证了事件触发成功后一定将消息推送给消费方。消息代理保证消息推送至少 1 次，但要求消费方自己实现幂等性，避免出现异常。幂等性的保证，可以通过为每一个事件创建唯一 ID，消费方增加一个过滤服务，每处理一个事件都会通过存储这个事件 ID 来实现。当消费方收到事件消息后，过滤服务会查询本事件 ID 是否已经消费过。
6. 分布式事务
分布式事务技术（DTP）用于保证跨多个资源事务的一致性，目前 X/Open XA 标准已由众多厂家实现来支持分布式事务。DTP 模型的典型应用场景是两阶段提交协议，多个资源管理器（RM）由一个事务管理器（TM）进行管理，事务管理器控制着全局事务和分支事务。DTP 模型分别通过准备阶段和提交阶段来协作完成全局事务：准备阶段，由 TM 通知各 RM 准备事务，并接收 RM 的准备结果；提交阶段，由 TM 通知各 RM 提交分支事务，并接收 RM 的执行结果。RM 执行结果都成功，那么 TM 返回成功，如果任意一个 RM 执行失败，原则上 TM 都会执行回滚。但在实践过程中，RM 失败的情况也有不同，TM 可按照客户的需要判定是否回滚所有事务。目前，各大云厂商都提供了分布式全局事务，其中阿里云的 GTS 已经实现了分布式全局事务。在应用场景涉及的系统和步骤不是特别多的情况下，GTS 可以方便快速地实现分布式事务。
扩展点机制
业务中台自身提供了很多配置化功能，支持灵活快速地对业务功能进行扩展。除此之外，扩展点机制提供在不修改现有代码的情况下，灵活扩展新功能。扩展点机制源于 Java 的 SPI 机制，当业务中台的某一个业务点遇到新业务逻辑比当前逻辑差别较大时，可以使用扩展点机制来实现。
出处：https://www.infoq.cn/article/AJUmUIo2DvQZYzZi2VLc
