《企业IT架构转型之道》读书笔记

《企业IT架构转型之道》读书笔记

前言

最近在拾起一些琐碎的知识点。故准备把以前看的相关书籍笔记整理一番。

《企业IT架构转型之道》 是2018/02/12在微信上读完的，距今有三年多了。

---

摘录

业务中台的基础-共享服务体系

SOA理念最核心的价值： 松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。

SOA架构的核心价值——服务重用。

领域专家形成：
随着我们掌握知识点的增多，我们开始有意识地将一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上是将这些相关的知识点串成了知识线；随着在领域知识的继续积累，越来越多知识线的汇聚，我们有机会更全面地了解到这一知识领域（知识面），从而构建了对这一领域自身的知识体系，而这时的你相信已经能称为这个领域的专家。

赋予业务快速创新和试错能力

如果企业打造了很好的业务中台，可以让3个人基于中台提供的核心服务在2周内就能建设一个系统并推向市场，看市场的反馈来决定是否加大对这个新业务的投入，我想任何一家企业的领导都是很乐意做这样的投入和尝试的。

阿里提出的“大中台、小前端”战略正是如此。

小前端团队特征：

• 团队协同效率最高。 科学证明，人数是7个人的团队协同效率是最高的。最短时间内达成意见的统一。

• 对战机（商机）的把握更加敏锐。 生存是小团队首先考虑的问题，这样的环境容易逼出团队成员的能量和潜能，这当前的战机（商机）的感知会更加敏锐。

• 调整方向更加快捷。 俗话说船大掉头难，大团队和小团队发现任务方向错误时，调整方向所花费的时间和资源一定远远超过小团队。所以以小团队的方式进行业务的试错，不管后续需要调整方向还是放弃该业务，其成本都是可控的。

• 一旦发现正确目标，全力投入扩大战果。

大数据项目实施落地问题：

• 数据分布广、格式不统一、不标准。 前期系统建设方式不统一，相关业务领域数据放在不同系统中，各自开发团队按照对业务的理解建设相关的数据模型，造成相关业务的数据模型和标准不统一。为数据层的抽取、清洗、转换带来不少复杂的工作。

• 缺少能基于数据有业务建模能力的专家。 基于对业务的理解提出对大数据平台需求的专家在企业中凤毛麟角，大数据平台的专家往往对于企业的业务又没有深入的了解。

以上两大原因导致大数据平台凸显不了其业务价值。

如果我们相关业务领域在业务和数据层做了很好的融合，系统运行时进行规整和沉淀，这样在大数据项目实施时为了获取完整的、有质量的业务数据所做的工作可以做到一定程度的避免和简化。

对于第二个问题，企业应该自我培养这样的专家。在自身技术功底扎实的同时，逐步提升业务上的能力。

共享服务体系搭建

共享服务体系作为业务中台的核心中枢。

共享服务中的每一个服务都将在企业的运营中扮演非常重要的角色。

这样对这些服务中心的服务稳定性、服务能力的扩展性、服务需求的快速响应能力提出了前所未有的更高要求。

淘宝平台“服务化”历程。

07年几百人维护一个WAR的模式，所带来的问题：

1. 项目团队间协同成本高，业务响应越来越慢。 几百个功能的模块，必然会按照由不同的团队所开发，系统升级前的合并会出现各种问题（jar包冲突、代码不一致等）。

2. 应用复杂度已超出人的认知负载。 系统功能多了，也复杂了，没有哪一个人能清楚每一个功能和业务流程的细节，造成不敢改动的风险。

3. 错误难以隔离。 核心和非核心代码运行在同一个jvm中，任何一个小的问题都会影响平台的正常运行。

4. 数据库连接能力很难扩展。 平台数据均保存在同一个数据库集群中，而数据库集群的数据库连接数量有上限。

5. 应用扩展成本高。 因为打包在一起，没法单独对某几个核心模块做服务能力的扩展。

14个月时间内将原来单一应用的模式改造成为基于SOA理念的分布式服务架构。

平台化改造：

1. 降低不同模块开发团队间的协同成本，业务响应更迅捷。 不同功能模块间进行清晰、稳定的服务契约的定义，负责不同功能的开发团队保证对外服务的接口不会发生变化。内部业务调整，不会影响到其它模块。

2. 大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块。 系统被拆分成几个服务中心的架构后，各个团队专注自己负责的业务模块即可。

3. 避免了个别模块的错误给整体带来的影响。 服务按照业务进行了拆分，各个服务中心之间独立部署。

4. 业务拆分后解放了对单数据库集群连接数的能力依赖。 平台被拆分为多个服务中心后，数据层也做了相应的拆分，每个核心服务拥有各自的数据库。

5. 做到针对性的业务能力扩容，减少不必要的资源浪费。 改造前一个war，改造后上百个war包。当某块业务能力需要扩容时，可以进行“粒度”更细的精准扩容。

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

SOA的实现

• 中心化框架： ESB（企业服务总线）。

• 去中心化框架：Dubbo，HSF

SOA的主要特性：

• 面向服务的分布式计算。

• 服务间松散耦合。

• 支持服务的组装。

• 服务注册和自动发现。

• 以服务契约方式定义服务交互方式。

ESB模式的“中心化”服务架构的根本诉求：
降低了系统耦合，更高效的集成。实现异构系统之间的交互。

“去中心化”分布式服务架构解决的问题：
“去中心化”分布式服务框架除了对于SOA特性的实现和满足外，相比“中心化”服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任务服务路由中介，避免因为“中心点”带来平台能力难以扩展问题，以及潜在的“雪崩”影响。

两种架构给业务带来的影响进行比较：

1. 服务调用方式的不同带来业务的响应和扩展。

2. “雪崩”效应束缚了“中心化”服务框架的扩展能力。 增加“中心”点企业服务总线实例的节点数量，并不能线性扩展平台的服务能力。

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

HSF服务框架主要组件：

• 服务提供者。

• 服务调用者。

• 地址服务器。 提供配置服务器和Diamond服务器列表信息。

• 配置服务器。 记录服务提供者和调用者ip和端口信息。采用长连接，用于服务发布、订阅、推送。

• Diamond服务器。 配置管理服务（安全管控规则、服务路由权重、服务QPS阀值等）。

HSF框架服务能力：

1. HSF框架采用Netty+Hession数据序列化协议实现服务交互。 采用多路复用的TCP长连接方式，两个服务之间多个请求时会共用同一个长连接。

2. HSF框架的容错机制。 调用失败重试其它服务，秒级感知服务故障。

3. HSF框架的线性扩展支持。 新增服务实例可在几秒类处理请求。分担其它节点压力。

关于微服务

微服务架构特征：

• 分布式服务组成的系统。

• 按照业务而不是技术来划分组织。

• 做有生命的产品而不是项目。

• 智能化服务端点与傻瓜式服务编排。 强调了能力向服务端的迁移，而不是传统ESB的方式，将整体服务架构核心能力都运行在ESB上。

• 自动化运维。

• 系统容错。

• 服务快速演化。

从本质上来说，“微服务”是SOA的一种演变后的形态。

共享服务中心建设原则

共享服务中心是中台架构的基石，如何构建稳定可靠、最高效地支撑上层业务快速创建的共享服务能力是中台战略成功落地的关键。

服务能力包括两个层次：

• 底层PaaS的能力：PaaS层解决大型架构在分布式、可靠性、可用性、容错、监控以及运维层面上的通用需求。

• 业务能力：业务服务能力提供云化的核心业务支撑能力，这层能力建设的好与坏，直接决定了是否能真正支持上层业务达到敏捷、稳定、高效。

服务于业务的边界：服务中心一定是实现通用的能力，个性化尽量在业务层实现。

服务中心提供的能力大概为三类：

1. 依赖于接口的服务：上层应用提供编程接口，接口可以是RPC，也可以基于Web API。

2. 依赖于工具的服务：提供定制的配置服务、运营管理类的工具。

3. 依赖于数据的服务：主要指对大数据的分析能力，实时交易型数据能力通过接口服务对外暴露。

共享服务中心架构目的：是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。

实际项目总结的基本原则：

1. 高内聚、低耦合原则。

2. 数据完整性原则。 服务化架构一个很重要的业务价值就是数据模型统一。

3. 业务可运营性原则。

4. 渐进性的建设原则。 服务化从简单开始，避免开始规划设计时拆分的过细，数据过于分散的问题。

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

比如按照订单id分库分表，如果用户维度来查询时，会出现全表扫描。针对此类场景方案：采用“异构索引表”的方式解决，即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。拿空间换时间。

异构索引表和按全量数据复制一份的区别是：

• 异构索引表存储的是买家id和订单id对应的关系。存储空间小。

• 全量复制会带来大量的数据冗余，增加数据库存储成本。

异步化与缓存原则

数据库事务与柔性事务

CAP理论：

• 一致性：指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

• 可用性：指用户在访问数据时可以得到及时的响应。可用性的要求包含时效性。

• 分区容错性：指分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性和可用性的服务。分布不是简单的理解为物理存储节点的分布，而且是节点间网络通信中断或报文丢失等。

BASE理论：

• 基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

• 柔性状态：指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

• 最终一致性：指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用合适的方式达到最终一致性。

柔性事务如何解决分布式事物问题

1. 引入日志和补偿机制。

2. 可靠消息传递。

实现事务隔离：

1. 避免事务进入回滚。

2. 辅助业务变化明细表。

3. 乐观锁。

事务自动回滚机制： 当资源管理器捕捉到sql的请求后，会对sql语句进行sql解析，如果是执行insert/delete/update的sql操作，则会针对该sql语句构造出对应的sql查询语句，将当前sql请求要修改的数据先从数据库中获取，以undo日志的方式保存起来，用于将来回滚。

如果当前数据库中的数据与redo日志中的值不一致，则说明是该分布式事物在第一阶段修改了数据后，又被其它线程（可能是通过非TXC事务控制的数据访问渠道）修改了该数据，这样就不能再继续进行数据的自动回滚，否则会出现业务不一致的情况，回滚会抛出异常，由TXC Server发出告警，引入人工干预。

缓存技术高度使用

秒杀缓存

通过服务分组方式，保持秒杀服务和普通服务运行环境的隔离。 将商品的详细信息（包括库存信息）保存在缓存服务器上，商品详情页和购买页相关的商品信息均从缓存服务器获取。

可通过给网页资源设置Expires和Last-Modified返回头信息进行有效控制，从而减少对后端服务的访问次数。

乐观锁避免超卖，核心是不允许同一商品的库存记录在同一时间被不同的两个数据库事务修改。

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

服务化建设野蛮发展带来的问题：

1. 服务的数量和业务覆盖范围越来越大。

2. 应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高。

3. 服务安全控制层缺乏。（服务升级和变更时，与依赖方沟通花大量时间；服务被未授权的业务方调用；随意发布服务）。

4. 开发体验很不友好，产品在接入流程，开发使用手册建设非常之差。

5. 整体服务体系缺乏一个统一的服务治理层。

服务和服务化区别：

• 服务是指服务端暴露出来的一种服务接口，与服务消费者相对应，其代表了服务端一个具体的能力。

• 服务化更像是一个商业策略，核心是从产品能力转化直接服务客户的能力。