珍贵的“企业IT架构转型之道”钟华演讲录像与读书笔记

2.打通烟囱式系统间交互的集成和协作成本高昂。各大企业不得不借助ESB构建企业服务总线，打通各系统间的交互问题。当然，我们并非是要完全否定ESB系统，它的确是能在某种程度上实现系统间的互联互通，但这种“中心化”的服务架构缺点也有不少。

“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点，而这个中心点的能力是很难进行扩展的；也许有人会说我可以通过增加中心服务总线实例的节点数量，以达到线性的扩展平台能力。但这种做法其实过于理想化了，我来举个例子，说明一下这种模式的“雪崩”隐患。

假设企业的服务总线集群数量是10台，每个负载量是80%。当访问峰值来临时，有可能因为某一个应用的不规范调用或者某个服务提供者出现了异常，导致了其中1台“罢工”。此时，服务路由压力就落在了剩下9台上，每台的平均负载量就变成了88%（个别服务器会更高），出现问题的概率就增加了。此时假设又有一台不堪重负也“罢工”了，就会出现后面的8台服务器在访问峰值时会瞬间被访问洪流冲垮，这就是“雪崩效应”。

我总结共享服务平台体系的优点主要有如下几点

2、服务被滋养。作者在书中提出了一个观点：服务最不需要“稳定”。一个服务如果一味追求不变，那就是固步自封，就会逼着其他系统去建同样的“轮子”。服务需要被滋养，不停的滋养，只有滋养才能最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产，而服务所需的滋养正是来自新的业务不断的接入。

3、服务助创新。大家都知道创新不是一件容易的事情，因为有些本质上的创新按照传统的开发模式是需要从分析、设计、开发，每一个环节都从0开始的，这样一来就会导致投入成本大，开发周期长，可能等你开发完了，商机已经被别人抢占了，公司领导可能考虑到上述因素就把你这个想法PASS掉了。而共享服务平台中的诸多服务是经过清晰的沉淀，可以通过重新编排、组合，快速的响应市场，达成创新，武侠小说里不常说天下武功，唯快不破嘛。

4、服务敢试错。说到试错，其实试错和创新有着千丝万缕的关系，有时甚至可以划等号，部分试错是会变成创新的。共享服务平台由于具备快速编排、组合服务的能力，可以以较小的成本投入来构建出一个新的前端业务，即使失败了，公司损失也很小。这在传统模式构建的系统中是几乎不可能达成的。

5、服务造BD。如今BIG DATE（大数据）成为近年来互联网和IT行业最为炙手可热的名词，很多企业甚至将互联网转型的期望完全寄托到大数据上，企业纷纷上马大数据项目。

多数项目在落地实施时却很难，主要有两个问题：

一是数据分布广、数据模型和标准不统一。需要进行数据层的打通、权限的控制、格式的转换、以及数据的清洗和转换等一系列复杂的工作；

二是缺少“数据科学家”。也就是说人件，项目只有强大的软件和硬件支持是远远不够的。更重要的是要有能基于对业务的理解提出对大数据平台需求的专家。此类专家需要懂数据采集、懂数学算法、懂分析、懂预测、懂市场应用…这样的专家对任何企业来说都是难寻的，就算你的公司财大气粗，可以把某某公司的专家挖过来，但他来到另外一个行业，另外一个公司，遇见另外一个全新的系统，由于对你公司的业务和技术熟悉程度较低，还是很难短时间带来效益。

而共享服务体系能很好的帮助企业培育出懂业务的专家，这些人员在自身拥有不错的技术功底的前提下，加上对业务熟悉度的不断提升，使之才有希望成为能发挥大数据平台价值的“数据科学专家”。

结合当前我部门主营的系统，我觉得我们完全是可以借鉴这种中台战略思想来规划和建设我们的新一代系统的。

首先把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们财务系统的生成凭证功能，据我所知，现在CBE，SSP，电子发票等都有这个功能，为何不把它独立出来一个通用的服务供大家调用？将重复、类似的服务进行整合，同时在单个服务的完善和增强的过程中注意服务的通用性，就可以避免其他相似“双胞胎”服务的出现。

最后说一点，由于服务能力的集中管控，很大程度会促进我们一体化运维的能力，但在“大中台、小前台”的模式下，每一个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力。

相关参考学习资料

钟华，《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》