【微服务设计】第一篇：什么是微服务

该系列文章是我阅读《微服务设计》这本书的读书笔记，对书中内容进行了提炼和总结，有些地方加入了自己的见解。

1.什么是微服务

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

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

伴随着新功能的增加，时间久了代码库会越来越庞大，以至于想要知道应该在什么地方做修改都很困难。

尽管我们想在巨大的代码库中做到清晰地模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，这让修复bug和修改原有实现更加困难。

微服务将内聚性这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容易确定某个功能代码应该放在哪里。由于该服务专注于某个边界之内，因此可以很好地避免由于代码库过大而衍生出来的很多让人头痛的问题。

那么代码库多小才算小？作者给出的一个比较老套的方案是：足够小即可，不要过小。那么换句话说，如果你不再感觉你的代码库过大，可能他就足够小了。

还有一点就是该服务是否能够很好的与团队结构相匹配。

服务越小，微服务架构的优点和缺点也就越明显。使用的服务越小，独立性带来的好处就越多。但是管理大量服务带来的复杂性也会越来越大。

如果你能够很好的处理这一复杂性，那就可以尽情地使用较小的服务了。

1.2 自治性

一个微服务就是一个独立的实体。它可以独立地部署在PAAS上，也可以作为一个操作系统的进程存在。我们要尽量避免把多个服务部署在同一台机器上，尽管这种隔离性会带来一些代价。

服务直接均通过网络调用进行通信，从而加强了服务直接的隔离性，避免紧耦合。

这些服务应该可以彼此间独立进行修改，对于一个服务来说，我们应该考虑暴露应该暴露的部分，如果暴露过多服务消费方和提供方就会产生耦合。这会使得服务提供方和消费方直接产生额外的协调工作，从而降低服务的自治性。

服务提供者会暴露出API，然后服务之间通过这些API进行通信。如果系统没有很好地进行解耦，那么一旦出现问题，所有的功能都将不可用。

2.微服务的主要好处

2.1 技术异构性

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

2.2 弹性

弹性工程学的一个关键概念是舱壁。其实服务边界就是一个很显然的舱壁，是保证微服务健壮性的一种模式。

比如说一艘邮轮有 8 个防水舱，舱壁的设计可以保障如果只有 2 个舱进水，密闭和隔离可以阻止水继续漫延至下一个防水舱，从而保证邮轮的基本浮力，继续航行。

微服务可以改进弹性，但你还是需要谨慎对待，因为一旦使用了分布式系统，网络就是个问题，机器也是个问题。因此我们需要了解出现问题时应该如何对用户进行友好展示。

2.3 扩展

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

2.4 简化部署

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

2.5 与组织架构相匹配

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

2.6 可组合性

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

2.7 重构更简单

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

3.面向服务的架构

面向服务的架构（SOA） 是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列的功能。

SOA 本身是一个很好的想法，但尽管做了很多尝试，人们还是无法在如何做好 SOA 这件事情上达成共识。

因为业界大部分的尝试都没能把它当作一个整体来看待，因此很难给出一个比该领域现有厂家提供的方案更好的替代方案，也就是没有对应的标准和方法论。所以在实施 SOA 时会遇到一些问题：通信协议如何选择、第三方中间件如何选择、服务粒度如何确定等。

而这事实上就是微服务架构，你也可以认为微服务架构是 SOA 的一种特定方法。

4.其他分解技术：共享库

不同的团队和服务可以通过库的形式共享功能，比如说公司私服上的那些可重用的工具类库。
但是需要注意的是，如果通过共享代码来做服务之间的通信，那么这将成为一个耦合点。

5.没有银弹

软件工程没有银弹，微服务也是如此，它不是免费的午餐更不是银弹。

选择微服务的同时，你需要在部署、测试、监控等等方面做很多的工作，你还需要考虑如何扩展系统，并且保证他们的弹性，还需要处理分布式事务与 CAP 相关的问题。

因为每个公司的组织架构，系统业务都不一样。微服务是否适合你，或者说你能够在多大的程度上采用微服务，这取决于众多的因素。

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