1. 阿里巴巴集团中台战略引发的思考 && 构建业务中台的基础-共享服务体系
所谓中台，居于前台和后台之间，我的理解是位于基础架构和各产品线间的业务架构，而业务中台，最为重要的就是上图里的共享业务事业部。
在最初的时候，淘宝与天猫是并驾齐驱的两大事业部，电商系统完全独立，包含了商品、交易、评价、支付、物流等功能。由于天猫事业部是后成立的，因此需求由淘宝技术团队支持。对淘宝的技术团队而言，自然地，“屁股决定脑袋”，淘宝业务需求的优先级，远远高于天猫，使得天猫业务很难开展。
于是，2009年，这部分淘宝技术团队划分开来，单独成为一个与淘宝、天猫同样级别的共享业务事业部，同时支持淘宝与天猫的业务。集团原有的目的自然是希望交集的技术能够在这里统一提供、支持、梳理和沉淀，然而事与愿违，共享业务事业部在两大业务部门需求下，不断被压缩，很多需求业务方自己就实现了。导致的结果是这样的：
这个现状非常难解，业务部门对共享事业部不满意，共享事业部则是有苦说不出。
而这种“烟囱式系统”的种种弊端：
- 重复功能建设和维护带来的重复投资
- 打通“烟囱式”系统间交互的继承和协作成本高昂
- 不利于业务的沉淀
其中对于互联网公司而言，3是急需要积累的，因为机会稍纵即逝，对需求能够快速响应，如果大部分工作都只是复制粘贴，推到重来，永远无法培养出有机会看的更远的人才和系统。
转折在2010年出现，彼时聚划算平台上线，由于能带来至少25倍的销售额，淘宝、天猫纷纷要求接入。阿里决策层强势要求，所有对接必须通过共享业务事业部，使得共享业务部有了一个极强的业务抓手，从而一步步奠定了最开始那张图的样子。
如今，淘宝、天猫、聚划算、去啊都不是独立的构建在阿里云之上，用户中心、商品中心、交易中心、评价中心等通用业务都沉淀到了这个事业部，统一接入、维护，全面的需求梳理、抽象。光一个用户中心里的账号系统统一，就值得我们反思很多。
亚马逊有个著名的披萨团队理论，这本书里也提到了7人团队协同效率是最高的。依靠完善的业务中台，可以让一个小团队基于中台的核心服务在两周的时间内建设一个系统并推向市场。这对于需要小步快跑，不断试错的互联网，是一个极大的优势。商场如战场，书中引用了美军作战阵型的演变的例子，因为有强大的中后台能力，能够支持几个人的小团队快速做判断，并且引领整个进攻完成：
2. 分布式服务框架的选择
共享服务中心并不是凭空搭建起来的，而是从淘宝平台逐渐抽离出来的，这个难度可想而知，称为“给飞行中的飞机换发动机”并不过分，需要极强的技术和理论基础。
当时的淘宝平台主要面临几个问题：
- 项目团队间协同成本高，业务响应越来越慢
- 应用复杂度已经超出人的认知负载
- 错误难于隔离
- 数据库连接能力很难扩展
- 应用扩展成本高
首先改造完成的是用户中心，接着“千岛湖”项目改造了交易中心、类目中心，“五彩石”项目将商品中心、店铺中心等核心业务功能做了抽离和改造，改造后：
- 降低不同模块开发团队间的协作成本，业务响应更迅捷
- 大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块
- 避免了个别模块的错误给整体带来的影响
- 业务拆分后解放了对单数据库集群链接数的能力依赖
- 做到针对性的业务能力扩容，减少不必要的资源浪费
使用的分布式服务框架是HSF(High Speed Framework)，有人戏称“好舒服”，包含以下组件：
- 服务提供者
- 服务调用者
- 地址服务器
- 配置服务器
- Diamond服务器
3. 共享服务中心建设原则
中台作为前台后台的枢纽，边界定义非常重要。服务中心也在不断变化：
可以看到是随着业务变化的一个过程。
书中提出了几个原则：
- 高内聚、低耦合原则
- 数据完整性原则
- 业务可运行性原则
- 渐进性的建设原则
4. 数据拆分实现数据库能力线性扩展
这一章主要是讲如何利用好存储
2006年，阿里B2B团队研发了Cobar这一关系型数据的分布式处理系统。
2008年，研发了分布式数据层框架TDDL(Taobao Distributed Data Layer，外号:头都大了)
2014年，研发出新一代分布式数据库产品DRDS(Distributed Relational Database Service)
每一次升级都是在易用性、性能、运维成本等上的升级和优化。
在存储的使用上，我们经常陷入两难的设计，例如增加索引会带来写入变慢，但是查询速度变快，真实的世界里，这条原则非常实用：
简单就是美
5. 异步化与缓存原则
毫无疑问，异步化与缓存两个技术都与系统性能有很大的关系，主要在两个方向上：
- 业务流程异步化
- 数据库事务异步化
业务流程异步化更多是一个梳理的过程，串联改串并联，例如这么一个转变:
数据库事务异步化相对复杂一些，牵扯到CAP/BASE理论，而架构上要做到高可用。
高可用 = 系统构建在多机 = 分布式系统
高性能 = 分布式系统的副产品
阿里有三套成熟的分布式事务解决方案：
- 消息分布式事务
- 支付宝XTS框架
- 阿里巴巴AliWare TXC事务服务
由于没有相关经验，这块几乎完全没有看懂😅，就不多介绍了。
不过应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时，这个看来是一个共识。
关于缓存，阿里内部有Tair，开源有Redis/Memcache等，在阿里特有的秒杀场景下，缓存发挥了极大作用。当然，秒杀这个活动，其实是产品设计、架构设计、平台稳定性、系统扩展能力的统一考验。对于小库存商品以及大库存商品，订单处理流程是不同的：
6. 打造数字化运营能力
面对每天几千亿次调用，架构设计需要提前考虑几点：
- 服务调用出现报错时如何快速定位问题？
- 实时监控到服务运行状态是否正常
- 给运营团队关注的业务指标实时呈现，以支持他们进行实时的精准营销
这是一个首先搭建高性能的分布式日志引擎，再到数字化运营能力的过程。
这个有多复杂？看下淘宝平台的服务调用关系图：
阿里使用鹰眼平台解决分布式服务调用链跟踪的问题，类似的还有例如Twitter的Zipkin，都起源于Google的Dapper论文。
鹰眼平台架构：
其中有两个唯一ID：
- TraceID: IP、创建时间、顺序数等
- RPCID：服务调用的嵌套关系
注意在较为简单/固定的架构设计下，我们一般都会忽略RPCID的设计。
这里提到一个代码侵入的观点让我感触比较大，埋点日志的信息并不是应用程序自己打印的，而是服务框架层或者各资源的访问驱动层打印的。因此几乎不需要应用升级。
毫无疑问，这需要有一个统一的底层框架，也就是我们前面提到的HSF服务框架，或者中间件平台例如分布式数据库、消息服务、缓存服务等，都在集团层面进行了很好的统一标准化。所以有时候，架构真的是一个需要长久积淀的工作，同时需要一个强悍的CTO来推动很多统一。
日志收集后，通过海量日志分布式处理平台TLog完成处理。
业务场景还是比较多的：
- 服务实时监控
- 服务调用链跟踪
- 服务调用链分析
- 业务全息排查
- 业务实时监控
7. 打造平台稳定性能力
常有人戏称好好一个项目，为了职称评审，总分成这么几项用于：
- 上功能
- 稳定性
- 省资源
- 平台化
其实我反而觉得很正常，每个阶段都有看中的点，对于架构能力各有不同方向的提高。
而稳定性，则总是让人觉得最难挑战的一个方向，不是因为难度，而是因为复杂、零碎、不受重视。
过去10多年的时间里，阿里投入了集团大量的精英人才用于提升淘宝、天猫平台服务的稳定性。能抗住双11这样称为现象级的电商大促活动，可以作为一个佐证的例子。
稳定性范围很广，机房布线、网络通信、硬件部署、应用架构、数据容灾等都与之关联，书里主要介绍了几点：
- 限流和降级：通过在Nginx上实现扩展组件TMD(Taobao Missile Defense，淘宝导弹防御系统)实现接入限流
- 流量调度：通过监控发现某些服务提供者出现服务响应慢或者系统资源负载飙高时，降低该服务器的路由权重
- 业务开关：Switch平台用于统一标准和规范的业务开关
- 容量压测及评估规划：解决测试结果可能不准确的问题，将线上环境直接引流到压测服务器
- 全链路压测平台
- 业务一致性平台
8. 共享服务中心对内和对外的协作共享
共享服务中心的服务数量野蛮生长下，也带来一些问题：
- 服务的数量和业务覆盖范围越来越大
- 应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
- 服务安全控制层缺乏
- 开发体验很不友好，产品在接入流程，开发使用手册假设非常之差
- 整体服务体系缺乏一个统一的服务治理层
共享服务平台(Shared Platform as Service, SPAS)目的对共享服务中心的服务能力在线化、数据化，是一个协作的平台，有三个角色参与其中：服务共享品台、服务提供者、服务消费者
而从人的角度，紧密沟通、分歧升级、轮岗、建立绩效考核指标等，防止中心惰性化，以推动共享服务中心的发展。
9. 思考
书里有很多值得架构学习的图片，都可以下载到。为了避免页面打开过慢，这篇笔记里没有罗列太多。
阿里的中台战略是15年启动的，现在也经常能看到对应的一些技术输出的文章，通过这本书也能提前了解一些背景，因此非常推荐一读。