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

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

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

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

一、引子

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

• 起源自2008年阿里巴巴三大电商体系的技术支持架构

  • 1688、淘宝、天猫三套电商体系架构完全独立

  • 三座烟囱分别矗立支撑阿里巴巴最核心的电商业务

• 烟囱式系统建设系统对企业的“三大”弊端

  • 重复功能建设和维护带来的重复投资

  • 打通“烟囱式”系统间交互的集成和协作成本高昂

  • 不利于业务的沉淀和持续发展 => 对企业伤害最大

• 企业信息中心的组织职能是业务支持？

  • 问题核心在于IT信息部门在现有模式下大多被高管定位为业务支持的部门 => 一个花钱的成本中心

  • 问题原因在于IT信息部门的人员不懂业务 => 这里的懂业务是指“能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好的地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。”

  • 问题结果导致了IT信息部门的人员很少能在一个业务领域做足够的业务沉淀 => 对业务知其然而不知其所以然

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

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

• SOA架构的核心价值

  • 服务重用 => 从服务重用到共享服务

• 共享服务体系的建设：克服“烟囱式”架构的三大弊端

  • 避免重复功能建设和维护带来的成本浪费 => 没有实现系统业务互通的诉求

  • 最大程度避免打通不同系统间实现业务交互带来的集成和协作成本 => 各个应用在核心业务层已经实现了统一和畅通

  • 能够很好地培养出特定领域的专家 => “既精通业务，又熟悉技术”的复合型人才

• 企业信息中心组织阵型的调整

  • 针对共享服务体系重新组织人员，使成员有机会成为业务领域的专家（复合型人才）

  • 最核心的角色是架构师，他们会是各服务中心的业务负责人

  • 信息团队会从“业务支持”的组织职能转向基于企业核心业务和数据进行运营的团队

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

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

正如钟华老师所示，未来在整个社会进入开放共享的时代，企业最大的价值将会是基于核心业务和数据进行对外开放的运营，到那时信息部门的共享服务体系将成为企业最为宝贵的资产。

二、共享服务体系的搭建

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

• “中心化”与“去中心化”服务框架的对比

  • 服务调用方式的不同带来业务的响应和扩展成本：基于ESB的响应速度慢（因为网络开销大一倍），而要扩展ESB需要承担软硬件的不小投入（比如巨大的授权费）

  • “雪崩”效应束缚了“中心化”服务框架的扩展能力：不适合互联网企业的根本原因，因为一旦雪崩故障恢复的时间和成本都非常高昂！

• 阿里巴巴的分布式服务框架HSF

  • 组成部分：服务提供者、服务调用者、地址服务器（Nginx）、配置服务器（服务注册&发现）、Diamond服务器（类似于Zookeeper）

  • 工作原理：服务节点对配置服务器列表的获取、服务的注册发布、服务的订阅、服务规则的推送（如果需要）、服务交互

  • 核心能力：Netty+Hession数据序列化协议实现服务交互（大并发量下的高性能）、容错机制（长连接+秒级感知）、线性扩展（增加服务实例即可扩展服务能力）

• 关于微服务

  • 微服务化的应用架构的有效服务管控？

  • 分布式事务的难题？

  • 自动化运维和平台稳定性？

  • 微服务的服务设计？=> DDD

  • 传统SOA架构基于“中心化”的ESB构建，而微服务采用的是系统提供服务的方式实现系统间的互通；

  • 传统SOA实施的方式是项目制，而微服务是以做产品的方式让服务在业务发展过程中快速演化；

  • 阿里巴巴2009年开始的共享服务体系算得上是微服务实践的先驱

  • 从本质上说，微服务是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别

  • 微服务与SOA的两点最鲜明差异在于：

    • 传统SOA架构基于“中心化”的ESB构建，而微服务采用的是系统提供服务的方式实现系统间的互通；

    • 传统SOA实施的方式是项目制，而微服务是以做产品的方式让服务在业务发展过程中快速演化；

  • 概念一时爽，问题一堆堆：

    • 微服务化的应用架构的有效服务管控？

    • 分布式事务的难题？

    • 自动化运维和平台稳定性？

    • 微服务的服务设计？=> DDD

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

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

• 服务中心的三个特征

  • 服务中心是伴随业务不断发展的：不做过于超前的设计，也不做过于理想化的架构

  • 服务中心的服务形态多样化：接口、工具、数据...

  • 一个服务中心还可以进一步划分：单个服务模块、多个服务模块...

• 服务中心的划分原则

  • 高内聚、低耦合原则

  • 数据完整性原则：特别强调大数据思维

  • 业务可运营性原则：服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元

  • 渐进性的建设原则：小步快跑，服务化从简单开始！

  • 设计 => 遵循面向对象的分析和设计方法论

  • 运营 => 服务中心应该是一个完整额业务模型

  • 工程 => 综合评估业务层对服务中心在DB、业务以及运营方面的需求和技术上需要的投入

  • 更多靠的是架构设计经验总结，很难给出精确的量化指标

  • 一般来说会兼顾3个方面的需求：

  • 实际中的一些基本原则：

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

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

• 数据库分库分表的实践

  • 阿里巴巴分布式数据层平台发展演变：Cobar(2006) => TDDL(2008) => DRDS(2014)，更多阿里中间件的简介可以转向这里：http://jm.taobao.org/about/

  • 数据尽可能平均拆分：需要结合业务数据的结构和业务场景来决定

  • 尽量减少事务边界：“事务边界”指单个SQL语句在后端数据库上同时执行的数量

  • 异构索引表尽量降低全表扫描频率：“拿空间换时间”，阿里巴巴的精卫填海产品

  • 将多条件频繁查询引入搜索引擎平台：采用专业搜索引擎平台提供搜索服务，Lucene、Solr、ElasticSearch

  • 简单就是美：“数据尽可能平均拆分”作为第一优先考虑，82法则

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