保护私人版权，尊重他人版权。转载请注明出处并附带页面链接
分布式服务架构这本书主要讲了其原理及设计、实践，主要有：
- 分布式微服务架构设计原理
- 彻底解决分布式系统一致性的问题
- 服务化系统容量评估和性能保障
- 大数据日志系统的构建
- 基于调用链的服务治理系统的设计和实现
- java服务线上应急和技术攻关—这个没有太多参考意义，不过部分理念还是一样的
- 服务的容器话过程
- 敏捷开发2.0的自动化工具
从单体架构到开源框架架构再到服务化结构，再到现在的微服务架构，从聚合到解耦。互联网时代业务复杂度及用户量都大大的提升，传统的单体结构，服务化架构在沟通成本，修改成本方面以及风险都有所提升，微服务结构就是在这样的环境下产生的，微服务架构按照业务功能进行划分，每个单一的业务做成公共服务，每个服务对应一个独立的职能团队，该职能团队包含了完成的人员组织架构，微服务的出现大大提高了开发效率，降低了模块间的耦合以及提高了各模块的 稳定性，因为微服务之间都是相互隔离的，只要大家遵守输入输出协议，单个服务出现问题只需解决单个服务的问题，查找问题的效率也得到大大提升。
同时，微服务的去中心化设计可以保证业务量上来后可进行快速扩容，降低扩容成本。基于微服务的容错模式，进行熔断、限流、隔离等，保证业务不会雪崩，也可以对出现问题的服务进行失效转移。
将单体应用拆分成网络服务，实现模块化组件，每个服务对应一个团队，去中心化，具备兼容性设计、容错性设计、服务契约设计，重视服务的合理拆分、分层和构造，可建设自动化持续发布平台。
微服务的粒度准则：按照业务功能进行拆分，每个服务的功能和职责单一，甚至不可再拆分为止，拆的越细越好内聚性越好越适合敏捷发布和上线；不要在本地事务中多用远程服务，这种情况会拖长事务，严重的情况会压垮数据库，我们要竭力避免这种情况，但是数据库应该也要有负载熔断机制。
微服务项目需要实现自动化的持续部署和持续集成，包括代码管理、自动编译、发布QA、自动化测试、性能测试、准生产环境部署和测试、生产环境发布等。
微服务之间可以使用rpc进行访问，比较好的rpc框架如thrift，thrift具有跨语言和高性能优点，在互联网企业里面受欢迎，跨语言服务平台建设的首选。
解决分布式系统一致性问题，我们可以了解一下“酸碱平衡理论”，学理科的同学应该对酸碱平衡比较熟悉啦~~那我们来看一下微服务中的酸碱平衡理论吧：
酸碱平衡中的“酸”也就是 ACID。
- A 原子性
- C 一致性
- I 隔离性
- D 持久性
而分布式系统的最大难点，就是各个节点的状态如何同步。CAP定理是这方面的基本定理，也是理解分布式系统的起点。CAP主要包括以下三点：
- C 一致性
- A 可用性
- P 分区容忍性
而酸碱平衡中的碱（BASE）也就是为了解决CAP提出的分布式系统的一致性和可用性不可兼得的问题：
- BA 基本可用
- S 软状态 状态可以在一段时间不同步
- E 最终一致性
前面也说到了酸碱平衡是为了解决CAP提出的分布式系统一致性和可用性不可兼得的问题，那么一般情况下如果使用向上拓展（加钱）能解决的话都不是问题，如果向上拓展性价比不高的情况下，那就只能进行业务分片、分机器处理了。
微服务的最终一致性：查询模式 补偿模式 异步模式继续完成未完成的操作。也都可以用定时校对保证最终一致性。
服务容量方面对于技术的要求，我们更多需要关注在“非功能质量需求”，也就是高性能、高可用、可伸缩、可拓展、安全性。我们需要对业务服务进行上线前的压力测试，压力测试方式主要有瞬间加压、逐渐加压、梯度加压；退出方式可以选择逐渐退出或者立即同时推出；同时我们可以找到最佳负载，对其进行24小时进行稳定测试。
分布式架构中大数据日志系统建设尤为重要，它可以为我们记录汇总业务中的一些输出信息，例如报错信息、复原调用过程等，我们可以使用vesta发号器进行发号，根据调用链唯一流水id traceID和标识调用和顺序的spanId和parentSpanId。但它也有致命的缺点：调用链有太多的节点和层次的时候，spanId会带有太多的冗余信息，导致服务间调用性能下降。
调用链是一个简单的树形结构，而业务链是一个森林结构。调用链跟踪系统通常由采集器 处理器和分布式存储系统组成，处理后会通过展示系统进行查询等操作。
线上问题处理原则及实时：
事故的发生都是量变的积累 再好的技术也要看人的自身素质和责任性
海恩法则：
每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆及1000起事故隐患
墨菲定律：
如果有两种或者两种以上的方式做某件事，而选择其中一种将导致灾难，则必定有人会做出这种选择。它强调 任何事没有表面的简单，所有事情发展都比预计长 会出错的事情总会出错，如果你担心某种情况发生，那它更有可能发生。
线上应急目标和方法，一般分为6个步骤：
- 发现问题
- 定位问题
- 解决问题
- 消除影响
- 回顾问题
- 避免措施：需要建立一个改进措施和避免措施的跟进方案和机制
收集发生问题的现象需要考虑5个W：
- when 什时候出现问题？
- where 哪里出现了问题？
- what 出现了什么问题？
- who 谁发现了问题，影响了谁？
- why 为什么出现问题？
剩下我们还可以去了解里面的服务容器化的过程 容器具有轻量级 可隔离性 可移植；敏捷开发 持续集成持续发布。
