微服务架构关键概念

微服务在创建应用程序中扮演什么角色？我们提供对微服务是什么、它们与单体结构有何不同以及在评估微服务以供采用时应考虑事项的基础理解。

微服务架构 是一种框架，它代表工作流或流程的不同部分，通常涉及业务的一个领域。例如 - 以一个零售应用程序为例，该应用程序涉及购物车、订单管理、付款、结账、产品目录、后端金融/会计集成以及客户服务支持。这些服务是解耦的，代表不同的知识领域，尽管它们确实需要相互交叉才能拥有一个功能齐全的微服务应用程序。

独立的、自主的软件开发团队管理、测试和部署这些解耦的服务，而不会影响整个系统的其余部分。这些独立但相互关联的服务的结果是一个作为更大架构运行的框架。如果实施得当，这种分隔可以通过允许团队创建自己的发布周期来提高运营灵活度，加快生产速度，并通过简化使用可重复使用工件的操作来缩短上市时间。

微服务架构与单体架构

单体是一个巨大的整体。想想澳大利亚的艾尔斯岩（它的土著名称“乌鲁鲁”的意思是“巨大的单体”）、狮身人面像或米开朗基罗的“圣母怜子像”。关键是：单体通常是庞大的结构。

从这个意义上说，单体架构是一种将整个应用程序的所有不同业务部门连接到一个共享相同代码库的单一栈中的架构。这种结构使得独立扩展任何单独的组件变得特别困难。例如，以一个发布网站为例，用户非常频繁地请求文章，但相比之下，新文章的发布频率却很低。在单体中，您无法有效地隔离和扩展文章阅读与发布。

微服务架构将分割不同的业务领域，允许独立的团队选择他们认为自己需要用于持续成功发布的技术栈。

微服务架构特点

微服务使团队能够扩展其整个应用程序并通过不需要整个栈大修的更新来更快地响应客户需求。以下是一些定义开发人员如何建立微服务的主要特点。

服务独立性和自治性

在任何公司中，每个业务部门都有与其特定应用程序相关的一套业务挑战和目标。在大多数情况下，每个开发团队都有权选择帮助他们在其限定上下文中完成工作范围的工具、技术和资源。这种架构与多语言技术栈完美匹配，因此开发人员在构建微服务应用程序时拥有充足的灵活性，以满足性能、可用性、持续发布周期和自动化测试目标。在微服务中，“领域之主”的格言尤其适用，因为每个团队都按功能细分，并最终负责他们所构建的内容。创建针对微服务应用程序中特定服务工作的模块化团队有助于加快上市时间**。**

一个成功的实践是领域驱动设计，它鼓励开发人员深入了解其领域，以便软件开发满足用户需求。在这种情况下，用户并不总是其他人类；其他相关服务也需要得到服务。虽然开发团队可能拥有很大的自主权，但它确实需要与其他开发团队无缝协作。

这些部分必须相互契合，并且需要一致的接口。许多公司实施了分散式治理，以确保软件在整个组织中保持一致性，通常在主题专家 (SME) 的帮助下，例如企业架构师。

实用建议：尽早建立容错策略

有时，大型微服务应用程序的一部分会失败。即使将松散耦合的功能部署为多个微服务，保持通信畅通也很重要。如果单个微服务失败，微服务架构需要在代码级别实现一种回退行为来解决此中断。否则，“小”故障会导致多米诺骨牌效应，影响所有其他微服务。

故障可能由许多原因引起，从不可用的服务器到无法访问的数据库。幸运的是，有一些方法可以规避这些挑战。其中包括：复制实例、在请求上添加超时以及使用库，这些库使用容错设计模式来增强微服务应用程序的弹性。无论哪种方式，在设计微服务时都要假设事情会在最糟糕的时间发生故障 - 理想情况下，只发生一个组件故障。

实用建议：保持领域松散耦合

根据康威定律，由计算机科学家梅尔文·爱德华·康威提出，“任何设计系统的组织（广泛定义）都会产生一个设计，其结构是该组织的通信结构的副本。”期望您的堆栈反映您的公司组织方式，并将此因素纳入您的设计流程中。

特别是，尽最大努力使微服务架构中的系统尽可能松散耦合。您不希望对一个元素的设计、实现或行为的更改导致对另一个元素的更改。对一个微服务进行更改以强制对所有直接或间接与其协作的其他微服务进行几乎立即的更改是一个坏主意。

如果多个微服务是在组织级别发生的严重依赖关系下构建的，那么领域将失去其自主性，进而失去生成自己的发布周期的能力。重要的是要取得适当的平衡。

通过 API 和消息进行通信

单体架构和微服务架构之间的服务间通信方法大不相同。组件在单体应用程序中难以独立扩展，并且高度耦合。微服务是松散耦合的，它们可以使用不同的服务间通信机制来交换信息，例如 REST API 或某种类型的消息队列系统。

单体架构已经拥有所有协同工作的组件，可能有一个或两个主要数据库。每个微服务都有自己的实例，它们不一定共享相同的数据存储；这是领域驱动设计和多语言持久化的部分 - 您可以为每个微服务选择合适的数据存储。

微服务使用同步或异步通信，这意味着组件等待回复（同步）或不等待回复（异步）。同步通信场景的一个示例是用于验证登录和密码的身份验证服务；该服务需要响应才能允许用户进入基于微服务的应用程序。

另一方面，异步通信不受时间限制，发送服务不需要其他服务(s)的回复。例如，在电子商务中，当客户结账时，您希望他们继续他们的一天。他们不需要等待您处理订单、接收付款并最终完成订单。所有这些都是异步完成的，客户通过通知（应用内推送通知、电子邮件或订单状态页面）了解进度。

实用建议：API 设计和服务注册

通常，您可以使用消息代理来实现服务之间的异步通信，但重要的是要使用一个不会增加系统复杂性和可能延迟的代理（如果消息增长时无法扩展）。

版本 您的 API：持续记录您对每个服务的属性和更改。 “无论您使用 REST API、gRPC、消息传递……” Sylvia Fronczak 为 OpsLevel 撰写，“架构会发生变化，您需要为这种变化做好准备。” 一个典型的模式是将 API（应用程序编程接口）版本嵌入到您的数据/架构中，并逐步弃用旧的 数据模型。例如，对于您的服务产品信息，请求者可以请求特定版本，该版本也会在返回的数据中显示。

少闲聊，多性能：同步通信在服务之间产生大量来回。如果确实需要同步通信，这对于少量微服务来说效果还不错，但当数十甚至数百个微服务同时运行时，同步通信会让扩展陷入停滞。执行微服务审核以确定哪些地方需要同步通信，哪些地方不需要。异步方法（例如使用消息代理）将有助于减少依赖关系，提高整体容错性并缓解性能迟缓。

记录每个更改（并保持整洁）：服务注册表是一个清单，记录所有可用实例的位置（例如，通过 IP 地址）。IP 地址是无形的——它们可以以极快的速度变化，从一分钟到下一分钟——因此要记录系统及其更改。

更坚定地内置安全性

单体应用程序只有几个入口点，《微服务安全实战》的作者 Prabath Siriwardena 和 Nuwan Dias 指出。但使用微服务架构编写的应用程序则提供了更多入口点。“随着进入系统的入口点数量增加，攻击面也会扩大，”他们写道。“这种情况是为微服务构建安全设计的基本挑战之一。每个微服务的每个入口点都必须以同等强度进行保护。系统的安全性不强于其最薄弱环节的强度。”

编写安全代码对于最简单的应用程序都很重要，但在微服务架构中更是如此。攻击面越广，攻击风险越高。

与单体应用程序不同，每个部署的微服务都必须执行独立的安全筛选——这会影响性能，这本书的作者指出。

实用建议：实施安全参数，

在受控环境中测试：一个 沙箱 是一个安全且受控的环境，开发人员可以在其中测试其代码，然后再投入生产。这在安全测试中也起着作用，并帮助您发现服务之间连接中的故障。

使用 Kubernetes 部署？使用操作员：Kubernetes 是部署容器化应用程序和启动更多微服务实例的热门选择，但可能需要 DevOps 进行大量配置才能正确部署和保护。为特定软件组件（例如数据库）提供三级 Kubernetes 操作员 可以帮助自动化和保护部署。即使 Kubernetes Secrets（有助于将敏感信息与应用程序的代码分开）也以未加密的方式存储在 API 的数据存储中，任何有权在同一命名空间中创建 pod 的人都可以轻松访问。

接下来呢？

希望以上内容可以作为理解微服务基本概念的入门指南。我们介绍了微服务架构与单体应用程序的不同之处、软件开发团队在两种模型下的通信方式以及微服务为开发人员提供的自主权和通过适当的 API 设计实践来加强数据的最佳实践。

如果您不熟悉微服务架构，请阅读我们的 5 种微服务误解 文章，帮助您避开应用程序开发中最常见的微服务陷阱。