中台进阶·架构篇（一）

最近仔细研究了一下阿里巴巴中台战略思想和架构实战，结合我所遇到的实际情况，分析如下：

 

架构转型历史原因

首先，中台概念被大家开始接受并且企业逐步开展中台建设的目的是为了解决以下三个根本问题：

一是重复的建设导致资源浪费。

二是系统间交互成本高昂（当然可以通过SOA解决交互，但也带来了巨大的成本消耗）。

三是不利于业务沉淀和持续发展（企业实施SOA的方式导致了“自顶向下”的建设模式，服务提供者会拒绝新需求或者原有的服务设计无法支撑新的修改，这也是项目制的弊端）

为了解决以上问题，需要构建共享服务体系。一方面遵循SOA的核心价值——松耦合的服务带来业务复用，既解决了重复建设的问题，又通过统一核心业务层避免了需要打通系统间交互的麻烦。另一方面走出SOA项目制的误区，多花些耐心，用业务为核心业务层做沉淀，打造一个高可用的共享服务。

一个足够优秀的共享服务体系，不仅可以为业务的创新、试错提供扎实的基础支持，也能够在如今的“大数据”时代沉淀足够的业务数据进而进行建模分析。

 

以某中小型互联网公司架构发展历程为例

最早期，作为初创公司，所有功能被集成在一个项目中（那时候还没有什么用户量）。

随着用户量的不断增加，老架构出现了各种问题，团队协作成本增高（花费大量时间解决代码冲突）、新的需求带来的数据模型和业务逻辑的变更，会给系统带来不可控的风险、项目复杂到看不懂，于是第二代服务体系出现了，也是最早期的微服务体系。项目逐渐被拆分为不同的项目，同时打通各个系统，便于交互，中台化初现。但是，并没有真正解决问题，因为部分项目过于耦合，导致新的需求无法接入，业务组不得不另起炉灶。

为了解决上述问题，第三代服务体系出现了，通过重构部分项目（例如账户系统，订单系统等），同时考虑系统的通用性和可拓展性，使这些项目真正中台化，与业务逻辑彻底解耦，业务方可快速接入进行迭代。

目前的架构确实满足解决了三大问题，但目前仍然存在一些未解决的问题（本文暂不赘述）：

1. 中台项目逻辑闭环问题

2. 中台项目成型后，“被”进入维护期，由于沟通以及服务提供者的问题，导致各业务组仍然存在一些重复建设的问题

 

下期预告：

阿里巴巴共享服务体系搭建以及我所经历的实际案例分析哦～尽情期待～

 

欢迎关注我的知乎专栏，不定期更新哦～