中台的核心建设

上期文章中，我们介绍了从烟囱架构到中台的演化过程以及什么是中台。从本章开始，我们开始分专题逐步介绍中台建设中的一些关键问题。

中台建设是一个很庞大的体系，在这个体系中，如果我们能找到建设的基础核心，通过基础核心向外围扩展，逐步实施，那么，无论从理解的角度还是建设的角度，都能起到事半功倍的效果。那么中台建设的核心是什么呢？

在回答这个问题之前，我们先结合企业及客户在做信息化的过程中遇到的问题，考虑下他们的关注点到底在哪里。因为中台建设的基础核心，一定是解决这些关注点的基础。结合我以前的工作经历，我认为，在这个过程中，企业和客户关注的点主要有四点：成本、运营、稳定、响应时间。先说成本：可以从两个层面来看。第一，建设成本。国内在经历了互联网创业期的洗礼后，同质化产品太多，各自的价格参差不齐，造成的直接后果就是项目预算被削减。第二，改造成本。“烟囱”系统要实现交互，要对现有服务的数据模型、业务逻辑做较大的改造，其改造成本，有时不亚于系统重新建设。所以不论是以上哪种情况，对于成本的控制，已经成为企业发展的核心优势之一。再说运营：系统运行期，能否嵌套运行管理工具，满足业务分析、日常维护等需要，从而降低运维难度及成本，也是企业及客户需要重点考虑的因素之一。然后说稳定：当系统面临大规模并发需求时，系统能否扛得住，是否能避免风险，涉及安全，没人敢忽视。最后说响应时间（这里所说的响应时间主要针对前端业务）：要满足市场个性化、多样化及不确定需求，交互层应用能否进行个性化调整？调整、上线时间为多久？这是涉及企业生存发展的重中之重。要同时满足以上四点，关键在于服务-抽象服务。它是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。

所以，中台建设的核心（也是基础），是共享服务体系的建设。通过共享服务，避免了重复功能建设和运维带来的重复投资，打通“烟囱式”系统间交互，降低集成和协作的高昂成本，同时，通过共享服务，对业务进行沉淀，使之成为业务创新的土壤，实现业务可持续发展。

分布式框架选择

我们可以把共享服务体系的建设作为中台建设的切入点，那么接下来，我们就应该考虑下框架的选择了。提到分布式架构，就不得不说下SOA。SOA是目前业界被验证的可以真正赋予企业业务快速响应和创新的科学架构，在中台的建设过程中，我们依然可以采用。

SOA的实现方式，目前主要有“中心化”和“去中心化”两种模式。

所谓的“中心化”模式，是传统软件厂商提出的以ESB（企业服务总线）来实现SOA的解决方案。相比多系统间“点对点”直接互通的模式，很好的避免了因为服务提供者服务接口的变化需要调用此服务的服务调用者都进行修改的现象，而只需要在ESB上进行一次调整，便实现了对服务接口变化带来影响的隔离。ESB架构降低了系统间的耦合，更方便、高效的实现了对新系统的集成，同时也在服务负载均衡、服务管控等方面提供了相比“点对点”模式更专业的能力。

而“去中心化”模式，则没有ESB企业服务总线这一“中心”，服务调用者和服务提供者采用“点对点”直接通信的方式。

关于SOA两种实现模式，其实没有好坏之分，只是适用的场景不同而已。ESB模式的SOA架构，更多的是解决异构系统之间的交互问题，便于系统集成。而去中心化的“点对点”模式，偏重于解决系统日后的拓展问题，同时，可以更快的进行业务响应、更好的支持业务创新等。

在中台建设的过程中，我们应该采用SOA的哪种模式呢？

一个平台业务发展的再好，一旦有更多的用户访问之后，这个平台如果拓展能力出了问题，将会给平台带来毁灭性的后果。因此，基于平台日后的拓展能力、快速支撑响应业务创新的角度出发，中台建设应该采用SOA“去中心化”模式来建设。建设过程中，对于服务集成问题，我们基于统一技术接口标准、网络协议、规范进行交互，并以服务契约先行的方式进行服务接口功能的约定，最大限度的降低因为服务接口发生变化给服务调用者带来的影响。相较于ESB模式的SOA架构，“去中心化”模式具有以下几方面的优势：

1、 业务响应时间短

ESB模式的SOA实现方式，服务每调用一次，服务调用者和提供者之间要通过ESB服务总线进行路由中转。

传统ESB服务总线下的服务交互方式

一次服务交互的路线如下：

服务调用者 -> ESB（接受服务请求） -> 服务提供者（服务处理） -> ESB（服务提供者返回结果） -> 服务调用者（返回服务）

分布式服务架构中的服务交互方式

一次服务交互的路线如下：

服务调用者 -> 服务提供者

从以上对比可以看出，在一次服务的交互响应上，ESB模式SOA需要4次网络会话创建和数据传输，而“去中心化”的SOA只需要2次。而在前端应用中，一个主核心功能页面，往往需要调用几个后端服务，并进行交互，ESB模式SOA很难从响应时间上，满足前端用户需求。

2、 扩容软硬件成本及网络开销成本低

ESB模式SOA中，所有服务调用均通过服务总线来进行，服务总线的访问和计算压力将会非常大。同时，对所需的网络宽带要求非常高，甚至会出现超过目前网络设备的能力范围。并且，一般企业服务总线包含的功能非常多，比如：服务发现、注册、路由、协议转换、接口监听等功能，使得企业服务总线一般对服务器的要求都比较高。因此，每一处服务总线的扩容升级，都将是一笔不小的成本投入。

3、 避免“雪崩”效应，安全系数高

更多的服务调用给企业服务总线带来了更多的服务路由压力，这就导致服务总线必然会采用线性集群部署方式。例如：根据对访问峰值的估算，一个企业服务总线所需集群数量是10台。当达到访问峰值时，每个服务总线的负载水平位达到了80%。如果当一台服务器发生故障停止工作，其提供的服务路由职能将会分摊到剩下的9台上，每台的负载水平位就超过了88%，可别服务器可能会更高，这样，其他服务器出现问题的概率就大大增加了。如果这时9台服务器中的一台不堪重负“罢工”，剩下的8台服务器将会在访问峰值下瞬间被冲垮，造成整个企业服务总线全军覆没，这就是“雪崩”效应。

而“去中心化”服务框架则可以避免因为个别问题波及整个平台的业务受影响，最多也只是部分服务出现故障。从而有效避免了整体业务瘫痪的情况发生。