读完本书，摘抄一些新概念，新思想并结合自己的认知，谈谈感触点。

“烟囱式”系统建设模式，2008年前的阿里巴巴三大系统（淘宝，天猫，1688）就是“烟囱”式系统。“烟囱”式系统又是如何而来的呢？大概是如下的流程：当业务部门提出业务需求后，信息中心部门对接业务需求并组织人力进行需求分析，开发，测试并最终上线产品，完成业务部门的需求。从某种程度上来说每个新系统的上线都是一座新的烟囱。这样的烟囱式系统至少有三个弊端：1.重复功能建设和维护带来的重复投资， 因为是烟囱式系统，每个系统都是相互独立的，与其他系统是不相联系的。这样功能肯定会重复建设且重复投入。2.随着企业的发展，整合内部资源，提升用户体验，实现各个系统的互联成为企业发展必不可少的事情。而打通“烟囱式”系统间交互的集成和协作成本确实是高昂的。3.不利于业务的沉淀和持续发展。采用“烟囱式”方式建设的系统体系，企业中业务领域的数据和业务就被打散在不同的系统中，采用ESB方式解决了眼前相关业务间的交互问题，但是随着业务的发展，终究无法满足业务快速响应和业务模式创新的需求。过去的很多企业都是如此：一个系统上线几年后，为了满足现状业务的新需求，都是向主管领导建议整体升级，用直白一点的话说：“这个系统太复杂了，没有资料，没有文档。甚至系统架构有致命错误（到底是不是致命错误，只是他的主观臆断，其他人无法判断），在它基础上维护，还不如重新做”，还有一点接触的是：很多人都是不愿意维护旧系统，都愿意重新做一套。推倒式重建且不说重复投入和将来建好的系统怎么样。单单是说从旧系统中继承下来的又有多少。几年发展下来，业务沉淀又有多少？

关于弊端3的本质问题就是所提供的业务服务没有随业务发展一起发展。当一个业务服务上线后进入维护阶段，对业务需求响应就没有那么积极了。接受需求处于暂停阶段。即使有更新也是半年或一年一次。想想这又如何能跟上快速变化的业务需求呢。当积累的业务需求从量变到质变时，远远落后的IT服务又怎么不推倒式重建呢？

一个错误的观点：IT信息部门一直处于其他业务部门的“业务支持“位置，即只是为了满足业务部门需求而进行IT系统建设的实施和运维部门。一直是配合协助的一方。从高层领导看来，IT部门就是一个只会花钱，不能赚钱的地方。其实正确观点应该是：IT部门从来不是一个协助配合的部门，和其他业务部门一样，拥有同等的地位。在完成业务部门的配合协助后，尽量地走出去独立赚钱。

ESB系统（企业服务总线）：采用服务的形态，以技术的视角选择了一个科学地架构实现了系统互联。很好地实现来多个独立系统间的打通，屏蔽了服务接口变化给服务消费者带来的影响。

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

服务需要业务不断地进行滋养：服务最不需要”业务稳定“，而是需要不断的滋养，只有在滋养中才能从最初仅提供单一业务功能的服务成长为企业最宝贵的IT资产。这就要求企业多一些耐心，在接下来的业务发展过程中逐步打魔这些服务，这就要求新的业务必须接入这些已经产生的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分，不能因为这些”刚出生“地服务功能简单，服务体验糟糕而放弃使用。

专家的形成：我们从开始就学习很多基础知识，掌握知识点，随着我们掌握的知识点的增多，我们开始有意识地把一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上将这些相关地知识点串联成知识线。随着知识领域的越积累越多，越来越多多线汇聚，这样我们就能更全面的了解这个知识领域（知识面），从而构建了对这一领域自身的知识体系。这就是所谓的专家。

第三章：分布式服务框架的选择

中心化：ESB就是典型的中心化思想，其流程：服务调用者-》ESB（接收服务请求）——》服务提供者（服务处理）——》ESB（服务提供返回结果）——》服务调用者（服务返回）。从结果来看：经过ESB路由过的服务交互，共出现4次网络会话创建和数据传输

去中心化：服务调用者——》服务提供者。从结果来看，只出现2次数据传输。

”雪崩“效应束缚了”中心化“服务框架等扩展能力。”雪崩“效应： 假设服务器上部署了9台服务器，单其中一台服务器出现问题（挂掉了），那么这台服务器提供的服务路由职能就分摊到剩下的8台上，这样加重了8台服务器的负载能力，还有负载不完全均匀，可能某一台又超高负荷又挂掉了。这样网络的服务路由职能又分摊给剩下的7台服务器。这些类推下去，导致后面服务器越来越超高负荷而挂掉。以至于一台机器挂掉导致所有机器都挂掉。在恢复”雪崩“效应的机器也是个麻烦事情，恢复第一台而其他还没有恢复好时，第一台服务器因服务路由超高负载又会挂掉。此时的解决方法是：暂停网路接入，等9台机器都启动好后再接入网络。

去中心化实例：分布式服务框架 HSF（Hight Speed Framework）又名”好舒服“ 还有一个开源项目Dubbo

1.服务调用者

2.服务提供者

3.地址服务器

4.配置服务器

微服务：本质上说，“微服务”是SOA的一种演变，与SOA的方法和原则没有本质的区别，但是还有一些区别

1.分布式服务组成的系统，意味着各个系统都是有多个分布式服务构成，这区别于SOA架构中基于“中心化”企业服务总线（ESB）方式，后者更多的是采用系统提供服务的方式实现系统间的打通和交互。

2.按照业务而不是技术来划分组织以及做有生命的产品而不是做项目。传统的SOA实施的方式是以项目为主的，一个项目完成，基本上就不维护了。

3.智能化服务端点和傻瓜式服务编排：更多的是将能力向服务器迁移，而ESB则将核心能力运行在ESB上。

4.自动化运维和系统容错：这个从高可用性和稳定性有更高的要求。

第4章：共享服务中心建设原则：

共享服务中心的能力包括两个方面：

1.底层的PaaS。这一层妖解决大型架构在分布式，可靠性，可用性，容错，监控，运维方面的通用需求

2.业务能力。提供云化的核心业务支撑能力，直接关系到上层的敏捷，稳定和高效

4大建设原则：

1.高内聚，低耦合。在服务中心内部的业务相关性要很高，依赖程度也高。而服务间应该隔离比较大

2.数据完整性

3.业务可运营

4.渐进性建设

第5章：数据拆分实现数据库能力线性扩展：TDDL（分布式数据层架）“头都大了”

1.数据库分库分表（平均分布在分布式数据库），需要解决多库的联合查询等问题

SQL和参数-》SQL解析-》规则计算-》表名替换-》选择GroupDS执行SQL-》根据权重选择AtomDS-》重试策略在AtomDS执行SQL-》读写数控制，线程并发数-》执行SQL，返回结构集-》合并处理结果集——》更新结果。

第6章 异步化与缓存原则

通过服务异步调用的方式让业务流程中业务逻辑上允许同步执行的服务同时被调用，解决了大量远程服务线性调用带来的性能问题。

以淘宝下订单为例：一次正常的订单创建按流程是要同步调用200个服务接口，完成这200个服务也要花费4s的时间。通过服务异步调用，也执行了200个服务接口，但是花费的时间微300毫秒

数据库事务：其核心就是体现在数据库单ACID（原子性，一致性，隔离性，持久性）属性。简单来说就是一个事务的所有业务逻辑要么全部成功，要么全部失败。

CAP理论：一个分布式系统最多只能同时满足一致性（Comnsistency）,可用性（Availibility），分区容错性（Partition tolerance）这三项中的两项

一致性：指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。简单来说，在分布式系统中，对于调用者来说，读操作和写操作都必须时单个即时完成的操作。不会感知到其他调用者访问和不同步问题。

可用性：指用户在访问数据时客户得到及时的响应。简单来说，无论操作冲突，还是软硬件问题都有数据返回给用户。让用户感觉到系统是可用的。当然包括数据的实效性和非脏数据。没有用户希望看到过期的响应或脏的无效数据。

分区容错性：指在分布式系统中，当某个节点或网络分区出现故障，系统任然能对外提供服务。简单的说就是：单个节点或网络分区出现故障，有其他节点或网络分区能顶替故障点，使系统继续使用。

BASE理论：基本可用（Basically Availiable），柔性状态(Soft State)，最终一致性(Eventual Consisitency)

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

柔性状态：指系统允许出现中间状态，该状态不影响系统整体的可用性。例如：数据库存在三个副本，允许不同节点间副本同步的延时。

最终一致性：指系统经过一段时间后，最终能够达到一致的状态。

BASE和ACID是两种截然不同的设计哲学，前者可以通过牺牲强一致性来获取高可用性，后者就是数据库常用的设计理念，追求强一致性模型。但是在现在的互联网时代，特别分布式系统中特别强调高可用。在现在的分布式结构中必然会有某一节点故障不可用，网络差而丢消息等因素。但是最终都是数据一致性的。

在传统的事务中，当事务的并发量达到一定数量的时候，就会出现大量事务挤压甚至出现死锁，系统性能和处理能力大幅度下降，甚至不可使用。所有现在互联网都采用柔性事务来解决。

那柔性事务又如何解决分布式事务问题呢？

1.引入日志和补偿机制，数据库记录所有日志，当操作失败时，柔性事务通过日志记录找回事务的当前执行状态，根据状态决定重试异常步骤（正向补偿或反向补偿）

2.可靠消息传递：对于消息的投递成功，失败或者不知道成功，失败 三种情况，做好相应策略。

3.实现无锁。数据库的锁的机制严重影响性能或吞吐率，使用无锁机制提高性能，但是无锁机制需要注意数据的完整性。

目前阿里巴巴在柔性事务的几种实现：

1.消息的分布式事务。主要是MQ消息通讯机制。通过消息机制来实现数据库锁的功能。

2.支付宝XTS 框架。基于BASE的思想实现的，具体为TCC（Try／Confirm／Cancel）型事务，属于典型的补偿型事务。

3.阿里巴巴的TXC 事务。主要是两阶段提交方案。

大促销秒杀和小库存商品秒杀 都使用了缓存技术。本质来说这部分数据预先存入缓存中，当然也是独立的数据库。即这大促销商品和其他非促销商品是不同的服务器。这样隔离的好处之一就是：大促销服务器出现问题不会影响正常商品服务器，还可以针对大促销服务器作定制，例如预先把商品加入缓存中。

第7章 打造数字化运营能力。

如果说前面的5，6章通过不同的技术或架构做好一个产品的话，那第7章就是通过其他方案更好的维护好产品。

又从微服务的过程阶段来说，这一章就是服务的监控和跟踪。

首先提出的“鹰眼”系统，就是通过一套分布式日志平台实现对服务调用链路的跟踪。

对于跟踪系统来说就是4步骤：

日志的采集：通过统一的埋点管理，获取所有的日志。

日志的传输：这里用到了TraceID，实现了服务链路全链路串联起来，通过JStrom流式计算引擎，对应用集群的日志进行解析拆分

日志的处理：通过海量日志分布式处理平台TLog来处理。

日志的展示：服务的实时监控，服务的调用链跟踪，服务调用链分析，业务的全息排查。

第8章打造平台稳定性能力

要保证阿里巴巴的系统常年稳定运行，还需要做一些措施。如下：

1.限流：限制用户的访问数。首先要准确评估出系统最大承载量。访问量超过了最大承载量，增加系统负荷，影响系统稳定性，少了就资源没有合理利用。浪费资源，

2. 降级：减少非核心功能的访问，淘宝的具体措施：在Nginx上扩展了一个组件（TMD）（taobao MIssible Definese） 淘宝导弹防御系统，其实主要模块就是nginx-http-sysguard，之后又发展为Sentinel系统，即“哨兵”，该系统实现了授权，限流，降级和监控 四大功能。

3.流量调度：合理的调整服务器的访问流程，让低流量的机器也分配到一定额度的流量，减少高流程机器的承载。

4.业务开关：调整代码中static 值的修改2.，从而实现限流，降级或则兼容不同的版本。阿里巴巴通过一个Switch平台实现了业务开关的统一管理和配置。

5.容量压测和评估规划。其实容量压测就是在线上对系统进行全链路压测。这样具有实用性，准确性和高效性。能更好的发现实际的问题。一般都是获取单机大QPS处理值。但是需要解决两大问题：

1.模拟大量的数据。

2.测试数据真实数据的隔离。

6.业务一致性平台。进入服务化时代，系统偶尔会出现调用失败，数据库访问失败。MQ消息发送失败。这些问题不能等用户保障才处理。需要系统实时监测到业务的不一致问题并及时转交给相关技术人员处理。淘宝就开发了一套实时业务审计平台（BCP）采用规范与标准化业务规则的方式，统一解决平台服务化的业务不一致性问题。

第9章共享服务中心对内对外的协作共享

其实这一章就是描述服务如何治理的问题。

随着服务的发展，带来了一下的一些问题：

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

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

3.服务安全控制层缺乏。

4.开发体验不友好，产品的接入流程越来越复杂

5.缺乏统一的服务治理层。

针对以上问题，阿里提出了共享服务平台的概念。

首先要明白服务与服务化的概念

1.服务，即是服务端暴露出来的一种服务接口，与服务消费者对应。代表了一种具体的能力。在SOA架构中就是组件化服务。

2.服务化，从产品能力转化服务客户的能力。以抽象API的形式对外提供服务能力。

从服务到服务化一般是以下4个步骤

1.找到一个合适的服务化对象

2.建设对象服务化的基础服务

3.事务化实施阶段

4.增强服务和基础设施实现服务的精细治理。

最后介绍下何所谓产品的“生态”和“上下游”。前者是所有体系中的人员都是主动参与者，都持续地往整个体系中注入自己的智慧和创造力；后者是整个体系中所有的参与者都是被动的使用者。