读书笔记：《企业IT架构转型之道》
前言：有赞最近开始在做平台化的事情，作为共享技术部门的成员，那么自然去要去参与平台化。偶然间，从同事那看到这本书，随意翻了下，不禁感觉相遇恨晚。
第1章：阿里巴巴集团中台战略引发的思考
第2章：构建业务中台的基础-共享服务体系
第3章：分布式服务框架的选择
第4章：共享服务中心建设原则
第5章：数据拆分实现数据库能力线性扩展
第6章：异步化与缓存原则
第7章：打造数字化运营能力
第8章：打造平台稳定性能力
第9章：共享服务中心对内核对外的协作共享
第1章：阿里巴巴集团中台战略引发的思考
1、阿里巴巴共享事业部的发展史
阿里巴巴的电商平台由开始的淘宝，逐渐发展出天猫部门，一开始，淘宝和天猫部门由淘宝技术团队支持。后逐渐拆分出共享技术部负责公用的部分来支持淘宝、天猫的发展，淘宝和天猫则各自有单独的技术团队做符合各自特性的业务。
但是结果并不如预期，共享技术没有平等的话语权，并没有沉淀下真正的能力，在淘宝、天猫的各种变化的业务需求中艰难生存，而淘宝、天猫则认为共享技术不能很好的支撑，并各种搭建了类似的技术体系。这直接导致很多重复工作，最可怕的是这种重复工作还在不断发生。
后来，在聚划算发展的契机下，淘宝、天猫、1688非常想接入聚划算带来流量，而这时集团给了共享技术平等的话语权，但想接入聚划算必须经过共享技术，这也帮助其规范内部技术体系，为阿里日后的“大中台，小前台”战略做好了铺垫。
最后，共享技术发展成业务中台，成为孕育的土壤，为集团减少了大量重复工作，节约成本，逐步快速培育出了如闲鱼、玩兔等等新业务，并为阿里的数据打通（比如会员数据、交易数据）及日后的发展打下了基础。
2、企业信息中心发展的症结：“烟囱式”系统建设模式的弊端
- 重复功能建设和维护带来的重复投资
- 打通“烟囱式”系统间交互的集成和协作成本高昂
- 不利于业务的沉淀和持续发展
3、企业信息中心发展的症结：业务支持一直是企业信息中心的组织职能
- 行政级别的平等不代表着具有同样平等的部门话语权。IT部门的工作被定位为配合业务部门完成业务目标，是一个花钱的中心，造成管理层对IT部门的不重视。
- 传统的项目制外包开发方式，造成IT部门的成员在业务上并没有非常深入的积累沉淀，更多的是知其然而不知其所以然，没有培养出这样的人才，这对企业未来的发展是不利的。
第2章：构建业务中台的基础-共享服务体系
1、SOA的本质是服务重用。
2、服务需要不断的业务滋养。
只有不断的业务滋养，才能使服务真正成为可重用的组件，为业务的快速响应、支持业务快速创新带来业务价值。而不是采用传统的“烟囱式”系统方式以及“项目制”的建设方式。
这是一个长期、持续的过程，在业务发展过程汇总，逐步打造这些服务，这就要求新的业务必须接入这些已产生的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分，而不能因为这些“刚出生”的服务功能简单、服务消费体验糟糕、服务不稳定等原因而放弃使用这些服务。
3、共享服务体系是培育业务创新的土壤。
共享服务体系能够看到各个业务场景中的自身业务的“点”，能接收到来自不同业务模式下所有交易相关的需求。这有利于培养出特定领域的专家，这些专家能很大概率给企业待来创新能力。
4、赋予业务快速创新和试错能力
共享服务的能力复用，可以极大减少企业的新业务建设成本和时间。而小的成本也让企业更愿意去更多领域快速试错，尝试更多业务。而对于前台的业务部门来讲，减少了很多重复造轮子的情况，团队自然也会更小，这样的小的前台业务团队将具有几个特征：①团队协同效率最高；②对战机（商机）的把握更加敏锐。③调整方向更加快捷。④一旦发现正确目标，全力投入扩大战果。
5、为真正发挥大数据威力做好准备
- 数据分布集中在共享服务，格式相对统一、标准。
- 可以培育出基于数据有业务建模能力的专家。
第3章：分布式服务框架的选择
1、单个应用主要的问题
- 项目团队协同成本高，业务响应越来越慢。
- 应用复杂度已超出人的认知负载。
- 错误难于隔离。
- 数据库连接能力很难扩展。
- 应用扩展成本高。
2、应用拆分后的优点
- 降低不同模块开发团队间的协同成本，业务响应更迅捷。
- 大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块。
- 避免了个别模块的错误给整体带来的影响。
- 业务拆分后解放了对单数据库集群连接数的能力依赖。
- 做到针对性的业务能力扩容，减少不必要的资源浪费。
3、SOA的主要特性
- 面向服务的分布式计算
- 服务间松散耦合
- 支持服务的组装
- 以服务定义服务交互方式
4、“中心化”（ESB）与“去中心化”（dubbo、HSF0）服务框架的对比。P39
ESB产生的原因在于做早期分布式系统整合时，各个系统的语言、通信协议等均有很大的差别，这时，需要一个“中心化”的组件帮助解决这些问题，ESB孕育而生，帮助解决各个系统间的通信问题。
而对于统一标准或者刚开始建立分布式系统的企业来讲，“去中心化”服务框架则更适合未来的发展。在解耦、扩展、性能、容错等均展现出优势。
5、微服务是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别，它们都得解决几乎相同的问题。具体技术的选型应该和企业发展的阶段保持一致。
第4章：共享服务中心建设原则
1、共享服务中心的架构目的
- 通过业务拆分来降低系统的复杂性
- 通过服务共享来提供可重用性
- 通过服务化来达到业务支持的敏捷性
- 通过统一的数据架构来消除数据交换的屏障
1、服务中心的划分原则（P63）
架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效的解决主要问题，偏执的追求一个维度的完美肯定会在其他方面付出代价。
- 高内聚、低耦合原则。高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合，这里的业务隔离性是从应用场景来说的。
- 数据完整性原则。服务化一个很重要的业务价值就是数据模型统一，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。
- 业务可运营性原则。服务中心应该承载业务逻辑、沉淀业务数据、产生业务价值、孕育创新想法，形成闭环。
- 渐进性的建设原则。服务化应该从简单开始，小步快跑的方式逐步推进，只有真实的业务需求才会锻炼出稳定可靠的共享服务。
第5章：数据拆分实现数据库能力线性扩展
这一块讲的比较粗，其实大致的方案都了解，（读写？分库分表？分片？心跳检测？）具体的细节可以遇到问题时再深入
第6章：异步化与缓存原则
1、为什么要异步化？
传统ESB服务组合和编排的时候更多采用的是同步的方式，一直保持连接。然而，当所有逻辑都同步顺序执行时，其性能和扩展性都将受到限制。
2、异步化的思想
将大的业务操作，拆分到不同的处理和计算单元，通过异步调用来实现，无需一直保持长连接，占用资源。
- 采用消息中间件进行异步化处理。可以很好的支持发布订阅、消息重试、缓存、削锋等。
- 数据库事务本身进行异步化，将大事务拆成小事务、消息异步补偿等，需要考虑异步事务的回滚和重试机制。这种方式可以减少对数据库资源占用、表的锁定，提升平台的吞吐量和事务操作响应时间。
3、分布式理论
强一致性（CAP）==> 最终一致性（BASE）
4、分布式事务
两阶段、三阶段、柔性事务（TCC、消息补偿等保证最终一致性）
5、柔性事务事务
- 引入日志和补偿机制，对于正常操作提供幂等的反向操作以用于回滚。
- 可靠消息传输：远程模块用异步消息来驱动，出现异常的是可以使用消息中间件的重试机制进行重试（需要支持幂等）。
- 实现无锁：为获取高性能和高吞吐量选择放弃锁。P105页辅助业务变化表和乐观锁方案。
第7章：打造数字化运营能力
主要是讲的阿里“鹰眼”的设计与实现。设计上都是基于Googl Dapper论文的实现，由于之前已经看过调用链的原理，这里没有细化去看每个实现细节，需要时再看每个技术细节也不迟。技术实现上，主要是通过引入鹰眼中间件，进行应用埋点，在机器本地打印日志，中间件会异步将日志传入storm集群实时收集，将实时统计结果写入HBase，将全量日志写入HDFS，MapReduce会运用Hadoop的集群的能力进行离线计算，并最终写入HDFS，最终支持可视化的日志的搜索、监控报警、链路跟踪等。
第8章：打造平台稳定性能力
1、限流降级
这一块在其他书上以及平常自己接触过，所以看的比较快。淘宝的限流降级平台为Sentinel，开源可参考hystrix。
- 应用维度
- 服务（接口）流量维度
- 缓存维度
- 数据库维度
- 业务维度（单个店铺、单个店铺单个接口、单个接口场景）
2、可能造成单点或局部应用出现故障的原因：
- 机器超配（一台物理机上创建的虚拟机CPU核数的总和超过物理机实际的CPU核数）
- 超卖问题带来的资源争抢问题
- 部分应用、部分机器启动的时候，容易出现个别机器负载飙高，导致这部分机器响应时间变长
- JVM假死、VM假死等问题
- 受宿主机影响，负载飙高问题
- JVM垃圾回收影响请求响应时间的问题
- 网络抖动导致RT抖动
3、单机、局部服务能力出现问题，也会带来严重的影响
- 分布式服务环境调用链路局部问题会被放大到整个链路
- 单店、局部问题会被放大成面。
4、流量调度平台（根据机器的实时服务能力、是否可用等来分配机器的实时流量，进行降权、下线等操作）
核心是通过秒级获取服务器系统运行指标以及业务指标，通过流量调度平台设置的决策算法以及规则，当发现满足规则条件的指标状态发生时，对线上环境的服务器进行下线等操作，以屏蔽这些单点或局部出现故障的应用实例对整体平台产生的雪崩式营销。
P171
5、统一分布式配置平台（如apollo、diamond）
6、容量压测及评估规划（这个参考有赞内部的扩容及《亿级流量网站架构核心技术》更详细点）
7、全链路压测平台（可直接参考有赞的全链路压测细节）
- 基础数据抽取（采样、过滤和脱敏）
- 链路与模型改造
- 链路验证
- 业务改造
- 数据平台（数据准备、链路构造、模型构造）
- 流量平台（全链路压测操控中心、压测引擎）
- 影子表
- 中间件改造
- 安全机制（安全的监控和保护，建立非法流量的监控机制；对压测流量的安全过滤，针对压测流量放松安全策略）
8、BCP（实时业务审计平台）的主要目标
- 高实时性的发现业务脏数据或错误逻辑实现，第一时间发现并及时通知技术保障人员，而不是等客户反馈。
- 方便的接入各种业务规则，通过脚本规则编写的方式，让各应用快速接入业务审计平台。（基于Groovy？）
- 整合订正工具，形成规范的脏数据订正流程。
- 业务上线的实时监控，新上线业务可以很方便的进行校验。
9、BCP（实时业务审计平台）的执行流程
- 数据触发（基于事件监听模式，如DB变更消息、消息服务消息、日志消息）
- 事件构造
- 规则获取（规则工厂，通过类型分大类，如订单、逆向；通过数据状态分小类，如创建、付款）
- 规则运行（规则中心，运行过滤规则，检测采样率，执行规则）
- 结果存储（数据处理，记入数据库，并产生日志）
- 报警
10、BCP（实时业务审计平台）平台实现业务稳定的典型案例：双流对账方案
- 单一系统内的对账
- 单链路不同系统间的对账
- 不同业务链路间的对账
第9章：共享服务中心对内核对外的协作共享
1、服务化建设野蛮发展带来的问题
- 服务的数量和业务覆盖范围越来越大
- 应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
- 服务安全控制层缺乏
- 开发体验很不友好，产品接入流程复杂，开发使用手册建设非常之差
- 整体服务体系缺乏一个统一的服务治理层
2、业务中台与前端应用协作（这里的前端应用是指中台的上层具体业务方）
- 业务中台对前端核心业务的紧密沟通机制，比如定期互相参与会议、问题沟通群等
- 建立分歧升级机制（业务模块-->部门--->事业部）
- 岗位轮转推动换位思考
- 业务持续沉淀及共建模式（上层业务共性持续沉淀到中台，中台和上层的团队业务一起共建中台能力）
3、业务中台绩效考核
- 服务稳定是重中之重
- 业务创新推动业务发展
- 服务接入量是衡量服务价值的重要考核
- 客户满意度促动服务的提升
4、能力开发，构建生态。
第10章、第11章讲述了两个案例，虽然该章属于“阿里巴巴能力输出的案例”，但是更多的是中间件能力的输出及中台思想的输出，而不是阿里中台本身能力的输出。