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