云时代的数据中台（一）

• 2019 年 10 月 7 日
• 筆記

近段时间，我们在拜访客户领导层的过程中，明显感觉到客户对于云时代有了新的要求：从省钱提效到希望直接支撑业务。有来自外部的压力、也有来自技术的革新，因此云时代的需求变了，IT架构该如何随之变化？

一、架构IT向中台转型

比较经典的案例，芬兰的SuperCell游戏公司，员工仅200余人，但年均税前利税15亿美元，甚至超过了国内的运营商年利润，非常惊人的数字。该公司的架构为典型的大中台、小前台，3-7个员工组成一个小组，不断开发新的游戏，成功就继续养大，失败则马上转换。高效的运营模式来自于长期的算法、图形库的沉淀，使用前台开发人员可以在几周时间内开发出游戏，并上市试运行。

二、企业的中台IT架构转型之路

一般企业的IT系统从OA综合办公开始起步，逐步开始有CRM客户资源管理系统，多个系统拥有独立的数据库，形成了烟囱系统。为便于数据的统一分析、便于数据的统一管理，希望将用户的数据能统一，避免重复登陆不同的系统，开始出现了数据中台的需求。

采用系统打通的方式实现数据交互，治标不治标。为了打通这些孤立的系统，开始出现了单点登陆、SOA的数据交互方式，像IBM等厂商均推出了自己的ESB业务总线产品，横行江湖。但时间不久，ESB产品也无法满足业务交互的需要：当封装好的服务一旦被固定来了，出现新的业务需求时需要改变原有的服务，为避免影响原有的架构，升级原服务模块的代价很大，造成有新业务需求的系统只能自己开发，又形成了新的烟囱。一方面原因还是因为这些不同的业务系统拥有不同的数据库，数据仍是分散的。曾亲眼目睹某数据共享交换系统的数据是5个月之间的老数据。另一方面原因是缺乏自主叠代功能开发能力，增加功能需走复杂的采购流程。最后是系统之间是平等地位，没有共同服务者的存在，新的业务需求没有责任主体去落实。实际除了一些拥有自主开发能力的公司，一般的政务、国企的业务系统直到今天依然采用此模式。

以共享平台式的数据中台架构支撑服务的重用。一些共享的功能，如用户名密码的鉴权，各个业务系统均需要，需要形成共用的能力，由一个共享的部门支撑其运营。这样后，前台的业务系统只需要与共享部门提供的IT数据中台互通，而不需要在前台业务系统之间进行数据互通，业务的复用性得到了很好的提升。由于不需要复杂的业务互通，在此阶段，ESB一般不会再继续存在。目前数据中台一般采用Http Restful轻量化的方式进行数据互通，中间只有轻量化的注册中心、数据路由模块。

三、架构IT是否是数据中台型最好？

架构是伴随企业的成长而成长，在小型企业也许烟囱式的系统就挺好，简单、成本低。

而随着企业的成长，it也随之变化，ESB、数据中台式的演化也是正常的路径。