《企业IT架构转型之道》读书笔记（部分2）

4 建设：分布式框架选择

2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，大小功能模块超过200个。

这带来了以下几个问题：

• 项目团队间协同成本高，业务响应越来越慢。
• 应用复杂度已超出人的认知。
• 错误难于隔离。
• 数据库连接能力很难扩展。
• 应用扩展成本高。

解决以上问题的根本在于业务的拆分。结果，在应用部署形态上，由之前一个几百兆字节大小的WAR包部署模式改造成为上百个WAR包独立部署的服务化架构。

好处：

• 降低不同模块开发团队间的协同成本，业务响应更加迅速。
• 大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注与各自的业务模块。
• 避免了个别模块的错误给整体带来影响。
• 业务拆分后解放了对单数据库集群连接数的能力依赖。每一个核心服务中心都拥有各自独立的数据库，缓解了之前的数据库连接瓶颈。
• 做到针对性的业务能力扩容，减少不必要的资源浪费。

技术选型：SOA ESB 架构还是分布式架构？

SOA 主要特征：

• 面向服务的分布式计算
• 服务间松散耦合
• 支持服务的组装
• 服务注册和自动发现
• 以服务契约方式定义服务交互方式

传统SOA ESB的服务调用方式的问题：

1. 每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。
2. 从逻辑上看，所有服务调用都通过服务总线，服务总线的访问和计算压力会非常大。
3. 企业所有的业务都通过服务总线方式，则服务调用量比较大，所需的网络带宽要求非常高，企业需要在网络上投入更大的成本。
4. 基于企业总线构建的服务体系，会成为企业服务调度的核心枢纽，这可能会导致『雪崩』效应，给整个平台带来灾难性后果。

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

主要组件：

• 服务提供者。为了保障服务高可用，一般都是集群部署。每个HSF应用均是以War包的形式存在，运行在Tomcat容器中。在Tomcat 容器层，已经集成了HSF服务框架对服务提供者或服务调用者进行配置服务器发现、服务注册、订阅、失败转移等功能。目前，淘宝内部大部分应用的部署方式，还是一个虚拟机运行一个tomcat容器，每个tomcat运行一个服务应用。
• 服务调用者。这是服务的消费者，大多数也是以WAR应用包的方式运行在 tomcat 容器中。
• 地址服务器。由 Nginix 实现。
• 配置服务器。负责记录所有服务发布和服务订阅信息，并将服务相关信息推送到服务节点上。
• Diamond 服务器。本质上也是一个通用的统一配置管理服务。

5 建设：共享服务中心建设原则

关于『服务中心』的概念：

• 服务中心一定是不断发展的。业务架构是能反应业务变化的，服务中心作为共享架构的核心元素一定也会提现出这种变化。
• 服务中心的服务形态的多样性。有人理解的服务中心是狭义的接口服务，这比较片面化，虽然接口是服务最重要的形式。服务中心提供的服务能力，可以分为三类：
  • 依赖于接口的服务
  • 依赖于工具的服务
  • 依赖于数据的服务

服务中心设计的一些原则：

• 高内聚、低耦合。
• 数据完整性原则。
• 业务可运营行原则。服务中心应该是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
• 渐进性的建设原则。服务化架构本来就是一种敏捷的实践，推荐小步快跑的方式逐步推进。

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

需求：

服务中心需要能很好地支撑将来任何业务场景的访问性能的要求，而数据库是最容易产生性能瓶颈的服务组件。

几个步骤：

淘宝的做法是基于数据库分库分表的方式，利用分布式数据库平台解决数据库瓶颈问题。

第一步：数据库的读写分离。拓展了数据库读读的处理能力，整体上也提高了数据库的读写能力，但这样的架构在主数据库上的写能力依然没法扩展。

第二步：当出现单个表的数据量很大的情况，则需要采用水平分区的方式对数据进行拆分，即将同一个表中的不同数据拆分到不同的数据库中。比如，对用户数据按照用户 ID 进行 has 取模的方式实现用户数据平均分到 8个数据库中，确保了单个数据库中保存的数据量在单机数据库能提供良好读写性能的范围内。

第三步：在2008年，阿里巴巴内部开始了分布式数据库的研发。

一些最佳实践：

• 开发了分布式数据层框架TDDL。针对分库分表场景，提供了对各种业务场景的支持更加完善，开发人员体验更加友好，管控能力大幅提升。
• 数据尽可能平均拆分。在分库分表场景下，最重要的一个原则就是被拆分的数据尽可能的平均拆分到后端的数据库中。如果拆分不平均，还会产生数据访问热点，这就同样存在热点数据因为增长过快而面临数据单表数据过大的问题。
• 尽量减少事务边界。
• 异构索引表尽量降低全表扫描概率。一个解决思路是『拿空间换时间』。
• 将多条件频繁查询引入搜索引擎平台。
• 简单就是美。

7 实现：使用异步化与缓存

1. 业务流程异步化

问题：淘宝的订单创建流程需要调用超过200个服务。如果是全线性调用，即使每个服务的响应时间都在20ms之内，那么全部流程也会超过4秒。这对客户来说难以接受。

解决之道：流程异步化。

总结：在分布式服务架构中，通过业务流程异步化，即通过服务异步调用的方式让业务流程中业务逻辑上允许同步执行的服务同时被调用，从而解决了大量远程服务线性调用带来的性能问题。

2 大促秒杀活动催生缓存技术的高度使用

需求：平台如何完美支持大促秒杀场景是一个体系工作，牵涉到应用架构设计的合理、平台稳定性报障、极强的系统扩展能力等多个方面。其中，利用缓存技术实现商品数据的高性能读取，以满足秒杀活动中对商品数据访问的同时不会出现商品超卖等严重的业务问题。下图是商品秒杀架构示意图：

示例：在小库存商品秒杀场景下的示例：

流程：

• 1.1：用户通过商品详情页查看商品时，获取的商品基本信息以及库存是从缓存Tair 中获取的。
• 2.1：当用户查看到当前商品还有可卖库存时，进入到 Buy 商品下单界面，此时商品的相关信息依然还是从缓存获取。
• 3.1： 用户在进行下单操作后，此时就通过数据库本机事务操作的方式，通过商品中心的服务（IC）获取到当前商品的真实库存信息。
• 3.2： 当此时获取的库存大于 0 时，则进行库存的扣减操作。
• 3.3： 通过该步骤更新了商品数据库中的库存信息
• 3.4： 在3.3 步骤的同时，也更新缓存中该商品的库存信息。此时，前方用户再访问该商品信息时，看到的就是已经更新了的信息。