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

上半部分Part1~Part5请点击这里

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 共享服务中心对内和对外的协作共享

• 共享服务平台的建设思路

  • API as Service => 服务化的第一步

  • Product as Service => 大量业务API升级为服务化平台的组件服务

  • Solution as Service => 经过长时间的沉淀可以形成解决方案，如海外淘宝解决方案

  • Step1.找到一个合适的服务化对象：比如API

  • Step2.建设对象服务化的基础设施：比如结构化包装，让API成为治理良好的组件服务

  • Step3.服务化实施阶段：循序渐进的过程，三个阶段参考

  • 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架构转型之道的思考》

---