golang，java架构必学-微服务架构

这篇文章适合谁看

希望您阅读这篇文档之前，开发过简单的微服务（不限制编程语言），并且用容器部署过微服务，这有助于您理解这篇文档，相信您读完后一定会有所收获，对微服务有新的理解。这是一个系列文章，更新时间不定

分布式系统的演进

要求计算机更具备人的特质一直是许多创新背后的驱动力。在计算的早期，一台大型计算机执行一组批处理作业以在学术机构解决某个数学问题。然后，大型商业公司希望拥有这些大型计算机来执行某些由人类完成需要很长时间才能完成的任务。随着电气和电子工程的进步，计算机变得越来越小，企业主希望通过使用多台计算机并行执行多个任务，而不是让一台计算机按顺序执行所有任务。改进技术对电子电路及其尺寸减小的影响导致成本降低，越来越多的组织开始使用计算机。

人们开始使用多台计算机来执行某些任务，而不是通过一台计算机完成任务，这些计算机需要连接以进行通信并共享其执行结果以完成整个任务。这就是术语分布式系统开始使用的地方。

分布式系统是位于不同联网计算机上的组件（应用程序）的集合，它们通过网络相互传递信息来沟通和协调他们的任务，以实现一个共同的目标。

在多台计算机之间分配工作负载（手头的任务）带来了前所未有的挑战。其中一些挑战如下：

• 故障处理
• 并发
• 数据安全
• 标准化数据
• 可扩展性

故障处理

两台计算机之间的通信通过网络进行。这可以是有线网络或无线网络网络。在任何一种情况下，无论电信行业的进步如何，在任何给定时间发生故障的可能性都是不可避免的。作为分布式系统的设计者，我们应该改变故障并采取必要的措施来处理这些故障。一个设计合理的分布式系统必须具备以下能力：

• 检测故障
• 掩蔽失败
• 容忍失败
• 从故障中恢复
• 冗余

并发

当多台计算机正在运行以完成一项任务时，可能会出现多台计算机试图访问某些资源（例如数据库、文件服务器和打印机）的情况。但是这些资源可能会受到限制，因为它们在给定时间内只允许一个计算机访问。在这种情况下，分布式计算机系统可能会失败并产生意想不到的结果。因此，管理分布式系统中的并发性是设计健壮系统的一个关键方面。在接下来，我们将讨论可用于解决这种并发挑战的技术，例如消息传递。

数据安全

分布式系统通过通信通道将数据从一台计算机传输到另一台计算机。这些通信渠道有时容易受到内部和外部黑客。因此，确保跨网络的数据传输是分布式系统中的一个关键挑战。诸如安全套接字层( SSL ) 之类的技术有助于提高线路级通信的安全性。在系统向外部方（例如，客户或合作伙伴）公开业务数据的情况下，这还不够。在这种情况下，应用程序应该有安全机制来保护恶意用户和系统不访问有价值的业务数据。业界已经发展出多种技术来保护应用程序数据。

其中一些如下：

• 过滤流量的防火墙和代理：通过网络策略和流量规则实现安全。
• 使用用户名和密码进行基本身份验证：使用以用户名和密码形式提供给用户的凭据保护应用程序。
• 使用 2-legged 和 3-legged OAuth 流（OAuth2、OIDC）的委托身份验证：允许应用程序使用委托身份验证代表用户访问服务。
• 双重身份验证 (2FA)：具有两个安全因素的附加安全性，例如用户名/密码和一次性密码( OTP )。
• 基于证书的身份验证（系统到系统）：保护应用程序到应用程序的通信，而无需使用证书进行用户交互。

标准化数据

在不同计算机上运行的软件组件可能使用不同的数据格式和线路级传输机制来向/从其他系统发送/接收数据。当越来越多的系统被引入时，这将成为一个重大挑战具有不同数据和传输机制的平台。因此，遵守通用标准可以更轻松地将不同系统联网，而无需做太多工作。分布式系统设计师和工程师过去提出了各种标准，例如 XML、SOAP 和 REST，这些标准在标准化系统之间的交互方面有很大帮助。然而，有相当多的基本软件系统（如 ERP 和 CRM）可以使用专有标准和格式交换数据。在这种情况下，分布式系统需要通过使用适配器或企业服务总线的技术来采用这些系统，这些技术可以代表这些系统转换通信。

可扩展性

大多数系统都是从一台或两台运行相似数量的系统和网络的计算机开始的，这不是一项艰巨的任务。但最终，这些系统变得越来越大，有时会增长到成百上千台运行类似或更多不同系统的计算机。

因此，必须在早期阶段采取必要的行动来应对可扩展性的挑战。有多种网络拓扑可用于设计整体通信架构。在大多数情况下，架构师和开发人员从最简单的点对点模型开始，最终进入网状架构或星形（集线器）架构。

总线拓扑是过去大多数分布式系统所遵循的另一种常见模式，即使在今天，也有大量系统使用这种架构。

分布式系统网络架构

从事这些初始分布式计算系统设计和实现的软件工程师和架构师已经意识到不同的用例需要不同的模式的网络。因此，他们根据自己的经验提出了一套拓扑结构。这些拓扑帮助系统工程师根据手头的问题有效地配置网络。

这些拓扑帮助工程师解决分布式计算的不同类型的现实问题。在大多数情况下，工程师和架构师从连接几个应用程序开始以点对点的方式。当应用程序的数量增加时，这将成为一个复杂的点对点连接网络。这些模型很容易开始，但是当节点数量超过一定限制时，它们就更难管理了。在传统的 IT 组织中，人们会避免改变，除非它很关键或接近盈亏平衡点。这种保留的心态使许多企业 IT 系统落入网状或全连接拓扑的范畴，这两种拓扑都难以扩展和管理。

网状拓扑

面向服务架构（SOA）和企业服务总线（ESB）的时代

设计和实施这些系统的 IT 专业人员意识到了这一挑战，并试图寻找替代方法来构建复杂的分布式系统。通过这样做，他们确定具有明确职责和服务分离的总线拓扑可以解决此问题。那是面向服务的架构( SOA ) 与集中式企业服务总线( ESB)一起流行起来。

基于 SOA 的方法帮助 IT 专业人员构建具有明确定义的接口的应用程序（服务），这些接口抽象了内部实现细节，因此这些应用程序的使用者只需通过接口进行集成。这种方法减少了应用程序的紧密耦合，最终形成了一个复杂的网格拓扑结构，变化很大。

基于 SOA 的方法允许应用程序开发人员更改他们的内部实现更自由，只要他们遵守接口定义。由于各种业务需求，引入了集中式服务总线 (ESB) 以将企业中存在的各种应用程序联网。以下该图描绘了具有总线拓扑的企业架构

如上图所示，这种架构在大多数用例中运行良好，它允许工程师和架构师降低整个系统的复杂性，同时加入越来越多的业务增长所需的系统。这种方法的一个挑战是越来越复杂的逻辑和负载由集中式 ESB 组件处理，并且它成为故障的中心点，除非您以高可用性部署它。对于这种架构，这是不可避免的，IT 专业人员也意识到了这一挑战。

按需扩展

随着敏捷开发方法的引入、基于容器的部署以及云平台的普及，这种基于 ESB 的架构看起来已经过时，人们正在寻找更好的方法来从这些新开发中获益。这是 IT 专业人员发现这种方法面临的主要挑战的时候。其中一些如下：

• 扩展 ESB需要同时扩展 ESB 中实现的所有服务。
• 管理部署很困难，因为更改一项服务可能会影响许多其他服务。
• ESB 方法不适用于敏捷开发模型和基于容器的平台。

大多数人意识到，采用 ESB 风格的分布式系统网络拓扑无法获得计算世界技术进步所带来的好处。这一挑战不仅与 ESB 有关，而且与许多应用程序有关它们的开发方式是将越来越多的功能内置到同一个应用程序中。术语单体应用被用来描述这样的应用程序。

微服务和容器

正是在这个时候，一群名为Digital Native的公司不知从何而来，统治了整个世界。商业和 IT 世界。一些流行的例子是谷歌、Facebook、亚马逊、Netflix、Twitter 和优步。这些公司变得如此庞大，以至于它们无法使用任何现有模型来支持其 IT 需求规模。他们开始以基础设施需求和应用交付需求为主要动机进行创新。因此，出现了两种技术：

• 基于容器的部署
• 微服务架构

这两项创新齐头并进，以解决上述公司需求增加的问题。这些创新后来帮助了各种规模的组织，因为它们带来了许多优势。我们将在接下更详细地探讨这些主题。

基于容器的部署

任何应用程序在分布式系统上运行需要计算能力来执行其分配的任务。最初，所有应用程序都在物理计算机（或服务器）上运行，该计算机具有包含相关运行时组件（例如 JDK）的操作系统。这种方法一直很有效，直到人们想在同一台计算机（或服务器）上运行不同的操作系统。这就是虚拟化平台进入画面和用户的时候能够在同一台计算机上运行多个不同的操作系统，而不会混淆在每个操作系统上运行的程序。这种方法被称为虚拟机，或VM。

它允许用户在同一台计算机上独立运行不同类型的程序，类似于在不同计算机上运行的程序。尽管这种方法提供了程序和运行时的明确分离，但它也消耗了额外的资源来运行操作系统。

为了解决这个问题，引入了容器技术。容器是软件包的标准单元，它捆绑运行特定应用程序所需的所有代码和依赖项。与虚拟机类似，容器不是在客户操作系统上运行，而是在计算机（或服务器）的同一主机操作系统上运行。这个概念随着 Docker Engine 的引入而得到普及，它是2013 年的开源项目。它利用了 Linux 操作系统中现有的概念，例如cgroups和namespaces。和虚拟机的主要是， Docker是使用主机操作系统而不是客户操作系统。

什么是微服务架构？

当工程师决定从大型单体应用程序迁移到 SOA 时，他们心中有几个目标来实现新模型。其中一些如下：

• 松耦合
• 独立性（部署、扩展、更新）
• 标准接口
• 服务发现和可重用性

尽管这些目标中的大多数是通过当时可用的技术实现的，但大多数基于 SOA 的系统最终成为运行在重型服务器或虚拟机上的大型单体应用程序的集合。当容器、领域驱动设计、自动化和虚拟化云基础设施等现代技术进步变得流行时，这些基于 SOA 的系统无法获得相同的好处。

出于这个原因以及其他一些原因，例如可扩展性、可管理性和稳健性，工程师们探索了一种改进的架构，可以满足这些现代企业的需求。企业架构师没有寻求具有大量重大更改的全新解决方案，而是将微服务架构确定为分布式系统设计的演变。尽管没有一个被普遍接受的特定定义，但微服务架构的核心概念可以这样描述：

“微服务架构是指使用一组小型自治服务（微服务）构建的分布式计算架构，这些服务作为一个有凝聚力的单元来解决一个或多个业务问题。”

前面的定义探讨了用于构建应用程序的软件架构。让我们将此定义扩展为两个主要部分。

微服务很小，做好一件事

微服务不是做很多事情，而是专注于做好一件事和一件事。这并不一定意味着它应该用少于 100 行代码或类似的东西来编写。代码行数取决于许多因素，例如选择的编程语言、库的使用以及手头任务的复杂性。但是在这个定义中有一点很清楚，那就是微服务的范围仅限于一项特定的任务。这就像医疗保健系统中的患者注册或银行系统中的帐户创建。我们可以通过将这些单独的功能任务划分为独立的微服务，在微服务架构中设计这些应用程序，而不是将整个系统设计为一个大型单体应用程序，例如医疗保健应用程序或银行应用程序。

微服务是自治的并充当有凝聚力的单元

这是微服务架构的特点，它解决了大多数人面临的挑战。面向服务的架构。与微服务相比，您需要拥有完全自治的服务，而不是紧密耦合的服务，这些服务可以执行以下操作：

• 开发
• 部署
• 扩展
• 管理
• 监控

这使得微服务能够相互独立地适应现代技术进步，例如敏捷开发、基于容器的部署和自动化，并比以往更频繁地满足业务需求。

该特性的第二部分是整个平台的内聚性，每个微服务在其中交互与其他微服务和具有良好定义的标准化接口的外部客户端一起使用，例如应用程序编程接口( API )，它隐藏了内部实现细节。

微服务架构的特点

• 通过服务组件化
• 每个服务都有一个基于业务功能确定的范围
• 分散治理
• 分散数据管理
• Smart endpoints and dumb pipes
• 基础设施自动化
• 基于容器的部署
• 为失败而设计
• 敏捷开发方法
• 不断发展的架构

让我们详细讨论这些特征。

通过服务组件化

将大型单体应用程序分解为单独的服务是 SOA 的成功特性之一，它允许工程师灵活地构建模块化软件系统。同样的概念在微服务架构中得到了更多关注。它不是停留在应用程序的模块化上，而是敦促这些应用程序的自主性通过引入领域驱动设计、去中心化治理和数据管理等概念来提供服务。

这使应用程序更加健壮。在这里，一个组件（服务）的故障不一定会关闭整个应用程序，因为这些组件是独立部署和管理的。同时，向一个特定组件添加新功能要容易得多，因为它不需要部署整个应用程序并测试其每一个功能。

每个服务的业务领域驱动范围

模块化架构不是微服务引入的。相反，它一直是工程师构建复杂和分布式系统的方式。挑战在于确定这些组件的范围或调整其大小。在微服务之前的架构中，没有关于组件大小的定义或限制。但是微服务特别关注每个服务的范围和大小。

一个微服务完成的工作量应该足够小，以便可以独立构建、部署和管理。这是大多数人在采用微服务时都在努力的领域，因为他们认为这是他们第一次就应该做的事情。但现实情况是，您在项目上工作得越多，就越能更好地定义给定微服务的范围。

分散治理

微服务不是让一个团队管理和定义要使用的语言、工具和库，而是允许各个团队选择适合其范围或用例的最佳工具。这通常被称为多语言编程模型，其中不同的微服务团队为各自的服务使用不同的编程语言、数据库和库。然而，它并不止于此——它甚至允许每个团队拥有自己的软件开发生命周期和发布模型，这样他们就不必等到团队之外的人批准他们。这不一定意味着这些团队不与组织中经验丰富的架构师和技术主管打交道。他们将在联调期间成为团队的一员

分散数据管理

有时，人们倾向于认为微服务风格只适用于无状态应用程序，他们回避了数据管理的问题。但在现实世界中，大多数应用程序都需要将数据存储在持久存储中，而管理这些数据是应用程序的一个关键方面设计。在单体应用程序中，大多数情况下，所有内容都存储在单个数据库中，跨组件共享数据是通过内存中的函数调用或共享相同的数据库或表来实现的。这种方法不适合微服务架构，它带来了许多挑战，例如：

• 一个组件处理数据的故障可能导致整个应用程序失败。
• 确定失败的根本原因是很困难的。（因为一份数据被多个微服务调用，难以确定是哪个微服务引起的失败）

微服务架构建议使用特定于每个微服务的数据库的方法，以便它可以保持微服务的状态。在微服务需要在它们之间共享数据的情况下，为公共数据访问创建一个单独的微服务，并使用该服务来访问公共数据库。这种方法解决了前面提到的两个问题。

Smart endpoints and dumb pipes

单体架构和微服务架构之间的主要区别之一是每个组件（或服务）相互通信的方式。在单体应用中，通信通过内存中的函数调用进行，开发人员可以在程序中实现这些组件之间的任何类型的互连，而无需担心故障和复杂性。但在微服务架构中，这种通信发生在网络上，工程师没有单体设计中的自由度。

鉴于微服务方法的性质，服务的数量可以迅速从几十到几百到几千增长。这意味着使用网状拓扑进行服务间通信会使整个架构变得超级复杂。因此，建议使用智能端点（即每一个微服务足够智能，不以耦合的方式调用其他服务）和笨管道（可以理解为消息队列）的概念，其中集中式消息代理（消息队列）用于跨微服务进行通信。每个微服务都足够智能，只需联系中央消息代理即可与与其相关的任何其他服务进行通信；它不需要知道其他服务的存在。这将发送方和接收方解耦并显着简化了架构。（这种方式仁者见仁，智者见智）

基础设施自动化

架构提供的自治通过自动化基础设施成为现实托管微服务。这使团队能够快速创新并将产品发布到生产中，而对应用程序的影响最小。随着基础架构即服务( IaaS ) 提供商的日益普及，部署服务变得比以往任何时候都容易。代码开发、审查测试和部署可以通过持续集成/持续部署( CI/CD ) 流水线和当今可用的工具实现自动化。

基于容器的部署

采用容器作为将软件打包为可独立部署的单元的机制提供了微服务架构所需的动力。容器针对虚拟机提供的改进（不依赖主机，而是独立的环境），将单一应用程序分解为多个服务的概念成为现实。这允许这些服务在相同的基础架构中运行（因为同一个镜像启动的容器环境相同），同时为微服务提供便利。

微服务架构创建了许多小型服务，这些服务需要一种机制来运行这些服务，而无需额外的计算资源。虚拟机的方法不足以构建高效的基于微服务的平台。容器为微服务提供了所需级别的进程隔离和资源利用。如果没有容器，微服务架构就不会如此成功。

为失败而设计

（指的是微服务的开发人员应该提前想好如何处理失败）

一旦一体化的单体应用程序被分解为单独的微服务并部署到单独的运行时，主要的挫折是通信网络和分布式系统的不可避免的性质，即组件故障。随着我们在微服务团队中看到的自治水平，失败的可能性更高。

微服务架构并没有试图避免这种情况。相反，它接受了这个不可避免的事实，并为失败设计了架构。这允许应用程序更加健壮并为失败做好准备，而不是在出现问题时崩溃。每个微服务都应该处理自身内部的故障，并且需要在每个微服务级别实现常见的故障处理概念，例如重试、挂起和熔断。

敏捷开发

微服务架构不仅需要改变软件架构，还需要改变组织文化。传统的软件开发模型（如瀑布方法）与微服务开发风格不匹配。这是因为微服务架构需要小团队和频繁的软件发布，而不是花费数月时间来交付具有许多不同层次和官僚主义的软件。相反，微服务架构采用更加以产品为中心的方法，其中每个团队由具有多个学科的人员组成，这些人员在产品发布的特定阶段是必需的。

不断发展的架构

到目前为止，我们讨论的概念或特征对于成功的微服务实现来说绝不是一成不变的。这些概念会随着时间的推移而发展，人们会发现新的问题，并提出更好的方法来解决微服务架构试图解决的一些问题。因此，重要的是要了解技术领域是一个不断发展的领域，而微服务架构不是例外。

将单体分解为微服务

让我们通过将单体应用程序分解为一组微服务来尝试通过一个实际示例来理解微服务架构的概念。我们将使用医疗保健来演示。

假设我们正在为一家医院构建一个 IT 系统，以提高医院向社区提供的医疗服务的效率。在典型的医院中，存在许多单位，并且每个单元都有一个或多个特定功能。让我们从一个特定的单位开始，即门诊部(outward patient department)，简写为OPD。在 OPD 部分中，执行几个主要功能来为人们提供服务：

• 患者登记
• 病人检查
• 临时治疗
• 释放患者

我们将从医院的一个单位开始，最终使用微服务构建一个完整的医疗保健系统。鉴于只有四个主要功能，医院的 IT 团队开发了一个涵盖所有这些不同功能单元的 Web 应用程序。当前的设计是一个简单的 Web 应用程序，有四个不同的网页，每个网页都包含一个表单，通过简单的登录来更新在每个阶段捕获的详细信息。在此系统中拥有帐户的任何人都可以查看所有四个页面的详细信息。

如图所示，OPD Web 应用程序托管在 Web 服务器中，它使用中央数据库服务器来保存数据。该系统运行良好，该系统的用户是给定用户名和密码以访问系统。只有获得授权的人才能访问 Web 应用程序，它托管在医院内的物理计算基础设施中。

让我们尝试确定这种将应用程序构建为单个单元或整体的方法的挑战： 添加新功能和改进现有功能是一项繁琐的任务，需要总共重新启动应用程序，可能会导致停机。

• 一个功能的失败可能导致整个应用程序无用。
• 如果某个特定功能需要更多资源，则需要对整个应用程序进行缩放（垂直或水平）。
• 与其他系统集成很困难，因为大多数功能逻辑都是进入同一个服务。
• 它包含变得复杂且难以管理的大型代码库。

由于这些挑战，系统的整体效率变得很低，并且有机会为更多患者提供新服务（新需求到来）变得更加困难。相反，让我们尝试将这个单体应用程序分解为小型微服务。

微服务架构通常需要改变组织的 IT 文化，以及软件架构和工具。大多数组织遵循构建软件产品的瀑布方法。它遵循顺序方法，其中序列中的每个步骤都依赖于前一步。这些步骤包括设计、实施、测试、部署和支持。这种模型不适用于微服务架构，它需要一个由来自这些不同内部团队的人员组成的团队，并且可以作为一个单元以敏捷的方式发布每个微服务。

瀑布模型的挑战，例如：

• 更长的产品发布周期
• 抵制变革导致缺乏频繁创新
• 团队之间的摩擦会导致发布延迟、功能缺失和产品质量低下
• 更高的失败和不确定性风险

这种组织文化不适合要求高、创新驱动的平台。因此，在开始微服务式开发之前，有必要减少这些界限并组建真正敏捷的团队。有时，可能很难完全消除这些界限开始。但随着时间的推移，个人和管理层将意识到敏捷方法的优势。

敏捷开发：

提供一个基本可用的系统，不断迭代。

在现有设计中，使用一个通用数据库在不同功能之间共享数据。在微服务架构中，每个微服务都有自己的数据存储是有意义的，如果需要跨服务共享数据，服务可以使用消息传递或具有该公共数据存储的单独微服务，而不是直接访问共享数据存储。我们可以将应用程序分解为单独的微服务，如下图所示：

如果您觉得上图太复杂，建议您关注我，读完这个系列。您将意识到这种架构的优点超越它带来的复杂性。正如我们所见，OPD Web 应用程序被划分为一组独立的微服务，这些微服务充当一个内聚单元，为消费者提供必要的功能。以下是我们对应用程序架构所做的主要更改的列表：

• 每个功能都实现为一个单独的微服务
• 每个微服务都有一个数据存储
• 引入消息代理用于服务间通信
• Web 界面设计为单页应用程序

让我们更详细地探讨这些变化，以便我们了解带来的优点。

业务功能实现为单独的微服务

在Eric Evans的《领域驱动设计》一书中，他通过许多实际示例解释了在决定每个微服务的边界时要遵循的方法。同时，他重申这并不简单，需要一些实践才能达到更高的效率水平。在 OPD 示例中，这有点简单，因为现有应用程序在表示层（网页）具有一定级别的功能隔离，尽管这没有反映在实现中。如上图所示，我们已经确定了要为 OPD 应用程序实现的六种不同的微服务。每个服务都有明确定义的功能范围，如下所述：

• 注册微服务：该服务负责捕获细节访问 OPD 单元的患者的身份，并为之前未访问过的患者生成一个唯一 ID。如果患者已经在系统中，则更新他们的访问详细信息并将他们标记为要检查的患者。
• 检查微服务：注册完成后，患者被引导到检查单元，医疗人员在那里检查患者，更新检查结果的详细信息，并就下一步采取的措施提出建议。下一步可能涉及临时治疗，将患者从病房出院并将他们转移到病房，或让患者服用药物。
• 临时治疗微服务：如果医务人员建议进行临时治疗，患者将被收治到本单元并提供所需的药物将会给予。该服务将根据患者 ID 和频率获取提供的药物。一定时间后，医务人员将再次对患者进行检查，由医务人员决定下一步。
• 出院微服务：一旦医务人员对患者做出最终裁决，他们将从 OPD 单位出院到长期治疗单位（病房）或他们的家中。该服务将捕获患者的详细信息状态以及在患者被送回家时需要提供的任何治疗。
• 身份验证微服务：该微服务被实现为基于用户和角色为应用程序提供身份验证和授权，以及保护宝贵的患者详细信息免遭未经授权的访问。该服务将存储用户凭据及其角色，并根据用户授予对相关微服务的访问权限。
• 通用数据微服务：由于整个 OPD 单元作为单个单元作用于给定的普通患者，每个微服务必须更新一个通用数据存储以满足需求，例如向外部公开摘要应用程序。拥有这种通用微服务可以通过提供与每个微服务接口不同的单独接口来帮助实现这种功能，而不是将每个服务暴露给外部应用程序。

一旦定义了微服务边界，实施就可以遵循一种敏捷方法，根据资源的可用性同时实施一个或多个微服务。一旦定义了接口，团队就不需要等到另一个服务完全实现。资源可以在团队之间轮换，具体取决于它们的可用性。更多细节在后面提及。

每个微服务都有一个数据存储

基于微服务的方法与我们在前几节中讨论的单体方法之间的主要区别之一是数据的处理方式。在单体方法中，有一个中央数据存储（数据库），用于存储与 OPD 单元的每个部分相关的数据。

每当需要数据共享时，应用程序直接使用数据库，不同的函数访问同一个数据库（同一个表），没有任何控制。这种做法可能会导致数据由于某个功能的实现错误而损坏，并且所有功能都因此而失败的情况。同时，由于应用程序的多个组件访问同一个数据库或表，因此很难找到根本原因。当应用程序在数据库上的负载较高时，这种设计会导致更多的问题，其中应用程序的所有部分都由于一个特定功能的性能而受到影响。

由于这些原因和许多其他原因，微服务架构建议遵循每个微服务都有一个数据存储的方法。同时，如果需要跨多个微服务共享一个公共数据库，建议有一个单独的微服务来包装数据库并提供受控访问。如果需要在微服务之间共享数据，这将通过消息的服务间通信机制来完成。我们后面将讨论如何部署这些本地数据存储，以及微服务

用于服务间通信的消息代理

在单体方法中，每个函数都在同一个应用程序运行时（例如，Java 的 JVM）中运行，并且每当需要在函数之间进行通信时，它使用内存调用，例如方法调用或函数调用。这更加可靠和快速，因为一切都发生在同一台计算机内。

微服务架构遵循不同的服务间通信方法，因为每个微服务都运行在不同的运行时环境中。此外，这些运行时环境可以在不同的联网计算机上运行。许多方法可用于服务间通信。对于这个初步介绍，我们将使用基于消息代理的方法。我们后面会更详细地讨论它。

我们发现网状拓扑会使整个系统架构复杂化，并使系统更难维护。因此，我们建议使用基于消息代理的方法进行服务间通信。这种方法的优点如下：

• 降低复杂度
• 解耦
• 支持同步和异步通信
• 更容易维护
• 以较低的复杂性支持架构的增长

为简单起见，上图仅描述了几个微服务。最终实现的微服务将更加复杂。

微服务架构的优势

微服务架构提供了许多优势。这些优势大多与技术格局的演变有关。以下列表指出了微服务架构的优势：

• 能够构建强大的应用程序
• 支持现代企业的可扩展性需求
• 更好地利用计算资源
• 通过缩短上市时间和频繁发布来帮助创新
• 构建易于支持和维护的系统

微服务架构还有其他几个优点，但我们将从上述列表开始，并在后面进行更多探索。

构建健壮、有弹性的应用程序

分布式系统的挑战一直是它们的健壮性和对故障的弹性。微服务架构通过设计可以应对故障并具有明确定义范围的应用程序来帮助组织解决这个问题。快速故障和恢复的概念允许基于微服务的应用程序快速识别故障并立即修复这些问题。同时，由于组件化的架构，一个组件的故障不会导致整个应用程序瘫痪。相反，如果他们不使用该功能，它的一部分和大多数用户甚至可能不会注意到失败。这为用户提供了更好的体验。

为现代企业构建可扩展、可用的应用程序

微服务架构随着大型数字原生组织对可扩展性的需求而发展，这些组织需要运行数千个应用程序实例和数百个不同的应用程序。因此，跨平台的可扩展性和可用性更广泛的地理区域一直是微服务架构的优势。单一职责、模块化架构和分散数据管理等特性使应用程序可以跨不同的数据中心和区域进行扩展，而不会出现很多复杂情况。

更好地利用计算资源

云供应商的流行对企业软件平台产生的基础设施成本产生了巨大影响。在许多情况下，软件系统只使用了这些组织维护的整体计算基础架构的一小部分。这些原因为容器的流行铺平了道路，而微服务则遵循了容器开辟的道路。

微服务允许将应用程序分解为独立的单元。每个单位都可以决定其运作所需的资源。容器允许每个微服务定义所需的资源级别，并且总的来说，它提供了一种机制来以比以前的单体应用程序驱动模型更好的方式利用计算资源。

有助于创新驱动的组织文化

现代商业组织由创新驱动，因此拥有支持这种文化的软件架构有助于这些组织脱颖而出。微服务架构允许团队通过选择适合特定业务需求的最佳技术和方法来频繁创新和发布。这促使其他团队也进行创新，并在 IT 组织内创建创新驱动的文化。

构建可管理的系统

单体系统很脆弱，此类应用程序的故障可能导致整个组织暂停其运营。由于每个微服务和个人在不同团队中轮换的定义范围很小，微服务驱动的应用程序对整个团队变得更加开放，而没有一个团队有权控制系统。

概括

我们讨论了分布式系统的概念，以及分布式系统的发展如何为微服务架构铺平道路，帮助组织使用分布式系统概念构建健壮的应用程序。我们讨论了微服务架构的关键特征，并通过一个将整体医疗保健应用程序分解为一组微服务的实际示例确定了它的优势。本章帮助您识别企业软件平台中存在的挑战，以及如何利用微服务架构原则应对这些挑战。您在本章学到的概念可用于为大中型企业构建可扩展、可管理的软件产品。

在下一章，我们将深入了解构建微服务架构的细节。我们将重点关注跨服务通信的重要方面与消息传递技术。后面的章节有一定难度，更新时间不定