第三部分未完结，挖坑先。。。
第一章 介绍
我们只在我们没有其他选择时改变单体 (monolithic) 系统。与其说是敏捷地抓住机会，我们考虑它是否确实值得倾覆我们称为纸牌屋的企业系统的微妙平衡。通常，机会很快就消失了，被快速的公司抓住。
Flaus Schwab: 在新世界，不是大鱼吃小鱼，是快鱼吃慢鱼。
基于微服务的架构是个简单的概念：它提倡用一组小的、隔离的服务来创建系统。这些服务拥有它自己的数据，各自是独立的、可扩展且对失败有弹性。服务集成其他服务来构建一个内聚的系统，它比我们当前构建的典型企业系统更灵活。
传统企业系统设计为单体应用，难以扩展，难以理解且难以维护。单体应用可能很快就变成噩梦，扼杀创新、进度和乐趣。单体应用导致的负面作用对一个公司可能是灾难性的，从底层的士气到高层雇员的周转，从阻止公司雇佣顶尖工程天才到失去市场机会，在极端情况下，甚至是公司的失败。
战争故事通常听起来是这样的：“我们终于做了决定来改变我们的 Java EE 应用，在得到管理层批准后。然后我们经过长达数月的大设计，在我们最终开始构建点东西之前。但我们构建期间的大多数时间都花在尝试弄清楚单体应用真正做了什么。我们因害怕而瘫痪，担心一个小的错误可能导致非预期的、未知的副作用。最终，在数月的担忧、害怕和艰难工作后，改变实现了，但地狱也打开了。”
这样的经历会加强害怕，使我们瘫痪更严重。这就是系统、公司如何停滞的。如果有更好的方式呢？
Steve Jobs：You’ve got to start with the customer experience and work back towards the technology 。
微服务的客户是投资于系统的组织，所以让我们从客户开始：开发人员、架构师和关键利益相关者。
需要拯救的服务
Helen Keller：Although the world is full of suffering, it is also full of the overcomming of it .
因为技术原因，微服务是软件里不纯粹的下一代设计演进。微服务这个词汇呈现的思想在我们进入面向服务的架构（SOA, Service Oriented Architecture）之前已经遍布各处。阻止我们采用微服务内嵌的概念的特定技术约束已经进入下一水平：单台机器运行着单个内核处理器，慢速的网络，昂贵的磁盘，昂贵的 RAM，组织结构是个单体。像把系统组织成一个定义良好的、有单一职责的系统的想法不是新的。
快进到 2016 年，阻止我们采用微服务的技术限制已经消失了。网络是快速的，磁盘是便宜的（且更快速），RAM 是便宜的，多核处理器是便宜的，云架构正在彻底改革我们如何设计、部署系统。现在，我们终于可以考虑着客户来构建我们的系统。
设计和编写软件是有趣的，这是大多数的我们进入软件行业的初衷。微服务不仅仅是一序列的原则和技术。它们以一种更专业的方式来达成复杂问题的系统设计。
微服务允许我们以组织我们团队的方式来构建系统，在团队成员之间划分职责，保证他们自由处理自己的工作。当我们理顺了我们的系统，我们把权利从中央治理主体移交到小团队里，小团队可以快速抓住机会并保持敏捷，因为他们明白 他们控制的、有定义良好的边界的软件。