读企业IT架构转型之道01(6.7)

内容简介：读企业IT架构转型之道01(6.7)

这本书全名是《企业IT架构转型之道-阿里巴巴中台战略思想与架构实践》，里面详细介绍了阿里巴巴中台战略的原因，架构演变过程，同时包含了共享服务中心搭建原则，技术选型，高可用和高并发技术等。

这本书推荐给所有大型集团传统企业CIO和架构师阅读，该书内容有一定技术背景都应该能够看懂，在我博客上写过企业私有云PaaS平台和微服务架构一系列文章，很多思想也是类似。一本书有时候并不是一定要学到多少，而是可以真正帮你理清楚一些思绪点，这本书内容讲解整体感觉更加通俗易懂，特别是演进过程，前因后果方面的讲解等。

对于这本书的读书笔记，我只记录我批注已经进一步触发我思考和沉淀部分的内容，不再重复书里面已经讲述的内容。记录内容也不再体现具体章节信息。

在私有云PaaS平台里面谈到了厚平台+轻应用构建模式，但是和这本书里面谈的中台还有些差异。后台更多是指底层PaaS技术平台和技术服务， 而中台更多是共享业务和数据组件能力的下沉 。阿里的中台里面常谈到的就是各种中心（如用户中心，商品中心，库存中心）等，前段时间一直有客户跟我说中心化这个概念，更多的应该是指这个中台里面的各个中心。

前台是前端的各种呈现方式的各类应用，例如天猫，淘宝，小的入聚划算等。基于业务创新需要，前段应用变化很快，但是中台的共享组件本身应该是稳定的，前台更多是中台共享服务能力的组装。

可以对中台的组件做进一步的细分，使其更加有层次性，也符合SOA参考架构思想，如下：

1. 数据组件： 提供基础数据或共享数据能力，例如用户中心，商品中心，店铺中心等。

2. 业务组件： 提供单一业务能力组件，例如订单中心，库存中心

3. 流程组件： 提供业务组合能力的组件，需要底层多数据+业务组件提供支撑，例如交易中心等。

传统企业内部ESB服务总线建设更多强调的是集成，虽然ESB本身提供共享服务能力，但是如果共性能力本身不下沉，并在下沉前提下提供共享服务能力接口，那么其本质仍然是烟囱式应用。

注意，传统企业如果是遗留系统后续改造并实施ESB的情况下，很难真正做到业务沉淀，其核心原因还是已经实施完成的遗留系统接口很难按新的服务识别和定义标准迁移，共性能力也很难真正做到下沉。因此很多企业在IT系统建设差不多后实施的ESB只能解决接口集成，标准化和统一管控问题。不能解决业务沉淀和业务服务资产积累方面的诉求。

企业多年的业务，多年的IT业务系统实施究竟能够沉淀什么样的IT资产下来？这个是每个CIO都值得认真去考虑的问题。数据库本身不是最优资产，前端应用更加不是，而真正最佳的资产就是中台的各个共享组件和共享服务， 即包含了数据+业务逻辑两个方面的重要内容 。

真正最佳的共享服务不是把遗留系统的接口能力适配接入并暴露服务，而是真正将共性业务下沉为共享组件（即前面说的各个中心），再由共享组件暴露共享服务。即 先做共享组件下沉，再做共享服务暴露。 而对于传统企业ESB实施更多的是解决接口集成问题，而不是共性能力下沉问题，这也导致了企业ESB更多的是数据集成和交换，而不是服务的共享和能力开放。

阿里共享业务事业部的五大价值定位： 开放，服务，滋养，稳定，数据。

专家的形成： 单知识点-》知识组合-》知识串联-》完整的知识体系架构 。共享服务中心和业务相互促进，可以看到共享服务中心暴露的共享服务能力也驱动业务进行价值创新。即我当前已经有这些服务能力，这些服务能力究竟能够通过组合玩出什么新花样来？

坚实的中台支持业务快速创新和试错，因为基于共享能力组合往往创新需要投入的资源和成本最小。比如当你要创新一个团购平台的时候，你发现原来中台提供的诸多共享服务都可以复用，这个时候更多的工作往往是在前台应用，以及服务的组合和组装。

数据层面的问题很多，包括了数据格式不统一，不标准，数据多处落地，数据不一致，没有全局数据视图等多方面的问题。但是要看到对于数据问题的解决不再是传统的数据集成和交换， 要解决数据问题首先要解决共享数据单元下沉到平台层，形成数据中心再提供服务能力 。数据能力下沉到平台，自然会形成标准的数据模型，并实现对数据的统一管理能力。

业务组件化的同时涉及到组织和团队也小规模化 ，或者说中台战略也推动业务组织架构变革。

为何要组件化或实施微服务架构，传统单体应用的问题这本书也做了详细的阐述，主要包括了如下几个方面我不再展开。1）项目团队协同成本高，业务响应慢。2）系统复杂度超出人的认知和管理范畴。3）错误难以隔离。4）数据库连接能力很难扩展。5）应用扩展成本高。

解决以上问题的根本在于业务拆分，和当前微服务架构思想是一致的。而在进行拆分的时候，可以选择基础主数据，共享数据模块首先拆分和下沉，原因还是业务逻辑相当简单和独立。

去中心化服务框架仍然是SOA架构，因为实现了服务松耦合，支持服务组装，服务注册发现，服务管控治理等基础的SOA架构能力。但是对于重的协议转换，适配器，数据映射能力不再支持。而这些能力重要性越来越弱，特别是新规划和建设系统，因此中心化ESB节点作用越来越弱，反而影响性能和后续扩展。

中心化的ESB服务总线，书里面提到了两个方面的关键问题，如下：

1.服务调用方式的不同带来的业务响应和扩展成本 （一个是性能问题，一个是扩展性问题）

2.雪崩效应约束了中心化服务框架的扩展能力 ，即集群节点本身会出现故障导致雪崩。

阿里分布式服务框架发展路线：Dubbo->HSF，DubboX为外部扩展分支。

HSF分布式服务框架包括了的主要内容为：

1.服务提供方 （集群部署，单个服务中心也会部署多个点）

2.服务消费方 （集群部署，单个服务中心也会部署多个点）

3.地址服务器 （只提供地址信息）

4.配置服务器 （真正的服务注册信息提供，详细的服务注册名称，访问地址等）

5.Diamond服务器 (类似Zookeeper调度，涉及到安全管控，流控，权重路由时候才需要）

阿里的HSF框架采用Netty+Hessian数据序列化协议实现服务交互 。Netty+Hessian的组合在互联网高并发量的场景下，特别是在TPS达到10w以上时，性能和效率远远高于HTTP Rest或Web Service接口。

注意当前的HSF框架实现中，可订阅的服务地址列表信息是全部返回到了服务消费方服务器的，也就是说实际的负载均衡和路由是在服务调用方服务器完成而不是在于配置管理服务器或者类似微服务架构中的微服务网关中完成。调用方服务器本身可以缓存地址或配置信息，这样的话配置服务器即使全部宕机也不影响实际的服务调用和服务消费。

同样，HSF的容错和重试，服务消费方服务器整个过程中也不再需要从配置服务器获取服务地址列表。对于配置服务器本身需要具备对服务提供方服务器的实时健康+心跳状态检测能力，一发现问题则从可用的服务地址列表信息中踢出。

注意在我前面微服务架构和 Docker 持续集成文章中谈到过， 当启用Docker+k8s的时候，这部分的能力完全可以迁移到Docker+k8s来实现 ，即由k8s提供出一个浮动IP供外部消费方访问。对于k8s动态分配出来的容器单元的可用性，内部的负载均衡和路由则由k8s内部机制来管控。

同样，由于是去中心化架构，整个数据流都不会通过地址，配置等服务器，因此这些服务器本身无压力。实际的线性扩展也是服务调用方或服务消费方服务器本身的扩展和管理，前面已经谈到，在使用Docker+k8s来实现后者部分扩展和动态调度管理会变得更加简单。

对于微服务架构实践，Docker只是解决了资源层调度和扩展问题，而对微服务架构本身的治理和管控并没有解决，这些通过当前主流的微服务框架如Spring CLoud等可以解决部分。对于微服务架构实施，真正的难点书里面提到了如下几个点，确实都很关键：

1. 微服务化的应用架构如何有效管控 （特别是服务链路跟踪和服务链分析）

2. 分布式事务难题 （组件化和拆分后不可避免）

3. 自动化运维和平台稳定性 （对于DevOps思路可以解决部分）

4. 微服务本身设计 （包括了微服务模块的划分，服务接口的定义，如何保证粒度和可重用性等）

共享服务中心是中台架构基石，这里更多指的是共享业务组件和服务能力。

共享能力包括了两个层次， 一个层次是底层PaaS的技术能力 ，PaaS解决大型架构在分布式，可靠性，可用性，容错，监控以及运维层面上的通用需求； 第二个层次是业务能力 ，业务服务能力提供云化的核心业务支撑能力，这层能力建设的好坏，直接决定了是否能够真正支持上层业务达到敏捷，稳定和高效。

服务中心是业务领域的概念，服务中心即我常说的业务能力组件化和服务化 ，服务中心是共性业务能力的下沉，在下沉后再提供和暴露统一标准的服务接口。注意服务中心本身也是带界面的，但是书里面能看到的是服务中心本身的界面更多是基础数据和配置信息维护界面，而不是实际的业务类界面。

服务中心提供的服务包括： 1）依赖于接口的服务 2）依赖于 工具 的服务 3）依赖于数据的服务。

服务中心的建设需要兼顾设计，运营和工程三个方面的需求，具体说明如下：

1. 设计： 遵循面向对象的分析和设计方法

2. 运营： 服务中心是一个完整的业务模型，要有数据运营和业务整合的价值

3. 工程： 设计要方便后续运维，避免粒度太小导致的大量分布式事务问题等

对于数据拆分的内容，在我博客上面已经写过很多文章，这里只列出一下关键批注部分内容。

发展过程： Cobar=》TDDL=》DRDS（分布式关系数据库服务）

对于Cobar不支持的跨库数据聚合，子查询，GroupBy，OrderBy等在TDDL都全部支持，包括对数据库分布式事务的支持能力。

异构索引表 的设计思路：好方法，实现了将单次全部扫描转换为两次的基于索引的扫描，提升效率。

精卫填海项目：基于 Mysql 的Binlog日志的实时数据复制框架，这个也是开源的可以参考。精卫平台更加重要的是实现了心跳监控，延迟堆积监控，任务状态和数据监控能力。

将多条件频繁查询引入到搜索引擎平台： 数据库-》xml文件=》索引文件（整个过程要实现实时或准实时），采用开源的Lucense,Solr，ElasticSearch来实现基于索引文件的快速检索，而不再需要频繁访问数据库。

在基于异步消息服务集成的架构下，则可以是消息中间件实时分发变更信息到索引文件库，以保证索引文件库和数据库一阵，这和数据库实时同步复制一样的道理，但是实现方法不同。

异步化和缓存原则

要注意到传统ESB服务组合和编排的时候往往更多采用的是同步化方式，一直保持长连接。或者通过独立的大方法体实现的时候，也容易将多次服务接口的调用同步化到一个大方法体里面。但是当所有的业务逻辑都在一个JVM中顺序执行的时候，其性能和扩展性都受到制约，这也是考虑异步化的一个重要原因。

大的业务操作-》拆分到不同的处理和计算单元异步调用实现 ，前端也无需长连接下等待，占用资源。

阿里内部是使用消息中间件的方式来实现了业务的异步化，消息中间件本身就能够很好的持续消息的发布订阅，消息的重试，消息缓存等能力。

为了解决大的数据库事务对数据库资源的占用，表锁定，已经性能问题，可以考虑数据库事务本身的异步化。通俗来说，就是将大事务拆分为小事务，降低数据库资源被长时间事务锁占用而造成的数据库瓶颈，能够大大的提升平台的处理吞吐量和事务操作响应时间。

数据库事务异步化同样需要考虑业务的回滚和重试机制。

强一致性（CAP中的一致性）=》最终一致性（BASE理论） ，当前在分布式服务框架中，更多采用的仍然是最终一致性保证策略。即书里面提到的柔性实务状态，对于柔性实务对分布式事务问题的解决：

1. 引入日志和补偿机制 ，对于正常操作提供幂等的反向操作以用于回滚。

2. 可靠消息传输 ：出现异常的是可以使用消息中间件的重试机制进行重试。

3. 实现无锁 ：为获取高性能和高吞吐量选择放弃锁，注意P105页辅助业务变化表和乐观锁方案参考性。

阿里的分布式事务处理平台XTS分布式事务处理框架。注意在这个事务处理框架中，你提供的任何一个业务服务都必须提供 三个子服务（Try，Confirm和Cancel） 。其中Cancel用于失败后的补偿和回滚。

对于柔性事务，在实现业务的最终一致性时候，需要采纳以下配合方案：

1. 应用程序或服务一定要做幂等实现。

2. 远程模块用异步消息来驱动，异步消息还可以起到检查点的作用。

以上所述就是小编给大家介绍的《读企业IT架构转型之道01(6.7)》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 微服务架构：引领数字化转型的基石
• 读企业IT架构转型之道02(6.8)
• 传统企业转型对微服务架构的诉求(12.3)
• 8 年上市、3 年微服务改造、2 年中台战，回顾这家公司 12 年技术架构转型路
• 【SDCC讲师专访】专访架构师薛珂：技术人迷茫应换工作而非急着转型
• 加快企业数字化转型 SMTX OS3.5构建更易用、稳定的超融合架构

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。