是的，我知道电影中真正的问题是，在午夜后喂魔怪了。用这个来类比单体应用确实是有些不完美。
单体应用复杂度高—— 代码越多，就越难理顺每个组件在整个应用程序中的作用。单体应用测试更困难 —— 随着应用程序的增长，测试变得更加困难，整体验收测试变得更加复杂。单体应用更容易发生库冲突 —— 一个功能可能需要某个依赖，但这与另一个所需的依赖又无法兼容。单体应用不易扩展—— 如果您需要将应用程序部署到更多节点，以扩展性能，会发现效率很低。因为即使只是应用程序的一小部分需要扩展，也必须将整个应用程序全部部署。技术选型会影响整体—— 当您需要为应用做技术选型时，如：为应用程序选择语言、运行时平台、框架或库，您是为整个应用程序在选择它。单体应用的部署上线工作更复杂 —— 虽然看起来当一个应用程序只有一个部署单元时，很容易就可以部署到生产环境。然而，由于单体应用的规模和复杂性很大，应用程序通常需要一个更严格的开发过程和更长的测试周期。以确保所部署代码的质量，以及不会因此引起其他问题。微服务架构是将应用程序分解成小规模应用的办法，这些小应用独立开发和部署。这些小应用（微服务）相互协调，以提供更完整和强大的应用程序。与单体应用程序架构相比，微服务体系架构有以下特点：微服务很容易理解 —— 在一个大的应用程序中，每个微服务与其他微服务之间的联系是有限的。因此，微服务的目标更加明确，作为一个完整单元更容易理解。微服务更容易测试 —— 越小的东西越容易测试。这一点是显而易见的，比如单元测试和集成测试、验收测试相比。当然这个原则也适用于测试微服务和测试单体应用的情况。微服务不太可能出现不兼容 —— 因为每个微服务都有自己的一组构建依赖项，这些依赖项不与其他服务共享。在微服务中，发生冲突的可能性较小。微服务更易扩展 —— 如果任何给定的微服务需要更多资源，微服务可以独立扩展。可以独立计算内存分配和实例数，而不影响其他微服务的内存或实例。技术选型更方便 —— 对于每个完全不同的微服务，技术选择可以不同。可以就语言、平台、框架，以及每个微服务的依赖库进行选择。事实上，一个用 Java 编写的微服务，与另一个用 C# 编写的微服务进行通讯，是完全合理的。微服务可以更频繁的部署 —— 一个应用程序由许多微服务组成，每个微服务都可以独立部署，而不要求任何其他微服务必须部署。因为它们更小，更专注，更容易测试，所以将微服务投入生产环境中的步骤就更少。从有一个想法，到在生产中看到它，使用微服务架构可能在几分钟内或几个小时就可以做到。而不是像单体应用架构那样，一般要几个星期或几个月。我们将重点讨论用 Java 和 Spring 编写的微服务。但是如果你对使用 .NET 编写与 Spring Cloud Services 一起工作的微服务感兴趣，可以关注 Steeltoe http://steeltoe.io/。
Cloud Native Patterns 一书（Manning, 2019, www.manning.com/books/cloud-native）。