本文讨论中台项目集中部署模式，以某个具体的中台应用为例，如何给不同的业务线提供服务，主要考虑隔离性和部署成本。

在微服务的情况下，中台的应用应该满足下面的基本原则：

• 通过 RPC 为业务方提供服务

中台为企业内部的其他业务线的应用提供服务，企业内部应用间通信 RPC 较为合适。

• 同一套代码微服务12要素－－12factor
  

• 在隔离部署的情况下，同应用的所有数据库都使用相同的数据结构。

共享模式

image.png

最简单的模式，对于某个中台应用，统一的集群服务对各个业务线提供服务，通过业务身份进行逻辑层面的区分，共享服务器资源、中间件资源等。

该中台应用部署了 4 个应用（server1、server2、server3 和 server4），连接相同的数据库 DB、缓存 cache 和消息队列 MQ，为公司内部的 4 条业务线提供服务（业务 1、业务 2、业务 3、业务 4）。

业务接入流程：

1. 申请业务身份 bizX

2. 调用方接口以参数的形式传入 bizX，中台代码中通过业务身份 bizX 做逻辑隔离。

弊端：

不同业务间共享服务和中间件资源，出现故障时可能会影响全部业务线。

服务端可以通过限流的方式，识别某一个业务的流量，达到某个阈值的时候限制其流量，一定程度上保护整个集群。

独享模式

模式 1 毕竟是软件上的隔离，任何资源出现问题，都会互相影响。

另一条方向就是为每个业务提供独立的服务器资源和中间件资源。如下图所示，为每个应用提供一个集群分组，每个分组提供至少 2 个应用用于做冗余，不同集群分组使用各自的数据库、缓存和消息队列，做到核心资源的隔离部署。

image.png

实现这个部署方式需要考虑下面的问题：

1. 服务发现与路由

服务集群如何分组，让各业务线调用不同的分组

1. 不同集群连接不同的中间件服务，例如 数据库、缓存、消息队列

应用服务部署启动时，传入参数 BizGroup，指定是哪个业务分组

对于 java 应用来说， 启动命令中加入 -Dapp.bizGroup=bizGrgoup1 

• 调用方根据约定的 BizGroup，调用对应服务分组

对于 Dubbo 框架， 可以通过服务分组，即 group 参数来实现，consumer 和 provider 指定相同的 group

• 服务提供方根据 BizGroup 到配置中心获取对应的中间件连接地址，连接指定的中间件实例

例如数据库的配置信息如下

bizGrgoup1.jdbc.url = jdbc:mysql://host1:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup1.jdbc.username = user_namebizGrgoup1.jdbc.password = ****
bizGrgoup2.jdbc.url = jdbc:mysql://host2:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup2.jdbc.username = user_namebizGrgoup2.jdbc.password = ****
bizGrgoup3.jdbc.url = jdbc:mysql://host3:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup3.jdbc.username = user_namebizGrgoup3.jdbc.password = ****
bizGrgoup4.jdbc.url = jdbc:mysql://host3:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup4.jdbc.username = user_namebizGrgoup4.jdbc.password = ****

业务介入流程：

1. 申请业务身份 bizX，定义业务分组 xGroup

2. 申请新的部署资源

3. 至少 2 个服务器实例

4. 数据库实例

5. 缓存实例

6. 消息队列的 topic

7. 中间件的地址添加到配置中心

8. 数据库初始化

9. 初始化通用的表结构

10. 初始化基础的配置数据

11. 部署服务，设置参数-Dapp.bizGroup=xGroup 

12. 调用方接口以参数的形式传入 bizX，引入 consumer 时指定 group=xGroup

弊端：

新业务接入较慢，需要新增部署的实例，每个分组都需要做冗余，对于请求量较低且业务对稳定性要求不高的应用来说，这个部署模式有一定的浪费。

混合模式 1

综合独立部署模式和共享模式，根据业务的需求，提供独立部署或者共享部署。

image.png

bizGrgoup1.jdbc.url = jdbc:mysql://host1:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup1.jdbc.username = user_namebizGrgoup1.jdbc.password = ****
bizGrgoup2.jdbc.url = jdbc:mysql://host2:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falsebizGrgoup2.jdbc.username = user_namebizGrgoup2.jdbc.password = ****
shareGrgoup.jdbc.url = jdbc:mysql://host3:port/db_name?useUnicode=true&amp&characterEncoding=UTF-8&useSSL=falseshareGrgoup.jdbc.username = user_nameshareGrgoup.jdbc.password = ****

业务接入流程：

场景：新增一个业务 X，该业务新启动，初期流量较小，先加入共享集群，共享集群新增一台机器

新增业务，申请业务身份 bizX

部署服务，设置参数-Dapp.bizGroup=xGroup

管理人员将该 IP 加入到“shareGrgoup”分组中，中间件的配置信息推送给新增的应用，新增应用初始化中间件连接池

业务 X 的调用方配置自身 consumer service，设置 group=shareGrgoup，接入到共享集群分组中。

申请业务身份 bizX，定义业务分组 xGroup

中间件的地址添加到配置中心

数据库初始化

1. 初始化通用的表结构

2. 初始化基础的配置数据

3. 部署服务，设置参数-Dapp.bizGroup=xGroup

4. 调用方接口以参数的形式传入 bizX，引入 consumer 时指定 group=xGroup

业务 X 发展越来越好，为其设置独立集群

1. 定义业务分组 xGroup

2. 申请新的部署资源

3. 至少 2 个服务器实例，用于冗余

4. 数据库实例

5. 缓存实例

6. 消息队列的 topic

7. 配置中间件连接信息到 xGroup 中

8. 数据库初始化

9. 初始化通用的表结构

10. 初始化基础的配置数据

11. 迁移 shareGroup 中和 X 业务相关的所有数据到 xGroup 的数据库中

12. 部署服务

13. 业务 X 的调用方修改 group=xGroup

弊端：

独享模式和混合模式 1 都存一个问题：基于环境变量配置不同的应用，部署上会造成一些麻烦，同一个集群内的不同应用时有差异的，自动化部署时需要为应用需要区分具体的分组。

混合模式 2

image.png

将分组的配置从应用部署时的参数迁移到独立的“业务配置服务”中，应用启动时从配置服务中读取对应的中间件配置信息，然后完成自身连接池的初始化。“业务配置服务”为所有中台应用提供服务，一个中台集群有多个分组，一个 IP 归属于某一个分组，该服务存储的对象如下

ERDDiagram1.jpg

业务接入流程：

image.png

弊端：

该方案较复杂，“业务配置服务”承担了部分配置中心的功能，将运维的工作内容分割到了平台应用端。