13.1深入思考微服务
到目前为止，您已经将 Taco Cloud 应用程序开发为单体应用程序。它构建到一个可部署的 JAR 或 WAR 文件中。开发成单体应用是很正常，几十年来大多数应用程序都是这样构建的。即使将应用程序分解为多模块构建，您最终也仍然会得到一个 JAR 或 WAR 文件，然后再将其推送到生产环境中。
这无疑是构建小型、简单应用程序的最适宜的方法。但有趣的是，小型应用程序往往会增长。当需要一个新的特性时，很容易在项目中添加更多的代码。在你意识到大事不妙之前，您的应用就已经变成复杂的单体的应用了。就像电影《小精灵》里的魔怪，如果你不断的喂养它，它最终会变成一个怪物，给您带来天大的麻烦。
是的，我知道电影中真正的问题是，在午夜后喂魔怪了。用这个来类比单体应用确实是有些不完美。
单体应用程序看似简单，但存在以下这些问题：
单体应用复杂度高—— 代码越多，就越难理顺每个组件在整个应用程序中的作用。单体应用测试更困难—— 随着应用程序的增长，测试变得更加困难，整体验收测试变得更加复杂。单体应用更容易发生库冲突—— 一个功能可能需要某个依赖，但这与另一个所需的依赖又无法兼容。单体应用不易扩展—— 如果您需要将应用程序部署到更多节点，以扩展性能，会发现效率很低。因为即使只是应用程序的一小部分需要扩展，也必须将整个应用程序全部部署。技术选型会影响整体—— 当您需要为应用做技术选型时，如：为应用程序选择语言、运行时平台、框架或库，您是为整个应用程序在选择它。单体应用的部署上线工作更复杂—— 虽然看起来当一个应用程序只有一个部署单元时，很容易就可以部署到生产环境。然而，由于单体应用的规模和复杂性很大，应用程序通常需要一个更严格的开发过程和更长的测试周期。以确保所部署代码的质量，以及不会因此引起其他问题。
在过去的几年中，微服务架构已经兴起以应对这些挑战。简单来说，微服务架构是将应用程序分解成小规模应用的办法，这些小应用独立开发和部署。这些小应用（微服务）相互协调，以提供更完整和强大的应用程序。与单体应用程序架构相比，微服务体系架构有以下特点：
微服务很容易理解—— 在一个大的应用程序中，每个微服务与其他微服务之间的联系是有限的。因此，微服务的目标更加明确，作为一个完整单元更容易理解。微服务更容易测试—— 越小的东西越容易测试。这一点是显而易见的，比如单元测试和集成测试、验收测试相比。当然这个原则也适用于测试微服务和测试单体应用的情况。微服务不太可能出现不兼容—— 因为每个微服务都有自己的一组构建依赖项，这些依赖项不与其他服务共享。在微服务中，发生冲突的可能性较小。微服务更易扩展—— 如果任何给定的微服务需要更多资源，微服务可以独立扩展。可以独立计算内存分配和实例数，而不影响其他微服务的内存或实例。技术选型更方便—— 对于每个完全不同的微服务，技术选择可以不同。可以就语言、平台、框架，以及每个微服务的依赖库进行选择。事实上，一个用 Java 编写的微服务，与另一个用 C# 编写的微服务进行通讯，是完全合理的。微服务可以更频繁的部署—— 一个应用程序由许多微服务组成，每个微服务都可以独立部署，而不要求任何其他微服务必须部署。因为它们更小，更专注，更容易测试，所以将微服务投入生产环境中的步骤就更少。从有一个想法，到在生产中看到它，使用微服务架构可能在几分钟内或几个小时就可以做到。而不是像单体应用架构那样，一般要几个星期或几个月。
我们将重点讨论用 Java 和 Spring 编写的微服务。但是如果你对使用 .NET 编写与 Spring Cloud Services 一起工作的微服务感兴趣，可以关注 Steeltoe http://steeltoe.io/。
微服务似乎确实让事情变得简单多了。但公平地说，微服务架构也不是免费的午餐。微服务架构是一种分布式体系结构，它有自身的挑战，包括网络延迟等。如果要迁移到微服务架构，您应该记住更多的远程调用会降低应用程序的响应速度。
您还应该考虑，使用微服务架构，构建您的应用程序是否是有意义的。并不是所有的应用程序都需要或受益于这样的架构。如果应用程序相对较小或简单，也许最好将其作为一个单体应用。…… 随着它的发展，您再开始考虑将其拆分为微服务。
在开发云原生、微服务架构方面有很多新思想。本章和接下来的几章将主要关注 Spring Cloud 提供的，用于开发微服务的能力。但如果您有兴趣深入研究云原生应用程序的设计和思想，我建议您阅读 Cornelia Davis 的 Cloud Native Patterns 一书（Manning, 2019, www.manning.com/books/cloud-native）。
微服务架构面临的另一个常见挑战是，一个服务如何了解与之协调工作的其他服务。这正是本文的主题。接下来让我们看看，如何使用 Spring Cloud 建立服务注册中心。