微服务中台架构开发
上QQ阅读APP看书,第一时间看更新

2.2.3 中台架构本质

上面的案例介绍了企业单个IT系统从无到有、从单一到全面的发展过程,这个过程可以理解为纵向的架构演进,图2-12展示了某集团企业IT架构的横向扩展。

图2-12(a)所示的4个系统分别是由集团下属的4个成员企业独立建设的,集团的汽车运输公司在建设机场大巴系统时,很难主动和地勤公司航班延误服务人员沟通乘坐大巴的旅客的航班延误后的服务。

图2-12

图2-12(b)所示的4个系统在建成使用过程中多多少少会涉及多方交互,例如航班延误后地勤公司需要联系汽车运输公司安排车辆将航班延误旅客运输到酒店休息,此时这2个系统就需要做接口进行点对点对接。这里最大的问题是沟通协调,4个系统在技术层面打通已经比较困难,更为困难的是4个系统对应的是4个不同的实体组织,实现图中的所有线条关系难度极大。

如图2-12(c)所示,通过ESB实现了多个系统的对接,解决了点对点沟通成本大的问题,每个系统只需和ESB对接即可。但我们发现ESB仅仅从技术上弥补了多系统的业务交互的缺陷,每个系统还是在独立建设,最后再考虑ESB集成,这种方式并没有根本上解决跨组织的业务协作问题。从我的经验分析,ESB很难适应需求的多变,而且ESB被当作技术集成工具,并不打算对业务进行整合和逻辑处理。

图2-12(d)中箭头方向发生了变化,业务中台对外提供业务能力的支撑,是面向服务的架构,而不去做多系统的集成打通。各业务系统基于业务中台提供的旅客行程、个人信息、行李、联系方式、用户画像等能力构建自己的业务场景实现,各系统之间是不需要交互的,只需在业务中台获取相应的能力即可。这也就是业务中台最核心的价值。