读企业IT架构转型之道阿里巴巴中台战略实践

　　作者：人月神话，新浪博客同名
　　简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践背景概述
　　这本书全名是《企业IT架构转型之道阿里巴巴中台战略思想与架构实践》，里面详细介绍了阿里巴巴中台战略的原因，架构演变过程，同时包含了共享服务中心搭建原则，技术选型，高可用和高并发技术等。
　　9月中去参加华南CIO大会，刚好也碰到了该书的作者钟华老师，现在已经从阿里出来自己创业，方向仍然是中台和产业互联网相关的，而且公司发展也很快。钟华老师给人感觉就是技术和务实，值得大家学习。
　　这本书我是在3年前阅读，当时也整理了笔记，今天对里面的内容做下回顾。
　　这本书推荐给所有大型集团传统企业CIO和架构师阅读，该书内容有一定技术背景都应该能够看懂，在我博客上写过企业私有云PaaS平台和微服务架构一系列文章，很多思想也是类似。一本书有时候并不是一定要学到多少，而是可以真正帮你理清楚一些思绪点，这本书内容讲解整体感觉更加通俗易懂，特别是演进过程，前因后果方面的讲解等。
　　对于这本书的读书笔记，我只记录我批注已经进一步触发我思考和沉淀部分的内容，不再重复书里面已经讲述的内容。记录内容也不再体现具体章节信息。中台和微服务
　　在私有云PaaS平台里面谈到了厚平台轻应用构建模式，但是和这本书里面谈的中台还有些差异。后台更多是指底层PaaS技术平台和技术服务，而中台更多是共享业务和数据组件能力的下沉。阿里的中台里面常谈到的就是各种中心（如用户中心，商品中心，库存中心）等，前段时间一直有客户跟我说中心化这个概念，更多的应该是指这个中台里面的各个中心。
　　前台是前端的各种呈现方式的各类应用，例如天猫，淘宝，小的入聚划算等。基于业务创新需要，前段应用变化很快，但是中台的共享组件本身应该是稳定的，前台更多是中台共享服务能力的组装。
　　可以对中台的组件做进一步的细分，使其更加有层次性，也符合SOA参考架构思想，如下：数据组件：提供基础数据或共享数据能力，例如用户中心，商品中心，店铺中心等。业务组件：提供单一业务能力组件，例如订单中心，库存中心流程组件：提供业务组合能力的组件，需要底层多数据业务组件支撑，例如交易中心等。
　　注意这里的数据组件仍然是属于业务中台内容而非数据中台，即业务中台里面的组件本身可以分为提供数据能力，提供业务规则能力，提供组合能力等。对于数据中台和业务中台的区分，在前面文章我也有谈到过，可以参考。
　　传统企业内部ESB服务总线建设更多强调的是集成，虽然ESB本身提供共享服务能力，但是如果共性能力本身不下沉，并在下沉前提下提供共享服务能力接口，那么其本质仍然是烟囱式应用。
　　注意，传统企业如果是遗留系统后续改造并实施ESB的情况下，很难真正做到业务沉淀，其核心原因还是已经实施完成的遗留系统接口很难按新的服务识别和定义标准迁移，共性能力也很难真正做到下沉。
　　因此很多企业在IT系统建设差不多后实施的ESB只能解决接口集成，标准化和统一管控问题。不能解决业务沉淀和业务服务资产积累方面的诉求。
　　企业多年的业务，多年的IT业务系统实施究竟能够沉淀什么样的IT资产下来？
　　这个是每个CIO都值得认真去考虑的问题。数据库本身不是最优资产，前端应用更加不是，而真正最佳的资产就是中台的各个共享组件和共享服务，即包含了数据业务逻辑两个方面的重要内容。
　　真正最佳的共享服务不是把遗留系统的接口能力适配接入并暴露服务，而是真正将共性业务下沉为共享组件（即前面说的各个中心），再由共享组件暴露共享服务。
　　即先做共享业务组件能力下沉，再做共享服务暴露和API能力开放。而对于传统企业ESB实施更多的是解决接口集成问题，而不是共性能力下沉问题，这也导致了企业ESB更多的是数据集成和交换，而不是服务的共享和能力开放。
　　阿里共享业务事业部的五大价值定位：开放，服务，滋养，稳定，数据。
　　专家的形成：单知识点》知识组合》知识串联》完整的知识体系架构。共享服务中心和业务相互促进，可以看到共享服务中心暴露的共享服务能力也驱动业务进行价值创新。即我当前已经有这些服务能力，这些服务能力究竟能够通过组合玩出什么新花样来？
　　坚实的中台支持业务快速创新和试错，因为基于共享能力组合往往创新需要投入的资源和成本最小。比如当你要创新一个团购平台的时候，你发现原来中台提供的诸多共享服务都可以复用，这个时候更多的工作往往是在前台应用，以及服务的组合和组装。
　　数据层面的问题很多，包括了数据格式不统一，不标准，数据多处落地，数据不一致，没有全局数据视图等多方面的问题。但是要看到对于数据问题的解决不再是传统的数据集成和交换，要解决数据问题首先要解决共享数据单元下沉到平台层，形成数据中心再提供服务能力。数据能力下沉到平台，自然会形成标准的数据模型，并实现对数据的统一管理能力。
　　注：共性数据能力的下沉并形成数据服务能力对外开放，对应到数据中台能力。在原来谈这点的时候少谈了一个关键就是跨域共性数据能力，即要先聚合集成，再下沉。
　　业务组件化的同时涉及到组织和团队也小规模化，或者说中台战略也推动业务组织架构变革。
　　为何要组件化或实施微服务架构，传统单体应用的问题这本书也做了详细的阐述，主要包括了如下几个方面我不再展开。项目团队协同成本高，业务响应慢。系统复杂度超出人的认知和管理范畴。错误难以隔离。数据库连接能力很难扩展。应用扩展成本高。
　　解决以上问题的根本在于业务拆分，和当前微服务架构思想是一致的。而在进行拆分的时候，可以选择基础主数据，共享数据模块首先拆分和下沉，原因还是业务逻辑相当简单和独立。
　　对应到我们自己项目的微服务转型，具体述求总结如下：
　　其一是原来大单体应用在高可用性，性能，可扩展性上很难达到要求。比如数据库在使用RAC集群后还存在瓶颈的时候很难再拆分。再比如我们所有的子模块都编译在一个大的部署包里面，往往任何一个模块本身出现异常或问题，都将导致所有模块不可用。
　　其二是无法满足敏捷协同的需求，这个协同既包括了我们自己前方实施，工程团队和后方开发团队的协同，我们开发人员和测试人员协同，也包括了我们面对客户需求的时候敏捷交付协同。这些都存在效率和敏捷性严重下降问题。
　　其三就是后续的平台运维，变更处理上面不方便。即使一个小版本发布往往也需要3周以上时间，一方面是敏捷性不够，一方面是系统很难运维，还经常会出现由于A模块的修改导致了B模块功能出现问题和异常的情况。
　　也正是这些原因，我们自己的大系统也启动了微服务架构改造工作。从SOA到分布式服务框架
　　传统中心化ESB总线架构
　　去中心化服务框架仍然是SOA架构，因为实现了服务松耦合，支持服务组装，服务注册发现，服务管控治理等基础的SOA架构能力。但是对于重的协议转换，适配器，数据映射能力不再支持。而这些能力重要性越来越弱，特别是新规划和建设系统，因此中心化ESB节点作用越来越弱，反而影响性能和后续扩展。
　　中心化的ESB服务总线，书里面提到了两个方面的关键问题，如下：服务调用方式的不同带来的业务响应和扩展成本（一个是性能，一个是扩展性）雪崩效应约束了中心化服务框架的扩展能力，即集群节点本身会出现故障导致雪崩
　　今天再回顾这个内容，可以看到不仅仅是ESB总线，在微服务架构体系里面如果你使用了API网关，本身也是中心化架构，也存在上面的问题。
　　而真正去中心化是我们现在说的服务注册中心方式，或者ServiceMesh方式。
　　中心化架构本身导致的问题即我们常说的性能，可靠性和可扩展性。即ESB总线本身不能宕机，如果总线宕机所有接口将导致不可用。其次即性能问题，所有的消息数据流都要过总线，自然会带来更大的性能损耗，同时对ESB总线本身也需要资源扩展和集群部署。但是对于雪崩效应，本身和是否中心化架构没有关系。即使非中心化架构模式，本身也存在雪崩效应的问题。
　　阿里分布式服务框架
　　阿里分布式服务框架发展路线：DubboHSF，DubboX为外部扩展分支。
　　HSF分布式服务框架包括了的主要内容为：服务提供方（集群部署，单个服务中心也会部署多个点）服务消费方（集群部署，单个服务中心也会部署多个点）地址服务器（只提供地址信息）配置服务器（真正的服务注册信息提供，详细的服务注册名称，访问地址等）Diamond服务器（类似Zookeeper调度，涉及到安全管控，流控，权重路由时候才需要）
　　阿里的HSF框架采用NettyHessian数据序列化协议实现服务交互。NettyHessian的组合在互联网高并发量的场景下，特别是在TPS达到10w以上时，性能和效率远远高于HTTPRest或WebService接口。
　　注意当前的HSF框架实现中，可订阅的服务地址列表信息是全部返回到了服务消费方服务器的，也就是说实际的负载均衡和路由是在服务调用方服务器完成而不是在于配置管理服务器或者类似微服务架构中的微服务网关中完成。调用方服务器本身可以缓存地址或配置信息，这样的话配置服务器即使全部宕机也不影响实际的服务调用和服务消费。
　　同样，HSF的容错和重试，服务消费方服务器整个过程中也不再需要从配置服务器获取服务地址列表。对于配置服务器本身需要具备对服务提供方服务器的实时健康心跳状态检测能力，一发现问题则从可用的服务地址列表信息中踢出。
　　可以看到上面这个内容有些已经过时。上面谈到的内容实际重点还是在Dubbo分布式服务框架里面，当前又有了专门的Nacos服务注册中心。对于分布式服务框架采用Dubbo还是SpringCloud前面也谈到过，虽然Dubbo可以走底层RPC调用，但是大部分应用来说SpringCloud框架提供的性能已经足够满足需求。
　　注意在我前面微服务架构和Docker持续集成文章中谈到过，当启用Dockerk8s的时候，这部分的能力完全可以迁移到Dockerk8s来实现，即由k8s集群提供出一个浮动IP供外部消费方访问。对于k8s动态分配出来的容器单元的可用性，内部的负载均衡和路由则由k8s内部机制来管控。
　　注：对于Kurbernetes提供的集群和服务注册功能，整体在服务本身的心跳监测，容错等方面比类似微服务里面的Eureka，Nacos来说能力偏弱，比如心跳不正常后对节点的自动踢出等。但是结合ServiceMesh后可以补足。
　　同样，由于是去中心化架构，整个数据流都不会通过地址，配置等服务器，因此这些服务器本身无压力。实际的线性扩展也是服务调用方或服务消费方服务器本身的扩展和管理，前面已经谈到，在使用Dockerk8s来实现后者部分扩展和动态调度管理会变得更加简单。
　　对于微服务架构实践，Docker只是解决了资源层调度和扩展问题，而对微服务架构本身的治理和管控并没有解决，这些通过当前主流的微服务框架如SpringCLoud等可以解决部分。
　　对于微服务架构实施，真正的难点书里面提到了如下几个点，确实都很关键：微服务化的应用架构如何有效管控（特别是服务链路跟踪和服务链分析）分布式事务难题（组件化和拆分后不可避免）自动化运维和平台稳定性（对于DevOps思路可以解决部分）微服务本身设计（包括了微服务的划分，接口的定义，如何保证可重用）
　　共享服务中心
　　共享服务中心是中台架构基石，这里更多指的是共享业务组件和服务能力。
　　共享能力包括了两个层次：
　　第一个层次是底层PaaS的技术能力，PaaS解决大型架构在分布式，可靠性，可用性，容错，监控以及运维层面上的通用需求；
　　第二个层次是业务能力，业务服务能力提供云化的核心业务支撑能力，这层能力建设的好坏，直接决定了是否能够真正支持上层业务达到敏捷，稳定和高效。
　　服务中心是业务领域的概念，服务中心即我常说的业务能力组件化和服务化，服务中心是共性业务能力的下沉，在下沉后再提供和暴露统一标准的服务接口。注意服务中心本身也是带界面的，但是书里面能看到的是服务中心本身的界面更多是基础数据和配置信息维护界面，而不是实际的业务类界面。
　　服务中心提供的服务包括：依赖于接口的服务依赖于工具的服务依赖于数据的服务
　　服务中心的建设需要兼顾设计，运营和工程三个方面的需求，具体说明如下：设计：遵循面向对象的分析和设计方法运营：服务中心是一个完整的业务模型，要有数据运营和业务整合的价值工程：设计要方便后续运维，避免颗粒度太小导致的大量分布式事务问题等
　　数据库拆分
　　对于数据拆分的内容，在我前面专门整理了一篇文章可以参考：
　　聊聊DaaS数据库即服务和微服务下数据库拆分
　　阿里的数据库拆分发展过程：Cobar》TDDL》DRDS（分布式关系数据库服务）
　　对于Cobar不支持的跨库数据聚合，子查询，GroupBy，OrderBy等在TDDL都全部支持，包括对数据库分布式事务的支持能力。
　　异构索引表的设计实现了将单次全部扫描转换为两次的基于索引的扫描，提升效率。
　　精卫填海项目：基于Mysql的Binlog日志的实时数据复制框架，这个也是开源的可以参考。精卫平台更加重要的是实现了心跳监控，延迟堆积监控，任务状态和数据监控能力。
　　将多条件频繁查询引入到搜索引擎平台：
　　数据库》xml文件》索引文件（整个过程要实现实时或准实时），采用开源的Lucense，Solr，ElasticSearch来实现基于索引文件的快速检索，而不再需要频繁访问数据库。
　　在基于异步消息服务集成的架构下，则可以是消息中间件实时分发变更信息到索引文件库，以保证索引文件库和数据库一致，这和数据库实时同步复制一样的道理，但是实现方法不同。
　　异步化和缓存原则
　　要注意到传统ESB服务组合和编排的时候往往更多采用的是同步化方式，一直保持长连接。或者通过独立的大方法体实现的时候，也容易将多次服务接口的调用同步化到一个大方法体里面。但是当所有的业务逻辑都在一个JVM中顺序执行的时候，其性能和扩展性都受到制约，这也是考虑异步化的一个重要原因。
　　在微服务架构体系下的API接口调用，一定要注意的就是长连接和大数据量，这两者都是较长时间的占用内存资源，线程池资源，直接导致后果就是JVM内存异常，同时在内存溢出前Server实际处于一种Hang的假死状态，心跳监测又能过，导致也无法被注册中心踢出。
　　大的业务操作》拆分到不同的处理和计算单元异步调用实现，前端也无需长连接下等待，占用资源。阿里内部是使用消息中间件的方式来实现了业务的异步化，消息中间件本身就能够很好的持续消息的发布订阅，消息的重试，消息缓存等能力。
　　为了解决大的数据库事务对数据库资源的占用，表锁定，已经性能问题，可以考虑数据库事务本身的异步化。通俗来说，就是将大事务拆分为小事务，降低数据库资源被长时间锁定占用而造成的数据库瓶颈，能够大大的提升平台的处理吞吐量和事务操作响应时间。
　　数据库事务异步化同样需要考虑业务的回滚和重试机制。
　　分布式事务处理
　　强一致性（CAP中的一致性）》最终一致性（BASE理论），当前在分布式服务框架中，更多采用的仍然是最终一致性保证策略。即书里面提到的柔性实务状态，对于柔性实务对分布式事务问题的解决：引入日志和补偿机制，对于正常操作提供幂等的反向操作以用于回滚。可靠消息传输：出现异常的是可以使用消息中间件的重试机制进行重试。实现无锁：为获取高性能和高吞吐量选择放弃锁
　　阿里的分布式事务处理平台XTS分布式事务处理框架。注意在这个事务处理框架中，你提供的任何一个业务服务都必须提供三个子服务（Try，Confirm和Cancel）。其中Cancel用于失败后的补偿和回滚。
　　对于柔性事务，在实现业务的最终一致性时候，需要采纳以下配合方案：应用程序或服务一定要做幂等实现。远程模块用异步消息来驱动，异步消息还可以起到检查点的作用。
　　对于事务处理方案，我们列个表格比较如下：
　　当前主流的方法仍然是事务补偿和BASE最终一致性，同时可以看到，基于消息中间件实现的事务最终一致性由于本身具备高可靠，高性能，并满足大并发的高吞吐量，因此在互联网应用往往采用的更加多。在企业内部的基于SOA服务的分布式事务控制，
　　打造数字化运营能力
　　在业务服务化后，大量的服务接口交互调用，会出现更加错综复杂的服务调用关系，而且在去中心化的服务框架实现模式下，整体调用是一种网状复杂关系。那么如果一个服务API接口调用出现问题，具体应该对应或追踪到哪个业务场景？对于服务开发者必然会关心如下问题：我的服务在什么链路下被调用，调用场景和数据是否合理？目前服务调用趋势如何？产生的瞬间峰值有多少？是否达到服务能力的最高水平？
　　而对于业务架构师而言，从技术到业务视角，往往会关心如下问题：当前的业务流程设计中，我依赖了哪些应用，哪些服务？整个链路的依赖路径是如何的？哪些服务对当前业务处理来说最为核心，SLA等级最高？一次完整的业务请求纠结经过了哪些服务调用，时间究竟花费在哪些地方？我所负责的业务链路中，哪些服务出错率高？哪些服务是业务链路本身的处理瓶颈？
　　服务链监控平台
　　阿里针对分布式服务调用链跟踪平台鹰眼，类似的有Twitter的Zipkin，华为开源SkyWalking等。
　　对于阿里的鹰眼可以看做是一种异步实时的实现模式，底层核心是基于JStorm流式计算引擎，通过实时的采集，拆分，解析，计算和归并得到最终的业务统计和性能统计数据。
　　注意，每个运行应用所在的服务器上均有一个代理程序，专门负责实时的将生成的增量日志发送到鹰眼处理集群上。为了确保追踪一次完整的业务请求，就需要进行埋点和输出日志，对于一次完整的业务请求调用需要全程都传输一个全局唯一ID信息，在鹰眼平台叫做TraceID，这个在前面服务链监控中我也谈到过，但是遗漏了一点。即如果要进一步追踪到整体的服务调用链层次结构和嵌套关系，还需要进一步传输RCPID信息，以确保最后的链路显示有层次和嵌套关系。
　　在埋点和输出日志中往往需要包含如下关键信息：TraceID，RPCID，开始时间，调用类型，对端IP处理耗时处理结果（ResultCode）数据传输量：请求大小效应大小
　　阿里海量分布式日志处理平台Tlog，实现日志采集，日志格式定义，日志解析和处理，日志输出和展示。同时Tlog采用GoogleBlocky可视化编程工具实现了日志解析格式的灵活配置和定义。
　　注意对于鹰眼平台的监控已经不是传统网管平台对资源层面的监控，而是上升到了应用和服务性能层面的监控，也是我们常说的APM应用性能监控方面的内容。其典型业务场景包括：服务实时监控（服务QPS，服务响应时间等）服务调用链跟踪（相当重要，为了显示完整层次逻辑，必须TraceIDRPCID）服务调用链分析（QPS，调用次数，耗时，依赖度，顺序）业务全息排查（实现服务调用链路信息和业务事件信息进行集成）业务实时监控（从单纯的技术监控到对业务事件和业务指标的监控，体现业务价值）
　　有了服务链跟踪这一功能，才使得阿里应用服务化后的平台从一个无服务管控的状态变成一个真正可管可控的状态。服务调用链跟踪的功能着重于对业务链路数据的实时监控，服务调用链分析则是对服务调用数据按照不同维度进行离线的统计和分析，两者相辅相成。
　　通过全息信息排查，将鹰眼平台从对跨系统调用追踪升级为跨业务领域追踪，走出了从运维平台朝运营平台转型的重要一步。
　　打造平台稳定性能力
　　平台稳定性的创新和积累包括了限流和降级，流量调度，业务开关，容量压测和评估，全链路压测平台，业务一致性平台等方面的内容。在双11或秒杀大促等活动中，稳定性就更加重要。平台的稳定性涉及到硬件基础设施（服务器，网络，存储），平台技术和应用架构，服务设计和监控，软件和应用等多方面的内容。
　　限流即流量控制，一方面是可以通过对资源层的资源性能监控触发限流，一个方面是根据预设的服务访问QPS阈值等触发限流操作。当前实际往往是以第二种为主。
　　阿里在Nginx上扩展组件TMD实现了接入层限流，可通过域名，Cookie，黑名单等多方式限流。
　　阿里限流熔断平台Sentinel
　　Sentinel有着丰富的开源生态，覆盖微服务、APIGateway与ServiceMesh几大核心生态。
　　Sentinel开源已经纳入CNCFLandscape版图，并且也成为SpringCloud官方推荐的流控降级组件之一。社区提供SpringCloud、Dubbo、gRPC等常用框架的适配，开箱即用；同时支持Reactive生态，支持Reactor、SpringWebFlux异步响应式架构。Sentinel也在逐渐覆盖APIGateway和ServiceMesh场景，在云原生架构中发挥更大的作用。
　　以下是Sentinel和Hystrix限流熔断功能的对比：
　　两个基础概念，资源和策略，对特定的资源采用不同过的控制策略，起到保障和稳定性的作用。注意Sentinel已经是一个完整的限流监控管理平台，能力包括了：授权：通过黑白名单实现服务调用访问授权限流：对特定资源进行调用的保护，防止资源的过度调用降级：当依赖的资源响应时间过长时进行自动降级，并在指定时间自动恢复调用。监控：提供全面的运行状态监控，可以实时监控资源的调用情况
　　流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线操作，以屏蔽单点故障影响。注意这和PaaS的动态资源调度还是有区别的，特别是增加了业务指标的监控。具体指标包括：系统指标信息：CPU，Load等。业务指标信息：Http响应时间，HSF服务调用时间，QPS，线程池使用和状态信息等。
　　在HSF框架里面则主要是通过动态的调整权重路由值来降低对问题服务器的路由权值，直到0，最终达到通过自动化的流量调度来隔离故障。服务治理和管控
　　对于服务治理实际上包括了两个方面的重要内容，即：
　　1。服务全生命周期管理层面
　　在服务全生命周期管理层面，服务治理需要解决的大问题包括了服务如何接入，服务如何消费和使用，服务变更和版本如何管理，服务如何上线，如何下线，服务开发的具体流程和规范是如何的，接口实现的方式和类型有哪些具体的要求和约束是如何的？
　　以上都可以纳入服务全生命周期管理阶段服务治理的内容。基于以上内容可以看到，在我们进行管控平台实现的时候则会基于服务全生命周期管理的治理思路，将核心功能分解为服务目录和元数据管理，服务识别和定义，服务设计，服务开发，服务测试，服务部署，服务开通等关键功能。
　　2。服务运维和管控
　　服务运维和监控是服务治理要解决的第二大类问题，对于服务治理本身来说主要是服务上线后如何运维，问题解决流程是如何的？问题排查流程是如何的？服务变更或新版本如何发布？服务多个版本如何管理？
　　除了运维，更加重要的就是服务监控，而服务监控首先要定义服务监控具体的指标，类似服务运行次数，运行时间，并发量，数据量，服务性能，服务异常情况等都需要监控。同时还需要基于服务SLA策略的需要，制定服务预警和告警机制，确保在服务运行异常前首先能够告警。
　　服务的SLA如何管，如何设置也是服务治理要解决的关键问题。
　　在服务集成的监控问题解决后，更加重要的则是从服务的技术类监控转移到业务监控，服务的交互调用最终都是业务产生的，那么通过服务本身的调用和调用关系，就应该很容易的逆向出对应的业务交互监控情况。
　　服务化改造和发展的持续进行，传统人工模式的服务支持带来越来越多的问题，具体如下：服务的数量和业务覆盖范围越来越大（如何高效找到服务并快速使用？）应用和业务架构越分越细，跨领域理解的成本越来越高服务安全控制层缺乏（数据安全，服务SLA，服务依赖关系，恶意服务调用等）开发体验不好，产品在接入流程，开发手册建设非常差整体服务体系缺乏一个统一的服务治理层
　　服务核心是暴露一个标准共享的服务接口能力，而服务化核心是从产品能力转化到直接服务客户的能力，实现按需服务。服务化的思路就是把产品和服务的重心转移到用户身上，以方便用户使用，降低使用成本为目标。
　　实践共享服务最基本的目标就是把普通的服务能力升级为组件化服务并提供良好的服务治理支持。所以这里面涉及到三个重要内容，也是我很多文章里面谈SOA和服务经常谈到的，即：建设服务化基础设施和平台业务组件化和组件能力服务化，划分好组件，控制好服务粒度后期的服务管控和治理体系，治理平台建设。
　　阿里服务化构建过程和基本思路，包括如下：确定服务化的对象是API（数量是巨大的）建设API服务封装和管理基础设施（元数据，服务注册接入，安全，SLA，基础运维，监控）服务化实施（从APIasService逐步发展到ProductasService，更加体现业务价值）
　　而实际上我们看到，很多企业在实施微服务架构转型的时候，管控和治理能力往往无法跟上，这里面既涉及到微服务架构设计，微服务划分和API接口设计等技术能力。又涉及到整个微服务全生命周期管理，集成，后期的微服务监控运维等能力。
　　由于微服务下模块拆分的更加细，API接口也指数级增长，如果管控治理能力无法跟上，那么企业面临的将是一个更加混乱和不可控的IT环境。