第一章 微服务架构

1.不微你就OUT了（类比方式初次介绍微服务）

类比金刚葫芦娃、活字印刷术。

2.产生背景

传统架构面对的问题：持续增长的业务需求、日益激烈的竞争、瞬息万变的市场，更高要求、更快交付、更多挑战的市场，敏捷、精益的目标。
时代的召唤（当代特点——快）：当代凡事都“快”，需求增长快，变化快，紧跟市场的变化，同样快速做出反应，才能在竞争激烈下超过对手。
容器神助攻：容器技术是解决微服务生态的最后一课拼图。即容器技术是微服务这个概念，最终落实成解决方案的重要部分。
微服务的进击（微服务架构的由来）：好的架构不是设计出来的，是进化出来的。微服务架构是在传统架构的基础上进化而来，按照业务能力将系统拆分成多个服务，每个服务都是一个独立的应用，对外提供一系列的公共服务API，服务之间以轻量的方式互相调用。

3.微服务的标签

单一职责：类比海贼王每个成员，各司其职。拆分的每个微服务也应对应着唯一的业务能力，做到单一职责。
微：微是相对于传统应用而言的。服务微，如传统大型ERP系统，用户服务可称为独立的应用，业务单一，体量小，每个服务在细化到API级别。人员微，每个团队人员少，代码量、功能数、业务复杂度，给人小项目的既视感（亚马逊，两个披萨原则。指与会人数不能多到两个披萨饼还不够他们吃的地步）
面向服务：微服务面向服务的重要特性。每个服务都对外部提供服务，消费者使用服务。面向服务解除了与平台或语言的绑定，做到了平台语言无关性，不限定于某种技术，真正的开放。消费方，使用服务时无任何代码级别的渗透，无任何配置，只需要HTTP
请求调用。
自治：
1.团队独立。一个团队负责一个或多个服务，人数限制在10人以内。
2.技术选型灵活。自由选择技术栈不干扰其他服务，重新技术选型重做代价小。
3.前后端分离。后台提供REST服务，前端以HTTP请求获取服务。
4.数据库分离。每个微服务使用自己的数据源，更好数据库也只需要考虑自己的服务项目。
5.部署独立。一个微服务的部署不影响其他服务，有利于持续集成和持续交付。不需要像传统应用那样，修改后需要重新打包、频繁部署，影响系统的可用性。
6.容错。故障隔离，单个服务出错不会影响到整个应用。通过断路器进行容错和降级，保证系统稳定性。
易扩展：传统应用，通过全量复制部署到集群服务器的多个节点上。扩展时，只能通过整体做集群式的方式增强，无法针对特定服务扩展，造成资源浪费。微服务可以实现局部强化。
流程化：流程化是一套关于用户行为准则的规范（定义含糊）。好处有 ：微服务通过流程化将业务难度分解到各个微服务中，降低每个服务的业务难度；减少犯错的机会；能不断改进优化；方便开发、理解和维护。
不能过于迷信流程化的力量，把走流程当成了工作本身（管理的工作任务就是走流程），导致效率低下、机构臃肿、官僚作风（微服务的人员组织架构确实有助于避免这种情况，舍弃复杂的管理）
造枪和富士康的例子。（流程化，具象说明就是各司其职，分工明确）
利用微服务的无状态性，实现流程化和标准化，降低每个环节的复杂度，不降低整体的复杂度。

4.实力碾压（微服务的特点）

组件化：好处是组件的独立、可复用性、可替换性。微服务是组件化最彻底的架构，每个服务时高内聚的组件，对外低耦合。出了问题容易定位，也能针对性的修复，最大程度做到易维护。
快速：传统服务的开发工作量大，导致开发效率低，微服务开发工作量小，所以开发速度快。（工作量变小的理由是框架工具的优化，省去了部分工作量？从业务角度来说，设计开发工作量应该是一样的。）装配方式上进化导致快；交付效率快；体量上，一个服务时原系统的N分之一，开发、测试、部署都快。
可复用：可复用的好处有：减少了开发时间；减少因为失误而造成的返工时间；有助于更快的开发和交互。
如何体现复用：每个服务间没有绑定关系。每个服务可不断改造成其他服务，而实现无限复用（举例如现代酒店的房间和门卡，解除了耦合）。
机动灵活：传统应用，一处问题，拖垮整个系统；微服务架构中，一个服务“挂掉”，不影响其他服务，且可立即启动该服务的其它实例作为后备。

4.不要奶我（不要过分夸大微服务的作用，客观了解其不足）

不足：
1.时效性。需要高时效性的系统不适合微服务架构。由于分布式特点，服务间的调用有额外的开销，因而在不同平台或网络上，调用延时导致系统响应慢。
2.一致性。分布式事物的复杂性，微服务在保证事务一致性方面需要做更多的工作。理论上能够实现，但微服务并不擅长（不擅长这个描述不正经）。
3.需要投入。享受新架构的好处，需要投入。（没有明确说明，可能值得是学习成本、改造成本等方面吧）
4.可能造成浪费。某些功能没有足够大到需要独立为一个服务，因而可能在多个微服务项目中都存在相同的该功能，每个微服务团队都独立开发实现该功能，造成了资源的浪费。
虽然微服务开始时需要一次性投入资金、时间和精力，但从长期来看，收益显著，一劳永逸。
挑战：
1.落地。一些先决条件的准备（如PAAS等基础设施、Docker等环境），有些团队已经具备，而有些团队可能还未掌握，需要投入成本学习实践。
2.规划。规划不合理的结果就是返工，造成重复投入、重复建设。包括技术选型和梳理业务。技术选型，需要选择合适的技术以适应业务场景，进行技术间的比较取舍。梳理业务，是重点，难度由项目本身决定，全面、清晰、正确的梳理有时极具挑战性，也会造成后期大量问题。
3.开发、测试、运维。
a.接口规范，接口设计需要兼容性强，避免服务变更后导致无法调用的情况发生，做到来者不拒，宽入严出（宽入能理解，严出如何体现？）；
b.契约一致性，多个产品服务依赖基础服务，契约变更时，要保证双方契约一致性，避免服务不可用。（不理解契约一致性，具体指的是哪个方面）；
c.服务编排，拆分粒度变细，服务数量会变多，服务间的调用变复杂，需要专门的服务编排工具进行处理（后续章节提及的Netflix Conductor）；
d.容错，服务数量多，可能发生被调用服务不可用的情况，服务的降级和容错是个大的挑战，而调用方调用失败时，如何处理也是个考验；
e.运营管理，运营方式已经改变，针对众多微服务的管理，需要引入日志、监控等很多的辅助工具。部署方式也已经改变，多服务的配置、部署、资源调配需要有高度自动化的持续集成、持续部署环境，运维人员也需要掌握。
（个人：以上有些挑战已经作为优势叙述过，且有了相应的技术工具的实现，此处作为挑战再次赘述，是否表明，这些实现还不完善？存在问题？）
其他：国外适用的架构，是否在国内的业务场景依然适用，需要避免南橘北枳。微服务是个好工具，若是不适用，不是工具的问题，而是要做可行性分析的时候，需要慎重分析考量。

第二章 为何选择微服务

1.传统架构的病（缺点）

中年危机（传统架构用久了的问题）：（个人归纳：本质原因是扩展性差，由于扩展性差，遇到作者描述的这些情况时，问题就会越来越严重）新业务需求的指数级增长；激增的用户数量；旧功能不断的迭代翻新；与多个外部系统对接；核心人员流失更迭，引起代码逻辑复杂糟糕等。
（中年危机指项目刚上线，功能划分合理，运行稳健，却随着时间推移，而变得问题不断，如青年成为中年）
宝宝心里苦（传统架构本身的不足）：
1.笨拙：传统应用成为单体应用或巨石应用，太过庞大，所以开发慢、测试慢、部署慢、导致交付周期长
2.耦合严重：业务耦合；代码耦合。引发的问题有：开发和维护困难；BUG难发现；一个模块运行出错，整个进程的出错。
3.协作困难：多人开发一个应用，彼此间的修改会出现冲突，导致开发与测试时间变长，还可能引发严重问题。
4.无法持续交付：所有功能依赖于一个大应用之上，应用与应用间的依赖导致部署困难。（不清晰，这里的应用指的是一个功能模块？而且，这个现象的结果不是无法持续交付，而是部署的困难，部署与交付还是有区别）
5.受技术栈限制：技术选型确定，便无法更改。导致两个现实问题：新招的人也需要熟悉这种技术栈，哪怕其已过时（例如基于IE的老旧项目）；新技术无法引入使用。（这一点，还是扩展性的问题）
6.债务多：a.生产上，运维提出的问题，需要耗费时间精力解决，影响项目的正常进度。b.技术向业务的妥协，先实现功能，后期再计划重构，最终原开发人员离职，而重构依旧没上日常（该点，生有体会，作为程序员在前期设计阶段，由于懒惰、怕困难等原因，设计不合理，却寄希望于日后）。c.旧项目的代码逻辑不合理，由于被多个地方调用，重写代价大，若是新人接受，耗费代驾更大。

2.微服务有药（微服务能解决传统架构的问题）

讳病忌医（不要拖延问题）：合适的时间，合适的人。人：对业务和技术架构熟悉的人（核心人员）。时间：重构要趁早（其一，越早重构，需要处理的问题会少；其二，在核心人员流失之前，进行重构）。太迟重构的代价可能比重新开发的成本还高。
朋友听说过架构么（好的架构需要具有的特点）：好的架构一开始就要考虑后面的扩展和修改。好的架构师是解耦的。好的架构一定是轻量灵活的。
沙盘演练看效果（实践前，先从理论上论证微服务可行）：提出问题，并将评测指标量化，然后以传统架构和微服务的分案分别得出数值，进行比较。例如：问题为修改一个需求的代价，评价指标为代码修改处数量、测试工作量、交付周期、人员数量等。
微服务灵活多变的特点，更适合应对多变的外界因素。

3.微服务的价值

资源价值：一些系统有偶发性流量洪峰（京东618、天猫双11、中介公司月末录单据），通过微服务合理利用资源：a.资源不足时扩容，资源过量时缩容；b.部署云平台，按需支持更省钱（交由云平台负责扩缩容）。（传统系统一样有分布式架构，这一点难道不能实现？）
业务价值：业务稳定的系统，是否通过微服务重构的决策，取决于收益。通过沙盘演练论证量化工作量、人员数量、交付质量、交付周期等指标，来表明收益。交由企业相关人员决策。
技术价值：a.“从一种技术架构换成另一种技术架构，只是重新实现一遍，若没有改变现状，也没有带来收益，是没有价值的。”作者否定了这种观点，他认为，技术的价值在于积累和可重用，新技术用在其他新项目上，就体现出了价值。（说白了，利用技术重构的契机，重学一门新技术并积累实践经验，对个人和公司的技术积累是有益的（若公司有注重技术积累的话），但是牺牲了项目进度。个人观点：需要考虑项目紧急程度，和该门新技术的未来前景）b.技术为业务服务，通过技术能够促进业务的发展（再一次出现这个观点），同时通过推广扩大技术的影响范围（这两个的前提是，新技术在性能上优于旧技术，扩大是发挥新技术的真正实力），最终体现技术的价值。
用户价值：当企业认为用户已经习惯旧系统，新系统将导致用户不适应。要从用户角度说服企业。沃尔玛引入电子支付的例子，改变传统的付账习惯。微服务的交付上线速度快（可每日发布更新），能迅速提升用户体验。
未来价值：微服务架构的高扩展性，可适应未来业务的不断提升，越发体现其价值。
小结：微服务的短期收益易于论证，而无法预测和量化的未来收益可能会更大。

4.定个小目标（微服务想实现的目标）

持续交付：传统周期性交付（短则一个月长则几个月的交付周期）变成随时上线、随时交付。
业务敏捷：通过快速响应、持续开发、持续交付，真正做到业务敏捷。传统模式下，需求审批部门根据上线周期，对需求进行排期；微服务架构下，将需求分散到日常，形成每天一个常态模式。
（个人：查看敏捷开发的概念和特点，会发现微服务架构完美契合，是实现敏捷开发思想的利器）
独立演进：每个服务作为一个独立项目由各个团队分别开发管理。原因：不同服务项目的业务和技术侧重点都不同（如报表统计业务和读写数据业务），独立演进能发挥各自技术的优点，更好地为业务服务；小的团队管理模式从简（流程简、交流易、掣肘少），生产更加高效。
高可用：架构的优化、能够持续交付、关键业务的隔离、熔断机制的保障，达到业务和系统的高可用，减少宕机次数与时间，降低宕机的感知度。（简单地说，通过架构和技术，使系统不容易出问题，即使出问题，用户也不容易察觉到，并且能很快地修复）
高性能：实现大规模存量数据和快速增长条件下的高性能。通过自由伸缩（即增加或减少服务实例）来实现。
站在云端：云服务简化了容器化微服务创建、集成、部署、运维的整个流程，推动微服务在云端的大规模实践。（不太理解）

4.别人家的公司（其他公司对微服务的态度）

仅仅以亚马逊作为例子。亚马逊在做事的方式和态度上，强势、谨慎、不盲从、不跟随（事例：每年重构系统；花几年时间准备一件事；甘肃云计算中心落户事件）。连亚马逊都选择微服务了，我们就无须顾虑。

第三章 我拆我拆我拆拆拆（拆解旧系统）

1.拆还是不拆（引言而已）

举例引出，不知道拆的原则的前提下，大多数关于拆和不拆的辩论无意义。
（个人：作者“拆的原则”指的是“怎么拆”，他认为只有知道了“怎么拆”，才能知道“该不该拆”。下一节的关键指标，就是是否要拆的判断标准）

2.如何拆（拆解流程和方法）

庖丁解牛（对拆解目标熟悉，并依据拆解规律）：对需要拆解的系统熟悉，熟悉系统的架构、业务，知道业务功能的划分、模块的边界。
数据模块和业务模型：数据模型是骨架，业务模型是皮肉，所有的业务功能依附于数据模型上。
根据数据模型分出业务模块：同属于一个业务模块的数据模型（实体）会聚集在一起，根据图像就能直观看出。
通过业务模型识别出不同业务主体（指人？）的流程环节，将业务主体进行分类，不同类别的业务主体间用业务泳道分隔，形成一个业务泳道图。
金字塔结构图：将系统的所有业务功能点不断细分，从上到下，从大到小，就能型材一个金字塔结构图，最底层是最小粒度的功能。
细分的过程中能发现很多相同的功能，用于去重。
关键指标（进一步拆分依据）：
1.公共的业务功能（10分关键）：a.被一个以上服务调用的接口方法都要独立出来，抽象成公共服务。b.服务的2种类型：产品服务和基础服务，基础服务就是公共服务（如用户服务、计算服务、配置服务）。c.业务环节中，每个业务主体有很多规则，贯穿整个流程，需要抽取每个主体的规则，做成统一的规则服务。
2.重点业务（9分关键）：偏向业务主体（意思是受到领导高层等有决策权的人的强调和关注），代表了未来业务的发展方向。
3.对系统有重大影响的业务功能（8分关键）：包括一些对性能和资源消耗高的业务（如强计算业务、业务量大的业务）
4.经常变化的业务主体（7分关键）：有些业务主体经常变化（个人：或者尚不确定），不要与其他业务解耦，避免出现变更改动时影响多出，也避免日后的隐患。
5.特殊业务主体（6分关键）：有独特的处理逻辑，与普通业务差别大，业务逻辑无法共用，需要独立出来。
6.不同业务渠道（5分关键）：不同方式实现同一个业务（如人工售票和自动售票），也需要拆解出来。
7.业务复杂、带业务流程的（4分关键）：复杂业务拆分多个服务；业务流程拆分不同服务，各个独立的服务还能再向下拆分

3.粒度

拆解的粒度必须结合业务场景。以解决实际问题为出发点来拆解，拆的时候考虑意义，拆完之后考虑维护的难度。
（个人：没有提出粒度的定性或定量标准，相当于回到了最初的无意义辩论上）
拆解的过程是循序渐进的。
满足复杂度和灵活性平衡的方案，所以拆解粒度不能太大，不能太小：拆的少，没有拆的必要。拆的多，一个业务的组合因子多，造成出现问题难定位，多服务的管理（普什图语的字典编写教授被国家遗忘的例子）等问题。

4.边界

边界清晰：每个微服务的业务边界需要明确且清晰。避免两个服务在功能上的重叠，引起共同维护或互相推责的问题。
另外，边界越早定清楚越好。
分工明确：微服务之间或者一个服务之内，分工需要明确，避免开发维护的麻烦。

第四章 如何使用微服务

使用微服务的两种情况：新项目、老项目微服务化（主要、难）

1.规划

全局性：包括业务和技术。业务方面，做好识别范围的工作，不能有遗漏。技术方面，考虑架构的成熟度和稳定性，还要考虑将来如何升级，当业务数量和用户数量几何级增长后，系统能否支撑。要从长远眼观考量，业务与技术的演进之路，同时技术要以为业务服务为目标。
针对性：针对主要业务，将其剥离成一个独立的服务；针对旧系统的不足与问题，考量新的方案。
良性发展：技术架构以长远的业务目标作为考量而设计，以促进业务的不断发展（业务方面的迭代）。（此处作者认为，优良的技术基础是能促进业务的发展）
格局大：大的格局，在之后的长时间内，都将具有很好的扩展性。

2.微服务重构

影响因素：环境因素，包括企业架构、战略、过程、技术、人等等。如，企业基础设施，部署的审批流程等。
重构原则：最合理、最经济、影响最小、安全系数最高
1.前后端分离。表现层和逻辑层解耦，微服务改造前提。
2.代价最小原则。重构时机，越早代价越小。需求“冷冻期”内重构（该情况不多见，多是一边使用以便重构）。新增需求和重构同时进行时，将新需求坐在新的服务上，避免两边都开发（重构和测试验证的的工作量巨大）。
3.影响最小原则。对系统的影响要降到最低，旧系统保证能正常使用。试点的方式让风险提前暴露，及时改进，避免风险影响范围的扩大。
4.吐故纳新。以微服务重构作为契机，废弃旧系统不合理之处，使用新的流程或者使用新规范优化。最优的方式是从业务上做优化，技术实现之。（业务简单明了，流程优化，重构才有价值；不做变化的业务流程，重构无意义）
重构方法：
1.接骨法：拆分业务环节，再慢慢逐一将各个业务环节服务化（REST接口或消息队列）。
2.分批逃跑法：从旧系统中拆业务，拆一个改造成一个新的微服务应用，最终，如果新应用代替旧系统。
3.修路法：微服务化时，旧系统正常使用。所有业务的上下游从直接调用改为REST调用或消息队列方式隔离。
（这一部分举了例子，减少了说明，很难让人分清3个方法间太大的差别）

第四章 微服务的朋友圈

1.好朋友容器

容器与微服务：微服务刚面世时，由于服务被拆成多个应用，部署的复杂度增加。容器的出现，取代了传统的部署方式。容器与微服务项目促进，共同发展。
容器的来历：容器最重要的特性是隔离。
虚拟化技术（如vmware虚拟机），是虚拟出多个操作系统，且互相不影响。容器技术，是虚拟化技术的升级，在一个操作系统上，隔离出多个应用，互相不影响。
容器相比虚拟机，轻量、灵活、启动快、移植方便、简化部署复杂度。
容器的好处：
1.环境的一致性。很多时候环境不一致引起部署的问题，如代码不一致、配置文件不一致、数据库脚本不一致、运维执行错误等。开发环境下使用Docker（开源的应用容器引擎）构建好应用的镜像，在生产上使用同一个镜像，保证线上线下环境的一致性。
2.减少部署的重复工作：传统部署需要搭建环境、配置变量等步骤，当需要再多台机器上部署时，便要不断重复这些步骤。使用Docker容器引擎，简化了部署过程。
3.快速交付：部署变得容易的同时，可以实现快速交付，为持续集成创建了条件。
（个人：持续集成、持续交付、持续部署。每一个都是在前一个的基础上完成的）
4.安全性高：容器和操作系统隔离，彼此互不干扰，提高了系统的安全性。
5.易集成：将不同应用部署在不同容器中，解除耦合，使应用间的集成变得容易。
6.自带体系。完整的、独立的生态，可以被各处运行。

2.天生一对DevOps

DevOps：开发+运维。将开发与运维融合在一起，实现快速交付，快速反馈。生成反馈及时给了开发，缩短了开发周期，部署频率更高，快速及时检测和修复缺陷。
DevOps模式使产品周期的流程形成一个闭环（PLAN > CODE > BUILD > TEST > RELEASE > DEPLOY > OPERATE > MONITOR > PLAN），而不再是线性的流转。一个闭环是一个迭代周期，不断地快速迭代。
DevOps的概念不久，但实践经验更早更长。在小团队、敏捷开发、全栈开发中一直都在运用，只是那时尚缺DevOps的自动化工具。
为什么采用DevOps：随着项目增大，人员增多，组织结构复杂，需要耗费沟通成本，责任分工不明等问题，导致交付效率变低。而微服务架构将一个大项目划分为多个微服务项目，人员的组织也能类似分为多个团队，一个团队对应一个或多个小项目，项目彼此独立，团队也彼此独立，重新变得高效。

3.SOA是谁

接着忽悠（微服务与SOA不同）：作者观点，谈及微服务时不要提SOA
SOA是个什么鬼：
SOA面向服务架构，WebService是面向服务的一种实现。
面向服务是软件架构的普适原则，由于服务两个字，便被虚假的专家误导，“微服务是SOA的最佳实践”这个错误观点。
微服务是不是SOA，仁者见仁，该问题没有实际意义，多关注微服务。
（个人：作者始终不敢，明确说出，微服务不是SOA，但却不断批评将SOA与微服务联系起来的“专家”）

微服务	SOA
能拆分的就拆分	是整体的，服务能放一起就放一起
纵向业务划分	是水平分多层
由单一组织负责	按层级划分不同部门的组织负责
细粒度	粗粒度
两句话可以解释明白	几百字只相当于SOA的目录
独立的子公司	类似大公司里面划分了一些业务单元（BU）
组件小	存在较复杂的组件
业务逻辑存在于每一个服务中	业务逻辑横跨多个业务领域
使用轻量级的通信方式，如HTTP	业务服务产总线（ESB）充当了服务中间通信的角色