最近在重读《微服务设计》这本书，我会输出我认为的精华部分所在，希望自己能有更多的总结领悟和思想碰撞，从而提升自己。重新审视微服务该如何设计。开始吧：

1.什么是微服务

微服务就是一些协同工作的小而自治的服务。

1.1 很小，专注于做好一件事

随着新功能的增加，代码库会越变越大。时间久了代码库会越来越庞大，以至于想要知道应该在什么地方做修改都很困难。尽管我们想在巨大的代码库中做到清晰地模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，这让修复bug和修改原有实现更加困难。
微服务将内聚性这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容易确定某个功能代码应该放在哪里。由于该服务专注于某个边界之内，因此可以很好地避免由于代码库过大而衍生出来的很多让人头痛的问题。
那么代码库多小才算小？作者给出的一个比较老套的方案是：足够小即可，不要过小。那么换句话说，如果你不再感觉你的代码库过大，可能他就足够小了。还有一点就是该服务是否能够很好的与团队结构相匹配。
服务越小，微服务架构的优点和缺点也就越明显。使用的服务越小，独立性带来的好处就越多。但是管理大量服务带来的复杂性也会越来越大。
如果你能够很好的处理这一复杂性，那就可以尽情地使用较小的服务了。

1.2 自治性

一个微服务就是一个独立的实体。它可以独立地部署在PAAS上，也可以作为一个操作系统的进程存在。我们要尽量避免把多个服务部署在同一台机器上，尽管这种隔离性会带来一些代价。
服务直接均通过网络调用进行通信，从而加强了服务直接的隔离性，避免紧耦合。
这些服务应该可以彼此间独立进行修改，对于一个服务来说，我们应该考虑暴露应该暴露的部分，如果暴露过多服务消费方和提供方就会产生耦合。这回使得服务提供方和消费方直接产生额外的协调工作，从而降低服务的自治性。
服务提供者会暴露出API，然后服务之间通过这些API进行通信。如果系统没有很好地进行解耦，那么一旦出现问题，所有的功能都将不可用。

2.微服务的主要好处

2.1 技术异构性

在一个由多个服务相互协作的系统中，可以在不同的服务中使用最适合该服务的技术。尝试使用一种适合所有场景的标准化技术，会使得所有的场景都无法得到很好的支持。
微服务可以帮助我们轻松地采用不同的技术：

2.2 弹性

弹性工程学的一个关键概念是舱壁虎。其实服务边界就是一个很显然的舱壁。微服务可以改进弹性，但你还是需要谨慎对待，因为一旦使用了分布式系统，网络就是个问题，机器也是个问题。因此我们需要了解出现问题时应该如何对用户进行友好展示。

2.3 扩展

庞大的单体服务只能作为一个整体进行扩展。即使系统中只有一部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的服务，则可以选择只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在性能更差的硬件上从而节省成本。

2.4 简化部署

在几百万代码行的单体应用程序中，即使你只修改了一行代码，也要重新部署整个服务发布该变更。
在微服务架构中，各个服务的部署是独立的，这样就能更快的对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚。

2.5 与组织架构相匹配

微服务架构可以将架构和组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小和生产力。服务的所有权也可以在团队直接迁移，从而避免异地团队的出现。

2.6 可组合性

在微服务架构中，系统会开放很多接口供外部使用。而单体应用只能提供一个非常粗粒度的接口供外部使用。所以微服务架构可以达到可重用，可组合的目的。

对可代替性的优化

想想看，在一个庞大的单体应用中你敢不敢在一天内删掉上百行代码，并且确性不会引发问题。所以使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务。

3.面向服务的架构

SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列的功能。SOA本身是一个很好的想法，但尽管做了很多尝试，人们还是无法在如何做好SOA这件事情上达成共识。因为业界大部分的尝试都没能把它当作一个整体来看待，因此很难给出一个比该领域现有厂家提供的方案更好呢替代方案，也就是没有对应的标准和方法论。所以在实施SOA时会遇到一些问题：通信协议如何选择、第三方中间件如何选择、服务粒度如何确定等。而这事实上就是微服务架构，你也可以认为微服务架构是SOA的一种特定方法。

4.没有银弹

软件工程没有银弹，微服务也是如此，它不是免费的午餐，更不是银弹。选择微服务的同时，你需要在部署、测试、监控等方面做很多的工作，你还需要考虑如何扩展系统，并且保证他们的弹性，还需要处理分布式事务与CAP相关的问题。
每个公司、组织及系统都不一样。微服务是否适合你，或者说你能够在多大的程度上采用微服务，取决于很多因素。

架构师承担了驱动系统演化的职责，而引入微服务之后的一个主要挑战就是，架构师职责的相应变化。下一章会讲到有哪些方法可以保证我们从这个新架构中受益。