3.1.2 微服务的优缺点

微服务有很多优点，具体如下。

1. 技术异构性

在一个由多个服务相互协作的微服务系统中，各服务可以选择使用最适合自己的技术。如果系统中的一部分需要进行性能提升，可以使用性能更好的技术栈重新构建该部分。对于系统中的不同部分，也可以使用不同的数据存储技术。

对微服务系统而言，总会存在一些可以使用新技术的地方，并且可以选择一个风险最小的服务来采用新技术，这样即便出现问题也容易处理，这种快速采用新技术的能力对很多组织而言是非常有价值的。而对单块系统而言，采用新的语言、数据库或者框架都会对整个系统产生巨大的影响，并且还存在一定的风险。

2. 弹性

弹性工程学中的一个关键概念是舱壁，如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务边界就是一个很典型的舱壁。在单块系统中，如果服务不可用，那么所有的功能都会不可用。对单块系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率。而微服务系统本身就能够很好地处理服务不可用和功能降级的问题，从而更好地改进弹性。

3. 扩展

庞大的单个服务只能作为一个整体进行扩展，即使其中只有一小部分存在性能问题，也需要对整个服务进行扩展。而对微服务而言，通过使用较小的多个服务，可以只对需要扩展的服务进行扩展。这样一来，可以把那些不需要扩展的服务运行在更小、性能稍差的硬件上，从而节省成本。

4. 简化部署

在有几百万行代码的单款应用中，即使只修改了一行代码，也需要重新部署整个应用程序才能够发布该更改。这种部署的影响很大、风险很高，因此相关干系人不敢轻易进行部署。于是在实际操作中，部署的频率就会变得很低，并且修改出错的可能性会变大。而在微服务架构中，各服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。当出现问题时，只会有一个服务受影响，并且容易快速回滚。这意味着客户可以更快地使用开发的新功能。Amazon和Netflix等之所以采用这种架构，主要就是基于上述考虑。这种架构能够很好地清除软件发布过程中的种种障碍。

5. 与组织结构相匹配

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

6. 可组合性

单纯考虑桌面网站或者应用程序的时代已经过去，现在需要考虑的应用程序包括Web、原生应用、移动端Web、平板应用及可穿戴设备等。针对每一种应用程序，都应该考虑如何组合已有功能来进行实现。在微服务架构中，人们可以根据不同的目的，通过不同的方式使用同一个功能。因为在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用。而整体化的应用程序只能提供一个非常粗粒度的接口供外部使用，如果想要得到更有用的细化信息，则需要将已有的单个应用程序分解成为多个微服务，从而实现可重用、可组合。

7. 对可替代性的优化

当使用多个小规模服务时，重新实现某一个服务或者直接产出该服务都是相对可操作的。使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务。当一个代码库只有几百行代码时，人们也不会对它有太多感情上的依赖，所以可以很容易地替换它。

与此同时，微服务也存在一些缺点，具体如下。

1. 运维成本及要求较高

对于单体架构的项目，工作人员只需要维护其本身就可以达到目的。而基于微服务的架构则不同，原因在于，一个项目是由多个微服务组成的，当某个模块出现故障时，整个项目都无法运行，而想要具体追踪到出故障的模块往往是不容易的，需要花费大量的时间和人力去解决，并且对运维人员来说是一种挑战。

2. 复杂性较高

对于单体架构，分布式技术可有可无，并不影响一个项目的运行。但是对于微服务架构，分布式技术是必不可少的技术，这也导致分布式本身具有的缺点也转移到微服务架构上，从而使微服务架构变得复杂。

3. 接口调整成本高

在调整一个运用层的接口时，微服务架构需要追溯到底层服务的各接口来支撑相关修改，对依赖它的微服务也要进行相应的调整，而整个修改是十分复杂的，并且其调整接口所需要的成本也相对较高。

4. 重复劳动

在单体结构上出现重复使用某个方法的情况时，为了避免重复，相关人员会将该方法抽象出来，将其作为一个工具类进行使用。但是对于微服务，却很难做到避免重复劳动，这是由于在多个微服务之间，某个服务不能直接调用其他服务的工具类，虽然在某些情况下可以使用相同的基石框架，然后让这些底层基石框架存储公用的工具类，但这样将会导致基石框架的复杂度变高，同时也会引入很多不必要的东西，不利于整个框架的运行。