1.7.1　从多层架构到微服务和其他架构

IT基础设施一直在影响着软件应用的架构和设计方式。最初，我们曾将单体应用以单一组件的形式部署在庞大的大型机上。当互联网和PC流行起来之后，我们开始按照客户端/服务器的范式设计应用。依赖该范式的多层架构广泛用于桌面和Web应用中，该架构会将代码分解为展现层、业务层和数据层。

随着应用复杂性的增加以及敏捷性的需要，人们在探索进一步分解代码的新方式，一种新的架构风格应运而生，那就是微服务。在过去的几年中，这种架构风格变得越来越流行，许多公司决定按照这种风格重构它们的应用。微服务通常会拿来与单体应用进行对比，如图 1.13所示。

图1.13　单体应用与微服务。单体架构通常是多层的，微服务是由不同的组件组成的，
这些组件可以独立部署

两者之间的主要差异在于应用是如何分解的。单体应用会使用较大的三层，而基于微服务的应用则会使用众多组件，每个组件实现一部分功能。目前有很多关于如何将单体分解为微服务，并处理众多组件所带来的复杂性的模式。

注意　本书不是关于微服务的，因此，我不会讨论细节。如果你对这个话题感兴趣的话，可以参阅Sam Newman的Building Microservices（第2版）（O’Reilly, 2021年）以及Chris Richardson的Microservice Patterns（Manning, 2018年）。在Spring方面，可以参阅John Carnell和Illary Huaylupo Sanchez合著的Spring Microservices in Action（Manning, 2021年）。如果你不熟悉微服务的话也不要担心，要学习后面的内容，这些知识并不是必备的。

在经历了多年的热度和诸多失败的迁移之后，开发者社区围绕这种流行的架构风格展开了激烈的讨论。有些开发人员建议转向宏服务（macroservice），以减少组件的数量，从而降低管理的复杂性。“宏服务”这个术语是由Cindy Sridharan提出的，最初带有讽刺意味，但是它已经被行业所采用，Dropbox和Airbnb这样的公司已使用它来描述新的架构。[18]有些人则提议采用城堡式（citadel）架构风格，该风格由一个被微服务包围的中心化单体组成。还有人主张以模块化单体的形式重回单体应用架构。

[18]　C. Sridharan, http://mng.bz/YG5N。

归根到底，我认为最重要的是选择一个能够支撑我们为客户和业务提供价值的架构。这是我们最初要开发应用的原因所在。每种架构风格都有其使用场景。没有所谓的“银弹”或者放之四海而皆准的方案。大多数与微服务相关的负面体验都是由其他问题导致的，比如糟糕的代码模块化或不匹配的组织结构。这不应该是单体和微服务之间的一场论战。

在本书中，我主要关注如何使用Spring构建云原生应用并将其以容器的形式部署到Kubernetes中。云原生应用是分布式系统，就像微服务一样。你会发现一些在微服务语境下讨论的话题，但它们实际上属于分布式系统领域，比如路由和服务发现。根据定义，云原生应用是松耦合的，这也是微服务的一个特点。

即便有一些相似之处，但很重要的一点是，我们需要明白云原生应用与微服务是不一样的。我们当然可以为云原生应用采用微服务风格。实际上，很多开发人员就是这么做的。但是，这并非必备条件。在本书中，我将会采用称为“基于服务”的架构风格。可能这并不是一个很响亮的名字，也不花哨，但对于我们的目的来讲，这已经足够了。我们会处理服务。它们的大小是随意的，可以根据不同的原则来封装逻辑。这并不重要，我们想要追求的是根据开发、组织和业务需求来设计服务。