自从头部互联网企业提出中台概念，很多企业都开始搭建中台系统，中台系统到底是什么和传统系统有哪些差异呢？本文通俗的聊一聊中台系统。

声明：本文非专业技术文章，重点在于通俗易懂。

一、传统架构和中台架构

1. 中台和PaaS的关系

先辨析下中台系统和PaaS系统的关系：

• 从外部视角看：中台系统可以是SaaS系统也可以是PaaS系统，但是PaaS系统肯定使用中台系统的架构。
• 从内部视角看：中台系统是改变了企业的组织架构和服务之间的组合关系。终端客户，感受并不直观。

2. 传统架构和中台架构的结构图

本图是传统系统架构和中台系统架构的简略示意图。

两者共同点和差异点为：

• 都在虚拟机上运转，传统架构一般在一个虚拟机上运转，如设备算力不足，只能人工干预，部署新的服务。中台系统部署在容器系统中，一般是Docker系统，Docker系统支持自动拓展虚拟机数量，无需人工干预。
• 都依托内部子服务对外提供功能，传统系统的子服务按照业务逻辑直接组织，内部层级混乱，拓展困难，无法实现针对性的算力拓展，如：只给服务1及其关联对象拓展5倍的算力，而不相关的服务不拓展。中台系统可以实现该功能。
• 都可监控系统运行数据，传统系统一般在一个虚拟机上运转，直接使用虚拟机自带的工具集基本可以满足要求。中台系统的数据监控平台可以监控所有自动拓展的虚拟机，并能细颗粒度的干预系统运行。可以叠加预警机制和其他业务管理工具。
• 都可以对系统干预，传统系统干预手段单一，比如：关机、重启。中台系统干预手段丰富，包括限流、预警等。
• 中台系统微服务复用效率更高。
• 都对外提供服务，由于以上优点，中台系统用户体验更好。
• 中台系统的缺点是：系统复杂，开发周期长。如果企业业务没有复杂到一定程度，可以根据需要部分上线中台系统，逐步完善，无需急于求成。

本节剩余内容对部分模块详细展开：

3. 虚拟机及虚拟机管理

此处的虚拟机并不是狭义上的Java虚拟机，而是广义上的虚拟机。

现代计算机包括输入设备、输出设备、控制器、计算器、存储器五个模块，无论这些设备是直接的硬件实现或者建立在硬件之上的虚拟机如Java、Python等，都属于此处的虚拟机。

传统的框架，设计的计算机程序，都默认在一台虚拟机上运行，当时的计算需求相对较少，一台计算机能提供的算力能满足绝大部分的计算需要。大部分情况下，计算机的算力远远超过了用户对算力的需求，所以当时的思路主要集中在如何实现分时共享，所以诞生了分时操作系统。

随着互联网的发展，各行各业都开始实现互联网+，此时单台虚拟机算力不够的事情才开始凸显。比如春节抢票，几亿人几乎在同一时间点涌向12306，12306系统忽然产生巨大的计算需求，系统刚上线时，系统无法及时响应用户体验较差（这是以前，现在体验已经很不错了）。正是这种类似的需求催生了中台系统。

4. 服务

之前的文章提到过，抽象的说：

• CPU的加法器、减法器等硬件实现的计算功能就是服务。
• C语言的函数将计算器和变量包装到函数体里也是服务。
• 面向对象的语言，是将多个函数和属性包装到对象里，也是服务。
• 面向中台的编程，是将多个对象包装到一个docker里，多个docker在docker管理器的支撑下完成业务，也是服务。

所以服务一直都是存在的，只是在传统架构里，各种服务并没有装到相同类型的容器里，所以无法区分操作。

面向中台的编程则是将不同的对象打包到相同类型的多个容器里。通过Docker管理器可以实现仅对某些服务定向拓展或定向关闭。

5. 数据监控

a. 建模和监控的关系

系统设计需要先建模，建模就是使用接口、类图梳理出不同的对象以及对象之间的关系，类图相当于该系统的静态地图。图中标识了哪些是高山、湖泊、河流、农田，他们相互之间的关联关系。

数据监控就是监控不同的数据在这个地图上是如何流动的，轨迹是什么。没有数据监控就不知道静态的地图哪里需要调整，哪条河需要清淤、什么时间容易涨水、哪个路需要加宽等等。

b. 传统模型的监控需求

在计算量需求不高的时候，对数据监控的关注度并不高，只有在系统运行故障时，才需要还原轨迹，用以帮助定位问题节点。

传统的架构，程序和数据在固定数量设备上运转，运算量足够，所以数据监控的重要性并未凸显，但是当系统用户越来越多时，就容易出现堵塞，就需要人工干预。

道理十分简单，很多村道只有一个车道，路口也不安装红绿灯，很少发生交通事故，主要就是因为流量小。但是大城市的道路大部分是四车道或更多，不仅安装红绿灯，高峰时期交警同志还需要上岗执勤，就是因为流量太大，容易出现问题。

c. 中台系统的监控需求

在中台系统中，系统会自动记录每个对象及其依赖对象的创建时间、数量、内存占有率、CPU占有时间等。并能用可视化的方式将信息呈现给技术运维。

d. 两系统对比

传统模型能不能监控数据呢？

当然能，无论是哪个语言都有机制查看对象的运行轨迹，但是当一个业务启用2个、3个甚至更多虚拟机的时候，逐个查看以判断问题，效率就太低了。

并且PaaS平台的数据监控不仅是显示数据，还需要叠加预警机制、干预机制。比如：扩增虚拟机的数量、关闭非紧急服务以释放算力、限制访问、限制流量等等都可以基于数据监控采取干预措施。

6. 干预平台

图中传统架构使用的是干预命令、中台架构使用的是干预平台。

从名字上就可知，中台架构对干预的手段做了极大的升级。

传统的方式最常见的方式就是停机、重启，中台架构不仅支持停机、重启、还支持限流、拓展算力、关闭虚拟服务。并且允许拓展干预指令定时执行等，干预平台实际上是传统架构的干预命令的升级版。

7. 服务平台

服务平台指的是服务用户的平台，包括PC系统、APP系统、智能硬件设备、物联网设备等，两个架构对用户而言，用户可能感觉不到太大的差异，但是实际上中台系统有很多优点：

a. 系统开发更快

按照中台架构设计的系统，系统原有的服务容易复用，传统架构的方式难以实现复用。

传统架构的复用可能主要体现为代码的复用，拷贝、粘贴、调试，基于中台系统的架构无需对原有服务拷贝、粘贴，可直接复用，所以开发周期更短。

系统延伸性强，如果延伸到可视化设计和流程搭建，可以将设计任务转到到非技术人员手中。

b. 系统服务更稳定

中台架构是自动延伸的架构，可以随着访问量的增加，自动拓展资源，自动拓展的硬件资源可以是一台、十台、百台、千台，只要系统本身够健壮，用户可以获得更好的服务体验。

比如12306上买票，大家现在的购票体验，肯定比系统刚上线的时候好很多，基本没有被阻碍的感觉了。

c. 平台更智能

平台在保证自动延伸的前提上，数据并没有分散，还是可以统一访问，为数据挖掘提供了便利，可以使平台更智能。

d. 拓展性更强

更强的拓展性体现在两方面：

• 硬件拓展性：基于IAAS平台，可以动态扩充硬件资源而不影响系统稳定性。
• 软件拓展性：方便增加新的微服务，比如部署用户画像系统、用户推荐系统等。

二、两种架构的拓展缘起

为什么要从传统架构升级到中台架构，我们可以从以下设想的场景中推演：

声明：下文只是以12306系统举例子，仅是推演。

设想：12306火车购票系统上线了，春节高峰期，有两亿用户同时访问本系统。虽然事先已经做了预案，但是客户访问量还是超过了预期，此时你应该用什么技术手段应对哪？

1. 现状

系统基于传统架构设计，已提前预估了可能的访问量，并采取了对应的技术措施。

但是系统访问量还是远远超过了预期，如何解决？

• 立刻改系统来不及，并且如何改，使用什么方案还不清楚。
• 只能启用临时方案

2. 解决方案

方案至少有三个：

• 方案一：多次放票，尽量不让访问需求集中在同一时间，错峰放票。（不展开）
• 方案二：直接拓展硬件，比如加CPU、加内存，该方法有上限。实际执行有哪些限制，需要IT部门评估可行性。（不展开）
• 方案三：再部署一套或两套独立的系统、独立的数据库。然后使用IP地址的路由技术实现：购买京广线的用户访问后台访问系统A，购买京沪线的用户访问系统B，购买其他路线的用户访问系统C。

最简单的是方案三，该方案可以解决本次问题，但是产生以下新问题：

a. 哪条线路的用户量和哪个系统能提供的计算量最匹配，没有实时的数据依据。

b. 系统不能自动切换，需要人工介入，人工响应慢。人工操作的时间=人反应的时间+机器响应时间。

c. 人工割裂的系统虽然能临时满足购票需求，但是导致数据割裂。导致很多与数据相关的服务无法拿到完整数据。

3. 根本方案

根本方案就是上云，并做中台系统改造：

a. 基于IAAS系统部署，可以动态扩展运算能力。每次新增的算力单位是一个虚拟机，因此虚拟机上运行的需要是具体的微服务，不能整体拓展。

b. 对微服务需要有管理平台，监控服务运行，并能提供干预。

三、服务平台拓展

服务平台有哪些可行的拓展，下文仅展开三个。

1. 可视化设计

产品经理最常使用的工具，肯定是Axure，使用Axure以及积累的元件母版，可以快速的在界面上画出：列表、单选框、复选框、菜单等等各种元素，可以使用动态面板或页面组织这些元素。

中台系统的可视化设计，就是将Axure的组件构建能力移植到Pass平台上，产品经理或者客户可以直接在Paas系统做设计。

PaaS平台的可视化设计比Axure设计的优势为：

• 可视化平台界面元素都已关联真实数据，无需使用Axure的中继器做数据模拟。
• 可视化平台的字体、颜色可以被预定义，保证了不同用户设计的风格一致。Axure不做限制，每个用户的设计风格可以不同。
• 可视化平台的菜单、跳转等框架可以被预定义，用户只需关注界面交互逻辑。相当于在Axure原型的基础上调整，而不是重新构建新系统。
• 可视化平台搭建的系统，搭建完成后可以直接交由测试，无需技术重新开发。

实际使用时，可视化设计可能会有各种各样的限制，这取决于Pass系统的设计特点和成熟度，理论上可以代替大部分的Axure功能。

2. 流程搭建

产品经理梳理业务常用的流程工具，包括 Visio、ProcessOn、Plantuml等，这些工具做出的流程图与Axure有个类似点，就是与业务系统并不直接联动。

可以将流程搭建的功能集成在PaaS平台上，与传统流程工具相比的特点为：

• 优势：流程搭建器已关联真实业务对象，通过该工具可以直接组织业务对象的功能和动作，开发周期短。
• 劣势：流程搭建器，约束更多，自由度低。

3. 叠加人工智能工具

传统方式做AI研究获取数据集的方式包括：excel表格、数据库直接获取、压缩包，然后使用Python自带的数学模型工具做研究。

PaaS平台上获取数据集的方式更简单，直接简单指令就可以获取平台上所需的数据集，并且可以对潜在的数据模型做包装，业务人员使用包装后的工具会比直接使用Python工具效率更高。

平台也支持集成Python工具，对新的模型允许使用Python工具直接计算。