《企业IT架构转型之道》的思考
认真读了《企业IT架构转型之道-阿里巴巴中台战略思想和架构实战》这本书，结合自己之前在河南移动的工作经历和目前工作的职责及认知水平，谈一下具体的思考感受。该书分为三个部分：第一是背景和中台的主要内容；第二部分是中台架构的具体实践和经验；第三是一些合作案例经验。当然我本人与阿里的工作经历不同，很多地方由于没有切身的经历或者经验可能感悟不深，不妥之处请批评指正。
一、中台战略是阿里业务大发展和企业基因驱动的
中台战略是阿里在2015年底宣布的企业战略转型内容，通过整合阿里产品技术和数据能力来打造强大的中台能力，进而形成“大中台，小前台”的组织和业务体制，使前台业务更加灵动、敏捷，以期迎接未来新商业环境带来的机遇和挑战。从阿里1年半左右的执行效果来看，中台战略对于阿里这两年的发展和规划起到了非常巨大的推动作用，从支撑内部逐步向逐步支撑外部客户发生了明显的转变。作者最后举了两个例子（一个应该是中石化的易派客）来证明业务中台对于传统大型企业转型升级的推动作用。
中台战略不是那一天突然提出来的，也不是对于技术架构和组织架构的重新规划和整理，其实是阿里10几年的巨大发展所不断演化出来的技术架构。中台战略主要是从阿里共享业务事业部发展而来，最初的阿里巴巴就是一个小型的购物网站，公司都是围绕这个网站建立的，企业的架构和人员是只要保持网站正常运转就可以，这也是目前为数众多的中小网站的现状，业务量小到根本没有任何技术架构升级的可能。但阿里不是这样的企业，业务量和产品的大量增长和发展推动着阿里不断对其系统进行功能升级和系统优化，淘宝之后又构建了天猫，08年成立了两大电商事业部。这个时候的阿里基本上仍是以关注业务为主，也就是关注前台为主，前台基本上是阿里的全部，也是阿里的核心价值所在，所有的后台从设备、开发、研发都是为前台服务的。这可能也是互联网公司的基因所决定的，互联网的基因就是极致和快速迭代，这样的基因决定了前台对于后台的话语权非常大，所有后台业务和技术必须跟上前台的业务发展要求。淘宝和天猫的竞争推动了共享业务事业部的成立，但是也基本上是个比较弱小的组织，共享业务事业部需要同时支撑天猫和淘宝的用户、商品、交易、支付、评价和物流等功能模块，非常艰难的支撑工作。移动的业支感觉与其有点类似。之后成立了聚划算，淘宝和天猫的商品在聚划算的平台可以得到明显的流量增长，之后还有1688，一系列的业务发展壮大对共享业务事业部提出了更高的挑战，每个业务口都需要资源，而资源总是短缺的。有突破的一点是：期间出现了阿里集团要求所有业务部门提交支撑需求必须经过共享业务事业部的同意，这个对于流程的优化改造举措使得共享业务事业部可以有更多的话语权来平衡上层的业务部门需求，也使得共享业务事业部可以集中精力对其技术和业务架构进行深入的复用和改造。此后的阿里形成了“厚平台、薄应用”的架构形态，在后端阿里云平台和前端业务间有了一个“共享业务事业部”，包括用户中心、商品中心、交易中心等10几个中心功能，共享业务事业部正是“厚平台”的真实体现。
罗马不是一天建成的，阿里的中台也不是一天就转型过来的。基本上对于技术部门和人员来说，从共享业务事业部演进来的中台战略，还是几乎相同的工作。所谓的中台其实是阿里从09年就开始逐步积累演进的路线，正是这种路线才沉淀了很好的实践经验。
从河南移动业支的经历来看，我们也经历了系统的烟囱式发展，从BOSS、CRM、ESOP、VGOP都在专业领域内自己演进发展，对于各种业务需求也是不断地推到业支进行支撑，业支内部也是按照业务模块进行组织架构划分。烟囱式系统建设的弊端主要是三个方面的：1、重复建设重复投资；2、打通系统成本高昂，边界沟通成本搞；3、业务和服务能力沉淀慢。这个在当时的业支也是体现的比较明显。
移动的业支部门也短暂经历了要求市场部统一对接需求的阶段，但是执行的不好，目前的业支支撑需求基本上属于排队支撑状态，各个业务口的满意度和效率肯定是会收到影响的。业支的地位就如同作者所说的一样，在公司内地位是较低的，业务部门领导基本上每周都有很多次汇报，业支领导几个月不见得有一次汇报，这个就是目前移动业支的一些真实写照吧。为什么我们没有发展出中台战略呢，与国企的一些基因是有关系的。
二、所谓的业务中台其本质是SOA，也就是服务共享
SOA在早些年做经分系统的时候自己也看到过一些内容，但是钻研的不深，当时看的REST服务、SOAP、CORBA等等都是站在不同的角度对于SOA的理解吧。SOA是目前业界被验证的真正能够赋能企业快速响应和创新的科学架构，我自己也搜索了一下，貌似亚马逊也是基于“去中心化”的SOA技术架构，虽然亚马逊没有提出中台的战略，但是感觉两个大型电商企业的技术演进路线很类似。
SOA的主要特性是面向服务的分布式计算；服务间松耦合；支持服务的组装；服务注册和自动发现；以服务契约方式定义服务交互方式等。最核心的理念是：松耦合，重（复用）服务。给企业创造的核心价值是：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新，这个本身就是和互联网企业的“极致”和“快速”是对应的。阿里的核心业务能力均建立在一套共享服务体系之上，真正发挥了SOA的核心价值：服务重用（服务共享）。SOA可以很大程度上解决烟囱式系统的一些问题，尽可能少的重复建设和投资，边界沟通成本大幅下降，服务能力逐步沉淀。
服务共享不是要求使用服务的业务端保持稳定，那样只会造成服务本身的落后和固化，最终变得没用应用端的使用而被淘汰。当然服务共享中的服务会有一部分因为服务本身的重构和规划而淘汰。服务共享给业务前端可以带来什么好处呢？作者列举了三个：一是培育业务创新；二是赋予业务快速创新和迭代试错；三是可以发挥大数据的能力（因为服务共享了，容易形成规范的大数据能力）。
业务中台的核心是服务共享，也要求阿里的组织架构是为共享服务提供更好支撑的组织。阿里基本上是按照服务中心来进行组织架构的优化，这一点可能会根据每个单位的不同基因产生不同的变化，总之组织架构也要为了“服务共享”做优化调整，不能生搬硬套。
从传统运营商的项目到我们目前的项目来说，都正在走向SOA的过程中，未来的项目基本上是基于服务化的项目，不管是基于私有云的服务化还是基于公有云的云化，都在向服务化进行演进。阿里在其内部做的更加极致，战略定位更加突出。
三、搭建中台，一条充满挑战的技术之路
阿里的SOA是去中心化的技术架构，为了保证服务提供者和服务调用者可以更加直接的连接，阿里没有采用中心化的ESB技术架构。中心化的技术架构在大量业务面前还是会存在雪崩效应的，而去中心化的SOA架构一般很难出现灾难性的全部中断服务情况。阿里的分布式服务架构是HSF，采用netty+hession数据序列化协议实现服务交互调用，而使用REST或者web service的都较少，这个也是其业务量过于巨大决定的。对于我们目前的数据量和业务情况来看，采用REST就基本上可以解决服务交互的性能和并发量问题，但是后期也是需要积极跟进新技术的。HSF本身支持一定的容错和线性扩展能力，这个对于我们建设的新一代客服和智能平台等系统都具备非常有价值的参考意义，目前众包业务和讯飞的智能能力都不能实现线性扩展，这是需要我们积极进行优化改造的地方。
微服务的概念和阿里的共享服务体系有点类似，只是阿里已经实践出了一条大型业务的微服务共享之路。而“微服务”本身还正在发展演进中。微服务是SOA的一种演进，它的主要特点是1、分布式服务组成的系统；2、按照业务而不是技术来划分组织以及做有生命力的产品而不是项目；3、智能化服务端点与傻瓜式服务编排；4、自动化运维和系统容错。
而容器化技术是为微服务进行快速部署发布的，docker容器化技术的主要优势是能够包装、便于移植，为适合用途而随需创建，可重复性高，易集成维护。后期结合我们自己的产品和业务应该是需要多参考阿里的HSF，更加注重应用微服务和docker的理念来进行产品的深入研发和交付集成。
阿里的中台是靠一个个共享服务中心提供服务的，服务中心不是一个简单的服务，它是很多服务的集中，是按照业务模型来进行划分的，类似与一个内部产品。它通过各种各样的对外服务接口为别的应用提供服务。服务中心本身和服务一样，都是不断发展演变的，提供的服务接口和形式是多样的，其内部明显是可以继续划分的。对于一个大型系统或者项目来说，怎么按照阿里的思路来划分服务中心呢？一定要兼顾三个方面的需求：从设计层面，按照面向对象的分析和设计方法；从运营层面，是一个完整的业务模型，要有数据运营和业务整合的价值；从工程层面，要基于分布式架构。架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题。共享中心的一些基本的设计原则是：1、高内聚、低耦合；2、数据完整性原则；3、业务可运营性原则；4、渐进性灰度建设的原则。这些原则对于后续我们划分功能模块和构建服务化体系是很好的参考。
在数据库层面要通过数据拆分实现数据库能力的线性扩展，技术上还是云化的思路。在性能层面，通过异步化和缓存技术来提升整体服务中心的性能，在分布式领域，基于CAP理论和延伸的BASE理论，按照柔性事务概念进行业务和数据和异步操作，提升整个系统的性能和稳定度。通过采用分布式日志引擎（鹰眼）来打造数字化运营的能力，通过鹰眼埋点的中间件来进行全流程的日志记录，为服务的实时监控和运营提供解决能力。
整个体系在服务化（SOA)之后，需要通过限流和降级、流量调度、业务开关、容量压测和评估、全链路压测平台以及业务一致性检查平台等手段来提升整个服务中心或者整体系统的稳定度。
服务中心为阿里内部的各个前端应用做好支撑之后，已经有越来越多外部平台希望使用这些服务中心的能力，为此阿里建设了共享服务平台，把服务中心的能力开放化和共享化，服务对整个淘宝生态圈开放。作者讲述的一个案例还是很有参考意义的，阿里曾经集中力量来开发统一的CRM系统给其电商使用，这个项目再经历了大量的开发和使用之后，最终失败。证明：面向所有电商的CRM系统由阿里一家是不可能做好的，所以阿里共享了其服务中心的能力给商家的IT服务供应商（目前超过15万家），最终繁荣了整个生态圈，也推动CRM向社会化CRM演进（SCRM）。
阿里的技术团队在近年开始向外输出技术服务能力，包括对口支撑中石化的易派客电商平台和某著名服务企业的电商化改造等等，以此证明共享服务中心的能力是可以复用的，也是符合企业转型互联网所真正需要的。
四、业务中台对于我们工作的启示
跟随作者的思路让我们对阿里的中台之路有了一个基本的认识和理解，也感受到企业信息化之路的不易和艰辛。目前公司也正在进行系统的大规模建设和重点产品的研发攻坚工作，业务中台对于我们研发工作有哪些可以借鉴之处呢？阿里的技术或者业务体系基本上是按照前台、中台和后台的架构进行搭建的，前台主要关注用户和需求，中台关注业务和逻辑，后台关注技术，对于阿里这样的企业来说前台的发言权肯定是相对较大的，但阿里并没有拘泥于前端，在不断优化运营前台的同时，也走出了中台共享服务中心和后台阿里云的能力输出之路。阿里业务中台之路给我们工作的一些启发：
1、服务共享化是一个主要趋势。企业不管是转型互联网还是内部自治，都需要向服务共享化方向转型，否则会拖累业务发展，不是被行业内企业超越，就是被行业内企业颠覆。运营商不努力，BAT会替代他们真的不是一句玩笑话。在运营商时代，我们习惯了各种大型项目，认为很多东西都是项目制的，而忽略了把项目中的模块的服务化，更别说共享化啦。服务共享化的工作有点类似我们之前做的数据集市工作，把数据开放出去产生的价值是远超过一小部分人自己做报表的价值。通过把服务和数据开放给更多的人，我们才能激发更多人的工作和创造力。公司已经在SOA的路上进行了较好的规划，后续的技术之路仍然充满挑战，需要久久用功。
2、技术架构要超前于业务布局。阿里在做共享服务事业部的时候提出的口号是可以保证10年技术架构不做大的改变，最大的一个原则是低耦合和高内聚原则，在这个原则下衍生出了服务中心、共享服务中心、云化和微服务化的架构，这么多年整体大的架构基本上没有变化，只是在这个原则上越来越细分，越来越专注。公司目前已经规划成熟的新一代客服架构，也基本上按照服务化的要求进行的布局，这个布局要超前于业务考虑，同时随着承接业务的增多会走向细化和专业化。
3、要更加重视自主研发和规划。阿里有很多业务架构师，属于既懂业务又懂技术的一些专家，这些骨干在阿里构建服务中心的时候发挥了巨大的作用。阿里的整体研发是基于自己业务发展的需求而制定的，不是外来和尚给规划的。目前公司的研发工作在我们自主架构的基础上，需要在自主研发的投入上给予更大力度的支持和规划，一定阶段内我们需要依赖厂商，但是想要更大的平台和未来必须依赖自主研发和创新，在自主研发的路上必须坚持不懈的给予投入。
4、支撑好内部是服务共享化和能力输出的强化。从阿里、亚马逊的发展道路来看，把自己对内的业务和需求建设好，就能积累和沉淀大量的技术能力，你内部做的越专业向外才能越强大。我们公司和阿里、亚马逊是有点类似的，首先服务好8.5亿移动用户是我们的内部技术基本要求，而把这个做优做强是一定可以积累和沉淀巨大的技术红利的。内部做不好，其实我们的很多能力是无法输出的，就是输出基本上也是借壳输出。当然，我们现在就要拓外部市场，其实也是换一种压力方式来加快推动我们支撑好内部的业务需求，同时提前培育市场，锻造队伍的各种市场能力。
5、服务中心可以更好的优化组织架构。阿里的组织机构从全部前台向前台-中台-后台的演变之路，使得专业的人员可以更加聚焦于做专业的事情，也可以更好的复用人力资源，为企业走向专业化能力输出打下了坚实的基础。可以参考服务中心来进一步整合优化我们的组织架构，更好的服务前台。
6、云化是服务共享化在互联网企业的一种架构，对于企业转型意义重大。如果企业的目标只是做好自己的事情，服务好自己的客户，用好自己的数据，保证企业的安全，那么私有云就够了。如果企业希望把自己的技术、业务能力输出给更多的外部企事业单位，那么公有云也应该是我们考虑的选项之一。老板曾经说过：你不开放共享，别人就把你OTT化，这个是阻止不了的大势，我们的服务能力能够共享，云化是我们的一个必经道路。
7、业务中台为未来的企业定位也指明了一定方向。未来的社会是个共享经济的时代，从滴滴到共享单车，它有利于公共资源的更优化配置，使得社会更加公平。未来的企业都必须把自己最核心的价值共享出去，中石油共享的是能源、中移动共享的是网络。而我们共享的是客服能力等。我们企业属于整个社会中台的一个服务共享中心，把自己企业的能力做的越来越专业，越来越强大，才能在未来共享经济社会中处于优势地位。
