从阿里中台战略看企业IT架构转型之道

此文是我阅读《企业IT架构转型之道》一书的学习笔记，所有内容出自钟华老师的这本书。

零、为何读《企业IT架构转型之道》

　　在加入X公司后，开始了微服务架构的实践，也开始了共享平台服务的建设，在这方面阿里巴巴的中台战略是一个较好的参考。于是，领导就赠了这么一本《企业IT架构转型之道》给我，希望我学以致用，更多的是有这样的一个眼界去指导我们的中台架构设计。因此，我花了两周时间快速地阅读了一下此书，总结了此文作为学习笔记以供日后复习用。此书的确讲了一些干货，虽然很多内容留于表面，但是对于中台的定义和思考，建设中台的方法以及阿里中间件有比较完整的描述，和多年前出版的《淘宝技术这十年》以及《大型网站技术架构-核心原理与案例分析》一样，是一本值得学习的好书。

一、引子

Part 1 阿里中台战略引发的思考

• 起源自2008年阿里巴巴三大电商体系的技术支持架构
  • 1688、淘宝、天猫三套电商体系架构完全独立
  • 三座烟囱分别矗立支撑阿里巴巴最核心的电商业务
• 烟囱式系统建设系统对企业的“三大”弊端
  • 重复功能建设和维护带来的重复投资
  • 打通“烟囱式”系统间交互的集成和协作成本高昂
  • 不利于业务的沉淀和持续发展 => 对企业伤害最大
• 企业信息中心的组织职能是业务支持？
  • 问题核心在于IT信息部门在现有模式下大多被高管定位为业务支持的部门 => 一个花钱的成本中心
  • 问题原因在于IT信息部门的人员不懂业务 => 这里的懂业务是指“能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好的地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。”
  • 问题结果导致了IT信息部门的人员很少能在一个业务领域做足够的业务沉淀 => 对业务知其然而不知其所以然

“烟囱式”的系统建设模式

Part 2 构建业务中台的基础—共享服务体系

• SOA架构的核心价值
  • 服务重用 => 从服务重用到共享服务
• 共享服务体系的建设：克服“烟囱式”架构的三大弊端
  • 避免重复功能建设和维护带来的成本浪费 => 没有实现系统业务互通的诉求
  • 最大程度避免打通不同系统间实现业务交互带来的集成和协作成本 => 各个应用在核心业务层已经实现了统一和畅通
  • 能够很好地培养出特定领域的专家 => “既精通业务，又熟悉技术”的复合型人才
• 企业信息中心组织阵型的调整
  • 针对共享服务体系重新组织人员，使成员有机会成为业务领域的专家（复合型人才）
  • 最核心的角色是架构师，他们会是各服务中心的业务负责人
  • 信息团队会从“业务支持”的组织职能转向基于企业核心业务和数据进行运营的团队

阿里巴巴的“大中台”体系建设

PS：在阅读这一部分时，个人最大的感触就在于企业信息中心的境遇，我所在的公司是一个传统行业，我们部门是从2018年末开始扩建的信息中心，和广大企业信息中心一样，虽然无一不被认可信息部门对企业发展的重要地位，行政级别也和核心业务部门的级别相当，但是实际情况却是没有同样平等的话语权，因为在高层领导的眼里就只是单纯把信息中心定位为了业务支持部门，是一个花钱的成本中心。而造成这样处境的原因，也很赞同钟华老师在书中的观点，那就是信息部门的员工不懂业务，这里的不懂业务是指能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好的地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。而要提高信息部门的员工对于业务的精进，需要建设类似阿里巴巴的共享服务中心，服务需要不断的业务滋养才能足够强大地支持前线的士兵，也只有在滋养中才能从最初提供单薄业务功能的服务组件成长为企业最为宝贵的IT资产。正如钟华老师所示，未来在整个社会进入开放共享的时代，企业最大的价值将会是基于核心业务和数据进行对外开放的运营，到那时信息部门的共享服务体系将成为企业最为宝贵的资产。

二、共享服务体系的搭建

Part 3 分布式服务框架的选择

• “中心化”与“去中心化”服务框架的对比
  • 服务调用方式的不同带来业务的响应和扩展成本：基于ESB的响应速度慢（因为网络开销大一倍），而要扩展ESB需要承担软硬件的不小投入（比如巨大的授权费）
  • “雪崩”效应束缚了“中心化”服务框架的扩展能力：不适合互联网企业的根本原因，因为一旦雪崩故障恢复的时间和成本都非常高昂！
• 阿里巴巴的分布式服务框架HSF
  • 组成部分：服务提供者、服务调用者、地址服务器（Nginx）、配置服务器（服务注册&发现）、Diamond服务器（类似于Zookeeper）
  • 工作原理：服务节点对配置服务器列表的获取、服务的注册发布、服务的订阅、服务规则的推送（如果需要）、服务交互
  • 核心能力：Netty+Hession数据序列化协议实现服务交互（大并发量下的高性能）、容错机制（长连接+秒级感知）、线性扩展（增加服务实例即可扩展服务能力）
• 关于微服务
  • 阿里巴巴2009年开始的共享服务体系算得上是微服务实践的先驱
  • 从本质上说，微服务是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别
  • 微服务与SOA的两点最鲜明差异在于：
    • 传统SOA架构基于“中心化”的ESB构建，而微服务采用的是系统提供服务的方式实现系统间的互通；
    • 传统SOA实施的方式是项目制，而微服务是以做产品的方式让服务在业务发展过程中快速演化；
  • 概念一时爽，问题一堆堆：
    • 微服务化的应用架构的有效服务管控？
    • 分布式事务的难题？
    • 自动化运维和平台稳定性？
    • 微服务的服务设计？=> DDD

PS：微服务不是“免费的午餐”，阿里巴巴2009年开始的共享服务体系建设历程算得上是微服务架构的建设过程。正如钟华老师所说，“罗马不是一天建成的”，企业如果要构建微服务架构体系，也是需要多一份耐心的，通过服务能力在业务发展过程中的不断沉淀，当业务的能力沉淀到一个阶段后，才能真正感受到微服务架构给企业的业务发展带来的长远价值。

Part 4 共享服务中心建设原则

• 服务中心的三个特征
  • 服务中心是伴随业务不断发展的：不做过于超前的设计，也不做过于理想化的架构
  • 服务中心的服务形态多样化：接口、工具、数据...
  • 一个服务中心还可以进一步划分：单个服务模块、多个服务模块...
• 服务中心的划分原则
  • 更多靠的是架构设计经验总结，很难给出精确的量化指标
  • 一般来说会兼顾3个方面的需求：
    • 设计 => 遵循面向对象的分析和设计方法论
    • 运营 => 服务中心应该是一个完整额业务模型
    • 工程 => 综合评估业务层对服务中心在DB、业务以及运营方面的需求和技术上需要的投入
  • 实际中的一些基本原则：
    • 高内聚、低耦合原则
    • 数据完整性原则：特别强调大数据思维
    • 业务可运营性原则：服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元
    • 渐进性的建设原则：小步快跑，服务化从简单开始！

PS：记得张逸老师在《领域驱动战略设计实践》课程中的开篇提到他向DDD大师Eric Evans提问“如何正确地识别限界上下文？”，结果Eric Evans思考了一会儿，严肃地回答了一句：“By experience！”。这是一个正确的废话，但好像又蛮有道理。对于共享服务中心的建设和划分来说，也同样如此，更多的是依靠架构设计经验的总结，作者也很难给出一些具体问题给出一个精确的量化指标。正如作者所说，架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题。

Part 5 数据拆分实现数据库能力线性扩展

• 数据库分库分表的实践
  • 阿里巴巴分布式数据层平台发展演变：Cobar(2006) => TDDL(2008) => DRDS(2014)
  • 数据尽可能平均拆分：需要结合业务数据的结构和业务场景来决定
  • 尽量减少事务边界：“事务边界”指单个SQL语句在后端数据库上同时执行的数量
  • 异构索引表尽量降低全表扫描频率：“拿空间换时间”，阿里巴巴的精卫填海产品
  • 将多条件频繁查询引入搜索引擎平台：采用专业搜索引擎平台提供搜索服务，Lucene、Solr、ElasticSearch
  • 简单就是美：“数据尽可能平均拆分”作为第一优先考虑，82法则

PS：阿里巴巴的分布式数据层平台发展的演变可谓是一部技术驱动变革的历程，经历了一个又一个的技术难题，出现了一个又一个的开源/商用产品，提高了阿里巴巴的效率。印象深刻的地方在于，我们都有一个印象就是在数据库开发和调用时，要充分利用索引，避免全表扫描。但是，作者说到在真实的业务场景中很难完全避免全表扫描，比如对于订单进行复杂的分布式条件检索的时候，就会需要采用全表扫描，将查询语句同时推送到后端的数据库中才能实现该场景。但是，因为调用量不会很频繁，而且计算的数据量并不大，所以整体上不会给DB产生太大的影响。另外一个点就是，从系统风险的角度来看，以82法则，在实际中，作者建议仅对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对于其他80%偶尔出现跨库join、全表扫描的场景，采取最为简单直接的方式往往就是最有效的方式。

Part 6 异步与缓存原则

• 异步化
  • 业务流程异步化：服务异步调用，提升大量远程服务线性调用带来的性能问题
  • 数据库事务异步化：将大事务拆分成小事务，提升吞吐量和事务操作的响应时间
    • 事务 => 核心是ACID
    • 柔性事务 => 基础是CAP理论和BASE理论，因为互联网应用最核心的需求是高可用（BASE中的BA）
      • 解决分布式问题的机制：①日志和补偿机制、②可靠的消息传递、③无锁实现（避免事务回滚、辅助业务变化明细表、乐观锁等）
    • ACID与BASE一般在系统中会结合使用，追求最终一致性
• 缓存
  • 小库存商品秒杀典型架构
    • 核心问题：处理好商品的库存的扣减，不出现超卖的情况
    • 核心方案：
      • 缓存商品的详细信息（包括库存），不直接访问后端数据库
      • 商品库存使用乐观锁，避免出现超卖
      • 商品库存控制业务流，只在下单环节才对数据库访问，降低数据库访问频率
  • 大库存商品大促架构
    • 核心问题：处理好库存更新的准确与用户等待时间的平衡
    • 核心方案：
      • 将缓存提升到为库存操作提供事务支持的角色 => 将订单交易创建环节在缓存服务器中运行，提高响应速度
      • 借助消息队列实现缓存服务器中的库存修改线性处理
      • 缓存服务故障时通过缓存数据和数据库订单信息还原订单处理的最新状态

PS：异步化与缓存两个技术都和我们的系统性能有很大的关联，在分布式应用架构中，如果没有这两项技术的引入，相信设计出来的应用很难有优质的性能表现。淘宝平台是一个典型的分布式服务架构，通过业务流程异步化提升了性能，分库分表后又在异步操作场景下实现了事务一致性与数据库处理性能的平衡。最后，通过适当使用缓存技术实现了商品秒杀场景下的技术架构，这都是我们需要学习和借鉴的。

小库存商品秒杀场景订单处理流程图

大库存商品秒杀场景订单处理流程图

Part 7 打造数字化运营能力

• 业务服务化带来的问题
  • 服务调用关系纷繁复杂，难以定位问题
  • 不同角色的技术人员需要一些列的管控
• 分布式服务调用链路平台
  • 阿里巴巴内部实现：“鹰眼”平台，JStorm流式计算引擎
  • 核心思路：埋点和输出日志
• 海量日志分布式处理平台
  • 阿里巴巴内部实现：TLog平台，日志处理流程“所见即所得”
  • 日志收集控制：遇到大量请求时只记录其中一部分数据，而非全量收集

PS：实现初步的分布式服务体系之后，我们的平台必然会变成一个比较复杂的交互链路网，这会对我们的管控带来一些问题，比如服务调用链监控、服务运行状态是否正常，如何提供关键指标以实现精准营销等等。好在无论是商用产品还是开源产品，都有了比较成熟的技术方案，我司已经在调研学习Skywalking和ElasticSearch，以后有机会做这方面的分享。

　　在此推荐一波Skywalking：

　　在 ASP.NET Core 中集成 Skywalking APM （from savorboard 杨晓东）

　　Apache SkyWalking 为.NET Core带来开箱即用的分布式追踪和应用性能监控 （from Lemon 刘浩杨）

　　使用docker-compose 一键部署你的分布式调用链跟踪框架Skywalking （from 一线码农 黄星辰）

　　更多Skywalking分享：https://github.com/OpenSkywalking/Community

Skywalking中的请求调用链拓扑视图

Part 8 打造平台稳定性能力

• 提高稳定性的实践
  • 限流和降级：限流相当于电路保险丝，而降级则是为保证核心服务而牺牲自己，阿里巴巴自研Sentinel限流平台
  • 流量调度：通过实时指标监控，对预计发生故障的服务进行下线等操作，以避免单点或局部故障
• 业务开关：通过集中化管理业务API操作开关，阿里巴巴自研Switch平台
• 容量压测及评估规划：将线上真实流量引到压测服务器，并差异化分析对线上服务器的增减提供实时参考决策
• 全链路压测：每个环节都参加的实战演习，例如双11实战演习
• 业务一致性平台：保证业务与数据一致的业务稳定性，实时检测业务不一致的问题，阿里巴巴自研BCR业务审计平台

　　＃Sential Github: https://github.com/alibaba/Sentinel （轻量级的流量控制、熔断降级 Java 库）

　　＃Sential Wiki：分布式系统的流量防卫兵

　　

Sentinel 的主要特性

Part 9 共享服务中心对内和对外的协作共享

• 共享服务平台的建设思路
  • Step1.找到一个合适的服务化对象：比如API
  • Step2.建设对象服务化的基础设施：比如结构化包装，让API成为治理良好的组件服务
  • Step3.服务化实施阶段：循序渐进的过程，三个阶段参考
    • API as Service => 服务化的第一步
    • Product as Service => 大量业务API升级为服务化平台的组件服务
    • Solution as Service => 经过长时间的沉淀可以形成解决方案，如海外淘宝解决方案
  • Step4.增强服务和基础设施实现服务的精细治理
• 对内：共享服务平台的协作
  • 与业务方的协作：以服务为对象建立一个在线市场，三大角色
    • 共享服务平台 => SPAS
    • 服务提供者 => 商品、交易、店铺、物流等
    • 服务消费者 => 商品、交易、店铺、物流等 （消费者通常也是提供者）
  • 与前端应用协作：服务提供者与消费者，相辅相成，共同发展
    • 阿里巴巴的一些实践：紧密沟通，分歧升级、岗位轮转（换位思考）、业务沉淀及共建
• 对内：业务中台绩效考核
  • No.1 服务的稳定：比如一年只允许两次P1故障
  • No.2 持续业务创新：鼓励业务中台运营团队业务创新，包容业务创新引起的故障
  • No.3 服务接入量：考量服务能力的专业度以及对外的服务运营能力
  • No.4 客户满意度：对中台服务运营团队起到督促作用
• 对外：开放能力构建生态
  • 核心内容：将自身平台中的数据以服务的方式对外进行开放，从而吸引众多外部群体基于这些服务提供增值服务，持续地为客户提供优质的运营平台能力，从而最终构建基于开放平台的生态体系。

PS：在这部分内容里边，印象最深刻的还是作者提到在互联网转型时，很多人想要构建生态，但却没搞清楚“生态”和“上下游”的关系，它们之间的最本质的区别在于：在“上下游”模式中整个体系中所有的参与者都是被动的使用者，而“生态”模式中的参与者确是主动使用者，他们会持续地往整个体系中注入自己的智慧和创新的源泉，不断贡献自己的价值，只有这样的模式才能打造出企业所希望的生态效果。而传统企业现在应该着眼于企业内部的核心业务能力的打造，等到有一天需要通过能力开放的方式拓展企业业务边界或构建生态的时候，这些沉淀的服务会是企业最大的资产，而信息中心部门也不会只是一个成本中心，而有可能变为对外进行能力输出的关键运营部门。

三、阿里巴巴的实践案例

Part 10 大型央企互联网转型

　　阿里巴巴协助国内某大型央企在90天构建出了一个B2B电商平台，整体平台架构基于阿里巴巴的共享服务理念和阿里云飞天Aliware的一系列产品，现在已经成为了国有大型企业进行互联网业务成功转型的标杆性项目。

Part 11时尚行业品牌公司互联网转型

　　某服装品牌民营企业基于阿里巴巴的共享服务架构完成了企业全渠道分销平台的重构，解决了高库存和高流单率的难题，实现了O2O的融合，建立了以客户体验为中心的系统架构，为企业在同行业的竞争中建立了差异化的竞争能力。

PS：2014年开始，国家就开始倡导“互联网+”的转型，越来越多的传统企业加入到互联网转型的浪潮，像我司一样的传统家居企业也开始了转型，于是开始建设信息中心，于是我就来了... 幸运的是，我司已经在成都地区小有名气，并且是一个知名的品牌，接下来要做的，借用作者的原话就是需要我们信息中心能够更好地使用互联网技术、利用互联网服务、借鉴互联网企业的运营模式，更好地实现价值链中各节点的连接，让流程更加透明，业务更加可视，最终能够挖掘企业的瓶颈，更好地满足消费者的需求，以获得更好的成长。对我个人而言，在此期间能够积累和沉淀更多的经验是最重要的，加油！

参考资料

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

James，《给架构师的推荐-企业IT架构转型之道》

马崇，《企业IT架构转型之道的思考》

作者：周旭龙

出处：http://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。