解决方案架构手册第三版（二）

原文：annas-archive.org/md5/767f6c16a82c581ed50af87f92c3fe8f

译者：飞龙

协议：CC BY-NC-SA 4.0

第五章：5

云原生架构设计模式

在数字化转型快速发展的时代，企业越来越多地转向云平台，提供可扩展、具备弹性且具成本效益的解决方案。采用云原生架构正成为寻求敏捷性、创新和运营效率的组织的战略必需。本章将引导您设计和实施云原生架构的旅程，重点介绍架构模式、设计和最佳实践。

本章将全面介绍各种云原生设计模式，包括设计原则和实际案例。除了架构设计模式外，您还将学习云原生架构设计中的反模式，帮助您了解应避免的做法。

本章将涵盖以下主题。

• 什么是云原生架构？

• 构建无服务器架构

• 构建无状态与有状态的架构设计

• 创建微服务架构

• 响应式架构

• 构建基于队列的架构

• 管道与过滤器架构

• 创建事件驱动架构

• 前端后端（BFF）

• 云原生架构反模式

到本章结束时，您将对云原生架构模式有一个坚实的理解，并能够设计、构建和优化您的云原生解决方案。

什么是云原生架构？

在第三章，云迁移与混合云架构设计中，您介绍了云迁移的不同策略，包括提升与迁移、重新平台化、重新购买、淘汰等。为了充分利用云的优势和定价模型，采用云原生架构至关重要。云原生架构指的是一种构建和运行应用程序的设计方法，旨在最大化利用云计算的优势和能力。它涉及将应用程序设计为在动态云环境中高效、可扩展且具有弹性。

云原生应用程序是基于利用云服务、自动化和现代开发实践的原则进行开发的。云原生架构的关键特点包括：

• 微服务：云原生应用程序通常由较小、松耦合的服务组成，这些服务被称为微服务。每个微服务处理一个特定的业务能力，可以独立开发、部署和扩展。

• 无服务器计算：云原生应用通常利用无服务器计算来实现无缝扩展和成本降低。这种方法使开发者能够专注于代码和应用逻辑，而无需担心管理服务器，从而实现自动扩展和高效的资源使用，显著降低运营成本。无服务器架构将应用程序及其依赖项打包，确保在不同环境中的一致性，便于无缝部署、扩展和应用的可移植性。

• 弹性和可扩展性：云原生应用能够根据需求进行上下扩展，实现高效的资源利用和成本节省。这是通过自动扩展和负载均衡来实现的。

• 弹性和容错性：云原生应用被设计为具备容错能力。它们采用冗余、自动恢复和容错机制等实践，确保即使在发生故障时也能持续运行。

• 自动化：云原生架构强调自动化，包括部署、扩展、监控和恢复等过程。自动化减少了人工干预，提高了效率，并降低了人为错误的风险。

• DevOps 实践：云原生开发鼓励开发与运维团队的紧密合作，促进持续集成、持续交付和快速迭代的文化。

• 无状态性：云原生应用设计为无状态，即每个组件不依赖于服务器的本地状态。这增强了可扩展性，并便于水平扩展。

• API 优先：API（应用程序编程接口）在云原生架构中至关重要。应用程序设计时会提供清晰且文档化的 API，促进微服务之间的通信，并促进与其他服务的集成。

• 持续监控和改进：云原生应用会持续监控，以确保最佳性能和可靠性。通过数据驱动的洞察来识别需要改进和优化的领域。

在将应用迁移到云端时，不仅仅是将它们原封不动地搬移。相反，这是一个优化并充分利用云端特性以获得最大优势的机会。首先，云端的按需付费模式是一个变革性的因素。意味着你只需为实际使用的资源付费，成本直接与实际消耗挂钩。这提供了弹性和成本效率，因为你可以根据需求进行上下扩展，而无需投资固定基础设施。仔细规划资源配置非常重要，以避免过度配置和不必要的成本。

云计算中可用的全球基础设施是另一个重要的优势。你可以将应用部署在更接近用户的不同地区，从而减少延迟并改善用户体验。这种全球覆盖使你能够在不投资全球物理数据中心的情况下，服务更广泛的用户群体。

从资本支出（CapEx）到运营支出（OpEx）的转变是云计算中的一个重要财务优势。与前期的硬件和维护投资不同，费用在时间上得以分摊。这更符合预算规划，并允许你更高效地分配资源。然而，在分布式团队和应用的背景下，成本管理成为一大挑战。必须在不同团队之间建立有效的成本控制措施。

云原生架构使得组织能够充分利用云计算的优势，包括可扩展性、灵活性和成本效益。考虑一个媒体流应用的例子，以突出云原生架构与无服务器方法相比于传统本地架构的区别和优势。

在云原生架构中，媒体流应用通过微服务和无服务器计算来设计。应用的不同部分，如用户认证、内容推荐、视频编码和存储，分别作为独立的微服务开发。这些微服务被封装在无服务器函数中，使其能够响应特定的事件或触发条件。例如，当新视频上传时，可以自动调用视频编码功能，而内容推荐功能可以响应用户互动。托管的云服务负责数据库、存储、认证，甚至无服务器函数的执行。

在传统本地架构中，媒体流应用托管在公司的服务器和基础设施上。单体应用处理所有任务，包括认证、内容提供和视频处理。扩展需要人工干预和额外的硬件采购。

在采用云原生开发时，需要注意潜在的服务提供商锁定问题。这意味着，使用特定云服务提供商的原生工具和服务（如 AWS）设计架构时，由于每个平台的服务具有独特的专有性质，可能无法顺利迁移到另一个提供商。不同平台上的服务名称可能不同，调用这些服务的方法也可能存在显著差异。虽然云原生功能为优化特定平台上的操作提供了强大的能力，但如果你后来决定迁移到其他云服务提供商，可能会带来一些挑战。仔细考虑利用这些先进功能与保持一定程度平台独立性之间的平衡。

采用云原生架构和无服务器方法，相较于传统的本地部署方式，具有许多优势。微服务和无服务器计算的结合使得应用能够在确保弹性和实时响应用户动态需求的同时，提供卓越的性能、可扩展性、成本效益和快速创新。

让我们更详细地了解无服务器架构。

构建无服务器架构

在传统的场景中，如果你想开发一个应用程序，你需要有一台服务器来安装你所需的操作系统和软件。在编写代码时，你需要确保服务器正常运行。在部署过程中，你需要添加更多的服务器以应对用户需求，并添加自动扩展等机制，来管理所需的服务器数量以满足用户请求。在这种情况下，大量精力投入到基础设施管理和维护上，这与您的业务问题无关。

无服务器意味着不需要服务器来托管你的代码，从而免除了自动扩展和解耦的开销，同时提供了一种低成本的模式。采用无服务器架构使你能够专注于应用，编写功能实现的代码，而无需担心底层基础设施的维护。

在 AWS 中，提到无服务器，首先想到的是 AWS Lambda 函数，这是 AWS 云提供的函数即服务（FaaS）。为了使您的应用成为面向服务的架构，Amazon API Gateway 提供了将 RESTful 接口放置在 AWS Lambda 函数前端的能力，帮助您将其作为微服务暴露。Amazon DynamoDB 提供了一个高度可扩展的 NoSQL 数据库，一个完全无服务器的 NoSQL 数据存储，而 Amazon 简单存储服务（S3）提供无服务器的对象数据存储。

让我们看一个在 AWS 上交付安全调查的无服务器架构示例，见下图：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_01.png

图 5.1：AWS 无服务器架构示例——安全调查交付

上述图示展示了用于客户调查应用的安全无服务器架构的流程，该应用托管在 AWS 上：

1. 客户发起对调查网站的安全 HTTPS 请求。静态网页，包括用于 AJAX 调用的任何客户端脚本，将直接从配置为网页托管的 Amazon S3 存储桶中提供。

2. 完成调查后，客户提交他们的回答。这触发了客户端浏览器向 Amazon API Gateway 发起 AJAX 调用。API Gateway 被配置为暴露接收调查数据所需的接口，并且进行了安全配置，确保只有授权的调用被处理。

3. Amazon API Gateway 与 AWS CloudTrail 内建集成，后者会记录所有对 API 的请求。这意味着每个调查提交都会被记录下来，提供一条审计跟踪，便于排查丢失数据或调查可疑活动。

4. API Gateway 将传入的 AJAX 调用转换为触发 AWS Lambda 函数的事件。这个无服务器函数负责处理调查数据，可能包括验证、转换以及应用与调查要求相关的业务逻辑。

5. 在处理完数据后，Lambda 函数会将调查结果安全地发送到另一个专门用于存储这些提交内容的 Amazon S3 存储桶。结果通过服务器端加密进行加密，确保静态数据受到保护，防止未经授权的访问。

6. 除了加密的调查结果，任何非敏感的元数据（不包括个人身份信息）会同时存储在 Amazon DynamoDB 表中。这些元数据可能包括时间戳、调查版本信息或其他与未来查询、报告或分析相关的上下文数据。

由于无服务器架构的日益流行，随着本书的进展，您将看到更多使用无服务器服务的示例架构。现在，AWS SAM（无服务器应用模型）提供了简洁的语法，用于创建函数、API 和专门为无服务器环境量身定制的数据库。让我们深入了解无服务器架构的设计考虑因素。

无服务器架构的考虑事项

在构建无服务器架构时，必须考虑一些关键因素，以确保应用程序的成功部署和运行。无服务器架构非常适合将应用拆分为更多模块化组件的设计。当你可以将应用程序分解为独立可扩展的服务时，这种方法尤其有效。然而，如果你的项目需要在一个单一的、庞大的模块中构建复杂的逻辑，那么选择传统的基于服务器的架构可能更为有利。

尽管无服务器架构提供了诸多好处，但通常会面临冷启动的问题，这可能影响应用启动的延迟。虽然对用户而言，基础设施看似是无服务器的，但像 AWS 这样的云服务商通过在后台创建一个抽象层来运营，根据需要动态启动服务器。这一过程有时可能需要一些时间，导致在函数空闲后被调用时出现延迟——即“冷启动”。在设计无服务器架构时，必须关注冷启动问题，并实施相应的策略来缓解这一问题，确保应用保持响应迅速并高效运行。

让我们通过一个例子来探讨：为社交媒体平台开发一个实时通知系统。系统必须在用户收到点赞、评论或新好友请求时，立即向他们的设备发送通知。以下是我们为通知系统设计无服务器架构时需要考虑的一些关键因素：

• 精细化函数设计：将应用程序逻辑分解为小而独立的函数。每个函数应执行特定任务或处理特定事件。这种精细化设计确保了资源的高效利用和更好的可扩展性。你可以为发送点赞、评论和好友请求设计独立的函数。

• 无状态性：无服务器函数设计为无状态的。任何需要的状态应该由外部管理，例如在数据库或存储服务中。这确保了函数可以扩展，并且在不影响应用程序行为的情况下轻松替换。确保每个函数都是无状态的，并且不依赖于本地内存。所有必要的数据，例如用户偏好或通知历史，应该存储在数据库中。

• 事件驱动设计：无服务器架构非常适合事件驱动型应用程序。设计你的函数以响应特定事件触发，例如用户操作或数据变化。例如，当用户收到新的好友请求时，应触发相应的函数。

• 冷启动：无服务器函数在首次调用时可能会出现延迟，称为“冷启动”。这可能会延迟通知的发送，因此架构设计应尽量减少冷启动的影响，例如通过使用预配置的并发性来保持一定数量的函数实例处于“热”状态，随时准备处理传入的请求。

• 可扩展性：无服务器平台会根据需求自动扩展函数。这使得应用程序能够处理突发流量峰值而无需人工干预。随着用户活动的增加，系统能够处理更多的通知，而无需人工干预。

• 性能考虑：了解无服务器平台的限制，例如执行时间限制和内存约束。优化你的函数性能，确保你的通知系统在高流量期间依然能保持响应。

• 分布式追踪和监控：实现监控和分布式追踪，以便了解无服务器函数的性能。这对于识别瓶颈和诊断通知传送问题至关重要。

• 安全性：为无服务器应用程序实施安全最佳实践，避免未经授权访问通知。这包括适当的身份验证、授权以及数据在静态和传输过程中的加密。

• 成本管理：虽然无服务器架构可以节省成本，但监控使用情况和费用至关重要。设置预算提醒并使用云服务提供商的工具分析支出模式。采用无服务器架构时，您为执行时间付费，因此优化代码以减少执行时间，并考虑使用成本分析工具来监控使用情况。

• 数据存储和持久化：为您的数据选择适当的存储解决方案，例如托管数据库、对象存储或数据仓库。确保在函数调用之间的数据持久性。对于我们的通知系统，我们将把用户偏好和通知历史存储在托管数据库中，确保数据在函数调用之间的持久性。

• 依赖关系：在编写函数时，要注意依赖关系。包含不必要的库或组件会增加部署包的大小，并影响性能。尽量减少依赖，以保持函数部署包小巧高效。

• 测试和调试：为您的无服务器函数开发有效的测试策略。使用云服务提供商提供的本地模拟器和调试工具。

• 利用托管服务：无服务器架构并不意味着每个组件都必须是一个函数。可以使用托管服务来处理应用架构中的其他部分，例如数据库、队列和认证。

• 合规性和法规：考虑与您的应用程序相关的合规性或监管要求，特别是在处理敏感数据或涉及严格监管的行业时。确保架构符合数据保护法规，特别是在处理个人信息时。

通过仔细处理这些注意事项，您可以创建一个架构良好的无服务器应用程序，充分利用自动扩展、成本效益和简化的管理。无服务器架构确保了可扩展性、成本效益和响应迅速的通知交付，而无需担心管理基础设施。

在开发无服务器架构时，强调无状态性至关重要。通过设计无状态应用程序，您减少了对服务器管理会话状态的依赖，从而有助于扩展性。无状态架构是扩展云原生架构的关键。让我们更深入了解它。

构建无状态和有状态的架构设计

无状态和有状态架构设计代表了在软件应用程序中管理客户端-服务器交互的两种不同方法。无状态架构将每个客户端请求视为一个独立的、单独的事务，不需要了解之前的交互；这简化了设计并增强了可扩展性，因为任何服务器都可以响应任何请求，无需维持会话信息。另一方面，有状态架构在多个请求之间保留客户端会话信息，允许进行更个性化和上下文感知的交互，但需要在管理会话数据时付出更高的复杂性代价，并且在扩展时面临挑战，因为状态必须在服务器实例之间始终可用并保持同步。

在设计复杂的应用程序（如电子商务网站）时，你需要处理用户状态以保持活动流程，用户可能会执行一系列活动，例如将商品添加到购物车、下单、选择配送方式和进行支付。用户可以通过各种渠道访问应用程序，因此很可能会在设备之间切换——例如，从手机上将商品添加到购物车，然后从笔记本电脑上完成结账和支付。为应对这种情况，你应该在不同设备之间保持用户活动的持久化，并保持其状态直到交易完成。因此，你的架构设计和应用程序实现必须规划用户会话管理，以满足这一需求。

为了保持用户状态并使应用程序无状态，用户会话信息需要存储在持久化的数据库层中，例如 NoSQL 数据库。这些用户状态可以在多个 Web 服务器或微服务之间共享。

传统上，单体应用程序使用有状态架构，将用户会话信息存储在服务器中，而不是通过任何外部持久化数据库存储。

无状态和有状态应用程序设计的关键区别在于它们如何处理会话存储。在有状态应用程序中，会话信息存储在服务器本地，这意味着它不能轻易地与其他服务器共享。这种设置对扩展性构成挑战，并且不太适合现代微服务架构，因为它要求所有后续请求都必须路由到处理第一个请求的原始服务器。这会大大限制应用程序在多个服务器或实例之间扩展的能力。另一方面，无状态设计不在服务器上存储会话数据，使得任何服务器都可以处理任何请求，这增强了应用程序的可扩展性和灵活性。是否采用无状态或有状态方法，取决于应用程序的需求，特别是在扩展性需求和持续个性化用户体验之间如何平衡。

有状态架构

在有状态应用程序中，状态信息由服务器处理，因此一旦用户与特定服务器建立连接，他们必须坚持使用该服务器直到事务完成。你可以在有状态应用程序前放置负载均衡器，但要做到这一点，你必须在负载均衡器中启用粘性会话。

粘性会话是一种确保来自特定用户会话的所有请求都被定向到处理初始请求的相同服务器的技术。在有状态应用程序中，这种方法是必要的，以保持会话一致性，因为它可以防止在随后的请求被路由到不同的服务器时丢失会话数据。通过使用粘性会话，负载均衡器偏离了其通常通过轮询方法将请求均匀分配到各个服务器的标准做法，而是将用户的请求路由到其会话信息所在的特定服务器。尽管这种方法支持会话持久性，但它也带来了挑战，例如可能因过多的持久连接而导致单个服务器超载。为了解决这个问题，实施会话超时机制变得至关重要，确保会话不会无限期地占用服务器资源。

通常，有状态应用程序不支持良好的水平扩展，因为应用程序的状态保留在服务器中，无法替换。当用户基数较小时，有状态应用程序表现良好。然而，随着互联网的普及，合理的假设是，你将在一个 Web 应用程序中拥有数百万活跃用户。因此，高效的水平扩展对于处理大量用户并实现低延迟应用程序至关重要。

无状态架构

使用无状态方法时，你的设计方法应该更多地关注共享会话状态，因为它允许水平扩展。

以下图表展示了一个无状态应用程序架构，适用于一个使用 AWS 的示例 Web 应用程序：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_02.png图 5.2：无状态应用程序架构

所示的 AWS 架构为跨两个可用区的三层应用程序提供了一个安全、高可用和可扩展的环境，以实现容错。它使用弹性负载均衡将流量分配到 EC2 服务器集群，这些集群通过自动扩展动态调整以满足变化的需求。由 Amazon RDS 支持的数据库层包括一个用于查询扩展的只读副本和一个用于故障转移的备用实例，确保数据持久性和高可用性。静态内容通过 Amazon S3 提供，并通过 Amazon CloudFront 高效传递，同时 AWS Route 53 管理 DNS 服务以优化用户流量路由。该设置确保了应用程序的运营弹性、成本效益和性能优化。为了使应用程序松散耦合并具备可扩展性，所有用户会话都持久存储在 NoSQL 数据库中，例如 Amazon DynamoDB。

对于会话 ID，你应该使用客户端存储，如 cookies。这种架构使你可以通过增加更多服务器来水平扩展应用程序，而无需担心丢失用户状态信息。无状态架构消除了创建和维护用户会话的开销，并允许应用程序各模块之间的一致性。无状态应用程序还具有性能优势，因为它减少了服务器端的内存使用，并消除了会话超时问题。

实现无状态架构涉及一些复杂性，例如集成额外的数据库组件来存储用户会话，以及创建一个附加层以便在服务器间检索正确的用户会话。然而，通过正确的方法，你可以为用户群体创造出一个有益的体验。你可以使用微服务方法结合 REST 设计模式来开发应用程序，并将其部署在容器中。为此，使用身份验证和授权来将用户连接到服务器。

在接下来的章节中，你将学习更多关于微服务和 REST 设计模式的知识。由于从多个 Web 服务器访问用户会话信息时，重点是单一的数据存储位置，因此必须小心，以防止数据存储的性能成为瓶颈。

创建微服务架构

在云原生架构中，微服务在将庞大的功能拆分为可以独立扩展的更小模块方面发挥着至关重要的作用。这种方法使得可以根据需要扩展或缩减特定组件，而不会影响整个系统。通过使用微服务，系统设计时会考虑到故障容忍性，意味着系统是基于潜在故障构建的，从而可以优雅地降低应用程序的可用性，并防止广泛的系统故障。

微服务的明显优势在于你只需维护较小的代码面。微服务应该始终是独立的。你可以构建每个服务时没有外部依赖，所有的前提条件都包含在内，这减少了应用模块之间的相互依赖，实现松耦合。

微服务的另一个核心概念是界限上下文，它们是构成单一业务领域的模块。一个业务领域可以是零售、汽车制造、书籍销售，或者涉及完整业务流程的社交网络互动。每个微服务定义了一个边界，所有细节都在其中封装。例如，我们考虑一个电商平台。在这样的系统中，你将有几个微服务处理业务的不同方面。以下是平台中的一些界限上下文：

1. 用户账户上下文：这个微服务处理与用户账户相关的所有事务，包括用户注册、个人资料管理、登录和认证。它的边界涵盖了用户信息和可以在这些数据上执行的操作，例如更新个人资料或重置密码。其他微服务不会管理这些操作。

2. 产品目录上下文：这个微服务负责管理产品列表、类别和产品详情。它独立于用户账户上下文操作，专注于产品、它们的组织以及如何向用户展示这些信息。

3. 订单处理上下文：这个微服务处理结账流程、订单跟踪和支付处理。它使用来自产品目录上下文（例如，产品 ID、价格）和用户账户上下文（例如，客户详情）中的信息来完成其功能，但保持独立操作，例如更新订单状态或处理退货。

每个界限上下文都是一个自包含的系统，具有自己的领域逻辑和数据库，通过明确定义的 API 与其他上下文进行通信。这些边界使得每个微服务可以独立开发、部署、扩展和更新，从而使整体系统更具韧性和适应变化的能力。

通过定义这些边界，电商平台可以确保一个上下文中的更改，例如在订单处理上下文中添加新的支付方式，不会影响用户账户或产品目录上下文，从而使系统更加可维护和可扩展。

在处理大规模访问应用时，扩展每个服务是至关重要的，因为不同的工作负载有不同的扩展需求。

让我们来学习一些设计微服务架构的最佳实践：

• 创建独立的数据存储：为每个微服务采用独立的数据存储，允许各个团队为他们的服务选择最合适的数据库。例如，网站流量团队可以使用可扩展的 NoSQL 数据库来存储半结构化数据。处理订单服务的团队可以使用关系数据库，以确保数据完整性和事务一致性。这还帮助实现松耦合，即一个数据库的变更不会影响其他服务。

• 保持服务器无状态：正如你在上一节构建无状态和有状态架构设计中学到的，保持服务器无状态有助于扩展。服务器应该能够轻松关闭并被替换，最小化或不需要在服务器上存储状态。

• 创建独立的构建：为每个微服务创建独立的构建，可以让开发团队更容易地引入新的变更，提高新功能发布的敏捷性。这有助于确保开发团队只为特定的微服务构建所需的代码，而不会影响其他服务。

• 容器化部署：在容器中进行部署可以为你提供一种标准化的工具，用相同的方式部署所有内容。使用容器，你可以选择以相同的方式部署所有微服务，而不论它们的性质如何。你可以使用像亚马逊 Fargate 这样的无服务器容器部署服务来管理你的容器，而无需担心基础设施。

• 无服务器架构：当你的微服务足够简单时，尝试使用无服务器平台或具有服务功能的函数，例如 AWS Lambda。无服务器架构可以帮助你避免基础设施管理的开销。

• 蓝绿部署：对于应用部署，最佳方法是创建一个生产环境的副本。部署新功能并将少量用户流量路由到新环境中，以确保新功能在新环境中按预期工作。之后，逐步增加新环境中的流量，直到整个用户群体都能看到新功能。在第十一章，DevOps 与解决方案架构框架中，你将学习更多关于蓝绿部署的内容。

• 监控你的环境：良好的监控是反应故障和通过适当的重新路由、扩展和管理降级来主动防止故障之间的区别。为了防止应用停机，你需要服务提供并将它们的健康状态推送到监控层，因为没有什么比服务本身更了解状态。监控可以通过多种方式进行，例如使用插件或通过写入监控 API。

尽管微服务架构具有多种优点，但模块化方法也带来了管理更多基础设施的开销。你必须仔细选择工具来帮助你管理并扩展多个模块的并行运行。在设计微服务架构时，尽可能使用无服务器平台，这将有助于减轻基础设施和运营的开销。接下来，让我们看看一个基于微服务的实时投票应用架构示例。

在下面的图示中，我们展示了一种使用微服务的实时投票应用设计。该应用通过多个小的、独立的服务来处理和统计用户的投票。当用户通过手机设备投票时，应用会记录每一票，然后将所有投票存入一个 NoSQL 数据库，Amazon DynamoDB。

在 AWS Lambda 函数中包含了应用逻辑，用来聚合所有用户投给他们最喜欢演员的投票数据，并返回最终结果：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_03.png

图 5.3：基于微服务的实时投票应用架构（使用 AWS）

在前面的架构中，发生了以下事情：

1. 用户向第三方提供的电话号码或短代码发送文本投票，例如 Twilio。

2. 第三方被配置为将消息内容发送到由 Amazon API Gateway 创建的端点，后者将响应转发到在 AWS Lambda 中构建的函数。

3. 这个函数从消息内容中提取投票，并将结果及相关元数据写入 Amazon DynamoDB 中的表。

4. 这个表启用了 DynamoDB Streams，它会跟踪表格上的变化，持续进行更新。

5. 更新后，DynamoDB Streams 通知第二个 AWS Lambda 函数，其中包含聚合投票（每秒）的应用逻辑，并将其写回到另一个 DynamoDB 表。第二个表仅存储每个类别的投票总数。

6. 用 HTML 和 JavaScript 创建了一个仪表盘，用于显示投票汇总，并作为静态网站托管在 Amazon S3 中。此页面使用 AWS JavaScript SDK 查询聚合后的 Amazon DynamoDB 表，并实时显示投票结果。

7. 最后，Amazon Route 53 是一个 DNS 提供商，用于创建指向 Amazon S3 存储桶中的自定义域名的托管区域。这使得你能够以成本效益高的无服务器方式在 S3 存储桶中托管静态网站。

这种架构不仅是基于微服务的，而且是无服务器的。通过使用微服务，你可以创建由小的独立组件组成的应用，这些组件作为更小的部分进行迭代。基于微服务的架构意味着成本、规模和变更风险都得到了降低，从而提高了变更的速度。

如果你的系统是使用微服务进行分布式的，协调多个服务变得至关重要。接下来，让我们学习如何编排多个微服务。

Saga 模式

Saga 模式是一种设计模式，用于管理长期运行的复杂业务事务。它在微服务架构中非常有用，因为单一的业务事务可能涉及多个微服务。与传统的两阶段提交不同，Saga 模式将事务分解成多个较小、独立的事务。每个微服务处理这些较小的事务，并协调它们以确保跨服务的数据一致性。如果某个小事务失败，将执行补偿事务以撤销之前的步骤。

在需要多个服务协同完成单一操作的复杂系统中，如处理订单或预订航班，Saga 模式有助于确保如果在任何环节出现问题，整个操作要么完全完成，要么回滚。

以下是 Saga 模式的工作原理：

• 分解：需要执行的操作被分解成更小的、独立的步骤或事务。每个步骤对应一个由特定微服务执行的操作。

• 补偿操作：对于每个步骤，都会定义一个相应的补偿操作。如果某个步骤失败或发生错误，补偿操作会被执行以撤销之前步骤的效果。这样，系统会恢复到一致状态。

• 协调者：协调者负责协调步骤的顺序及其相应的补偿操作。它启动 Saga，监控其进度，并确保所有步骤完成或采取必要的补偿操作。

• 本地事务：每个步骤及其补偿操作都封装在各自微服务中的本地事务内。这保证了每个微服务内操作的原子性。

• 最终一致性：Saga 模式支持最终一致性，这意味着即使发生故障，系统最终也会通过成功完成整个操作或回滚到一致状态来达到一致性。

想象一个电子商务应用，客户下了一个订单。Saga 模式可以用于处理整个订单处理流程：

1. 启动：订单服务为订单处理启动一个新的 Saga。

2. 步骤：Saga 包括多个由不同微服务执行的步骤：检查产品可用性、向客户收费、更新库存并通知客户等。

3. 补偿操作：定义相应的补偿操作，例如，如果物品缺货：释放已收取的金额、重新进货并向客户发送道歉邮件。

4. 协调者：协调者负责监督 Saga，确保每个步骤都成功执行或得到补偿。例如，步骤包括检查产品是否有货、下订单、向客户收费并完成订单配送。

5. 最终一致性：如果任何步骤失败（例如，如果客户支付失败），则触发补偿操作，使系统回到一致的状态。

每个参与 Saga 的服务都会生成和监听事件，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_04.png

图 5.4：电商应用架构的 Saga 模式顺序图

如前图所示，当一个服务完成其事务部分时，它会生成一个事件，触发 Saga 中的下一个服务。例如：

1. 订单服务接收到创建订单的请求。

2. 订单服务通过创建一个待处理状态的订单并发布订单创建事件来启动 Saga。

3. 支付服务监听订单创建事件，处理支付，并发布支付处理事件。

4. 库存服务监听支付处理事件，验证商品是否有库存，保留库存，并发布库存已保留事件。

5. 运输服务监听库存已保留事件，安排配送，并发布配送已安排事件。

6. 订单服务监听配送已安排事件，并将订单状态更新为已完成。

如果任何服务未能完成其事务部分，它会发布一个补偿事件来触发回滚前面的步骤。例如，如果库存服务发现库存不足，它可以发布库存不足事件。支付服务会监听此事件并发起退款。订单服务会监听库存不足事件并将订单状态更新为失败。

Saga 模式是一种设计方案，旨在解决分布式系统中数据一致性的问题，特别是在处理微服务时。Saga 模式并不依赖于单一的大规模事务来确保不同服务之间的数据一致性，而是将事务拆分为每个服务的一系列本地事务。每个本地事务更新数据库并发布事件或消息，指示事务的成功或失败。然而，Saga 模式引入了最终一致性的概念，这意味着系统的状态会随着时间的推移变得一致，但不一定是立即的。此外，实施 Saga 模式可能会很复杂，因为它需要处理失败场景并确保补偿事务正确撤销先前的操作。这通常涉及复杂的协调和强大的消息系统，以管理服务之间的异步通信。

Saga 模式允许将复杂的操作分解为可管理的步骤，并提供安全网来处理故障并保持数据完整性。它通过确保系统在发生故障时仍然保持一致性并最终达到一致，提升了分布式系统的韧性。然而，实现 Saga 模式需要谨慎的设计和协调，以有效地处理各种故障场景。如果你有大量需要多个微服务处理的信息，并且需要将其整合以生成有意义的见解，怎么办？在这种情况下，fan-out/fan-in 模式可以帮助你。让我们来了解一下它。

Fan-out/fan-in 模式

Fan-out/fan-in 模式是分布式系统中常用的设计模式，用于高效地处理请求并从多个来源汇总数据。它适用于需要从不同输入流或来源收集、处理和整合数据的场景。该模式得名于数据如何从多个来源扩展（fan out），然后再汇聚（fan in）进行整合。

假设我们有一个社交媒体平台的实时分析系统。Fan-out/fan-in 模式可以应用于收集和处理来自各种用户活动的数据。让我们看看 fan-out/fan-in 模式是如何工作的：

• Fan-out 阶段：

  • 在 fan-out 阶段，数据从多个来源收集，包括不同的微服务、API 或数据流。每个来源将其数据发送到一个独立的处理组件。用户的帖子、评论、点赞、分享和关注者生成实时数据流。

  • 每个来源的处理组件独立且同时操作。这使得高效的并行处理成为可能，减少了从不同来源收集数据的时间。每种活动类型都有一个专门的处理组件，计算诸如参与率、热门内容和趋势话题等统计信息。

• Fan-in 阶段：一旦个别处理完成，来自每个处理组件的结果会被汇总或合并，在这个例子中是用来计算整体平台参与度指标。这种汇总可能涉及计算、总结或任何其他为最终结果所需的操作。汇总的数据生成所需的结果或最终报告。这可以是单一报告、总结分析或任何其他形式的整合数据。在我们的例子中，这些数据显示给管理员，作为一个实时参与度分析的仪表盘。

在这个例子中，fan-out/fan-in 模式允许分析系统高效地处理和整合来自多个用户活动的数据，为管理员提供实时的参与度见解。

Fan-out/fan-in 模式的好处

Fan-out/fan-in 模式是分布式系统中的一种战略方法，显著增强了数据的管理和处理方式。采用这种模式的主要好处如下：

• 并行性：该模式利用并行处理，允许从多个源快速收集和汇总数据。

• 效率：该模式通过并行处理多个源，而不是按顺序处理每个源，优化了处理时间。

• 可扩展性：每个源可以独立处理，使得系统能够随着源数量的增加而高效扩展。

• 模块化：该模式通过将数据收集（fan-out）阶段与汇总（fan-in）阶段分离，鼓励模块化设计。这使得系统更易于维护和扩展。

虽然 fan-out/fan-in 模式在分布式系统中对并行处理和提高效率有利，但它也带来了需要谨慎应对的具体挑战。实现这一模式增加了复杂性，因为它要求对多个并行任务及其后续汇总进行精确协调。错误处理变得更加复杂，因为系统必须考虑到任何 fan-out 任务中的潜在失败，并确保具备强大的恢复机制，以维持数据一致性。

该模式也可能会消耗大量资源，因为它可能需要大量的计算能力来管理并行处理，这可能导致更高的运营成本，并需要先进的扩展策略。此外，汇总阶段可能成为瓶颈，尤其是当处理大量数据时，这可能会延迟整体数据处理进度。此外，该系统可能只能实现最终一致性，这对于需要实时处理的应用程序构成挑战。最后，该模式的分布式特性使得调试和监控变得复杂，需要全面的工具来确保跨所有任务的可视性。尽管存在这些挑战，但通过精心设计和管理，fan-out/fan-in 模式依然是提高分布式架构中数据处理效率的有效策略。

总体而言，fan-out/fan-in 模式对于在分布式系统中管理和处理来自各种源的数据非常有价值，它实现了高效的并行处理和简化的汇总。

增加微服务的数量需要精心的协调，这就是服务网格发挥作用的地方。让我们进一步了解它。

服务网格模式

在现代软件开发中，微服务已成为构建灵活且可扩展应用程序的首选方法。然而，随着微服务数量的增加，管理它们的通信和可靠性可能变得比穿越繁忙的道路交叉口还要复杂。这时，服务网格的概念就应运而生，它简化了微服务之间的通信，同时增强了它们的稳健性。

想象你处在一个繁忙的城市交叉口，那里有多条车道。每辆车代表一个微服务，执行特定的任务。为了确保交通顺畅，防止发生碰撞，交通信号灯、标志和道路规则是必不可少的。同样，服务网格就像微服务的交通指挥员，调节它们的互动，确保它们协调工作。

服务网格是基础设施的一层，管理云应用中不同服务之间的通信。它确保这些服务之间的可靠消息传递。开发者可以专注于核心应用程序编程，而服务网格则负责系统基础设施中的网络和安全工作。

以下图示展示了以 AWS 服务为例的服务网格基础设施。

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_05.png

图 5.5：AWS 云中服务网格模式架构

让我们逐步了解服务网格图中展示的每个步骤：

1. EC2 服务 A：表示运行服务（服务 A）的 Amazon EC2 实例。EC2 实例提供可扩展的计算能力，运行在Amazon Web Services（AWS）云中。

2. 调用服务 B：服务 A 发起对服务 B的调用。这是服务间通信过程的开始。

3. 通信：此模块表示通信层，其中捕获服务 A 的请求并通过服务网格路由。

4. 通过 App Mesh：来自服务 A 的请求通过 AWS App Mesh，该服务网格提供应用级网络功能。App Mesh 标准化了服务之间的通信方式，提供端到端可见性，并确保应用的高可用性。

5. 路由到服务 B：AWS App Mesh 将请求路由到适当的服务，本例中为服务 B。

6. ECS 服务 B：表示运行服务 B 的 Amazon Elastic Container Service（ECS）任务。ECS 是一个高度可扩展、高性能的容器管理服务，支持 Docker 容器。

7. 调用服务 C：在服务 B 完成处理后，它调用服务 C。这可能是涉及多个微服务的大型事务的一部分。

8. 路由到服务 C：同样，AWS App Mesh 将来自服务 B 的调用路由到服务 C。

9. Lambda 服务 C：表示服务 C 的 AWS Lambda 函数。AWS Lambda 让你无需配置或管理服务器就可以运行代码。它仅在需要时执行代码，并自动扩展。

该架构抽象了服务网格中服务间复杂的相互作用，展示了 AWS App Mesh 在管理、路由和控制不同服务之间通信中的作用。

以下是服务网格提供的主要功能：

• 流量管理：服务网格通过丰富的路由规则、重试、故障转移和故障注入提供对流量行为的详细控制。

• 可观察性：它们通过可视化、追踪、监控和日志记录服务之间的流量，为你提供深入的应用洞察。

• 安全性：服务网格提供自动化的双向 TLS（mTLS）流量加密，确保服务之间的安全通信。

• 策略执行：它们允许你在所有服务中一致地定义和执行策略，无论这些服务运行在哪里。

• 弹性：服务网格支持先进的负载均衡、超时和重试功能，帮助你构建更具弹性的应用。

实现服务网格的一种流行方式是使用 sidecar 代理。每个微服务应用中的服务实例都配有一个 sidecar 代理，处理所有进出该服务的网络通信。所有这些代理通过网络连接成网格，因此得名“服务网格”。

服务网格正成为现代云原生应用架构中不可或缺的一部分，提供多种根据不同需求和环境量身定制的实现方式。在最受欢迎的服务网格实现中，包括：

• Istio：这款全面的服务网格解决方案为在微服务架构中控制服务间通信提供了强大的方式。它允许开发者定义详细的路由规则和策略，实施诸如重试和断路器等弹性模式，并收集应用流量的洞察。Istio 的政策执行和度量收集能力有助于保护和监控服务间的通信，从而提高网络的可靠性和性能。

• Linkerd：以专注于简洁性和性能而闻名，Linkerd 是一个开源服务网格，提供关键特性，如服务发现、路由、故障处理和对现代应用架构的可视化。它被设计为轻量级且易于安装，具有最小的资源占用，因此对于希望在不增加大量开销的情况下采用服务网格技术的团队来说，是一个有吸引力的选择。

• AWS App Mesh：专为 AWS 用户设计，App Mesh 是一种托管的服务网格服务，使得管理和控制 AWS 服务之间的微服务通信变得更加简单。它支持应用级网络，使应用服务能够在网络上进行通信，并提供更多的可见性和控制。AWS App Mesh 简化了服务通信的配置，提供了应用级的洞察力，并确保应用的高可用性。

• Consul Connect：作为 HashiCorp Consul 的一部分，Consul Connect 专注于通过自动 TLS 加密和基于身份的授权来保障服务间的通信安全。它旨在平台无关，提供一种一致的、统一的方法来保障和配置跨服务的通信，无论底层平台如何。Consul Connect 强调安全性，确保只有经过授权的服务才能相互通信，从而减少内部威胁的风险。

尽管服务网格为微服务架构提供了一系列优势，如改善服务间通信、增强安全性和更好的可观察性，但在引入服务网格时，必须考虑它对基础设施带来的复杂性。引入服务网格意味着需要管理、监控和维护额外的组件，这可能会增加团队的运维负担。这一额外的基础设施层要求进行精心规划、配备专业人员进行管理，并且需要明确了解其对系统性能和复杂性的影响。因此，在决定实施服务网格之前，评估应用的具体需求，并权衡其优势与基础设施复杂度的潜在增加是非常重要的。这种谨慎的方法确保了采用服务网格的好处能够与应用的需求和团队应对额外复杂性的能力相匹配。

AWS App Mesh 是一项规范化服务间通信的服务，提供全面的监控并促进一致的可用性。以下架构图展示了使用 AWS 云服务实现服务网格模式的实现：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_06.png

图 5.6 – 由 App Mesh 在 AWS 中管理的电商应用

如前图所示，Amazon Fargate 作为无服务器容器计算引擎，兼容 Amazon 弹性容器服务（ECS）和 Amazon 弹性 Kubernetes 服务（EKS）。以下是通过 App Mesh 实现电商应用的步骤：

1. 创建 Fargate 服务：将每个微服务（用户、订单、支付、产品目录和认证）定义为一个在 EKS 上的 Amazon Fargate 服务，并附上所需的任务定义。

2. 设置 AWS App Mesh：创建一个作为服务之间网络流量逻辑边界的网格。

3. 定义虚拟节点：为每个 ECS 服务在 App Mesh 中创建一个虚拟节点。虚拟节点充当指向特定 ECS 服务的逻辑指针。

4. 创建虚拟路由器和路由：定义虚拟路由器和路由，以控制虚拟节点之间的流量流动。

5. 配置虚拟服务：虚拟服务将流量路由到虚拟节点，从而实现网格内服务的发现。

6. 部署边车代理：将 Envoy 代理附加到每个 ECS 任务定义中，作为边车容器。Envoy 代理拦截并管理微服务之间的流量。

7. 监控与日志记录：使用 AWS CloudWatch 和 AWS X-Ray 监控和记录流经服务网格的流量。

实施服务网格可以增强服务间的通信、安全性和可观察性。这种方法使得您能够更高效、更有效地管理微服务架构，为复杂应用程序提供一个强大且可扩展的解决方案。从故障中恢复是构建大规模架构的一个重要方面。让我们了解反应式架构来解决这个问题。

反应式架构

由于云原生架构可能由于多个微服务和小模块而包含多个动态部分，因此它们需要防止故障。反应式架构是一种构建能够高效应对变化并在各种条件下保持响应性的设计方法。它有利于需要保持高可用性和响应性的、大规模和分布式系统，即使在面临故障或高需求时。

反应式架构的原则基于反应式宣言，这是一份概述反应式系统核心特征的文档：响应式、弹性、可扩展和消息驱动。您可以通过访问www.reactivemanifesto.org/了解反应式宣言的详细信息：

• 响应式：反应式系统优先考虑响应性，确保无论系统的负载或状态如何，都能及时响应用户请求。

• 弹性：反应式系统被设计为能够优雅地处理故障。即使某些组件发生故障，它们也能快速恢复并继续运行。

• 可扩展：反应式系统能够根据需求进行扩展或缩减，高效利用资源，并在不同负载下保持响应性。

• 消息驱动：在反应式系统中，组件通过异步传递的消息进行通信。这种方式使得组件可以松散连接、独立隔离，并能够从不同位置访问。

反应式架构风格高度依赖于微服务，它将功能划分为更小的、可独立扩展的服务，以提高可扩展性、可维护性和更快的部署周期。反应式系统中的通信是事件驱动的，这意味着组件通过异步事件进行交互和响应，从而更高效地利用资源并提升系统性能。

为了管理数据，响应式架构采用了去中心化的方法，每个微服务管理自己的数据，最大限度地减少对共享数据资源的依赖和争用。这不仅增强了系统的弹性，还提升了其从故障中快速恢复的能力。隔离性和自治性是响应式系统的核心，确保组件可以独立失败，而不会影响整体系统的可用性，从而增强了容错性。

可扩展性是通过横向扩展来实现的，在横向扩展中，系统通过增加更多服务实例而不是升级现有实例的容量，来应对更高的负载。

此外，响应式架构还实现了如电路断路器、超时和重试等弹性模式。这些机制帮助管理和从故障中恢复，防止单个组件的问题蔓延成系统级别的中断。综合这些原则，有助于创建更加响应用户需求、对故障具备弹性，并能在负载下优雅降级的系统。

响应式架构有利于处理需要应对不同工作负载、快速从故障中恢复并提供响应性用户体验的大规模分布式系统。

想象一个在线游戏平台，成千上万的玩家在虚拟世界中同时互动。响应式架构可以在这里应用，确保无缝且响应迅速的游戏体验：

• 响应式：系统能迅速响应玩家的操作，使得角色可以实时移动、施放法术和与物体互动。

• 弹性：如果服务器因技术故障突然崩溃，架构会自动将负载重新分配到健康的服务器上，确保其他玩家的游戏不中断。

• 弹性扩展：当更多玩家在高峰时段加入游戏时，架构会动态分配额外的服务器资源来应对增加的负载。当玩家人数减少时，多余的资源将被释放，以节省成本。

• 消息驱动：玩家的操作，例如施放法术或交易物品，是通过消息进行传递的。这种异步通信最小化了瓶颈，确保即使在大量并发操作的情况下也能顺畅的游戏体验。

要实现响应式架构，您可以采取以下步骤：

• 设计组件以使用消息队列异步通信。这可以防止阻塞并提高响应性。

• 实现 Actor 模型，其中组件（演员）通过消息进行通信。每个演员按顺序处理消息，避免了并发问题。

• 集成像电路断路器和舱壁等弹性模式，以应对故障并防止错误蔓延。你在第四章，解决方案架构设计模式中学到了这些模式。

• 利用自动扩展机制，根据负载动态分配资源。像 AWS 这样的云平台提供了相关工具。

• 利用像 Akka、Spring WebFlux 或 ReactiveX 这样的反应式库或框架，它们提供了用于构建反应式系统的抽象。

让我们探讨如何使用 AWS 服务实现反应式架构，应用于广告追踪的用例。下图展示了广告技术公司使用的反应式架构：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_07.png

图 5.7 – 广告追踪应用程序的参考架构

上图所示的架构演示了一个广告追踪应用程序，使用了 AWS 的架构来进行实时和批处理处理。

在给定的架构布局中，当用户查看或点击广告时，应用负载均衡器会捕获该请求，并将其转发到主应用程序中的相应服务。应用程序独立地、及时且稳健地处理每个请求，避免了立即写入数据库。相反，Amazon Kinesis 数据流收集这些事件，AWS Lambda 函数随后负责将信息记录到 Amazon DynamoDB 表中。Amazon Kinesis 数据流是一种高度可扩展和持久的实时数据流服务，旨在收集、处理和分析流数据。这种数据流的设置充当了一个保护性的中介，确保在高流量期间没有数据丢失。

为了优化对关键数据的访问速度，Amazon ElastiCache for Redis 充当主要缓存。核心数据更新通过消息传递架构进行同步，使用事件流来捕获并传递来自所有相关系统的变化。这种安排能够处理不同的请求量，Lambda 函数处理流数据并刷新主缓存，以确保系统的完整性和性能。

集成这些 AWS 服务使你能够为你的在线广告平台构建反应式架构。AWS 提供的服务符合反应式系统定义的核心原则——响应性、弹性、可伸缩性和基于消息的通信。松耦合架构在构建高度可扩展的云原生架构中起着关键作用，而消息队列在其中扮演着举足轻重的角色，因此让我们来学习一些基于队列的架构模式。

构建基于队列的架构

在前面的章节中，你学习了使用 RESTful 架构的微服务设计。RESTful 架构帮助你的微服务易于发现，但如果你的服务出现故障会发生什么呢？RESTful 是一种现代架构，其中客户端服务等待主机服务的响应，这意味着 HTTP 请求会阻塞 API。有时，由于下游服务不可用，你的信息可能会丢失。在这种情况下，你必须实现一些重试逻辑，以便保留你的信息。

基于队列的架构通过在服务之间添加消息队列来解决此问题，队列代表服务存储信息。基于队列的架构提供完全异步的通信和松耦合的架构。在基于队列的架构中，你的信息仍然保存在消息中。如果服务崩溃，消息将在服务恢复后立即得到处理。让我们了解一些基于队列的架构的术语：

• 消息：消息有两个部分——头部和主体。头部包含关于消息的元数据，而主体包含实际的消息内容。

• 队列：队列保存可以在需要时使用的消息。

• 生产者：一种将消息生成并发布到队列中的服务。

• 消费者：一种消耗并利用消息的服务。

• 消息代理：帮助在生产者和消费者之间收集、路由和分发消息。

让我们探索一些典型的基于队列的架构模式，了解它们的工作原理。

队列链模式

当需要在多个连接的系统上进行顺序处理时，应用队列链模式。让我们通过一个图像处理应用程序的例子来理解队列链模式。在图像处理管道中，捕捉图像并将其存储在服务器上的顺序操作、运行作业以创建不同分辨率的图像副本、为图像加水印以及生成缩略图等操作紧密相连。任何部分的故障都可能导致整个操作中断。

你可以在各种系统和作业之间使用队列，消除单点故障，并设计真正松耦合的系统。队列链模式有助于将不同的系统连接起来，并增加可以并行处理消息的服务器数量。如果没有图像需要处理，可以配置 自动扩展 来终止多余的服务器。

下图展示了我们图像处理应用程序的队列链模式架构。在这里，AWS 提供的队列称为 Amazon 简单队列服务（SQS）：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_08.png

图 5.8：队列链模式架构

前述架构包含以下步骤：

1. 当原始图像上传到服务器时，应用程序必须为所有图像添加公司的水印。一个 Amazon EC2（弹性云计算）服务器集群运行批处理作业，为所有图像加水印并将处理后的图像推送到 Amazon SQS 队列。

2. 第二批 Amazon EC2 服务器从 Amazon SQS 队列中提取带水印的图像。

3. 第二批 EC2 工作节点处理图像并创建不同分辨率的变体。

4. 在编码完图像后，EC2 工作节点将消息推送到另一个 Amazon SQS 队列，用于缩略图的创建。

5. 随着图像的处理，作业会从之前的队列中删除消息以腾出空间。

6. 最终的 EC2 服务器集群从队列中获取编码消息，并生成缩略图和版权信息。

这种架构的好处如下：

• 你可以使用松耦合的异步处理来快速返回响应，而无需等待其他服务的确认。

• 你可以通过使用 Amazon SQS 将 Amazon EC2 实例或容器松耦合来构建系统。

• 即使 Amazon EC2 实例出现故障，队列服务中的消息仍然完好无损。这对保持数据完整性和系统的健壮性至关重要，因为它确保了在服务器恢复后可以继续处理。这种设计创建了一个能够抵御和从服务器故障中恢复的强大系统，不会丢失关键数据。

你可能会遇到应用需求的波动，这可能会导致消息负载的意外增加。使用队列链模式自动化工作负载将帮助你应对任何波动。让我们深入了解如何使用任务观察者模式来处理突发的工作负载波动。

任务观察者模式

队列链模式有助于你设计一个松耦合的架构，但如何处理工作负载的峰值呢？在请求波动的情况下，你需要根据用户需求调整处理能力，而任务观察者模式可以解决这一问题。

在任务观察者模式中，你可以根据队列中的消息数量创建一个自动扩展组来处理任务。任务观察者模式帮助你通过增加或减少用于任务处理的服务器实例数量来维持性能。

下图展示了任务观察者模式：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_09.png

图 5.9：任务观察者模式架构

在前述架构中，第一批 Amazon EC2 服务器，即 AWS 的虚拟服务器，位于左侧，运行批处理任务并将消息放入队列，例如图像元数据。右侧的第二批 EC2 服务器则消费并处理这些消息，例如图像编码。当消息达到某个阈值时，Amazon CloudWatch 会触发自动扩展，在消费者集群中添加额外的服务器以加速任务处理。当队列深度低于阈值时，自动扩展还会移除额外的服务器。

任务观察者模式根据任务规模计算扩展，提供了高效性和成本节约。任务观察者模式架构允许任务快速完成。该过程具有弹性，这意味着如果服务器故障，任务处理不会停止。

虽然基于队列的架构提供了松耦合，但它主要依赖于异步拉取方法，消费者可以在消息可用时从队列中拉取消息。

在云原生架构中，通常有助于在不同的架构组件之间构建较小的独立步骤，其中一个事件触发另一个事件。为了实现这一点，我们将在下一部分详细了解管道-过滤器架构。

管道-过滤器架构

管道-过滤器架构是一种软件设计模式，它将复杂任务划分为一系列较小、独立的处理步骤或阶段。每个阶段对输入数据执行特定操作，并通过“管道”将处理过的数据传递给下一个阶段。各个阶段被称为“过滤器”，连接器则称为“管道”。让我们更详细地了解这种架构的主要组成部分：

• 过滤器：这些处理单元对数据执行特定操作。过滤器读取输入数据，处理它，并生成输出数据。每个过滤器独立工作，可以单独实现和测试。

• 管道：管道是连接器，负责在过滤器之间传输数据。它们可以是简单的数据流，也可以是更复杂的机制，如消息队列，它们提供缓冲、同步和数据格式转换。

这种架构模式的主要优点在于它是一种健壮的结构，能够促进关注点分离和模块化，使得理解、修改和维护复杂系统变得更加容易。它因其可重用性、可组合性、顺序处理和可扩展性而受到青睐。每个独立的过滤器执行离散的处理任务，可以在各种应用中复用，从而确保一致性并减少开发时间。这些过滤器的可组合性使得可以构建复杂的处理链，且通过重新排列过滤器来轻松修改。数据以清晰、顺序的方式流经管道，使得每个过滤器能够逐步地转换数据，这简化了对系统的理解和维护。此外，这种模式支持可扩展性，因为过滤器可以并行运行，并分布在多个计算节点上，从而使系统能够有效地处理日益增长的工作负载。

让我们通过一个例子来理解这一点。假设有一个文本处理管道，它读取一个文本文件，去除停用词，进行词干提取（将单词还原为根词），并统计每个单词的出现次数。这可以通过使用管道-过滤器架构来实现：

1. 过滤器 1—读取文件：读取文本文件并输出文本行

2. 过滤器 2—分词：将行分割成单独的单词

3. 过滤器 3—去除停用词：去除诸如“and”、“the”、“is”等常见词

4. 过滤器 4—词干提取：将单词还原为根词（例如，将“walking”还原为“walk”）

5. 过滤器 5—统计单词：统计每个单词的出现次数

过滤器通过管道连接，管道负责在过滤器之间传输数据。管道读取文本文件，逐步处理它，并输出单词的频率。

管道与滤镜架构是一种强大的设计模式，用于构建模块化和易于扩展的系统。架构师可以通过将复杂的任务分解为一系列较小的独立滤镜，并通过管道连接它们，来创建灵活、可维护和可扩展的应用程序。

接下来，让我们更深入了解事件驱动架构（EDA），这是一种设计范式，其中程序的流程由用户操作或其他程序发出的消息等事件决定。这些事件由独立的组件异步处理，使得系统能够对变化或工作负载的波动作出高度响应和适应。

创建事件驱动架构

当 EDA 被应用于云原生架构时，它增强了系统对实时数据和事件的响应能力。通过这种结合，可以构建出高效、可扩展的系统，能够快速应对变化。云原生环境支持动态资源分配，以处理事件驱动系统的可变负载，而 EDA 则提供了立即响应和处理的机制。

事件驱动架构（EDA）帮助你将一系列事件串联起来，以完成功能流程。例如，当你在网站上进行支付购买时，你期望在支付完成后立即生成订单发票并收到一封电子邮件。事件驱动架构帮助将这些事件连接起来，从而使支付操作能够触发其他任务以完成订单流程。通常，在讨论 EDA 时，你会看到消息队列（在前一节中已学习过）作为核心点。EDA 还可以基于发布/订阅模型或事件流模型。

发布者/订阅者模型

在发布者/订阅者（pub/sub）模型中，当事件被发布时，通知会发送给所有订阅者，每个订阅者可以根据其数据处理需求采取必要的行动。

让我们来看一个照片工作室应用的例子，它通过不同的滤镜美化照片，并向用户发送通知。以下架构描述了这个发布/订阅模型：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_10.png

图 5.10：照片工作室应用的发布/订阅事件驱动架构

在前面的图示中，你会注意到以下几点：

1. 用户首先通过 Web/移动应用将图片上传到Amazon S3存储桶。

2. Amazon S3存储桶然后向Amazon Simple Notification Service（SNS）发送通知。Amazon SNS是一个消息主题，具有以下订阅者：

   • 这里，第一个订阅者使用电子邮件服务，一旦照片上传完成，就会向用户发送电子邮件。

   • 第二个订阅者使用Amazon SQS队列，从Amazon SNS主题获取消息，并在 AWS Lambda 中编写的代码中应用各种滤镜，以提高图像质量。

   • 第三个订阅者使用直接的AWS Lambda函数，创建图像缩略图。

在这个架构中，Amazon S3 作为生产者将消息发布到 SNS 主题，多个订阅者进行消费。此外，一旦消息到达 SQS，它会触发事件，启动 Lambda 函数处理图像。

事件流模型

在事件流模型中，消费者可以从生产者那里读取连续的事件流。例如，你可以使用事件流来捕获点击流日志的持续流，并在检测到异常时发送警报，如下图所示的架构图所示：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_05_11.png

图 5.11：点击流分析事件流架构

亚马逊 Kinesis 是一项用于摄取、处理和存储持续流数据的服务。在前面的图示中，来自 Web 和移动应用程序的各种客户点击电子商务应用程序，生成一系列点击事件。

这些点击流通过Amazon API Gateway发送到分析应用程序，进行实时分析。在这个分析应用中，Amazon Kinesis Data Analytics计算转化率，例如过去五分钟内完成购买的人数。实时聚合数据后，Amazon Kinesis Data Analytics将结果发送到Amazon Kinesis Data Firehose，后者将所有数据文件存储在Amazon S3存储中，以便根据需要进一步处理。

一个 Lambda 函数从事件流中读取数据，并开始检查数据中的异常。当检测到转换率的异常时，AWS Lambda函数会通过电子邮件发送通知，提醒活动团队。在这种架构中，事件流持续发生，AWS Lambda会从流中读取特定的事件。

在 EDA 中，生产者和消费者独立操作，事件充当通信媒介。这种解耦意味着生产者可以发送事件，而无需知道哪些消费者会处理它们，消费者则可以监听自己感兴趣的事件，而无需知道是哪些生产者生成的。这导致了一个灵活且可扩展的系统，新的消费者可以在不修改现有生产者的情况下添加，以处理事件，从而促进了系统的可扩展性和适应性。然而，尽管 EDA 有诸多优点，但也存在需要解决的挑战：

• 避免重复处理：在分布式系统中，由于网络重试或服务故障，相同的事件可能会被多次发送。通过在事件消费者中实现幂等性，确保多次处理同一事件时不会导致不正确的行为或数据不一致。

• 错误消息处理：一个健壮的 EDA 必须具有有效处理错误的机制。这可以包括死信队列，用于存储无法处理的事件，供以后检查或重试；以及消费者中的错误处理逻辑，用于管理异常而不干扰整个系统。

• 事件顺序：确保事件按正确顺序处理可能至关重要。这可能涉及序列模式，或使用事件溯源（event sourcing）来维护每个实体的事件顺序。

• 事件追踪与监控：随着系统的扩展，追踪事件流动和监控系统健康状况变得至关重要。实施适当的日志记录、追踪和警报机制确保了对系统运行的可视化，并能快速诊断问题。

• 事件模式管理：随着系统的演进，事件模式可能会发生变化。管理这些变化而不破坏系统的稳定性，需要一个模式注册表和版本控制策略，以便消费者能够理解事件的不同版本。

尽管 EDA（事件驱动架构）促进了高度可扩展和可扩展的云原生架构，但它需要精心设计和操作考虑，以确保系统具备弹性、一致性和可维护性。

在讨论模块化架构时，至关重要的一点是，模块化应当贯穿所有架构层次，才能真正实现可扩展性。让我们深入探讨 BFF 设计模式，它倡导这种做法。

前端专属后台模式

BFF 模式是一种云原生架构方法，它为每种特定类型的前端应用量身定制后台服务。BFF 是一种设计模式，作为对现代网页和移动应用日益复杂化的回应而出现。它涉及为每个前端或用户体验创建独立的后台服务。通过这样做，BFF 旨在简化前端开发，并根据每个前端的独特需求优化后台响应。

以下是 BFF 模式的关键方面概述：

• 量身定制的 API：每个前端（例如网页、移动端或智能电视）都有针对其特定需求定制的后台服务（BFF）。BFF 提供的 API 仅返回前端所需的数据，并以合适的格式呈现。这种方法减少了前端的数据转换需求，从而优化了 API 响应。

• 简化的前端开发：前端开发人员可以与 BFF 密切合作，从而实现更好的协作和更快的开发周期。BFF 可以使用与前端相同的编程语言编写，这使得前端开发人员更容易理解和修改后台。

• 委派复杂性：BFF（前端专属后台）可以处理本应由前端承担的任务，例如身份验证、数据聚合和错误处理。这种复杂性的委派减少了前端的工作负担，提升了用户体验的流畅度。

• 独立演进：每个 BFF 可以独立演进，这使得在不影响其他前端的情况下推出特定前端的更新和功能变得更加容易。BFF 作为前端和核心后台服务之间的适配器，最小化了两层之间变化的影响。

让我们以一个具有网页、移动端和智能电视前端的电商应用为例：

• Web BFF：提供产品详情、用户评价和针对 Web 前端优化的推荐。聚合来自多个后端服务的数据，如产品信息、用户资料和推荐引擎。将数据转换为适合 Web 显示的格式。

• 移动 BFF：提供简化的产品视图、用户评价和针对移动设备优化的推荐。处理诸如图像调整以适应小屏幕等任务。聚合数据并根据移动前端的具体需求进行调整。

• 智能电视 BFF：提供产品信息、用户评价和针对智能电视显示优化的推荐。将数据转换为适合大屏幕和简化导航选项的格式，符合智能电视的前端需求。

通过为每个前端创建独立的 BFF，电子商务应用可以在不同平台之间提供优化的用户体验，同时简化前端开发，减少后端服务的复杂性。

BFF 设计模式对于构建现代 Web 和移动应用非常有力，它提供了量身定制的 API、简化的前端开发、委托的复杂性以及独立演进。架构师使用 BFF 来创建更加高效、响应迅速且用户友好的跨平台应用。

到目前为止，你已经了解了各种云原生架构设计模式。接下来，我们将学习一些需要避免的反模式。

云原生架构反模式

在云原生架构中，和任何系统设计一样，某些做法被视为反模式。反模式是看似有益，但通常效果不佳，甚至可能对应用造成负面影响的方法。以下是一些常见的反模式，值得在云原生架构中避免。

单点故障

单点故障是指一个组件的故障可能导致整个系统的崩溃。设计云原生架构时，要考虑冗余和故障转移机制，以优雅地处理此类故障。如果一个依赖单一数据库实例且没有备份或复制的云应用，若该数据库实例发生故障，系统可能会全面崩溃。通过实现具有复制和自动故障转移的冗余数据库配置，可以避免这一情况。

手动扩展

手动扩展涉及手动添加或移除资源以应对需求变化。这可能既耗时又容易出错，效率较低。使用无服务器服务和自动扩展功能，可以根据需求自动调整运行实例的数量。

例如，如果一个流媒体服务在一场热门事件中突然迎来大量观众，手动扩展基础设施可能无法及时跟上。使用无服务器服务或自动扩展可以让服务快速扩展资源以应对需求激增，并在需求减少时迅速缩减资源。

紧耦合服务

在微服务架构中，服务应当是松耦合的，以便独立运作。紧密耦合的服务可能会导致脆弱的系统，难以维护和发展。例如，如果一个电商平台中的支付服务和运输服务是紧密耦合的，对其中一个服务的更改可能会无意间影响到另一个服务。设计这些服务时，要明确服务边界和 API，这样它们可以独立演进。

忽视安全最佳实践

安全应当是任何云原生架构中的首要任务。忽视安全最佳实践可能会导致数据泄露、未授权访问以及其他安全事件。例如，存储用户密码明文的应用程序容易遭受数据泄露。实施适当的密码哈希、加盐和其他安全措施可以防止此类事件的发生。

没有监控或日志记录

监控和日志记录对于诊断问题、优化性能和理解系统行为是必不可少的。实施监控工具来追踪应用程序健康状态，并记录日志来诊断问题。如果云应用出现性能问题，详细的监控和日志记录可以帮助识别原因，比如网络延迟增加、资源限制或应用错误。

忽视网络延迟

网络延迟可能会影响分布式系统中的应用程序性能。设计系统时应考虑如何优雅地处理网络延迟。例如，在基于微服务的电商平台中，服务之间的网络延迟可能会拖慢用户互动，比如浏览商品或结账。实施缓存、数据复制和异步通信等技术可以缓解这些影响。

缺乏测试

适当的测试确保应用程序按预期功能运行，并有助于在问题进入生产环境前进行识别。一个处理用户数据的云原生应用应当有全面的单元测试、集成测试和端到端测试，以确保数据处理的正确性，防止数据丢失或损坏，并验证服务之间的正确集成。

过度优化

过早地对应用程序进行过度优化可能会使代码复杂且难以维护。为云应用实现一个高度优化的自定义数据结构，可能会稍微提高性能，但也会使代码变得难以理解、维护和适应未来的变化。

没有考虑成本

如果没有正确管理，云服务可能会变得非常昂贵。监控并优化云资源使用，避免产生意外的成本。例如，对于需求波动的应用程序，如果 24/7 运行大型虚拟机实例，成本将非常高。通过实现自动扩展和使用无服务器服务，可以通过根据需求调整来优化成本。

通过避免这些反模式，你可以创建一个强大、可扩展且易于维护的云原生架构。遵循最佳实践，避免这些反模式，并利用微服务方法，可以确保你的云应用程序具有可扩展性、稳健性和安全性。在持续构建和演化你的应用程序时，始终保持警惕，关注潜在挑战，并不断努力改进设计、操作和监控策略。

总结

在本章中，你全面探索了云原生架构，揭示了设计具有弹性、可扩展且高效系统所必需的基本概念、模式和实践。

你从云原生架构的本质入手，欣赏了它在现代软件开发中的变革性潜力。你了解了它的核心优势，包括可扩展性、弹性和敏捷性，这些优势使得它在当今动态的软件环境中变得不可或缺。

你深入研究了无服务器架构，发现它如何提供成本节省、无缝扩展性和简化的操作。你了解了无状态与有状态设计之间的对比和细微差别，理解了它们各自的使用场景、挑战和实施策略。你进入了微服务架构领域，掌握了它在可扩展性、容错性和部署简便性方面的固有优势。

你了解了 Saga 模式，深入探讨了它在管理长时间运行事务中的应用，并学习了其有效实现的考虑因素。你探索了 fan-out/fan-in 模式，理解了它在并行数据处理和后续聚合中的强大作用。你了解了服务网格模式，欣赏了它在去中心化服务管理、增强可观察性和流量管理方面的贡献。

你沉浸于反应式架构，掌握了它的异步和事件驱动特性，并认识到它在提升响应性和可扩展性方面的潜力。你探索了基于队列的架构，了解了它们在解耦和异步处理中的优势。你学习了排队链模式，深入了解了它在构建强大的顺序工作流中的应用和策略。

你被介绍到作业观察者模式，理解了它在高效监控和管理作业中的实用性。你发现了管道和过滤器架构，欣赏了它在处理数据流时的灵活性和可组合性。你深入研究了事件驱动架构，了解了它们在可扩展性、响应性和解耦方面的优势。你探索了发布/订阅模型，理解了它在可扩展且松散耦合的事件分发中的潜力，并深入研究了事件流模型，认识到它在处理连续事件流时的优势。

你探索了 BFF 模式，了解了它如何根据特定用户界面量身定制后端，从而提高灵活性和性能。最后，你揭示了常见的云原生架构反模式，学习如何避免这些陷阱并遵循最佳实践。

通过对云原生架构的全新理解，你将更好地设计出符合你独特需求和目标的健壮、可扩展、高效的云原生系统。

在本章中，你学习了各种架构模式，而在下一章中，你将学习针对性能优化的架构设计原则。此外，你还将深入探讨计算、存储、数据库和网络中的技术选择，这些都有助于提升你应用程序的性能。

加入我们书籍的 Discord 空间

加入本书的 Discord 工作区，向作者和其他解决方案架构专家提问并互动：packt.link/SAHandbook

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/QR_Code930022060277868125.png

第六章：6

性能考虑因素

实验表明，每一秒钟的应用加载延迟都会导致组织收入的显著损失。因此，应用的性能是解决方案设计中最关键的属性之一，它会影响产品的增长和用户的采纳。

在上一章中，我们讨论了可以用来解决复杂业务问题的各种解决方案架构设计模式。在本章中，我们将探讨一些优化应用性能的最佳实践，这些实践需要在每一层以及每个架构组件中进行。你将学习如何为架构的各个层次选择合适的技术，以持续提高应用的性能。本章将重点关注以下内容：

• 高性能架构的设计原则

• 性能优化的技术选择

• 移动应用性能考虑

• 性能测试

• 性能监控管理

到本章结束时，你将理解性能提升的几个重要属性，如延迟、吞吐量和并发性。你将能够在技术选择上做出更好的决策，帮助你提升架构各层的性能，例如计算、存储、数据库和网络。

高性能架构的设计原则

架构性能效率专注于利用应用基础设施和资源来满足日益增长的需求和技术演进。性能效率指导架构师创建不仅能满足当前需求，还能灵活扩展和发展的系统，确保在用户期望和技术环境变化时，性能保持强大和响应迅速。让我们来看看一些优化工作负载性能的关键设计原则。

降低延迟

延迟可能会显著影响你的产品采纳，因为用户都在寻找最快的应用程序。无论用户身处何地，你都需要提供高效可靠的服务，才能让产品成长。延迟是指数据包从一个指定点传输到另一个指定点所需的时间。简单来说，就是你在执行某个操作后，看到设备或系统响应时所经历的延迟或滞后。延迟受多种因素的影响，包括客户端与服务器之间的物理距离、传输介质的速度（如光纤或无线信号）以及网络的繁忙程度。

举个例子，假设你正在浏览一个网站。当你点击一个链接或按下一个按钮时，一个请求从你的设备发送到网站的服务器。这个服务器可能位于与你相同的城市，也可能位于世界的另一端。请求从你的设备传送到服务器、服务器处理该请求并返回响应的时间，就是我们所说的延迟。虽然你可能无法实现零延迟，但目标应该是让响应时间保持在用户可以接受的容忍范围内。

如下图所示，假设在一个场景中，从你的设备到服务器的消息传递需要 600 毫秒（ms）（这可能是因为数据需要跨越物理距离，或者数据包通过多个中间设备进行路由，如路由器和交换机）。如果服务器再花 900 毫秒来处理请求并返回响应，那么总的延迟将是 1.5 秒（1,500 毫秒）。在这段时间里，你可能会注意到网页加载的延迟。

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_01.png

图 6.1：客户端-服务器模型中的请求-响应延迟

现在，任何应用程序都需要访问互联网，以便拥有全球范围的多样化用户作为消费者。这些用户期望无论地理位置如何，性能都能保持一致。但这有时很具挑战性，因为数据从世界的一个地方传输到另一个地方需要时间。

各种因素，如网络传输介质、路由器跳数和传播，都可能导致网络延迟。企业通常使用光纤线路来建立公司网络与云之间的连接，这有助于防止不一致性。组织还可以利用内容分发网络（CDN）将重型图像和视频数据存储在靠近用户的位置，以减少网络延迟并提高性能。通过边缘位置，更容易将工作负载部署到靠近用户群体的地方。

除了网络引起的问题外，延迟还可能出现在各种架构组件中。由于内存和处理器问题，计算服务器可能在基础设施层面上出现延迟，其中 CPU 与 RAM 之间的数据传输较慢。磁盘也可能因读写过程缓慢而产生延迟。硬盘驱动器（HDD）的延迟取决于选择磁盘存储扇区的时间以及该扇区定位到磁头下进行读写的时间。磁盘存储扇区是数据在内存磁盘中的物理位置。在 HDD 中，数据在写入操作期间会分布到存储扇区。由于磁盘持续旋转，数据可以随机写入。在读操作中，磁头需要等待旋转将其带到相应的磁盘存储扇区。

在数据库层面，延迟可能由硬件瓶颈或查询处理缓慢导致的数据读取和写入问题引起。通过分区和分片来分布数据，可以减少数据库负载，从而降低延迟。

低延迟意味着更高的吞吐量，因为延迟与吞吐量是直接相关的，所以我们来深入了解吞吐量。

提高吞吐量

网络吞吐量是指在给定时间内成功通过网络传输的数据量。这个指标对于了解网络在特定条件和负载下的表现至关重要。吞吐量会受到多种因素的影响，包括网络的容量（带宽）、连接的质量以及用于数据传输的协议。带宽决定了网络中可以传输的最大数据量。

吞吐量和延迟之间存在直接关系。低延迟意味着高吞吐量，因为可以在更短的时间内传输更多的数据。为了更好地理解这一点，我们可以用国家的交通基础设施做个类比。

假设高速公路的车道是网络管道，汽车是数据包。假设一条高速公路在两座城市之间有 16 条车道。并非所有的车辆都能按时到达目的地，它们可能因交通拥堵、车道关闭或事故而被延误。在这里，延迟决定了汽车从一座城市到另一座城市的旅行速度，而吞吐量告诉我们有多少辆车能够到达目的地。对于网络来说，充分利用带宽是具有挑战性的，因为会有错误和交通拥堵。

网络吞吐量通过以每秒比特数（bps）计算的传输数据量来衡量。网络带宽是指网络管道的最大容量，表示可以处理的数据量。下图展示了客户端和服务器之间传输的数据量：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_02.png

图 6.2：网络中的吞吐量

除了网络，吞吐量还适用于磁盘层面。磁盘吞吐量是一个重要的指标，描述了数据从存储设备读取或写入的速度。它以每秒兆字节（MB/s）为单位进行测量，受两个主要因素的影响：每秒输入/输出操作数（IOPS）和每次 I/O 操作的大小（平均 I/O 大小）。

计算磁盘吞吐量的公式是：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_001.png

下面是公式的分解：

• 平均 I/O 大小是指每次读写操作的平均大小，单位为字节。根据工作负载的不同，这个值可能会有所不同；例如，数据库操作的 I/O 大小通常比大视频文件的流媒体操作要小。

• IOPS（每秒输入/输出操作数）衡量存储在一秒钟内能够处理多少次读写操作。较高的 IOPS 值表示存储系统速度较快，能够并行处理大量操作。

• 吞吐量（MB/s） 提供了存储设备实际数据传输速率的度量。它将 IOPS 和平均 I/O 大小结合起来，反映每秒可以从存储系统中移动多少数据。

为了将结果转换为 MB/s，我们将平均 I/O 大小和 IOPS 的乘积除以 1,024*1,024（因为 1 KB 等于 1,024 字节，1 MB 等于 1,024 KB）。

给定磁盘 IOPS 为 20,000，I/O 大小为 4 KB（即 4 * 1,024 字节 = 4,096 字节），可以按如下方式计算吞吐量：

1. 首先，将 I/O 大小从字节转换为兆字节：

   • https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_002.png

2. 然后，乘以 IOPS 以得到 MB/s 为单位的吞吐量：

   • 吞吐量 = I/O 大小（MB）× IOPS

   • 吞吐量 = 0.00390625 MB × 20,000

   • 吞吐量 = 78.125 MB/s

所以，给定磁盘 IOPS 为 20,000，I/O 大小为 4 KB，吞吐量大约为 78.125 MB/s。这个计算结果显示了在这些条件下，每秒可以从磁盘读取或写入的总数据量。

在操作系统层面，吞吐量由每秒在 CPU 和内存之间传输的数据量决定。在数据库层面，吞吐量由数据库每秒可以处理的事务数决定。在应用层面，你的代码需要通过垃圾回收和内存缓存的高效使用来管理应用内存，从而处理每秒能够处理的事务。

当你考虑延迟、吞吐量和带宽时，还有一个因素叫做并发，它适用于各种架构组件，并有助于提高应用性能。让我们来了解更多关于并发的知识。

处理并发

并发在设计可扩展和高效的应用程序中起着至关重要的作用。它允许应用程序同时执行多个任务，更好地利用系统资源，提高整体应用性能。通过实现并发，开发者可以确保应用程序能够在不等待某个任务完成后再开始另一个任务的情况下处理多个操作。这对于服务成千上万用户的 Web 应用程序以及需要高效处理大量数据的数据处理任务尤为重要。实现并发可以显著提高响应时间和吞吐量，从而增强用户体验并提升应用程序的扩展能力。

并行性是软件设计中的另一个关键概念，它通过在不同的处理器或核心上同时执行多个操作来补充并发性。虽然并发性涉及同时处理许多任务（例如，在单核 CPU 上进行多任务处理，任务快速切换，给人同时执行的假象），但并行性进一步扩展了这一概念，通过多核处理器或分布式系统真正实现同时执行多个操作。这种方法通过将工作划分为可以并行处理的小块，大大加快了计算密集型任务的处理时间。处理大型数据集、复杂计算或可以分解为独立单元的任务的应用，能从并行性中获得极大的益处，实现更高的吞吐量和效率。

如下图所示，并发就像一个交通信号灯，控制着所有四个车道之间的交通流动。由于所有交通必须经过单一的车道，其他车道的处理必须暂停，直到一个车道中的交通处于清理过程中。在并行的情况下，存在并行车道，所有车辆可以在不互相干扰的情况下并行运行，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_05.png

图 6.3：并发与并行

数据库始终是架构设计的核心。并发在数据处理中的作用至关重要，因为数据库应该具备同时响应多个请求的能力。数据库的并发性更为复杂，因为一个用户可能正在尝试读取一条记录，而另一个用户则在同时更新它。数据库应该仅在数据完全保存后允许查看数据。在另一个用户尝试更新数据之前，确保数据已经完全提交。

缓存可以显著提高性能；让我们了解一些架构中的不同缓存类型。

应用缓存

在第四章，解决方案架构设计模式中，你学到了如何在基于缓存的架构部分应用不同层级的缓存。缓存显著地帮助提升应用性能。尽管你已经学习了通过添加外部缓存引擎和技术（如内容分发网络（CDN））来应用不同的设计模式，但必须理解的是，几乎每个应用组件和基础设施都有一个缓存机制。在每一层利用缓存机制有助于减少延迟并提高应用性能。

CPU 在服务器级别有其硬件缓存，这可以减少从主内存访问数据时的延迟。CPU 缓存包括指令缓存和数据缓存；数据缓存存储频繁使用的数据副本。缓存也在磁盘级别使用，但由操作系统软件管理（称为页缓存）；然而，CPU 缓存完全由硬件管理。磁盘缓存来源于二级存储设备，如 HDD 或 固态硬盘（SSD）。频繁使用的数据会存储在主内存的空闲部分（即 RAM 中的页缓存，这样可以更快速地访问内容）。

通常，数据库有一个缓存机制，将数据库的查询结果保存起来，以便更快速地响应。它们有一个内部缓存，根据你的使用模式准备数据。它们还拥有查询缓存，如果你多次查询某些数据，这些数据会被存储在主服务器内存（RAM）中。如果表内的数据发生变化，查询缓存会被清空。如果服务器内存不足，最旧的查询结果会被删除以腾出空间。

你在网络级别有一个 DNS 缓存，将网页域名和相应的 IP 地址保存在服务器的本地。如果你再次访问相同的网站域名，DNS 缓存可以快速进行 DNS 查询。操作系统管理着 DNS 缓存，并保存所有最近访问的网站。你在第四章《解决方案架构设计模式》中了解了客户端缓存机制，如浏览器缓存，以及缓存引擎如 Memcached 和 Redis。

在这一节关于高性能架构设计原则中，你了解了需要处理的原始设计因素，如延迟、吞吐量、并发性和缓存，以优化架构性能。架构的每个组件（无论是服务器级别的网络，还是数据库级别的应用程序）都有一定的延迟和并发问题需要解决。

你应该根据期望的性能来设计应用程序，因为提高性能是有代价的。性能优化的具体细节可能因应用程序而异。解决方案架构需要相应地引导工作方向——例如，一个股票交易应用无法容忍甚至是亚毫秒级的延迟。而另一方面，一个电商网站则可以接受几秒钟的延迟。为了克服性能挑战，让我们了解如何为不同架构层次选择技术。

性能优化的技术选择

在 第四章 和 第五章 中，你学习了多种设计模式，包括微服务、事件驱动、基于缓存和无状态模式。一个组织可以根据其解决方案的设计需求选择这些设计模式的组合。根据工作负载，你可以有多种架构设计方法。一旦你确定了策略并开始实施解决方案，下一步就是优化应用程序。为了优化应用程序，你必须通过进行负载测试并根据应用程序的性能要求定义基准来收集数据。

性能优化是一个持续改进的过程，在这个过程中，你需要从解决方案设计的开始直到应用程序上线后，都关注资源的最佳利用。你需要根据工作负载选择合适的资源，或调整应用程序和基础设施的配置。例如，你可能会选择使用 NoSQL 数据库来存储应用程序的会话状态，并将事务存储在关系数据库中。

对于分析和报告目的，你可以通过将数据从应用程序数据库加载到数据仓库解决方案中，从而卸载生产数据库，并从中创建报告。

在服务器的情况下，你可以选择虚拟机或容器。你也可以完全采用无服务器的方式来构建和部署应用程序代码。无论你采用什么方式和应用程序工作负载，你都需要选择主要的资源类型：计算、存储、数据库或网络。让我们更详细地看看如何选择这些资源类型以进行性能优化。

做出计算选择

在这一节中，你会看到使用 compute 代替 server 的术语，因为如今软件部署不再局限于服务器。像 AWS 这样的公共云服务提供商提供无服务器服务，你不再需要服务器来运行应用程序。最受欢迎的 FaaS 服务之一是 AWS Lambda。像 AWS Lambda 一样，其他流行的公共云提供商也在 FaaS 领域提供解决方案——例如，微软的 Azure 提供 Azure Functions，GCP 提供 Google Cloud Functions。

然而，组织通常仍然默认选择带有虚拟机的服务器。随着自动化需求和资源利用率的提高，容器也变得越来越受欢迎。容器，尤其是在微服务应用程序部署领域，正在成为首选。

计算的最佳选择——无论是选择服务器实例、容器还是无服务器——取决于你的应用程序使用案例。让我们来看看各种计算选择。

以下表格提供了 CPU、图形处理单元（GPU）、现场可编程门阵列（FPGA）和应用特定集成电路（ASIC）之间的差异快照，重点介绍它们的主要用途、编程的难易度、核心结构、成本影响以及它们在并行处理等方面的适用性。让我们首先定义这些术语：

• CPU：计算机中的主要处理器，执行大多数数据处理操作，通常被称为计算机的“大脑”。

• GPU：一种专门的电子电路，设计用于快速操作和修改内存，加速在帧缓存中生成图像，供显示器输出。

• FPGA：一种集成电路，设计为在制造后由客户或设计师进行配置，因此称为“现场可编程”。

• ASIC：为特定用途定制的芯片，而非用于通用用途。

根据工作负载的变化，您可能会使用一个或多个这些处理单元选择。

特点	CPU	GPU	FPGA	ASIC
主要用途	通用应用	图形处理，大数据应用	可编程硬件用于特定任务	定制集成电路用于特定应用
编程难易度	容易	需要特定库的知识（例如，CUDA）	复杂，需要硬件编程	不适用（硬件为定制设计）
多任务处理	是	受限于并行设计的焦点	是，可重新配置	否，仅限单一用途
多功能性	高	中等	中等，可重新配置以适应任务	低，仅适用于特定应用
性能度量	GHz（每秒十亿次周期）	TFLOP（每秒万亿次浮点操作）	通常不以 Flops（每秒浮点操作）衡量	优化功耗与性能
核心结构	少数大核心	数千个小核心	可重新配置的逻辑单元	不适用（定制设计）
并行处理	有限	高，具有大规模并行处理（MPP）能力	支持 MPP，可配置为 CPU	针对特定应用进行了优化
成本	低	高于 CPU	高于 CPU 和 GPU，需定制	最高，因定制设计和较长开发周期
功耗	中等	高	低	针对应用进行了优化
灵活性	适用于各种应用	专用于计算密集型应用	可重新配置，但需要开发	固定，变更需要重新设计
开发周期	短	短到中等	长，由于需要定制	最长，需要硬件级重新设计

表 6.1：各种处理器类型的比较

上述表格比较了各种处理类型。ASIC 是最高效的，但实施周期长。ASIC 提供了最优性能，但灵活性最低，而 CPU 非常灵活，可以适用于许多用例。

今天，CPU 已经成为一种普遍商品，广泛用于一般用途设备以降低成本。GPU 因计算密集型应用而著名，而 FPGA 则在需要更定制性能时成为首选。这些处理选择可通过公共云提供商（如 AWS）获得。

在本节中，您了解了最受欢迎的计算选择。

您可能还会听说其他类型的处理器，例如加速处理单元（APU）。APU 结合了 CPU、GPU 和数字信号处理器（DSP），专为分析模拟信号并需要高速实时数据处理而优化。

让我们进一步了解其他因其优化虚拟机内资源利用能力而迅速受到欢迎的流行计算容器。

使用容器工作

在 第四章，解决方案架构设计模式 中，您了解到了在 使用容器部署应用程序 部分中部署容器的好处。由于其自动化和资源利用效率的便利性，容器的使用正成为部署复杂微服务应用程序的常态。有多种平台可供容器部署使用。

由于其受欢迎程度和与平台无关的能力，容器已成为构建云无关平台的首选。您可以在本地数据中心部署容器，并通过云端进行管理。此外，您还可以采用迁移方法，将容器从本地迁移到云端，而无需进行任何更改。

您可以使用容器构建多云平台，现在每个主要的公共云供应商都提供了管理跨多个平台的容器环境的工具。例如，AWS 提供了弹性容器服务（ECS）Anywhere，使您能够轻松在客户管理的基础设施上运行和管理容器工作负载。同样地，GCP 提供了Google Anthos，为您提供跨本地和其他云平台的容器管理。让我们学习一些在容器领域中最受欢迎的选择、它们的区别以及它们如何协同工作。

Docker

Docker 是最受欢迎的技术之一。它允许您将应用程序及其相关依赖项打包为容器，并部署到任何操作系统平台上。Docker 提供了与软件应用程序无关的能力，使整个软件开发、测试和部署过程变得简单和易于访问。

Docker 容器帮助您构建更复杂的多层应用。例如，您需要同时运行应用服务器、数据库和消息队列。在这种情况下，您可以使用不同的 Docker 镜像将它们并行运行，并在它们之间建立通信。这些层中的每一层可能使用不同的库版本，而 Docker 允许它们在同一台计算机上运行且不会发生冲突。

Docker 容器镜像可以通过局域网或互联网在系统之间进行传输，使用 Docker Hub 进行管理和分发。您可以通过 Docker Hub 容器仓库管理和分发您的容器。假设您在 Docker 镜像中做了更改，导致环境问题，这时可以轻松回滚到有效版本的容器镜像，从而简化整体故障排查过程。

使用 Docker 时，开发团队构建应用并将所需的依赖打包成容器镜像。此应用镜像将在 Docker 主机上的容器中运行。就像您管理 GitHub 等代码库中的代码一样，Docker 镜像也应存储在一个注册中心中。Docker Hub 是一个公共注册中心，其他公共云供应商也提供他们自己的注册中心，如 AWS Elastic Container Registry (ECR) 和 Azure Container Registry。此外，您还可以在本地为您的 Docker 镜像设置私有注册中心。

像 AWS 这样的公共云服务商提供容器管理平台，如 Amazon ECS。容器管理平台在云虚拟机 Amazon EC2 上管理 Docker 容器。AWS 还提供了一种无服务器的容器部署选项 Amazon Fargate，您可以在不配置虚拟机的情况下部署容器。

复杂的企业应用是基于跨多个容器的微服务构建的。将多个 Docker 容器作为一个应用的一部分进行管理可能会变得复杂。Kubernetes 有助于解决多容器环境的挑战；让我们深入了解 Kubernetes。

Kubernetes

Kubernetes 在生产环境中管理和协调多个容器方面表现出色，作为一个全面的容器编排系统，它支持在物理服务器或虚拟机节点上托管 Docker 容器，这些节点通常被称为工作节点。Kubernetes 高效地协调这些节点群集的操作，自动化执行部署、扩展以及容器化应用管理等任务，从而确保基础设施上应用的顺畅和可靠运行。

Kubernetes 通过在应用错误的情况下替换无响应的容器，使您的应用实现自我修复。它还提供水平扩展能力和蓝绿部署能力，以防止停机。Kubernetes 会在容器之间分配传入的用户流量负载，并管理各容器共享的存储。

下图展示了 Kubernetes 和 Docker 如何协同工作，以编排您的软件应用程序。Kubernetes 负责工作节点与 Docker 容器之间的网络通信：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_06.png

图 6.4：Docker 和 Kubernetes

Docker 作为应用程序的独立部分，而 Kubernetes 负责协调，确保这些部分按照设计一起工作。通过 Kubernetes，整体应用程序的部署和扩展非常容易自动化。在 Docker 中，容器托管在节点中，每个 Docker 容器在单个节点中共享相同的 IP 地址。在 Docker 中，你需要通过处理任何 IP 冲突来管理容器之间的连接。Kubernetes 通过有一个主实例来解决这个问题，该实例跟踪所有托管 Pods 的节点。

Kubernetes 的主节点分配一个 IP 地址，并托管一个用于容器配置的键值存储和一个 kubelet 来管理容器。kubelet 是每个节点上的主要“节点代理”，确保在 Pods 中定义的容器被启动并持续运行。Docker 容器被分组为 Pods，共享相同的 IP 地址。整个配置被称为 Kubernetes 集群。

Kubernetes 维护起来较为复杂。云服务提供商为其提供了自己的管理工具。例如，AWS 提供了 Amazon 弹性 Kubernetes 服务 (EKS)，以简化 Kubernetes 集群的管理。OpenShift 是由 Red Hat 管理的另一个 Kubernetes 发行版，并作为 平台即服务 (PaaS) 提供。类似地，微软 Azure 提供了 Azure Kubernetes 服务 (AKS)，而 GCP 提供了 谷歌 Kubernetes 引擎 (GKE)，这些服务提供了一个简单的方式来自动部署、扩展和管理 Kubernetes。

总的来说，容器为整个应用程序基础设施增加了一层虚拟化。尽管它们在资源利用方面非常有帮助，但如果您的应用程序需要超低延迟，建议选择裸机物理机进行部署。

无服务器架构

最近几年，随着来自 Amazon、Google 和 Microsoft 等云服务提供商的公共云解决方案的普及，无服务器计算变得可行。无服务器计算使得开发者可以专注于代码和应用程序开发，而无需担心底层的资源配置、配置和扩展基础设施。无服务器解决方案将服务器管理和基础设施决策从开发者中抽象出来，让他们专注于自己擅长的领域和他们正在尝试解决的业务问题。无服务器计算带来了相对较新的 功能即服务 (FaaS) 概念。

FaaS（功能即服务）由 AWS Lambda、Microsoft Azure Functions 和 Google Cloud Functions 提供。例如，你可以在云编辑器中编写代码，AWS Lambda 负责底层的计算基础设施，运行并扩展你的函数。你可以通过使用 Amazon API Gateway 和 AWS Lambda 函数添加 API 端点，设计基于事件的架构或 RESTful 微服务。Amazon API Gateway 是一个维护的云系统，它为 Lambda 函数添加 RESTful API 和 WebSocket API，作为前端接口，并实现应用程序之间的实时通信。你还可以将微服务进一步拆分为可自动扩展和独立的任务。

除了专注于你的代码外，在 FaaS 模型中，你无需为闲置资源付费。你可以根据需要独立扩展所需的函数，且具有内置的可用性和容错性，而不是扩展整个服务。然而，如果你需要协调数千个功能，预测自动扩展成本可能会比较复杂。这非常适合任务调度、处理 Web 请求和排队消息。

在本节中，你已经了解了可以为性能优化做出的各种计算选择。我们讨论了服务器实例、容器和无服务器选项。你需要为你的应用程序选择合适的计算服务。没有任何规则强制要求你选择特定类型的计算；这完全取决于你组织的技术选择、创新的步伐以及软件应用的性质。

然而，对于单体应用程序，你通常可以选择虚拟机或裸金属机器；对于复杂的微服务，你可以选择容器。对于简单的任务调度或基于事件的应用程序，无服务器函数是一个显而易见的选择。许多组织已经完全基于无服务器计算构建了复杂的应用程序，这帮助他们降低了成本，并在不管理任何基础设施的情况下实现了高可用性。

让我们了解基础设施的另一个重要方面，以及它如何帮助你优化性能。

做出存储选择

存储在任何软件应用的性能中起着至关重要的作用，而数据亲和性的概念在讨论应用存储时尤为重要。数据亲和性指的是将数据战略性地放置在靠近应用程序的位置，以减少延迟、提高性能并确保高效的数据检索。

在多云或混合云环境中，并非所有存储都必须靠近应用服务器。现代分布式系统旨在允许数据存在于多个位置，无论是本地还是不同的云提供商，同时仍保持可接受的延迟和性能水平。这种灵活性对于使用各种云服务的组织或具有数据驻留要求的组织至关重要，这些要求规定某些数据必须保持在特定的地理或司法边界内。

然而，决定数据存储的位置——是靠近应用服务还是在其他位置——需要仔细考虑多个因素：

• 延迟要求：请求与响应之间的可接受延迟可能会显著影响数据存储位置的选择。需要实时访问数据的应用程序可能需要具有最小延迟的存储解决方案，通常意味着需要物理或网络上的接近。

• 数据主权和合规性：法律和监管要求可能会决定数据可以存储和处理的地点，这意味着架构需要与合规要求保持一致。

• 成本考虑：在不同位置或云中存储和访问数据可能会产生额外费用。在考虑云环境中的数据外流费用时，平衡性能需求与预算限制是至关重要的。

• 带宽和吞吐量：应用服务器与数据存储位置之间的可用网络带宽和吞吐量会影响性能。高带宽和高吞吐量可以减轻一些延迟问题，从而提供更多灵活的数据存储选项。

• 数据访问模式：了解应用程序如何访问数据（例如，频繁访问的数据与不常访问的数据）可以帮助你选择合适的存储位置。频繁访问的数据可能需要靠近应用程序存储，以加速访问速度。

• 灾难恢复和可用性：数据弹性策略可能要求在不同地理位置复制数据，以确保在故障发生时仍能保持可用性。

在多云策略中，通过实施缓存、数据复制或边缘计算解决方案，可以通过将关键数据的同步副本保持在应用程序附近，从而帮助保持性能标准，无论主要数据存储位置在哪里。这些方法使得应用程序能够在最小延迟下访问数据，即使主要数据源地理位置较远。

选择合适的存储方式依赖于对这些因素的全面分析。你应该在运营需求、性能、成本和合规性之间找到平衡。最终目标是构建一个满足应用程序性能需求的解决方案，同时遵守组织、法律和预算约束。

您首先需要决定数据是存储在块存储、文件存储还是对象存储中。这些是以不同方式存储和呈现数据的存储格式。让我们更详细地看一下这个问题。

使用块存储和存储区域网络

块存储将数据划分为块并将其作为数据块存储。每个块都有一个唯一的 ID，允许系统将数据存储在最容易访问的位置，因为块本身不存储有关文件的任何元数据。因此，基于服务器的操作系统管理并使用这些硬盘上的块。每当系统请求数据时，存储系统会收集这些块，并将结果返回给用户。

部署在存储区域网络（SAN）中的块存储能够高效且可靠地存储数据。当需要存储大量数据并频繁访问时，它表现出色——例如，数据库部署、电子邮件服务器、应用程序部署和虚拟机。

SAN 存储系统功能复杂，支持复杂且关键的应用程序。它是一个高性能存储系统，负责在服务器和存储之间传输块级数据；然而，SAN 系统价格昂贵，应该用于需要低延迟的大型企业应用。

在配置基于块的存储时，您必须在 SSD 和 HDD 之间做出选择。HDD 是服务器和企业存储阵列的传统数据存储系统。HDD 便宜但速度较慢，并且需要大量电力和冷却。SSD 使用半导体芯片，比 HDD 更快。尽管 SSD 成本较高，但随着技术的发展，SSD 变得更加实惠和受欢迎，因为它们具有更高的效率，且对电力和冷却的需求较低。

使用文件存储和网络附加存储

文件存储已经存在了很长时间，并且被广泛使用。在文件存储中，数据作为一个整体存储并在文件夹中进行组织。当需要访问数据时，您提供文件路径并获取数据文件；然而，随着文件在多个文件夹层级下嵌套，文件路径可能变得复杂。

每条记录都有有限的元数据，包括文件名、创建时间和最新的时间戳。可以将其类比为图书馆，在图书馆中，书籍存放在书架上，并且有一本日志记录了每本书的位置。

网络附加存储（NAS）是一种附加到网络的文件存储系统，向用户展示存储和访问文件的位置。NAS 还管理用户权限、文件锁定及其他保护数据的安全机制。NAS 在文件共享系统和本地归档中表现良好；然而，考虑到 NAS 的元数据有限且文件夹层级结构复杂，对于存储数十亿文件，NAS 并不是最优解。为了存储数十亿个文件，需要使用对象存储。让我们更深入地了解对象存储及其与文件存储相比的优势。

使用对象存储和云数据存储

对象存储将数据与唯一标识符和可定制的元数据捆绑在一起。与文件存储中的层次化地址或块存储中分布在多个块上的地址不同，对象存储使用平坦的地址空间。平坦的地址空间使得无论数据存储位置在哪里，都能更容易地快速定位和检索数据。对象存储还帮助用户实现存储的无限扩展性。

对象存储的元数据可以包含许多细节，如对象名称、大小、时间戳等，用户可以定制它以添加比文件存储中标记更多的信息。一个简单的 API 调用即可访问数据，而且存储成本非常低。对象存储在处理高容量、非结构化数据时表现最佳；然而，对象无法修改，只能被替换，因此它并不适合用作数据库。

云数据存储，如Amazon Simple Storage Service（S3），提供具有高可用性和耐久性的无限扩展对象数据存储。你可以通过唯一的全局标识符和元数据文件前缀访问数据。

以下图表概述了三种存储系统：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_07.png

图 6.5：数据存储系统

如上图所示，块存储将数据存储在块中。块存储非常适合需要单个实例独占存储访问的场景，如数据库或需要高性能和快速数据访问的应用程序。文件存储将数据存储在层次化的文件夹结构中，几乎没有额外的延迟。你应该在数据需要被多个实例同时访问时使用文件存储系统，就像不同的人可能需要访问共享房间中的文件一样。对象存储将数据存储在桶中，每个对象都有一个唯一标识符。它通过网络提供访问，以减少延迟并提高吞吐量。你应该使用对象存储来存储和访问静态内容，如图片和视频。你可以在对象存储中存储大量数据并进行大数据处理和分析。

直接附加存储（DAS）是另一种直接附加到主机服务器的数据存储类型；然而，它的可扩展性和存储容量非常有限。

磁带驱动器是另一种流行的备份和归档存储系统。由于其低成本和高可用性，磁带驱动器用于归档目的，但由于其高延迟，不适合直接应用。

通常，你需要提高任务关键型应用程序（如事务数据库）的吞吐量和数据保护，其中数据存储在 SAN 存储中。

选择与访问模式匹配的存储解决方案，以最大化性能。通过云服务，您可以选择块存储、文件存储和对象存储等多种选项。例如，AWS 公共云提供Amazon Elastic Block Store（EBS）作为云中的 SAN 存储，以及Amazon Elastic File System（EFS）作为云中的 NAS 存储。

亚马逊 S3 在对象存储中非常流行。同样，微软 Azure 提供 Azure 磁盘存储用于 SAN，Azure 文件存储用于 NAS，以及 Azure Blob 存储用于块存储。

数据库存储

选择合适的存储类型对于数据库性能至关重要，以确保最佳操作和效率。选择通常取决于数据库工作负载的具体要求，如 IOPS、数据库大小、数据访问的地理位置以及数据库操作的性质（在线事务处理（OLTP）与在线分析处理（OLAP））。下面是一个比较表，概述了不同存储类型在数据库中的选择标准和适用性。

存储类型	IOPS 能力	适用的数据库大小	位置考虑	最佳应用场景	适用性
SSD	高	小到大	靠近应用服务器	OLTP 和 OLAP	非常适合大多数数据库，特别是在 IOPS 高和延迟低至关重要的场景下。
HDD	中等到低	大型	靠近应用服务器	大型 OLAP	适用于大规模、访问频率较低的数据库或对成本敏感的场景，但不推荐用于高性能 OLTP 系统。
NAS	低到中等	小到中等	灵活，可离线	OLAP 和备份	适用于性能要求中等的数据库，或用于备份/归档目的。
SAN	高	大型	灵活，最好靠近	OLTP 和 OLAP	非常适合需要高 IOPS、吞吐量和可扩展性的大型数据库。可以是本地部署或基于云的。
云存储	可变	可变	本地或云端	OLTP 和 OLAP	适用于各种数据库规模和类型。性能和适用性取决于特定的云服务提供商。

表 6.2：不同存储类型的比较

在涉及多云或混合环境的场景中，其他因素，如数据主权和合规性（决定数据存储位置的法规要求）、访问模式（数据是以读取为主还是写入为主）、网络延迟、带宽和成本考虑等，也起着至关重要的作用。尤其是在通过广域网（WANs）访问数据库时，这些因素尤其重要，因为延迟可能会影响性能。

现在您已经了解了为实现最佳性能所需的计算和存储选择，让我们来看看应用程序开发的下一个关键组成部分：数据库。选择适合需求的数据库将改善应用程序的性能并减少整体应用程序延迟。市面上有多种数据库类型，选择正确的数据库至关重要。

做出数据库选择

通常，您会希望标准化一个通用平台，并使用数据库以便于管理；然而，根据数据需求考虑使用不同的数据库解决方案。选择错误的数据库解决方案可能会影响系统延迟和性能。

您选择的数据库将取决于应用程序的可用性、可扩展性、数据结构、吞吐量和持久性要求。选择数据库时需要考虑多个因素。例如，访问模式可能会显著影响数据库技术的选择，这取决于用户数量和数据访问频率。您应该根据访问模式来优化您的数据库。

数据库通常具有用于工作负载优化的配置选项。您应该考虑内存、缓存、存储优化等方面的配置。您还应当探讨关于可扩展性、备份、恢复和维护的数据库技术的操作方面。让我们来看一下可以用于满足应用程序数据库需求的不同数据库技术。

在线事务处理

大多数传统的关系型数据库被认为使用在线事务处理（OLTP）。事务型数据库是最古老和最流行的存储和处理应用程序数据的方法。关系型 OLTP 数据库的一些例子包括 Oracle、Microsoft SQL Server、MySQL、PostgreSQL 和 Amazon RDS。OLTP 的数据访问模式涉及通过查找 ID 来获取一个小的数据集。数据库事务意味着要么所有相关的数据库更新都完成，要么一个也没有完成。

关系模型允许在应用程序中处理复杂的业务事务，如银行、交易和电子商务。它使您能够聚合数据，并使用跨表的多个连接来创建复杂的查询。

在优化关系型数据库时，您需要考虑包括以下优化内容：

• 包含计算、内存、存储和网络功能的数据库服务器

• 操作系统级设置，如存储卷、卷管理和块大小

• 根据需要配置数据库引擎和分区

• 数据库相关选项，如模式、索引和视图

对于关系型数据库来说，扩展性可能会有挑战，因为它们只能垂直扩展，最终会遇到系统容量的上限。可以利用只读副本来分担读取负载。这使得你可以将读取查询从主数据库转移到一个或多个副本，从而增强系统的读取能力。通过实现分区（分片）来扩展写入性能。通过将较大的数据库划分成较小、更易管理的部分（分区或分片），每个部分包含数据的一个子集，你可以将写入负载分散到多个服务器或实例上，从而提高写入性能。

在上一章中，你学习了如何在应用架构中的数据库处理部分中扩展关系型数据库。

OLTP 数据库适用于大型和复杂的事务型应用；然而，当需要聚合和查询大量数据时，它们需要更好的扩展性。同时，随着互联网的爆炸式发展，很多非结构化数据从各个地方涌现，而关系型数据库无法高效地处理这些非结构化数据。在这种情况下，非关系型数据库或 NoSQL 数据库可以派上用场。让我们进一步了解如何处理这些数据。

非关系型数据库

很多非结构化和半结构化的数据来自于社交媒体程序、物联网（IoT）、点击流数据和日志等应用程序，这些应用有着非常动态的架构。这些数据类型可能会有不同的架构用于每一组记录。将这些数据存储在关系型数据库中可能是一项非常繁琐的任务。所有内容都必须按照固定的架构进行存储，这可能导致大量的空值或者数据丢失。非关系型数据库，通常称为 NoSQL（“Not Only SQL”或“非 SQL”），提供了一种灵活的数据存储和管理方式。与传统的关系型数据库不同，关系型数据库需要在存储数据之前定义固定架构，而 NoSQL 数据库允许在没有预定义架构约束的情况下存储和管理数据。具有可变列数的记录可以存储在同一张表中。

NoSQL 数据库可以存储大量数据并提供低访问延迟。当需要时，它们通过添加更多节点来轻松扩展，并且可以支持水平扩展。它们非常适合用于存储用户会话数据，并使你的应用程序无状态，以便实现水平扩展而不妥协用户体验。你可以在 NoSQL 数据库之上开发分布式应用程序，提供良好的延迟和扩展性，但查询连接必须在应用层处理，因为 NoSQL 数据库不支持诸如连接表和实体的复杂查询。

有多种 NoSQL 数据库选项可供选择，如 Cassandra、HBase 和 MongoDB，你可以在虚拟机集群中安装它们。AWS 提供了一种托管的 NoSQL 数据库——Amazon DynamoDB，它提供高吞吐量、子毫秒级延迟和无限制的扩展能力。

你可以使用 OLTP 来处理关系型数据库，但它的存储能力有限。它需要更好地响应大量数据的查询，并进行数据仓库所需的聚合。数据仓库的需求更偏向于分析而非事务处理。OLAP 填补了 OLTP 在查询大规模数据集方面的不足。让我们更深入了解 OLAP。

在线分析处理

OLTP 和 NoSQL 数据库对于应用程序部署很有帮助，但在大规模分析方面能力有限。OLAP 主要用于数据仓库技术。对于大规模结构化数据的分析查询，更适合使用为更快访问结构化数据而设计的数据仓库平台。现代数据仓库利用列式存储格式和大规模并行处理（MPP）架构，显著提升数据检索和分析速度。与传统的行式数据库不同，行式数据库是按行存储数据，而列式存储按列组织数据。

列式格式意味着当你只需要对某一列进行数据聚合时，无需扫描整个表。例如，如果你想确定某个月的库存销售量，订单表中可能有数百列，但你只需要聚合购买列的数据。使用列式格式，你只需要扫描购买列，相比于行式格式，这减少了扫描的数据量，从而提高了查询性能。

使用 MPP，你将数据以分布式方式存储在子节点之间，并向主节点提交查询。根据分区键，主节点会将查询分发到子节点。每个节点然后处理查询的一部分进行并行处理。主节点随后从每个子节点收集子查询结果，并返回聚合结果。这种并行处理帮助你更快地执行查询，并快速处理大量数据。

你可以通过安装 IBM Netezza 或 Microsoft SQL Server 等软件在虚拟机上使用这种处理方式，或者选择更符合云原生的解决方案，比如 Snowflake。AWS 作为公共云，提供了 PB 级数据仓库解决方案 Amazon Redshift，它使用列式格式和 MPP。你将在第十二章，面向解决方案架构的数据工程中了解更多关于数据处理和分析的内容。

你需要存储和搜索大量数据，尤其是当你想在日志中找到特定错误或构建文档搜索引擎时。为了实现这种功能，你的应用程序需要创建数据搜索功能。让我们了解一下数据搜索功能。

构建数据搜索功能

经常需要快速搜索大量数据来解决问题或获取商业洞察。搜索应用数据可以帮助你从不同角度访问和分析详细信息。为了低延迟和高吞吐量地搜索数据，你需要使用搜索引擎。

Elasticsearch 是最流行的搜索引擎平台之一；它建立在 Apache Lucene 库的基础上。Apache Lucene 是一个免费的开源软件库，许多流行的搜索引擎都基于它。ELK（即 Elasticsearch、Logstash 和 Kibana）堆栈易于使用，可以自动发现大规模数据并为搜索建立索引。由于其特性，围绕 Elasticsearch 已开发了多种可视化和分析工具。例如，Logstash 与 Elasticsearch 配合使用，收集、转换并分析大量应用日志数据。Kibana 与 Elasticsearch 内建连接器，提供了一种简单的解决方案来创建仪表板并分析已索引的数据。Elasticsearch 可以部署在虚拟机中，通过水平扩展来增加容量，方法是向集群中添加新节点。AWS 公有云提供了托管的 Amazon OpenSearch Service，使得在云中扩展和管理 Elasticsearch 集群既经济又简单。

在本节中，你了解了各种数据库技术及其应用场景。你的应用可以使用多种数据库技术来支持不同的组件，以实现最佳性能。对于复杂的事务，需要使用关系型 OLTP 数据库；而对于存储和处理非结构化或半结构化数据，则需要使用非关系型 NoSQL 数据库。当需要在多个地理区域提供非常低的延迟时，或者在应用层需要处理复杂查询时，比如在游戏应用中，就应该使用 NoSQL 数据库。如果需要对结构化数据进行大规模分析，应使用数据仓库 OLAP 数据库。

让我们来看看架构的另一个关键组成部分：网络。网络是整个应用程序的支柱，负责建立服务器与外界之间的通信。让我们了解一下与应用性能相关的网络知识。

提升网络性能

在这个几乎每个角落都有快速互联网连接的时代，应用程序需要拥有全球用户覆盖。系统响应时间的任何延迟都取决于请求负载和最终用户与服务器之间的距离。如果系统无法及时响应用户请求，可能会产生连锁反应，持续占用系统的所有资源，并堆积大量请求积压，这将导致整体系统性能下降。

为了减少延迟，你应该模拟用户的地理位置和环境，以找出任何差距。根据你的发现，你应该设计服务器的物理位置和缓存机制来减少网络延迟；然而，应用程序的网络解决方案选择取决于网络速度、吞吐量和延迟要求。一个面向全球用户的应用程序需要与其客户之间有快速的连接，而地理位置在此过程中起着重要作用。CDN 提供的边缘位置帮助本地化丰富内容并减少整体延迟。

在第四章，解决方案架构设计模式中，你学习了如何使用 CDN 在基于缓存的架构部分将数据放置在靠近用户的位置。如果你的应用程序内容以静态文件为主（例如，需要向最终用户传递大量图像和视频内容），那么可以使用 CDN 解决方案。市场上一些较为流行的 CDN 解决方案包括 Akamai、Cloudflare 和 Amazon CloudFront（由 AWS 云提供）。

使用边缘计算

边缘计算是一种分布式计算范式，它将计算和数据存储靠近需要它们的地点，以提高响应时间并节省带宽。这些是为提供 IT 基础设施而在使用地点附近设置的小型数据中心。边缘计算已经成为优化软件应用性能的变革性策略，尤其是在延迟、带宽和实时数据处理至关重要时。你可以利用边缘计算来提升应用程序的性能，尤其是当你的用户群体遍布全球时。

假设一个著名的全球社交媒体网站，如 Facebook、X 或 TikTok，因重大事件（如体育比赛或名人宣布）而遭遇用户活动激增。在传统模式下，集中式服务器可能无法处理大量请求，导致加载时间变慢并可能发生中断。这时，内容分发网络（CDN）就发挥了作用，行业巨头如 Akamai、Cloudflare、Imperva 和 Amazon CloudFront 处于领先地位。

Akamai 是 CDN 领域的先驱之一，拥有广泛的边缘服务器网络，战略性地分布在全球多个国家和城市。比如，当一位来自日本东京的用户在高流量事件期间访问其全球社交媒体网站时，东京的 Akamai 边缘服务器便开始工作。这些服务器会从离用户更近的地方缓存并传输经常访问的内容，如图像、视频和静态文件，而不是通过集中式数据中心。这样，用户就能体验到超快的加载速度、减少的延迟和顺畅的内容传输。

此外，Akamai 的边缘服务器还提供先进的安全功能，如分布式拒绝服务（DDoS）保护和Web 应用防火墙（WAF）功能，确保社交媒体网站在面对网络攻击和未授权访问时保持韧性。与Amazon Web Services（AWS）紧密集成的 Amazon CloudFront 也为各种规模的企业提供了强大的边缘计算解决方案。

除了社交媒体，边缘计算正在改变各行各业。例如，在自动驾驶汽车中，边缘设备实时处理传感器数据，做出瞬间决策，确保道路安全。在物联网领域，边缘计算使智能设备能够在本地分析数据，减少延迟并节省带宽。例如，一款智能温控器可以根据本地传感器数据调整温度设置，而无需与集中式服务器进行持续通信。

在医疗保健领域，边缘计算被用于远程患者监控。配备边缘处理能力的可穿戴设备能够实时分析健康数据，并在发生异常时向医疗服务提供者或患者本人发送警报，从而实现及时干预。

通过将计算推近数据源和最终用户，边缘计算提升了性能、响应能力和可扩展性，使其成为提高应用程序性能的重要技术。

如果您的应用程序是全球部署的，我们来看看一些 DNS 路由策略，以实现低延迟。

定义 DNS 路由策略

您可以将应用程序部署到多个地理区域，以实现全球覆盖。在用户请求路由方面，您需要将用户请求路由到最近且响应最快的服务器，以便快速响应应用程序的请求。DNS 路由器提供域名与 IP 地址之间的映射。它确保当用户输入域名时，请求能被正确的服务器处理——例如，当您在浏览器中输入 amazon.com 进行购物时，您的请求总是被路由到 Amazon 应用程序服务器的 DNS 服务。

AWS 提供了一项名为Amazon Route 53的 DNS 服务，您可以根据应用程序的需求定义不同类型的路由策略。Amazon Route 53 提供的 DNS 服务旨在简化域名管理。以下是最常见的路由策略：

• 简单路由策略：顾名思义，这是一种最直接的路由策略，不涉及任何复杂的设置。它有助于将流量路由到单一资源——例如，用于向特定网站传递信息的 Web 服务器。

• 故障转移路由策略：该路由策略要求通过配置主动-被动故障转移来实现高可用性。如果您的应用程序在某一地区出现故障，所有流量可以自动转移到另一个地区。

• 地理位置路由策略：如果用户位于特定位置，你可以使用地理位置策略。地理位置路由策略将流量路由到特定区域。

• 地理邻近路由策略：这类似于地理位置策略，但在需要时，你可以将流量转移到附近的地点。

• 延迟路由策略：如果你的应用运行在多个区域，你可以使用延迟策略来从延迟最低的区域提供流量。

• 加权路由策略：加权路由策略用于 A/B 测试，其中你希望将一定量的流量发送到一个区域，并随着测试的成功增加此流量。

此外，Amazon Route 53 可以检测 DNS 查询的来源和流量异常，并优先处理已知的可靠用户的请求。它还可以保护你的应用免受 DDoS 攻击。

一旦流量通过 DNS 服务器，在大多数情况下，下一站将是负载均衡器，负载均衡器会将流量分配到一组服务器。让我们进一步了解负载均衡器。

应用负载均衡器

负载均衡器将网络流量分配到各个服务器，以提高并发性、可靠性和应用延迟。负载均衡器可以是物理的或虚拟的。最好选择适合你的应用需求的负载均衡器。通常，有两种类型的负载均衡器可以被应用使用：

• 第 4 层或网络负载均衡器：第 4 层负载均衡根据数据包头部的信息（例如，源/目标 IP 地址和端口）路由数据包。第 4 层负载均衡不会检查数据包的内容，因此其计算强度比第 7 层或应用负载均衡低，速度也更快。网络负载均衡器可以处理每秒数百万个请求。

• 第 7 层或应用负载均衡器：第 7 层负载均衡检查并基于数据包的完整内容进行路由。第 7 层负载均衡与 HTTP 请求一起使用。影响路由决策的因素包括 HTTP 头部、URI 路径和内容类型等。它允许更强大的路由规则，但需要更多的计算时间来路由数据包。应用负载均衡器可以根据容器的独特端口号将请求路由到你集群中的容器。

根据不同的环境，你可以选择基于硬件的负载均衡器，如 F5 负载均衡器或 Cisco 负载均衡器。你也可以选择基于软件的负载均衡器，如 Nginx。

AWS 提供了一种托管的虚拟负载均衡器，称为 Amazon 弹性负载均衡（ELB）。ELB 可以作为应用负载均衡器在第 7 层（Layer 7）应用，也可以作为网络负载均衡器在第 4 层（Layer 4）应用。

负载均衡器是保护应用程序的一个极佳方式，它通过将请求发送到健康的实例来使应用程序高度可用。它与自动扩展一起工作，根据需要添加或移除实例。让我们来看看自动扩展，并了解它如何帮助提高整体性能并确保应用程序的高可用性。

应用自动扩展

你在第二章《解决方案架构设计原则》中了解了自动扩展。你在按需设计部分学习了预测型和响应型自动扩展。自动扩展的概念随着云计算平台提供的灵活性而流行开来。云基础设施允许你根据用户或资源需求快速地扩展或缩减服务器集群。

使用像 AWS 这样的公共云平台，你可以在架构的每一层应用自动扩展。你可以根据展示层的请求数量扩展 Web 服务器集群，基于服务器的内存和 CPU 利用率扩展应用层。如果你知道服务器负载增加时的流量模式，还可以执行计划性扩展。在数据库层，像 Amazon Aurora Serverless 和 Microsoft Azure SQL Database 等关系型数据库支持自动扩展。像 Amazon DynamoDB 这样的 NoSQL 数据库可以根据吞吐量能力进行自动扩展。

在自动扩展时，你需要定义所需的服务器实例数量。你需要根据应用程序的扩展需求来确定服务器的最大和最小容量。以下截图展示了在 AWS 云中的自动扩展配置示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_06_08.png

图 6.6：自动扩展配置

在前面的自动扩展配置设置中，如果三个 Web 服务器实例正在运行，当服务器的 CPU 利用率超过 50%时，它可以扩展到五个实例；如果 CPU 利用率低于 20%，它将缩减到两个实例。如果实例在标准情况下变得不健康，实例总数将低于所需容量。在这种情况下，负载均衡器将监控实例的健康状况，并使用自动扩展提供新的实例。负载均衡器监控实例健康，并触发自动扩展来根据需要配置新的实例。

自动扩展是一个很好的功能，但请确保设置适当的配置，以限制 CPU 使用率变化带来的成本。在出现分布式拒绝服务（DDoS）攻击时，自动扩展可能会显著增加成本，造成预料之外的流量增加。它将有助于保护你的系统免受此类事件的影响。你将在第七章《安全考虑因素》中了解更多内容。

在本节中，你已经了解了可以帮助提高应用程序性能的各种网络组件。你可以根据用户位置和应用需求优化应用程序的网络流量。由于移动设备已成为许多应用程序的首选用户界面，你应该对移动应用程序进行主动的性能监控，以改善客户体验。接下来，让我们进一步了解移动应用程序的性能考虑。

移动应用程序的性能考虑

移动应用程序现在已成为许多数字平台的重要组成部分。如今，用户往往首先查看移动应用程序，然后再访问桌面网站。此外，用户流量的一个重要部分是通过移动应用程序驱动的，这使得确保这些应用程序具有高性能变得至关重要。随着移动应用程序越来越成为我们数字互动的核心，确保其性能、安全性和可用性显得尤为重要。接下来，让我们深入了解一些构建高效移动应用程序的最佳实践。

加载时间优化

在移动应用程序中，加载时间是一个关键因素，它既可以增加用户参与度，也可能成为用户流失的原因。快速高效的加载时间至关重要，尤其是在用户常常需要随时随地使用应用程序并期望即时响应的情况下。提高加载时间的一些方法包括优化图片尺寸、使用懒加载技术加载元素，并确保初始可见内容能迅速加载。

资源高效使用

移动设备的资源有限，如 CPU、内存和电池，这些限制了其性能。为了确保应用程序在不消耗设备资源的情况下平稳运行，开发人员需要优先考虑最小化这些资源的使用。策略包括使用高效算法、通过适当管理内存分配来减少内存泄漏，以及优化查询仅获取必要的数据。

响应式用户界面 (UI)

用户界面应直观且高度响应，确保用户输入能立即反馈。为实现这一点，任何计算密集型的过程，如数据检索或图像处理，都应在后台执行，以避免干扰 UI 交互。使用异步编程和多线程可以保持 UI 的灵活性和响应性。

网络效率

考虑到移动环境中可能存在不稳定或慢速的网络连接，应用程序应有效地管理网络请求。实现对不常变动数据的缓存、优化 API 调用，并通过提供适当的用户反馈优雅地处理网络故障，可以显著提升用户体验和应用性能。

电池消耗

应用程序如果过度消耗电池，将很快失宠于用户。您应该注意优化流程并管理后台任务，以最小化能耗。确保 GPS、蓝牙和其他耗电量大的进程在不需要时得到谨慎使用和关闭是至关重要的。

跨平台兼容性

随着大量设备、操作系统和屏幕尺寸的出现，应用程序应在各种平台上保持高性能。利用跨平台开发框架并在多种设备上进行彻底测试，可以确保一致和最佳的用户体验。

用户体验（UX）设计

确保用户体验（UX）无缝和直观对于任何应用程序的成功至关重要。这涉及设计用户友好的界面，确保导航的便利性，并在整个应用程序中保持逻辑流，以确保用户可以以最小的努力完成他们想要的操作。

有效的数据管理

通过利用本地存储频繁使用的数据，确保本地和远程数据之间的平稳同步，对于提供用户最新信息而不影响性能至关重要。

测试和质量保证

实施严格的测试协议，包括在不同条件和不同设备上进行性能测试，确保应用程序即使在负荷下也能保持最佳性能。采用自动化测试和持续集成可以帮助在开发阶段及时识别和纠正问题。

构建高性能的移动应用程序涉及用户中心设计和技术专业性的和谐结合。通过精心优化应用程序的每个方面，从界面和加载时间到数据管理和安全功能，开发人员可以确保它在各种条件和多种设备上表现最佳。在您实施各种策略以提高应用程序性能的同时，始终建议进行测试。让我们更深入地了解性能测试。

性能测试

性能测试是软件测试的一个关键子集，旨在确保软件应用在预期工作负载下表现良好。它围绕评估应用程序在各种情况下的稳定性、速度、响应能力和可扩展性展开。性能测试不是为了识别错误或缺陷，而是确定应用程序在不同需求水平下的反应方式。考虑到今天用户期望的无缝和迅速的功能，性能测试变得更加关键。

在今天的数字时代，性能良好的应用程序意义重大。首先，它直接影响用户满意度。用户习惯了在设备上进行迅速且无缝的互动，因此，应用程序反应迟缓或频繁崩溃会让人非常反感。没有人愿意浪费时间在一个无法迅速响应的应用程序上，尤其是在高需求或使用高峰期。此类体验带来的挫败感可能会导致用户完全放弃该应用，转而选择提供更流畅体验的竞争对手。

假设一个受欢迎的电子商务网站正在为黑色星期五促销做准备。预计会有成千上万甚至数百万的用户访问该网站，因此必须确保系统不会崩溃，交易处理迅速，且即便在用户激增的情况下，用户体验依然流畅。在这种情况下，性能测试不仅是有帮助的，而是至关重要的。

性能测试的类型

性能测试有几种类型，每种类型都是为了应对应用程序性能的特定方面。以下是主要性能测试类型的简要概述：

• 负载测试：这种测试旨在了解系统在预期的实际负载下的表现。这相当于通过逐渐增加重量来测试一座桥梁，直到它承载预期的最大车辆数量。例如，如果一家电子商务网站预计在节假日促销期间会有 10,000 名访客，负载测试将模拟这 10,000 名用户，确保网站在这种情况下平稳运行。

• 压力测试：想象一下，把太多人塞进电梯，超出了电梯的承载能力，看它是继续运行还是崩溃；这就是压力测试的本质。它旨在将系统推向极限，确保即便在最坏的情况下，故障也不会导致灾难性的结果。例如，银行应用可能会进行压力测试，看看如果一百万用户同时尝试登录，远超正常流量时，系统会如何表现。

• 耐力测试：耐力测试回答的问题是：“系统在长时间承受预期负载时能否高效运行？”例如，流媒体服务可能会进行耐力测试，以确保它能够连续流畅地为用户播放电影和节目，且质量和速度不受影响。

• 突发测试：在现实世界中，用户流量往往不可预测。突发测试就像观察电网在热浪期间每个人同时开启空调时的反应。一个例子可能是测试新闻网站在重大事件期间（如奥运会）是否能承受突如其来的大量用户访问，这些用户可能会查看比赛结果或更新。

• 容量测试：在这里，重点是数据。这类似于检查一个图书馆如何组织并借出数百万本书。对于数据库驱动的应用程序，容量测试可能包括查看系统在数据库拥有数十亿条记录时的表现。一个实际的例子是全球电子邮件服务测试其系统在通过大量存储邮件时的响应能力。

有许多性能测试工具可供使用，例如JMeter、LoadRunner和WebLoad。这些工具通过模拟各种场景和负载来测试应用程序的性能。

性能测试在软件开发生命周期中扮演着至关重要的角色。确保应用程序的健壮性、可靠性和速度对于其在实际环境中的成功至关重要。

性能测试和性能监控是确保应用程序效率和可靠性的两个关键方面，但它们在开发和部署生命周期中有不同的作用。性能测试旨在在问题影响用户之前识别潜在的性能问题，而性能监控则是持续关注系统性能并迅速应对部署后发生的任何问题。让我们在下一节中了解更多关于性能监控的内容。

性能监控管理

性能监控在你试图关注性能问题并主动减少最终用户影响时至关重要。

你应该定义你的性能基准，并在超出阈值时向团队发出警报——例如，应用程序的移动端加载时间不应超过三秒。你的警报应该能够触发自动化操作来处理表现不佳的组件——例如，向 Web 应用程序集群中添加更多节点以减少请求负载。

有多种监控工具可以衡量应用程序性能和整体基础设施。你可以使用像 Splunk 这样的第三方工具，或 AWS 提供的 Amazon CloudWatch 来监控任何应用程序。

监控解决方案可以分为主动监控和被动监控两种类型：

• 在主动监控中，你必须模拟用户活动并提前识别性能差距。应用程序的数据和工作负载情况不断变化，要求进行持续的主动监控。主动监控与被动监控协同工作，你需要运行已知的可能场景来复制用户体验。你应在所有的开发、测试和生产环境中运行主动监控，以便在问题影响用户之前发现它。

• 被动监控尝试实时识别未知模式。对于基于 Web 的应用，被动监控需要从浏览器收集可能导致性能问题的关键指标。你可以收集关于用户的地理位置、浏览器类型和设备类型的指标，以了解应用的用户体验和地理性能。监控就是关于数据，包括大量数据的摄取、处理和可视化。

性能总是有代价的，作为解决方案架构师，你需要考虑权衡，以选择正确的方法。例如，组织的内部应用，如时间表和人力资源程序，可能不需要像外部产品（如电子商务应用）那样高的性能。处理交易的应用（例如）需要非常高的性能，这就需要更多的投入。你应该平衡耐久性、一致性、成本和性能，以适应应用的需求。你将在接下来的章节中继续了解各种监控方法和工具，并在第八章、架构可靠性考虑中深入探讨监控和警报。

跟踪和改进性能是复杂的任务，你需要收集大量数据并分析模式。访问模式帮助你为性能优化做出正确的选择。结合主动监控和被动监控的持续应用，帮助你维持应用的一致性性能。

总结

在本章中，你了解了影响应用性能的各种架构设计原则。你了解了不同架构层次中的延迟和吞吐量，以及它们之间的关系。

对于高性能的应用，你需要在每一层架构中实现低延迟和高吞吐量。并发性有助于处理大量请求。你还学到了并行性和并发性的区别，并了解了缓存如何帮助提高整体应用性能。

然后，你了解了选择技术及其工作模型，这可以帮助实现你期望的应用性能。在查看计算选项时，你了解了不同的处理器类型及其差异，帮助你在选择服务器实例时做出正确的决策。你还了解了容器，以及它们如何帮助你有效利用资源，同时提升性能。你还学到了 Docker 和 Kubernetes 如何相互配合并融入你的架构中。

在选择存储部分，你了解了不同类型的存储，例如块存储、文件存储和对象存储及其差异。你还了解了在本地和云环境中可用的存储选择。

在选择数据库这一章节中，你了解了各种数据库类型，包括关系型数据库、非关系型数据库和数据仓库。你还了解了不同的请求路由策略，这些策略可以帮助你改善全球分布用户的网络延迟，同时你学会了负载均衡器和自动扩展如何帮助你管理大量的用户请求而不影响应用性能。由于移动应用对于任何应用程序至关重要，你也学习了移动应用的性能考虑因素。你还了解了性能测试的重要性以及如何监控应用的性能。

在下一章中，你将学习如何通过应用认证和授权来保障你的应用安全，这将帮助你在数据静态存储和传输过程中保护数据，并确保你的应用免受威胁和攻击。你还将了解合规性要求，以及在设计应用时如何满足这些要求。你将学习到安全审计、警报、监控和自动化的相关内容。

加入我们书籍的 Discord 空间

加入本书的 Discord 工作区，向作者和其他解决方案架构专业人士提问并互动：packt.link/SAHandbook

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/QR_Code930022060277868125.png

第七章：7

安全性考虑

安全性始终是架构设计的核心。许多企业因安全漏洞导致客户数据泄露而遭受财务损失。因此，组织不仅可能失去客户信任，还可能失去整个业务。

有许多行业标准的合规性和法规，以确保您的应用程序是安全的并且保护客户敏感数据。在前一章中，您了解了关于架构性能改进和技术选择的各个方面。本章将帮助您了解如何采用最佳实践来保护您的应用程序，并确保它符合行业标准的法规要求。

架构中的安全性不仅仅是保护 IT 工作负载的边缘。它还包括确保应用程序基础设施的不同部分相互之间是安全的。例如，在服务器上，您可以使用防火墙来控制哪些数据可以进出以及可以去哪里。这样，如果某个部分存在安全问题，它不会影响其他部分。您需要对所有部分进行相同的操作，如数据和程序。安全性需要应用于架构的每一层和每个组件。本章还讨论了保持云系统安全的不同方法。

在本章中，您将学习以下安全实践：

• 架构安全设计原则

• 选择技术以实现架构安全

• 安全性和合规性认证

• 云的共享安全责任模型

• 安全威胁建模

架构安全设计原则

安全性关乎于在为客户提供业务价值的同时保护您的系统和信息。缺乏良好的安全性可能对您的客户和业务产生严重影响。

您需要进行深入的安全风险评估，并规划出连续运营的缓解策略。接下来的章节将讨论标准设计原则，帮助您加强架构的安全性。

实施身份验证和授权控制

身份验证的目的是确定用户是否可以使用提供的凭据访问系统，而授权则决定用户进入系统后可以做什么。

您应该创建一个集中式系统来管理用户的身份验证和授权。集中式用户管理系统可以帮助您跟踪用户活动，以便在他们不再是系统的一部分或不再正确使用系统时停用他们。您可以定义标准规则来为新用户提供入职，并为不活跃的用户取消访问权限。集中式系统消除了对长期凭据的依赖，并允许您配置其他安全方法，例如密码轮换。

在授权方面，你应当遵循最小权限原则——这意味着用户初始时不应拥有任何权限，且仅根据其职位角色分配所需的访问权限。根据职位角色创建访问组，有助于在一个地方管理授权策略，并在大量用户中应用授权限制。例如，你可以限制开发团队仅能访问开发环境的全部权限，而只能以只读方式访问生产环境。如果有新的开发人员加入，他们应被添加到这个开发组，所有授权策略都在此集中管理。

启用单点登录（SSO）并使用集中的用户存储库，有助于减少用户群体记住多个密码的麻烦，并消除密码泄露的风险。为了进一步增强安全性，将多因素认证（MFA）与 SSO 结合，可以增加额外的保护层。MFA 要求用户提供两个或更多的验证因素来访问资源，例如安全令牌、指纹或面部识别。

大型组织使用集中式用户管理工具，例如Active Directory（AD），对员工进行身份验证和授权，从而提供访问内部企业应用程序的权限，如人力资源系统、费用系统和考勤系统。

在面向客户的应用程序中，例如电子商务和社交媒体网站，你可以使用 OpenID 身份验证系统来维持一个集中的系统。OpenID 是一种开放标准的身份验证协议。你将在本章的OAuth 和 OpenID Connect部分详细了解大规模用户管理工具。

在各个层级应用安全

通常，组织主要关注确保数据中心的物理安全，并保护外部网络层免受任何攻击。与其仅专注于单一的外层防护，不如确保在每个应用层都实施安全措施。

运用深度防御（DiD）方法，将安全控制措施层层叠加在应用程序中；例如，Web 应用程序需要通过保护全球演进增强数据速率（EDGE）网络和域名系统（DNS）路由来防止外部互联网流量的侵入。在负载均衡器和网络层面应用安全，阻止恶意流量。

通过仅允许必要的进出流量来保护每个应用实例，在 Web 应用和数据库层面实施这一措施。使用杀毒软件保护操作系统，以防止任何恶意软件攻击。通过在流量流动前放置入侵检测系统（IDS）和入侵防御系统（IPS），以及使用Web 应用防火墙（WAF）来保护应用免受各种攻击。你将在本章的选择技术以确保架构安全部分了解更多有关各种安全工具的细节。

减少爆炸半径

在每一层应用安全措施时，你应该保持系统的隔离，将其分隔成较小的区域，以减少爆炸半径。如果攻击者访问了系统的某一部分，你应该能够将安全漏洞限制在应用程序的最小区域内。例如，在 Web 应用中，将负载均衡器放在与架构其他层分离的独立网络中，因为它是面向互联网的。此外，在 Web、应用和数据库层之间应用网络隔离。如果一个层发生攻击，应该防止它扩展到架构的其他层。

相同的规则也适用于你的授权系统，给用户最小权限，只提供最低限度的必要访问权限。实施多因素认证（MFA），即使用户访问遭到突破，攻击者也始终需要第二级身份验证才能进入系统。

提供系统的最小访问权限，确保不暴露整个系统，并提供临时凭证以确保访问仅在短时间内开放。提供编程访问时，采取预防措施，通过使用安全令牌并频繁更换密钥来保证安全。

时刻监控和审计一切

你需要为系统中的每个活动设置日志机制，并应定期进行审计。审计功能通常是各种行业合规要求的一部分。收集来自每个组件的日志，包括所有交易和每次 API 调用，以实现集中监控。一个好的做法是对集中日志账户添加一层安全性和访问限制，以防止任何人篡改。

采取积极主动的方法，做好准备在用户受到影响之前处理任何事件。通过集中监控的警报功能，帮助你迅速采取行动并减少任何事件的影响。监控所有用户活动和应用程序账户，以限制安全漏洞。

自动化一切

自动化对于快速应对任何安全规则违规行为至关重要。你可以使用自动化来恢复与所需配置不符的更改，并向安全团队发出警报。例如，如果有人将管理员用户添加到你的系统，并将防火墙打开到未经授权的端口或 IP 地址，你可以应用自动化来删除这些不需要的系统更改。

将自动化应用于安全系统已成为 DevSecOps 概念中的一部分。DevSecOps 旨在将安全性融入应用开发和操作的每个部分。你将在第十一章，DevOps 与解决方案架构框架中进一步了解 DevSecOps。

创建安全的架构并实施定义和管理为代码的安全控制。你可以对安全作为代码模板进行版本控制，并根据需要分析更改。作为软件代码的自动化安全机制帮助你更快速、更具成本效益地扩展安全操作。

数据保护

数据是你架构的核心，保护和确保数据安全至关重要。大多数合规性法规的制定都是为了保护客户数据和身份。大多数攻击的目的是窃取用户数据。

你应该根据数据的敏感性级别对其进行分类，并相应地进行保护。例如，客户的信用卡信息应为最敏感的数据，并应以极大的谨慎处理。另一方面，客户的名字可能不那么敏感，而卡号则属于敏感信息。

在数据的整个生命周期中保护数据对维护其机密性、完整性和可用性至关重要。数据可以存在三种状态，每种状态都需要特定的安全措施来确保全面保护：

• 静态数据：指存储在物理介质上的数据，无论是在服务器的硬盘、笔记本电脑、USB 闪存驱动器还是云存储中。保护静态数据的一个机制是加密，它确保即使存储设备落入不法之手，数据也无法访问，除非拥有加密密钥。此外，你还需要设置访问控制并定期审计，确保只有授权用户可以访问或修改数据。

• 传输中的数据：当数据在网络中传输时——从用户的计算机到服务器、服务器之间，或通过互联网——它被视为处于传输中。为了保护传输中的数据，你可以使用加密协议，如传输层安全性（TLS）。这确保即使数据在传输过程中被拦截，它也对攻击者保持不可读。

• 使用中的数据：这通常是保护最具挑战性的状态，因为数据正在被应用程序处理或使用。加密可以保护数据在静态和传输中的状态，但一旦加载到内存并被应用程序使用，数据就变成了明文，可能会有安全漏洞。新技术如受信执行环境（TEEs）和同态加密正在兴起，用于保护使用中的数据，允许在加密数据上执行操作而无需先解密。

创建最小化直接访问数据需求的机制和工具。通过应用基于工具的自动化，避免手动数据处理，从而消除人为错误，特别是在处理敏感数据时。在可能的情况下对数据应用访问限制，以减少数据丢失或数据修改的风险。

一旦按敏感性分类数据，您可以使用适当的加密、令牌化和访问控制来保护数据。数据不仅需要在静态状态下保护，还需要在传输过程中保护——即在网络上传输时。您将在本章的数据安全部分学习各种保护数据的机制。

响应安全事件

保持随时准备应对任何安全事件。根据您的组织政策要求创建事故管理流程。事故管理因组织和应用程序而异。例如，如果您的应用程序处理客户的个人身份信息（PII），则需要在事故响应中采取更严格的安全措施。然而，如果应用程序处理的是少量敏感数据，如库存管理应用程序，则其处理方式将不同。

确保模拟响应安全事件，以查看您的安全团队如何从中恢复。

您的团队应使用自动化工具加速检测、调查和响应任何安全事件。您需要设置警报、监控和审计机制，进行根本原因分析（RCA），以防止类似事件再次发生。

在本节中，您学习了应用于应用程序安全架构中的一般安全原则。在下一节中，您将学习如何使用不同的工具和技术来应用这些原则。

选择用于架构安全的技术

前一节专注于设计架构时考虑的一般应用程序安全规则，但问题是：我们如何在实施过程中应用这些规则来确保应用程序安全？ 每个应用程序层都有各种工具和技术可用，用于使其安全。

本节中，你将详细了解在用户管理以及应用程序的 Web 层、基础设施和数据保护领域中可用的多种技术选择。让我们从第一个领域——用户身份和访问管理开始。

用户身份和访问管理

用户身份和访问管理是信息安全的关键部分。因为最好的做法是确保只有经过身份验证和授权的用户才能以特定方式访问你的系统资源。

随着组织的发展和产品被广泛采用，用户管理可能成为一项艰巨的任务。用户访问管理应区分并管理组织员工、供应商和客户的访问权限。

企业或公司用户可能是组织的员工、承包商或供应商。他们是拥有特殊权限的专家用户，负责开发、测试和部署应用程序。此外，他们可能需要访问其他企业系统以完成日常工作——例如，企业资源系统 (ERP)、薪资系统、人力资源系统、工时表应用等。随着组织的扩展，用户数量可以从几百人增加到几千人。

最终用户是指使用应用程序并拥有足够权限来探索和利用应用程序所需功能的客户——例如，游戏应用的玩家、社交媒体应用的用户，或电子商务网站的客户。随着你的产品或应用程序的普及，这些用户的数量可以从几千人到几百万不等。当应用程序面向外部互联网流量时，你需要特别注意安全性，以保护其免受各种威胁。

首先，我们来谈谈企业用户管理。你需要一个集中式的存储库来执行安全策略，如强密码创建、密码轮换和多因素认证（MFA），以便更好地进行用户管理。MFA 提供了另一种验证身份的手段，如果密码可能已被泄露的话。常见的 MFA 提供商包括 Google Authenticator、Gemalto、YubiKey、RSA SecurID、Duo 和 Microsoft Authenticator。

从用户访问的角度来看，基于角色的认证 (RBA) 简化了用户管理；你可以根据用户的角色创建用户组，并为每个组分配适当的访问策略。如以下图示所示，你可以有三个组——管理员、开发者和测试人员，并为每个组应用相应的访问策略。例如，管理员可以访问任何系统，包括生产环境，而开发者的访问仅限于开发环境，测试人员只能访问测试环境：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_01.png

图 7.1：用户组组织

如上图所示，当新用户加入团队时，他们会被分配到适合其角色的组中。通过这种方式，每个用户都拥有一组定义好的标准访问权限。如果引入了新的开发环境，所有开发人员都需要访问它，用户组也可以更新访问权限。

SSO 是一个标准过程，有助于减少安全漏洞并自动化系统。SSO 使得用户通过一个单一的用户 ID 和密码登录不同的企业系统。联合身份管理（FIM）允许用户通过预先认证的机制在没有密码的情况下访问系统。我们来看看更多的细节。

联合身份管理与单点登录

FIM提供了一种连接身份管理系统的方式，当用户信息存储在第三方身份提供者（IdP）中时。通过 FIM，用户仅向 IdP 提供认证信息，而 IdP 与服务之间已经建立了信任关系。

如下图所示，当用户登录以访问服务时，服务提供者从 IdP 获取凭证，而不是直接从用户处获取：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_02.png

图 7.2：FIM 认证流程

SSO（单点登录）允许使用一组登录凭证来访问多个服务。在这里，服务提供者可以针对你想要登录的环境进行设置——例如，客户关系管理（CRM）应用程序或你的云应用程序。身份提供者（IdP）可以是公司内部的 AD。联合身份认证类似于 SSO，但无需密码，因为联合服务器知道用户信息，并允许他们访问相关信息。

实现 FIM 和 SSO 的方式有很多种。我们来看一些流行的身份与访问管理（IAM）选项。

Kerberos

Kerberos 是一种身份验证协议，允许两个系统安全地识别对方，并实现 SSO。它基于客户端-服务器模型，并使用票证系统来确认用户身份。

Kerberos 具有一个密钥分发中心（KDC），它促进了两个系统之间的身份验证。KDC 由两个逻辑部分组成——认证服务器（AS）和票证授权服务器（TGS）。

Kerberos 存储并维护每个客户端和服务器的密钥。在通信过程中，它在两个系统之间建立一个安全会话，并通过存储的密钥来识别它们。以下图示展示了 Kerberos 身份验证的流程：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_03.png

图 7.3：Kerberos 认证

如上图所示，当你想要访问一个服务时，涉及以下步骤：

1. 当你想要访问计算机网络上的某项服务时，你的计算机（客户端）会向一个名为认证服务器（AS）的特殊服务器请求一个票据。

2. AS 会检查你是否在其数据库中。如果在，它会创建一个票据授予票（TGT）和会话密钥，并将它们发送回你的计算机。你可以用密码解锁会话密钥，但无法解锁 TGT，因为它是用只有票据授予服务器可以解锁的密钥加密的。

3. 你的计算机将这个 TGT 提交给另一个服务器，即 TGS，申请一个服务票据，以访问你所需的服务。

4. TGS 检查 TGT，如果一切正常，则返回一个服务票据，你的计算机可以用它向服务证明你有权限访问该服务。

5. 你的计算机将此票据展示给服务，如果服务同意票据有效，你就能获得访问权限。

虽然 Kerberos 有其优势，但它是一个开源协议，通常，大型企业喜欢使用更多管理化的软件，且具有强大支持，例如 AD。接下来，我们来看一下最流行的用户管理工具之一，基于轻量级目录访问协议（LDAP）的微软 AD 的工作机制。

微软活动目录

AD 是微软为用户和计算机开发的身份服务。AD 拥有一个域控制器，也称为活动目录域服务（AD DS），用于存储用户信息、访问凭据和身份，以及系统信息。

以下图示说明了身份验证过程的简单流程：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_04.png

图 7.4：AD 认证流程

如上图所示，用户登录由域网络上的 AD 管理。用户首先将请求发送到域控制器，并提供凭据，同时与活动目录认证库（ADAL）进行通信。ADAL 验证用户凭据后，返回一个访问令牌，并为请求的服务创建一个持续会话。

LDAP 是处理存储在目录中的信息的树形层次结构的标准协议。活动目录轻量级目录服务（AD LDS）为用户和系统的目录提供 LDAP 接口。对于文件加密和网络流量加密，活动目录证书服务（AD CS）提供密钥基础设施功能。活动目录联合服务（AD FS）为外部资源提供访问机制，例如许多用户的 Web 应用登录。

随着许多组织开始使用云服务，下面让我们了解一下 AWS 云提供的活动目录服务。

亚马逊 Web 服务目录服务

Amazon Web Services (AWS) 目录服务将您账户中的 AWS 资源与现有的本地用户管理工具（如 AD）连接。AWS 目录服务在 AWS 云中设置一个新的用户管理目录，并为本地目录提供安全连接。建立连接后，所有用户可以使用现有凭证访问云资源和本地应用程序。

AWS AD Connector 是另一项服务，帮助您将现有的 Microsoft AD 连接到 AWS 云；您无需特定的目录同步工具。管理员用户可以使用 AWS IAM 管理 AWS 资源。

AD Connector 通过与您现有的 MFA 基础设施（如 YubiKey、Gemalto 令牌或 RSA 令牌）集成，帮助启用 MFA。

对于小规模用户群（少于 5000 个用户），AWS 提供了 Simple AD，这是一个由 Samba 4 Active Directory 兼容服务器 提供支持的托管目录。Simple AD 具有常见功能，如用户账户管理、用户组管理、基于 Kerberos 的 SSO 和用户组策略。

其他主要技术公司提供的目录服务包括 Okta、Centrify、Ping Identity 和 Oracle 身份云服务 (IDCS)。

安全断言标记语言

在本节的 联合身份管理与单点登录 部分，您了解了 IdP 和服务提供商。要访问服务，用户通过 IdP 进行验证，而 IdP 与服务提供商之间建立了信任关系。安全断言标记语言 (SAML) 可用于通过 可扩展标记语言 (XML) 在 IdP 和服务提供商之间建立信任关系，从而标准化它们之间的通信。

SAML 断言是一个 XML 文档，IdP 将其发送给服务提供商，并包含用户授权信息。下图展示了 SAML 断言的流程：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_05.png

图 7.5：使用 SAML 进行用户认证

如前面的图所示，以下步骤用于通过 SAML 实现用户认证：

1. 用户向服务请求访问权限——例如，Salesforce CRM 应用程序——作为服务提供商。

2. 服务提供商（如 CRM 应用程序）向 SAML IdP 发送包含用户信息的 SAML 请求。

3. SAML IdP 会弹出 SSO 登录页面，用户在此输入认证信息。

4. 用户访问凭证发送到用户数据库，这是一个身份存储，用于验证。在此情况下，用户身份存储是一个 AD。

5. 用户身份存储将用户验证状态发送给与其建立信任关系的 SAML IdP。

6. SAML IdP 向服务提供商（如 CRM 应用程序）发送 SAML 断言，包含用户验证的信息。

7. 在收到 SAML 响应后，服务提供商允许应用程序访问用户。

有时，服务提供商也可以充当身份提供者（IdP）。SAML 在建立身份存储和服务提供商之间的关系方面非常流行。所有现代身份存储应用程序都与 SAML 2.0 兼容，这使得它们能够无缝地相互通信。SAML 允许用户身份被联合管理，并为企业用户启用单点登录（SSO）。

对于像社交媒体和电子商务网站这样的大型用户群体，OAuth（即开放授权）和 OpenID 比 SAML 更为适合。让我们来了解一下 OAuth 和 OpenID Connect（OIDC）。

OAuth

OAuth 是一种开放标准的授权协议，提供安全的访问委托给应用程序。OAuth 不共享密码数据，而是使用授权令牌在服务提供商和消费者之间建立身份。应用程序的用户在不提供登录凭据的情况下授权访问他们的信息。

虽然 OAuth 主要用于授权，但许多组织已开始添加他们自己的身份验证机制。

OIDC 是一个协议，它在 OAuth 2.0 授权框架之上定义了身份验证标准。OAuth 2.0 提供了一个授权框架（授予访问资源的权限），而 OIDC 添加了一个额外的层来处理用户身份验证。这意味着 OIDC 不仅帮助应用程序知道用户可以访问哪些资源，还验证访问服务的用户身份。它是一种基于授权服务器执行身份验证后，客户端验证用户身份，并以可互操作和类似 REST 的方式获取用户基本资料信息的方法。

亚马逊、Facebook、谷歌和 X 等大型科技公司允许用户与第三方应用共享其帐户中的信息。例如，您可以使用 Facebook 登录一个新的照片应用程序，并授权新应用程序仅访问您的 Facebook 照片信息。下图说明了一个 OAuth 访问委托流，用户请求 LinkedIn 应用程序从 Facebook 获取其个人资料照片：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_06.png

图 7.6：使用 OAuth 2.0 的用户访问委托

如上图所示，身份验证流程遵循以下步骤：

1. 在此场景中，用户向 LinkedIn 应用程序发出请求，要求从 Facebook 获取个人资料照片。

2. LinkedIn 应用程序请求授权访问 Facebook 个人资料照片。

3. 授权服务器（在本例中是您的 Facebook 帐户）创建并向用户展示同意屏幕。

4. 用户同意 LinkedIn 应用程序仅访问其 Facebook 个人资料照片的请求。

5. 在获得用户批准后，Facebook 授权服务器将授权码发送回请求的 LinkedIn 应用程序。

6. LinkedIn 应用程序随后使用授权代码向授权服务器（Facebook 账户）请求访问令牌。

7. 授权服务器识别 LinkedIn 应用程序并检查认证代码的有效性。如果访问令牌验证通过，服务器会向 LinkedIn 应用程序发放访问令牌。

8. LinkedIn 应用程序现在可以使用访问令牌访问资源，例如 Facebook 个人资料照片。

   OAuth 2.0 比 OAuth 1.0 更快，且更容易实现，现在是最常用的版本。

JSON Web 令牌（JWT）是一种简单且易于访问的令牌格式，可与 OAuth 一起使用，并且在 OpenID 中广受欢迎；我们接下来会讨论这个。

JWT

JWT 是一种紧凑且自包含的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。这些信息可以通过数字签名进行验证和信任。JWT 可以使用密钥或公/私钥对进行签名。

JWT 具有 JSON 结构，其中包含关于过期时间、发行者、主题等的信息。它比简单 Web 令牌（SWT）更强大，比 SAML 2.0 更简洁。你可以在以下截图中看到 JWT：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_07.png

图 7.7：JWT 示例

上面的截图展示了 JWT，它分为三个部分，每个部分之间由点分隔。第一部分是头部，告诉我们令牌类型——JWT——以及它使用的签名算法，例如 HS256 或 RSA。第二部分是有效载荷，包含声明，即关于用户及其他数据的信息。最后一部分是签名，它确保令牌没有被篡改，并确认了发送 JWT 的人。

JSON 的结构比 XML 简单，而且更小，这使得 JWT 比 SAML 更紧凑。JWT 是将信息传递到 HTML 和 HTTP 环境中的绝佳选择。由于其小巧的体积，JWT 是在微服务架构中在服务之间传递经过认证用户身份的理想选择，或者用来提供让用户访问资源的访问令牌。它们在各种身份验证和授权场景中都有应用，尤其是在 Web 和移动应用程序中。

在本节中，你了解了最常见的用户管理工具和服务。然而，还有许多其他协议和服务可用于用户身份验证和授权。前面提到的协议实现可能会很复杂，而且有大量打包软件可以简化这项工作。

Amazon Cognito 是 AWS 提供的用户访问管理服务，包含基于标准的授权，如 SAML 2.0、OIDC 和 OAuth 2.0，并且提供一个企业用户目录，支持与 AD 连接。Okta 和 Ping Identity 提供企业用户管理，并能在一个地方与各种服务提供商工具进行通信。

一旦您的应用程序暴露于互联网，始终会有各种类型的攻击可能发生。让我们学习一些最常见的攻击方式，以及如何为 Web 层保护设置第一层防御。

处理 Web 安全

随着用户需求的变化，要求服务全天候 24/7 可用，企业正在向线上模式转型，为此，它们采用了 Web 应用程序模型。Web 应用程序还帮助企业获得全球客户群。像在线银行和电子商务网站这样的企业始终保持在线，并且处理敏感的客户数据，如支付信息和支付者身份。

现在，Web 应用程序已经成为任何企业的核心，这些应用程序暴露在全球互联网上。Web 应用程序可能存在漏洞，使其容易受到网络攻击和数据泄露的威胁。让我们来探讨一些常见的网络攻击类型，以及如何减轻这些风险。

网络攻击

Web 应用程序容易受到安全漏洞的影响。黑客从不同的位置和使用各种方法协调网络攻击。就像您锁住并保护物理建筑一样，您的 Web 应用程序也需要防止非法活动。让我们探讨一些可能导致 Web 应用程序安全漏洞的常见攻击方式。

拒绝服务和分布式拒绝服务攻击

拒绝服务（DoS）攻击试图使您的网站无法访问。为了成功实施 DoS 攻击，攻击者使用各种技术消耗网络和系统资源，从而中断合法用户的访问。攻击者使用多个主机来协调攻击一个单一的目标。

分布式拒绝服务（DDoS）攻击通过使用许多被劫持的系统，通常是被恶意软件感染的系统，向单一目标系统发送大量请求。这会使目标系统不堪重负，导致服务中断。攻击者远程控制被感染的系统发起攻击。如以下图所示，当多个系统消耗目标系统的带宽资源时，就会发生 DDoS 攻击：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_08.png

图 7.8：DDoS 攻击

DDoS 攻击的基本概念是利用额外的主机来放大对目标发出的请求，使其超载并无法使用。DDoS 攻击通常是由多个被感染的系统发起的，僵尸网络向目标系统发送大量流量。

僵尸网络是通过恶意软件感染并控制的设备网络。

最常见的 DDoS 攻击发生在应用层，使用 DNS 洪水攻击或 安全套接字层 (SSL) 协商攻击。在 DNS 洪水中，攻击者通过过多请求消耗 DNS 服务器的资源。在 SSL 协商中，攻击者发送大量无法理解的数据，用于计算密集型的 SSL 解密。攻击者还可以对服务器集群执行其他基于 SSL 的攻击，使其不堪重负。

在基础设施层，典型的 DDoS 攻击以以下形式发生：

• 用户数据报协议 (UDP) 反射：通过 UDP 反射，攻击者伪造目标服务器的 IP 地址，发起请求，从被黑的反射服务器返回放大的响应。

• SYN 洪水：通过 SYN 洪水，攻击者通过创建并放弃大量连接来耗尽目标服务器的 传输控制协议 (TCP) 服务，从而阻止合法用户访问服务器。

攻击者通常试图窃取敏感的客户数据，为此他们使用一种称为 SQL 注入 (SQLi) 的不同攻击方式。让我们了解更多关于它的信息。

SQLi 攻击

顾名思义，在 SQLi 攻击中，攻击者注入恶意的 结构化查询语言 (SQL)，以控制 SQL 数据库并获取敏感用户数据。攻击者利用 SQLi 访问未经授权的信息，控制应用程序，添加新用户等。

以贷款处理的 Web 应用程序为例，你有一个 loanId 字段，客户可以用它来获取与其贷款相关的所有信息。如果没有采取适当的防护，攻击者可以执行如 SELECT * FROM loans WHERE loanId = 117 or '1=1' 的查询，并获取整个客户数据库的访问权限，因为这个查询始终会返回真结果。

另一种通过脚本注入来黑客入侵用户数据的常见方式是 跨站脚本 (XSS)，黑客伪装成合法用户。让我们了解更多关于它的信息。

XSS 攻击

你可能遇到过伪装成你熟悉网站的钓鱼邮件链接。点击这些链接可能导致通过 XSS 被泄露的数据。在 XSS 攻击中，攻击者将其恶意代码嵌入合法网站。当无辜用户访问网页时，这段代码就会执行。

攻击者可以通过多种方式引入此代码，例如将其直接嵌入 URL 字符串中，或者通过在网页上插入一段 JavaScript 代码。当你加载网页时，这段客户端 JavaScript 代码会执行，并窃取你的浏览器 cookies。

这些 cookies 通常包含敏感信息，例如你的银行或电子商务网站的访问令牌和身份验证。利用这些被窃取的 cookies，黑客可以进入你的银行账户，甚至其他账户，窃取你的辛苦钱。

跨站请求伪造攻击

跨站请求伪造（CSRF）攻击利用用户身份，通过制造混乱并欺骗已认证的用户进行状态更改操作，例如，修改购物网站的密码或请求将钱转账到你的银行账户。

它与 XSS 攻击略有不同，因为 CSRF 攻击者尝试伪造请求，而不是插入代码脚本。例如，攻击者可以伪造一个请求，要求从用户的银行账户转账一定金额，并将该链接通过电子邮件发送给用户。当用户点击这个链接时，银行收到请求并将钱转账到攻击者的账户。如果攻击者能够进入管理员账户，CSRF 攻击会特别危险。

缓冲区溢出和内存损坏攻击

软件程序会将数据写入一个临时内存区域，以便快速处理，这个区域叫做缓冲区。在缓冲区溢出攻击中，攻击者可以覆盖与缓冲区相关的内存部分，故意引发缓冲区溢出，并访问连接的内存区域，其中可能存储着应用程序的可执行文件。攻击者可以将可执行文件替换为实际的程序，从而控制整个系统。整体来看，基础设施层、网络层和数据层存在更多的安全威胁。接下来，我们将探讨一些标准方法来减轻和预防 web 层的安全风险。

Web 安全缓解

安全性需要应用到应用程序的每一层，特别需要关注 web 层，因为它直接暴露给外部世界。对于 web 的保护，必要的步骤包括跟进最新的安全补丁、遵循最佳的软件开发实践，并确保正确的身份验证和授权得以执行。

有几种方法可以保护和确保 web 应用的安全；我们来探讨两种常见的方法。

Web 应用防火墙

WAF 是一种防火墙，它应用于 HTTP 和 HTTPS 流量（即端口 80 和 443）。WAF 会检查你的 web 流量，并验证它是否符合预期的行为规范。它们提供了一层额外的保护，防止 web 攻击。

WAF 限速是通过查看发送到服务的请求数量或类型，并定义一个阈值，限制每个用户、会话或 IP 地址所允许的请求次数。通过批准和不批准列表，你可以明确地允许或阻止用户。

AWS WAF 是一个 Web 应用防火墙（WAF）的例子，它通过创建并应用规则来过滤 Web 流量，从而为你的 Web 层增加安全性。这些规则基于诸如 HTTP 头、用户地理位置、恶意 IP 地址、自定义 统一资源标识符 (URIs) 等条件。AWS WAF 规则可以阻止常见的 Web 攻击，如 XSS 和 SQL 注入。你可以为一个运行多个网站和 Web 应用程序的环境创建一组规则，并且可以跨应用重用规则，而无需重新创建它们。

总体而言，WAF 是一种应用规则集以处理 HTTP 流量的工具。它基于 IP 地址、HTTP 头、HTTP 正文或 URI 字符串等数据来过滤 Web 请求。它可以通过卸载非法流量来缓解 DDoS 攻击。让我们进一步了解 DDoS 缓解。

DDoS 攻击缓解

弹性架构可以防止或缓解 DDoS 攻击。保持基础设施安全的基本原则是减少攻击者可能攻击的目标数量。简而言之，如果某个实例不需要公开，就不要让它公开。

你可以采用多种策略来最小化攻击面：

• 在可能的情况下，减少必要的互联网入口点数量——例如，开放传入的互联网访问到你的负载均衡器，而不是到 Web 服务器。

• 识别并消除任何不必要的互联网入口点。例如，你可以为供应商设置文件共享存储以上传数据，但应将访问权限限制在一个有限的群体中，而不是让全球互联网流量都能访问。

• 隐藏任何必要的互联网入口点，以防止不受信任的终端用户访问它们。

• 隔离访问点，并对终端用户流量与应用管理流量应用特定的限制策略。

• 创建一个解耦的互联网入口点，以最小化攻击面。

你的主要目标是在 CDN 的边缘位置缓解 DDoS 攻击。如果 DDoS 攻击渗透到你的应用服务器，处理起来会更具挑战性且成本更高。以下图示展示了 AWS 云工作负载的 DDoS 缓解示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_09.png

图 7.9：DDoS WAF 三明治缓解策略

上述图示展示了一个 WAF 三明治架构，其中 WAF 设备被放置在两个负载均衡器之间，以应对 DDoS 攻击。

常见的 DDoS 攻击来自如 SYN 洪水和 UDP 反射等策略，Amazon CloudFront 通过只接受格式正确的连接，防止攻击策略在到达应用服务器之前进入。像 Amazon CloudFront 这样的 CDN 通过将 DDoS 攻击隔离到地理上独立的地点，并防止流量影响其他位置，来帮助应对 DDoS 攻击。网络防火墙安全帮助你在单个服务器级别控制进出流量。

如上一节所述，WAF（Web 应用防火墙）用于保护 Web 应用免受 XSS 和 SQLi 等漏洞攻击。除此之外，WAF 还帮助检测和防止 Web 应用层的 DDoS 攻击。

要应对 DDoS 攻击，你可以应用水平或垂直扩展。你可以通过以下方式利用扩展：

1. 首先，选择适合你 Web 应用程序的服务器大小和配置。

2. 其次，使用负载均衡器将流量分配到服务器群集，并添加自动扩展功能，根据需要添加或移除服务器。

3. 最后，使用 CDN 和 DNS 服务器，因为它们是为了处理大规模流量而设计的。

针对 DDoS 攻击进行扩展是一个很好的例子，说明了为服务器设置合理的最大数量是非常必要的。DDoS 攻击可能会将你的服务器扩展到一个极为昂贵的数量，而仍然可能无法防止服务器变得不可用。为常规流量波动设定合理的最大限制，可以避免 DDoS 攻击给公司带来过大的经济损失。

在本节中，你了解了 Web 层的各种安全风险和漏洞以及一些标准的保护方法。由于安全性需要应用于每一层，让我们更详细地探讨如何保护基础设施层。

保护应用程序及其基础设施

在上一节中，你了解了如何保护 Web 层。由于安全性需要应用于工作负载的每一层，让我们学习如何保护架构中的应用层和网络层。

应用程序和操作系统加固

虽然无法完全消除应用程序中的漏洞，但你可以通过加固应用程序的操作系统、文件系统和目录来限制系统攻击。一旦攻击者能够进入你的应用程序，他们就可以获得 root 权限，并对整个基础设施发起攻击。

通过 加固权限 来限制目录，以将攻击限制在应用程序级别是至关重要的。在进程级别，限制内存和 CPU 使用率，以防止 DoS 攻击。

在文件、文件夹和文件分区级别设置正确的权限。避免将 root 权限授予应用程序或其用户。你应该为每个应用程序创建一个包含所需访问权限的独立目录，这样只有需要的用户才能访问应用程序。对于某些应用程序，只使用公共访问权限。

通过使用 DAEMON Tools 和 Supervisord 等进程工具来自动化应用程序重启，以避免人工操作，防止用户需要登录服务器进行启动。对于 Linux 操作系统，像 systemd 或 System V init 脚本这样的工具可以启动/停止应用程序。

软件漏洞缓解与安全编码

始终建议应用操作系统厂商提供的最新安全补丁。这有助于修补系统中的安全漏洞，保护系统免受攻击者窃取安全证书或执行任意代码的威胁。

保持系统更新，及时安装最新的安全补丁非常重要。最好是自动化处理最新补丁的安装，一旦补丁发布就能迅速应用。然而，运行安全补丁有时可能会导致现有软件出现问题，因此，设置一个持续集成（CI）和持续部署（CD）的自动化测试和部署管道非常有用。你将在第十一章，DevOps 和解决方案架构框架中深入了解 CI/CD 流程。

AWS 云提供了一种系统管理工具，允许你在云中应用安全补丁并监控你的服务器群。你可以使用像自动更新或无人值守升级这样的工具来自动化安装安全补丁。当你选择云提供商的托管服务时，实际上是解放了你对底层基础设施的运维负担。云提供商负责服务的设置、管理、操作和优化。这包括定期的维护任务，如补丁安装，这对安全性和性能至关重要。

确保将安全编码最佳实践整合到你的软件开发过程中，正如开放网页应用安全项目（OWASP）推荐的，更多信息请参考：owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction。

网络安全

在保护基础设施时，确保网络安全应该是你的首要考虑。数据中心的物理安全由数据中心提供商负责。我们来谈谈如何确保网络安全，这部分是作为应用程序所有者的你需要负责的。

让我们以 AWS 等公有云服务提供商为例，帮助你理解网络安全。你可以将这个示例应用到你的本地或私有云网络基础设施中。

如下图所示，安全性应该在每一层都得到应用，并且应该定义每一层的受信边界，确保最小化访问权限：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_10.png

图 7.10：基础设施安全的网络配置

在前面的图中，负载均衡器位于公有子网中，可以接受互联网流量并将其分发到应用程序服务器群。WAF 根据设定的规则过滤流量，保护应用程序免受各种攻击，正如你在上一节中所学的那样。应用程序服务器群和数据库服务器位于私有子网中，这意味着它们无法直接访问互联网。

让我们深入分析前面的架构图，并逐层进行讲解：

• Amazon 虚拟私有云（VPC）为你的云基础设施提供了一个逻辑上隔离的网络。它作为你在云中的个性化网络环境，承载各种资源。为了更好地控制，它允许将不同的环境和资源进行隔离。你可以在每个 AWS 账户或区域内设置多个 VPC。在设置 VPC 时，你需要使用无类域间路由（CIDR）符号定义其 IP 地址范围。这种符号是一种简洁的表示特定 IP 地址范围的方式。例如，CIDR 块 10.0.0.0/16 包括从 10.0.0.0 到 10.0.255.255 所有 IP 地址。这个范围包含总共 65,535 个可用的 IP 地址。

• 子网是网络的一部分，通过 CIDR 范围划分，用于建立私有资源和公有资源之间的安全边界。与其按应用程序或功能（如 Web、应用或数据层）组织子网，不如根据互联网访问需求进行安排更为高效。这种设置能在子网级别实现明确的隔离，将面向公众的资源与私有内部资源区分开来。

  在此设置中，需要互联网访问的资源，如面向公众的负载均衡器、网络地址转换（NAT）实例和堡垒主机，都会被放置在公有子网中。其他资源，如数据库和应用程序，将放置在私有子网中。这种方式创建了不同资源层之间的明确分隔，将应用程序实例和数据资源分别分配到各自的私有子网。在 AWS 中，大多数资源可以托管在私有子网中，只有在需要互联网访问时才使用公有子网。因此，建议为你的私有子网分配比公有子网更多的 IP 地址，以确保为大多数将驻留在私有网络中的资源提供足够的空间。子网通过网络访问控制列表（NACL）规则提供基本的资源隔离，但安全组则提供更为细致的流量管理。这种方法避免了基础设施过于复杂以及 IP 地址使用效率低下的问题。

• 路由表由规则组成，这些规则被称为路由，决定哪些应用程序服务器接收网络流量。为了增强安全性，建议为每个子网使用不同的自定义路由表。

• 安全组作为虚拟防火墙，管理一个或多个实例的入站和出站流量。这些实例可以在给定的 CIDR 块范围内指定，或者可以是另一个指定安全组的一部分。遵循最小权限原则，安全组默认设置为拒绝所有入站流量。然后，您可以建立特定的规则，根据协议（如 TCP、UDP 和互联网控制消息协议（ICMP））来过滤流量。此设置确保只有必要且授权的流量可以访问您的实例，从而增强网络安全性。

• NACL是一个可选的安全层，作为虚拟防火墙控制您网络中子网级别的入站和出站流量。与安全组不同，安全组是有状态的，而 NACL 是无状态的。无状态性意味着每个请求，无论是入站还是出站，都是独立处理的。例如，即使一个入站请求被允许通过，相关的出站响应也必须通过在 NACL 中设置的规则明确允许。这要求您精确地定义入站和出站流量规则，以确保子网级别的流量流动和安全。

• 互联网流量通过互联网网关（IGW）路由，以使子网变为公网。默认情况下，您的环境中会拒绝互联网流量的访问。需要将 IGW 附加到您的 VPC，并且子网的路由表应定义 IGW 的规则。

• 私有子网阻止所有进出互联网的流量，但服务器可能需要外向互联网流量来进行软件和安全补丁安装。NAT 网关使得私有子网中的实例能够发起向互联网的外向流量，并保护资源免受来自互联网的流量。

• 堡垒主机充当跳板服务器，允许访问私有子网中的其他资源。堡垒主机需要进行加固，确保只有授权的人员可以访问它。要登录服务器，请始终使用公钥密码学进行身份验证，而不是常规的用户 ID 和密码方法。

组织通常会出于多种原因收集、存储和审查网络流量日志。这些原因包括诊断连接问题、解决安全问题和评估网络访问策略。您需要监控系统 VPC 的流量，这包括记录来自网络的入站和出站流量信息。VPC 流日志使您能够捕获这些信息，以及指定资源的接受和拒绝流量信息，帮助您更好地了解流量模式。

流日志作为监控流量到实例的安全工具。你可以为特定流量类型设置报警，并创建度量标准来发现趋势和模式。流日志可以为 VPC、子网或网络接口创建。当为子网或 VPC 创建时，它们会监控该子网或 VPC 内的每个网络接口。例如，假设你有一个包含多个子网的 VPC。通过为 VPC 设置流日志，你可以监控其网络接口上的所有进出流量。如果你注意到异常的流量模式，比如来自未知 IP 地址的数据请求突然激增，你可以配置报警来提醒你。这种主动监控有助于及早识别潜在的安全威胁或网络低效。

如你所见，在网络层面有多层安全防护可用于保护你的基础设施。将资源保存在其独立的子网中有助于减少爆炸半径。如果攻击者能够突破一个组件，你应该能够将其限制在有限的资源中。你可以在基础设施前使用 IDS 和 IPS 来检测和阻止任何恶意流量。接下来我们来了解它们。

入侵检测系统和入侵防御系统

IDS 通过识别攻击模式，检测通过网络流量发生的任何网络攻击。IPS 则进一步主动帮助阻止恶意流量。

IPS 提供对潜在威胁的关键分析，位于防火墙后面。它可以识别危险的内容，如恶意数据包，并可以阻止流量或重置连接。IPS 使用两种主要的检测方法：

• 基于特征的检测：这种方法依赖于一个不断增长的数据库，其中包含与每个已知漏洞相关的唯一模式或“特征”。

• 基于统计异常的检测：这种方法建立正常网络性能的基准，并将网络流量的随机样本与此基准进行比较。如果流量偏离基准较大，IPS 会介入。

你需要确定 IDS/IPS 系统是否适用于你的应用需求。IDS 可以是基于主机的，也可以是基于网络的。

基于主机的 IDS

基于主机或代理的 IDS 在你环境中的每个主机上运行。它可以检查该主机内的活动，以确定是否发生了攻击并且攻击是否成功。它可以通过检查日志、监控文件系统、监控与主机的网络连接等方式来实现。然后，软件或代理与一个中央/指挥应用程序沟通，报告它所监控的主机的健康状况或安全性。

主机基础的解决方案的优点包括能够深入检查每个主机内部的活动。它们可以根据需要进行横向扩展（每个主机都有自己的代理），并且不需要影响正在运行的应用程序的性能。缺点包括如果在许多服务器上管理代理，可能会引入额外的配置管理开销，这对组织来说是负担。

由于每个代理在隔离状态下运行，广泛的/协调性的攻击可能难以检测。为了处理协调攻击，系统应该在所有主机上立即响应，这需要主机基础的解决方案与部署在主机上的其他组件（如操作系统和应用接口）合作。

基于网络的 IDS

基于网络的 IDS 将一个设备插入到网络中，所有流量都会通过该设备进行路由，并检查是否存在攻击。

优点包括只需部署和管理一个简单/单一的组件，且该组件不在应用主机上。此组件也可以以可能对所有主机造成负担的方式进行加固或监控。安全的单一视图存在于一个地方，以便可以检查整体情况是否存在异常或攻击。

然而，基于网络的入侵检测系统（IDS）则包括了增加一个网络跳点对应用程序性能的影响。必须解密/重新加密流量以进行检查，这不仅是一个巨大的性能损失，也是一个安全风险，使得网络设备成为一个吸引的目标。IDS 无法解密的任何流量都无法进行检查/检测。

IDS 是一个检测和监控工具，不能自行采取行动。IPS 根据设定的规则检测、接受并拒绝流量。IDS/IPS 解决方案通过其异常检测能力帮助防止 DDoS 攻击，使其能够识别何时有效协议被用作攻击工具。IDS 和 IPS 通过分析网络数据包并将其内容与已知威胁的数据库进行比较来工作。这个过程使它们能够识别并响应潜在的安全风险。为了主动保护您的基础设施免受任何攻击，必须进行持续的审计和扫描。

在这一部分，你学习了如何保护你的基础设施免受各种类型的攻击。这些攻击的目标是获取你的数据。你应该以某种方式保护你的数据，使得攻击者即使获取了数据，也无法获得敏感信息。接下来，让我们了解如何使用数据层安全性、加密和备份来保护数据。

数据安全

在今天的数字化世界中，每个系统都围绕数据运转。有时，这些数据可能包含敏感信息，如客户健康记录、支付信息和政府身份信息。确保客户数据的安全，防止未经授权的访问至关重要。许多行业都对数据保护和安全性施加了巨大压力。

在设计任何解决方案之前，你应该定义与目标相一致的基本安全实践，例如遵守监管要求。

有几种不同的方法用于保护数据。我们将在接下来的章节中讨论这些方法。

数据分类

最佳实践之一是对数据进行分类，这为根据敏感性级别对组织数据进行分类和处理提供了一种方式。

根据数据敏感性，你可以规划数据保护、数据加密和数据访问要求。

通过根据系统的工作负载需求进行数据分类，你可以创建所需的数据控制和访问级别。例如，像用户评分和评论这样的内容通常是公开的，允许公开访问是可以接受的，但用户的信用卡信息是高度敏感数据，需要加密并受到严格的访问限制。

从高层次来看，你可以将数据分类为以下几类：

• 受限数据：这类数据包含一旦泄露会直接对客户造成危害的信息。处理不当可能会损害公司的声誉，并对业务产生不利影响。受限数据可能包括客户的个人身份信息（PII），例如社会保障号码、护照信息、信用卡号码和支付信息。

• 私密数据：如果数据包含可能被攻击者用来策划获取受限数据的客户敏感信息，则可以将其归类为私密数据。私密数据可能包括客户的电子邮件地址、电话号码、全名和地址。

• 公开数据：这些数据对所有人可用且可以访问，保护要求较低——例如，客户评分和评论、客户位置，以及如果用户将其公开，客户的用户名。

你可以根据行业类型和用户数据的性质设立更细化的分类。数据分类需要平衡数据的可用性与数据的访问权限。设置不同级别的访问权限，正如前面提到的，有助于限制只有必要的数据，并确保敏感数据不被暴露。始终避免直接给人类访问数据的权限，并增加一些工具来生成只读报告，以限制用户的访问方式。

静态数据加密

静态数据是指存储在某个地方的数据，例如存储区域网络（SAN）、网络附加存储（NAS）驱动器或云存储。所有敏感数据必须通过本节中解释的对称或非对称加密进行保护，并采用适当的密钥管理。

除了加密，还有其他方法可以保护静态数据，例如数据掩码和令牌化。这些方法提供了额外的安全层，特别适用于需要使用或共享敏感信息而不暴露实际数据的情况。

数据加密是一种保护数据的方式，您可以通过使用加密密钥将数据从明文转换为编码的密文格式。此密文需要使用解密密钥进行解密才能读取，且只有授权用户可以访问解密密钥。

常用的基于密钥的加密属于两类密码学之一：

• 对称密钥加密：使用对称加密算法时，数据的加密和解密都使用相同的密钥。每个数据包都使用一个秘密密钥进行自我加密。数据在保存时被加密，在检索时被解密。对称加密曾经按照数据加密标准（DES）应用，该标准使用了一个 56 位的密钥。如今，高级加密标准（AES）被广泛应用于对称加密，因为它使用 128 位、192 位或 256 位的密钥，提供了更高的可靠性。

• 非对称密钥加密：借助非对称算法，可以使用两种不同的密钥：一个用于加密数据，另一个用于解密数据。在大多数情况下，加密密钥是公钥，解密密钥是私钥。非对称密钥加密也称为公钥加密。公钥和私钥是不相同的，但它们是成对的。私钥只对一个用户可用，而公钥可以分发给多个资源。只有持有私钥的用户才能解密数据。里韦斯特–沙密尔–阿德尔曼（RSA）是最早也是最流行的公钥加密算法之一，广泛用于保护网络上的数据传输。

数据加密和解密会带来性能开销，因为它们增加了额外的处理层。在选择加密数据时，您需要仔细权衡。最好仅在必要时使用加密，以减少性能损失和密钥管理开销。

如果使用 AES 256 位安全密钥对数据进行加密，几乎不可能破解该加密。解密的唯一方法是获取加密密钥，这意味着您需要保护好您的代码并将其保存在安全的地方。让我们了解一些基本的管理方法，以保障您的加密密钥。

加密密钥管理

密钥管理对于有效的加密至关重要。它确保只有授权人员可以访问和管理加密密钥。密钥管理包括密钥的创建、存储、轮换和删除，并控制谁可以访问这些密钥。信封加密是一种特定的密钥管理技术，通常用于对称加密，其中数据密钥加密明文，而主密钥加密数据密钥。通过要求两个密钥进行解密，这种方法增强了安全性，增加了额外的保护层。

AWS 密钥管理服务（KMS）提供信封加密功能。它提供一个安全的环境，其中数据密钥加密客户数据，KMS 的主密钥则加密数据密钥。该服务提供集中式的密钥管理控制，包括用户访问和密钥轮换。

AWS KMS 是一个多租户的密钥管理模块。其他云供应商也提供类似的密钥管理系统，如 GCP 的云密钥管理和微软的 Azure Key Vault。

有时，基于监管要求，客户更倾向于选择包含物理硬件安全的专用密钥管理存储。在这种情况下，他们可以选择将密钥存储在硬件安全模块（HSM）中。像 AWS 这样的云提供商也提供此类存储，如 AWS CloudHSM。您也可以选择自己喜欢的 HSM 供应商。

HSM 是一种专门设计用于保护加密密钥和操作的设备，具有强大的物理和逻辑安全机制。在物理层面，它能够检测和响应篡改行为，通过删除密钥来防止泄露。在逻辑层面，它采用严格的访问控制，只允许授权用户对设备进行特定角色和操作。为了防止数据丢失，确保 HSM 的高可用性至关重要，通常通过在不同位置部署多个单元来实现。

传输中的数据加密

传输中的数据是指通过网络传输的数据。您可以在源和目标上对数据进行静态加密，但在传输数据时，您的数据传输管道需要是安全的。当通过未加密的协议（如 HTTP）传输数据时，可能会受到窃听攻击或中间人攻击（MITM）的威胁。

在窃听攻击中，攻击者捕获来自网络的小数据包，并利用它搜索任何其他类型的信息。中间人攻击是一种基于篡改的攻击，攻击者秘密地更改通信内容，以代表接收方进行通信。这类攻击可以通过使用强协议（如传输安全层（TSL））通过 SSL 传输数据来预防。

您会发现，现在大多数网站都使用 HTTPS 进行通信，通过 SSL 加密数据。默认情况下，HTTP 流量是不受保护的。所有 Web 服务器和浏览器都支持 HTTP 流量的 SSL/TSL 保护（HTTPS）。HTTP 流量还适用于面向服务的架构，如表现层状态转移（REST）和简单对象访问协议（SOAP）架构。

SSL/TSL 握手使用证书来交换公钥，采用非对称加密，然后使用公钥交换私钥，采用对称加密。安全证书由可接受的认证机构（CA）颁发，例如 Verisign。获取的安全证书需要通过公钥基础设施（PKI）进行保护。以下是使用 RSA 密钥交换的标准 SSL 握手过程概述：

1. 客户端 Hello：客户端通过向服务器发送消息来启动 SSL 通信。此消息包括 SSL 版本号、首选密码设置以及与用户会话相关的数据。

2. 服务器 Hello：服务器回应客户端，同意使用 SSL 进行通信。它验证 SSL 版本号，并发送包含公钥的证书。

3. 认证与预主密钥生成：客户端验证服务器的证书，检查证书的常用名称、有效期和颁发机构。然后，客户端基于所选密码生成预主密钥，并使用服务器的公钥加密后发送给服务器。

4. 解密与主密钥创建：服务器使用其私钥解密预主密钥。双方随后使用该预主密钥生成主密钥，按照所选密码的步骤进行。

5. 会话密钥加密：服务器和客户端都发送消息，表明后续的通信将使用会话密钥加密，也称为共享密钥。他们确认消息加密和解密成功，确保会话中剩余的通信能够安全加密。

网络上传输的数据也应加密，包括安全外壳协议（SSH）和互联网协议安全（IPsec）加密。SSH 在连接到服务器时最为常见，而 IPsec 则用于保护通过虚拟专用网络（VPN）传输的公司流量。文件传输应使用SSH 文件传输协议（SFTPS）或FTP 安全（FTPS）进行加密，电子邮件服务器通信则需要通过简单邮件传输协议安全（SMTPS）或互联网邮件访问协议（IMAP）来加密。

在本节中，你了解了使用不同加密技术来保护静态数据和传输数据的各种方式。

数据备份和恢复是保护数据免受任何突发事件影响的重要方面。你将在第八章、架构可靠性考虑中的灾难恢复规划部分了解更多有关数据备份的信息。

安全 API

应用程序编程接口（APIs）是不同软件系统之间的连接纽带。它们促进无缝的互动和数据传输。将 API 想象成餐厅中的服务员；你（软件应用）向服务员（API）提出订单（请求），然后服务员从厨房（另一个软件系统或数据库）拿回菜肴（数据/响应）。由于 API 在现代软件基础设施中，特别是在云服务和微服务架构中的关键作用，它们已成为网络攻击者的诱人目标。因此，确保 API 安全性比以往任何时候都更为重要。API 本身就暴露了可能涉及敏感应用功能和数据的入口。若未进行妥善安全防护，API 可能导致各种威胁，例如未经授权访问敏感数据、数据破坏、拒绝服务，甚至是完全的系统妥协。此外，考虑到当今软件生态系统的互联性，一个 API 的漏洞可能会危及整套应用程序和服务的安全。随着企业日益依赖 API 来集成第三方服务并实现支付网关等功能，API 被攻破的后果可能非常严重，影响收入、品牌声誉和法律地位。

以下是确保 API 安全性的一些最佳实践：

• 身份验证和授权：采用强身份验证方法，如 OAuth 或 JWT，来确认尝试访问 API 的实体身份。此外，实施有效的授权协议来管理访问权限。这意味着，即使是已通过身份验证的用户，也只能访问他们明确被授权的数据和功能。一个安全的 API 知道谁在发起请求，以及该实体被允许访问的内容。

  一款银行应用程序使用 API 允许用户查看账户余额。该应用程序使用 OAuth 来确保只有经过身份验证和授权的用户才能查看他们的特定账户信息。

• 速率限制：实施速率限制，以防止任何形式的滥用，包括暴力破解攻击。通过限制用户或 IP 在特定时间范围内可以发出的请求次数，您可以阻止潜在攻击者通过大量快速尝试不同的组合来压垮系统。在线商店的 API 可以限制用户每分钟的请求次数，防止系统过载和潜在滥用。

• 输入验证：始终验证并清理发送到 API 的数据。这可以防止各种类型的攻击，包括 SQL 注入（SQLi），攻击者通过发送恶意数据来操控系统。一个在线反馈表单使用 API 提交用户评论。系统会检查输入内容，以确保其中不包含可能危及网站安全的恶意脚本。

• 加密：传输到和从 API 的数据应该使用 TLS 等协议进行加密。这确保即使数据包被拦截，它们对未经授权的方也是无法理解的。一个消息应用确保用户之间发送的消息是加密的。如果有人拦截了这些消息，他们看到的只是乱码，而不是实际的内容。可以把它想象成用密码语言交谈。即使有人偷听了你的对话，除非他们懂得密码，否则他们也无法理解。

• 定期监控和审计：持续监控 API 活动。任何异常的模式，比如请求量突增或数据访问模式异常，可能是攻击或漏洞利用的早期迹象。定期审计还可以帮助发现任何存在的安全配置问题。一个云存储提供商监控其 API，以发现异常的数据传输模式，确保没有大量数据被意外下载或上传，这可能是安全漏洞的迹象。可以将其比作商店里的监控摄像头，它们监视活动，能够发现并阻止盗窃行为。

• 实现 API 网关：使用 API 网关可以作为额外的保护层。它们负责请求路由、API 组合和其他功能，确保只有合法的请求能够到达后端系统。一个电子商务网站使用 API 网关来管理请求，确保只有合法且结构良好的请求能够到达其数据库，过滤掉潜在的恶意请求。可以把它比作酒店礼宾，礼宾会在允许你进入房间之前检查并确认你的预订。

• 错误处理：避免通过错误信息暴露敏感信息。应返回通用的错误信息给用户，同时在服务器端安全地维护详细的错误日志以供诊断使用。当用户尝试重置密码且他们的电子邮件未被识别时，系统不会具体说明电子邮件是错误还是不存在。它仅提示用户重新尝试，从而防止潜在的数据钓鱼。

• 使用 Web 应用防火墙：WAF 可以检测并阻止对你的 API 的恶意请求，提供另一层防御，抵御常见的基于 Web 的威胁。例如，如果你在运营一个电子商务平台，WAF 可以审查进入 API 端点的流量，识别并阻止潜在的有害请求，如 SQL 注入和跨站脚本攻击（XSS）。这确保只有合法的请求得到处理，保护你的应用免受网络攻击。

• 版本控制：在你的 API 中实现版本控制。如果在某个 API 版本中检测到安全问题，可以在不影响其他版本的情况下进行修复，确保使用未受影响版本的应用程序服务持续可用。例如，假设你有一款依赖 API 获取用户数据的移动应用。通过实现版本控制（例如 v1、v2、v3），如果在 v2 版本中发现安全漏洞，你可以迅速修复该版本的问题，而旧版本（v1）和新版本（v3）则继续安全运行且不受影响。这种方法使你的开发团队能够对特定版本的 API 进行修补或升级，最小化对最终用户的影响。

• 定期安全测试：定期对你的 API 进行渗透测试和漏洞评估。这种主动的做法有助于在漏洞被利用之前识别并修复潜在的弱点。一个音乐流媒体平台定期测试其 API，确保未授权用户无法在没有有效订阅的情况下访问高级功能。

随着 API 在现代数字基础设施中发挥着核心作用，确保其安全性变得愈加重要。通过遵循行业最佳实践并保持积极的安全防范态势，企业能够保护其运营、客户和声誉免受任何威胁。

有许多管理机构发布关于数据安全的合规要求，这些要求可能以一套清单的形式呈现。合规还确保组织遵守行业和当地政府的规定。让我们在下一节中深入了解各种合规措施。

安全性和合规认证

许多用于保护客户隐私和确保数据安全的合规认证取决于你的行业和地理位置。对于任何解决方案设计，合规要求是必须评估的关键标准之一。以下是一些最广为人知的地理和行业标准合规要求：

• 全球合规认证包括所有组织必须遵守的认证，无论其所在地区。这些包括 ISO 9001、ISO 27001、ISO 27017、ISO 27018、SOC 1、SOC 2、SOC 3 和 CSA STAR（云安全）。

• 美国政府要求处理公共部门工作负载的各种合规性要求，包括 FedRAMP、DoD SRG Level-2、4 和 5、FIPS 140、NIST SP 800、IRS 1075、ITAR、VPAT 和 CJIS。

• 应用程序的行业级合规性适用于特定行业，包括 PCI DSS、CDSA、MPAA、FERPA、CMS MARS-E、NHS IG 工具包（英国）、HIPAA、FDA、FISC（日本）、FACT（英国）、共享评估和 GLBA。

• 地区合规认证适用于特定国家或地区。这些包括 EU GDPR、EU 模式条款、UK G-Cloud、中国 DJCP、新加坡 MTCS、阿根廷 PDPA、澳大利亚 IRAP、印度 MeitY、新西兰 GCIO、日本 CS Mark Gold、西班牙 ENS 和 DPA、加拿大隐私法以及美国隐私盾牌。

如您所见，不同的监管机构提供了许多与行业、地区和政府政策相关的合规性认证。我们不打算深入探讨合规性细节，但在开始解决方案设计之前，您必须评估您的应用程序是否符合合规性要求，因为合规性要求会对整体解决方案设计产生重大影响。您需要根据合规性需求决定所需的加密类型，以及日志记录、审计和工作负载的位置。

日志记录和监控有助于确保强大的安全性和合规性，并且是必不可少的。如果发生事件，您的团队应立即收到通知并准备响应。您将在第九章，运营卓越考虑事项中进一步了解监控和警报方法。

多个合规性行业依赖于您的应用程序的地理位置、行业和政府规则。您已了解不同类别的合规性以及适用于每个组的常见合规性标准。许多组织正在转向云，因此了解云中的安全性至关重要。

云的共享安全责任模型

随着云成为常态，许多组织将工作负载迁移到 AWS、GCP 和 Azure 等公共云，客户需要了解云安全模型。

云中的安全是客户与云服务提供商的共同努力。

客户负责使用云服务实施的内容以及连接到云的应用程序。在云中，客户对应用程序安全的责任取决于他们使用的云服务提供商以及系统的复杂性。

以下图表展示了来自最大公共云提供商之一（AWS）的云安全模型，几乎适用于任何公共云提供商，如 Azure、GCP、Oracle、IBM 和阿里巴巴：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_07_11.png

图 7.11：AWS 云共享安全责任模型

客户负责云中的安全，包括以下内容：

• 服务器的操作系统：安装在服务器上的操作系统可能会受到攻击。操作系统的修补和维护是客户的责任，因为软件应用程序严重依赖于操作系统。

• 应用程序：每个应用程序及其环境（如开发、测试和生产）由客户维护。因此，处理密码策略和访问管理是客户的责任。

• 操作系统/基于主机的防火墙：客户必须保护其整个系统免受外部攻击。云提供了该领域的安全性，但客户应考虑使用 IDS 或 IPS 来增加额外的安全层。

• 网络配置与安全组：云平台提供工具来创建网络防火墙，但需要停止或允许通过的流量取决于应用程序的要求。客户负责设置防火墙规则，以保护其系统免受外部和内部网络流量的侵害。

• 客户数据与加密：数据处理是客户的责任，因为客户更清楚所需的数据保护级别。云平台通过各种加密机制提供数据保护工具，但客户需要负责应用这些工具并确保数据安全。

如图 7.11所示，AWS 和其他公共云提供商负责确保云安全，特别是托管您资源的物理基础设施。这项安全措施涵盖了几个关键领域：

• 数据中心：AWS 数据中心是一些不起眼的设施，配备了全天候的保安。它们实施严格的访问控制，包括双因素认证、全面的访问日志记录和定期审核，以及视频监控。此外，AWS 还通过磁盘去磁和销毁等方法，确保数据存储设备的安全处置。

• 硬件基础设施：这包括服务器、存储设备以及支撑 AWS 服务的各种其他设备。AWS 确保这些硬件的安全性和完整性。

• 软件基础设施：这指的是 AWS 服务中使用的宿主操作系统、服务应用程序和虚拟化软件。AWS 维护这一软件层的安全性，确保它能够抵御威胁。

• 网络基础设施：AWS 保障其网络基础设施的安全，其中包括路由器、交换机、负载均衡器、防火墙、电缆等。这项安全措施的一部分是对网络外部边界进行持续监控。AWS 还维护着安全的访问点和冗余的网络基础设施，以防止中断并增强安全性。

为了使您的应用程序符合行业法规，如金融数据安全的 PCI-DSS 和欧洲数据保护的 GDPR，您需要处理并完成针对应用层的合规审核。公共云提供了适用于它们所管理硬件部分的各种合规认证。作为客户，您可以通过继承云服务提供商所提供的安全性和合规性，获得额外的优势。

云平台提供各种工具和服务来保障您的应用程序安全，并在 IT 基础设施层面提供内建安全性。然而，如何使用这些服务并确保应用程序在云中的安全，取决于客户自身。云平台提供了更强的可见性和集中控制，帮助有效管理和保护您的系统。

安全是任何解决方案的首要任务，解决方案架构师必须确保他们的应用程序是安全的，且能够防止任何攻击。目标是尽可能地融入自动化的安全最佳实践。利用基于软件的安全机制可以显著提高可扩展性、成本效益和整体安全性。从创建虚拟服务器的自定义基准镜像开始，该镜像包含了你的安全标准。然后，可以在每次部署新服务器时一致地使用该镜像，确保整个基础设施的安全性一致性。此外，在定义和管理的模板中设计整个基础设施。这种方法可以让你在每个新环境中复制已建立的安全最佳实践。

安全是一个持续的努力。每一次安全事件都应该被视为对应用程序的改进机会。一个强大的安全机制应该具备身份验证和授权控制。组织和应用程序应当自动响应安全事件，并在多个层次上保护基础设施。

威胁建模

威胁建模是一种结构化的方法，用于识别、评估和优先排序潜在的应用程序威胁。通过了解潜在威胁，你可以设计并实施适当的对策，以防止、检测或减轻这些威胁的影响。威胁建模通常用于软件开发，但也可以应用于其他领域，如基础设施和运营。

以下是威胁建模的组件：

• 系统表示：在分析威胁之前，你需要清楚地了解系统。这通常涉及创建系统架构、组件、数据流和潜在入口点的图表或模型。对于一个简单的在线电子商务网站，你可能有一个供用户使用的前端，一个处理请求的后端服务器，一个存储用户凭证的数据库，以及一个用于交易的外部支付网关。在推出一个允许用户保存多个送货地址的新功能之前，开发团队希望确保没有安全漏洞。他们创建了一个数据流图，展示了该新功能如何与现有系统交互。

• 威胁识别：根据系统的表示列举潜在的威胁。这可能包括使用像欺骗、篡改、否认、信息泄露、服务拒绝和权限提升（STRIDE）和攻击树等技术。对于我们的电子商务网站，威胁可能包括 SQL 注入（访问数据库）、钓鱼攻击（窃取用户凭证）或 DoS 攻击（使网站瘫痪）。团队意识到，允许用户保存地址可能会在发生数据泄露时暴露这些地址。他们将这个威胁与其他威胁一起列出。

• 威胁分析：评估每个已识别威胁的潜在影响和发生的可能性。这可以帮助你优先处理威胁。虽然 SQL 注入可能暴露大量敏感的用户数据，但钓鱼攻击可能影响较少的用户，但发生的可能性更大。开发团队评估，泄露已保存的地址可能导致用户信任丧失并可能被滥用。他们将此威胁评定为高严重性。

• 缓解策略：对于每个已识别的威胁，确定减少其风险的最佳行动方案。这可能包括添加安全控制、改变系统架构，甚至接受风险（如果其潜在影响是可以接受的）。为了防止 SQL 注入，团队可以使用参数化查询。为了应对钓鱼攻击，他们可能引入双因素认证。为了保护用户地址，团队决定在数据库中加密这些地址。他们还为任何与地址更改相关的可疑活动添加了警报。

• 文档：记录调查结果，包括潜在威胁、其严重性以及采取的缓解策略。创建一份文档，详细说明用户地址已加密及所使用的加密方法。六个月后，需要切换到另一个数据库。文档帮助新的数据库团队理解现有的安全措施。

• 审查和更新：威胁建模不是一次性的任务。随着系统的发展，新的威胁可能出现，而一些威胁可能变得不再相关。定期审查和更新威胁模型确保其始终保持相关性。电子商务网站决定引入一个新的聊天机器人功能。在部署聊天机器人之前，团队参考了他们的威胁模型，查看引入这一新功能是否会带来新的漏洞，或者现有的威胁是否发生了变化。

本质上，威胁建模帮助团队在安全工作中保持积极主动，在漏洞成为问题之前先行应对。

总结

在本章中，你学习了应用安全最佳实践的各种设计原则。这些原则包括通过使用适当的访问控制、数据保护和监控来保护应用程序的关键考虑因素。

你需要在每一层应用安全。从用户身份验证和授权开始，你学习了如何在 Web 层、应用层、基础设施层和数据库层应用安全。每一层都容易受到不同类型的攻击，而你学习了使用可用的技术选择来保护你的应用。

对于用户管理，你学习了如何使用 FIM 和 SSO 来处理企业用户，以及实现用户身份验证和授权的各种方法。这些方法包括像 Microsoft AD 和 AWS 目录服务这样的企业管理服务。你还可以通过 OAuth 2.0 处理数百万用户。

在 Web 层面，你了解了各种攻击类型，如DDoS、SQL 注入和XSS。你学习了如何使用不同的预防技术和网络防火墙来保护免受这些攻击。你了解了在应用层保护代码的各种技术，并确保基础设施的安全。你深入研究了不同的网络组件和方法，以建立受信任的边界来限制攻击范围。

你通过实施适当的数据分类并将数据标记为机密、私密或公开，学习了数据保护。你了解了对称和非对称算法以及它们之间的区别。你研究了如何使用密钥管理来保护公钥/私钥加密密钥。数据可以是活动的，也可以是静态存储的，你学习了如何在这两种模式下保护数据。你探讨了 API 安全性以及确保所有暴露应用程序的 API 都是安全的最佳实践。你了解了适用于云工作负载的各种合规性和共享安全责任模型。最终，你学习了如何构建威胁模型。

本章介绍了应用安全最佳实践，而可靠性是任何解决方案设计的另一个重要方面。为了使你的业务成功，你需要创建一个始终可用并能处理工作负载波动的可靠解决方案。在下一章中，你将学习如何利用现有技术使应用程序更可靠的最佳实践。你将学习各种灾难恢复和数据复制策略，以提高应用程序的可靠性。

留下评论！

享受这本书吗？通过在亚马逊上留下评价帮助像你一样的读者。扫描下面的二维码，获取你选择的免费电子书。

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/Image.png

第八章：8

架构可靠性考虑因素

应用程序可靠性是架构设计中的关键方面，是任何企业成功的关键。

可靠性意味着系统从故障中恢复的能力。这涉及使您的应用程序具有容错能力，能够从任何基础设施或服务器故障中恢复，而不会影响客户体验。您的系统应该做好准备，能够应对任何可能导致中断的情况。

随着各种企业现在都在线上，高可用性也成为在线应用程序的强制性标准。用户希望随时浏览您的应用程序，并在他们方便的时候完成购物和银行等任务。在本章中，您将学习各种设计原则，以使您的解决方案可靠。在评估可靠性时，您需要考虑架构的每个组件。您将了解如何选择合适的技术，以确保每一层架构的可靠性。

在本章中，您将学习以下最佳的可靠性实践：

• 架构可靠性的设计原则

• 架构可靠性的技术选择

• 通过云提升可靠性

本章结束时，您将了解各种灾难恢复技术和数据复制方法，以确保应用程序的高可用性和业务流程的持续性。

架构可靠性的设计原则

可靠性和高可用性（HA）是确保应用程序和基础设施能够满足用户需求、不中断地运行的基础支柱。可靠性侧重于系统在特定条件下和一定时间内正常运行的能力。

这涉及到设计系统以在尽可能小的范围内容纳和管理故障，最大程度地减少对整体操作的影响。该方法需要全面理解潜在的故障模式，并实施针对性的缓解策略，以防止这些故障发生或在故障发生后优雅地恢复。

在第二章中详细讨论的 HA 与可靠性密切相关，但重点是确保服务始终可访问。HA 策略涉及创建冗余系统和组件，以消除单点故障，从而在发生故障时实现无缝切换。其目标是在硬件故障、网络中断或软件漏洞的情况下，保持服务的连续性。通过将可靠性和 HA 集成到系统设计中，组织可以确保其应用程序能够抵御故障，并能够维持一致的服务水平。

本讨论包含了有助于增强系统可靠性的标准设计原则。您会发现，所有的可靠性设计原则是密切相关的，并且相辅相成。

通过应用自动化使系统具备自愈能力

将自愈能力和自动化集成到系统设计中，可以通过让系统预测并自动从故障中恢复，增强其可靠性。自愈系统能够主动检测并修复硬件、网络或软件等各个系统层面的故障，最大限度地减少对终端用户的影响。这一方法要求识别与你的应用程序和业务运营相关的关键关键绩效指标（KPI），例如每秒请求处理能力或网页加载时间。基础设施级别的 KPI 可能包括 CPU 和内存利用率的阈值，确保其不超过预定限制。

为了实现自愈架构，实施一个强大的监控系统，跟踪这些关键绩效指标（KPIs），并在它们接近临界阈值时发出警报。该系统应当有自动化策略支持，例如，当 CPU 使用率接近其最大允许百分比时，自动启动额外的服务器来应对增加的负载。这种积极的监控和自动响应不仅能防止潜在的故障，还能帮助系统在无需人工干预的情况下保持最佳性能水平。

此外，贯穿应用程序生命周期的自动化—从部署和配置到基础设施扩展—能够促进一个更加敏捷和有弹性的环境。它使你的团队能够快速部署新特性，更自由地进行实验，并确保系统在负载波动时仍保持一致的性能。通过根据预定需求或意外流量激增来自动化资源扩展，可以确保应用程序保持响应能力和可用性。通过利用自动化部署独立任务并汇总其结果，你不仅可以实现更高的可靠性和效率，还可以增强系统自我恢复事件的能力，使基础设施真正具备弹性和自我维持能力。

质量保证

经常需要将你在开发环境中使用的相同配置应用于质量保证（QA）环境。每个测试阶段可能有多个 QA 环境，包括功能测试、用户验收测试（UAT）和压力测试环境。

通常，QA 测试人员会发现由于资源配置错误导致的缺陷，这可能会进一步延迟测试进度。最重要的是，你不能在生产服务器中出现配置错误，因为这可能会导致大规模的停机，因此最好提前进行测试。

为了在你的开发环境和 QA 环境中精确复现相同的配置，你可能需要编写一步一步的配置说明。手动重复相同的配置步骤容易出错。总是存在人为错误的可能性，比如在数据库名称中打错字。解决这个问题的方法是通过创建脚本来自动化这些步骤。自动化脚本本身就是文档。

只要脚本正确，它比手动配置更可靠。它无疑是可复制的。检测不健康的资源并启动替代资源可以实现自动化，当资源发生变化时，你可以通知 IT 运维团队。自动化是一个基础的设计原则，应该在系统的各个方面应用。

创建一个分布式系统

单体应用程序在系统正常运行时间方面的可靠性较低，因为某个模块的小问题可能会导致整个系统崩溃。将你的应用程序拆分成多个小服务可以减少影响范围。应用程序的一个部分不应该影响整个系统，且应用程序可以继续提供关键功能。例如，在电子商务网站上，支付服务出现问题不应影响客户下单的能力，因为支付可以稍后处理。

在服务层面，水平扩展你的应用程序以提高系统的可用性。设计一个系统，使用多个较小的组件协同工作，而不是一个单一的整体系统，从而减少影响范围。在分布式设计中，请求由不同的系统组件处理，一个组件的故障不会影响系统其他部分的功能。例如，在一个电子商务网站上，仓库管理组件的故障不会影响客户下单。

然而，在分布式系统中，通信机制可能会变得复杂。这种复杂性源于确保在不同网络计算机之间可靠的数据交换的需求，每台计算机可能运行不同的操作系统，并且位于不同的地理区域。挑战包括应对网络延迟、处理消息传递保证、在各节点之间同步数据以确保一致性，以及实施容错机制以应对部分系统故障。此外，开发和维护一个高效支持分布式架构多样化需求的通信协议也增加了复杂性。

熔断器模式可以帮助处理系统依赖性。正如你在第四章《解决方案架构设计模式》中所学到的，基本概念很简单。你将一个受保护的函数调用包装在熔断器对象中，熔断器监控故障并采取自动化措施来减轻它们。

监控和增加容量

资源饱和是导致应用失败的最常见原因。通常，你会遇到因 CPU、内存或硬盘过载导致应用开始拒绝请求的问题。

在传统的本地环境中，你必须提前根据假设计算服务器容量。在线流量非常不可预测，且波动剧烈，受到全球趋势的驱动。通常，硬件采购需要 3 到 6 个月，而提前猜测容量非常困难。订购过多的硬件会导致额外成本，因为资源会闲置，而资源不足则会因为应用不可靠而导致业务损失。

你需要一个无需猜测容量的环境，且你的应用能够按需扩展。

像亚马逊 Web 服务（AWS）这样的公共云提供商提供基础设施即服务（IaaS），便于按需提供资源。

在云环境中，你可以监控系统的供需情况。你可以根据需要自动添加或移除资源。这使你能够维持一个足够满足需求的资源水平，避免过度配置或资源不足的情况。

执行恢复验证

在基础设施验证方面，大多数组织通常专注于验证一条顺利的路径，即一切都在正常运行。实际上，你应该验证系统是如何失败的，以及恢复过程的有效性。假设一切都可能失败，验证你的应用程序。不要仅仅依赖于你的恢复和故障转移策略能够正常工作，确保定期进行测试，以防万一出现问题时不会感到惊讶。

基于模拟的验证有助于发现潜在的风险。你可以自动化可能导致系统失败的场景，并相应准备事件响应。你的验证应当提高应用程序的可靠性，确保生产环境中不会发生故障。

恢复能力有时被忽视作为可用性的一部分。为了提高系统的恢复点目标（RPO）和恢复时间目标（RTO），你应该将数据、应用程序及其配置备份为机器镜像。在下一节中，你将了解更多关于 RTO 和 RPO 的内容。假设自然灾害导致一个或多个组件不可用，或者摧毁了你的主要数据源。在这种情况下，你应该能够快速恢复服务，且不会丢失数据。接下来，我们将讨论特定的灾难恢复策略，以提高应用程序的可靠性以及相关的技术选择。

架构可靠性的技术选择

应用程序可靠性通常关注应用程序是否能够持续为用户提供服务。有多个因素决定了你的应用程序是否具备高度可用性。然而，容错性指的是应用程序组件的内建冗余。你的应用程序可能是高度可用的，但并不一定具备 100%的容错能力。例如，如果你的应用程序需要四台服务器来处理用户请求，你可以将它们分配到两个数据中心以实现高可用性（HA）。

如果一个站点出现故障，你的系统仍然能在 50%的容量下保持高可用性，但这可能会影响用户的性能预期。然而，如果你在两个站点之间创建相等的冗余，每个站点都有四台服务器，那么你的应用程序不仅将具有高度可用性，还将具备 100%的容错能力。

假设你的应用程序不是 100%容错的。在这种情况下，你需要添加自动化的可扩展性，定义你的应用程序的基础设施如何响应容量需求的增加，以确保应用程序的可用性，并在你的标准要求内保持性能。为了让你的应用程序更加可靠，你应该能够快速恢复服务并且不丢失数据。接下来，我们将讨论这个恢复过程，即灾难恢复（DR）。在进入不同的灾难恢复场景之前，让我们先了解 RTO/RPO 以及数据复制，因为它们是灾难恢复规划中的关键因素。

规划 RPO 和 RTO

企业应用程序需要以服务水平协议（SLA）的形式定义服务可用性。组织通过定义 SLA 来确保应用程序的可用性和可靠性。例如，你可以在 SLA 中声明你的应用程序在一年内应保持 99.9%的可用性，或者组织可以容忍每月 43 分钟的停机时间，等等。定义的 SLA 主要驱动应用程序的 RPO 和 RTO。

RPO 是指组织在特定时间段内能够容忍的数据丢失量。例如，如果我的应用程序可以接受丢失 15 分钟的数据，那就没有问题。在这种情况下，如果你每 15 分钟处理一次客户订单，那么在订单履行应用程序发生系统故障时，你可以容忍重新处理这段数据。RPO 有助于定义数据备份策略。

RTO 是指应用程序停机时间以及在故障发生后，应用程序恢复并正常运行所需的时间。下图展示了 RTO 和 RPO 之间的区别：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_01.png

图 8.1：RTO 和 RPO

在前面的图示中，假设故障发生在早上 10 点，而你最后一次备份是在早上 9 点；如果发生系统崩溃，你将丢失 1 小时的数据。当你恢复系统时，数据丢失的时间为一个小时，因为你每小时进行一次数据备份。

在这种情况下，你的系统 RPO 是 1 小时，因为它可以容忍最多 1 小时的数据丢失。这里的 RPO 表示最大可容忍的数据丢失为 1 小时。

如果你的系统需要 30 分钟才能恢复到备份并启动系统，那么 RTO 就定义为半小时。这意味着可以容忍的最大停机时间是 30 分钟。RTO 是指在系统故障导致停机后，恢复整个系统所需的时间，在这个案例中是 30 分钟。

组织通常会根据用户体验以及系统不可用时对业务的财务或声誉影响，决定一个可接受的 RPO（恢复点目标）和 RTO（恢复时间目标）。组织会根据定义的 RTO 和 RPO 规划有效的系统恢复解决方案。随着时间的推移，你应该致力于减少 RTO/RPO，这将直接带来业务上的好处，因为应用程序的正常运行时间会增加。现在你可以看到数据是系统恢复的关键，因此让我们学习一些方法来最小化数据丢失。

数据复制

数据复制和快照是灾难恢复（DR）和确保系统可靠性的关键。复制会在备份站点创建主数据站点的副本。若主系统发生故障，系统可以故障转移到备份系统，继续可靠地运行。这可能是你存储在NAS 硬盘中的文件数据，数据库快照或虚拟机镜像快照。站点可以是两个地理位置分离的本地系统，两个位于同一场所的独立设备，或是物理分隔的公共云。

数据复制不仅有助于灾难恢复，还能通过快速创建新的测试和开发环境，提高组织的敏捷性。数据复制可以是同步的或异步的。

同步与异步复制

同步复制会实时创建数据副本。实时数据复制有助于减少 RPO，并在灾难发生时提高可靠性。然而，它的成本较高，因为它需要额外的资源来进行持续的数据复制。

异步复制会在某些延迟的情况下，或者根据定义的时间表创建数据副本。然而，异步复制比同步复制成本低，因为它使用的资源较少。如果你的系统可以容忍较长的 RPO，你可以选择异步复制。

对于像 Amazon RDS 这样的数据库技术，当我们创建一个具有多个可用区（AZ）故障转移的 RDS 时，会应用同步复制。该配置确保你的主数据库和其在另一个可用区的副本始终保持同步，从而提供高可用性（HA）和数据持久性。如果主数据库遇到问题，服务可以自动故障转移到副本，且对业务的影响最小。对于只读副本，则使用异步复制，你可以用它来处理报告和读取请求。

如下图所示，在同步复制中，主数据库实例和备用数据库实例之间的数据复制没有延迟，而在异步复制中，主数据库实例和复制实例之间可能会存在一些数据复制延迟：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_02.png

图 8.2：同步与异步数据复制

让我们来探索一些用于同步和异步方法的数据复制方式。

复制方法

复制方法是一种从源系统提取数据并创建副本以用于数据恢复的方式。根据存储类型，有不同的复制方法可以存储数据副本，以便业务流程的继续。复制可以通过以下方式实现：

• 基于阵列的复制：在这种方法中，内建的软件会自动进行数据复制。然而，源存储阵列和目标存储阵列必须兼容并且是同类的才能进行数据复制。存储阵列包含多个存储磁盘，在机架中进行安装。

  大型企业通常使用基于阵列的复制，因为它易于部署，且能减少主机系统的计算负载。你可以选择像 HP Storage、EMC SAN Copy 和 NetApp SnapMirror 这样的基于阵列的复制产品。

• 基于网络的复制：这可以在不同类型的异构存储阵列之间复制数据。它使用一个附加的交换机或设备，在不兼容的存储阵列之间复制数据。在基于网络的复制中，由于涉及到多个厂商，复制的成本可能较高。你可以选择像 NetApp Replication X 和 EMC RecoverPoint 这样的基于网络的复制产品。

• 基于主机的复制：在这种方法中，你需要在主机上安装一个软件代理，该代理可以将数据复制到任何存储系统，如 NAS、SAN 或 DAS。你可以使用基于主机的软件供应商，例如 Symantec、Commvault、CA 或 Vision Solution。

  由于较低的前期成本和异构设备兼容性，这在中小型企业（SMBs）中很常见。然而，由于需要在主机操作系统上安装代理，它会消耗更多的计算资源。

• 基于虚拟化管理程序的复制：这是虚拟机感知型的，意味着将整个虚拟机从一个主机复制到另一个主机。由于组织通常使用虚拟机，因此它提供了一种非常高效的灾难恢复方法，以减少恢复时间目标（RTO）。基于虚拟化管理程序的复制具有高度的可扩展性，并且比基于主机的复制消耗更少的资源。它可以通过 VMware 和 Microsoft Windows 中内建的本地系统执行。你可以选择像 Zerto 这样的产品来执行基于虚拟化管理程序的复制，或者选择其他供应商提供的产品。

在第二章中，解决方案架构设计原则，你学习了可扩展性和容错性。在第四章中，解决方案架构设计模式，你学习了多种设计模式，以使你的架构高度可用。现在，你将发现多种从故障中恢复系统并使其高度可靠的方法。

灾难恢复规划

灾难恢复（DR）是关于在系统故障期间保持业务连续性。它是关于为任何可能的系统停机做好准备，并具备从中恢复的能力。DR 规划涉及多个维度，包括硬件和软件故障。

在进行 DR 规划时，始终确保考虑到操作损失，例如停电、网络中断、供暖和制冷系统故障、物理安全漏洞以及其他事件，如火灾、洪水或人为错误。

组织根据系统的重要性和影响，在 DR 规划上投入努力和资金。一个生成收入的应用程序需要始终保持在线，因为它对公司形象和盈利能力有重大影响。对于这样的应用程序，组织会投入大量精力来创建基础设施并培训员工应对 DR 情况。DR 就像一份保险政策，即使你没有使用它，你也必须投资并保持它，因为在不可预见的事件发生时，DR 计划将是你业务的救命稻草。

基于业务关键性的基础，例如软件应用程序，可以放置在一个复杂性谱系上。DR 有四种场景，按照 RTO/RPO 从高到低排序如下：

• 备份与恢复

• 引导灯

• 热备份

• 多站点

如下图所示，在 DR 规划中，随着每个选项的进展，RTO 和 RPO 会减少，而实施成本会增加。你需要根据应用程序的可靠性要求，在 RTO/RPO 要求和成本之间做出适当的权衡：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_03.png

图 8.3：DR 选项的范围

DR 策略高度定制化，根据每个组织的独特需求制定，执行完整站点故障转移的决定取决于多种关键因素。触发这种 dr 联合行动的点各不相同，范围从轻微的中断到数据中心的大灾难，如破坏。例如，在重大灾难事件中，组织可能需要迅速评估和优先考虑关键服务，通常这些服务占其收入的重要部分。这些优先服务可能有预定义的 rto，例如在金融影响变得过于严重之前，需要在 24 小时窗口内恢复运营，考虑到罚款、sla 违规和减少销售等潜在损失。另一方面，对于不那么灾难性但仍然关键的服务中断，公司可能为更短的停机时间容忍度设置自动故障转移协议，如 15 分钟。在这两种情况下，dr 的决策标准包括评估业务影响分析，了解关键服务的 rto 和 rpo，评估停机成本与恢复过程，以及确保遵守任何法规要求。此外，技术可行性，包括备用站点的可用性和准备情况，在确定适当响应以确保连续性和最小化运营中断方面起着至关重要的作用。

让我们详细探讨涉及的每个选项及其涉及的技术选择。请注意，像 AWS 这样的公共云能够以成本效益和高效的方式实现上述每种 dr 策略。

备份和恢复

备份和恢复是成本最低的选择，导致较高的 rpo 和 rto。这种方法易于启动，成本效益高，因为您只需要备份存储空间。这种备份存储可以是磁带驱动器、硬盘驱动器或网络访问驱动器。随着存储需求的增加，跨区域添加和维护更多硬件可能是一项艰巨的任务。使用云作为备份存储的最经济和简单的选择之一。Amazon S3 就是一个例子；它以低成本和按需付费模式提供无限的存储容量。

下图显示了一个基本的 dr 系统。在此图中，数据位于传统数据中心，备份存储在 AWS 中。使用 AWS Import/Export 或 Snowball 类型的物理硬盘（8 TB 到 100 TB）将数据导入 AWS，并将信息存储在 Amazon S3 中：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_04.png

图 8.4：从本地基础设施备份数据到 Amazon S3

您可以使用其他备份和恢复的第三方解决方案。一些最流行的选择包括 NetApp、VMware、Tivoli 和 Commvault。

在云环境中规划灾难恢复（DR）时，必须结合利用各种云服务提供商的优势，例如 AWS、谷歌云平台（GCP）和微软 Azure。此方法确保在不同平台之间具有灵活性和韧性。以下是适用于这些云服务的通用程序：

• 备份和存储解决方案：利用云存储服务来保存系统的备份。对于 AWS，Amazon S3 可作为可靠的备份存储解决方案；在 GCP 中，Google Cloud Storage 提供耐用且高度可用的对象存储；Azure 的等效服务 Azure Blob Storage 提供类似的存储服务，用于存储大量非结构化数据。

• 机器镜像和配置：准备包含操作系统、应用程序和配置的机器镜像。AWS 使用 亚马逊机器镜像（AMIs），GCP 使用 Compute Engine 镜像，Azure 提供 Azure 虚拟机镜像。这些镜像可以根据需要进行定制和预配置，包含必要的软件和安全补丁，以便在灾难发生时进行部署。

• 系统恢复文档：明确记录从不同云平台的备份恢复系统所需的步骤。该文档应包括如何部署存储的机器镜像，以及如何从备份恢复数据库和应用程序。

• 流量路由和故障切换程序：概述将流量从主站点重新路由到云中的备份站点的过程。AWS 提供 Route 53 进行 DNS 管理和流量路由，GCP 提供 Cloud DNS 和 Traffic Director，Azure 提供 Azure Traffic Manager 和 DNS Zone。了解如何利用这些服务进行故障切换场景至关重要。

• 部署运行手册：制定一份详细的运行手册，说明部署配置、潜在问题及其解决方案。该手册应为云无关型，并可根据 AWS、GCP 和 Azure 的具体要求进行调整，确保团队无论使用何种云平台都能做好准备。

在准备阶段，创建并存储自定义机器镜像和备份到各自的云存储解决方案——AWS 的 S3、GCP 的 Cloud Storage 和 Azure 的 Blob Storage。同时，准备数据库快照、存储卷以及任何重要文件。通过这种主动方式，确保无论使用哪个云服务提供商，组织都能在灾难发生时迅速恢复，最小化停机时间和数据丢失。

这种灾难恢复模式易于设置且相对便宜。然而，在这种情况下，RPO 和 RTO 都会较高；RTO 将是系统从备份恢复并开始运行的停机时间，而 RPO 则取决于系统的备份频率。接下来我们将探讨“灯塔模式”，它能够进一步提升你的 RTO 和 RPO。

灯塔模式

试点灯方法是继备份和恢复之后的第二低成本灾难恢复方法。就像您家中气炉的试点灯一样，一个始终亮着的小火焰，能够迅速点燃整个炉子为房子加热，采用这种灾难恢复方法时，您需要保持最少数量的核心服务在不同区域内保持运行。在发生灾难时，您可以快速启动额外的资源。

您可以主动复制数据库层，然后从虚拟机镜像启动实例，或者使用基础设施即代码（如 CloudFormation、Terraform、Ansible 等）构建基础设施。

下图显示了试点灯灾难恢复模式。在这种情况下，数据库已复制到 AWS，Web 服务器和应用程序服务器的 Amazon EC2 实例已准备好，但当前未运行：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_05.png

图 8.5：试点灯数据复制到灾难恢复站点场景

试点灯场景类似于备份和恢复，您将大部分组件进行备份并被动存储。然而，您为关键组件（如数据库或认证服务器）维护低容量的活动实例，这些组件可能需要较长时间才能启动。您需要根据需要自动启动所有必需的资源，包括网络设置、负载均衡器和虚拟机镜像。由于核心组件已经在运行，因此恢复时间比备份和恢复方法更快。试点灯方法非常具有成本效益，因为您仅以完全容量运行部分资源。

您需要启用所有关键数据到灾难恢复站点（在本例中为 AWS 云）的复制。您可以使用 AWS 数据迁移服务在本地和云数据库之间复制数据。对于基于文件的数据，您可以使用 Amazon File Gateway。

许多其他第三方管理工具提供高效的数据复制解决方案，例如 Attunity、Quest、Syncsort、Alooma 和 JumpMind。

如果主系统发生故障，如下图所示，您可以启动带有最新数据副本的 Amazon EC2 实例。然后，您可以将 Amazon Route 53 重定向到新的 Web 服务器：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_06.png

图 8.6：试点灯方法中的恢复

对于试点灯方法，在灾难发生时，您需要执行以下步骤：

1. 启动处于待命模式的应用程序和 Web 服务器。此外，通过使用负载均衡器进行水平扩展，扩展应用程序服务器。

2. 垂直扩展运行在低容量的数据库实例。

3. 更新路由器中的 DNS 记录，指向新站点。

在引导灯方法中，你会自动启动围绕复制的核心数据集的资源，并根据需要扩展系统以处理当前流量。引导灯灾难恢复模式相对容易设置且成本低。然而，在这种情况下，RTO（恢复时间目标）需要更长的时间来自动启动替代系统，而 RPO（恢复点目标）则主要取决于复制类型。让我们来探讨下一个方法，热备用，它进一步改善了 RTO 和 RPO。

热备用

热备用，或完全运行的低容量备用，代表了一种通过利用云的灵活性提供成本效益灾难恢复解决方案的先进方法。这种方法通过保持环境服务的子集处于持续运行状态，尽管容量低于完整生产环境，从而增强了基础引导灯策略。

热备用方法的关键优势在于它在成本节约和恢复准备之间取得了平衡。通过让必要的服务已经启动并运行，尽管规模较小，但与冷备用或引导灯策略相比，灾难发生时的恢复时间显著缩短，因为冷备用或引导灯策略在恢复过程中需要配置或扩展资源。

组织可以根据其恢复目标和预算考虑，将热备用环境量身定制为处理其生产流量的特定百分比，如 20%、30% 或 50%。这种灵活性使得灾难恢复解决方案能够根据业务需求和风险承受能力水平进行定制。

此外，热备用环境不仅仅局限于灾难恢复（DR）场景；它还可以通过提供一个非生产环境的平台，如测试、预发布或开发工作，发挥双重作用。这种热备用环境的双重使用通过将基础设施用于除单纯备用外的其他目的，最大化了灾难恢复投资的价值，从而优化了资源利用率和成本效益。

下图展示了两种系统在热备用方法下运行——中央系统和低容量系统——在 AWS 云上。你可以使用像 Amazon Route 53 这样的路由器来分配请求到中央系统和云系统：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_07.png

图 8.7：热备用场景下，运行一个低容量的活动-活动负载

在数据库方面，热备用采取与引导灯（pilot light）类似的方法，即数据不断从主站点复制到灾难恢复站点。然而，在热备用中，你会全天候运行所有必要的组件，但它们并不会扩展以应对生产流量。

通常，组织会选择热备份策略来处理更关键的工作负载，因此你需要通过持续测试确保灾难恢复站点没有问题。最佳做法是 A/B 测试，其中主站点将处理更多的流量。约 1%到 5%的流量将被路由到灾难恢复站点。这将确保在主站点发生故障时，灾难恢复站点能够提供流量服务。同时，确保定期修补和更新灾难恢复站点上的软件，以保持与生产环境的同步。

如下图所示，在主环境不可用时，路由器会切换到次级系统，次级系统设计为在主系统发生故障时自动扩展其容量：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_08.png

图 8.8：热备份场景中的恢复阶段

假设主站点发生故障，在这种情况下，你可以采取以下方法：

1. 通过将流量从 5%增加到 100%，立即将关键生产工作负载的流量转移到灾难恢复站点。例如，在银行业务中，你必须首先启动面向客户的网站以保持其正常运行。

2. 扩展低容量运行的环境。你可以对数据库进行垂直扩展，对服务器进行水平扩展。

3. 当你扩展环境时，其他在后台运行的非关键工作负载也可以转移，例如仓库管理和发货。

可用于热备份的工具包括 Terraform，这是一个由 HashiCorp 开发的开源工具，因其能够在各种云提供商之间以安全高效的方式构建、修改和版本化基础设施而闻名。与此同时，Veeam 凭借其提供的全面备份和复制解决方案，在云环境、虚拟环境和物理环境中脱颖而出，确保对多云策略的强大支持。Zerto 进一步补充了这些功能，提供了为虚拟化基础设施和云环境量身定制的灾难恢复、备份和工作负载迁移软件。

热备份灾难恢复（DR）模式相对较复杂且成本较高。关键工作负载的恢复时间目标（RTO）比备用灯模式要快得多。然而，对于非关键工作负载，它取决于你能够多快地扩展系统，而恢复点目标（RPO）则主要取决于复制类型。接下来我们将探讨下一种方法——多站点，它提供近乎零的 RTO 和 RPO。

多站点

最后，多站点策略，也称为热备份，帮助你实现接近零的恢复时间目标（RTO）和恢复点目标（RPO）。通过这种方法，你的灾难恢复站点是主站点的副本，且站点之间进行持续的数据复制和流量流动。由于自动化的流量负载均衡，跨区域或本地与云端之间的流量管理，这种方法被称为多站点架构。

如下图所示，多站点是灾难恢复的下一个层级，具有在云端与本地系统同时运行的完全功能系统：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_08_09.png

图 8.9：在 AWS 上运行全负载的活动-活动工作负载的多站点场景

多站点方法的优势在于它随时准备承载完全的生产负载。它类似于温备份，但灾难恢复站点在全负载运行。如果主站点出现故障，所有流量可以立即切换到灾难恢复站点，这相比温备份下切换和扩展灾难恢复站点时的性能损失和时间延迟要好得多。

实施多站点灾难恢复策略需要选择一些先进的工具和技术，这些工具和技术旨在自动化和管理无缝的故障转移过程，从而确保在最小性能损失的情况下保持操作连续性。像 VMware 的 vRealize Automation 和 Microsoft Azure Site Recovery 等云管理平台，在协调虚拟机和数据的复制方面起着至关重要的作用，确保在必要时可以立即切换到灾难恢复站点。负载均衡器和全局流量管理器（包括 F5 BIG-IP 和 AWS Route 53 等解决方案）会根据站点的可用性和负载动态地引导流量，确保灾难恢复站点能够瞬间处理传入的请求。

基础设施即代码（IaC）工具如 Terraform 和 AWS CloudFormation 使得必要的基础设施能够快速配置和扩展，从而使灾难恢复站点能够迅速复制生产环境的能力。此外，网络性能监控工具如 SolarWinds 和 Nagios 提供实时的网络健康状况洞察，帮助快速检测可能需要故障转移的问题。

多站点灾难恢复模式是最昂贵的，因为它要求为所有组件建立冗余；然而，对于那些需要高可用性（HA）且不能承受任何停机时间的企业，如金融机构、医疗服务和电子商务平台，投资多站点架构是合理的，因为潜在的停机成本非常高。

在这种情况下，所有工作负载的恢复时间目标（RTO）都要快得多，而恢复点目标（RPO）则主要取决于复制类型。

让我们探讨一些关于灾难恢复的最佳实践，确保你的系统可靠运行。

应用灾难恢复的最佳实践

当你开始考虑灾难恢复（DR）时，以下是一些重要的注意事项：

• 从小做起，按需扩展：确保首先启动最关键的工作负载，这些工作负载对业务影响最大，然后再逐步扩展，启动那些影响较小的负载。

• 应用数据备份生命周期：备份一切，无论是文件服务器、机器镜像还是数据库。保持大量的活动备份可能会增加成本，但一定要应用生命周期策略，根据你的业务需求归档并删除数据。例如，你可以选择保留 90 天的活动备份，在此之后将其存储在低成本的归档存储中，如磁带驱动器或 Amazon Glacier。1 到 2 年后，你可能想设定生命周期策略来删除数据。遵守像 PCI-DSS 这样的标准可能要求你存储数据 7 年，在这种情况下，你必须选择归档数据存储以减少成本。

• 检查你的软件许可证：管理软件许可证可能是一项艰巨的任务，尤其是在当前微服务架构环境中，你有多个独立运行的服务，每个服务都运行在虚拟机和数据库上。软件许可证可能与多个安装、多个 CPU 和多个用户相关联。当你进行扩展时，这会变得更加复杂。监控并检查这些许可证很重要；你需要确保有足够的许可证来支持扩展需求。同时确保不要购买过多的许可证，这些许可证可能不会被利用，反而会浪费更多的资金。总的来说，确保像管理基础设施或软件一样管理你的许可证库存。

• 规划你的扩展：对于水平扩展，添加更多安装了软件的实例；对于垂直扩展，添加更多的 CPU 或内存。你需要了解你的软件许可协议，并确保你有足够的许可证来支持系统的扩展。

• 经常测试你的解决方案：灾难恢复（DR）站点是为罕见的灾难恢复事件创建的，常常被忽视。你需要确保你的灾难恢复解决方案能够按预期工作，以便在发生事故时实现高可靠性。妥协已定义的服务水平协议（SLA）可能会违反合同义务，并导致金钱和客户信任的流失。

• 进行演练：经常测试解决方案的一种方法是进行演练。进行演练时，你选择一个生产工作负载较小的日子，召集所有负责维护生产环境的团队成员。你可以通过关闭部分生产环境来模拟灾难事件，让团队处理情况以保持环境的正常运行。这些事件确保你有可用的备份、快照和机器镜像来应对灾难事件。

• 持续监控资源：建立监控系统，确保在发生事件时，能够自动切换到灾难恢复站点。监控帮助你采取主动的方法，监控容量可以避免资源饱和问题，这些问题可能会影响应用程序的可靠性。

创建灾难恢复计划并定期进行恢复验证，有助于实现预期的应用程序可靠性。接下来，让我们了解如何通过使用公共云来提高可靠性。

通过云提高可靠性

在前面的章节中，您已经看到灾难恢复（DR）站点的云工作负载示例。许多组织已经开始选择云作为灾难恢复站点，以提高应用程序的可靠性。此外，像 AWS、Azure 和 GCP 等主要云服务提供商的云市场提供了各种第三方解决方案，可以集成到灾难恢复规划和执行中。这些服务通常包括备份和复制、编排、监控和安全工具。

云提供了遍布地理位置的数据中心，随时触手可及。您可以轻松地在另一个大洲创建一个可靠的站点，毫不费力。借助云，您可以轻松创建和跟踪基础设施的可用性，例如备份和机器镜像。

在云中，轻松的监控和跟踪帮助确保您的应用程序根据业务定义的 SLA 保持高可用性。云为您提供对 IT 资源、成本的精细控制，以及在 RPO/RTO 需求方面的权衡处理能力。

云提供了轻松有效地测试您的灾难恢复计划的功能。您可以继承云中可用的特性，如各种云服务的日志和指标。内建的指标是深入了解系统健康状况的强大工具。

通过所有可用的监控功能，您可以通知团队任何阈值突破，或触发自动化以实现系统自愈。例如，AWS 提供了 CloudWatch，它收集日志并生成指标，同时监控不同的应用程序和基础设施组件。它可以触发各种自动化来扩展您的应用程序。

云提供了一个内建的变更管理机制，有助于跟踪配置的资源。云服务提供商扩展了开箱即用的功能，以确保应用程序和操作环境运行的是已知软件，并能够以受控方式进行修补或替换。例如，AWS 提供了 AWS Systems Manager，它具备批量修补和更新云服务器的功能。

使用云，您可以设计一个可扩展的系统，提供灵活性，自动添加和删除资源以匹配当前需求。数据是任何应用程序可靠性的重要组成部分。云提供了开箱即用的数据备份和复制工具，包括机器镜像、数据库和文件。在灾难发生时，您的所有数据都被备份并妥善保存在云中，这有助于系统快速恢复。

应用程序开发与运营团队之间的定期互动将有助于解决和防止已知问题以及设计漏洞，从而减少故障和停机的风险。不断架构您的应用程序，以实现弹性并分布式处理任何停机。

总结

在本章中，你了解了使系统可靠的各种原则。这些原则包括通过应用自动化规则使系统自我修复，并通过设计分布式系统来减少故障时的影响，在该系统中，工作负载跨多个资源分布。

整体系统的可靠性在很大程度上依赖于系统的可用性以及从灾难事件中恢复的能力。你已经学习了同步和异步数据复制类型，以及它们如何影响系统的可靠性。你还学习了各种数据复制方法，包括基于阵列、基于网络、基于主机和基于虚拟机监控程序的方法。每种复制方法都有其优缺点。市面上有多家供应商提供实现所需数据复制的产品。

你了解了根据组织需求以及 RTO 和 RPO 来选择不同的灾难规划方法。你学习了备份和恢复方法，它具有较高的 RTO 和 RPO，且易于实施。引导灯方法通过在灾备站点保持关键资源（如数据库）的活跃，来提高你的 RTO/RPO。热备份和多站点方法通过保持灾备站点工作负载的活跃副本，降低系统的 RTO/RPO，并通过降低系统复杂性和成本来提高应用程序的可靠性。

你已经了解了如何利用云平台的内建功能来确保应用程序的可靠性。

解决方案的设计和发布可能只是偶尔发生，但运营维护却是每日任务。在下一章中，你将学习解决方案架构中的警报和监控方面内容，包括各种设计原则和技术选择，以提升应用程序的运营效率，并实现卓越的运营。

加入我们书籍的 Discord 空间

加入本书的 Discord 工作区，向作者和其他解决方案架构师提问并互动：packt.link/SAHandbook

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/QR_Code930022060277868125.png

第九章：9

操作卓越考虑因素

应用程序可维护性是解决方案架构师在架构设计过程中需要考虑的主要方面之一。每个新项目开始时都需要大量的规划和资源，团队会花费最初的几个月来创建和发布应用程序。生产发布后，应用程序需要进行多方面的维护才能继续运行。你需要持续监控应用程序，以便在日常运营中发现并解决任何问题。

运维团队需要处理应用程序基础设施、安全性以及任何软件问题，以确保你的应用程序可靠运行，没有任何问题或故障。通常，企业应用程序非常复杂，并且有明确的服务级别协议（SLA），涉及到应用程序的可用性。你的运维团队需要理解业务需求，并做好相应准备，以应对任何事件。

操作卓越的核心在于确保系统架构的每个组件和层次都以高效的方式运行。这涉及到对过程、系统和服务的持续监控、优化和改进。

操作卓越应当在架构的每个组件和层次中实施。在现代微服务应用中，涉及到许多不同的部分，使得系统的操作和维护成为一项复杂的任务。

你的运维团队需要建立适当的监控和警报机制，以解决可能妨碍业务流的任何问题。操作问题涉及多个团队的协调，进行准备和解决。

在本章中，你将学习适用于实现操作卓越的各种设计原则。你将了解如何选择合适的技术，以确保软件应用程序每一层的操作可维护性。你将学习以下操作卓越的最佳实践：

• 操作卓越的设计原则

• 选择技术实现操作卓越

• 在公共云中实现操作卓越

• 通过 CloudOps 提升效率

本章结束时，你将了解实现操作卓越的各种流程和方法。你将学到可以在应用程序设计、实施和后期生产过程中应用的最佳实践，以提高应用程序的可操作性。

操作卓越的设计原则

操作卓越是指以最小的中断运行应用程序，以获得最大的业务价值。它是通过应用持续改进来使系统高效。

以下部分将讨论可以帮助你增强系统可维护性的标准设计原则。你会发现所有的操作卓越设计原则都彼此紧密相关，并相互补充。

自动化手动任务

技术发展迅速，IT 运营需要跟上这一速度，尤其是在硬件和软件库存来自多个供应商的情况下。企业正在构建混合云和多云系统，因此您必须学习如何处理本地和云端的操作。现代系统拥有广泛的用户基础，各种微服务协同工作，数百万设备通过网络连接。IT 运营中有许多动态组件，使得手动操作变得非常困难。

组织保持敏捷，运营需要迅速响应，以便为新服务的开发和部署提供所需的基础设施。运营团队有更大的责任，确保服务持续运行，并能在发生意外事件时快速恢复。如今，IT 运营要求采取主动的方式，而不是等到事件发生后再进行反应。

通过应用自动化，您的运营团队可以高效工作。需要将手动工作自动化，以便团队能够将精力集中在更具战略性的任务上，而不是被战术性的工作压得喘不过气来。自动化主动发现和响应任何安全威胁是最重要的，以释放团队的精力。通过基础设施即代码（IaC）的方法，启动新服务器或启动和停止服务应该自动化。自动化让团队能够投入更多时间进行创新。

对于您的面向 Web 的应用程序，您可以通过使用机器学习预测提前发现异常，避免其对系统造成影响。如果有人通过 HTTP 端口80暴露了您的服务器，您可以自动化地生成安全工单。几乎可以自动化整个基础设施，并多次重新部署，作为一键解决方案。自动化还有助于防止人为错误，即使一个人重复做同一工作时，也可能发生错误。自动化现在是 IT 运营的必备工具。

进行渐进式和可逆的变更

运营优化是一个持续的过程，需要不断努力识别差距并加以改进。这些差距可能集中在可靠性、可用性、性能和成本效益上，确保架构支持业务目标并适应不断变化的需求。实现卓越运营是一段旅程。在维护过程中，您始终需要对工作负载的各个部分进行更改。例如，通常需要通过供应商提供的安全补丁更新服务器的操作系统。您应用程序使用的各种软件也需要进行版本升级。您可能需要对系统进行更改，以符合新的合规要求。

你应该设计工作负载，使所有系统组件都能定期更新，从而使系统能够受益于最新和最重要的更新。自动化流程以应用小而渐进的变化，避免任何重大影响。任何变化都应该是可逆的，以便在出现问题时恢复系统的正常运行状态。渐进式变化有助于彻底测试，并提高整体系统的可靠性。自动化任何变更管理，以避免人为错误并提高效率。

预测故障并作出响应

预防故障对于实现卓越的操作至关重要。故障是难以避免的，关键是尽早发现并预见它们。在架构设计过程中，预见到故障并确保设计能够应对故障，从而防止其发生。假设一切都会随时失败，并准备好备份方案。定期进行演练，以识别任何潜在的故障源。尽量去除或减轻在系统运行过程中可能导致故障的任何资源。

基于你的 SLA 创建一个测试场景，包括系统恢复时间目标（RTO）和恢复点目标（RPO）。测试你的场景，并确保你理解它们的影响。通过模拟类似生产的场景，确保你的团队准备好响应任何事件。测试响应流程，确保它能够有效解决问题，并打造一个熟悉响应执行的自信团队。

从错误中学习并改进

随着系统中操作故障的发生，你应该从错误中学习并识别其中的差距。确保这些相同的事件不会再次发生，并准备好解决方案，以防故障重演。

改进的一种方式是进行根本原因分析（RCA）。在 RCA 过程中，召集团队并提问五个为什么。每提一个为什么，就揭开问题的一层，直到最后一个为什么，你就能找到问题的根本原因。确定了问题的实际原因后，你可以准备解决方案，并更新操作手册，提供可立即使用的解决方案。

随着工作负载随时间的变化，你必须确保操作程序相应更新。确保定期验证和测试所有方法，并确保团队熟悉最新的更新以便执行它们。

保持操作手册的更新

通常，团队会忽视文档，这导致手册过时。手册提供了一个执行一系列操作的指南，用于解决由于外部或内部事件引发的问题。缺乏文档可能会使你的操作依赖于人员，这样由于团队人员流失可能会带来风险。始终建立流程以保持系统操作独立于人员，并记录所有方面。

在操作手册中，你需要跟踪所有之前的事件和团队成员采取的解决措施，这样任何新成员都可以快速解决类似的事件，帮助他们在运营支持过程中迅速应对。

系统管理员应维护操作手册，记录启动、停止、修补和更新系统的步骤。运营团队应包括系统测试和验证结果，以及应对事件的程序。你的操作手册还应包括与 RTO/RPO、延迟、可扩展性、性能等相关的定义服务级别协议（SLA）。

自动化流程，记录文档，当团队对系统进行更改时以及每次构建后进行标注。你可以通过标注来自动化你的操作，且这些标注可以通过代码轻松读取，以持续适应业务优先级和客户需求。

选择运营卓越的技术

运营团队需要创建程序和步骤来处理任何运营事件，并验证他们行动的有效性。他们需要理解业务需求，以提供高效的支持，并收集系统和业务指标来衡量业务成果的实现情况。

运营程序可以分为三个阶段——规划、执行和改进。让我们来探索可以帮助每个阶段的技术。

运营卓越的规划

运营卓越过程的第一步是定义运营优先级，聚焦于对业务影响较大的领域。这些领域可以是例如：应用自动化、简化监控、随着工作负载变化发展团队技能，以及专注于提升整体工作负载性能。

有一些工具和服务可以扫描系统日志和活动，逐步检查你的系统。这些工具提供了一套基本的评估功能，提出对系统环境的优化建议。它们通过提供关键洞察和优化建议，帮助形成优先事项。

在识别并理解优先级之后，你需要设计运营流程，其中包括要设计的工作负载，并构建支持这些负载的程序。工作负载的设计应涵盖其实施、部署、更新过程以及运营策略。一个完整的工作负载可以视为由不同的应用组件、基础设施组件、安全、数据治理和运营自动化组成。在设计运营流程后，创建一个操作就绪检查表。这些检查表应该是全面的，以确保系统在生产环境上线时已经准备好进行操作支持。内容包括日志记录和监控、沟通计划、警报机制、团队技能、团队支持章程、供应商支持机制等。

对于运营卓越规划，以下是需要适当工具进行准备的领域：

• IT 资产管理

• 配置管理

让我们更详细地探索每个领域，以了解可用的工具和流程。

IT 资产管理

运营卓越规划需要列出 IT 资产清单并追踪其使用情况。这些资产包括基础设施硬件，如物理服务器、网络设备、存储、终端用户设备等。你还需要跟踪软件许可证、运营数据、法律合同、合规性等。IT 资产包括公司用于执行业务活动的任何系统、硬件或信息。

跟踪 IT 资产有助于组织做出关于运营支持和规划的战略性和战术性决策。然而，在大型组织中管理 IT 资产可能是一项艰巨的任务。有多种IT 资产管理（ITAM）工具可供运维团队帮助管理资产过程。最受欢迎的 ITAM 工具包括SolarWinds、Freshservice、ServiceDesk Plus、Asset Panda、PagerDuty和Jira Service Desk。

IT 管理不仅仅是追踪 IT 资产。它还涉及持续监控和收集资产数据，以优化使用情况和运营成本。ITAM 通过提供端到端的可视化以及快速应用补丁和升级的能力，使组织更加敏捷。下图展示了 ITAM：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_01.png图 9.1：ITAM 过程

如上图所示，ITAM 过程包括以下阶段：

• 计划：资产生命周期从规划开始，这是一个更具战略性的关注点，用于确定整体 IT 资产的需求和采购方法。它包括成本效益分析和总拥有成本。

• 采购：在采购阶段，组织根据规划结果获取资产。他们还可能决定根据需要开发一些资产——例如，用于日志记录和监控的内部软件。

• 集成：在这一阶段，资产被安装到 IT 生态系统中。该阶段包括资产的操作和支持，包括定义用户访问——例如，安装日志代理来从所有服务器收集日志并将其显示在集中式仪表板上，同时将监控仪表板的度量限制为 IT 运维团队。

• 维护：在维护阶段，IT 运维团队会跟踪资产，并根据资产生命周期采取升级或迁移的行动——例如，应用软件供应商提供的安全补丁。这包括跟踪许可软件的生命周期结束，比如计划从 Windows Server 2008 迁移到 Windows 2022，因为旧操作系统已经接近生命周期末期。

• 退役：在退役阶段，运维团队处置生命周期结束的资产。例如，如果一台旧的数据库服务器即将结束其生命周期，团队则采取措施对其进行升级，并将所需的用户和支持迁移到新服务器上。

ITAM 帮助组织遵守ISO 19770合规性要求，包括软件采购、部署、升级和支持。ITAM 提供更好的数据安全性并有助于改善软件合规性，还促进了业务单位之间更好的沟通，例如运维、财务、营销团队以及一线员工。配置管理是规划运营卓越的另一个方面，有助于维护 IT 库存数据，以及诸如所有者和当前状态等细节。让我们深入了解它。

配置管理

配置管理维护配置项（CIs），以管理和交付 IT 服务。配置项在配置管理数据库（CMDB）中进行跟踪。CMDB 记录服务器是物理的还是虚拟的，操作系统及其版本（例如，Windows 2022 或 Red Hat Enterprise Linux（RHEL）8.0），服务器的所有者（即，支持、市场或人力资源），以及它是否依赖于其他服务器，如订单管理等。

配置管理与资产管理不同。资产管理处理资产的整个生命周期，从规划到退役，而 CMDB 是资产管理的一个组成部分，用于存储单个资产的配置记录。如下面的图所示，配置管理实现了资产管理的集成和维护部分：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_02.png

图 9.2：IT 资产生命周期与配置管理对比

如前图所示，配置管理实现了资产管理的集成和维护部分。

配置管理和变更管理是 IT 运维中的互补过程。配置管理专注于维护组织 IT 环境中所有组件的准确且最新的记录，包括它们的版本、配置和相互关系。这确保了系统的一致性和高效性部署与运行。另一方面，变更管理则负责监督和控制 IT 基础设施的修改，确保变更以协调和系统化的方式实施，从而防止意外后果。二者共同作用，帮助维护 IT 资产的完整性和稳定性，配置管理提供评估变更影响所需的详细信息，变更管理则确保配置变更经过充分规划、执行并文档化。

配置管理工具可以通过提供资产配置的现成信息，帮助运维团队减少停机时间。最流行的配置管理工具包括 Chef、Puppet、Ansible 和 Bamboo。在第十一章，DevOps 和解决方案架构框架中，你将了解更多关于它们的细节。

如果您的工作负载托管在像 AWS、Microsoft Azure 或 GCP 这样的公共云上，IT 管理会变得更加轻松。云服务商提供内建工具，以便在一个地方跟踪和管理 IT 库存和配置。例如，AWS 提供 AWS Config 等服务，跟踪作为 AWS 云工作负载一部分的所有 IT 库存，以及 AWS Trusted Advisor 等服务，它会推荐成本、性能和安全方面的改进，您可以利用这些建议来决定如何管理您的工作负载。以下截图展示了 AWS Trusted Advisor 的示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_03.png

图 9.3：AWS Trusted Advisor 仪表板

如前所示的截图所示，AWS Trusted Advisor 仪表板显示了 12 个安全问题，可以进一步探索以了解更多细节等内容。

配置管理在持续监控和记录 IT 资源配置中起着至关重要的作用，它使得根据预定义标准自动化配置评估成为可能。配置管理的好处包括：

• 持续监控：它允许对 IT 资源配置的变化进行持续观察和记录。

• 变更管理：帮助追踪资源之间的相互关系，并在实施任何变更之前审查依赖关系。

• 持续评估：便于定期审计和评估，确保您的 IT 资源符合组织的政策和指南。

• 企业级合规性监控：提供企业范围内合规状态的全面视图，定位任何不符合要求的账户，并允许在区域账户级别进行深入检查。

• 第三方资源管理：支持记录第三方资源的配置，如 GitHub 仓库、Microsoft Active Directory 资源及服务器，无论是在本地还是云端。

• 操作故障排除：捕捉配置变化的详细历史记录，帮助简化操作问题的解决。

通过配置管理，您可以进行安全分析，持续监督资源配置，并评估这些配置是否存在潜在的安全漏洞。它在确保 IT 和第三方资源配置符合内部政策和监管标准方面起着重要作用，并且能够持续审查资源配置变化是否符合您的预期标准。

在本节中，你了解了资产管理和配置管理。这些都是信息技术基础设施库（ITIL）框架的一部分，ITIL 实施了信息技术服务管理（ITSM），与运营卓越密切相关。ITSM 帮助组织日常运行其 IT 操作。你可以通过访问其官方网站 (www.axelos.com/best-practice-solutions/itil)，了解更多关于 ITIL 的信息，AXELOS 还提供 ITIL 认证，帮助提升 IT 服务管理流程中的技能。

既然你已经了解了规划，让我们在下一节中探讨 IT 操作的运作。

运营卓越的运作

运营卓越的关键在于主动监控，以及在发生意外事件时的快速响应与恢复。通过了解工作负载的运营健康状况，可以识别出事件和响应对其的影响。使用能够通过指标和仪表盘帮助你理解系统运营健康的工具。你应该将日志数据发送到集中存储，并定义指标以建立基准。这些工具还能够自动化响应操作事件，在特定警报触发时自动执行。

设计工作负载组件时，要确保它们是可替换的。这种方法意味着，你可以通过用已知、可靠的版本替换故障组件，来减少恢复时间，而不是花费时间修复问题。然后，你可以分析故障资源，而不会影响生产环境。

为了实现运营卓越，以下领域需要合适的工具：

• 监控系统健康状况

• 处理警报和事件响应

让我们通过可用工具和流程的信息来探讨每个领域。

监控系统健康状况

跟踪系统健康状况对理解工作负载行为至关重要。运营团队使用系统健康监控来记录系统组件的任何异常并做出相应处理。传统上，监控通常只局限于基础设施层，关注服务器的 CPU 和内存利用率。然而，监控应该应用于架构的每一层。监控应用的重要组件包括：

• 基础设施监控

• 应用监控

• 平台监控

• 日志监控

• 安全监控

我们将在以下小节中讨论这些内容。

基础设施监控

基础设施监控至关重要，并且是最常见的监控形式。基础设施包括托管应用所需的组件。这些核心服务包括存储、服务器、网络流量、负载均衡器等。

基础设施监控可能包括以下指标：

• CPU 使用率：在特定时间段内，服务器 CPU 的利用百分比

• 内存使用情况：服务器在给定时间段内使用的随机存取内存（RAM）百分比

• 网络利用率：在给定时间段内的网络数据包 进出

• 磁盘利用率：磁盘读写吞吐量和每秒输入/输出操作（IOPS）

• 负载均衡器：在给定时间段内的请求数量

还有许多其他可用的指标，组织需要根据其应用监控需求来定制这些监控指标。以下截图展示了一个网络流量的监控仪表盘示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_04.png

图 9.4：基础设施监控仪表盘

从前面的系统仪表盘可以看到，网络输入平均值面板在某一天出现了峰值，并且对不同的服务器应用了颜色编码。运维团队可以深入分析该图表及其他图表和资源，获取更精细的视图，以确定基础设施的整体健康状况。

应用监控

有时候，除了应用程序由于代码中的某个漏洞或第三方软件问题出现问题之外，基础设施本身是健康的。你可能应用了某个供应商提供的操作系统安全补丁，结果影响了你的应用程序。应用监控可以帮助解决这一问题。

应用监控可能包括以下指标：

• 端点调用：在给定时间段内的请求数量

• 响应时间：完成请求的平均响应时间

• 限制：由于系统无法处理更多请求，导致溢出的有效请求数量

• 错误：应用在响应请求时抛出错误

以下截图展示了一个应用端点监控仪表盘示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_05.png

图 9.5：应用监控仪表盘

根据应用和技术，可能还有更多的监控指标。例如，Java 应用的内存垃圾回收量，RESTful 服务的多个 HTTP POST 和 GET 请求，4XX 客户端错误的计数，5XX 服务器错误的计数，以及可能表明应用健康状况不佳的指标。

平台监控

你的应用可能会利用多个第三方平台和工具，这些也需要被监控。它们可能包括以下内容：

• 内存缓存：Redis 和 Memcached

• 关系型数据库：Oracle 数据库，Microsoft SQL Server，Amazon 关系型数据库服务（RDS），PostgreSQL

• NoSQL 数据库：Amazon DynamoDB，Apache Cassandra，MongoDB

• 大数据平台：Apache Hadoop，Apache Spark，Apache Hive，Apache Impala，Amazon 弹性 MapReduce（EMR）

• 容器：Docker，Kubernetes，OpenShift

• 商业智能工具：Tableau，MicroStrategy，Kibana，Amazon QuickSight

• 消息系统：MQSeries，Java 消息服务（JMS），RabbitMQ，简单队列服务（SQS）

• 搜索：基于搜索的应用程序，如 OpenSearch 和 Solr

上述提到的每个工具都有其自己的指标，您需要监控这些指标，以确保您的应用程序整体健康。以下截图显示了关系数据库平台的监控仪表板：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_06.png

图 9.6：关系数据库管理系统（RDBMS）的平台监控仪表板

在上述仪表板中，您可以看到数据库有大量写入活动，表明应用程序正在持续写入数据。另一方面，读取事件相对一致，除了某些尖峰情况。

日志监控

传统上，日志监控是一个手动过程，组织在遇到问题时采取反应性方法来分析日志。然而，随着竞争加剧和用户期望不断提高，必须在用户察觉到任何问题之前快速采取行动。为了采取积极的措施，您应该能够将日志流式传输到集中位置，并运行查询以监控和识别问题。例如，如果某个产品页面抛出错误，您需要立即了解错误并修复问题，避免用户投诉；否则，您将遭受收入损失。

在发生任何网络攻击的情况下，您需要分析网络日志并屏蔽可疑的 IP 地址。这些 IP 地址可能会发送大量错误的数据包，导致您的应用程序崩溃。像 AWS CloudWatch、Logstash、Splunk、Google Stackdriver 等监控系统提供了可以安装在应用程序服务器上的代理。该代理会将日志流式传输到集中式存储位置。您可以直接查询集中日志存储，并为任何异常设置警报。

以下截图显示了集中存储的示例网络日志：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_07.png

图 9.7：原始网络日志流式传输到集中式数据存储

您可以在这些日志中运行查询，找出请求被拒绝次数最多的前 10 个源 IP 地址，如下图所示：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_08.png

图 9.8：通过运行查询从原始网络日志中获得的洞察

如前面的查询编辑器所示，您可以创建图表并设置警报，如果检测到的拒绝次数超过某个阈值（例如超过 5000 次）。

安全监控

安全是任何应用程序的关键方面。在解决方案设计时应该考虑安全监控。如在第七章《安全考虑》一节中所学，安全需要在所有层面进行应用。建议实施安全监控，以便对任何不利事件进行响应和处理。

以下列表显示了安全监控需要应用的地方：

• 网络安全：监控任何未经授权的端口开放、可疑 IP 地址和活动

• 用户访问：监控任何未经授权的用户访问和可疑的用户活动

• 应用安全：监控任何恶意软件或病毒攻击

• 网络安全：监控 分布式拒绝服务攻击 (DDoS)、SQL 注入或 跨站脚本攻击 (XSS)

• 服务器安全：监控任何安全补丁的漏洞

• 合规性：监控任何合规性漏洞，例如 支付卡行业 (PCI) 对支付应用程序的合规性检查或 健康保险流通与问责法案 (HIPAA) 对医疗应用程序的合规性检查

• 数据安全：监控未授权的数据访问、数据屏蔽以及静态和传输中的数据加密

使用 Amazon GuardDuty 进行 AWS 云安全监控的一个示例如下所示：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_09.png

图 9.9：使用 Amazon GuardDuty 进行安全监控

其他可以用于安全监控的工具包括 Imperva、McAfee、Qualys、Palo Alto Networks、Sophos 和 Symantec。

当您在部署应用监控工具以监控系统的所有组件时，监控监控系统本身也至关重要。确保监控您的监控系统主机。例如，如果您将监控工具托管在 Amazon Elastic Compute Cloud (EC2) 中，那么 AWS CloudWatch 可以监控 EC2 的健康状况。

处理警报和事件响应

监控是运营卓越的一部分；另一部分是处理警报并根据警报采取行动。通过使用警报，您可以定义系统阈值以及何时需要工作。例如，如果服务器的 CPU 使用率在 5 分钟内达到 70%，那么监控工具会记录高服务器利用率并向运营团队发送警报，要求采取措施在系统崩溃之前降低 CPU 使用率。响应这一事件时，运营团队可以手动添加服务器。当自动化到位时，自动扩展会根据需求触发警报，增加更多服务器。它还会向运营团队发送通知，通知可以稍后处理。

事件响应对于处理这些警报并解决问题至关重要。采取的行动可以是自动化的，也可以由运营团队管理，以应对系统停机或故障。这个过程确保任何中断都能及时有效地处理，从而减少对组织运营的影响，保持系统的可靠性和可用性，以便为用户和利益相关者提供服务。

通常，您需要定义警报类别，并根据警报严重性准备运营团队进行响应。以下严重性级别提供了如何对警报优先级进行分类的示例：

• 严重性 1：这是一个关键优先级问题。只有当存在显著的客户影响且需要立即人工干预时，才应提出 Sev1 问题。Sev1 警报可能是整个应用程序崩溃。典型团队需要在 15 分钟内响应这些警报，并需要 24/7 支持来解决问题。

• 严重性 2：这是一个高优先级警报，应在工作时间内处理。例如，应用程序正常运行，但某个特定产品类别的评分和评论系统无法工作。典型的团队需要在 24 小时内响应这些警报，并需要常规工作时间支持来解决问题。

• 严重性 3：这是一个中等优先级的警报，可以在工作时间内处理——例如，服务器磁盘将在 2 天内填满。典型的团队需要在 72 小时内响应这些警报，并需要常规工作时间支持来解决问题。

• 严重性 4：这是一个低优先级的警报，可以在工作时间内处理——例如，安全套接层（SSL）证书将在两周后过期。典型的团队需要在一周内响应这些警报，并需要常规工作时间支持来解决问题。

• 严重性 5：属于通知类别，无需升级，通常是简单的信息——例如，发送一个部署完成的通知。在这种情况下，不需要回复，因为它仅供参考。

每个组织可以根据其应用需求设置不同的警报严重性级别。有些组织可能希望设置四个严重性级别，而其他组织可能选择六个。同时，警报响应时间也可能不同。有些组织可能希望在 24/7 基础上，在 6 小时内解决 Sev2 警报，而不是等到工作时间内再处理。

在设置警报时，确保标题和摘要是 描述性 且 简洁 的。通常，警报会发送到手机（如短信）或寻呼机（如消息），需要简洁且信息量足够，便于接收者立即采取行动。确保在消息正文中包含适当的度量数据。例如，在消息正文中，包含特定信息，如 生产服务器 production-web-1 的磁盘已满 90%，而不仅仅是说 磁盘已满。以下是来自 CloudWatch 的警报仪表板截图示例：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_10.png

图 9.10：警报仪表板

如前所示的警报仪表板，当名为 testretail 的 NoSQL Amazon DynamoDB 数据库表使用低写入容量单位并导致不必要的额外费用时，会有一个警报正在进行中。

底部的警报和顶部的两个警报状态为 正常，因为在监控过程中收集的数据完全在阈值范围内。

有时可能会出现 数据不足 的警报，这意味着需要更多的数据点来确定您监控的资源状态。如果能够收集数据并将其移至“正常”状态，则可以认为此警报有效。

测试在关键警报情况下的事件响应非常重要，以确保你准备好根据定义的 SLA 进行响应。确保正确设置阈值，以便你有足够的时间来处理问题，并且不会发送过多的警报。确保一旦问题解决，警报会重置为原始设置，并准备好再次捕获事件数据。

事件是指任何未计划的中断，可能对系统和客户产生负面影响。在发生事件时，首要响应是恢复系统并恢复客户体验。解决根本问题可以在系统恢复并开始正常运行后进行。自动化警报有助于主动发现事件并最小化用户影响。如果整个系统宕机，它可以作为灾难恢复站点的备份。主系统可以稍后修复并恢复。

例如，Netflix 使用Simian Army（netflixtechblog.com/the-netflix-simian-army-16e57fbab116），这是一组工具，用于测试系统的弹性，包括 Chaos Monkey。Chaos Monkey 随机终止一个生产服务器，以测试系统是否能够在不影响终端用户的情况下响应灾难事件。类似地，Netflix 还有其他猴子，用于测试系统架构的各个维度，如 Security Monkey、Latency Monkey，甚至 Chaos Gorilla，后者可以模拟整个可用区的故障。

监控、警报和事件响应是实现运营卓越的关键组件。所有监控系统通常都集成了警报功能。一个完全自动化的警报和监控系统可以提高运营团队维持系统健康和提供专业知识的能力，使他们能够迅速采取行动并提升用户体验。

在监控应用环境时，持续改进至关重要，必须不断努力追求卓越。让我们进一步了解如何提升运营卓越。

提升运营卓越

对任何流程、产品或应用的持续改进是其卓越的必要条件。运营卓越需要持续改进，才能随着时间的推移达到成熟。

在执行根本原因分析（RCA）时，建议逐步实施小幅增量的变更，从各种运营活动中学习经验。通过从失败中学习，你将能够预见到任何可能的运营事件，这些事件可能是计划内的（如部署）或计划外的（如利用率激增）。你应该记录所有学到的经验教训，并在操作手册中更新解决方案。对于运营改进，以下是需要适当工具的领域：

• IT 运营分析 (ITOA)

• 根本原因分析（RCA）

• 审计和报告

IT 运营分析

ITOA 是一种从各种资源收集数据以做出决策并预测您可能遇到的潜在问题的实践。分析所有事件和操作活动对于改进至关重要。分析故障将有助于预测未来事件，并使团队做好准备，以便提供适当的响应。

一个大型组织可能有数百个系统生成大量数据。实施机制以收集操作事件日志、工作负载中的各种活动以及基础设施更改，将这些数据存储一段时间（如 90 天或 180 天）。IT 运营分析（ITOA）使用大数据架构来存储并分析来自各地的多个 TB 数据。

它帮助您发现通过查看单个工具无法发现的问题，并帮助您确定各个系统之间的依赖关系，提供全局视图。

如下图所示，每个系统都有自己的监控工具，帮助获得洞察并维护各个系统组件。对于运营分析，您需要将这些数据汇集到一个集中地点。将所有操作数据收集在一个地方为您提供了一个单一的真实数据源，在这里您可以查询所需数据并运行分析，以获得有意义的洞察：

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_11.png

图 9.11：IT 运营分析的大数据方法

要创建一个运营分析系统，您可以使用可扩展的大数据存储，如 Amazon 简单存储服务（S3）。您还可以将数据存储在本地的 Hadoop 集群中。对于数据提取，可以在每个服务器上安装一个代理程序，如 Amazon CloudWatch 代理，该代理程序可以将所有监控数据发送到集中存储系统。第三方工具如 ExtraHop 和 Splunk 可以帮助从各个系统中提取数据。

一旦数据集中存储，您就可以执行数据转换，将数据转换为适合搜索和分析的形式。数据转换和清理可以通过使用大数据应用程序，如 Spark、MapReduce、AWS Glue 等来实现。

要可视化数据，您可以使用任何商业智能工具，如 Tableau、MicroStrategy、Amazon QuickSight 等。这里，我们讨论的是构建提取、转换和加载（ETL）管道。您将在第十二章，面向解决方案架构的数据工程中学习更多细节。

您可以进一步进行机器学习，进行未来事件的预测分析。您将在第十三章，机器学习架构中了解更多关于机器学习的内容。

根本原因分析

为了持续改进，您希望防止任何错误的再次发生。如果能够正确识别问题，可以制定并应用有效的解决方案。找到问题的根本原因对于解决问题至关重要。

五个为什么是一种简单但有效的技术，用于识别问题的根本原因。在五个为什么技巧中，你将团队召集起来回顾一个事件，并连续提出五个问题，以识别实际问题。举个例子，假设数据应该出现在你的应用监控仪表盘中，但当前没有显示。你将通过五个为什么来找出根本原因。

问题：应用程序仪表盘没有显示任何数据。

1. 原因：因为应用程序无法与数据库连接。

2. 原因：因为应用程序出现了数据库连接错误。

3. 原因：因为网络防火墙未配置到数据库端口。

4. 原因：因为配置端口是手动检查，基础设施团队错过了这一点。

5. 原因：因为团队没有自动化工具。

根本原因：基础设施创建过程中出现手动配置错误。

解决方案：实施自动化基础设施创建工具。

在前面的例子中，乍一看，问题似乎与应用程序有关。但经过五个为什么分析，结果发现这是一个更大的问题，需要引入自动化来防止类似事件的发生。

RCA 帮助团队记录经验教训，并在此基础上不断改进，以实现卓越运营。确保你更新并维护运行手册——因为你将编写并与团队共享最佳实践。

审计和报告

审计是识别系统内外部恶意活动的关键环节，它可以帮助制定建议并解决问题。特别是当你的应用程序必须遵守监管机构要求时，审计变得尤为重要——例如，PCI、HIPAA、联邦风险与授权管理计划（FedRAMP）和国际标准化组织（ISO）。大多数监管机构要求定期进行审计，并验证系统中的每一项活动，以准备合规报告并颁发证书。

审计对于防止和检测安全事件至关重要。黑客可能悄无声息地进入你的系统，系统地窃取信息，而没人察觉。定期的安全审计可以揭示隐藏的威胁。

考虑定期进行成本优化审计，以识别在不需要时是否有资源处于闲置状态。同时，确定资源需求和可用容量，以便进行规划。

IT 审计确保你保护 IT 资产和许可证，并确保数据完整性和操作充分，以实现组织目标。

下面的截图展示了存储在 Amazon S3 存储桶中的数据审计，使用了 Amazon Macie。Amazon Macie 是一种由机器学习和模式匹配技术驱动的数据安全和隐私服务，专门设计用于检测和保护 AWS 环境中的敏感数据。

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_09_12.png

图 9.12：来自 Amazon Macie 的数据审计报告摘要

前述截图中的数据审计报告展示了数据访问性、加密、数据共享报告以及数据存储和大小的详细信息。

审计步骤包括规划、准备、评估和报告。任何风险项目必须在报告中突出显示，并应进行后续跟进以解决未解决的问题。

实现公共云的运营卓越

像 AWS、GCP 或 Azure 这样的公共云提供商提供了许多内建功能和指导，帮助实现云中的运营卓越。例如，云提供商提倡自动化，这是运营卓越的最关键因素之一。

以 AWS 云为例，以下服务可以帮助您实现运营卓越：

• 以下 AWS 服务帮助您在规划阶段：

  • AWS Trusted Advisor：AWS Trusted Advisor 根据预设的最佳实践检查您的工作负载，并提供实施建议。

  • AWS CloudFormation：通过 AWS CloudFormation，整个工作负载可以被视为代码，包括应用程序、基础设施、策略、治理和操作。

  • AWS Systems Manager：AWS Systems Manager 提供批量管理云服务器的能力，用于修补、更新和整体维护。

• 以下 AWS 服务帮助您在运作阶段：

  • Amazon CloudWatch：CloudWatch 提供数百个内建指标，用于监控工作负载的运行情况，并根据定义的阈值触发警报。它提供了一个集中式日志管理系统，并触发自动化事件响应。

  • AWS Lambda：该 AWS 服务可用于自动化响应操作事件。

• 以下 AWS 服务将帮助您在改进阶段：

  • Amazon OpenSearch：OpenSearch 可用于分析日志数据，以获取洞察力，并通过分析从经验中学习。

  • AWS CodeCommit：您可以通过将学习内容、库、脚本和文档作为代码存储在中央仓库中，与他人分享知识。

AWS 提供多种功能，允许将您的应用程序和基础设施作为代码进行配置。这些功能帮助您自动化操作和事件响应。使用 AWS，您可以轻松地用良好的版本替换失败的组件，并分析失败的资源，而不会影响生产环境。

在 AWS 上，您可以收集并结合来自系统操作、工作负载活动和基础设施的日志，创建一份全面的活动历史记录，这个任务可以通过 AWS CloudTrail 等服务高效完成。利用 AWS 工具，您可以查询和分析这些操作日志。该分析可以帮助您识别改进的领域，提高系统的效率和安全性。在云端，资源发现非常容易，因为所有资产都位于同一层级的 API 和基于 Web 的接口中。您还可以从云端监控本地工作负载。对于 AWS 云的安全审计，Amazon GuardDuty 和 Amazon Detective 提供了跨多个账户的出色洞察力和详细信息。

操作卓越需要持续的承诺。每次操作失败都应进行彻底分析，以提高应用程序的性能和可靠性。这个过程涉及理解应用程序负载的特定需求和特性，并根据这些需求调整操作策略。此外，通过将常规活动文档化为运行手册，遵循指导问题处理的步骤，使用自动化并提高意识，您的操作将能应对任何故障事件。

通过 CloudOps 提高效率

CloudOps 指的是高效运营和管理云环境的过程、工具和最佳实践。CloudOps 的好处包括提高效率、降低成本、增强安全性和合规性、更快从故障中恢复，以及能够快速扩展。

CloudOps 的关键支柱，适用于所有云服务提供商，包含：

• 建立治理：实现一个安全、良好架构的环境。利用 AWS Organizations、Azure Management Groups 或 Google Cloud Resource Manager 等工具进行账户组织和治理。通过 AWS Control Tower、Azure Blueprints 或 Google Cloud 的 Policy Intelligence 等工具强制执行政策。

• 启用合规性：使用 AWS Config、Azure Policy 或 Google Cloud Security Command Center 等工具持续监控配置。自动化合规性检查和修复，以与行业标准保持一致。

• 配置与协调：使用基础设施即代码的方式加速环境设置，借助 AWS CloudFormation、Azure Resource Manager 模板或 Google Cloud Deployment Manager 等工具。使用 AWS Service Catalog、Azure Service Catalog 或 Google Cloud Service Catalog 等工具管理标准化 IT 服务组合。

• 监控和观察：使用 AWS CloudWatch、Azure Monitor 或 Google Cloud Operations Suite 等工具确保可观察性。快速识别并排除故障，以保持系统性能和可靠性。

• 集中运营：使用 AWS Systems Manager、Azure Automation 或 Google Cloud Operations 等工具管理大规模基础设施，实现自动化和集中管理，提高运营效率。

• 管理成本：使用 AWS 成本探测器、Azure 成本管理或 Google Cloud 成本管理等工具控制和优化开支。设置预算，监控支出，发现异常，以保持成本的可控。

通过统一 CloudOps 实践，你可以在任何云环境中保持一致且高效的运营框架。

自动化是 CloudOps 的核心支柱。它帮助组织更高效地管理复杂的云环境，并减少错误。例如，通过 AWS CloudFormation 或类似工具，基础设施变更可以自动化执行，这样可以避免手动操作中可能出现的错误，从而确保一致性和速度。当像 AWS CloudWatch 这样的监控工具发现性能问题时，可以触发自动化操作来解决这些问题，无需人工干预。

采纳 CloudOps 是一个从基础治理和合规开始的过程。例如，一个数字营销公司可能会首先根据最佳实践来确保他们的云环境安全，然后再逐步实现部署管道的完全自动化。随着数字营销公司规模的扩大，跨团队合作变得至关重要，以便分享最佳实践和工具。从治理和合规入手，逐步增加自动化，团队可以有效管理成本并高效扩展运营。

在这里，我们以 AWS 为例，但同样的概念适用于任何公共云，如 GCP 和 Azure。

使用 CloudOps，构建、部署、监控和操作云环境的整个生命周期得到了简化，为敏捷开发和卓越运营铺平了道路。

要了解更多关于 CloudOps 的详细信息，你可以参考我们的另一本书，AWS 解决方案架构师指南。

总结

卓越运营可以通过根据运营需求和从过去事件中获得的经验教训不断改进来实现。通过提升运营的卓越性，你可以获得业务成功。专注于以提高效率和确保高度响应性部署的方式开发和管理应用程序。在工作负载中实施最佳实践是实现卓越运营的关键。

在这一章节中，你学习了实现卓越运营的设计原则。这些原则倡导操作自动化、持续改进、增量方法、预测故障并做好响应准备。

你了解了卓越运营的各个阶段和相应的技术选择。在规划阶段，你了解了 ITAM（IT 资产管理），用于跟踪 IT 资源的库存，并通过配置管理识别它们之间的依赖关系。

你了解了在卓越运营的功能阶段中的警报和监控，并考虑了各种类型的监控，包括基础设施、应用、日志、安全和平台监控。你了解了警报的重要性，以及如何定义警报的严重性并做出响应。

在运营卓越的改进阶段，你通过构建大数据管道来进行分析，了解了 IT 运营中的分析方法、使用五个为什么进行根本原因分析（RCA）的方法，以及审计的重要性，以防止系统遭受恶意行为和未被察觉的威胁。

你了解了云中的运营卓越以及 AWS 云中可以用于运营卓越的不同内置工具。最后，你学习了 CloudOps 以及它如何帮助你简化云操作。

到目前为止，你已经学习了在性能、安全性、可靠性和运营卓越领域的最佳实践。在下一章，你将学习关于成本优化的最佳实践。你还将了解各种工具和技术，以优化整体系统成本，以及如何在云中利用多种工具来管理 IT 支出。

加入我们书籍的 Discord 空间

加入本书的 Discord 工作空间，向作者和其他解决方案架构专业人士提问并互动：packt.link/SAHandbook

https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/QR_Code930022060277868125.png