解决方案架构手册第三版-全-

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

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

解决方案架构师手册引导读者学习解决方案架构的不同方面，以及云环境中的下一代架构设计，从而创建强大、可扩展、高可用且容错的解决方案。

本书将首先详细介绍解决方案架构和解决方案架构师的角色。通过提供设计支柱、先进设计模式和现代软件设计中的云原生方面的详细概述，它将引导读者走过解决方案架构设计的过程。读者将进一步深入了解解决方案设计的性能优化、安全性、合规性、可靠性、成本优化和运营卓越。

本书深入探讨了安全、基础设施、DevOps、灾难恢复以及解决方案架构文档化的自动化。它还解释了如何通过数据工程、机器学习和生成式人工智能来未来-proof 架构设计。此外，本书还提供了关于解决方案架构师软技能的指导以及持续学习的技巧。

本书的读者对象

本书面向软件开发人员、系统工程师、DevOps 工程师、架构师以及在 IT 行业中渴望成为解决方案架构师的技术领导者，也适用于资深架构师设计安全、可靠、高性能且具成本效益的架构。

本书的内容

本书包含以下章节：

第一章：组织中的解决方案架构师，探索了解决方案架构师在组织中的多种角色，详细介绍了他们的职责，并展示了他们如何与不同的组织结构对接。

第二章：解决方案架构设计原理，讨论了指导可扩展、安全和高效的解决方案架构创建的基础性原则，强调了设计方法中的最佳实践。

第三章：云迁移与云架构设计，为过渡到云环境提供了路线图，包括迁移策略、云采纳的好处以及云架构设计的基本原则。

第四章：解决方案架构设计模式，回顾了常见的架构模式，并提供了关于何时以及如何有效应用它们以解决不同架构挑战的见解。

第五章：云原生架构设计模式，深入探讨了专为云原生环境量身定制的设计模式，强调了可扩展性、弹性和可维护性。

第六章：性能考虑因素，重点讨论了 IT 系统性能优化，讨论了关键指标和增强架构设计速度与效率的策略。

第七章：安全考虑因素，讨论了解决方案架构中安全性的关键问题，涵盖了最佳实践、模式和策略，以保护系统安全。

第八章：架构可靠性考虑因素，考察了构建可靠系统所需的原则和实践，包括灾难恢复规划和高可用性设计。

第九章：运营卓越考虑因素，强调了实现运营卓越的策略和实践，确保系统高效、可靠且易于维护。

第十章：成本考虑因素，提供了管理和优化与架构解决方案相关的成本的指导，重点是最大化价值并最小化开支。

第十一章：DevOps 与解决方案架构框架，将 DevOps 实践与解决方案架构相结合，阐明了这种协同作用如何提升部署、监控和维护的效果。

第十二章：解决方案架构的数据工程，介绍了解决方案架构中的数据工程基础，重点讲解数据系统和工作流的设计。

第十三章：机器学习架构，涵盖了将机器学习整合到解决方案中的架构考虑因素，从数据准备到模型部署。

第十四章：生成式 AI 架构，探讨了生成式 AI 系统的架构，讨论了使 AI 能够创造新内容的组件和过程。

第十五章：重构遗留系统，提供了现代化遗留系统的策略和见解，重点讲解如何将它们迁移到现代化的云环境中。

第十六章：解决方案架构文档，概述了全面的解决方案架构文档的重要性和结构，指导架构师如何有效地传达他们的设计。

第十七章：学习软技能以成为更好的解决方案架构师，强调了解决方案架构师成功所需的软技能，包括沟通、问题解决和领导能力。

如何从本书中获得最大收益

具备软件架构设计的相关经验将有助于跟随本书的内容。了解任何流行的公共云服务提供商（如 AWS）的一些基本知识也是有益的。然而，要理解本书内容并没有具体的前提要求。所有示例和相关指导均在各个章节中提供。本书将带您了解解决方案架构设计的概念，并不需要掌握任何特定的编程语言、框架或工具。

下载彩色图像

我们还提供了一个 PDF 文件，里面有本书使用的截图/图表的彩色图像。您可以在此下载：packt.link/gbp/9781835084236。

使用的约定

本书中使用了许多文本约定。

CodeInText：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 X 句柄。例如：“物联网平台需要支持 SigV4, X.509 和自定义认证，同时提供精细化的访问控制，确保物联网政策能到达 MQTT 主题级别。”

代码块设置如下：

`def sum_of_squares_of_odd_numbers(numbers):     # initialize the sum to zero sum = 0 # loop through the list of numbers for number in numbers:         # check if the number is odd if number % 2 == 1:             # square the number and add it to the sum sum += number ** 2 # return the sum return sum` 

粗体：表示新术语、重要单词或屏幕上出现的文字，例如菜单或对话框中的文字。例如：“云服务提供商如AWS、Microsoft Azure 和 GCP 提供了许多开箱即用的选项，可以帮助您现代化系统。”

警告或重要说明如下所示。

提示和技巧如下所示。

与我们联系

我们始终欢迎读者的反馈。

一般反馈：发送电子邮件至 feedback@packtpub.com，并在邮件主题中提及书籍标题。如果您对本书的任何方面有问题，请发送邮件至 questions@packtpub.com。

勘误：尽管我们已经尽力确保内容的准确性，但错误是难免的。如果您发现本书中有错误，我们非常感谢您向我们报告。请访问 www.packtpub.com/submit-errata，选择您的书籍，点击“勘误提交表单”链接并填写相关信息。

盗版：如果您在互联网上遇到我们作品的任何非法副本，您可以提供位置地址或网站名称，我们将不胜感激。

请通过 copyright@packtpub.com 与我们联系，并提供材料的链接。

如果您有兴趣成为作者：如果您在某个领域有专长，并且有意写书或为书籍贡献内容，请访问 authors.packtpub.com。

分享您的想法

一旦您阅读了 《解决方案架构师手册 - 第三版》，我们很想听听您的想法！请 点击这里直接前往 Amazon 书评页面，分享您的反馈。

您的评价对我们和技术社区非常重要，并将帮助我们确保提供优质的内容。

下载本书的免费 PDF 版本

感谢您购买本书！

您喜欢随时随地阅读，但又无法携带纸质书籍吗？

您购买的电子书与您选择的设备不兼容吗？

别担心，现在每本 Packt 书籍都会免费赠送一份无 DRM 的 PDF 版本。

在任何地方、任何设备上阅读。搜索、复制并将代码从您喜爱的技术书籍中直接粘贴到您的应用程序中。

优惠不仅仅止于此，您还可以独享每日送达的折扣、新闻通讯和优质的免费内容。

按照以下简单步骤获取福利：

1. 扫描二维码或访问以下链接

packt.link/free-ebook/978-1-83508-423-6

1. 提交您的购买凭证

2. 就是这样！我们将直接把您的免费 PDF 和其他福利发送到您的电子邮箱。

第一章：1

组织中的解决方案架构师

本书是你成为解决方案架构师的终极指南，旨在帮助你掌握解决方案架构的技能。在本章中，你将了解解决方案架构的含义及其作为组织中解决方案开发基础的重要性。解决方案架构涉及设计一个坚实的框架，涵盖 IT 基础设施、应用安全性、可靠性和运营等重要领域。

解决方案架构师与利益相关者紧密合作，分析需求并考虑诸如成本、预算、时间表和法规等约束条件，以创建一个全面的解决方案。

解决方案架构师还积极参与上线后的工作，确保可扩展性、可用性和可维护性。此外，他们与销售团队合作，推广产品及其技术优势。

在本章中，你将学习以下主题：

• 什么是解决方案架构？

• 解决方案架构师的角色

• 理解解决方案架构师的职责

• 敏捷组织中的解决方案架构师

• 解决方案架构师角色中的常见挑战

• 解决方案架构师的职业发展路径和技能提升

在本章结束时，你将深入了解解决方案架构师的角色和他们所面临的挑战。你将发现解决方案架构师如何处理约束条件，并为组织的技术愿景和整体成功做出贡献。

什么是解决方案架构？

解决方案架构的概念可能因不同的专业人士和组织的角度而有所不同。然而，本质上，解决方案架构涉及定义和构思商业解决方案的各个方面，同时考虑战略性和事务性的因素。

从战略角度来看，解决方案架构师负责为软件应用程序制定长期愿景。这个愿景确保解决方案在未来变革中保持相关性和适应性，并能够扩展以满足不断变化的用户需求和工作负载。

另一方面，从战术角度来看，解决方案架构关注业务的即时需求。它涉及设计一个能够处理当前工作负载并有效应对组织日常挑战的应用程序。

然而，解决方案架构不仅仅局限于软件。它涵盖整个系统，包括系统基础设施、网络、安全性、合规要求、系统操作、成本考虑和可靠性等方面。

通过考虑这些不同的因素，解决方案架构师创建了一个全面的蓝图，指导解决方案的开发和实施。这个蓝图不仅确保解决方案满足业务当前的需求，还为其未来的增长和成功奠定基础。

解决方案架构的好处

解决方案架构至关重要，原因有多方面。首先，它为企业软件解决方案的开发提供了坚实的基础。随着项目规模的扩大和团队地理分布的增加，拥有明确定义的解决方案架构可确保长期的可持续性和高效的协作。

解决方案架构解决了多样化的解决方案需求，同时保持与整体业务背景的一致性。它包含了技术平台、应用组件、数据需求、资源需求以及关键的非功能需求（NFRs）等要素。这些非功能需求包括可扩展性、可靠性、性能、可用性、安全性和可维护性。通过考虑这些方面，解决方案架构确保所开发的解决方案符合必要的标准和期望。

图 1.1 展示了当在业务中采用解决方案架构师角色时，组织可能获得的潜在益处。

图 1.1：解决方案架构的有益属性

上述图表突出了良好解决方案架构的以下特征：

• 技术与业务需求对齐：解决方案架构师评估组织或项目应采用哪些技术，以满足业务需求并实现长期可持续性、可维护性以及团队技能匹配。

• 市场机会 评估：解决方案架构涉及分析和持续评估市场中最新趋势的过程，确保所开发的解决方案满足客户需求以及业务需求。它还帮助构建和推广新产品。

• 最小化目标日期滑移：解决方案架构师与所有利益相关者持续合作，包括业务团队、客户和开发团队。他们确保整体解决方案与业务目标和上线时间表保持一致，从而确保最小化目标日期滑移的可能性。

• 促进有效协作：解决方案架构作为项目中各利益相关者的共同参考点和沟通工具，促进了业务团队、开发人员、设计师和其他利益相关者之间的有效协作。解决方案架构的清晰文档和可视化有助于团队成员之间的更好理解、对齐和决策，确保每个人在同一页面上，并朝着共同目标努力。

• 可扩展性和灵活性：一个设计良好的解决方案架构将可扩展性和灵活性视为关键因素。它使解决方案能够随着业务的演变和用户工作负载的增加，平滑地适应和增长。通过预测未来增长并纳入可扩展性措施，解决方案架构确保系统能够在不出现重大中断或高昂返工的情况下应对日益增长的需求。

• 实现业务目标：解决方案架构设计的主要责任是满足利益相关者的需求，并将其调整为他们的要求。解决方案架构通过分析市场趋势和实施最佳实践，将业务目标转化为技术愿景。解决方案架构需要足够灵活，以应对新的、具有挑战性的、苛刻的和快速变化的业务需求。

• 更好的资源规划：通过明确的解决方案架构，组织可以精确确定所需的资源类型和数量。这有助于人力资源的战略规划，确保适当的财务资源和时间，确保项目人员配备充足，资源得到最佳利用，从而使项目执行更顺利，并遵守时间表。

• 更好的预算预测：投资于准确的估算对于有效的预算预测至关重要。一个明确定义的解决方案架构为项目完成所需的资源提供了清晰的洞察。详细了解项目的范围和需求使组织能够更准确地预测成本，并减少预算超支的风险。

• 风险缓解：一个好的解决方案架构包括风险评估和缓解策略。通过及早识别潜在风险，解决方案架构师可以采取措施来减轻这些风险。通过这种积极的方式，有助于最小化风险对项目时间表、预算和整体成功的影响。风险缓解策略可以包括备份计划、冗余措施、安全性考虑和灾难恢复计划。

• 提高投资回报率：解决方案架构决定了投资回报率（ROI），并有助于衡量项目的成功。它促使企业思考如何通过应用自动化来降低成本和消除过程浪费，从而提高整体投资回报率。

• 定义项目时间表：定义准确的项目时间表对于解决方案实施至关重要。解决方案架构师确定设计阶段所需的资源和努力，这应有助于定义解决方案开发的时间安排。

现在，您已经对解决方案架构及其好处有了一个高层次的概述，接下来让我们了解解决方案架构师的角色以及它如何帮助构建一个良好的解决方案架构。

解决方案架构师的角色

如果你想了解一个解决方案应该如何组织和交付，那么解决方案架构师在这个过程中扮演着至关重要的角色。解决方案架构师设计整体系统以及不同系统如何在各个小组之间进行集成。解决方案架构师通过与业务利益相关者合作，定义预期结果，并向技术团队清晰地传达交付目标。

图 1.2 包含一个流程图，展示了解决方案交付生命周期。解决方案架构师参与了解决方案设计和交付的所有阶段。

图 1.2：解决方案交付生命周期

如图所示，解决方案交付生命周期包括以下几个阶段，且解决方案架构师在其中的参与方式：

• 业务需求与愿景：解决方案架构师与业务利益相关者合作，理解他们的愿景。

• 需求分析与技术愿景：分析需求，定义技术愿景，以执行业务战略。

• 原型设计与推荐：解决方案架构师通过开发概念验证（POC）并展示原型，做出技术选择。

• 解决方案设计：解决方案架构师根据组织的标准并与其他相关小组合作，开发解决方案设计。

• 开发：他们与开发团队一起开发解决方案，并充当业务团队与技术团队之间的桥梁。

• 集成与测试：他们确保最终解决方案按照预期工作，并满足所有功能需求和非功能需求（NFR）。

• 实施：他们与开发和部署团队紧密合作，确保顺利实施，并在遇到问题时给予指导。

• 运营与维护：他们确保日志记录和监控到位，并根据需要指导团队进行扩展和灾难恢复。

整个生命周期是一个迭代过程。一旦应用程序投入生产并开始被客户使用，可能会通过客户反馈发现更多需求，从而推动产品愿景的未来增强。

解决方案架构师在解决方案设计中具有主要的责任，他们会执行以下任务：

• 记录解决方案标准

• 定义高层设计

• 定义跨系统集成

• 定义不同的解决方案阶段

• 定义实施方法

• 定义监控和警报方法

• 记录设计选择的优缺点

• 记录审计和合规要求

解决方案架构师不仅负责方案设计；他们还协助项目经理进行资源和成本估算，定义项目的时间表和里程碑，项目的发布以及支持计划。解决方案架构师贯穿解决方案生命周期的不同阶段，从设计到交付和上线。解决方案架构师通过提供专业知识和广泛的理解，帮助开发团队克服障碍和难题。

根据项目的规模和复杂性，团队内可能需要多名解决方案架构师。一般来说，本书将通用地探讨解决方案架构师的角色，但你经常会看到不同职称的解决方案架构师，这取决于组织的结构；例如，企业解决方案架构师、软件架构师或技术架构师。在这一部分，你将找到与各种职称相关的一些独特属性。然而，解决方案架构师的职责可能会有所重叠，具体取决于组织的结构。

解决方案架构师可以分为通才型和专家型。通才解决方案架构师在多个技术领域拥有广泛的知识。他们全面理解解决方案架构的各个方面，能够提供整体性的指导。另一方面，专家型解决方案架构师（SSAs）在大数据、安全、网络或行业领域等特定领域具有深厚的专业知识。他们拥有专门的知识，能够在各自领域提供深入的指导。

在许多情况下，一名通才解决方案架构师与 SSAs 合作，以对齐项目的需求和复杂性。这种合作可以充分利用专家的专业知识，同时确保整体解决方案架构保持一致和良好集成。

组织中同时存在通才解决方案架构师和 SSAs，能够实现解决方案架构的平衡和全面性。这确保了架构决策和建议与项目需求相符，涵盖了知识的广度和深度。

通过结合不同类型解决方案架构师的技能和专业知识，组织可以有效应对项目的独特挑战和需求，从而成功设计和实施稳健的解决方案。

通才解决方案架构师角色

通才解决方案架构师在解决方案架构中扮演着至关重要的角色，他们对多个技术领域有广泛的理解。他们拥有全面的知识库，能够在解决方案设计和实施的各个方面提供指导并做出明智的决策。以下是不同类型的通才解决方案架构师角色。

企业解决方案架构师

你是否曾经想过信息技术行业中的产品是如何推出的？这正是企业解决方案角色发挥作用的地方——他们定义最佳实践、文化和合适的技术。企业架构师与利益相关者、领域专家和管理层密切合作，识别信息技术的组织战略，并确保他们的知识与公司业务规则对齐。

企业架构师负责整个组织的解决方案设计；他们与利益相关者和领导层共同制定长期规划和解决方案。最重要的一方面是最终确定公司应该使用哪些技术，并确保公司在使用这些技术时保持一致性和完整性。

企业架构师角色的另一个重要方面是定义业务架构。在一些组织中，可能会看到业务架构师这一职位名称。业务架构填补了组织战略与成功执行之间的空白。它帮助将战略蓝图转化为可执行的行动项，并将这些行动项带到战术层面进行实施。

解决方案架构师和企业解决方案架构师之间的主要区别在于他们的工作范围和关注点。解决方案架构师专注于特定的项目或解决方案，设计并指导应用程序或系统的实施，以符合业务和技术要求。他们的角色通常是以项目为中心，专注于特定的技术或职能领域。相反，企业解决方案架构师则处于更战略的层面，负责监督组织的整体 IT 基础设施和战略。他们确保 IT 战略与业务目标的一致性，跨部门整合各种解决方案架构。这个角色涵盖了更广泛的技术和业务流程，专注于组织的整体技术格局和战略方向。

总体而言，企业架构师在定义整个组织的标准以成功实现业务愿景时，更加贴合公司的愿景和责任。

应用架构师

应用架构师，有时也称为软件架构师，在软件设计和开发中扮演着至关重要的角色。他们与组织合作，定义软件开发项目的技术细节。应用架构师专注于确保软件符合行业最佳实践并遵循组织的标准。他们与不同团队合作，了解如何与其他软件模块进行集成。

例如，一个医疗机构可能会确保新的病人管理系统能够与现有的电子健康记录系统无缝集成，同时遵守医疗规定和内部协议；或者在金融机构中，他们可能会监督一个新的银行应用程序的开发，确保它能安全地与现有的交易处理系统集成，并符合金融行业标准。在这两种情况下，应用架构师确保软件不仅满足功能需求，还符合关键的行业和组织标准。

应用架构师的关键职责之一是管理软件开发的技术方面。他们负责 API 设计，确保其设计良好并且性能最优。同时，他们还会考虑可扩展性要求，确保软件能够应对不断增加的工作负载。此外，应用架构师还确保与其他软件组件的无缝集成，确保它们能够轻松互相互动。

应用架构师是工程团队技术咨询的联络点。他们解决问题并提供指导，确保系统的平稳运行。

虽然较小的软件开发项目可能没有专门的应用架构师，但高级工程师通常会承担这一责任，并参与软件架构设计。

除了技术专长外，应用架构师还扮演着导师的角色。他们支持并指导软件工程团队，解决跨团队集成或因业务需求变化而产生的障碍。他们与团队的密切合作确保了软件开发过程的协调与成功。

总的来说，应用架构师通过提供技术领导、确保遵循最佳实践并在整个开发生命周期中支持工程团队，为软件项目的成功做出了重要贡献。

云架构师

云架构师这一角色在过去十年才出现，但随着企业对云技术的采用日益增加，这一角色的需求也在不断增长。云架构师的出现是为应对企业对云技术采纳的增加。随着组织向云计算转型，规划、设计和管理云环境的专业人才需求激增。

云架构师负责制定和实施公司的云计算战略。他们对各种云服务有深入的了解，能够设计出充分发挥云原生能力的解决方案。

云计算的使用现在已经非常普遍，许多组织已将其转移到公共云平台上。随着像亚马逊云服务（AWS）、微软 Azure 和谷歌云平台（GCP）等公共云平台的流行，云架构师在引导组织进行云迁移的过程中发挥着关键作用。你将会在第三章中学习更多关于云架构的内容，云迁移与混合云架构设计。

云架构师的关键任务之一是协助组织将现有的工作负载迁移到云端。他们制定全面的云迁移策略，并设计将本地应用程序与云资源无缝集成的混合云架构。这使得组织能够利用云所提供的可扩展性、成本效益和管理便捷性。

对于那些刚刚开始使用云的初创公司和企业，云架构师可以设计优化云环境的云原生架构。这些架构利用按需付费模式来优化成本，并充分利用云平台提供的自动化功能。

在当今的商业环境中，云计算已经成为企业战略的一个重要组成部分。为了在这个现代时代蓬勃发展，并跟上创新和自动化的快速步伐，拥有一位熟练的云架构师至关重要。他们在帮助公司通过利用云计算的力量，释放其在可扩展性、效率和业务增长方面的潜力方面发挥着至关重要的作用。

架构师布道者

架构师布道者，也被称为技术布道者，已经成为市场营销中的一个改变游戏规则的角色，特别是在复杂解决方案平台的背景下。在竞争激烈的环境中，人们寻求专家的指导，这些专家拥有深厚的知识，能够解答他们的疑问，从而帮助他们做出明智的决策。这正是架构师布道者凭借其在特定领域的专业知识发挥作用的地方。

架构师布道者在设计满足客户需求并解决其痛点的架构方面发挥着至关重要的作用。通过成为客户和合作伙伴的可信顾问，他们深刻理解架构概念、问题和市场趋势。这种专业知识有助于确保平台的采纳，并通过增加市场份额促进收入增长。

为了推动目标受众对平台的采用，架构推广者创建公共内容，如博客、白皮书和文章。他们还积极参与公共平台，包括行业峰会、技术演讲和会议。进行技术研讨会和发布教程也是他们的工作内容之一，使他们能够传播意识并激发对其产品的兴趣。架构推广者需要具备优秀的书面和口头沟通能力，解决方案架构师也常常将技术传播作为附加职责。

总体而言，架构推广者是通过其专业知识和沟通技巧，利用影响力将产品和解决方案推广到更广泛的受众。他们与客户、合作伙伴和社区互动，最终推动产品的采用、增长和市场成功。

专业解决方案架构师角色

除了通用解决方案架构师外，解决方案架构领域内还有一些专业化的角色，具体取决于组织的结构和项目的复杂性。这些 SSAs 专注于特定领域的专业知识，以应对独特的挑战和需求。

SSAs 的具体角色和职称在不同组织中可能会有所不同。根据项目和组织的复杂性，解决方案架构师可能会承担多个角色，或者不同的解决方案架构师可能会有重叠的职责。关键在于确保组织在每个专业领域具备必要的专业知识和技能，以有效应对项目的独特挑战和需求。让我们来了解一些常见的专业架构师角色。

基础设施架构师

基础设施架构师是一个专注于企业 IT 基础设施设计、安全性和数据中心运营的专业架构师角色。他们与解决方案架构师密切合作，确保组织的基础设施战略与整体业务需求保持一致，并通过分析系统需求和现有环境来分配适当的资源容量，以满足这一需求。他们帮助减少资本支出，将资金用于运营支出，以提高组织效率和投资回报率。

基础设施架构师在定义和规划组织的 IT 资源方面发挥着关键作用，涵盖从存储服务器到个人工作空间的各个方面。他们制定详细的计划来采购和搭建 IT 基础设施，确立软件标准，并协调组织内的系统更新和补丁管理。安全性是他们职责的关键方面，因为他们确保所有环境都能防范潜在的病毒攻击。灾难恢复规划和系统备份也是他们的重点，确保业务持续运营。

例如，在大多数电子商务企业中，规划需求高峰期的基础设施是一个挑战，像美国的感恩节、加拿大和英国的圣诞节后购物日（Boxing Day）或印度的排灯节（Diwali），这时候大多数消费者开始购物，基础设施架构师需要为此做好准备。他们需要为高峰期准备足够的服务器和存储容量，通常高峰期的工作负载可能是正常时期的十倍，从而增加了 IT 基础设施的成本。而且在大部分时间里，这些系统在高峰期之外大多是闲置的。

他们需要规划成本优化和更好的用户体验，这也是他们可能使用云来满足额外容量需求并按需扩展以降低成本的原因之一。他们需要确保系统在支持新功能增长的同时保持活跃。

在云计算的背景下，云基础设施架构师是基础设施架构领域中的一个专业角色，专注于设计和管理基于云的 IT 基础设施。他们深入了解云平台以及主要云服务提供商如 AWS、Microsoft Azure 和 GCP 提供的服务。

云基础设施架构师与组织紧密合作，确定符合其特定需求的最佳云架构，考虑可扩展性、成本效益、安全性和性能等因素。他们设计并实施基于云的解决方案，确保与现有系统和应用程序的无缝集成。

云基础设施架构师负责规划资源分配、管理云安全措施，并优化云环境以实现最佳的性能和成本效益。他们在云技术方面的专业知识使得组织能够利用云计算的优势，同时确保一个可靠且可扩展的基础设施。

总体而言，基础设施架构师需要深入了解数据中心的运营以及相关的组件，如供暖、冷却、安全性、架设和堆叠、服务器、存储、备份、软件安装和修补、负载均衡器和虚拟化等。

网络架构师

你是否曾经想过，拥有多个办公室或商店的大型企业是如何实现无缝连接与沟通的？这正是网络架构师的工作所在，他们负责策划组织的网络通信策略，并使 IT 基础设施发挥作用。

网络架构师负责设计计算机网络、局域网（LAN）、广域网（WAN）、互联网、内联网和其他通信系统。他们管理组织的信息和网络系统，确保用户能够享受低网络延迟和高网络性能，以提高工作效率。他们通过使用虚拟专用网络（VPN）连接，建立用户工作空间与内部网络之间的安全连接。

网络架构师与基础设施架构师密切合作；有时你会看到这两个角色有所重叠，以确保所有 IT 基础设施都连接在一起。他们与安全团队合作，设计组织的防火墙，以防止不道德的攻击。他们负责通过数据包监控、端口扫描，以及实施入侵检测系统（IDS）和入侵防御系统（IPS）来监控和保护网络。你将在第七章，安全考虑中了解更多关于 IDS/IPS 系统的内容。

网络架构师必须与时俱进，了解最新的网络策略、操作和使用 VPN 的安全连接技术。他们配置负载均衡器，微调域名系统（DNS）路由，并精通 IT 基础设施连接的艺术。这就像构建一个复杂的连接网络，确保数据在组织内顺畅高效地流动。

数据架构师

在数据爆炸的时代，数据架构师的角色变得越来越重要。想一想——每一个解决方案设计都围绕数据展开，无论是客户信息、产品细节，还是从复杂数据集中提取的洞察。随着数据的爆炸性增长，从千兆字节到太字节甚至更大，数据管理和架构的有效性需求变得至关重要。数据架构师可能有不同的职称，包括分析架构师或大数据架构师。（我没有包括数据库架构师这个职称，因为他们的工作范围仅限于关系型数据库中像 Oracle 和亚马逊关系型数据库系统（RDS）这样的结构化数据。）

传统上，数据存储在结构化的关系型数据库中。然而，随着来自社交媒体、物联网（IoT）和应用程序日志等来源的非结构化数据的崛起，数据环境发生了变化。于是，数据架构师应运而生，他们是组织数据战略背后的远见者。数据架构师的角色是定义规则、政策、标准和模型，管理组织数据库中收集和使用的数据类型。他们设计、创建并管理数据架构，确保一致的性能和质量。

数据架构师与各方利益相关者合作，包括业务高管、分析师、数据工程师、数据科学家和开发团队。他们的客户从使用商业智能（BI）工具进行数据可视化的高管，到利用机器学习（ML）技术的数据科学家。数据架构师的目标是满足组织的数据需求，并为用户提供有价值的洞察。

为了满足这些需求，数据架构师承担了广泛的责任。他们选择合适的数据库技术，确定结构化和非结构化数据的存储选项，管理流数据和批处理数据的处理，设计数据湖作为集中式数据存储。他们还确保数据安全、合规性和加密，以保护敏感信息。数据仓库、数据集市设计和数据转换是他们专长的其他领域。

随着 ML 在企业中日益重要，专职的 ML 架构师角色也在涌现。这些专家与数据架构师密切合作，设计和实施 ML 算法和模型，将数据驱动的洞察推向更高层次。

在不断变化的技术环境中，数据架构师必须紧跟最新的数据库技术、商业智能工具和安全措施。他们在数据工程和架构方面的专业知识为有效的数据利用铺平道路，使组织能够释放其数据资产的全部潜力。

ML 架构师

在人工智能（AI）和 ML 的时代，ML 架构师的角色变得尤为重要。随着组织越来越多地在其解决方案中采用 ML，能够设计和实施强大 ML 架构的专家需求变得至关重要。

ML 架构师负责运用系统思维将 ML 技术应用到企业软件栈中。他们根据组织的需求分析并确定最适合 ML 和 AI 实施的工具和技术。他们构建信息架构和数据架构，以支持 ML，确保高效的数据摄取、处理和存储，用于训练和推理。

ML 架构师的一项关键职责是修改现有的软件栈和基础设施，以便无缝集成 ML 能力。这涉及将 ML 框架、库和 API 融入现有生态系统，促进高效的数据预处理、模型训练和部署。

将 ML 解决方案投入生产是 ML 架构师角色中的另一个关键环节。他们建立持续监控和改进 ML 模型的机制，确保模型在时间推移中的最佳性能、准确性和可靠性。他们与数据科学家、数据工程师和软件开发人员密切合作，推动 ML 模型在生产环境中的无缝部署和扩展。

ML 架构师必须深刻理解架构最佳实践、性能优化技术、安全考虑、合规要求、成本优化策略以及在 AI 和 ML 解决方案背景下的运营卓越。他们设计的架构在遵循这些原则的同时，还要考虑现代 ML 技术栈中的云原生特点。

在本书的第十三章中，你将深入了解 ML 架构的世界，探索设计支柱、高级设计模式、反模式以及现代 AI 和 ML 技术堆栈的云原生方面。这将为你提供设计和部署稳健可扩展 ML 解决方案所需的知识和技能。

ML 正在改变各个行业，并推动跨多个领域的创新。随着组织继续利用 ML 的力量，ML 架构师在帮助组织充分利用 AI 和 ML 以实现业务成功方面的角色变得不可或缺。

GenAI 架构师

除了 ML 之外，另一个备受关注的新兴领域是生成人工智能（GenAI）。GenAI 专注于创建具有类人认知能力的智能系统，并能够跨多个领域执行各种任务。

GenAI 架构师负责设计和开发超越特定用例的高级 AI 系统，能够展示普通智能。他们探索尖端技术，如深度学习、强化学习、自然语言处理和计算机视觉，以构建能够实时推理、学习和适应的智能系统。

GenAI 架构师利用他们在神经网络、认知科学和计算模型方面的专业知识创建架构，使机器能够理解复杂数据、做出决策并以模拟人类智能的方式解决问题。他们与跨学科团队密切合作，包括数据科学家、计算机科学家和领域专家，以塑造整体的 GenAI 解决方案。

设计一个 GenAI 架构涉及解决诸如伦理考量、处理不确定性和模糊性的挑战。GenAI 架构师专注于构建能够从有限数据中学习、跨领域传递知识，并在动态和不可预测环境中表现出强大性能的系统。

在本书的第十四章中，你将深入探讨 GenAI 架构的迷人世界，探索与构建能够实现 GenAI 的智能系统相关的原则、技术和挑战。你将深入了解最新的进展、架构范式和 GenAI 中的伦理考虑，从而能够设计和开发推动 AI 能力边界的智能系统。

随着 AI 领域的不断发展，GenAI 为转变行业、革新自动化并使机器执行复杂任务提供了巨大潜力，这些任务以前被认为是人类智能的专属领域。GenAI 架构师在推动这一转变和塑造智能系统未来方面发挥着关键作用。

机器学习（ML）和生成型人工智能（GenAI）与解决方案架构的结合为智能自动化、个性化体验和各行业的突破性创新带来了令人兴奋的可能性。

安全架构师

在今天的数字化环境中，确保组织数据和系统的安全性至关重要。安全架构师的角色在设计和实施强大的安全措施以防范潜在威胁和漏洞方面变得至关重要。

安全架构师与各个团队和外部供应商合作，优先考虑整个组织的安全性。他们负责设计和部署网络和计算机安全解决方案，保护信息系统，并确保公司网络和网站的安全。他们还在漏洞测试、风险分析和安全审计中扮演重要角色，识别潜在弱点并制定缓解策略。

作为职责的一部分，安全架构师审查并批准防火墙、虚拟专用网（VPN）、路由器及其他安全措施的安装。他们对安全流程进行全面测试，确保其有效性，并为安全团队提供技术指导。遵守行业标准和法规是他们职责的重要方面，确保应用程序遵守必要的安全协议，并确保数据得到适当的加密和访问。

安全架构师具备深厚的安全技术、工具和方法的理解，擅长设计涵盖数据、网络、基础设施和应用的全面安全架构。他们的专业知识在保护组织免受网络威胁、确保敏感信息的机密性、完整性和可用性方面发挥着至关重要的作用。

在本书的第七章中，你将深入探讨安全架构的相关考虑因素，探索安全架构的原则、最佳实践和新兴趋势。你将获得评估风险、实施安全控制措施以及在组织内建立安全文化的方法论。通过理解安全架构师的角色和安全设计的复杂性，你将能够创建强大的安全架构，保护组织免受潜在威胁，保障其宝贵资产。

DevOps 架构师

在今天快节奏且高度竞争的环境中，组织正在寻求简化开发和运营流程的方法，以更快、更高效、更高质量地交付应用程序。这时，DevOps 架构师的角色变得至关重要。

DevOps 是一种协作方法，弥合开发和运维团队之间的差距，使它们能够无缝协作。DevOps 架构师在推动这种协作以及实施自动化软件交付生命周期各个方面的实践和工具中发挥着至关重要的作用。

DevOps 架构师的关键职责之一是建立并优化持续集成和 持续部署（CI/CD）流水线。他们自动化构建、测试和部署过程，确保代码变更经过充分测试并无缝部署到生产环境中。通过自动化这些过程，组织可以减少错误，加速发布周期，并更可靠地交付软件。

基础设施即代码（IaC）是 DevOps 架构师角色中的另一个重要方面。他们利用 Chef、Puppet、Ansible 和 Terraform 等工具来定义和自动化基础设施资源的配置和供应。这使得开发和运维团队能够轻松创建、复制和管理环境，提供更大的灵活性和可扩展性。

监控和告警是强大 DevOps 架构的核心组件。DevOps 架构师规划并实施监控解决方案，持续监控应用程序、基础设施和安全事件。自动化告警被设置，以便在出现任何问题或重大变化时及时通知相关团队，从而实现快速响应和解决问题。

灾难恢复也是 DevOps 架构师的关键考虑因素。他们设计并实施部署策略，确保组织能够在最小数据丢失（恢复点目标（RPO））和停机时间（恢复时间目标（RTO））的情况下从故障或灾难中恢复。通过提前规划灾难恢复，组织可以最小化潜在干扰的影响，保持业务连续性。

在本书的第十一章中，您将深入探索 DevOps 在解决方案架构框架方面的世界。您将了解 DevOps 中使用的原则、方法论和工具，并理解如何将 DevOps 实践整合到您的解决方案架构中。在一位熟练的 DevOps 架构师的指导下，组织可以增强协作，加速交付，并在当今动态的技术环境中实现更大的敏捷性。

行业架构师

行业架构师是一个专门角色，专注于为特定行业或垂直领域设计量身定制的解决方案。他们具备深厚的特定领域知识和专业技能，了解该行业特有的挑战、需求和法规。

行业架构师的角色是与利益相关者密切合作，包括商业高管、主题专家和技术团队，以理解行业的特定需求和目标。他们分析行业趋势、创新技术和最佳实践，制定与行业目标一致的架构策略。

行业架构师负责将业务需求转化为技术解决方案，解决行业特定的挑战。他们设计和开发行业特定的软件应用、系统和平台，满足行业的特定需求。这包括考虑合规性、数据隐私、安全性、可扩展性和互操作性等因素。

此外，行业架构师在保持与行业最新创新和发展同步方面发挥着至关重要的作用。他们持续评估新技术、工具和框架，这些技术能够提升行业运营并推动竞争优势。

协作和沟通技巧对于行业架构师至关重要，因为他们需要与包括业务领导、开发人员、数据分析师和监管机构在内的多方利益相关者密切合作。他们充当值得信赖的顾问，提供关于技术采用、架构决策和行业数字化转型举措的指导和建议。

通过利用他们的行业专业知识和架构知识，行业架构师为特定行业运营组织的增长、效率和数字化转型做出贡献。他们的角色在确保技术解决方案与行业标准、法规和最佳实践一致方面至关重要，最终推动行业内的创新和成功。

以下是特定行业架构师的一些例子：

• 金融行业架构师：他们专注于金融机构的技术解决方案，理解复杂的法规和安全需求。他们开发风险管理、欺诈检测和金融合规的解决方案。

• 制造行业架构师：他们为汽车和消费品等制造行业设计解决方案，专注于供应链优化、生产规划和工业物联网，以提高效率和生产力。

• 零售行业架构师：他们为零售行业开发技术解决方案，包括 POS 系统、CRM 和全渠道体验。他们处理数据安全问题，并整合实体和数字零售渠道。

• 医疗行业架构师：他们专注于医疗解决方案，设计用于电子健康记录（EHR）、患者管理和远程医疗的系统。他们处理隐私、安全性以及与医疗法规的合规性问题。

这些只是行业架构师及其专注领域的一些例子。每个行业都有其独特的挑战、需求和技术环境，而行业架构师在设计量身定制的解决方案、满足该行业特定需求方面扮演着至关重要的角色。

SSA 角色不仅涵盖行业和技术领域，还包括特定的 SaaS 供应商，如 Salesforce、ServiceNow、Databricks 和 Snowflake，以及来自 SAP、VMware、Microsoft、Oracle 等企业工作负载和云平台如 AWS、GCP 和 Azure。由于很难在一个部分中涵盖所有 SSA 角色的变体，因此本节专注于 SSA 角色的通用概念，强调其多样性和领域内的专业化广度。

在你了解了各种解决方案架构师的角色后，我们现在深入探讨他们的职责。

理解解决方案架构师的职责

现在我们已经拆解了解决方案架构师的各种角色，接下来我们将深入了解解决方案架构师的职责细节。解决方案架构师是客户对接角色中的技术领导者，肩负着许多责任。解决方案架构师的主要责任是将组织的商业愿景转化为技术解决方案，并在业务和技术利益相关者之间充当桥梁。解决方案架构师利用广泛的技术专长和商业经验，确保解决方案交付的成功。

解决方案架构师的职责可能会根据组织的性质略有不同。通常，在咨询组织中，解决方案架构师可能专注于特定项目和客户，而在以产品为基础的组织中，解决方案架构师可能需要与多个客户合作，向他们介绍产品并审查他们的解决方案设计。

解决方案架构师在应用开发周期的不同阶段承担着多种责任，甚至在项目启动之前。在项目孵化阶段，解决方案架构师与业务利益相关者合作，准备并评估响应请求（RFR）文档。

项目启动后，解决方案架构师分析需求，以决定技术实现的可行性，同时定义 NFR，如可扩展性、高可用性、性能和安全性。解决方案架构师了解各种项目约束，并通过开发 POC（概念验证）来做出技术选择。

一旦开发开始，解决方案架构师会指导开发团队，并调整技术和业务需求。

应用上线后，解决方案架构师确保应用按照定义的 NFR（非功能需求）进行性能表现，并根据用户反馈确定下一步迭代。

在本节中，您将深入了解解决方案架构师在产品开发生命周期各个阶段的角色。总体而言，解决方案架构师承担以下主要职责，详见图 1.3。

图 1.3：解决方案架构师的职责模型

如图所示，解决方案架构师有许多重要职责。在接下来的章节中，您将了解解决方案架构师职责的各个方面。

分析功能需求（FRs）

在任何项目的开始，定义业务需求是解决方案设计的基础。这些需求最初以基本形式呈现，要求从一开始就需要一个多样化的团队参与，其中包括具有技术专长的人，以准确识别和理解这些需求。最初由业务利益相关者设定这些需求，但随着项目的技术演进，通常需要进行频繁调整。这时，解决方案架构师的角色至关重要，不仅仅是在设计应用程序方面，还在于塑造整体的业务结果。

解决方案架构师不仅具备技术专长，还融合了深刻的商业洞察力，将技术与商业目标对接。他们与产品经理和利益相关者紧密合作，将功能需求（FRs）与技术解决方案连接起来，成为值得信赖的顾问。这个角色对于可视化最终产品及其实现至关重要，指导项目不仅满足技术规范，还能够实现战略商业目标，并符合用户期望。

本质上，解决方案架构师的角色超越了传统的技术专长界限。他们在弥合技术可能性与商业现实之间的差距方面发挥着关键作用，确保最终解决方案不仅符合技术规范，还能提供真正的商业价值。他们能够与各类利益相关者合作，理解业务需求的细微差别，并预见潜在的挑战，使他们在从概念化到项目实现的过程中不可或缺。项目的成功往往取决于他们能否将复杂的需求转化为一致、可行且高效的解决方案架构。

功能需求（FRs）指定系统应执行的功能，详细描述应用程序必须支持的行为、功能和特性。它们与用户交互和应用程序执行的任务直接相关。而非功能需求（NFRs）则定义系统执行某些功能的方式，概述系统的质量属性，例如性能、可用性、可靠性和安全性。这些需求描述了系统的操作条件和限制，影响用户体验，但不涉及具体行为。让我们进一步了解非功能需求（NFRs），以及解决方案架构师如何帮助挖掘它们。

定义非功能需求（NFRs）

NFR 可能不会直接显现给用户和客户，但其缺失可能会以负面方式影响整体用户体验，并阻碍业务发展。NFR 包括系统的关键方面，如性能、延迟、可扩展性、高可用性和灾难恢复。最常见的 NFR 如图 1.4所示：

图 1.4：解决方案设计中的 NFR

在涉及 NFR 时，解决方案架构师会问自己以下问题：

• 性能：

  • 用户的应用加载时间将是多少？

  • 我们如何处理网络延迟？

• 安全性和合规性：

  • 我们如何保护应用程序免受未经授权的访问？

  • 我们如何保护应用程序免受恶意攻击？

  • 我们如何遵守当地法律和审计要求？

• 恢复能力：

  • 我们如何从停机中恢复应用程序？

  • 我们如何在停机事件中最小化恢复时间？

  • 我们如何恢复丢失的数据？

• 可维护性：

  • 我们如何确保应用程序的监控和警报？

  • 我们如何确保应用程序的支持？

• 可靠性：

  • 我们如何确保应用程序的一致性能？

  • 我们如何检查和修复故障？

• 可得性：

  • 我们如何确保应用程序的高可用性？

  • 我们如何使应用程序具备容错能力？

• 可扩展性：

  • 我们如何应对日益增长的资源需求？

  • 我们如何应对突发的使用量激增进行扩展？

• 可用性：

  • 我们如何简化应用程序的使用？

  • 我们如何实现无缝的用户体验？

  • 我们如何使应用程序对不同用户群体可访问？

然而，根据项目的性质，可能会有一些 NFR 仅适用于特定项目（例如，呼叫中心解决方案的语音清晰度）。

你将在第二章，《解决方案架构设计原则》中进一步了解这些属性。

解决方案架构师从项目的早期阶段就开始参与，这意味着他们需要通过评估组织内各方的需求来设计解决方案。解决方案架构师需要确保在系统组件和需求之间的一致性。他们负责定义跨不同组件和不同小组的 NFR（非功能需求），确保解决方案在各方面都能实现期望的可用性。

NFR 是解决方案设计中不可或缺的核心方面，当团队过于关注业务需求时，NFR 常常会被忽视，这可能影响用户体验。一位优秀的解决方案架构师的主要责任是传达 NFR 的重要性，并确保它们在解决方案交付中得到实现。

了解并参与利益相关者

利益相关者是任何对项目有兴趣的人，无论是直接的还是间接的。除了客户和用户，利益相关者还可以是开发团队、销售团队、市场团队、基础设施团队、网络团队或支持团队，或者是项目资助方。利益相关者还可以是项目内部或外部的。内部利益相关者包括项目团队、赞助商、员工和高层管理人员；外部利益相关者包括客户、供应商、供应商、合作伙伴、股东、审计员以及某个国家的政府部门。

利益相关者往往会根据他们所处的环境对同一个业务问题有不同的理解；例如，开发人员可能从编码角度来看待业务需求，而审计员则可能从合规性和安全性角度来审视。

解决方案架构师的角色涉及与技术和非技术利益相关者的合作，以确保项目的成功。他们需要从多个角度理解项目需求，这需要与各种利益相关者进行沟通。这包括为非技术利益相关者翻译复杂的技术概念，并确保技术团队理解业务目标。通过与所有相关方的合作，解决方案架构师确保技术解决方案与更广泛的业务目标对齐。这种广泛的合作对于制定全面有效的解决方案至关重要，以满足各方的需求。

解决方案架构师具备出色的沟通技巧和谈判技巧，这帮助他们在确保每个人都在同一阵线的同时，确定解决方案的最佳路径。解决方案架构师充当技术和非技术资源之间的联络人，填补沟通空白。通常，业务人员和技术团队之间的沟通差距成为失败的原因。业务人员通常从功能和特性角度来看待问题，而开发团队则努力构建一个更加技术兼容的解决方案，这可能有时偏向于项目的非功能性方面。

解决方案架构师需要确保两个团队在同一页面上，并且建议的功能在技术上是兼容的。根据需要，他们指导和辅导技术团队，并将他们的观点以简单易懂的语言表达出来，让每个人都能理解。

理解架构限制

架构约束是解决方案设计中最具挑战性的因素之一。架构约束对解决方案设计构成了重大挑战，因为它们限制了灵活性和创新。在这些约束下确保新解决方案与现有系统技术兼容需要大量的努力和资源。此外，预算、资源和时间表等相关约束会影响解决方案的质量和范围。遵守行业标准和法规要求的同时满足功能需求是一个微妙的平衡。

解决方案架构师需要谨慎管理架构约束，并能够在它们之间进行谈判，以找到最佳解决方案。通常，这些约束是相互依赖的，强调一个限制可能会导致其他限制的加剧。最常见的约束呈现于图 1.5。

图 1.5：解决方案设计中的架构约束

解决方案设计应考虑以下约束：

• 成本：

  • 解决方案实施可用的资金是多少？

  • 预期的投资回报率（ROI）是多少？

• 质量：

  • 结果应与功能需求（FRs）和非功能需求（NFRs）匹配的程度如何？

  • 我们如何确保并跟踪解决方案的质量？

• 时间：

  • 输出应何时交付？

  • 交付时间是否有灵活性？

• 范围：

  • 来自业务和客户的确切期望是什么？

  • 如何处理和适应需求差距？

• 技术：

  • 可以使用哪些技术？

  • 使用传统技术与新技术之间提供的灵活性如何？

  • 我们是应该内部开发还是从供应商处采购？

• 风险：

  • 什么可能出错，我们如何减轻风险？

  • 利益相关者的风险容忍度是多少？

• 资源：

  • 完成解决方案交付需要哪些要求？

  • 谁将参与解决方案的实施？

• 合规性：

  • 可能影响解决方案的当地法律要求是什么？

  • 审计和认证的要求是什么？

解决方案架构师需要平衡约束并分析每个约束的权衡；例如，通过减少资源来节省成本可能会影响交付时间。

在资源有限的情况下完成计划可能会影响质量，从而由于不必要的缺陷修复而增加成本。因此，在成本、质量、时间和范围之间找到平衡至关重要。范围蔓延是解决方案架构师可能面临的最具挑战性的情况之一，因为它可能对所有其他约束产生负面影响，并增加解决方案交付的风险。

范围蔓延是指项目目标和交付物逐渐扩展，通常没有相应的资源、时间或预算增加。

解决方案架构师必须理解每个限制的各个方面，并能够识别由此产生的任何风险。他们必须制定风险缓解计划，并在风险之间找到平衡。有效处理范围蔓延有助于按时交付项目。

做出技术选择

技术选择是解决方案架构师角色中的关键方面，可能涉及最大的复杂性。技术的种类繁多，解决方案架构师需要识别适合解决方案的技术。

解决方案架构师需要在技术知识上具备广度和深度，以便做出最佳决策，因为选择的技术栈可能会影响产品的整体交付。

每个问题可能有多种解决方案和一系列可用的技术。为了做出正确选择，解决方案架构师需要牢记功能性需求（FRs）和非功能性需求（NFRs），并在做出技术决策时定义选择标准。所选技术需要从不同角度考虑，无论目标是与其他框架和 API 的集成能力，还是满足性能需求和安全需求。

解决方案架构师应能够选择不仅满足当前需求，而且能够扩展以适应未来需求的技术。

开发 POC 和原型

创建原型可能是作为解决方案架构师工作中最有趣的部分。为了选择一种成熟的技术，解决方案架构师需要在各种技术栈中开发 POC，以分析它们是否适合解决方案的功能性需求（FRs）和非功能性需求（NFRs）。解决方案设计 POC 是解决方案架构师试图搞清楚解决方案构建块的过程。

开发 POC（概念验证）的目的是通过实现关键功能子集来评估技术，这可以帮助我们根据技术能力选择技术栈。POC 生命周期较短，仅限于团队或组织内部专家评审。

在使用 POC 评估多个平台后，解决方案架构师可以继续进行技术栈的原型开发。原型是为了演示目的开发的，并交给客户，以便用于获得资金支持。POC 和原型开发距离生产就绪还很远；解决方案架构师构建的原型功能有限，这可能会成为解决方案开发中的一个挑战。

解决方案设计与交付

解决方案架构师在理解功能性需求（FRs）、非功能性需求（NFRs）、解决方案约束和技术选择等各个方面后，开始进行解决方案设计。在敏捷环境中，这是一种迭代方法，需求可能随着时间变化而发生变化，需要适应解决方案设计。

解决方案架构师需要设计一个具有未来适应性的解决方案，该解决方案应该具备坚实的构建模块，并足够灵活，以应对因用户需求或技术进步而可能发生的变化。例如，如果用户需求增加十倍，则应用程序应能够扩展并容纳用户需求，而无需对架构进行重大修改。同样，如果新技术，如机器学习（ML）或区块链被引入来解决某个问题，架构应该能够适应这些新技术；例如，使用人工智能在现有数据上构建推荐系统，用于电子商务应用。

解决方案架构师需要小心对需求的剧烈变化，并应用风险缓解计划。

为了确保设计具有未来适应性，可以参考基于 RESTful API 的松耦合微服务架构。这些架构可以扩展以应对新需求，并具有易于集成的能力。你将在第四章，解决方案架构设计模式，和第五章，云原生架构设计模式中了解更多关于不同架构设计的内容。

确保发布后的可操作性和维护

解决方案架构师在解决方案发布后，对于产品的可操作性起着至关重要的作用。为了应对不断增长的用户基数和产品使用量，解决方案架构师需要了解如何扩展产品以满足需求，并确保高可用性，同时不影响用户体验。

在突发事件如故障发生时，解决方案架构师会指导基础设施、IT 支持和软件部署团队执行灾难恢复计划，以确保业务流程的持续进行。解决方案架构师需要满足组织的 RPO（恢复点目标）和 RTO（恢复时间目标）。RPO 定义了组织在中断期间可以容忍的最大数据丢失量——例如，15 分钟的数据丢失。RTO 定义了系统恢复正常运行所需的时间。你将在第十一章，DevOps 与解决方案架构框架中了解更多关于 RTO 和 RPO 的内容。

如果由于需求增加导致性能问题，解决方案架构师会帮助水平扩展系统，以缓解应用程序瓶颈，或垂直扩展以缓解数据库瓶颈。你将在第八章，架构可靠性考虑中了解更多关于不同扩展机制和自我修复的内容。

解决方案架构师计划在现有产品中处理因使用模式或其他原因而产生的任何新需求。他们可以根据用户行为监控对 NFR（非功能需求）进行调整；例如，如果页面加载超过三秒钟，用户可能会离开。解决方案架构师会处理这些问题，并指导团队解决可能在发布后出现的问题。

解决方案扩展和技术传播

成为一名推广者是解决方案架构师角色中最激动人心的部分。解决方案架构师通过在公共论坛上传播信息，推动产品和平台的采用。他们撰写关于解决方案实施的博客，并举办研讨会，展示技术平台的潜在好处和应用。

他们为技术建立广泛的支持，并帮助建立标准。解决方案架构师应该对技术充满热情。他们应当是优秀的演讲者，并具备出色的写作能力，以履行技术推广者的角色。

敏捷组织中的解决方案架构师

敏捷模型正在变得非常流行，它代表了传统项目管理方法的重大转变。与遵循线性和顺序方法的传统瀑布模型不同，敏捷强调灵活性、协作和适应性。它涉及迭代开发，将项目分解为小而易管理的单元，从而允许频繁的重新评估和调整。这种方法鼓励在整个项目生命周期中持续收集反馈并让客户参与，与传统模型在特定阶段才收集反馈的僵化结构形成对比。敏捷的动态特性使其特别适用于需求可能发生变化或在项目开始时并不完全定义的项目。

提到敏捷模型中的解决方案架构师，你首先想到的是什么？有很多误解，比如认为解决方案架构是一项非常复杂的活动，而且在敏捷环境中，你会被要求立即或在下一个冲刺周期内提交设计。另一个误解是认为敏捷架构无法应对这种架构设计和开发，或者认为无法进行测试。

在敏捷环境中，解决方案架构师需要遵循一种迭代重构的概念，通过检查和调整方法来不断改进。这意味着要为企业选择合适的解决方案，进行有效沟通，持续收集反馈，并以敏捷的方式进行建模。开发团队需要一个坚实的架构基础，并具备适应变化需求的能力；他们需要解决方案架构师的指导和辅导。

敏捷架构的基础应该包括降低变更成本，通过质疑不必要的需求来减少它们，并创建一个框架，以便快速逆转错误的需求。敏捷架构师通过构建原型来最小化风险，并通过理解变更来规划应对措施。他们在设计原型时平衡各方需求，创建一个松耦合的架构，便于与其他模块轻松集成。

敏捷架构提倡设计解耦且可扩展的接口、自动化、快速部署和监控。解决方案架构师可以利用微服务架构来构建解耦设计，并通过测试框架自动化与持续部署管道实现快速部署。你将在第四章，解决方案架构设计模式中学习到更多松耦合架构模式。

解决方案架构师常见的挑战

虽然这个职位充满了激动人心和动态的挑战，但作为解决方案架构师的角色也有其难度。理解并应对这些挑战对角色的成功至关重要。

以下是解决方案架构师角色中常见的一些挑战：

• 平衡业务与技术需求：解决方案架构师需要在满足业务目标和确保解决方案技术可行性之间找到平衡。这要求他们理解业务需求和技术能力，并找到一个既满足业务目标又确保技术可行的最佳方案。

• 管理复杂性：解决方案架构师经常与复杂的系统和技术打交道，这可能会让人难以理解和集成。他们需要在错综复杂的技术环境中导航，整合不同的组件，确保无缝的互操作性。

• 跟上技术进展：技术领域不断发展，新的工具、框架和方法论定期涌现。解决方案架构师必须保持对最新进展和行业趋势的关注，以提供创新和有效的解决方案。

• 利益相关者管理：解决方案架构师需要与多方利益相关者合作，包括业务领导者、开发人员、项目经理和最终用户。管理不同的期望、需求和优先级可能会很有挑战性。有效的沟通、协作和谈判技巧是应对多样化利益相关者需求的关键。

• 解决可扩展性和性能问题：解决方案架构师必须设计能够应对日益增加的数据量、用户负载和不断变化的业务需求的解决方案。确保可扩展性、性能和可靠性是关键挑战，因为解决方案需要在不牺牲效率的前提下适应未来的增长。

• 安全性与合规性：数据安全和监管合规性是当今数字化环境中的重要关注点。解决方案架构师必须在设计中融入强大的安全措施、加密技术和合规框架，以保护敏感数据，并确保符合行业标准。

• 解决冲突的需求：不同的利益相关者经常会有冲突的需求或优先级。解决方案架构师必须应对这些冲突，识别权衡，并找到最佳的折中方案，满足解决方案的整体目标。

• 管理项目限制：解决方案架构师需要在预算、时间表和资源的限制下工作。他们必须做出明智的决策，优化资源分配，并适应不断变化的项目动态，以确保成功交付解决方案。

• 云技术的采用：随着云计算日益流行，解决方案架构师常常面临如何有效利用云平台和服务的挑战。他们需要理解云架构的复杂性、部署模型以及供应商特定工具，以设计可扩展和成本效益高的基于云的解决方案。

• 持续学习和技能发展：鉴于技术的快速发展，解决方案架构师必须投入持续学习和技能提升。他们需要获取新知识，增强技术专长，并保持对行业最佳实践的更新，以便在角色中保持有效性。

通过认识到这些挑战并主动解决，解决方案架构师可以应对角色中的复杂性，交付既符合业务目标又满足技术要求的成功解决方案。

解决方案架构师的职业发展路径和技能提升

解决方案架构师的职业发展路径因组织、行业和个人抱负的不同而有所差异。以下是解决方案架构师职业路径和技能发展的一个大致概述。

职业发展路径

解决方案架构师的职业发展路径通常包括一系列渐进的角色，起始于教育基础：

• 教育基础：通常需要计算机科学、软件工程或相关领域的本科学位，才能开始成为一名解决方案架构师的职业生涯。在软件开发、系统设计和 IT 概念方面打下坚实的基础至关重要。

• 专业经验：解决方案架构师通常从软件开发人员、系统分析师或技术顾问开始他们的职业生涯。通过亲身参与设计和实施软件解决方案，帮助他们深入理解实际应用开发和 IT 基础设施。

• 解决方案设计和架构：随着职业生涯的进展，解决方案架构师将转向解决方案设计和架构角色。他们与利益相关者密切合作，分析业务需求，并设计可扩展、可靠且成本效益高的解决方案。掌握解决方案架构框架和方法论（如The Open Group Architecture Framework（TOGAF）或扎克曼框架）是有益的。

技能发展

为了提升职业前景，解决方案架构师应专注于以下领域的技能发展：

• 技术专长：解决方案架构师需要具备广泛的技术技能，涵盖不同领域，如应用程序开发、数据库管理、网络、云计算和安全。他们应持续提升自己的技术知识，以跟上最新的技术和行业趋势。

• 沟通与协作：有效的沟通和协作技能对于解决方案架构师至关重要。他们必须能够将技术概念转化为非技术利益相关者能理解的术语，促进讨论并达成共识。发展强大的人际关系和领导能力对于有效地与跨职能团队合作至关重要。

• 商业敏锐度：解决方案架构师需要将技术解决方案与商业目标对齐。培养商业敏锐度有助于他们理解组织战略、行业动态和客户需求。他们应能够分析技术决策对整体业务的影响，并据此提出建议。

• 领导力与管理：随着解决方案架构师职业生涯的进展，他们可能会承担领导和管理角色，监督架构师团队或管理解决方案交付项目。在项目管理、团队领导和战略规划方面的技能发展，将增强他们推动成功结果的能力。

• 持续学习：技术领域不断发展，解决方案架构师需要积极主动地进行学习。保持对新兴技术、行业最佳实践和新架构模式的更新至关重要。追求认证、参加行业会议和研讨会有助于持续的职业发展。

在今天的数字化环境中，云计算已成为解决方案架构的核心组成部分。云平台提供可扩展性、灵活性和成本效益，使得应用程序能够迅速部署和扩展。它们还提供对先进技术的访问，如人工智能、大数据分析和物联网，这些技术对于数字化转型战略至关重要。因此，解决方案架构师必须精通云解决方案，以设计有效、面向未来且具有竞争力的技术解决方案。

以下是关于解决方案架构师云知识与认证的一些关键点：

• 云平台：解决方案架构师应该熟悉主要的云平台，如亚马逊云服务（AWS）、微软 Azure 和谷歌云平台（GCP）。他们应了解这些平台提供的核心服务、架构模式、可扩展性选项和安全特性。

• 云架构：解决方案架构师需要精通设计基于云的架构，充分利用云平台的能力。这包括设计高可用性和可扩展的解决方案，实施容错系统，并优化云环境中的成本和性能。

• 云安全：安全性是云计算中的关键方面。解决方案架构师应具备云安全最佳实践、加密机制、身份与访问管理以及适用于云环境的合规标准的知识。了解如何设计和实施安全的云架构至关重要。

• 云存储和数据库：解决方案架构师应具备对云存储选项（如对象存储、块存储和文件存储）的良好理解，并能够根据特定需求选择合适的存储解决方案。此外，了解云端数据库服务，如 Amazon RDS、Azure SQL 数据库和 Google Cloud Spanner，也会有所帮助。

• 云认证：云认证验证个人在云技术方面的专业知识，并为行业提供可信度。解决方案架构师常见的云认证包括 AWS 认证解决方案架构师、Microsoft 认证：Azure 解决方案架构师专家以及 Google Cloud 认证 – 专业云架构师。这些认证展示了设计和实施云基础解决方案的能力。

拥有云计算知识和认证不仅能够增强解决方案架构师的技能，还能展示他们设计和实施可扩展、可靠、安全的云基础解决方案的能力。这增强了他们的职业信誉，并提高了他们在日益以云为中心的行业中的市场竞争力。你可以通过参考《AWS for Solutions Architects》一书（www.amazon.com/gp/product/180323895X/）来了解更多关于如何发展成为一名 AWS 专注的云解决方案架构师的职业路径。

总结

在本章中，我们探讨了组织中解决方案架构师的角色，全面概述了他们的职责、技能和挑战。本章首先定义了解决方案架构，并回顾了其演变过程，强调了它在推动成功项目结果和将技术解决方案与业务目标对齐方面的重要性。

本章介绍了解决方案架构师领域内的各种角色，包括通才和专家角色。每个角色都进行了描述，阐明了他们独特的责任和专业知识。

本章深入探讨了解决方案架构师的职责，涵盖了分析用户需求、定义非功能性需求（NFRs）、与利益相关者沟通、管理架构约束、选择合适的技术、开发 POC（概念验证）、设计与交付解决方案、确保上线后的可操作性和维护以及担任技术布道者等重要方面。

本章还提到了解决方案架构师在敏捷团队中的角色，强调了在敏捷开发过程中，协作、适应性和持续改进的重要性。

本章讨论了解决方案架构师面临的常见挑战，并提供了有效克服这些难题的见解。章节还强调了持续职业发展和技能提升的重要性，以跟上不断变化的技术和行业趋势。

通过深入探讨解决方案架构师角色的核心方面，本章为有志之士和在职专业人员提供了全面的指南。所提供的概述为深入探索解决方案架构奠定了基础。

后续章节深入探讨了设计可扩展、具有弹性和高性能架构的原则。内容包括应用安全措施、应对架构约束，并通过测试和自动化实施变更等关键方面。

留下评论！

享受本书吗？通过留下亚马逊评论帮助像你一样的读者。扫描下面的二维码，获取你选择的免费电子书。

第二章：2

解决方案架构设计原则

本章阐明了解决方案架构中最重要和最常见的设计原则和特性。尽管本章的重点是最关键的设计元素，但值得注意的是，随着产品复杂度的增加和特定行业领域的不同，可能会出现其他设计方面。随着你在本书中逐步成为解决方案架构师，你将看到这些基础原则和特性在更深层次的应用，包括在制定针对不同场景和挑战的各种设计模式时。

在本章中，你将学习设计可扩展、具备弹性且性能优化的架构的原则，同时确保有可靠的安全措施来保护你的应用程序。你将探索如何通过测试和自动化来应对架构限制并接受变化，强调数据驱动的方法。通过理解和应用这些原则，你将能够批判性地思考并做出明智的决策，从而提高架构设计的有效性和可靠性。

本章将介绍以下内容：

• 构建可扩展架构设计

• 构建高度可用且具备弹性的架构

• 为性能设计

• 创建不可变架构

• 思考松耦合

• 思考服务，而非服务器

• 思考数据驱动设计

• 在每个地方增加安全性

• 让应用程序更易用和可访问

• 构建面向未来、可扩展的架构

• 确保架构的互操作性和可移植性

• 到处应用自动化

• 为操作设计

• 克服架构限制

让我们开始探索架构设计的基础要素。到本章结束时，你将深入了解在构建架构时需要考虑的各种设计方面。这些知识将成为你理解和实施有效且强大的架构解决方案的重要基石。

构建可扩展架构设计

可扩展性一直是设计解决方案时的一个关键因素。如果你问任何企业关于他们的解决方案，可扩展性将是一个重要的考虑因素。可扩展性指的是使你的系统能够处理日益增长的工作负载，这适用于多个层面，如应用服务器、Web 应用程序和数据库。可扩展性帮助你在不影响应用性能的情况下满足用户需求，从而实现更高的业务回报。

由于现在大多数应用程序都是基于 Web 的，让我们也谈谈弹性。这意味着通过增加更多的功能来扩展系统，或者缩小它以节省不必要的成本。随着公共云的采用，快速扩展和收缩工作负载变得更加容易，弹性现在取代了可扩展性。

传统上，有两种扩展模式：

• 水平扩展：由于过去十年中计算能力已成为一种指数级更便宜的商品，水平扩展变得越来越流行。在水平扩展中，团队通过增加更多的服务器来处理增加的工作负载，如图 2.1所示：

  图 2.1：水平扩展

  比如说，你的应用可以处理每秒 1,000 个请求，并且是两台服务器实例。随着用户基础的增长，应用每秒收到2,000 个请求，这意味着你可能需要将应用实例增加到四个，以应对增加的负载。

• 垂直扩展：这种方式已经存在很长时间了。这是一种做法，其中团队通过向同一台服务器增加额外的计算存储和内存能力，以应对日益增加的工作负载。如图 2.2所示，在垂直扩展过程中，你将获得一台更强大的服务器——而不是增加更多的服务器——来处理增加的工作负载：

  图 2.2：垂直扩展

  垂直扩展模型可能成本效益较低；然而，当你购买具有更强计算能力和更大内存容量的硬件时，成本会呈指数级增长。除非需要应对由于高成本和服务器容量限制而增加的工作负载，否则你希望避免在达到某个阈值后继续进行垂直扩展。

垂直扩展最常用于扩展关系数据库服务器。然而，你需要考虑数据库分片问题，因为如果服务器达到了垂直扩展的极限，它无法超越特定的内存和计算能力。

分片是一种通过将数据划分并分布到多个服务器上来扩展数据库的技术。数据基于分片键进行分区，分片键决定了数据如何在各个分片之间分布。在垂直分片中，分片键可以是表中的某一列或一组列。

扩展可以是预测性的，如果你了解你的工作负载，这通常是有可能的；也可以是反应性的，如果你遇到突发流量或以前从未处理过这种负载。

预测性扩展是一种先进的应用工作负载管理方法，特别适用于具有可预测流量模式的场景，如电子商务网站上常见的流量模式。通过分析历史数据，组织可以预测流量趋势，并相应地调整资源。

例如，电子商务网站可能会根据星期几、一天中的时间或特定购物假期经历不同的流量，迫使其采取预先调整资源的扩展策略，以应对预期的负载增加。这种方法不仅优化了资源使用，还通过减少延迟和防止故障，提升了用户体验，这在流量激增时尤其重要，因为资源分配可能滞后于需求。

另一方面，反应式扩展对于应对突发的流量激增至关重要，这种流量通常远高于常规水平，可能由闪购等事件触发。了解网站不同页面的独特流量模式以及用户的导航路径，对于有效管理这些流量激增非常重要。通过识别哪些页面可以缓存，或者哪些查询是读密集型的，组织可以策略性地将流量从 Web 层卸载，利用内容分发网络来管理静态内容。

这种预测性和反应性扩展的结合确保了应用程序在流量波动的情况下仍然保持弹性和响应性。例如，下面的自动扩展组的最大实例数为六个，最小实例数为三个。在正常的用户流量下，三个服务器将运行并处理工作负载，但在流量激增时，服务器数量可以增加到六个。您的服务器集群将根据您定义的扩展策略增加实例数量。例如，当现有服务器集群中的 CPU 利用率超过 60%时，您可以增加一台服务器，但不会超过六台服务器。

图 2.3：服务器自动扩展

无论扩展是反应式的还是预测性的，您都需要监控应用程序并收集数据，以规划扩展需求。

扩展静态内容

静态内容，如图片和视频，在吸引用户访问网站时发挥着至关重要的作用。然而，如果管理不当，这些元素可能会显著降低应用程序的性能。为了保持最佳的速度和用户体验，有效地扩展和分发静态内容至关重要。

以一个电子商务网站为例。每个产品可能有多张图片——甚至可能有视频——展示产品的质地和演示，这意味着网站将有大量的静态内容，并且负载主要是读取型的，因为大部分时间用户都在浏览产品。此外，用户可能会上传多个图片和视频来进行产品评价。

将静态内容存储在 Web 服务器中意味着会消耗大量存储空间，随着产品列表的增长，您必须担心存储的可扩展性。另一个问题是，静态内容通常需要较大的文件尺寸，这可能会在用户端造成显著的加载延迟。Web 架构层必须利用内容分发网络（CDN）来解决这个问题。CDN 帮助将内容缓存到离用户更近的位置，减少延迟并加快加载速度。合理地扩展静态内容确保您的应用程序在流量增加时仍然保持快速和响应，提供无缝的用户体验。

CDN 提供商（如 Akamai、Amazon CloudFront、Microsoft Azure CDN 和 Google CDN）在全球范围内提供静态内容缓存的位置，可以从靠近用户位置的 Web 服务器中缓存静态内容，从而减少延迟。第四章，解决方案架构设计模式，将向你介绍更多关于缓存的内容。

为了扩展静态内容存储，建议使用对象存储，如 Amazon S3，或本地自定义源，这样可以独立于内存和计算能力进行扩展。此外，使用流行的对象存储服务独立扩展存储可以节省成本。这些存储解决方案可以存放静态 HTML 页面，减少 Web 服务器的负担，并通过 CDN 降低延迟，从而提高用户体验。

应用服务器扩展的会话管理

应用架构层从 Web 层收集用户请求，执行复杂的业务逻辑计算并与数据库进行交互。当用户请求量增加时，应用层需要进行扩展以应对这些请求，然后在需求减少时缩减规模。在这种情况下，用户会与会话绑定，例如，他们可能会在手机上浏览并在桌面上购买。如果在不处理用户会话的情况下进行水平扩展，可能会导致糟糕的用户体验，因为会重置用户的购物进度。

在这里，第一步是通过将用户会话与应用服务器实例解耦来处理用户会话，这意味着你应该考虑将用户会话保存在独立的层中，例如 NoSQL 数据库，在那里你可以存储半结构化的数据。

NoSQL 数据库最适合存储半结构化数据，其中数据项的模式可能会有所不同。例如，一个用户在设置用户资料时可能输入姓名和地址，而另一个用户则可以输入更多的属性，如电话号码、性别、婚姻状况、姓名和地址。由于用户具有不同的属性，NoSQL 数据可以适应它们并提供快速搜索。

NoSQL 数据库，如 Amazon DynamoDB 或 MongoDB，提供卓越的分区能力，使得水平扩展变得轻松，并且能够超越其他数据库类型的可扩展性。

一旦你开始将用户会话存储在 NoSQL 数据库中，你的实例就可以进行水平扩展，而不会影响用户体验。你可以在一组应用服务器前添加负载均衡器，负载均衡器可以将负载分配到各个实例上；借助自动扩展功能，你可以根据需求自动增加或删除实例。

数据库扩展

大多数应用程序使用关系型数据库来存储其事务数据。这些数据库已经存在了几十年，并提供许多应用程序所需的强大事务一致性。然而，关系型数据库的主要问题是，除非你计划使用其他技术（如分片），并相应地修改应用程序，否则它们无法水平扩展。这将是一个繁重的工作。

对于数据库来说，采取预防措施并减少其负载是更好的做法。使用多种存储方法的组合，如将用户会话存储在单独的 NoSQL 数据库中，将静态内容存储在对象存储中，并应用外部缓存，有助于减轻主数据库的负担。最好将主数据库节点保留用于写入和更新数据，并使用额外的只读副本来处理所有读取请求。例如，Amazon RDS for MySQL 为关系数据库提供最多 15 个只读副本。只读副本在与主节点同步时可能会有毫秒级的延迟，在设计应用程序时需要考虑这一点。建议使用缓存引擎，如 Memcached 或 Redis，来缓存频繁的查询，从而减少主节点的负担。

如果数据库的增长超出了当前容量，你需要通过应用分区将其重新设计并分割成多个分片。

每个分片可以独立增长，应用程序需要确定一个分区键来将用户数据存储在相应的分片中。例如，如果分区键是user_name，那么A到E的用户名可以存储在一个分片中，F到I的用户名可以存储在第二个分片中，依此类推。应用程序需要根据用户名的首字母将用户记录定向到正确的分区。

正如你所看到的，扩展性是设计解决方案架构时的一个重要因素，如果规划不当，它会显著影响整体项目预算和用户体验。解决方案架构师在设计应用程序并优化工作负载以实现最佳性能和最低成本时，始终需要考虑弹性。

解决方案架构师需要评估不同的选项，如用于静态内容扩展和负载均衡的 CDN，服务器扩展的自动扩展选项，以及用于缓存、对象存储、NoSQL 存储、只读副本和分片的各种数据存储选项。

构建弹性架构

在专注于扩展性以提升应用性能的同时，构建一个成本意识的架构设计至关重要。这意味着，随着你扩展服务器基础设施以满足不断增长的用户需求，系统也应该在服务器负载减少时进行收缩。弹性是正确调整架构大小所必需的，它涉及将服务器基础设施扩展到准确匹配当前需求。它是一种平衡行为，确保有足够的容量高效处理峰值负载，同时避免在非高峰时段过度配置资源，导致资源闲置。

让我们继续以电子商务网站为例，考虑一种现代的三层架构，并看看如何在不同的应用层实现弹性。在这里，我们仅关注架构设计中的弹性和扩展性方面。图 2.4展示了 AWS 云技术栈的三层架构图：

图 2.4：扩展三层架构

该图描绘了一个三层架构，旨在实现弹性和高可用性，重点是构建一个弹性的服务器集群，以高效地管理可变负载。

以下是架构组件：

• 弹性负载均衡自动将传入的应用流量分配到多个目标上，如 Amazon 弹性计算云（EC2）实例、容器、IP 地址等，跨多个可用区进行分配。这增加了电子商务应用的容错能力。

• Web 层由一个 EC2 实例的自动扩展组组成，旨在为应用提供动态内容。这个实例组可以根据定义的标准（如 CPU 利用率）自动扩展（增加实例）或收缩（移除实例），确保它能够适应传入的流量并保持一致的性能。

• 应用层还具有一个 EC2 实例的自动扩展组，负责执行应用的业务逻辑。与 Web 层类似，这一层可以根据应用负载的需求动态调整其大小。

• 在底部，数据库层包括 Amazon 关系型数据库系统（RDS）实例，这些实例提供托管的关系型数据库。设置包括一个主数据库实例和一个只读副本，用于处理读取密集型操作，提高性能并减少主实例的负载。还有一个位于不同可用区的备用实例，用于高可用性和故障转移支持。

该架构允许灵活、可扩展的应用环境，可以跨多个可用区处理可变的工作负载并保持高可用性。它设计成能够根据应用需求自动扩展和收缩，确保用户体验一致、响应迅速的性能。

当用户通过网站或移动应用访问并与应用互动时，他们的请求将通过 Amazon Route 53 路由，它是一个高度可用且可扩展的 域名系统（DNS）Web 服务。Amazon CloudFront 作为 CDN 被用来高效地分发静态内容，如图片、样式表和 JavaScript 文件。这减少了 Web 服务器的负载，并通过降低延迟提升了用户体验。

在这一部分，你已经了解了各种扩展方法，以及如何将弹性注入到架构的不同层级。可扩展性是确保应用高可用性的关键因素，进而使应用具备弹性。我们将在下一部分学习更多关于高可用性和弹性的内容。

构建高度可用且具有弹性的架构

创建高度可用和具有弹性的架构需要设计能够容忍单个组件故障而不影响整体系统功能的系统。

高可用架构

一个组织想要避免的事情就是 停机时间。应用的停机时间会导致业务损失和用户信任度下降，使得 高可用性 成为设计解决方案架构时的首要因素。高可用性的原则是“设计时考虑故障，任何故障都无法发生。”

应用的正常运行时间需求因应用而异。如果你有一个面向外部的大型用户群体的应用，例如一个电子商务网站或社交媒体平台，100% 的正常运行时间变得至关重要。对于一个内部应用（由员工访问，如人力资源系统或公司内网），它可能能够容忍一些停机时间。实现高可用性与成本直接相关，因此解决方案架构师必须根据应用需求始终规划高可用性，以避免过度设计。

为了实现高可用架构，最好将工作负载规划在一个孤立的物理位置，这样，如果一个地方发生故障，应用的副本可以从另一个位置运行。高可用架构与自愈能力密切相关，你可以确保应用始终运行，但你还需要快速恢复以保持期望的用户体验。

弹性架构

弹性架构意味着你的应用应该在恢复故障时仍能为客户提供服务。让你的架构具有弹性包括应用最佳实践来应对由于更多用户请求、恶意攻击和架构组件故障而导致的负载增加。弹性需要在所有架构层面上应用，包括基础设施、应用、数据库、安全和网络。一个弹性架构应该在预定的时间内从故障中恢复。

为了让你的架构具备弹性，你需要定义恢复时间，并解决以下几点：

• 在需要的地方识别并实现冗余的架构组件。

• 理解何时修复与何时替换架构组件。例如，修复服务器问题可能比用相同的机器镜像替换它更耗时。

实现冗余

冗余是构建弹性系统的一个关键因素。构建弹性架构需要多层次的冗余策略。这包括在单一数据中心内跨不同机架部署服务器集群，扩展到同一区域内的多个数据中心，甚至跨多个地理区域进行部署。这种地理分布确保了抵御局部和区域性灾难的能力，并为全球用户群体降低延迟。

结合智能负载均衡和全球流量管理，例如基于 DNS 的路由和健康检查，确保用户始终从最优位置获取服务。通过战略性复制实现数据库的韧性，并配备自动故障转移机制，以保持数据库的可用性和完整性。

如果服务器分布在不同的物理位置，则流量路由的第一层可以通过 DNS 服务器处理，直到流量到达负载均衡器。这样，在整个区域发生故障时，您的应用程序仍然可以继续运行。

图 2.5：使用 DNS 服务器的应用架构韧性

正如您在前述架构中所看到的，韧性必须应用于所有影响应用可用性的关键层，以实现能够承受故障的设计。为了实现韧性，除了使用 DNS 服务器在不同的物理位置之间路由流量外，还需要应用以下最佳实践来创建冗余环境：

• 使用 CDN 将视频、图像和静态网页等静态内容分发并缓存到靠近用户位置的地方，这样您的应用程序仍然可以保持可用。

• 一旦流量到达某个区域，使用负载均衡器将流量路由到一组服务器，这样即使该区域的一个位置发生故障，您的应用程序仍然可以运行。

• 使用自动伸缩根据用户需求添加或移除服务器。因此，您的应用程序不应受到单个服务器故障的影响。

• 创建备用数据库以确保数据库的高可用性，这意味着在数据库故障时，您的应用程序应该仍然可用。

解决组件故障

如果某些组件发生故障，您应该有备份以恢复它们，并实现架构的韧性。DNS 服务器上的负载均衡器和路由器执行健康检查，确保流量仅路由到健康的应用实例。您可以配置它执行浅层健康检查，监控本地主机故障，或者执行深度健康检查，这也能处理依赖项故障。然而，深度健康检查需要更多的时间，并且比浅层健康检查更消耗资源。您将在第八章，架构可靠性考虑中了解更多关于韧性架构的内容。

在应用层面，必须避免级联故障，即一个组件的故障可能导致整个系统瘫痪。为减少系统中级联故障的风险，可以采取多种机制：

• 超时：为操作和请求设置最大时间限制可以防止无限等待响应，从而避免资源耗尽。

• 流量拒绝：当系统负载过重时，它可以主动拒绝新请求，以防止过载，并保持现有进程的稳定性。

• 幂等操作：确保操作可以重复执行而不会造成意外效果，可以帮助从中间故障中恢复而无需重复操作或引起不一致。

• 断路器：实施断路器模式可以检测故障模式并打开“电路”，停止对故障服务的进一步请求，使其恢复并防止故障扩散到系统的其他部分。

通过采用这些策略，系统可以变得更加弹性，保持在单个组件故障的情况下的功能性，并防止这些故障升级为广泛的系统故障。

尽管高可用性和弹性确保系统对用户可用，但在保持性能的同时，容错性也至关重要。现在让我们转向容错的主题。

使架构具有容错性

高可用性意味着您的应用程序对用户可用，但可能会导致性能下降。假设您需要四台服务器来处理用户流量。为此，您将两台服务器放置在两个物理隔离的数据中心中。如果一个数据中心出现故障，用户流量可以从另一个中心提供服务。但现在您只有两台服务器，这意味着只有原始容量的 50%可用，用户可能会遇到性能问题。在这种情况下，您的应用程序具有 100%的高可用性，但只有 50%的容错能力。

如图 2.6所示，要实现 100%的容错能力，您需要完全的冗余，并且必须保持双倍的服务器数量，以便在一个区域发生故障时，用户不会遇到任何性能问题。

图 2.6：容错架构

容错性是在不影响系统性能的情况下处理工作负载容量。全面容错的架构由于增加的冗余而带来高昂的成本。您的用户群体能否接受应用程序恢复期间的性能降级取决于应用程序的关键性。

在设计应用程序架构时，解决方案架构师需要确定应用程序用户的性质以及是否需要 100%的容错能力，这必然会带来成本影响。例如，电子商务网站可能需要 100%的容错能力，因为性能降低直接影响业务收入。同时，内部的工资单系统，员工在月底检查其工资单时使用，可以容忍短时间内的性能降低。让我们深入探讨构建高性能架构的问题。

为性能设计

随着快速互联网的普及，客户正在寻求具有最低加载时间的高性能应用程序。组织已经注意到，直接的收入影响与应用程序性能成正比，而应用程序加载时间的慢速会显著影响客户参与度。现代公司在性能方面设定了高期望，这导致高性能应用程序成为在市场中保持竞争力的必要条件。

与弹性一样，解决方案架构师需要在架构设计的每一层考虑性能。DevOps 团队需要实施监控，以检查解决方案是否持续有效地运行，并不断改进。更好的性能意味着更高的用户参与度和投资回报率。

高性能应用程序设计用于应对因外部因素（如慢速互联网连接）导致的应用程序缓慢。例如，您可能已经设计了一个博客网页，在良好的互联网环境下加载时间为 500 毫秒。然而，在互联网较慢的地方，您可以先加载文本并通过这些内容吸引用户，同时图像和视频仍在加载中。

在理想环境下，随着应用程序工作负载的增加，自动扩展机制开始处理额外的请求，而不会影响应用程序性能。但在现实世界中，随着扩展生效，您的应用程序延迟会在短时间内下降。为了了解它在实际情况中的表现，最好通过增加负载来测试应用程序的性能，并了解是否能够实现预期的并发性和用户体验。

您需要根据工作负载选择正确类型的服务器。例如，选择合适的内存和计算能力来处理工作负载，因为内存拥塞可能会减慢应用程序性能，并最终导致服务器崩溃。您还应选择正确的每秒输入/输出操作数（IOPS）用于存储。对于写密集型应用程序，您需要高 IOPS 以减少延迟并提高磁盘写入速度。

IOPS 是一种性能衡量标准，用于基准测试存储设备（如硬盘、固态硬盘和存储区域网络）读取和写入数据的速度。每个输入或输出操作可能是一次数据读取或数据写入。

为了实现更高的性能，请在架构设计的每一层应用缓存。缓存使您的数据可以本地提供给用户，或将数据保存在内存中以提供超快速响应。

以下是在您的应用程序设计的各个层面添加缓存时需要考虑的事项：

• 使用用户系统上的浏览器缓存来加载经常请求的网页。

• 使用 DNS 缓存以快速查找网站。

• 使用 CDN 缓存来存储靠近用户位置的高分辨率图像和视频。

• 在服务器级别，最大化内存缓存以服务用户请求。

• 使用缓存引擎，如 Redis 和 Memcached，从缓存引擎提供频繁查询服务。

• 使用数据库缓存从内存中为频繁查询提供服务。

• 注意缓存过期问题，缓存过期是指存储在缓存中的数据变得过时，并被标记为更新或移除。而缓存淘汰则是指将数据从缓存中移除，通常是为了为新数据腾出空间。

如你所见，保持应用程序的高性能是一个至关重要的设计方面，且直接与组织的盈利能力相关。解决方案架构师在创建解决方案设计时需要考虑性能，并应不懈努力提升应用程序的性能。在第六章，性能考虑中，你将深入了解这一点，并学习优化应用程序以提高性能的技术。

创建不可变架构

组织在硬件上进行大量资本投入，并养成定期用新版本的应用程序和配置来刷新硬件的做法。随着时间推移，这可能导致不同的服务器运行不同的配置，排查问题变得繁琐。有时，组织可能不得不继续运行不必要的资源，因为不确定该关闭哪个服务器，这可能会导致应用程序失败。无法替换服务器使得在你的服务器集群中推出和测试任何新更新变得具有挑战性。这些问题可以通过将服务器视为可替换资源来解决，从而更快速地适应变化，如升级应用程序和底层软件，减少停机时间，并快速修复应用问题。因此，在设计应用程序时，你应该始终考虑不可变基础设施。这意味着，在应用程序升级过程中，你不仅会替换软件，还会替换硬件。

在现代云架构中，采用将服务器视为牲畜而非宠物的思维方式是至关重要的。这种方法意味着，个别服务器不会被精心维护或定制到无法替代的程度。相反，服务器被设计为可以快速配置、一致管理，并在不对整体系统造成重大影响的情况下被处置或替换。这种方法提高了可扩展性和弹性，因为它允许快速适应需求变化或从故障中恢复。

为了创建可替换的服务器，建议使你的应用程序无状态，以保持用户体验，并避免硬编码任何服务器 IP 或数据库 DNS 名称，以防止在替换过程中出现故障。你需要应用将基础设施视为代码而非硬件的理念，并避免对在线系统进行更新。

使用虚拟机创建不可变基础设施变得更加可行。你可以创建虚拟机的黄金镜像，并使用它来部署新版本的基础设施，而不是尝试更新现有版本。你应始终从黄金镜像启动新的服务器实例，该镜像作为模板，已包含所有必要的安全性和软件。这种部署策略对于服务器故障排除也很有帮助，你可以丢弃出现问题的服务器，并从黄金镜像启动新服务器。

在丢弃有问题的服务器之前，你应该备份日志以进行根本原因分析。这种方法还能确保环境的一致性，因为你使用相同的基准服务器镜像来创建所有环境。

松耦合是另一个关键的设计原则，它与“牛群而非宠物”方法相辅相成。它涉及设计系统组件，使其通过明确定义的接口进行交互，并且独立性足够强，组件之间的变化不会导致其他组件的变化。这样的分离增强了灵活性和可扩展性，使得各个组件能够独立演化、扩展或从故障中恢复。让我们更深入了解松耦合。

思考松耦合

传统的应用程序部署在紧密集成的服务器队列上，其中每台服务器都有特定的责任。通常，应用程序依赖多个服务器来实现功能的完整性。

如下图所示，在紧耦合架构中，网页服务器队列直接依赖于所有应用服务器，反之亦然：

图 2.7：紧耦合架构

在之前的架构图中，如果某个应用服务器出现故障，所有的网页服务器将开始接收错误请求，因为请求会被路由到不健康的应用服务器，这可能导致整个系统的故障。在紧耦合架构下，如果你想通过添加或移除服务器来进行扩展，那么需要做很多工作，因为所有的连接都需要适当设置。

使用松耦合，你可以添加一个中间层，例如负载均衡器或队列，它会自动处理故障或扩展问题。

在下图的架构中，网页服务器和应用服务器队列之间有一个负载均衡器，它确保用户请求始终由健康的应用服务器提供服务：

图 2.8：基于负载均衡器的松耦合架构

如果某个应用服务器出现故障，负载均衡器会自动将所有流量引导到其他三个健康的服务器上。松耦合架构还帮助你独立扩展服务器，并优雅地替换不健康的实例。它使得你的应用更具容错性，因为错误的范围仅限于单个实例。

松耦合架构也可以是基于队列的；以一个图像处理网站为例，你需要存储一张图片，然后对其进行编码、生成缩略图和版权处理。以下架构图展示了基于队列的解耦。通过在系统之间使用队列并交换消息，将工作通过这些队列传递，从而实现了系统的松耦合。

图 2.9：基于队列的松耦合架构

基于队列的解耦实现了系统的异步连接，其中一个服务器不会等待另一个服务器的响应，而是独立工作。这种方法让你可以增加接收和处理消息的虚拟服务器数量，并行工作。如果没有需要处理的图像，例如，你可以配置自动扩展来终止多余的服务器。

在一个复杂的系统中，通过创建微服务架构来实现松耦合架构，其中独立的服务包含一整套功能，并通过标准协议彼此通信。在现代设计中，这种事件驱动的设计变得非常流行，有助于应用程序组件的解耦。松耦合设计具有许多优点，从可扩展性、高可用性到易于集成。

想想服务，而不是服务器

在上一节中，你了解了松耦合以及为什么架构的松耦合对可扩展性和容错性如此重要。培养面向服务的思维将有助于实现松耦合架构（与面向服务器的思维相对，后者可能导致硬件依赖和紧耦合架构）。基于微服务的事件驱动架构帮助我们实现了解决方案设计的易部署和易维护。

在 RESTful 架构中，你可以将消息格式化为 XML、JSON 或纯文本，并通过简单的 HTTP 协议将其发送到互联网。RESTful 架构之所以受欢迎，是因为它非常轻量。微服务基于 RESTful 架构，并且可以独立扩展，这使得你可以在不影响其他组件的情况下，轻松扩展或缩减应用程序的某个组件。

正如你在以下图表中看到的，在单体架构中，所有组件都构建为一个服务，因此部署在单一服务器上，并与单一数据库绑定，造成了硬依赖。相比之下，在微服务架构中，每个组件都是独立的，拥有自己的框架和数据库，从而允许它们独立扩展：

图 2.10：单体架构与微服务架构

在前面的图示中，你可以看到一个电子商务网站的例子，展示了单体架构和微服务架构，在这个架构中，客户可以登录并下单，假设他们想要的商品有货，通过将商品添加到购物车来完成。

要将单体架构转换为基于微服务的架构，你可以创建由小型、独立组件组成的应用程序，这些组件是构成更小部分并进行迭代的基础。

模块化方法减少了成本、规模和变更风险。在前述案例中，每个组件都作为服务独立创建。这里，登录服务可以独立扩展以处理更多流量，因为客户可能会频繁登录以浏览产品目录和订单状态。相比之下，订单和购物车服务的流量可能较少，因为客户不太可能频繁下单。

解决方案架构师在设计解决方案时需要考虑微服务。服务的明显优势是，代码的维护面更小，而且服务是自包含的。然而，监控微服务需要比传统单体应用更为细致的方法，因为微服务的分布式特性。每个微服务独立运行，这意味着监控必须在单个服务层级以及系统层级进行，以确保对应用程序健康和性能的全面视图。

你可以构建没有外部依赖的微服务。所有的前置条件都包含在服务中，这使得松耦合和扩展成为可能，同时在发生故障时可以减少冲击范围。

任何应用程序设计都围绕数据展开，从数据出发来反推设计有助于构建最佳架构。让我们进一步了解数据驱动的设计。

思考数据驱动设计

任何软件解决方案都围绕数据的收集和管理展开。以电子商务网站为例，软件应用程序的构建旨在展示网站上的产品数据，并鼓励客户购买产品。它从收集客户数据开始，当客户创建账户、添加支付方式、存储订单交易以及在产品销售时维护库存数据。另一个例子是银行应用程序，它存储客户的财务信息，并确保所有金融交易数据的完整性和一致性。对于任何应用程序来说，最重要的是适当地处理、存储和保护数据。数据在很大程度上影响着解决方案的设计，通过始终关注数据，你可以为自己的需求应用合适的设计驱动解决方案。

不仅仅是应用设计围绕数据展开，运营维护和商业决策也同样如此。你需要增加监控功能，确保你的应用和业务能够顺利运行。例如，在应用监控中，你需要从服务器收集日志数据并创建仪表板以可视化指标。持续的数据监控和在出现问题时发送警报可以帮助你通过触发自动修复机制快速从故障中恢复。

作为解决方案架构师，你需要考虑应用设计和整体商业价值主张，包括如何收集数据并在应用程序中加以利用，这有助于提高客户满意度并最大化投资回报。数据就是金矿，深入洞察数据能够显著影响组织的盈利能力。

在各个方面添加安全性

安全性是解决方案设计中至关重要的方面；任何安全上的漏洞都可能对企业或组织的未来造成灾难性的影响。许多组织因安全漏洞而遭受损害，导致客户信任丧失并损害企业声誉。行业标准的规定，如PCI（支付卡行业）、HIPAA（健康保险流通与问责法案）、GDPR（通用数据保护条例）和SOC（系统与组织控制）合规性，都是确保数据在不同领域安全的关键框架。PCI 保护金融行业的信用卡信息，HIPAA 保护医疗行业的患者数据，GDPR 增强欧盟地区的数据隐私，而 SOC 确保服务组织中的数据管理安全，执行安全保护措施以保护消费者数据，同时为组织提供标准化的指导。根据你的行业和地区，你必须遵守本地法规，满足诸如这些合规需求。

安全性会显著影响解决方案设计，因此在开始设计之前，你需要了解你的安全需求。安全性需要在硬件层面进行平台准备，同时在软件层面进行应用开发。

以下是在设计阶段需要考虑的安全方面：

• 数据中心物理安全：数据中心中的所有 IT 资源应防止未经授权的访问。

• 网络安全：网络应保持安全，防止任何未经授权的服务器访问。

• 身份与访问管理（IAM）：只有经过身份验证的用户才能访问应用程序，并且他们可以根据授权进行相应的操作。

• 数据传输中的安全：数据在通过网络或互联网传输时应保持安全。

• 静态数据安全：数据在数据库或任何其他存储介质中存储时应保持安全。

• 安全监控：任何安全事件都应被捕捉，团队应收到警报并采取行动。

应用程序设计需要平衡安全要求（如加密）与其他因素（如性能和延迟）。数据加密始终会对性能产生影响，因为它增加了额外的处理层，因为数据需要解密才能被使用。您的应用程序需要在不影响整体性能的情况下适应额外加密处理的开销，因此在设计应用程序时要考虑需要加密的使用场景。例如，如果数据是机密的，您需要对其进行加密。

与安全相关的应用程序设计的另一个方面是遵守当地法律的合规性。如果您的应用程序属于受监管行业（如医疗、金融或联邦政府），合规性至关重要。每种合规性都有其要求，通常包括数据保护和记录每项活动以供审计。您的应用程序设计应包括全面的日志记录和监控，以满足审计要求。

安全性是应用程序弹性最重要的方面之一。从安全角度来看，分布式拒绝服务（DDoS）攻击可能会影响服务和应用程序的可用性。DDoS 攻击通常会在服务器上产生虚假流量，使其忙碌，这意味着合法用户无法访问您的应用程序。这种攻击可能发生在网络层或应用层。采取积极的预防措施来防止 DDoS 攻击至关重要。尽可能将应用程序的工作负载保留在私有网络中，并避免将应用程序端点暴露在互联网上。

安全自动化是您应始终与设计一起实施的另一个因素，以减少和缓解任何安全事件。安全自动化涉及利用技术执行安全任务，而无需人工干预，从而简化安全事件的检测、分析和修复。通过集成自动化的安全措施，您可以实现持续监控和实时威胁检测，从而更快响应漏洞和安全漏洞。

在本节中，您已经学习了如何在设计过程中应用安全思维，并考虑任何监管需求。然而，您在这里得到的是一个高层次的概述。您将在第七章，安全性考虑中学习更多细节。

您可能会创建一个功能丰富的产品，但只有当用户发现它易于导航和访问时，才会广泛吸引用户。应用程序的可用性和可访问性在产品成功中起着至关重要的作用。让我们在下一部分了解更多内容。

使应用程序易用且可访问

确保应用既可用又可访问是设计中的一个关键方面，直接影响用户体验。可用性指的是用户与应用交互时的易用性和直观性，这涉及到用户友好的界面、清晰的导航以及高效的任务完成流程。另一方面，可访问性确保应用可以被各种有不同障碍的用户使用。我们来了解更多相关内容。

实现可用性

你希望用户在浏览应用时能够拥有无缝的体验。它应该顺畅到让用户甚至不注意到他们是如何轻松找到所需内容的，而没有遇到任何困难。你可以通过提高应用的可用性来实现这一点。

可用性是指用户第一次使用应用时能够多快学习到导航逻辑。它关乎用户如果犯错后能多快恢复，并且是否能高效完成任务。如果应用功能复杂且功能丰富，但不能有效使用，那么它就没有意义。目标是创建一个直观且用户友好的界面，提升用户体验，确保应用的功能对于所有用户都可访问且易于理解。

用户研究和测试对于定义能够满足用户体验的可用性至关重要。

实现可访问性

在设计应用时，你通常希望面向全球用户或重要的地理区域。你的用户群体在技术设施和身体能力方面会有很大的差异。可访问性关乎包容性；你希望你的应用对每个人都可访问，无论用户是否有慢速的互联网连接、使用旧设备，还是有身体限制。

在设计应用时，解决方案架构师必须确保考虑到可访问性。有时，可能需要完全创建应用的不同版本来实现这一目标。

可访问性设计应包括设计组件，例如语音识别与语音导航、屏幕放大器，以及能将内容大声朗读出来的功能，以帮助那些因视力或听力障碍而无法轻松访问和使用应用的用户。

本地化帮助应用以特定地区的语言（例如西班牙语、普通话、德语、印地语或日语）提供服务，使全球用户能够以自己的母语浏览应用。

如图 2.11所示，客户满意度是可用性和可访问性的重要组成部分。

图 2.11：客户对可用性和可访问性的满意度

要实现可用性和可访问性，你必须了解你的用户——其中可访问性是可用性的一个组成部分——它们是密切相关的。在开始解决方案设计过程之前，解决方案架构师应与产品负责人一起，通过访谈和调查研究用户，并收集对前端设计原型的反馈。你需要了解用户的限制，并在应用开发过程中通过支持性功能赋能用户。

当产品上线时，团队应该规划 A/B 测试，将一小部分用户流量引导到新功能上，并了解用户的反应。A/B 测试涉及对比应用的两个版本，评估其表现，并确定哪个版本更优。上线后，应用程序必须具备收集持续反馈的机制（例如提供反馈表单或启动客户支持），以不断优化设计。

随着用户不断变化，架构应能够跟上不断增长的需求。为此，你需要设计可扩展且具有未来保障的架构。让我们学习如何使你的架构具备未来保障。

构建具有未来保障的可扩展和可重用架构

随着企业的成长，业务也在不断演变；应用程序需要扩展以应对日益增加的用户群体，并增加更多功能，以保持领先地位并获得竞争优势。解决方案设计需要具备足够的可扩展性和灵活性，以便修改现有功能或添加新功能。

为了实现解决方案的可扩展性，解决方案架构师必须尽可能使用松耦合架构。总体而言，创建 RESTful 或基于队列的架构有助于在不同模块或跨应用程序之间开发松耦合的通信。你将在第四章、解决方案架构设计模式中学习到更多关于其他类型架构的内容。在本节中，我们将通过一个简单的例子来解释架构灵活性的概念。

为了模块化他们的应用程序，组织通常希望构建一个包含一组功能的平台，并将其作为独立的应用程序发布。这只有通过可重用的设计才能实现。

图 2.12 显示了一个电商应用中的基于 API 的架构。在这里，你有独立的服务，如产品目录、订单、支付和配送，最终用户应用程序可以按需选择使用这些服务。客户通过移动端和浏览器应用程序下单。这些应用程序需要一个产品目录服务，让客户浏览网页上的产品，一个订单服务让他们下单，以及一个支付服务处理支付。

反过来，产品目录和订单服务与配送服务进行通信，将已订购的商品送到客户的家门口。另一方面，实体店使用销售点系统，客户代表扫描条形码、代为下单并收取付款。在这里不需要配送服务，因为顾客可以到店内领取商品。

图 2.12：基于 API 的可扩展架构

在图 2.12中，您可以看到用于第三方 API 集成的 Reward API。这种架构允许您扩展当前设计，以集成 Reward API，从而通过在客户购买商品时提供优惠来提高客户保持率，并吸引新客户。在这里，您可以看到支付服务被在线和店内订单共同重用。如果组织希望为礼品卡服务、餐饮服务等收取付款，另一个服务也可以重用支付服务。

可扩展性和可重用性不仅限于服务设计层面——它们深入到实际的 API 框架层面，软件架构师应该使用面向对象分析与设计（OOAD）的概念，如继承，来创建一个可扩展和可重用的 API 框架，为同一服务添加更多功能。

OOAD 是软件工程中的一种基础性方法，帮助开发人员更有效地规划和建模应用程序，确保软件具有模块化、可扩展和可维护的特性。

为了扩展应用程序功能，它需要与其他产品无缝对接，以便扩展数据和事务。使应用程序与生态系统互操作有助于通过利用其他相关应用程序来添加新功能。让我们进一步了解如何构建兼容的架构。

确保架构的互操作性和可移植性

架构的互操作性和可移植性是现代软件架构中至关重要的方面，确保应用程序能够在不同环境中运行，并与其他系统无缝地互动。让我们来看一下这些概念。

使应用程序具备互操作性

互操作性是指一个应用程序通过标准格式或协议与其他应用程序协同工作的能力。通常，一个应用程序需要与多个上游系统进行通信以获取数据，并与下游系统进行通信以提供数据，因此，确保这种通信无缝进行至关重要。

例如，一个电子商务应用程序需要与供应链管理生态系统中的其他应用程序协同工作。这包括企业资源规划应用程序，用于记录所有交易，运输生命周期管理、运输公司、订单管理、仓库管理和劳动管理。

所有应用程序应该能够无缝交换数据，以实现从客户订单到交付的端到端功能。无论是在医疗保健应用、制造应用，还是电信应用中，您都会遇到类似的使用案例。

解决方案架构师在设计时需要考虑应用程序的互操作性，通过识别并处理各种系统依赖关系。一个互操作的应用程序在成本方面能够节省很多，因为它依赖于可以以相同格式进行通信的系统，无需任何数据消息传输工作。

每个行业都有其标准的数据交换大小，需要了解并遵守。一般来说，在软件设计中，架构师可以为不同的应用选择一种流行的格式，如 JSON 或 XML，以便它们能够相互通信。现代 RESTful API 设计和微服务架构都原生支持这两种格式。

使应用程序具备可移植性

系统可移植性允许您的应用在不同环境中运行，且只需最小的更改或不需要更改。任何软件应用都必须能够在各种操作系统和硬件上运行，以实现更高的可用性。

由于技术变化迅速，您经常会看到新的软件语言、开发平台或操作系统版本发布，您需要确保您的应用程序能够适应这些变化。如今，移动应用程序是任何系统设计中不可或缺的一部分，您的移动应用需要与主要的移动操作系统平台兼容，例如 iOS 和 Android。

在设计阶段，解决方案架构师需要选择一种可以实现应用程序所需可移植性的技术。例如，如果您的目标是将应用程序部署到不同的操作系统上，像 Java 这样的编程语言可能是一个不错的选择，因为几乎所有操作系统都支持它，您的应用将能够在不同平台上运行，而无需进行移植。对于移动应用，架构师可能会选择一个基于 JavaScript 的框架，如 React Native，它可以提供跨平台的移动应用开发。

互操作性丰富了系统的扩展性，而可移植性增加了应用程序的可用性。两者都是架构设计的关键属性，如果在解决方案设计时没有得到解决，可能会带来成倍的成本。解决方案架构师必须根据行业需求和系统依赖关系仔细考虑这两个方面。

自动化是减少错误和提高效率的关键。我们接下来会讨论这个。

在各处应用自动化

大多数事故发生是由于人为错误，而这些错误可以通过自动化避免。自动化不仅能够高效处理任务，还能提高生产力并节省成本。任何被认为是可重复的任务都可以进行自动化，从而释放宝贵的人力资源，让团队成员将时间用于更有趣的工作，并专注于解决实际问题。这也有助于提高团队士气。

在设计解决方案时，要考虑可以自动化的部分。思考哪些可重复的任务可以被自动化。考虑以下组件是否可以在你的解决方案中自动化：

• 应用测试：每次对应用程序进行更改时，都需要进行测试，以确保没有破坏任何功能。此外，手动测试非常耗时并且需要大量资源。自动化可重复的测试用例更有利于加速部署和产品发布。你应该在生产规模上自动化测试，并使用滚动部署技术，如金丝雀发布和 A/B 测试，来发布更改。金丝雀测试涉及将更改发布给一小部分用户，以评估影响并在全面推出之前发现问题，充当潜在问题的早期警告系统。A/B 测试，或称为分流测试，比较应用程序的两个版本，以确定哪个版本在用户中表现更好，基于数据做出决策。

• IT 基础设施：你可以通过使用基础设施即代码脚本来自动化你的基础设施，例如 Ansible、Terraform 和 Amazon CloudFormation。基础设施的自动化使得环境的创建能够从几天缩短到几分钟。将基础设施作为代码进行自动化可以避免配置错误，并创建环境的副本。

• 日志记录、监控和警报：监控至关重要，你需要时刻监控一切，以确保应用程序的各个部分都正常运行，并能主动采取措施解决任何问题。只有通过自动化才能有效监控庞大的系统。你需要自动化所有活动监控和日志记录，以确保你的应用程序平稳运行并按预期工作。此外，基于监控，你应该采取自动化措施，如扩展系统或向团队发出警报以采取行动。

• 部署自动化：部署是一个可重复的任务，非常耗时，并且在许多实时场景中会导致最后时刻的发布延迟。通过应用持续集成和持续部署（CI/CD）自动化部署管道，能够帮助你更灵活，快速迭代产品特性，并进行频繁的发布。CI/CD 帮助你对应用程序进行小规模、增量式的更改。

• 安全自动化：在自动化一切时，记得加入安全自动化。如果有人试图攻击你的应用程序，你需要立即知道并迅速采取行动。

• 你需要通过自动化任何进出系统边界的流量，并设置警报以监控可疑活动，从而采取预防措施。

自动化通过帮助确保产品无故障运行，提供了安心感。在设计应用程序时，总是从自动化的角度思考，并将其视为一个关键组件。你将在第九章，运营卓越的考虑因素中深入了解自动化。

业务连续性规划

可能会出现这样的情况：由于大规模电网故障、地震、洪水或安全攻击，数据中心所在的整个区域出现停机，但你的全球业务应该继续运行。在这种情况下，你必须有一个灾难恢复计划，通过在完全不同的地区，甚至不同的大陆或国家，准备足够的 IT 资源来规划业务连续性，以便在出现问题时，业务能够迅速恢复或完全没有停机。

在规划灾难恢复时，解决方案架构师必须了解组织的恢复时间目标（RTO）和恢复点目标（RPO）。RTO 衡量业务可以承受多长时间的停机而不会造成重大影响；RPO 则表示业务可以容忍多少数据丢失。减少 RTO 和 RPO 意味着需要更高的成本，因此了解业务是否是关键任务并需要最小的 RTO 和 RPO 非常重要。例如，股票交易应用不能承受丢失任何数据点，而铁路信号系统应用不能有一秒钟的停机，因为人的生命安全依赖于此。

图 2.13中的架构图展示了一个多站点灾难恢复架构。主要数据中心位于欧洲爱尔兰，灾难恢复站点位于美国弗吉尼亚州，托管在 AWS 公有云上。在这种情况下，即使发生了欧洲地区或公有云的故障，企业仍然可以继续运营。基于多站点模型的灾难恢复计划，能够实现最小的 RTO 和 RPO，这意味着几乎没有停机时间和数据丢失。

图 2.13：混合多站点灾难恢复架构

以下是最常见的灾难恢复计划，所有这些你将在第十一章，DevOps 与解决方案架构框架中了解：

• 备份与存储：这是成本最低的方案，但具有最大的 RTO 和 RPO。在该方案中，所有服务器的机器镜像和数据库快照应存储在灾难恢复站点。团队将在灾难发生时尝试从备份中恢复灾难站点。

• Pilot lite：在此计划中，所有服务器的机器镜像都会被存储为备份，并且在灾难恢复站点维护一个小型数据库服务器，与主站点进行持续的数据同步。其他关键服务，如 Active Directory，可能会在小型实例中运行。在灾难发生时，团队将尝试从机器镜像中启动服务器，并扩展数据库。Pilot lite 方案比备份和存储更昂贵，但具有较低的 RTO 和 RPO。

• Warm standby：在此计划中，灾难恢复站点中的所有应用程序和数据库服务器（以低容量运行）实例继续与主站点同步。在灾难发生时，团队将尝试扩展所有服务器和数据库。Warm standby 方案比 Pilot lite 更昂贵，但具有更低的 RTO 和 RPO。

• Multi-site：此计划是最昂贵的，具有接近零的 RTO 和 RPO。此计划在灾难恢复站点中保持主站点的副本，并拥有相同的容量，能够主动服务用户流量。在灾难发生时，所有流量将被路由到备用位置。

通常，组织会选择成本较低的灾难恢复方案，但必须定期进行测试以确保故障切换能够正常工作。团队应将操作卓越性作为常规检查点，以确保在灾难恢复期间保持业务连续性。将应用程序投入生产并维护多年非常重要。让我们了解如何使应用程序具有可维护性和操作性的原则。

为运营设计

操作卓越性可以成为您应用程序的巨大差异化因素，通过提供高质量的服务给客户，减少停机时间。主动应用操作卓越性还帮助支持和工程团队提高生产力。可维护性与操作卓越性密切相关。易于维护的应用程序有助于降低成本，避免错误，并使您获得竞争优势。

解决方案架构师需要为运营设计，包括工作负载如何部署、更新和长期运营。规划日志记录、监控和警报至关重要，以捕捉所有事件并采取快速行动以确保最佳的用户体验。在可能的情况下应用自动化，无论是部署基础设施还是更改应用程序代码，以避免人为错误。

在设计中包括部署方法和自动化策略非常重要，因为这可以加速任何新变更的上市时间，而不影响现有的运营。操作卓越性规划应考虑安全性和合规性因素，因为监管要求可能会随时间变化，您的应用程序必须遵守这些要求才能正常运行。

维护可以是主动的，也可以是被动的；例如，一旦有新版本的操作系统发布，你可以立即更新你的应用程序以切换平台，或者监控系统健康状况，直到软件生命周期结束才进行任何更改。在任何情况下，变更都应该以小的增量进行，并且有回滚策略。为了应用这些变更，你可以通过设置 CI/CD 流水线来自动化整个过程。在发布时，你可以计划 A/B 测试或蓝绿部署。

对于运营准备，架构设计应包括适当的文档和知识共享机制——例如，创建并维护运行手册以记录日常活动，并创建操作手册以指导你的系统过程应对问题。这使得你在发生事故时能够迅速采取行动。你应该使用根本原因分析进行事后报告，以确定问题发生的原因，并确保不会再发生。

运营卓越和维护是持续进行的；每一次操作事件和故障都是通过从以往的错误中学习来改善操作的机会。你必须分析操作活动和故障，进行实验，并不断改进。你将在第九章，运营卓越的考虑因素中学到更多关于运营卓越的内容。

在第一章，组织中的解决方案架构师中，你学习了一个解决方案架构需要处理和平衡的各种约束。处理约束是一个关键的架构原则，我们接下来会详细讨论这个问题。

克服架构约束

在设计应用架构时，主要的限制因素是成本、时间、预算、范围、计划和资源。克服这些约束是设计解决方案时必须考虑的重要因素。你应该将这些限制视为可以克服的挑战，而不是障碍，因为挑战总是推动你达到创新的极限。

解决方案架构师需要在考虑约束的同时做出适当的权衡。例如，高性能应用需要在架构的多个层次中添加额外的缓存，这会导致更多的成本。然而，有时，成本比性能更重要，特别是当一个系统被内部员工使用时，这可能不会直接影响收入。有时，市场的需求比推出一个功能全面的产品更为重要，在这种情况下，你需要在范围和速度之间做出权衡。在这种情况下，你可以采用最小可行产品（MVP）的方法；你将在下一节中学到更多关于这一点的内容。

在大型组织中，技术约束变得尤为明显，因为在数百个系统中进行变更将是一个巨大的挑战。在设计应用程序时，需要使用组织内最常见的技术。还需要确保应用程序能够升级，以便采用新技术，并能够插入在不同平台上构建的组件。

当团队可以自由选择任何技术进行开发时，RESTful 服务模型非常受欢迎。它们只需要提供一个 URL，客户就可以通过该 URL 访问他们的服务。即使是旧的系统，如大型主机，也可以通过围绕其构建的 API 封装器集成到新系统中，这有助于克服技术挑战。

在本书中，您将学习如何处理各种架构约束。MVP 方法帮助您克服这些约束，构建以客户为中心的产品。

采取 MVP 方法

对于成功的解决方案，始终将客户放在首位，从客户的需求出发进行反向思考，确定他们的关键需求，并以敏捷的方式规划解决方案交付。

MVP 是一种开发策略，用于构建一个新的产品或网站，只包含满足早期用户需求和在产品开发周期初期验证产品想法所必需的最少功能。在这种方法中，产品的初始版本仅包含允许产品部署的核心功能，其他一切都不包含。目标是提供即时价值，最小化开发成本，并尽可能快速地收集客户反馈，以便不断迭代和改进产品。

优先排序客户需求的一个流行方法是MoSCoW，您可以将需求划分为以下几类：

• Mo (必须具备的)：对客户至关重要的需求，没有这些需求，产品无法发布

• S (应该具备的)：一旦客户开始使用应用程序后，最希望具备的需求

• Co (可以具备的)：需要的需求是非常理想的，但其缺失不会影响应用程序所需的功能

• W (不需要的)：如果客户没有注意到，可能不会觉得缺少的需求

您需要为客户规划一个 MVP，确保具备必须具备的需求，并进行下一次交付迭代，确保具备必须具备的需求。通过这种分阶段交付的方法，您可以充分利用资源，克服时间、预算、范围和资源的挑战。MVP 方法帮助您确定客户需求。您不是在尝试构建一切，而是知道您的功能是否为客户带来价值。这种以客户为中心的方法有助于明智地利用资源，减少资源浪费。

在下图中，您可以看到一个卡车制造交付的 MVP 评估，其中客户最初需要交付的卡车，并根据客户的需求和反馈逐步演变这个过程：

图 2.14：MVP 方法构建解决方案

一旦客户得到第一辆功能完备的交付卡车，他们就能判断是否需要更强大或更大的卡车来处理更大的负载。基于此，制造商可以制造 6 轮、10 轮或 18 轮卡车拖车。这种逐步推进的方法提供了具备基本功能的工作产品，客户可以使用这些产品，团队也可以根据客户需求继续在其基础上构建。

你可以看到，MVP（最小可行产品）方法如何帮助高效利用有限资源，从而为高质量产品开发争取更多时间并明确范围，这与一种方法相比显得更加高效：在我们第一次到达时，发现只需要一辆 6 轮卡车而不是一辆 18 轮卡车。将工作的产品尽早交到客户手中，可以让你更清楚地了解需要在哪些方面进行投资。由于你的应用程序已经开始产生收入，你可以展示使用案例，以便根据需要申请更多资源。

总结

本章为你提供了设计原则的深入概述，这些原则是构建有效且高效系统所必需的。最初，我们探讨了可扩展架构设计，详细介绍了预测性和反应性扩展策略，并讨论了扩展架构的技术，包括静态内容策略、应用服务器扩展的会话管理以及数据库扩展。我们还讨论了弹性的意义。

本章接着探讨了如何构建高可用性和高韧性的架构，强调了容错的必要性，并利用可替换资源来设计强健的系统架构。专门有一节讨论了性能，强调了如何在不同条件下构建性能最优的系统。

接下来讨论了松耦合的原则，强调了它在现代设计中的重要性，随后介绍了“服务而非服务器”的方法，这是无服务器计算范式的核心。本章还强调了数据驱动设计的重要性，通过数据来做出关于系统架构的明智决策，并探讨了架构中对强大安全性的需求。此外，还讨论了应用程序设计中可用性和可访问性的重要性。

构建面向未来的、可扩展的架构是接下来的议题，重点讨论了架构的互操作性和可移植性，以确保系统能够随着需求变化不断发展和适应。讨论了在系统架构的各个方面应用自动化，以提高效率并减少错误率。

强调了操作设计，特别是系统维护和更新的简便性。最后，本章讨论了克服架构限制的挑战，并提供了识别和缓解特定系统设计限制的策略。MVP 方法也被作为一种工具，快速验证架构选择。

在下一章中，你将深入探讨云迁移所必需的各种策略和方法，重点介绍企业如何将其基础设施、应用程序和数据迁移到云端。此外，本章还将涵盖设计和实施混合云架构的复杂性，混合云架构将本地基础设施与云服务结合，提供灵活且可扩展的解决方案。

留下评论！

喜欢这本书吗？通过在亚马逊上留下评论，帮助像你一样的读者。扫描下面的二维码，获取你选择的免费电子书。

第三章：3

云迁移与云架构设计

组织必须不断吸引新客户，满足他们的需求，同时在激烈的竞争环境中工作。如今，组织必须更具灵活性以应对日益增长的客户需求，这要求它们能够迅速扩展以应对数百万客户，并在需要时缩减规模而不影响预算。云迁移可能是实现灵活性和速度的解决方案。云端能够频繁发布应用程序，并通过应用自动化和数据中心整合来降低成本。

云计算已成为每个企业战略的核心。大多数组织通过迁移到公有云来减少开支，除了节省成本外，还将前期资本支出转变为运营支出。许多在过去十年中诞生的初创公司都起步于云端，并借助云基础设施实现快速增长。随着企业迁移到云端，它们必须关注云迁移策略和混合云。

公有云，如Amazon Web Services（AWS）、Microsoft Azure和Google Cloud Platform（GCP），正在成为托管应用程序的主要目标，因此了解迁移到云端的策略和方法至关重要。在本章中，你将了解云的各个方面，并培养“云思维”，这将帮助你更好地理解后续章节。

本章涵盖以下主题：

• 公有云、私有云和混合云

• 公有云中的解决方案架构

• 云原生架构

• 创建云迁移策略

• 选择云策略

• 云迁移步骤

• 云端应用优化

• 创建混合云架构

• 采用多云策略

• 实施 CloudOps

到本章结束时，你将了解到云的好处，并理解不同的云迁移策略和步骤。你还将学习到混合云设计、采用多云策略以及实施 CloudOps。

公有云、私有云和混合云

有三种不同类型的云模型：公有云、私有云和混合云。

公有云基于标准计算模型，在该模型中，服务提供商通过互联网向客户提供如虚拟机（VMs）、应用程序和存储等资源。在云计算模型中，公有云供应商提供按需可用的 IT 资源，如服务器、数据库、网络和存储，组织可以通过安全的基于 Web 的界面或通过互联网的应用程序来使用这些资源。公有云服务提供按需付费模式，在大多数情况下，客户只需为他们正在使用的服务付费，按使用时长计费，通过优化 IT 资源减少闲置时间，从而节省成本。

你可以将公共云视为一种电力供应模型，在这种模型中，你打开灯并仅为你使用的电量按单位付费。你从关掉灯的那一刻起就不再付费。它让你远离了使用涡轮机发电、维护设施资源以及建立庞大基础设施的复杂性，你以一种简化的方式使用整个服务。

除了成本优势外，主要的公共云提供商，如 AWS、GCP、Microsoft Azure、阿里云和 Oracle Cloud Platform (OCP)，通过云扩展他们的技术平台，帮助推动创新。这些公共云提供商已经掌握了可扩展性和面向未来的架构，提供全面的机器学习和分析功能。通过公共云，你可以访问这些前沿技术，并选择使用它们来推动你的架构发展。

私有云，或称本地云，是由单个组织注册、拥有并访问的。私有云作为公司现有数据中心的复制或扩展。相比之下，公共云有共享租户，这意味着来自多个客户的虚拟服务器共享同一物理服务器；然而，如果客户需要满足许可证或合规性需求，公共云也提供专用的物理服务器。

第三种模型是混合云，大企业使用它将工作负载从本地迁移到云，企业可能仍然有一些无法直接迁移到云的遗留应用，或者他们可能有需要保留在本地的许可应用——有时由于合规性原因，他们需要在本地保护数据。在这种情况下，混合模型能够帮助企业保持部分环境在本地，并将其他应用迁移到公共云。有时，组织将测试和开发环境迁移到公共云，并将生产环境保留在本地。混合模型的应用可能会根据组织的云战略有所不同。

由于市场上有多个公共云提供商，你可能会看到多云趋势，企业选择将工作负载分布在不同的公共云供应商之间，以最大化每个云技术的优势，或根据团队的技能集为他们提供选择。

让我们进一步了解公共云，以及它如何成为企业的关键技术平台。

公共云中的解决方案架构

云中的解决方案架构变得越来越重要，随着更多企业选择将工作负载迁移到云，这一趋势正在成为“新常态”。公共云已成为推动初创企业增长的关键因素，因为它们只需要较少的前期投资，而无需像本地解决方案那样进行大量前期投资。这使得企业能够像进行实验一样运作，并具备敏捷性和创新性。

云计算架构的好处在于，您可以全面查看所有架构组件，包括前端平台、应用开发平台、服务器、存储、数据库、自动化、交付以及管理整个解决方案景观所需的网络。

让我们更深入地了解公共云架构。

公共云架构

公共云的典型定义是通过互联网和私人网络访问的完全虚拟化环境。然而，公共云供应商最近开始提供本地物理基础设施，以实现更好的混合云采用。公共云提供多租户模型，其中 IT 基础设施（如存储和计算能力）在多个客户之间共享；但在软件和逻辑网络层面是隔离的，不会干扰彼此的工作负载。组织可以在公共云中创建网络级隔离，使其虚拟私有云等同于逻辑数据中心。鉴于组织的监管需求，公共云还提供专用的物理实例；然而，这也可以通过网络访问，但这是一个不太常见的选项。

公共云存储通过使用多个数据中心和强大的数据复制实现高耐用性和可用性的冗余模型。这使其实现了架构的弹性和轻松扩展性。

有三种主要的公共云计算模型，如图 3.1所示。为了比较，还显示了本地解决方案。

图 3.1：云计算模型类型

在图 3.1中，您可以比较本地环境中客户的责任与云计算服务模型。在本地环境中，客户必须管理一切，而在云计算模型中，客户可以将责任转移到供应商，并专注于其业务需求。以下是不同云计算模型下提供的服务的高级详细信息：

• 基础设施即服务（IaaS）：在这里，云供应商提供基础设施资源，如计算服务器、网络组件和数据存储空间，作为托管服务。它帮助客户使用 IT 资源，无需担心处理数据中心的诸多开销，如加热与冷却、机架堆叠、物理安全等。

• 平台即服务（PaaS）：PaaS 模型增加了一层服务，云供应商负责您开发平台所需的资源，如操作系统（OS）、软件维护和打补丁，以及基础设施资源。PaaS 模型通过为您处理平台维护的负担，帮助您的团队专注于编写业务逻辑和处理数据。

• 软件即服务（SaaS）：SaaS 模型在 PaaS 和 IaaS 模型之上增加了一层抽象，其中云或软件供应商提供现成的软件服务，你为此支付费用。例如，你使用的电子邮件服务如 Gmail、Yahoo Mail、AOL 等，提供了自己的电子邮件空间作为服务，你无需担心底层的应用或基础设施。

第四种新兴模型是函数即服务（FaaS）模型，这一模型在构建无服务器架构中越来越受到欢迎，通过使用包括 AWS Lambda 在内的服务。你将在第五章，云原生架构设计模式中学习到更多关于无服务器架构的细节。让我们快速回顾一下公共云服务提供商的概况。

主要的公共云服务提供商

全球云市场主要由四大云服务提供商主导。根据 Statista 2023 年的报告，AWS 以 32%的市场份额领先，提供包括计算、存储、网络、数据库、分析、机器学习和人工智能在内的广泛云服务。AWS 在本书中作为示例进行说明。

微软 Azure 紧随其后，市场份额为 24%，在企业应用和混合云计算方面表现出色。GCP（Google Cloud Platform）市场份额为 11%，并且增长迅速，尤其在机器学习和人工智能领域享有盛誉。阿里云以 4%的市场份额位列第四，在亚太地区表现突出。这四大提供商占据了全球云市场超过 70%的份额。其他重要参与者包括 Oracle、IBM Cloud、腾讯云和 Salesforce。你可以在此参考详细报告：www.statista.com/chart/18819/worldwide-market-share-of-leading-cloud-infrastructure-service-providers/。

由于公共云的功能和收费模式截然不同，我们来学习如何开发云原生架构设计方法。

云原生架构

随着云计算的普及，云原生（或基于云的）架构优化了系统架构，以适应云的能力。典型的本地架构通常是为固定基础设施构建的，因为添加新的 IT 资源（如服务器和计算能力）往往需要花费大量的时间、成本和精力。然而，云计算是按使用量收费的，并通过自动化提供便利，例如按需扩展或缩减服务器，而无需担心漫长的采购周期。云原生架构专注于实现按需扩展、分布式设计，并替换失败的组件，而不是修复它们。

在云原生架构中，你不断地创建自动化操作，以实现恢复、可扩展性、自我修复和高可用性，利用云的持续集成 (CI)、部署和基础设施自动化能力。这鼓励你在成本和性能方面不断优化应用程序，使用每天发布和改进的最新云能力。

公有云提供商允许全球基础设施覆盖世界各地，从而帮助应用程序在接近用户群体的地方进行全球扩展。为了鼓励采用，所有云服务都提供免费的基础服务，并附有大量学习资源，让你可以尝试并发展你的知识。

云原生方法帮助员工发展创新思维，并立即实施他们的想法，而不是等待长期的基础设施周期。

借助云计算，客户无需为应对高峰期（如零售商的假日购物季节）而规划过剩的容量；他们可以利用云的弹性，根据需求即时配置资源。这大大有助于降低成本，并改善客户体验。任何想要保持竞争力的组织，都必须快速创新。

云计算使企业能够快速在全球范围内部署基础设施，并访问以前无法使用的各种技术。这些技术包括以下前沿技术：

• 大数据和分析

• 机器学习和人工智能

• 物联网 (IoT)

• 区块链

• 生成式人工智能

构建云解决方案架构不同于常规的企业架构。在迁移到云的过程中，你必须培养云思维，并理解如何利用云的内建能力。对于云思维，你需要遵循按需付费模式，这意味着你需要确保正确优化工作负载，并且只在需要时运行服务器。

在云中，解决方案架构师必须全面考虑每个组件的性能、扩展性、高可用性、灾难恢复、容错性、安全性和自动化等方面。

其他优化领域包括云原生监控和警报机制。你可能不需要将现有的第三方监控工具从本地带到云端，因为你可以更好地利用原生云监控，避免昂贵的第三方许可软件。此外，你现在可以在几分钟内将部署能力扩展到世界任何地方。不要局限于某个特定区域；利用全球部署模型来构建更好的高可用性和灾难恢复机制。

云提供了出色的自动化方案；你可以自动化一切。自动化减少了错误，加快了市场推出的时间，并通过高效利用人力资源并将其从繁琐重复的任务中解放出来，节省了大量成本。

云采用共享责任模型，其中云服务提供商负责保护物理基础设施。然而，应用程序及其数据的安全性完全由客户负责。因此，重要的是要锁定您的环境，并通过使用云原生工具进行监控、警报和自动化来密切关注安全性。

设计云原生架构

每个组织可能对云原生架构有不同的看法，但从本质上来说，云原生就是以最好的方式利用所有云服务功能。真正的云原生架构是从应用程序的基础设计开始，让它从一开始就适合云平台构建。

云原生并不意味着将应用程序托管在云平台上；而是要利用云提供的服务和功能。这可能包括以下内容：

• 将单体架构容器化为微服务，并为自动化部署创建 CI/CD 流水线。

• 使用技术如 AWS Lambda FaaS 和 Amazon DynamoDB（云中的托管 NoSQL 数据库）构建无服务器应用程序。

• 创建无服务器数据湖，例如，使用 Amazon S3（托管对象存储服务）、AWS Glue（托管 Spark 集群用于 ETL）和 Amazon Athena（托管 Presto 集群用于临时查询）。

• 使用云原生监控和日志服务，例如，Amazon CloudWatch。

• 使用云原生审计服务，例如，AWS CloudTrail。

以下图示为一个云原生无服务器架构示例，用于微博客应用程序：

图 3.2：云原生微博客应用架构

上述图示展示了如何在 AWS 云中利用云原生无服务器服务。在这里，管理 DNS 服务的 Amazon Route 53 负责路由用户请求。Lambda 作为服务来处理用户验证、用户资料和博客页面的代码。所有博客资产存储在管理对象存储服务的 Amazon S3 中，所有用户资料数据存储在由 NoSQL 数据库管理的 Amazon DynamoDB 中。

当用户发送请求时，AWS Lambda 验证用户并查看其个人资料，确保他们在 Amazon DynamoDB 中有订阅；然后，它从 Amazon S3 中获取博客资产，如图片、视频和静态 HTML 写作，并将其展示给用户。由于所有服务都是云原生托管服务，并且您不需要处理任何基础设施，因此此架构可以以无限的方式进行扩展。

关键因素如高可用性、灾难恢复和可扩展性由这些云原生服务保障，这样你就可以专注于功能开发。在成本方面，只有当请求访问博客应用时，你才需要付费。如果晚上没有人浏览博客，你将不需要为托管代码支付任何费用，只需支付名义上的存储费用。

云原生架构的好处在于，它能够促进快速创新并提高团队的敏捷性。它简化了构建复杂应用和基础设施的过程。当你专注于设计和构建网络、服务器、文件存储和其他计算资源时，可以将物理实现交给你的云计算服务提供商。

其他云原生架构的优势包括：

• 按需快速扩展：你可以在需要时请求所需的资源。你只需为实际使用的部分付费。

• 快速复制：基础设施即代码意味着你可以一次构建并多次复制。你不再需要手动构建基础设施，而是可以将其结构化为一系列脚本或应用程序。通过程序化构建基础设施，你可以按需构建和重建它，满足开发或测试的需求。

• 轻松拆卸和重建：在云中，服务是按需提供的，因此建立一个大型实验系统非常简单。你的系统可能包括一个可扩展的 Web 和应用服务器集群、多个数据库、数 TB 的存储空间、工作流应用和监控。实验完成后，你可以将其拆除，从而节省成本。

在存储、网络和自动化领域，还有许多其他构建云原生架构的例子。你将在第五章，云原生架构设计模式中学到更多关于此架构的内容。

在本书中，你将学习到解决方案架构的云视角，并深入理解云架构。在下一节中，你将了解各种云迁移策略。

创建云迁移策略

你的云策略帮助你确定迁移策略并优先考虑应用程序。这些是促发云迁移和混合云策略倡议的一些原因：

• 数据中心需要技术更新

• 数据中心的租约即将到期

• 数据中心的存储和计算能力已耗尽

• 应用程序现代化

• 利用前沿技术，如生成性 AI、高级分析、机器学习、物联网等

• 需要优化 IT 资源以节省运营成本

• 灾难恢复规划和操作韧性

• 利用内容分发网络来优化网站

• 降低前期资本支出并消除维护成本

• 提高员工效率和生产力

• 提高业务敏捷性

每个组织都有不同的战略，在云迁移方面，没有“一刀切”的解决方案。常见的用例是将开发和测试环境放在云端，为开发人员提供更高的敏捷性，以便他们更快地行动。随着托管 Web 应用程序在云端变得更加经济和简便，组织正在通过将其网站和数字资产托管在云端，利用云进行数字化转型。

对于应用程序的可访问性，不仅需要为 Web 浏览器构建应用程序，还要确保其能够通过智能手机和平板电脑进行访问。云正在助力这种转型。数据处理和分析是企业利用云的另一个领域，因为在云中收集、存储、分析和共享数据更加便宜和高效。

云迁移不仅仅是选择平台、安全设计和运营；您还需要考虑人员、流程和文化，除了技术之外。为了确保云迁移的成功，您必须与领导对齐，并通过提升技能来获得团队的承诺。您需要在整个组织中定义愿景，以确保云转型的成功。

通常，迁移项目会采用多种策略，并根据不同的工具进行调整。迁移策略将影响迁移所需的时间，以及应用程序在迁移过程中如何进行分组。下图展示了将现有应用程序迁移到云端的一些常用策略：

图 3.3：云迁移策略

如上图所示，您可以将服务器或应用程序进行提升与迁移，将其从源环境转移到云端。迁移资源时，只需要进行最少的更改即可使其在云端正常工作。如果采取更加云原生的方法，您可以重构应用程序，以充分利用云原生功能，例如，将单体应用程序转换为微服务。

如果您的应用程序是无法迁移或不兼容云的遗留应用程序，您可能需要将其淘汰，并用云原生的 SaaS 产品或第三方解决方案替代。

一个组织可以采用多种迁移策略；例如，如果应用托管的操作系统已到达生命周期末期，您需要升级它。您可以借此机会迁移到云端以获得更好的灵活性。在这种情况下，您很可能会选择重新平台的方法，将代码重新编译成操作系统的新版本，并验证所有功能。测试完成后，您可以将应用程序迁移到云端提供的服务器操作系统。如果您想购买一个新的平台，例如，用 Salesforce 提供的基于 SaaS 的解决方案替代您的旧客户关系管理（CRM）系统，您可以选择退役并重新购买策略。如果您想将应用程序从单体架构重构为微服务以增加灵活性，您可以选择重构。

您的业务目标将推动您决定迁移应用程序，并根据优先级定义迁移策略。例如，当成本效益是主要驱动力时，迁移策略通常包括大规模迁移，并重点采用提升与迁移方法。然而，如果主要目标是实现灵活性和创新，云原生方法（如重构和重架构）在云迁移策略中发挥着至关重要的作用。让我们在接下来的小节中详细了解每种策略。

提升与迁移

提升与迁移是最快的迁移模式；它只需要很少的工作来移动您的应用程序。然而，这种模式需要利用云原生功能。让我们看看最常用的迁移策略（重托管、重新平台和迁移），这些策略通常用于提升与迁移。

重托管

重托管速度快、可预测、可重复且经济实惠，这使得它成为迁移到云端的首选方法。重托管是最快的云迁移策略之一，其中服务器或应用程序从源本地环境被提升并迁移到云端。迁移过程中对资源进行的修改很少。

客户常常使用重托管技术快速将应用迁移到云端，然后在资源在云中运行时专注于优化。这项技术使他们能够实现使用云计算的成本效益。

客户通常使用重托管技术来实现以下目的：

• 临时的开发和测试环境

• 当服务器运行打包软件时，如 SAP 和 Microsoft SharePoint

• 当应用程序没有活跃的路线图时

虽然重托管通常适用于打包软件，帮助您快速迁移到云端，但您可能需要升级底层应用平台，如操作系统。在这种情况下，您可以使用云迁移中的重新平台方法。

重新平台

当操作系统、服务器或数据库版本达到生命周期的尽头时，可能会触发云迁移项目，例如，将你的 Web 服务器操作系统升级到 Microsoft Windows 2022，或将数据库升级到 Oracle 23c 等。此策略涉及在云迁移项目中升级平台，而不改变应用程序架构。你可以决定将操作系统或应用程序更新到较新的版本，作为迁移的一部分。

当使用重新平台迁移策略时，你可能需要在目标环境中重新安装应用程序，这会触发应用程序的变更。重新平台后，需要对应用程序进行全面测试，以确保和验证其迁移后的运营效率。

以下常见原因需要使用重新平台技术：

• 将操作系统从 32 位更改为 64 位

• 更改数据库引擎

• 更新应用的最新版本

• 升级操作系统

• 升级数据库引擎

• 为了获得云供应商提供的托管服务的好处，如托管存储、数据库、应用部署和监控工具

重新平台有助于在迁移到云的同时推动应用程序的底层平台升级。如果你的应用程序部署在容器或 VMware 中，可以将其迁移到云。现在，让我们深入了解迁移策略。

迁移

你可能在本地数据中心使用容器或 VMware 设备部署应用程序。你可以使用加速迁移策略：迁移，将这些工作负载迁移到云。迁移可以帮助你在几天内移动数百个应用程序。你可以基于 VMware 和容器技术，轻松、快速地将应用程序迁移到云。

重新定位策略只需要少量的前期开发者投入或测试计划，因为它提供了你期待的云的敏捷性和自动化。你需要确定现有的配置，并使用 VMotion 或 Docker 将服务器迁移到云。你将在第六章，性能考虑中学习更多关于 Docker 的内容。

VMotion 以实时迁移而闻名。它是 VMware 的一项技术，可以将虚拟实例从一台物理主机服务器迁移到另一台，而不会中断服务。

在将应用程序迁移到云时，你可能希望借此机会重新构建和重新设计整个应用程序，使其更加云原生。云原生方法使你能够充分利用云的全部能力。让我们进一步了解云原生方法。

云原生方法

当你的团队决定迁移到云原生时，短期内看起来似乎需要更多的前期工作，并且向云的迁移速度较慢。这有点昂贵，但从长远来看，当你使用所有云的优势，并与敏捷团队一起进行创新时，它是值得的。

采用云原生方法后，你将看到成本随着时间的推移大幅下降，因为你可以根据适当的价格优化工作负载，同时保持性能不变，采用按需付费模式。云原生方法包括通过将应用程序架构转为微服务或选择纯粹的无服务器架构来进行容器化。

让我们更深入了解云原生迁移方法中的重构和重新购买策略。

重构

重构方法涉及在将应用程序迁移到云端之前重新架构和重写应用程序，使其成为云原生应用程序。在重构过程中，你将应用程序更改为更模块化的设计，例如从单体架构转为微服务架构。重构为微服务帮助组织创建小型独立团队，能够完全负责各自的服务，从而提高创新速度。

云原生应用程序是专门设计、架构和构建以便在云环境中高效运行的应用程序。这些云固有能力的好处包括可扩展性、安全性、敏捷性和成本效益。

重构需要在迁移之前花费更多的时间和资源来重新编码应用程序和架构。这种方法通常被拥有丰富云计算经验或高技能劳动力的组织采用。重构的另一种选择是将应用程序迁移到云端后再进行优化。你可以使用云原生的无服务器技术来减少模块化设计的管理开销。

重构的常见示例包括以下内容：

• 更换平台，例如从 AIX 转为 Unix

• 从传统数据库过渡到云数据库

• 替换中间件产品

• 将应用架构从单体架构转为微服务架构

• 重建应用架构，例如容器化或采用无服务器架构

• 重新编码应用组件

• 数据仓库现代化，以便将组织与客户连接起来

决定是否将应用程序重新架构为微服务，或重建以适应容器化或无服务器架构，需要仔细考虑组织的战略目标、成本影响和技术能力。将应用架构转为微服务能够提供更强的可扩展性和灵活性，使每个服务能够独立开发、部署和扩展，这对于长期的敏捷性和效率具有显著的好处。然而，这种方法可能涉及大量的重构，并且在服务协调和网络通信方面可能引入复杂性。另一方面，重建架构以采用容器化或无服务器模型可以简化操作、减少基础设施开销，并提高部署速度，尽管这需要在开发上的初期投资，并且团队可能面临学习曲线。

决策应考虑应用程序与新架构的兼容性、团队的专业技能，以及对性能和可靠性的潜在影响。虽然微服务可以改善故障隔离并促进更细粒度的资源管理，容器化和无服务器架构则可以优化资源使用，并有可能降低成本。安全性和合规性也是关键考虑因素，因为每种架构风格都会带来独特的挑战，必须主动应对。

有时会投入大量精力重建一个应用程序。作为架构师，你应评估购买 SaaS 产品是否能为你带来更好的投资回报（ROI）。让我们更详细地探讨一下重新购买策略。

重新购买

当你的 IT 资源和项目迁移到云时，可能需要一些服务器或应用程序，这要求你购买与云兼容的许可证或版本。例如，在云中运行应用程序时，可能需要验证当前本地部署的许可证。

解决此类许可问题有多种方式。你可以购买新的许可证并继续在云中使用你的应用程序，或者放弃现有许可证并用另一个云中的许可证替换它。此替换可能是相同应用程序的 SaaS 版本。

云可能并非所有问题的解决方案，有时你会发现一个遗留的应用程序可能无法从云迁移中获益，或者发现一些很少使用的应用程序可以退役。

工作负载优化

工作负载优化是云迁移和架构设计中的一项战略过程，专注于将相似的服务整合以简化操作并提高效率。该方法涉及评估并合并不同的系统，例如将多个 CRM 系统合并为一个统一的解决方案。其目标是消除冗余、降低复杂性，并优化整个组织 IT 环境中的资源利用。

在许多公司中，工作负载优化是一项关键任务，它指导决策者决定哪些应用程序应该保留、更新、退役或合并。这个过程不仅有助于简化技术架构，还能将 IT 资源与业务目标对齐，确保每项服务都是必要的、高效的，并有助于实现组织的整体目标。通过优化，公司可以实现更加灵活、成本效益高且可扩展的 IT 基础设施，这在云迁移和混合云架构中尤为重要，因为在这些环境中，效率和适应性至关重要。

接下来，让我们更详细地了解一下保留或退役策略。

保留或退役

在规划云迁移时，可能只需要迁移某些应用程序。由于技术限制，您可能需要保留一些应用程序；例如，可能有与本地服务器耦合的遗留应用程序无法迁移。另一方面，您可能会退休一些应用程序，并利用云原生的功能，例如第三方应用程序监控和告警系统。让我们了解更多关于保留或退休策略的信息。

保留

在您的本地环境中，您可能会遇到一些对业务至关重要，但由于技术原因（例如操作系统或应用程序在云平台上不受支持），不适合迁移的应用程序。在这种情况下，您的应用程序不能迁移到云端，但您仍然可以继续在本地环境中运行它。

对于这些服务器和应用程序，您可能只需要进行初步分析，以确定它们是否适合云迁移。然而，这些服务器或应用程序可能仍然与已迁移的应用程序存在依赖关系。因此，您可能需要保持这些本地服务器与云环境之间的连接。在本章的创建混合云架构部分，您将进一步了解本地与云的连接。

您可能希望保留复杂的遗留系统在本地，并优先处理它们，以便稍后迁移；然而，在发现阶段，组织经常会找到一些不再使用但仍然存在并占用基础设施空间的应用程序。您可以选择退休这些应用程序。让我们深入了解一下退休策略。

退休

在迁移到云端时，您可能会发现以下情况：

• 很少使用的应用程序

• 消耗过多服务器资源的应用程序

• 由于云不兼容可能不再需要的应用程序

在这种情况下，您可以退休现有的工作负载，并采取更适合云原生的全新方法。

退休策略可以应用于即将停用的主机和应用程序，也可以应用于不必要和冗余的托管应用程序。根据您的业务需求，这些应用程序可以在本地停用，而无需迁移到云端。通常适合退休的主机和应用程序包括以下内容：

• 用于灾难恢复的本地服务器和存储

• 服务器整合以解决冗余问题

• 由于并购产生的重复资源

• 典型高可用性设置中的替代主机

• 作为云内置功能提供的第三方授权工具（如工作负载监控和自动化）

大多数迁移项目都会采用多种策略，每种策略都有不同的工具可供选择。迁移策略将影响迁移所需的时间以及应用程序在迁移过程中如何分组。云迁移是检查你整体资源清单并清除未被记录的“幽灵服务器”的好时机。在这一部分，你学习了各种云迁移策略。接下来，我们来快速比较一下这些策略。

选择云迁移策略

选择适合自己业务需求的云迁移策略至关重要。需要考虑财务、资源、时间和技能等各种约束条件。你可以通过下表对比前一部分讨论的不同策略所需的努力。表格中的条形图展示了每种策略所需的时间与成本，以及优化机会的程度。

迁移策略	描述	时间与成本	优化机会
重构	重新设计应用程序，使其更模块化，变得云原生
重新平台化	将应用程序迁移到升级后的平台，但不改变核心架构
重新购买	通过购买云基础解决方案来替代当前环境
重新托管	快速将应用程序迁移到云端，而无需改变架构
保留	暂时将应用程序保留在本地		无
重新定位	快速将应用程序迁移到云端，无需进行任何更改		无
停用	识别不再有用的资源并彻底移除	无	无

表 3.1 – 云迁移策略对比

云迁移虽然提供了可扩展性、灵活性和成本效益等众多好处，但也伴随有一定的风险。组织必须意识到这些潜在的陷阱，以便有效地进行规避。可能的风险包括：

• 数据丢失与泄露：在迁移过程中，如果没有正确的加密和管理，敏感数据可能面临泄露风险。在迁移过程中确保数据完整性和安全性对于防止数据泄露至关重要。

• 停机时间：迁移可能会导致系统停机，影响业务运营。通过分阶段规划和执行迁移，或在非高峰时段进行迁移，可以最小化对业务连续性的影响。

• 成本超支：如果没有适当的规划和对云定价模型的理解，组织可能会面临意外的费用。因此，制定明确的迁移路线图和预算至关重要。

• 性能问题：由于架构差异或不可预见的兼容性问题，应用程序在云中的初始表现可能不如预期。迁移后需要进行严格的测试和优化。

• 技能差距：组织内缺乏云计算专业知识可能会妨碍迁移过程和未来的运营。投资培训并可能聘请专家可以降低这一风险。

• 互操作性和集成挑战：确保现有系统和应用程序与云服务无缝协作可能非常复杂，需采用强大的集成和测试策略。

• 合规性：遵守行业法规和合规标准在云环境中可能是一个挑战，尤其是当组织处于高度监管的行业时。

• 供应商锁定：过度依赖单一云服务商的技术和服务可能导致将来更换供应商时的困难，可能影响灵活性和成本效益。

为了减少与云迁移相关的风险，通常建议在将应用程序迁移到云时采取分阶段的方法。首先，优先考虑业务功能，并优化应用程序以实现成本节省、性能提升和资源生产力的差异。尽量先进行迁移；然后，在后续阶段，你可以进行优化。例如，如果你正在迁移一个使用 MS SQL 数据库的应用程序，并用云原生数据库（如 Amazon Aurora 或 Azure SQL）替换它，最佳做法是先迁移应用程序，在第二阶段迁移数据库，同时监控风险和应用程序的稳定性。你可以在后续步骤中使用云原生无服务器技术栈（如 AWS Lambda、Amazon API Gateway 和 Amazon DynamoDB）来优化你的应用程序。

迁移策略应定义为便于快速执行，允许团队独立工作。云迁移策略可能影响其他组织因素，例如在组织内部构建工程职能，而不是外包。迁移到云还为组织内采用或增强 DevOps 文化提供了一个绝佳机会。这种文化强调开发和运维团队之间的协作，简化工作流程，提高效率。

组织通常会发现，通过应用程序发现来准备迁移的过程中，优化工作负载和加强安全性是意外的好处。

云迁移涉及多个阶段。在下一部分，你将学习云迁移的步骤。

云迁移步骤

在上一节中，您了解了不同的迁移策略，并且可能已经开始将应用程序分组，以应用合适的迁移技术。这些策略也被称为 7Rs（保持、退休、重新定位、重新托管、重新购买、重新平台化和重构），这些策略中的某些或所有都可能是您云迁移旅程的一部分。

由于您可能需要迁移和管理多个应用程序到云中，因此建议设置一个云卓越中心（CoE），并通过云迁移工厂对这一过程进行标准化。云卓越中心包括来自组织各个 IT 和业务团队的经验丰富的人员，他们作为专门的云团队，致力于加速组织内部云技术的建设。云迁移工厂定义迁移流程和工具，以及需要采取的步骤，如下图所示：

图 3.4：云迁移步骤

如前面的图示所示，云迁移步骤如下：

• 发现：发现云迁移投资组合和本地工作负载

• 分析：分析发现的数据和工作负载

• 规划：规划迁移到云端并定义迁移策略

• 设计：根据迁移策略设计应用程序

• 迁移：执行迁移策略

• 集成：与其他应用程序和系统依赖项集成

• 验证：在迁移后验证功能

• 运营：规划在云中运营

• 优化：为云优化您的工作负载

云迁移项目的初始步骤之一是评估并优先考虑要迁移的应用程序。为此，您需要获取完整的 IT 资产清单，以确定哪些服务器、应用程序和业务单元适合迁移到云中，优先考虑迁移计划，并为这些应用程序确定迁移策略。让我们深入了解每个步骤并学习更多内容。

发现您的投资组合和工作负载

在迁移项目的发现阶段，您会发现并捕捉有关您的云迁移投资组合的详细数据，例如迁移项目的范围。您将识别投资组合中的服务器和应用程序，以及它们之间的相互依赖关系和当前的基准性能指标。此外，工作负载发现还包括理解以下组件：

• 存储：识别存储的数据量和类型，例如数据库和文件。例如，发现某个应用程序是否使用 1 TB 的块存储进行数据库操作。

• 网络配置：理解网络拓扑，包括子网、防火墙和负载均衡器。例如，识别某个应用程序是否分布在多个子网中，并具有特定的防火墙规则。

• 安全性和合规性需求：记录安全政策、数据保护机制和合规要求，例如识别应用程序必须遵守 GDPR，并对静态数据进行加密。

• 应用发布频率：了解新版本发布的频率，例如确定应用程序是否遵循每两周发布一次的发布计划。

• DevOps 模型：了解集成和部署流程、使用的工具以及自动化程度。例如，注意到组织使用 Jenkins 进行 CI/CD，并且高度自动化了管道。

• 升级路径：记录处理事件和故障的流程，例如识别关键联系人和服务中断时的处理程序。

• 操作系统维护和补丁：了解操作系统更新的应用方式和时间，例如服务器是否每月自动打补丁，或是手动更新。

• 许可要求：识别需要维护或更新的任何软件许可证，例如检查应用程序是否使用了需要在云中进行核算的授权中间件。

• 其他相关资产：记录与工作负载相关的额外组件，如外部依赖、第三方服务或集成工具。例如，识别应用程序对外部支付网关服务的依赖。

除了帮助您设计和架构目标云环境并识别成本外，详细的发现过程还可以帮助识别当前应用程序中可能需要在迁移到云之前进行缓解的任何问题。

组合发现：识别所有参与云迁移项目的 IT 资产，包括服务器和应用程序、它们的依赖关系以及性能指标。

您还需要收集有关资源的业务细节，如资源的当前状态、应用程序的更新周期、应用程序的路线图以及服务器或应用程序的业务重要性。这些细节将帮助您确定迁移策略并制定迁移计划。在大多数组织中，这些细节由多个业务单元和团队维护。因此，在发现过程中，您可能需要与多个团队进行互动，如业务、开发、数据中心、网络和财务等。

需要理解的是，您的发现范围将取决于多种因素：

• 已经迁移到云的内容是什么？

• 存在什么应用程序依赖关系，以及相应的资源和资产？

• 云迁移的业务驱动因素是什么？

• 整个迁移项目的预计持续时间是多少？

• 迁移过程将分为几个阶段？

迁移项目的主要挑战之一是确定应用程序之间的相互依赖性，特别是当它们涉及到输入/输出（I/O）操作和通信时。随着组织因并购和扩展而不断增长，云迁移变得更加具有挑战性。组织往往无法获得以下完整信息：

• 服务器数量的清单

• 服务器规格，如操作系统类型和版本、内存、CPU 和磁盘

• 服务器利用率和性能指标

• 服务器依赖关系

• 总体网络详细信息

进行彻底的投资组合发现有助于回答如下问题：

• 哪些应用程序、业务单元和数据中心是迁移的理想候选者？

• 应用程序迁移到云端的适宜性如何？

• 迁移应用程序到云端可能面临的已知或未知风险是什么？

• 应该如何对应用程序进行迁移优先级排序？

• 应用程序依赖于哪些其他 IT 资产？

• 应用程序的最佳迁移策略是什么？

• 对于应用程序来说，是否更好有一些停机时间，而不是因其依赖关系和风险进行实时迁移？

市面上有多个工具可以帮助自动化发现过程，并提供更多不同格式的详细信息。这些工具可以根据各种特性进行分类，如部署类型、操作、支持以及发现和报告的数据类型。大多数现有的解决方案可以大致分为两类：

• 基于代理的解决方案，要求在服务器上安装其软件客户端以收集必要的详细信息。例如，在环境中的所有服务器上安装监控代理，以跟踪性能指标、软件清单和系统日志。

• 无代理解决方案，可能能够在不进行任何额外安装的情况下捕获这些信息。一个例子是使用基于网络的扫描工具，远程检查服务器的开放端口、运行的服务和漏洞，通过与现有的网络协议和管理接口进行交互来实现。

一些解决方案执行端口扫描，探测服务器或主机的开放端口。与此不同的是，另一些解决方案执行数据包扫描，通常涉及捕获并分析网络数据包以解码信息。这些工具也会根据发现数据的粒度、存储类型和报告选项有所不同。例如，一些工具可以提供更高层次的智能，超越网络层次，还能确定正在运行的应用程序类型。

发现过程的复杂性取决于组织的工作负载以及是否已经有良好维护的库存。发现过程通常会运行至少几周，以便收集有关环境的更全面的信息。一旦你发现了所有必要的信息，就需要对其进行分析。让我们更详细地看看分析步骤。

信息分析

信息分析对云迁移至关重要，因为它提供了对当前 IT 环境的详细了解，从而支持做出明智的决策。这项分析有助于确定哪些应用程序和工作负载适合迁移，评估它们与云环境的兼容性，并确定最优的云服务和架构。它还揭示了应用程序与基础设施之间的依赖关系，确保平稳过渡而不干扰业务操作。此外，深入的分析有助于预测和缓解潜在风险，优化资源分配，并预测成本，从而确保一次成本效益高且成功的云迁移。

要识别服务器和应用程序的依赖关系，你需要分析主机上的网络连接数据、端口连接、系统和进程信息。根据你的工具，你可以可视化服务器的所有联系，以识别其依赖关系，或者你可以运行查询，列出所有运行特定进程、使用特定端口或与特定主机通信的服务器。

要对服务器和应用程序进行迁移调度分组，你需要识别主机配置中的模式。通常，某些前缀会嵌入到服务器主机名中，以标识它们与特定工作负载、业务单元、应用程序或需求的关联。有些环境还会使用标签和其他元数据将这些细节与主机相关联。

要为目标环境调整资源大小，你可以分析服务器和应用程序的性能指标：

• 如果服务器被过度配置，你可以修改你的正确尺寸映射信息。你还可以通过利用服务器/应用程序的使用数据，而不是服务器规格来优化这个过程。

• 如果服务器被配置不足，你可能需要为该服务器分配更高的优先级，以便将其迁移到云端。

你可以结合你获得的洞察力与资源的可用性和业务需求，优先安排你的云迁移工作负载。这可以帮助你确定每个云迁移冲刺中包括的服务器数量。

基于对云迁移组合的发现和分析，您可以为您的应用程序确定合适的云迁移策略。例如，复杂性较低并且运行在受支持操作系统上的服务器和应用程序可能是提升和迁移策略的合适候选者。运行在不受支持操作系统上的服务器或应用程序可能需要进一步分析，以确定合适的策略。

迁移项目的下一个阶段是规划云迁移。在这一阶段，您将利用在组合发现阶段和分析阶段收集的信息来创建一个高效的迁移计划。让我们更详细地了解迁移规划。

创建迁移计划

在云迁移项目中，发现、分析和规划是紧密集成的。您需要全面发现云迁移组合，并分析数据以创建迁移计划。在分析阶段结束时，基于您的分析和从业务负责人那里收集的详细信息，您应该能够对每个服务器/应用程序执行以下操作，这些服务器/应用程序是您云迁移组合的一部分：

• 根据您组织的云采纳战略选择迁移策略。您可能会在保留、退休、重新定位、重新购买、重新托管、重新平台化和重构策略中受到特定选择的限制。

• 为迁移资源到云端分配优先级。最终，所有属于云迁移组合的资源都可能迁移到云端，但这个优先级将决定迁移的紧急性。优先级较高的资源可能会在迁移计划中更早地迁移。

• 记录迁移资源到云端的业务驱动因素，这将推动迁移资源到云端的需求和优先级。

规划利用在发现和分析阶段收集的信息来创建迁移波次。波次是资源的逻辑分组，可以在云迁移过程中按顺序部署到生产环境和测试/开发环境中。

在迁移项目的这一阶段结束时，您应该能够创建一个有序的应用程序待迁移列表，这些应用程序可以迁移到云端。

除了选择迁移策略外，迁移规划阶段的主要目标还包括以下内容：

• 定义迁移的成功标准

• 确定云中资源的合适大小

• 确定迁移到云端的应用程序的优先级

• 确定迁移模式

• 创建详细的迁移计划、检查清单和时间表

• 创建迁移冲刺团队

• 确定迁移工具

冲刺和待办事项是敏捷和 Scrum 持续交付方法论的一部分。

在迁移规划阶段的准备过程中，你需要对所有属于云迁移组合的 IT 资产进行详细发现和分析。迁移规划包括确定云账户结构并为你的应用创建网络结构。同时，理解与目标云环境的混合连接性也至关重要。混合连接性将帮助你为那些仍在本地运行的资源依赖应用进行规划。

应用迁移的顺序可以通过三个高层步骤来确定：

1. 从多个业务和技术维度评估每个应用程序，准确量化迁移环境的潜力。

2. 识别每个应用程序的依赖关系，分为紧耦合、松耦合等，确定任何依赖性排序的需求。

3. 确定组织的优先级策略，以确定各个维度的适当相对权重。

如果组织策略是最小化风险，那么业务重要性将在识别应用时占有更大的权重。如果策略是迁移的简易性，那么能够使用重新托管方法迁移的应用将具有更高的优先级，因为重新托管比其他策略更为直接。规划的结果应是一个有序的应用列表，用于安排云迁移的时间表。

设计应用程序

在设计阶段，你的重点应该放在成功迁移应用程序，并确保你的应用设计符合规划阶段确定的成功标准。你还应确保应用程序在迁移到云后保持最新。例如，如果你在本地应用服务器中维护用户会话（以便进行水平扩展），那么在迁移后，确保在云端实现类似的架构，这样可以定义成功标准。

在设计阶段，你将识别架构差距，并根据应用需求增强架构。当你有多个账户时，每个账户可能具有某种程度的关系或依赖；例如，你可以有一个安全账户，以确保所有资源符合公司范围内的安全指南。

在思考应用程序的网络设计时，你需要考虑以下几点：

• 进入应用边界的网络数据包流

• 外部和内部流量路由

• 网络保护的防火墙规则

• 应用程序与互联网及其他内部应用的隔离

• 整体网络合规性和治理

• 网络日志和流量审计

• 根据应用程序与数据和用户的暴露程度，划分应用风险等级

• DDoS 攻击保护与防御

• 生产环境和非生产环境的网络要求

• 基于 SaaS 的多租户应用访问要求

• 组织内业务单元级别的网络边界

• 在业务单元之间共享服务模型的计费和实施

根据您的连接需求，您可以考虑与本地系统的混合连接选项。

为了在云中构建和维护一个安全、可靠、高效并且成本优化的架构，您需要应用最佳实践。在迁移到云之前，回顾您的云基础架构，确保符合云最佳实践。

在迁移到云时，您可以设计应用架构，利用全球云基础设施，增加与最终用户的接近度，降低风险，提高安全性，并解决数据驻留限制。预计会随着时间增长的系统应当构建在可扩展架构之上，这种架构能够在不影响性能的情况下支持用户、流量或数据的增长。

对于需要维护一些用户状态信息的应用程序，可以使特定架构组件无状态。如果架构中的某些层需要保持状态，可以利用会话亲和性等技术来扩展这些组件。对于处理大量数据的应用程序，可以采用分布式处理方式。

另一种减少运行应用程序操作复杂度的方法是使用无服务器架构。这种架构可以降低成本，因为您既不会为未充分利用的服务器付费，也无需提供冗余的基础设施来实现高可用性。在第五章，云原生架构设计模式中，您将学习更多关于无服务器架构的内容。

以下图示展示了一个从本地环境到 AWS 云的迁移设计示例。本地设计如下：

图 3.5：本地架构映射

所描绘的架构概述了一个高可用性设置，适用于跨多个层级的 Web 应用程序，每个层级在处理用户请求中扮演特定角色。用户通过互联网访问该应用程序，负载均衡器将他们的请求均匀地分配到一组 Web 服务器。这些服务器提供前端内容，并且可能还会执行一些初步的请求处理。

随后，更深层的业务逻辑由一个单独的应用服务器层处理，该层可能会与数据库进行交互以进行数据检索和存储。为了确保数据的完整性和连续性，维护一个备用数据库，准备在主数据库出现问题时接管。

这种多层次的方式，在 Web 层和应用层都有冗余设计，并且数据库还具备故障切换策略，旨在提供对服务器故障的鲁棒性，并在高流量情况下提供最佳性能。

现在我们转向 AWS 云设计：

图 3.6：本地到 AWS 云架构映射

在前面的图示中，作为云迁移策略的一部分，决定重新托管 Web 服务器并引入自动伸缩以提供弹性，从而帮助应对需求激增。还添加了弹性负载均衡器，将传入的流量分配到 Web 服务器实例。应用程序服务器通过重构方法进行迁移，数据库层的平台从传统数据库更改为云原生的Amazon Relational Database Service（Amazon RDS）。整个架构分布在多个可用区，并且数据库会复制到第二个可用区的备用实例，以提供高可用性。

作为设计阶段的输出，你应该创建一份关于你在云端应用架构的详细设计文档。设计文档应包括以下细节：

• 用户账户迁移：迁移过程中将转移的用户账户

• 网络配置：新环境中应用程序所需的网络设置

• 访问控制列表：需要访问迁移数据的用户、组和应用程序的全面列表

• 托管详情：迁移后应用程序将如何和在哪里托管

• 备份需求：特定于应用程序的备份策略和要求

• 许可需求：与应用程序相关的任何许可要求

• 监控协议：将实施的监控系统和协议

• 安全措施：应用程序必须遵守的安全措施和合规标准

• 维护和修补：定期维护和修补的程序和时间表

确保为每个应用程序创建设计文档。在迁移验证阶段，你必须执行基本的云和应用程序功能检查。

执行应用程序迁移到云端

迁移执行步骤将把你的计划付诸实践。在执行阶段，你必须定义步骤和配置，因为在开发/测试和生产阶段你将重复这些步骤。在执行迁移之前，确保你已经制定了迁移计划，并且已经确定了冲刺团队、迁移波次和时间表，创建了优先级排序的待办事项清单，并通知了所有应用程序利益相关者有关迁移时间表、时间线以及他们的角色和责任。

您还必须确保云端的目标环境已经设置好基础架构和核心服务。您可能需要一些特定于应用程序的预备步骤，例如在迁移之前执行备份或同步、关闭服务器，或从服务器卸载磁盘和设备。确保将必要的组件放置到位，例如网络和防火墙规则、身份验证和授权以及账户。所有这些都需要适当配置。您需要在基础设施上测试应用程序，确保它们能够访问所需的服务器、负载均衡器、数据库、认证服务器等。您必须关注应用程序的日志记录和监控，以衡量迁移后的性能。

在迁移过程中确保与云环境有良好的网络连接。正确估计需要迁移的数据量也有助于您适当估计将数据迁移到云端所需的时间，考虑到带宽和网络连接等其他因素。您还需要了解可用于执行迁移的工具。考虑到市场上可用设备的数量，您可能需要根据您的要求和其他限制缩小选择标准。

正如您所知，重新托管通常是将应用程序迁移到云端的最快方式。当应用程序在云中运行时，您可以进一步优化以利用其所有的优势。通过应用提升和转移方法将应用程序迁移到云中，您可能会更早地实现成本和敏捷性的优势。

根据迁移策略的不同，通常可以迁移整个服务器，包括应用程序及其运行所需的基础设施，或者只迁移属于应用程序的数据。让我们看看如何迁移数据和服务器。

数据迁移

云数据迁移指将现有数据移动到新的云存储位置。大多数应用程序在向云端发展过程中都需要数据存储。存储迁移通常与以下两种方法之一对齐，但组织也可能同时执行两种方法：

• 首先，单一的提升和转移移动。在云端启动新应用程序之前可能需要进行此操作。

• 第二，一个以云为主的混合模型，结果是新架构的云原生项目与一些传统的本地数据。随着时间推移，传统数据存储可能会向云端转移。

然而，您对数据迁移的方法将会有所不同。这取决于诸如数据量、网络和带宽限制、数据分类层级（例如备份数据、关键数据、数据仓库或存档数据）、数据安全级别以及您可以分配给迁移过程的时间量等因素。

假设您有大量的数据归档或数据湖，且带宽和数据量不现实的情况下，您应将数据从当前位置直接迁移到云服务提供商的数据中心。您可以通过使用专用的网络连接来加速数据传输，或者通过物理方式将数据从硬盘转移。

如果您的数据存储可以逐步迁移，或当新数据从多个非云源聚合时，考虑采用提供友好界面的迁移方法，这些方法可以连接到云存储服务。这些迁移服务可以利用或补充现有的安装，如备份和恢复软件或存储区域网络（SAN）。

对于小规模的数据库，一步迁移是最佳选择，这要求根据工作负载的复杂性，关闭应用程序几个小时到几天。在停机期间，所有来自数据库的信息都会被提取并迁移到云端的目标数据库。一旦数据库迁移完成，必须与源数据库进行验证，确保没有数据丢失。之后，可以完成最终切换。

相反地，如果系统要求最小的停机时间，那么对于任何规模的数据库，更常用的做法是采用两步迁移过程：

1. 信息从源数据库中提取。

2. 数据在数据库运行时迁移。您可以配置更改数据捕捉（CDC）来确保所有数据都被迁移，并且在迁移期间应用程序可以正常运行。

在整个过程中没有停机时间。完成迁移任务后，您可以根据需要对连接外部应用程序或其他任何标准进行功能和性能测试。

在此期间，由于源数据库仍在运行，必须在最终切换之前将更改数据传播或复制到目标数据库。此时，您需要安排数据库的停机时间，通常为几个小时，并同步源数据库与目标数据库。所有更改数据传输到目标数据库后，应执行数据验证，以确保迁移成功并将应用流量切换到新的云数据库。

您可能有一些关键任务数据库，不能承受任何停机时间。进行零停机迁移需要详细的规划以及适当的数据复制工具。您需要使用连续数据复制工具来应对这种情况，如 AWS DataSync、Oracle GoldenGate 或 NetApp SnapMirror。需要注意的是，在同步复制的情况下，源数据库的延迟可能会受到影响，因为它需要等待数据在各处复制完成后，才能响应应用程序请求，同时复制操作仍在进行中。

如果你的数据库停机时间只有几分钟，可以使用异步复制。通过零停机迁移，你可以更灵活地选择切换时间，因为源数据库和目标数据库始终保持同步。

服务器迁移

有几种方法可以将服务器迁移到云端：

• 主机或操作系统克隆技术涉及在源系统上安装代理，用于克隆系统的操作系统镜像。在源系统上创建快照并将其发送到目标系统。这种类型的克隆用于一次性迁移。

• 通过操作系统复制方法，所有操作系统文件都会从源机器复制并托管在云实例上。为了使操作系统复制方法有效，执行迁移的人员和/或工具必须理解底层操作系统环境。

• 灾难恢复复制技术在源系统上部署代理，将数据复制到目标系统。然而，数据是以文件系统或块级别复制的。一些解决方案会持续地将数据复制到目标卷，提供持续的数据复制解决方案。

• 使用磁盘复制方法，整个磁盘卷会被复制。一旦磁盘卷被捕获，它可以作为卷加载到云中，然后可以附加到云实例上。

• 对于虚拟机（VM），你可以使用无代理技术将虚拟机导出/导入到云中。通过虚拟机复制方法，本地虚拟机镜像会被复制。如果本地服务器以虚拟机形式运行，如 VMware 或 OpenStack，那么你可以复制虚拟机镜像并将其作为机器镜像导入云中。这种技术的主要好处是可以拥有可重复启动的服务器备份镜像。

• 用户数据复制方法仅复制应用程序的用户数据。一旦数据从原始服务器导出，你可以选择三种迁移策略之一——重新购买、重新平台化或重构。用户数据复制方法仅适用于了解应用程序内部的人。然而，因为它只提取用户数据，所以用户数据复制方法是一种与操作系统无关的技术。

• 你可以将应用程序容器化，然后在云中重新部署它。容器化方法复制了应用程序二进制文件和用户数据。一旦应用程序二进制文件和用户数据被复制，它就可以在托管在云中的容器运行时上运行。由于底层平台不同，这就是平台迁移策略的一个例子。

市面上有多种迁移工具可以帮助你将数据和/或服务器迁移到云端。每个主要的公有云提供商都有自己的迁移工具；不过，你也可以使用其他流行的云迁移工具，如CloudEndure、NetApp、Dynatrace、Carbonite、OpenText等。一些工具采用灾难恢复策略进行迁移，还有一些灾难恢复工具也支持连续复制，以便进行实时迁移。有些工具专门用于提升和迁移你的服务器、跨平台执行数据库迁移或数据库模式转换。该工具必须支持你熟悉的业务流程，并且有相应的操作人员来进行管理。

集成、验证与切换

迁移、集成和验证是并行进行的，因为你希望在将应用程序集成到云端时能够持续进行验证。

验证

团队首先会执行必要的云功能检查，以确保应用程序在适当的网络配置下运行（在所需的地理位置），并具有一定的流量流动。当基本的云功能检查完成后，实例可以根据需要启动或停止。建议验证服务器配置（如 RAM、CPU 和硬盘）是否与预期一致。

执行这些检查需要一定的应用程序及其功能知识。当主要检查完成后，你可以对应用程序进行集成测试。

集成

集成测试包括检查与外部依赖项和应用程序的集成，例如确保应用程序能够连接到 Active Directory、CRM 服务、补丁或配置管理服务器以及共享服务。例如，你的应用程序可能需要与 Active Directory 服务器、配置管理服务器或共享服务资源进行通信，而这些都属于应用程序外部的内容。你的应用程序也可能需要与客户或供应商的外部应用程序集成，例如在采购订单下达后，供应商通过 API 接收来自你的数据流。

当集成过程完成后，你需要通过进行单元测试、冒烟测试和用户验收测试（UATs）来验证集成的有效性。这些测试的结果将帮助你获得应用程序和业务所有者的批准。

集成和验证阶段的最后一步包括来自应用程序和业务所有者的签字流程，这将允许你将应用程序从本地环境迁移到云端。

切换过程

云迁移的下一个阶段是切换过程。在此阶段，你将采取必要步骤，将应用流量从源本地环境重新定向到目标云环境。根据数据或服务器迁移的类型（一阶段、二阶段或零停机迁移），你的切换步骤可能会有所不同。确定切换策略时需要考虑的一些因素包括：

• 应用程序的可接受停机时间

• 数据更新频率

• 数据访问模式，如只读或静态数据

• 应用程序特定的要求，如数据库同步、备份和 DNS 名称解析

• 业务约束，例如切换可以发生的日期或时间以及数据的关键性

• 更改管理指南和批准

实时迁移在业务关键型工作负载迁移中最为流行。让我们深入了解一下它。

实时迁移切换

在此方法中，数据持续复制到目标地，并且你在应用程序仍在运行时进行大多数功能验证和集成测试。下图展示了一个适用于实时零停机迁移的切换策略。

图 3.7：使用蓝绿部署的实时迁移切换

上述图示描述了一种混合云架构，用于蓝绿部署策略中的实时迁移切换。

蓝绿部署的理念是，蓝色环境是你现有的生产环境，承载着实时流量。同时，你可以配置一个绿色环境，它除了新版本的代码外，与蓝色环境完全相同。你将在第十一章，DevOps 与解决方案架构框架中进一步了解蓝绿部署。

以下是该方法在图示中的工作原理：

1. 当前设置（蓝色环境）：位于欧洲（爱尔兰）的本地数据中心，包括 Web 服务器、应用服务器和数据库。它处理一定比例的用户流量（20%，如所示）。

2. 目标设置（绿色环境）：位于美国东部（北弗吉尼亚）区域的 AWS 云环境是准备接管整个流量的新环境。该环境包括一个用于 Web 服务器群集的 Amazon EC2 实例群集和另一个用于应用服务器群集的群集。Amazon RDS 被用于数据库。

3. 流量路由和分配：Amazon Route 53，一项 DNS 服务，用于在本地和 AWS 云环境之间路由用户流量。最初，它被配置为将大部分流量（80%）发送到 AWS 云环境，而剩余的流量仍然指向本地数据中心。

4. 数据复制：数据复制持续进行，从本地数据库复制到 AWS 云中的 Amazon RDS，以确保数据一致性和云环境中的最新信息。

5. 实时迁移切换：在蓝绿部署的切换阶段，AWS 中的新（绿色）环境已完全投入使用，并处理大部分流量。

6. 在经过彻底测试并确认新环境稳定、按预期运行后，Route 53 将逐步将 100% 的流量从内部（蓝色）环境切换到 AWS 云（绿色）环境。

7. 在此阶段，内部环境处于待命状态。如果 AWS 云设置中出现任何关键问题，流量可以重新路由回内部服务器以确保服务连续性。

8. 完成：一旦切换成功完成，AWS 云环境开始处理所有流量，企业内部基础设施可以按需停用或重新利用。

这种方法通过在停用旧环境之前，使用实时流量完全测试新环境，从而最大限度地减少停机时间和风险。如果在切换过程中出现问题，还提供了一个简单的回滚策略。

最初，应用程序在内部和云中都在运行，流量在两者之间分配。你可以逐步增加流量到云应用程序，直到所有流量都导向新应用程序，从而实现无停机的切换。

其他常用的切换策略涉及一些停机时间。你可以为应用程序安排停机时间，暂停流量，停用应用程序，然后通过应用 CDC 过程进行最终同步。

在最终同步后，在目标端进行快速冒烟测试检查所有关键功能是否按预期工作是一个不错的选择。此时，你可以将流量从源端重新导向到在云中运行的应用程序，从而完成切换。

数据在迁移过程中至关重要，因为当应用程序上线时数据会不断变化。你可以使用数据迁移工具，如 AWS 数据库迁移服务（DMS）和 Oracle GoldenGate，来执行一次性 CDC 数据迁移。

操作云应用程序

迁移过程的操作阶段帮助你按照与业务相关方达成的水平，在云中允许、运行、使用和操作应用程序。

大多数组织通常已经为其内部环境定义了指导方针。此操作卓越流程将帮助你识别需要调整的流程变更和培训，以便支持云采纳目标。

以下是你在云中需要处理的 IT 操作：

• 服务器修补

• 服务和应用日志记录

• 云监控

• 事件管理

• 云安全操作

• 配置管理

• 云资产管理

• 变更管理

• 具有灾难恢复和高可用性的业务连续性

IT 组织通常遵循信息技术基础架构库（ITIL）和信息技术服务管理（ITSM）等标准来执行这些操作。ITSM 组织和描述了规划、创建、管理和支持 IT 服务的活动和流程，而 ITIL 则应用最佳实践来实施 ITSM。你需要现代化你的 ITSM 实践，以充分利用云提供的敏捷性、安全性和成本效益。

迁移到云后，工作并未结束；要充分利用云的全部潜力，必须进行持续的优化。让我们深入了解一下。

云中的应用优化

优化是云计算中运营的一个重要方面，这是一个持续改进的过程。在本节中，你将学习各种优化领域。本书中有专门的章节讨论每个优化考虑因素。以下是主要的优化领域：

• 性能：优化性能，确保系统架构能够为一组资源（如实例、存储、数据库和空间/时间）提供高效的性能。你将在第六章，性能考虑中了解更多关于架构性能的内容。

• 安全性：持续审查和改善组织的安全政策和流程，以保护云中的数据和资产。你将在第七章，安全性考虑中了解更多关于架构安全的内容。

• 可靠性：为可靠性优化应用，以实现高可用性和为应用定义的停机阈值，这将有助于从故障中恢复、应对需求增长并减少长期的中断。你将在第八章，架构可靠性考虑中了解更多关于架构可靠性的内容。

• 运营卓越：优化运营效率和运行及监控系统的能力，以提供业务价值，并不断改进支持过程和程序。第九章，运营卓越考虑将教你更多关于架构运营的内容。

• 成本：优化应用或一组应用的成本效益，同时考虑波动的资源需求。你将在第十章，成本考虑中了解更多关于架构成本的内容。

作为对一些主要元素的快速概述，你需要了解当前在云环境中部署的内容以及每个资源的价格，以优化成本。你可以通过使用详细的账单报告和启用账单警报，主动监控云中的成本。

你需要维护和扩展基础设施，并且通过卸载更多工作负载来减少成本。优化成本的另一种方法是设计具有弹性的架构。确保为资源选择合适的规模，使用自动扩展，并根据价格和需求调整使用率。例如，让应用程序使用更多小型实例而不是较少的大型实例，可能会更具成本效益。

一些应用架构修改可以帮助提高应用程序的性能。提高 Web 服务器性能的一种方法是通过缓存卸载网页。你可以编写一个应用程序，允许缓存图像、JavaScript，甚至整个页面，从而为用户提供更好的体验。

你可以设计多层次和面向服务的架构，使每一层和模块可以独立扩展，这有助于优化性能。第四章，解决方案架构设计模式，将教你更多关于这种架构模式的内容。

客户可能希望在云迁移过程中保留本地工作负载，原因可能是分阶段的迁移方式或由于应用程序复杂性或许可问题而无法迁移到云中。在这种情况下，你必须构建一个混合云架构，使本地工作负载能够与云工作负载无缝交互和交换信息。接下来，我们将更详细地了解如何创建混合云架构。

创建混合云架构

云的价值正在增长，许多大型企业正在将其工作负载迁移到云中。然而，通常情况下，不能在第一天就完全迁移到云中，对于大多数客户来说，这是一段旅程。这些客户寻求混合云模型，在本地环境中保留部分应用程序，并使其能够与云模块进行通信。

在混合部署中，你必须建立本地和云环境中运行的资源之间的连接。最常见的混合部署方法是在云与现有本地基础设施之间进行，以便将组织的基础设施扩展到云中，同时将云资源连接到内部系统。设置混合云的常见原因可能包括以下几点：

• 你希望在本地环境中运行遗留应用程序，同时在云中通过蓝绿部署模型进行重构和部署。

• 诸如大型机的遗留应用程序可能没有兼容的云选项，因此必须继续在本地运行。你需要时间来重构技术堆栈。

• 由于合规要求，你需要将部分应用程序保留在本地。

• 为了加速迁移，你希望将数据库保留在本地，并将应用服务器迁移到云中。

• 你希望对部分应用程序进行更精细的控制。

• 你希望从本地将数据摄取到云中进行分析。

公有云供应商提供了一种机制，用于在客户现有的基础设施和云之间进行集成，以便客户可以轻松地将云作为当前基础设施投资的无缝扩展。这些混合架构功能使客户能够进行一切操作，从集成网络、安全性和访问控制，到支持自动化工作负载迁移，并通过其本地基础设施管理工具控制云。

如下图所示，通过 AWS Direct Connect，您可以在数据中心与 AWS 云之间建立高速连接，实现低延迟的混合部署：

图 3.8：混合云架构（本地到云连接）

在图中，VPC 指的是亚马逊虚拟私有云（Amazon Virtual Private Cloud）。VLAN 是虚拟局域网，VGM 是虚拟专用网关，WAN 是广域网。

如前图所示，AWS Direct Connect 位置建立了本地数据中心与 AWS 云之间的连接。这帮助您实现客户对专用光纤线路连接到 AWS Direct Connect 位置的需求；客户可以从第三方供应商（如 AT&T、Verizon、T-Mobile 或美国的 Comcast）选择这条光纤线路。AWS 在全球每个地区都有 Direct Connect 合作伙伴。

在 AWS Direct Connect 位置，客户的光纤线路连接到 AWS 专用网络，这为数据中心到 AWS 云提供了专用的端到端连接。这些光纤线路可以提供高达 10 GB/s 的速度。为了通过直接连接保护流量，可以设置 VPN 并应用 IPSec 加密流量。

为了有效平衡混合云模型的风险与收益，需要进行全面评估。

混合云模型的好处包括：

• 灵活性与控制：混合云提供了利用公有云可扩展性的能力，同时将关键工作负载保留在本地，以便更好地控制和性能。

• 可扩展性：企业可以按需扩展其 IT 资源，确保能够处理高峰负载，而无需在物理基础设施上进行大量资本投资。

• 增强的韧性：通过在多个环境中分布资源，混合云策略可以提高整体系统的韧性和业务连续性。

• 创新与实验：混合云模型使组织能够测试新的云技术和服务，而不会干扰仍然在本地部署的核心业务应用程序。

但是，也存在一些风险，包括：

• 复杂性：混合云环境本身复杂，需要先进的编排和网络能力，以便在多个平台之间无缝管理工作负载。

• 安全问题：由于公共云和私有云的互联互通，潜在攻击面增大，这需要严格的安全措施和持续的警惕。

• 合规性挑战：当数据和应用分布在不同的云环境中时，遵守监管标准变得更加困难。

• 成本管理：如果没有仔细规划和监控，混合云的运营成本可能会由于资源未充分利用或影子 IT 问题而迅速超出预算预期。

实施混合云策略的决策应权衡这些风险与潜在收益，并与组织的具体需求、能力和战略目标相一致。

随着市场上来自知名供应商的云产品不断增多，组织可能会选择采取多云策略。接下来，让我们了解一下多云策略。

采用多云策略

在云计算存在之前，组织使用多个供应商以获取最优的服务，并避免供应商锁定。随着越来越多的公共云供应商进入市场，组织开始寻求采用多云策略。多云策略利用两个或更多的公共云提供商来满足组织的基础设施和技术需求。多云策略可以是像 AWS、GCP、Microsoft Azure、Oracle Cloud、IBM 等主要公共云供应商的组合。组织可以根据地理位置、技术能力和成本在云之间分配工作负载。它们还可以将多云策略与本地部署结合使用。

采用多云策略的主要优势如下：

• 供应商灵活性：通过多云，你可以在多个供应商之间进行选择，保持谈判的主动权、灵活性和敏捷性。如果出现服务级别协议（SLA）未达标的情况，你可以切换到更好的云服务提供商。

• 灾难恢复：另一个优势是在同一区域规划灾难恢复，当某个云提供商发生故障时，可以依赖其他提供商。每个云提供商都有其优势，你可以根据需要在云端挑选最好的服务。

尽管多云方法为组织提供了竞争优势，但它也带来了一些挑战：

• 最突出的一大挑战是技能要求。你需要具备了解多个云的人员来制定工作负载托管策略，此外，你还需要组建团队深入研究每个云技术栈。可以考虑聘请顾问或将云管理外包给具有全球人力资源池的系统集成商。

• 另一个主要挑战是协调跨多个云的数据信息可用性、安全性和性能。尽管每个云服务商都提供内置安全性、跨区域应用和云原生工具来提高性能，但这方面的管理责任由组织承担。你需要在云中实施一致的数据管理，将数据从一个云平台转移到另一个，并确保性能的一致性。

如你所见，多云策略具有一定的优势和劣势，选择此类策略时需要考虑这些因素。

一旦你开始了云计算之旅，就可以构建云原生应用程序。让我们深入了解如何构建云原生架构。

实施 CloudOps

云操作模型，即 CloudOps，是组织为管理成本、提升效率并减轻云基础设施、安全性和操作风险而建立、监控和调整的一系列规则和指南。这一操作模型为将人员、流程和技术与云相关任务（包括安全性、预算管理和跨云工作负载合规性）对齐提供了指导原则。

CloudOps 模型提供了几个关键的好处：

• 解锁速度和敏捷性：组织可以利用云服务固有的敏捷性和快速响应能力，加速云的采用和应用现代化努力，成为数字化转型的一部分。

• 利用自动化提升效率：自动化通过简化日常任务减少人为错误和干预，释放宝贵的资源和时间。

• 大规模一致性治理：云治理在不同的环境中保持一致，确保组织内的标准化和合规性。

• 有效利用熟练人才：CloudOps 使熟练的人员能够专注于交付业务成果，而非重复的手动任务。

• 避免超支：通过利用自动化和治理，组织可以避免意外的成本超支，并优化云开支。

有效的管理和治理对于转型到云端的企业至关重要，能够保持云 IT 操作中的最佳实践。云管理和治理服务提供了更快的创新，并在成本、合规性和安全性方面提供强有力的控制。

云自动化在帮助组织开发高效的云操作模型中扮演着关键角色，通过自动化云资源的创建、修改和删除。按需云服务的概念承诺灵活性，但实际上，许多组织仍依赖手动流程来配置、测试、识别需求以及退役云资源。这些手动工作流可能导致劳动密集型任务、潜在错误和成本增加。

云自动化可能需要初期的投入，但随着复杂任务可以通过少数几次点击迅速完成，优势逐渐显现。除了显而易见的减少人工工作的好处，云自动化还带来了其他优势，包括：

• 提高安全性和恢复力：自动化有助于通过减少人为错误来增强安全性，并确保正确实施安全措施，例如为新添加的开发环境设置安全凭证。此外，自动化还可以在容量相关问题发生时自动恢复，确保恢复力并避免停机。

• 简化的备份过程：自动化备份确保在灾难恢复事件中保持业务连续性和客户信任，最大限度地减少业务损失。自动化备份消除了对个人启动备份的依赖，降低了数据丢失的风险。

• 增强治理：自动化确保对各个环境中的活动进行全面监控，通过有效跟踪服务器、数据库和访问控制来提供更好的治理。

云服务提供商提供一系列服务和第三方工具，以支持现代企业实施 CloudOps 模型，促进创新、提高应用性能，并更快地响应客户反馈，同时保持治理和合规性。

CloudOps 模型包括几个支柱，涵盖了 IT 工作负载自动化的各个方面。接下来我们来看看这些内容。

CloudOps 支柱

在规划你的 CloudOps 战略过程中，采用全面的 360 度视角至关重要。目标是以业务敏捷性和治理控制为重点，来配置和管理你的云环境。无论你的云迁移旅程如何，建立一个强大的 CloudOps 模型，使你能够在不同的基础设施环境中实现一致的治理和简化的操作。这种战略方法使你能够优化关键资源，进而加速业务成果的交付，缩短市场时间，并改善安全性、效率和成本控制。

下图展示了 CloudOps 模型的关键支柱，涵盖了完整的 IT 工作负载自动化。

图 3.9：CloudOps 支柱

以下是 CloudOps 的基本支柱，如图所示：

1. 建立治理：创建一个强大、架构良好且具有多账户的云环境，并设置护栏，作为治理的基础。遵循 Well-Architected Framework 检查清单，确保安全性、操作卓越性、成本优化、可靠性和性能的全面监控和告警机制。

2. 确保合规性：持续监控云资源的合规性和配置，使用自动化方法及时修复故障，并收集审计证据，以确保遵守行业法规和内部政策。

3. 提供与编排：使用基础设施即代码（IaC）原则加速应用程序和资源的提供，同时在整个云环境中保持一致性和合规性。

4. 监控与观察：有效地衡量和管理你的应用程序和云资源，迅速识别并解决问题，以确保最佳性能和可靠性。

5. 集中化操作：简化并自动化整个应用程序组合的操作，确保无缝执行，同时保持安全性、保密性和合规性标准。

6. 管理成本：通过实施成本透明、控制措施、预测能力和优化策略来转变业务运营，优化云支出。

你可以通过参考我们的另一本书《AWS for Solutions Architects》：迁移到、构建、扩展并在云中成功的 AWS 解决方案架构权威指南（第二版）详细了解每个支柱。

总结

在本章中，你探讨了公有云中解决方案架构的基本方面。你还了解了云原生架构和混合架构，全面理解了云计算及其优势。

我们从公有云、私有云和混合云的比较开始，帮助你掌握不同的云部署模型及其各自的应用场景。

我们随后通过其架构更详细地定义了公有云的概念，并介绍了一些流行的公有云提供商。

此外，你深入了解了云原生架构，获得了采用云原生架构的优势的见解，例如增强的可扩展性、灵活性和成本效益。

通过扎实的公有云基础知识，我们讨论了创建云迁移战略。详细探讨了不同的迁移方法，包括提升与迁移、重新托管、重新平台化、迁移、重构、重新购买、保留和退役。你探讨了如何根据业务需求选择最合适的云迁移战略的指导。

随后的章节概述了云迁移的关键步骤，从工作负载发现和分析开始。你学习了如何创建全面的迁移计划并设计应用程序，以实现无缝迁移到云。此外，我们还介绍了应用程序迁移的关键方面，包括数据迁移、服务器迁移、集成、验证和切换，并向你介绍了云中应用程序优化技术，以确保最佳性能和成本效益。

由于组织通常处理复杂的基础设施，你学习了如何创建混合云架构，并采用多云策略，充分利用多个云提供商的优势。

本章以设计云原生架构为重点，强调 CloudOps 的原则，帮助你将云工作负载操作化。

在下一章中，你将深入了解各种架构设计模式和参考架构，例如多层架构、面向服务架构、无服务器架构和微服务架构。

进一步阅读

要了解更多关于主要公共云提供商的信息，请参考以下链接：

• 亚马逊网络服务 (aws.amazon.com):

  • AWS 解决方案架构师，作者：Saurabh Shrivastava, Neelanjali Srivastav, Alberto Artasanchez 和 Imtiaz Sayed: www.amazon.com/gp/product/180323895X

  • AWS 高架构框架: aws.amazon.com/architecture/well-architected/

• 谷歌云平台 (cloud.google.com):

  • GCP 云架构框架: cloud.google.com/architecture/framework

• 微软 Azure (azure.microsoft.com):

  • Azure 高架构设计: azure.microsoft.com/en-us/solutions/cloud-enablement/well-architected#reliability

• 甲骨文云基础设施 (OCI): www.oracle.com/cloud/

• 阿里云: us.alibabacloud.com

• IBM Cloud: www.ibm.com/cloud

几乎每个云提供商都提供给新用户学习的机会，这意味着你可以使用邮箱注册并在选择合适的服务前先尝试它们的产品。

加入我们书籍的 Discord 社区

加入书籍的 Discord 工作区，提问并与作者和其他解决方案架构师互动: packt.link/SAHandbook

第四章：4

解决方案架构设计模式

你是否曾想过大型企业是如何设计可扩展的系统的？在开始应用开发之前，解决方案架构师需要跨组织工作，权衡多个选项，制定架构设计以应对业务需求。

设计解决方案有多种方式。解决方案架构师需要根据用户需求以及成本、性能、可扩展性和可用性等架构约束来选择合适的方法。在本章中，你将了解各种解决方案架构模式、参考架构，以及如何将它们应用于实际场景。

在前几章中，你学习了解决方案架构设计的原则。本章既激动人心又至关重要，因为你可以将所学应用于各种架构设计模式。在本章中，你将了解一些重要的解决方案架构模式，如分层架构、事件驱动架构、微服务架构、松耦合架构、面向服务架构和 RESTful 架构。

你将了解各种架构设计的优势，并查看示例，演示何时使用它们。你还将了解架构设计中的反模式以及以下架构设计模式：

• 构建 n 层架构

• 创建基于多租户的 SaaS 架构

• 理解面向服务的架构

• RESTful Web 服务架构

• 构建基于缓存的架构

• 模型-视图-控制器（MVC）架构

• 构建领域驱动设计（DDD）

• 理解断路器模式

• 实现舱壁模式

• 创建浮动 IP 模式

• 使用容器部署应用程序

• 应用架构中的数据库处理

• 清洁架构

• 避免解决方案架构中的反模式

到本章结束时，你将了解如何优化你的解决方案架构设计并应用最佳实践，使得本章成为你学习的中心和核心。

构建 n 层架构

在n层架构（也称为多层架构）中，你需要应用松耦合设计原则，并具备可扩展性和弹性属性。在 n 层架构中，你将产品功能划分为多个层次，例如展示层、业务层、数据库层和服务层，使得每个层次可以独立实现和扩展。

使用 n 层架构，采用新技术并提高开发效率变得容易。这种分层架构提供了灵活性，可以在每一层中添加新功能，而不影响其他层的功能。在安全性方面，您可以确保每一层都安全且彼此隔离，这样如果一层被攻破，其他层不会受到影响。应用程序故障排除和管理也变得更加可控，因为您可以快速定位问题所在，并明确需要进行故障排除的应用程序部分。

最常见的多层设计架构是三层架构，所以让我们进一步了解它。以下图示展示了一个 AWS 示例架构，允许您通过浏览器与 web 应用程序进行交互，并执行所需功能，例如订购您喜欢的 T 恤或阅读博客并留言：

图 4.1：三层网站架构

在上述架构中，您有以下三层：

• 网络层：网络层是应用程序的面向用户部分。最终用户通过网络层与应用程序互动，以收集或提供信息。

• 应用层：应用层主要包含业务逻辑，并根据从网络层接收到的信息进行处理。

• 数据库层：所有类型的用户数据和应用数据都存储在数据库层中。

让我们更详细地看一下这些层次。

网络层

网络层也被称为表现层。网络层提供用户界面，帮助最终用户与应用程序进行交互。网络层是你的用户界面（在这个例子中是网站页面），用户在此输入信息或浏览内容。网页开发者可能使用 HTML、CSS、Angular、React、JavaServer Pages（JSP）和Active Server Pages（ASP）等技术来构建表现层用户界面。这个层次从用户处收集信息，并将其传递给应用层。

网络层是面向用户的，因此组织会花费大部分时间来提升用户体验。许多组织有专门的用户体验（UX）团队，研究各个领域，以了解用户如何与应用程序互动。

此外，解决方案架构师必须确保架构设计包括用户体验（UX）的输入和页面加载性能。网络层和应用层之间应该有无缝的信息流，以便在预期的时间内将正确的信息返回给用户，例如用户登录、个人资料加载等。

让我们来看一下应用层。

应用层

应用层也被称为逻辑层，因为这是产品的核心，所有业务逻辑都驻留在此。展示层从用户处收集信息并将其传递给逻辑层进行处理，以获取结果。例如，在像 Amazon 这样的电子商务网站上，用户可以在网站的订单页面输入日期范围，以查找其订单摘要。作为回报，web 层将数据范围信息传递给应用层。应用层处理用户输入以执行业务逻辑，如订单数量、金额总和和购买的商品数量。然后，这些信息返回给 web 层并呈现给用户。

一般来说，在三层架构中，所有算法和复杂的逻辑都位于应用层，包括创建推荐引擎或根据用户的浏览历史向用户展示个性化页面。你可以添加诸如领域层、数据访问层或展示层等层次，以构建四层或五层架构。开发人员可以选择在服务器端编程语言中实现这一层，例如 C++、Java、.NET 或 Node.js。应用层是系统设计的核心，通常需要最多的设计工作。大多数应用功能都依赖于在应用层构建的逻辑。应用层对存储在数据库层的数据进行逻辑处理。让我们更详细地了解数据库层。

数据库层

数据库层，也称为数据层，存储与用户档案和交易相关的所有信息。本质上，它包含需要持久化存储在数据层中的任何数据。这些信息被发送回应用层进行逻辑处理，然后最终在 web 层呈现给用户。例如，假设用户使用 ID 和密码登录网站。在这种情况下，应用层会验证存储在数据库中的用户凭证。如果凭证与存储的信息匹配，用户将被允许登录并访问网站的授权区域。

架构师可以选择在关系型数据库中构建数据层，例如 PostgreSQL、MariaDB、Oracle Database、MySQL、Microsoft SQL Server、Amazon Aurora 或 Amazon RDS。架构师也可以添加 NoSQL 数据库，如 Amazon DynamoDB、MongoDB 或 Apache Cassandra。

数据层用于存储交易信息、用户会话信息和应用程序配置。架构师可能会考虑添加缓存数据库，如 Memcached 和 Redis，以满足性能需求。你将在第十二章，解决方案架构的数据工程中了解更多关于各种数据库的知识。

在安全方面，数据层需要特别注意。您必须通过在静止状态和传输过程中应用数据加密来保护用户信息。在n-层分层架构图中，您会注意到每一层都有自己的自动扩展配置，这意味着可以独立扩展每一层。此外，每一层都有网络边界，这意味着访问一层并不能访问其他层。您将在第七章，安全考虑中了解更多关于安全方面的内容。

架构师需要根据应用程序的复杂性和用户需求决定层数。例如，您可以添加额外的层，如用于数据库访问逻辑的数据访问层，并保持数据存储层作为数据库引擎。您可以通过定义逻辑分离来增加应用程序的整体可维护性、扩展性和性能。

创建基于多租户 SaaS 的架构

在前一节中，您了解了多层架构，也称为单租户，适用于单个组织构建。随着组织欢迎数字革命，多租户架构变得越来越流行，同时保持整体应用程序和运营成本较低。

软件即服务（SaaS）模型建立在多租户架构之上，其中软件实例和相关基础设施为众多客户提供服务。在这个框架内，每个客户都以共享方式使用应用程序和数据库。通过每个租户独特的配置、身份和数据隔离，他们彼此相互隔离，同时共享同一产品。

作为多租户 SaaS 提供商，它们负责从硬件到软件的一切，基于 SaaS 的产品将组织的责任转移到应用程序的维护和更新上，因为 SaaS 提供商负责处理这些事务。

每个购买 SaaS 产品的组织都被视为租户。这些租户可以使用配置而无需进行代码更改来自定义其用户界面。由于多个客户共享公共基础设施，它们可以从规模中受益，进一步降低成本。一些最受欢迎的 SaaS 提供商包括 Salesforce CRM、Jira Software、Slack、Google Workspace 和 Amazon Connect。

如下所示的架构图表明，两个组织（租户）使用相同的软件和基础设施。SaaS 供应商通过为每个组织分配唯一的租户 ID，提供对应用层的访问：

图 4.2：多租户 SaaS 架构

前述架构设计显示，表现层提供用户界面，应用层保存业务逻辑。在数据访问层，每个租户将通过以下一种方法实现数据级隔离：

• 数据库级隔离：在这种模型中，每个租户都有与其租户 ID 关联的数据库。当每个租户从用户界面查询数据时，将其重定向到其数据库。如果客户出于合规性和安全性原因不希望使用单一共享数据库，则需要此模型。

• 表级隔离：可以通过为每个租户提供单独的表来实现此隔离级别。在此模型中，需要为每个租户唯一分配表，例如使用租户 ID 前缀。当每个租户从用户界面查询数据时，根据其唯一标识符将其重定向到其表中。

• 行级隔离：在这种隔离级别中，所有租户在数据库中共享同一张表。表中有一个额外的列，存储每行针对的唯一租户 ID。当单个租户希望从用户界面访问其数据时，应用程序的数据访问层根据租户 ID 向共享表生成查询。每个租户仅获取属于其用户的行。

对企业客户而言，应进行仔细评估，以了解 SaaS 解决方案是否适合基于其独特功能需求。这是因为，通常情况下，SaaS 模型的定制能力有限。

隔离方法的选择基于组织的合规性、安全性、成本以及租户合同要求等考虑因素。

如果需要许多用户订阅，找到成本价值主张非常重要。在进行“构建还是购买”决策时，成本比较应基于总体拥有成本来计算。这是因为构建软件并不是大多数组织的主营业务，因此 SaaS 模型因其使组织能够专注于业务并让专家处理其 IT 方面而变得非常流行。

面向服务的架构 (SOA) 是设计和构建应用程序的流行方法，特别是当组织有独特的定制需求时。让我们更多地了解它。

理解面向服务的架构

在SOA模式中，不同的应用程序组件通过网络上的通信协议进行交互。每个服务提供端到端的功能，例如获取订单历史记录。SOA 被大型系统广泛采用，以集成业务流程，例如从主应用程序中取出您的支付服务并将其作为单独的解决方案。

从一般意义上讲，SOA 将单体应用程序拆分为一些独立运行的 服务。使用 SOA 的目标是松耦合应用程序的服务。有时，SOA 包括将服务彼此拆分并将资源拆分为该服务的独立实例。例如，虽然有些人选择将公司数据存储在一个通过表格拆分的单一数据库中，但 SOA 会考虑按功能模块化应用程序，将其拆分成完全独立的数据库。这使得你可以根据每个数据库中表格的个别需求进行扩展和管理吞吐量。

SOA 具有多个优点，例如开发、部署和运营的并行化。它解耦了服务，使你能够单独优化和扩展每个服务。

然而，它也需要更强有力的治理来确保每个服务团队所执行的工作符合相同的标准。在 SOA 中，解决方案可能会变得足够复杂，从而增加开销，因此你需要选择工具并实施自动化来进行服务监控、部署和扩展。

实现 SOA 的方式有多种。

简单对象访问协议 (SOAP) 最初是最流行的消息传递协议，但由于完全依赖 XML 进行数据交换，它的重量较重。表现层状态转移 (REST) 架构越来越受欢迎，因为开发人员需要构建更轻量的移动和 Web 应用程序。在撰写本文时，SOAP 架构已被视为遗留架构，因此在本书的这一版本中，我们将重点学习 REST 架构。

RESTful Web 服务架构

REST 或 RESTful Web 服务因其轻量级架构而提供更好的性能。与仅允许 XML 的 SOAP 不同，REST 允许多种消息格式，如 JSON、纯文本、HTML 和 XML。REST 是一种架构风格，定义了使用 HTTP 协议进行数据传输的松耦合应用程序设计标准。

JavaScript 对象表示法 (JSON) 是 REST 架构中更易于访问的数据交换格式。JSON 也是轻量级的，且与语言无关。它包含一个简单的键值对，使其与大多数编程语言中定义的数据结构兼容。

RESTful Web 服务，也称为 REST Web 服务，建立了一个具有特定规则的框架，用于设计 Web 服务。其目的是确保通过互联网连接的各种计算机系统之间的兼容性。通过 RESTful Web 服务，系统可以使用一致的、预定义的一组操作访问和修改基于文本的数据，而不依赖于过去的交互或状态。以下是 RESTful Web 服务架构的一些基本原则，以及使用电子商务网站示例来说明 RESTful Web 服务架构的原则：

• 无状态: 客户端到服务器的每个请求必须包含服务器理解和处理所需的所有信息。客户端发出的每个请求都包含完成该请求所需的所有必要信息，并且无需在服务器端维护任何会话相关的信息；相反，所有信息完全由客户端管理。以一个电子商务网站为例，客户端的每个请求，比如查看产品或将其添加到购物车，都必须包含处理该请求所需的所有信息。如果用户想查看他们的购物车，请求必须包含用户的 ID 或其他相关细节，以便服务器能够识别并返回相应的购物车详情。

• 客户端-服务器架构: 在这种设计中，客户端和服务器是两个独立的部分，它们通过网络进行通信。客户端负责管理用户界面并与用户互动，而服务器负责后端和数据处理。它们可以独立演化而不互相影响。客户端（浏览器或应用程序）管理用户交互，比如选择产品，而服务器处理数据检索、购物车管理和结账处理。它们通过 HTTP 请求和响应进行交互。

• 统一接口: REST 使用统一接口，简化和解耦架构。对于 RESTful API，交互通过一组标准的 HTTP 方法来促进，这些方法对应 CRUD（创建、读取、更新、删除）操作。这些方法包括：

  • GET: 这种方法用于从服务器检索数据。例如，当用户想要查看 example.com 上的产品列表时，他们的浏览器会向服务器发送一个 GET 请求。URL 可能看起来像 https://example.com/api/products，服务器会以结构化格式（如 JSON 或 XML）返回产品列表。

  • POST: 这种方法用于在服务器上创建新的资源。假设用户想在 example.com 上将一个新产品添加到购物车中。他们可能会填写一个包含产品详情的表单，并点击 添加到购物车。这个操作会触发一个 POST 请求，发送到 https://example.com/api/cart，并将产品详情包含在请求体中。然后，服务器处理这些数据并将新产品添加到用户的购物车中。

  • PUT：此方法用于更新服务器上已存在的资源。如果用户想要更新购物车中某个商品的数量，则会向像https://example.com/api/cart/{productId}这样的特定 URL 发送 PUT 请求。请求体中会包括更新后的数量，服务器将会更新用户购物车中对应的商品。

  • DELETE：此方法用于从服务器移除某个资源。例如，如果用户决定从购物车中删除某个商品，浏览器会向像https://example.com/api/cart/{productId}这样的 URL 发送 DELETE 请求。服务器随后会从购物车中移除指定的商品。

  通过遵循这些标准方法，API 为开发者提供了一种与 Web 服务交互的一致方式，使开发者能够对资源执行基本操作，而无需了解底层实现细节。

• 基于资源：在 REST 中，所有事物都被视为资源，每个资源都可以通过特定的 URL 进行访问。资源是 REST 中的关键抽象，资源可以表示一个单独的对象或多个对象的集合。像商品、用户、订单和购物车商品等资源都通过 URL 进行标识。例如，特定商品可以通过www.amazon.com/products/{product_id}进行访问。

• 资源的表示：资源可以有不同的表示形式，如 JSON、XML、HTML 等。客户端通过获取资源的表示并操作这些表示来与资源交互。当客户端持有资源的表示时，它拥有足够的信息来修改服务器上的资源。相同的商品资源可能在网页浏览器和移动应用中以不同的方式呈现。

• 分层系统：这种架构允许引入中间层（如负载均衡器或缓存层），而不影响客户端与服务器的交互方式。每一层可以提供特定的功能集，从而提高系统的可扩展性和可维护性。一个电子商务网站可能会有多个层次，如负载均衡层、缓存层或认证层。客户端不需要了解这些层次。请求查看商品时，可能会经过缓存层以提高响应速度，但客户端对此并不知情。

• 按需代码：服务器可以向客户端提供可执行代码，供客户端在其上下文中执行。这允许部分应用逻辑转移到客户端。例如，一个电子商务网站可以向客户端的浏览器发送 JavaScript 代码，以执行客户端验证或增强用户浏览体验中的交互性。

RESTful 架构风格使用标准的 HTTP 方法，并通过遵循这些原则，RESTful Web 服务旨在简单、可扩展和可维护。许多现代 Web API 遵循 RESTful 原则开发，使用标准约定对资源执行 CRUD 操作。让我们了解基于 RESTful 架构的参考架构。

构建基于 RESTful 架构的电子商务网站

例如 www.amazon.com 的电子商务网站具有全球用户和庞大的数百万产品目录。每个产品都有多个图像、评论和视频。为全球用户群维护如此庞大的目录是一项非常具有挑战性的任务。

此 AWS 中的参考架构遵循 RESTful 原则。服务尽可能独立运行：

图 4.3：电子商务网站的 RESTful 架构

如前述架构图所示，我们可以注意到以下内容：

• 当用户在浏览器中输入网站地址时，用户请求会到达 DNS 服务器以加载网站。Amazon Route 53 将网站的 DNS 请求路由到托管 Web 应用程序的服务器。

• 用户群体是全球的，用户继续浏览要购买的产品，因为该网站具有庞大的产品目录，包括静态图像和视频。像 Amazon CloudFront 这样的内容分发网络缓存和向用户传递静态资产。

• 存储在 Amazon S3 中的目录内容，如静态产品图像和视频，以及其他应用程序数据，如日志文件。

• 用户将从多个设备浏览网站；例如，他们将从移动设备向购物车添加商品，然后在桌面上进行付款。需要持久的会话存储，如 DynamoDB，来处理用户会话。DynamoDB 是一个 NoSQL 数据库，无需提供固定的模式，因此它是产品目录和属性的优秀存储选项。

• Amazon ElastiCache 用作产品的缓存层，以减少对数据库的读写操作，提供高性能并减少延迟。

• 便捷的搜索功能对产品销售和业务成功至关重要。Amazon CloudSearch 通过从 DynamoDB 加载产品目录来帮助构建可扩展的搜索能力。您还可以使用 Amazon Kendra 实现 AI 驱动的搜索引擎。

• 推荐可以鼓励用户基于浏览历史和过往购买行为购买其他产品。独立的推荐服务可以消耗存储在 Amazon S3 上的日志数据，并向用户提供潜在的产品推荐。

• 电子商务应用程序还可以具有多个层和组件，需要频繁部署。AWS Elastic Beanstalk 处理基础设施的自动配置，部署应用程序，通过应用自动扩展来处理负载，并监视应用程序。

你在本节中了解了 RESTful 架构。接下来让我们深入了解基于缓存的架构设计中的关键方面。

构建基于缓存的架构

缓存涉及将数据或文件临时存储在请求者与永久存储之间的中间位置。这种做法旨在加速未来的请求并最小化网络带宽的使用。缓存提高了应用程序的速度并降低了成本。它允许你重复使用先前检索的数据。为了提高应用程序性能，缓存可以应用于架构的各个层次，如 Web 层、应用层、数据层和网络层。

通常，服务器的 随机存取内存 (RAM) 和内存缓存引擎被用来支持应用程序缓存。然而，如果缓存与本地服务器耦合，那么在服务器崩溃时缓存将不会持久化数据。大多数应用程序都运行在分布式环境中，因此最好拥有一个独立于应用生命周期的专用缓存层。如果你对应用程序进行水平扩展，那么所有服务器都应该能够访问集中式缓存层，以实现最佳性能。

下图描述了解决方案架构各层中的缓存机制：

图 4.4：架构层的缓存

如上图所示，以下是每一层架构中的缓存机制：

• 客户端缓存：客户端缓存应用于用户设备，如手机和桌面。客户端缓存将先前访问的网页内容缓存起来，以便更快地响应随后的请求。每个浏览器都有自己的缓存机制。HTTP 缓存通过在本地浏览器缓存内容来加速应用程序。cache-control HTTP 头定义了客户端请求和服务器响应的浏览器缓存策略。这些策略定义了内容应该缓存在哪里，以及它会持续多长时间，这被称为 生存时间 (TTL) 。Cookies 是另一种用于存储信息在客户端计算机上，以便更快响应浏览器的方法。

• 互联网 DNS 缓存：当用户在互联网上输入网站地址时，公共 域名系统 (DNS) 服务器会查找 IP 地址。缓存此 DNS 解析信息将减少网站的加载时间。DNS 信息在第一次请求后可以缓存到本地服务器或浏览器中，任何进一步对该网站的请求都将更快。

• Web 内容缓存：许多请求涉及检索 Web 内容，如图像、视频和 HTML 页面。将这些资产缓存到用户附近的位置可以为页面加载提供更快的响应。这还消除了磁盘读取和服务器负载时间。内容分发网络（CDN）提供了一个边缘位置的网络，在这些位置可以缓存静态内容，如高分辨率图像和视频。这对重读型应用程序（如游戏、博客、电商产品目录页面等）非常有益。用户会话包含有关用户偏好和状态的大量信息。通过将用户会话存储在自己的键值存储中，提供了快速的用户响应，从而提供了良好的用户体验。

• 应用缓存：在应用层，可以通过缓存来存储复杂的重复请求的结果，从而避免业务逻辑计算和数据库访问。总体而言，它提高了应用性能，减少了数据库和基础设施的负担。

• 数据库缓存：应用性能高度依赖于数据库提供的速度和吞吐量。数据库缓存显著提高了数据库的吞吐量，并降低了数据检索的延迟。数据库缓存可以应用于任何关系型或非关系型数据库之前。一些数据库提供商集成了缓存功能，而应用程序则处理本地缓存。

Redis 和 Memcached 是最流行的缓存引擎。虽然 Memcached 更快（它适用于低结构数据，并以键值对格式存储数据），但 Redis 是一个更持久的缓存引擎，能够处理应用所需的复杂数据结构，例如游戏排行榜；你将在本章的 Memcached 与 Redis 部分学习更多细节。接下来让我们了解几种其他的缓存设计模式。

三层 Web 架构中的缓存分发模式

传统的 Web 托管架构遵循常见的三层 Web 应用模型，将架构划分为表示层、应用层和持久层。

如下图所示，在 AWS 架构中，缓存应用于 Web、应用和数据库层：

图 4.5：缓存分发模式架构

在缓存模式中，目标是尽量减少后端的访问。你可以编写一个应用程序，在其中缓存图像、JavaScript，甚至是整个页面，从而为用户提供更好的体验。在上图中，缓存被战略性地实施在架构的各个层次上：

• Amazon Route 53 在缓存 DNS 到 IP 的映射中起到了作用，从而简化了域名管理。

• Amazon S3 作为静态内容的存储位置，包括高分辨率图像和视频。

• Amazon CloudFront 提供边缘缓存服务，用于高流量内容，通过使用缓存控制头部来确定从源服务器更新的频率。

• 亚马逊 DynamoDB 用于会话存储，帮助 Web 应用通过缓存管理用户会话。

• 弹性负载均衡 (Elastic Load Balancing) 将流量均匀分配到 Web 服务器的自动扩展组中。

• 亚马逊 ElastiCache 提供应用程序的缓存服务，能有效减轻数据库层的负担。

通常，静态内容会被缓存，但也有一些场景中，缓存动态或唯一的内容可以提高应用程序性能。是否缓存取决于具体的使用模式和需求。

让我们来看看一个更具体的模式。

重命名分发模式

使用 CDN（如 Amazon CloudFront）时，你可以将经常使用的数据存储在离用户较近的边缘位置，以便获得更快的性能。通常，你会在 CDN 中为你的数据设置 TTL，这意味着在 TTL 到期之前，边缘位置不会回到服务器请求更新的数据。TTL 是指对象在缓存系统中存储的时间，直到被删除或刷新。你可能会遇到需要立即更新 CDN 缓存内容的情况，例如，如果你需要修正错误的产品描述。

在这种情况下，你不能等待文件的 TTL 到期。重命名分发模式可以帮助你在新更改发布后立即更新缓存，这样用户就能立刻获得更新的信息。下图展示了 AWS 中的这一模式：

图 4.6：重命名分发模式架构

如前图所示，使用重命名分发模式与缓存分发模式结合有助于解决更新问题。通过这种模式，服务器上传带有新文件名的更新文件，而不是覆盖原始服务器中的文件并等待 CloudFront 中 TTL 到期，然后更新网页中的新 URL。当用户请求原始内容时，CloudFront 必须从源服务器获取内容，不能提供已缓存的过时文件。

然而，你可以立即使旧文件失效，但这会产生更多成本，因此最好上传文件的新版本，供 CDN 立即获取。同样，你必须在应用程序中更新 URL 以便获取新文件，这相比使失效的选项会增加一些开销。最好根据你的业务需求和预算来做出决定。

你可以使用代理缓存服务器来代替 CDN，尤其是当用户分布在全国各地时。让我们在下一部分中详细了解它。

缓存代理模式

通过添加缓存层，你可以显著提高应用程序的性能。在缓存代理模式中，静态或动态内容会被缓存到 Web 应用服务器的上游。如下面的架构图所示，你在 Web 应用集群前面有一个缓存层：

图 4.7：缓存代理模式架构

在前面的图中，为了高效交付，缓存内容由缓存服务器传递。缓存代理模式的一些好处如下：

• 缓存代理模式帮助您通过缓存传递内容，这意味着无需在 web 服务器或应用服务器级别进行修改。

• 它们减少了动态内容生成的负载。

• 可以在浏览器级别设置缓存，例如在 HTTP 头、URL、Cookies 等中。或者，如果不想在浏览器级别存储缓存，可以在缓存层存储信息。

在缓存代理模式中，必须维护多个缓存副本，以避免单点故障。有时，您可能希望从服务器和 CDN 提供静态内容，每个方法需要不同的处理方式。让我们在下一节深入探讨这种混合情况。

重写代理模式

有时，您希望更改静态网站内容的访问目标，如图像和视频，但又不想更改现有系统。您可以通过提供代理服务器来实现这一点，使用重写代理模式。要将静态内容的目标更改为其他存储，如内容服务或互联网存储，您可以在 web 服务器群集前使用代理服务器。如以下架构图所示，您在应用层前放置一个代理服务器，帮助在不修改实际应用的情况下更改内容交付目标：

图 4.8：重写代理模式架构

如前图所示，将代理服务器放置在当前运行系统的前端，以重写代理模式。您可以使用如Apache或NGINX等软件构建代理服务器。以下是构建重写代理模式的步骤，使用 AWS 作为示例：

1. 将运行中的代理服务器放置在 EC2 实例上，代理服务器可以在负载均衡器和存储服务（如存储静态内容的Amazon S3）之间覆盖内容。

2. 在代理服务器规则中添加覆盖内容中 URL 的规则。这些规则将帮助弹性负载均衡（ELB）指向新位置，如前图所示，将代理服务器规则从https://cdn/test.jpg重定向到/test.jpg。ELB 是 AWS 提供的一项服务，可以自动将传入的应用流量分配到多个目标上，如 Amazon EC2 服务器、容器和 IP 地址。

3. 按照应用负载要求，为代理服务器配置自动扩展，设定代理服务器的最小和最大数量。

在本节“构建基于缓存的架构”中，你学习了如何处理静态内容分发的缓存。然而，在应用层进行缓存非常重要，可以提高应用性能，改善整体用户体验。接下来，让我们了解更多关于应用缓存模式的内容，以应对动态用户数据传输的性能需求。

应用缓存模式

在为应用程序应用缓存时，你需要在应用服务器和数据库之间添加一个缓存引擎层。应用缓存模式可以帮助你减少数据库的负载，因为最频繁的查询是通过缓存层提供的。应用缓存模式可以提升整体应用和数据库的性能。

如下图所示，你可以看到在 AWS 中，缓存层应用于应用层和数据库层之间：

图 4.9：应用缓存模式架构

如前图所示，你可以根据数据访问模式使用惰性缓存或写穿透缓存。在惰性缓存中，缓存引擎检查数据是否在缓存中，如果没有，它将从数据库中获取并存入缓存，以便服务未来的请求。惰性缓存也叫做缓存旁路模式。在写穿透方法中，数据同时写入缓存和数据存储。如果数据从缓存中丢失，可以从数据库中重新获取。

当你的应用是读密集型且能接受过时数据时，选择惰性缓存；而当处理写密集型操作并需要即时数据一致性时，选择写穿透缓存。例如，你可以在电子商务网站的产品目录中使用惰性缓存，其中产品细节经常被读取，但更新较少。当用户访问不在缓存中的产品详情时，它会从数据库中获取并存入缓存，供后续访问，减少数据库负载。在电子商务网站的用户评价部分，你可能希望使用写穿透缓存，因为用户生成的评价需要即时显示在产品页面。当用户提交评价时，它会同时写入缓存和数据库，确保后续的读取请求获取到最新数据。

让我们深入了解流行的缓存引擎Redis和Memcached。

Memcached 与 Redis

Redis 和 Memcached 是两种在应用设计中常用的缓存引擎。Redis 缓存引擎通常用于更复杂的应用缓存需求，例如为游戏创建排行榜。然而，Memcached 性能更高，有助于处理重负载应用。每种缓存引擎各有优缺点。我们来看看它们之间的主要区别，这将帮助你决定使用哪种：

Memcached	Redis
提供多线程支持	单线程
能够利用更多的 CPU 核心进行更快速的处理	无法利用多核处理器，导致相对较慢的性能
支持键值对数据	支持复杂和高级数据结构
缺乏数据持久性；在崩溃时丢失缓存中的数据	可以通过内建的读取副本和故障转移来保持数据持久性
易于维护	由于需要维护集群，涉及更多复杂性
适合缓存简单字符串，如简单 HTML 页面、序列化 JSON 等	适合为游戏排行榜、实时投票应用等创建缓存

表 4.1 – Memcached 与 Redis 的比较

如果你需要决定使用哪个引擎，应该根据一个能够证明使用 Redis 或 Memcached 的用例来选择。Memcached 简单且维护成本较低，通常在你的缓存不需要 Redis 提供的高级功能时优先选择。然而，如果你需要数据持久性、高级数据类型或其他任何 Redis 列出的特性，Redis 是最好的解决方案。

在实现缓存时，理解需要缓存的数据的有效性是至关重要的。如果缓存命中率很高，则数据在需要时可以从缓存中获取。为了提高缓存命中率，通过减少直接查询来卸载数据库，从而提升整体应用性能。缓存未命中发生在数据不在缓存中时，这会增加数据库的负担。缓存不是一个大型数据存储，因此你需要根据应用需求设置 TTL 并逐出缓存。

如你所见，应用缓存有多个好处，包括提升应用性能、提供可预测的性能以及减少数据库成本。

让我们了解更多应用程序架构，展示松耦合和约束处理原则的 MVC 架构。

模型-视图-控制器（MVC）架构

MVC 是开发软件应用程序时最流行的设计模式之一。它将应用程序分为三个互相关联的组件：模型、视图和控制器。这样的分离实现了更模块化的开发、更容易的测试和出色的可维护性。让我们详细探讨这些组件：

• 模型：模型表示应用程序的内部状态，以及管理和操作该状态的规则、逻辑和数据。模型不依赖于视图或控制器，这意味着 UI 或业务逻辑的变化不会影响数据处理。它确保应用程序的数据在不同部分之间保持一致。它的责任包括：

  • 管理数据：它包含所有与数据相关的逻辑。无论是从数据库还是 API 中检索数据，模型都会处理。

  • 实现业务规则：实现业务逻辑，如计算或数据转换。

  • 通知变更：当数据发生变化时，通知相关的视图和控制器，以便它们可以相应地更新自己。

• 视图：视图是模型数据的可视化表现。它定义了应用程序数据如何呈现给用户。当底层模型数据发生变化时，视图会自动更新，确保用户始终看到最新的数据。可以从同一模型数据创建多个视图，允许不同的表现形式（例如，表格、图表、详细视图）。它的职责包括：

  • 显示数据：从模型中获取数据，并以易于理解的格式呈现。

  • 处理用户界面（UI）：处理应用程序的所有 UI 逻辑，如用户输入字段、按钮、显示屏等。

• 控制器：控制器在模型和视图之间进行调解。它从视图获取用户输入，处理这些输入（可能会更新模型），并将输出显示返回给视图。控制器确保视图和模型始终保持同步。它充当所有用户交互的集中处理器，使得这些交互的管理更加系统化和有序。它的职责包括：

  • 处理用户输入：接收并解释用户命令，将其转化为模型执行的动作

  • 更新模型：通过向模型发送命令来修改模型中的数据

  • 更新视图：根据用户输入和模型变化更改视图中呈现的内容

以下是应用 MVC 模式的主要优势：

• 关注点分离：通过将应用程序的数据、用户界面和控制逻辑隔离开来，MVC 促进了模块化开发。

• 可重用性：组件可以在应用程序的不同部分甚至不同的应用程序之间重用。

• 可维护性：使得更新、测试和调试应用程序的不同部分变得更加容易。

• 灵活性：使开发者能够在不影响其他部分的情况下更改系统的一部分，例如更改 UI 而不改变底层数据处理。

MVC 是一种强大的架构模式，提供了强大的数据管理、用户界面和业务逻辑管理。它广泛应用于各种应用开发环境，从 Web 开发框架到桌面应用程序，帮助创建可扩展和易于维护的软件。通过遵循 MVC 原则，应用程序架构师可以创建组织良好、高效且灵活的应用程序，便于更新和维护。让我们通过一个例子更好地理解 MVC。

将 MVC 应用于设计一个在线书店

例如，在设计一个在线书店时，MVC 架构可以高效地处理书籍数据、用户界面和用户输入之间的复杂交互，从而构建一个更加健壮和可扩展的系统。让我们来看看每个模块的详细内容：

• 模型：管理与书籍、作者、分类、客户评价等相关的数据。操作示例包括：

  • 获取特定书籍的详细信息

  • 购买后更新库存

  • 添加新书到目录

• 视图：以易读和互动的格式向用户展示信息。视图的示例包括：

  • 书籍列表页面：显示书籍的标题、封面和价格列表

  • 书籍详情页：显示有关特定书籍的详细信息，包括作者、简介、评价等。

  • 购物车页面：允许用户查看、添加或移除购物车中的商品

• 控制器：处理用户交互，根据需要更新模型，并更新视图以反映变化。操作示例包括：

  • 搜索书籍：用户输入搜索词。控制器查询模型中匹配的书籍，并更新视图以显示结果。

  • 添加到购物车：用户点击添加到购物车，控制器更新模型，反映购物车中的新商品，视图随之更新以显示新的购物车状态。

  • 结账：用户决定购买。控制器处理交易，更新模型（包括库存），并重定向到确认视图。

MVC 模式提供了清晰的关注点分离，使得扩展、维护和测试应用程序变得更加容易。

构建领域驱动设计（DDD）

领域驱动设计（DDD）是一种方法论和一组实践，旨在理解并解决软件核心复杂性。该方法用于基于“领域”或业务核心逻辑和关键概念来设计和建模软件。通过使用通用语言并将系统划分为清晰的上下文，DDD 促进了对问题空间的深入理解，并导致一个准确反映底层业务需求的设计。它在复杂领域中特别有价值，因为在这些领域，确保软件与它所代表的现实世界概念紧密对齐至关重要。

让我们通过一个具体的示例和用例深入探讨 DDD。为此，我们将考虑一个医疗健康管理系统（HMS）的领域。假设我们正在开发一个为医疗服务提供商管理患者记录、预约、医疗治疗、账单等的系统。我们可以将 DDD 的概念应用到这个领域，方法如下：

• 领域： "领域"指的是软件旨在解决的特定问题领域。应用逻辑围绕着这一知识和活动范围展开。理解领域对于创建一个真正满足业务需求的系统至关重要。对于医疗管理系统（HMS）来说，领域将是医疗管理，聚焦于病人、医疗人员、预约、治疗和账单。

• 通用语言：通用语言是开发人员和非技术利益相关者之间共享的语言，用来描述领域。这种共同的语言确保团队成员对关键术语和概念有统一的理解，减少误解，促进清晰的沟通。对于 HMS，创建一个既能被医疗专业人员又能被开发人员理解的共享语言，例如，病人、预约、治疗、医疗人员等。

• 限界上下文：在领域驱动设计（DDD）中，应用程序被划分为不同的限界上下文，每个上下文代表领域内的特定职责或功能。限界上下文封装了该领域特定部分的所有术语、定义和逻辑，并明确什么是其边界内的，什么是边界外的。例如，病人管理限界上下文处理病人记录、个人信息、病历等；预约调度限界上下文包括管理预约、调度、取消、重新安排等；而账单限界上下文则包括处理付款、保险、发票等事务。

• 实体：这些对象具有独特的身份，贯穿不同的时间和状态，例如病人（拥有唯一 ID）和医疗人员（拥有独特的资格证书）。

• 值对象：描述事物特征但没有概念性身份的对象。它们是不可变的，可以轻松替换。例如，地址、出生日期和病历（因为这些没有单独的身份）。

• 聚合：聚合是指一组关联对象，作为数据更改的单一单元进行处理。聚合内的一个实体被称为根实体，外部引用仅限于该根实体，以确保数据完整性。例如，在一个在线医疗管理系统中，医疗预约可以被建模为一个聚合。该聚合可能包括像病人（预约的对象）、医疗人员（为病人提供服务的人员）、治疗室（预约地点）、时间段（预约的时间）等实体和值对象。在这里，预约实体将是聚合根。与特定预约相关的任何病人、医疗人员、治疗室或时间段的更改都应通过预约实体进行。这确保了预约聚合的一致性，并强制执行所有与医疗预约相关的业务规则。

• 仓储：仓储用于从底层持久化层中检索聚合。它们提供了一种抽象，使得应用程序的其他部分可以以与领域模型一致的方式与数据存储进行交互。例如，病人仓储用于获取和管理病人实体，而预约仓储用于检索和存储预约聚合。

• 工厂：工厂负责封装创建复杂对象和聚合的逻辑。它们确保对象或聚合在一致且有效的状态下创建。例如，病人工厂用于创建一个具有有效初始状态的新病人实体，而预约工厂用于创建一个包含必要细节的新预约聚合。

• 服务：当某个操作在逻辑上不属于值对象或实体时，可以将其定义为服务。服务是领域模型的一部分，包含针对领域概念的业务逻辑。例如，在计费上下文中，计费服务包含计算总费用、应用保险折扣、生成发票等操作。

• 领域事件：领域事件捕捉领域内发生的重大事件。它们可以触发系统内或其他系统中的其他活动。例如，预约调度事件会在新预约安排时触发，通知相关工作人员；支付处理事件则会在支付成功后发生，可能会启动生成收据的流程。

• 反腐层：这一层负责在使用不同语言或模型的系统各部分之间进行转换。它确保每个模型的完整性得到维护，并处理不一致性。如果计费系统必须与外部第三方支付网关进行交互，反腐层可以在计费上下文中的领域模型与外部系统使用的模型之间进行转换。

在这个 HMS 中，DDD 确保复杂的领域逻辑得到精心建模和组织。它鼓励医疗专业人员（领域专家）与开发人员之间的协作，以创建共享的理解和语言。

系统的设计紧密结合了现实世界的医疗操作，通过定义明确的界限上下文、实体、聚合和其他 DDD 概念。这种对齐确保了软件提供了一种稳健且灵活的解决方案，满足医疗领域的特定需求。

这个例子展示了 DDD 如何通过关注核心领域并促进不同利益相关者之间的协作，成为打造复杂、结构良好的系统的关键工具。

依赖处理是处理复杂系统时的重要方面。让我们学习如何通过熔断器处理不同服务之间的依赖，以确保一个服务中的错误不会导致整个系统崩溃。

理解熔断器模式

分布式系统通常会调用其他下游服务，而该调用可能失败或挂起，且没有响应。你通常会看到代码会重试失败的调用多次。远程服务的问题在于，它可能需要几分钟甚至几个小时来修复，而立即重试可能会导致另一次失败。因此，最终用户会更长时间等待错误响应，而你的代码在重试多次。这种重试功能会消耗线程，可能会引发级联故障。

熔断器模式是关于理解下游依赖的健康状态。它会检测这些依赖是否不健康，并实现逻辑，优雅地失败请求，直到检测到它们再次健康。熔断器可以通过使用持久化层来实现，监控过去请求时间间隔内的健康和不健康请求。

如果在过去的时间间隔内，观察到请求的某一比例呈现不健康行为，或者总的异常计数超过预定义值，不管该比例如何，电路将标记为打开。在这种情况下，所有请求都会抛出异常，而不是与依赖集成，直到定义的超时期过去。一旦超时期结束，少量请求将尝试与下游依赖集成，以检测健康状态是否已恢复。当足够比例的请求在一段时间内再次健康，或者没有错误出现时，电路将再次关闭，所有请求将正常进行集成。

实现决策涉及到状态机跟踪/共享健康/不健康请求计数。服务的状态可以保存在 DynamoDB、Redis/Memcached 或其他低延迟持久化存储中。

接下来，我们来讨论隔舱架构模式，它有助于减少服务之间的依赖，并在服务出错的情况下缓解问题。

实现隔舱模式

隔舱是船只上用来创造独立密闭区域的结构隔板。其主要目的是在船体发生破损时，控制进水的后果，防止水在船只中蔓延。这种设计作为一种重要的安全措施，旨在最小化单一区域损坏时整个船只沉没的风险。

相同的概念有助于在大型系统架构中限制故障的范围，在这种架构中，你希望划分系统以解耦服务之间的依赖。其核心思想是一个故障不应该导致整个系统失败，正如下图所示：

图 4.10：舱壁模式

在舱壁模式（bulkhead pattern）中，最好将应用程序的高依赖元素隔离到服务池中，这样如果其中一个发生故障，其他的可以继续为上游服务提供服务。Service 3 在前面的图中从单一服务分隔成了两个池。在这里，如果Service 3 发生故障，Service 1 或 Service 2 的影响将取决于它们对该池的依赖，但整个系统不会崩溃。引入舱壁模式时，需要特别注意以下几点，尤其是在共享服务模型下：

• 保存部分船体，这意味着你的应用程序不应因一个服务的失败而关闭。

• 决定是否可以接受资源使用效率较低。一个分区中的性能问题应该不会影响整个应用程序。

• 选择合适的粒度。确保服务池是可管理的，并且能够处理应用程序负载。

• 监控每个服务分区的性能，并遵守服务水平协议（SLA）。确保所有组件协同工作，并在一个服务池宕机时测试整个应用程序。

应根据每个业务或技术需求定义一个服务分区。最好使用这种模式，以防止应用程序发生级联故障，并将关键消费者与普通消费者隔离开来。

通常，遗留应用服务器的配置中会包含硬编码的互联网协议（IP）地址或域名系统（DNS）名称。进行现代化和升级时，任何服务器变更都需要修改和重新验证应用程序。在这种情况下，你希望保持服务器地址不变。在下一节中，我们将学习如何通过浮动 IP 来处理这种情况。

创建浮动 IP 模式

通常，单体应用程序对其部署的服务器有很多依赖。应用程序配置和代码通常会根据服务器的 DNS 名称和 IP 地址进行硬编码。如果你想在原始服务器出现问题时启动新服务器，硬编码的 IP 配置会带来挑战。此外，你不希望因升级而使整个应用程序停机，这可能会导致较长时间的停机。

要处理这种情况，您需要创建一个新的服务器，保持相同的服务器 IP 地址和 DNS 名称。这可以通过将网络接口从有问题的实例移动到新服务器来实现。网络接口通常基于网络接口卡（NIC），用于在网络上服务器之间进行通信。它可以是硬件或软件形式。移动网络接口意味着现在您的新服务器承担了旧服务器的身份。您的应用程序可以使用相同的 DNS 和 IP 地址。它还允许通过将网络接口移回原始实例来轻松回滚。

公共云（例如 AWS）通过提供弹性 IP（EIP）和弹性网络接口（ENI）简化了操作。如果您的实例发生故障，并且需要将流量推送到具有相同公共 IP 地址的另一个实例，则可以将 EIP 地址从一台服务器移动到另一台服务器，如下面的架构图所示：

图 4.11：浮动 IP 和接口模式

由于您正在移动 EIP，DNS 可能不需要更新。EIP 可以将您的服务器公共 IP 移动到不同的实例。如果需要移动公共和私有 IP 地址，则可以使用更灵活的方法，例如 ENI，如前图右侧所示。ENI 可以跨实例移动，并且您可以使用相同的公共和私有地址进行流量路由或应用程序升级。

到目前为止，您已经了解了多种架构模式，其中应用程序部署在虚拟机中。但是，在许多情况下，您可能需要帮助来利用虚拟机。为了进一步优化您的利用率，您可以将应用程序部署在容器中。容器最适合于微服务部署。让我们在下一节中深入了解基于容器的部署。

使用容器部署应用程序

随着许多编程语言的发明和技术的进步，这带来了新的挑战。不同的应用堆栈需要不同的硬件和软件部署环境。通常需要在不同平台上运行应用程序并迁移至另一个平台。解决方案需要一种可以在任何地方运行并且一致、轻量且可移植的东西。

就像运输集装箱标准化了货物的运输一样，软件容器标准化了应用程序的运输。Docker 创建一个包含软件应用程序运行所需的所有内容的容器，例如文件系统结构、守护程序、库和应用程序依赖项。

容器为软件提供了相应开发和测试环境中的隔离。这种隔离至关重要，因为它可以防止多个团队在相同底层基础设施上运行各种软件应用时产生冲突。

虚拟机在操作系统级别进行隔离，而容器则在内核级别进行隔离。这种隔离允许多个应用程序在单一主机操作系统上运行，并且仍然拥有各自的文件系统、存储、RAM、库，以及大多数情况下，各自的系统视图：

图 4.12：应用程序部署的虚拟机和容器

如前图所示，容器在单个虚拟机中部署多个应用程序。每个应用程序都有其运行时环境，因此您可以在保持服务器数量不变的情况下运行多个独立应用程序。容器共享机器的操作系统内核。它们具有快速启动时间和高效利用计算资源（如 RAM）的优点。容器镜像是通过文件系统的层构建的，可以共享公共文件。这种共享资源的方法减少了磁盘使用量并加快了下载容器镜像的速度。

让我们来看看为什么容器越来越受欢迎，以及它们的好处。

容器的好处

关于容器，经常会有人提出以下问题：

• 当我们已有实例时，为什么还需要容器？

• 难道实例不已经为我们提供了与底层硬件的隔离吗？

尽管前面的问题是有效的，但使用像Docker这样的系统仍然有许多好处。Docker 的一个关键优势是，它允许您通过在同一实例中托管多个应用程序（在不同端口上）来充分利用虚拟机资源。

Docker 利用 Linux 内核的某些特性，特别是内核命名空间和组，来实现每个 Docker 进程之间的完全隔离，正如下图所示：

图 4.13：应用程序基础架构中的容器层

如前图所示，实际上可以在同一台机器上运行两个或多个需要不同版本 Java 运行时的应用程序，因为每个 Docker 容器都有自己安装的 Java 版本和相关库。进而，应用程序基础架构中的容器层使得将应用程序拆解为微服务变得更加容易，这些微服务可以在同一实例上并行运行。容器具有以下优点：

• 可移植的运行时应用环境：容器提供平台无关的能力，您可以一次构建应用程序并在任何地方部署，无论底层操作系统如何。

• 更快的开发和部署周期：修改应用程序并快速启动，通常几秒钟内即可运行，几乎可以在任何地方进行。

• 将依赖项和应用程序打包成单一工件：将代码、库和依赖项打包在一起，使应用程序能够在任何操作系统上运行。

• 运行不同版本的应用程序：具有不同依赖关系的应用程序可以在同一服务器上同时运行。

• 一切皆可自动化：容器管理和部署通过脚本进行，帮助减少成本并降低人为错误的风险。

• 更好的资源利用：容器提供高效的扩展和高可用性，同一微服务容器的多个副本可以在服务器之间部署，为您的应用程序提供支持。

• 轻松管理安全性：容器是特定于平台的，而不是特定于应用程序的。

由于其优势，容器部署变得非常流行。有多种方式可以编排容器。接下来，我们将更详细地了解容器部署。

容器部署

使用容器部署，具有多个微服务的复杂应用程序可以迅速部署。容器使得构建和部署应用程序更加可管理，因为环境是一致的。在开发模式下构建容器，将其推送到测试环境，再发布到生产环境。对于混合云环境，容器部署非常有用。容器使得在微服务之间保持环境一致性变得更容易。由于微服务通常不会消耗大量资源，它们可以被放置在同一个实例中以降低成本。

有时，客户的工作流较短，需要临时的环境设置。这些环境可能是队列系统或持续集成任务，这些任务不总是高效地利用服务器资源。容器编排服务如 Docker 和 Kubernetes 可以作为解决方案，允许它们将容器推送到实例并随时弹出。

Docker 的轻量级容器虚拟化平台提供了管理应用程序的工具。它的独立应用程序可以安装在任何计算机上，以运行容器。Kubernetes 是一个与 Docker 以及其他容器平台配合使用的容器编排服务。Kubernetes 允许自动化容器配置，并精心处理安全性、网络和扩展等方面的问题。

容器帮助企业创建更多的云原生工作负载，公共云服务提供商如 AWS 扩展了服务来管理 Docker 容器和 Kubernetes。

以下图示展示了 Docker 使用 Amazon 弹性容器服务 (ECS) 进行容器管理，提供全托管的弹性服务，自动化 Docker 容器的扩展和编排：

图 4.14：容器部署架构

在上述图中，多个容器被部署在单个通过 Amazon ECS 管理的 Amazon EC2 虚拟机中，该虚拟机促进了代理通信服务和集群管理。所有用户请求通过负载均衡器在容器之间分发。同样，AWS 提供了 Amazon Elastic Kubernetes Service（EKS）来使用 Kubernetes 管理容器。

容器是一个广泛的话题，作为解决方案架构师，你必须熟悉所有可用的选项。本节提供了容器的概述。然而，如果你将容器用于微服务部署，你需要更深入地了解。让我们在下一节中看看基于容器的架构。

构建基于容器的架构

如你在前一节所学，容器化有助于创建可重复和可扩展的应用环境。要开始采用容器，你需要识别一个由容器编排管理的试点工作负载。你可以将现有的微服务组件部署到容器中。在识别出差距和运营需求后，你可以定义一个迁移策略，将工作负载迁移到容器中。

如果你的应用最初并未设计为在容器化环境中运行，容器迁移可能会很具挑战性。这是因为许多应用通常将文件存储在本地，并依赖有状态会话。在迁移到容器时，必须处理这些特定要求，并确保你的应用可以在容器环境中平稳运行。

对于容器平台，你可以做出选择；你可以选择 Docker、OpenShift、Kubernetes 等。然而，Kubernetes 正变得越来越流行，成为一个开源的容器编排工具。像 AWS 这样的公共云服务商提供了管理容器的平台，例如 Amazon ECS 用于 Docker，Amazon EKS 用于 Kubernetes。这些云服务提供了一个控制平面，可以选择不同的计算选项，比如选择自管节点、托管节点或与 AWS Fargate 一起使用的无服务器选项。控制平面作为中央管理接口，允许对容器化应用及其资源进行编排和操作监督。如果你正在利用 Amazon EKS 部署基于微服务的应用程序，例如，由 AWS 管理的 Kubernetes 控制平面负责容器部署的编排、状态管理和保持期望配置。这样的设置让你能够专注于应用程序开发，而不是基础设施管理。

以下架构图展示了在 Amazon EKS 上运行有状态服务，使用你选择的编程语言，如 Java 或 .NET。在这个架构中，你可以在 Redis 数据库中管理会话状态。

图 4.15：在容器上部署有状态应用

正如你在前面的图表中看到的，基于容器的架构包含了几个关键组件：

• 一个 Amazon 虚拟私有云（VPC），包含特定的子网：

  • 公有子网：托管负载均衡器

  • 私有子网：用于部署应用和数据库

• 应用负载均衡器，负责提供对托管在容器中的网站的访问。

• 一个 Amazon 弹性 Kubernetes 服务（EKS）集群，包含 Kubernetes 中的托管节点组。这些节点负责运行多个应用容器。

• 一个 Amazon ElastiCache Redis 数据库，用于存储用户会话状态。

这种架构通过将用户会话存储在 Redis 数据库中，支持应用的可扩展性。然而，请注意，实现此解决方案可能需要修改应用代码，这在某些情况下可能不可行。

现在，你已经了解了多种专注于应用开发的架构模式。数据是任何架构设计中不可或缺的一部分，且大多数架构围绕着数据的收集、存储和处理展开。在下一节中，让我们深入了解如何在应用架构中处理数据。

应用架构中的数据库处理

数据始终是任何应用开发的核心，数据扩展一直是一个挑战。高效地处理数据可以提升应用的延迟和性能。在前面一节 构建基于缓存的架构 中，你学习了如何通过在数据库前面放置缓存来处理频繁查询的数据，属于应用缓存模式。你可以将 Memcached 或 Redis 缓存放在数据库前面，从而减少对数据库的多次访问，并提高数据库的响应速度。

在应用部署中，随着应用用户基础的增长，你需要通过关系型数据库处理更多的数据。你需要增加更多的存储或通过增加更多的内存和 CPU 来垂直扩展数据库服务器。通常，当涉及到扩展关系型数据库时，横向扩展会更加复杂。如果你的应用是读密集型的，你可以通过创建只读副本来实现横向扩展。将所有的读请求路由到数据库的只读副本，同时保持主数据库节点处理写入和更新请求。由于只读副本采用异步复制，它可能会增加一些延迟时间。如果你的应用可以容忍几毫秒的延迟，选择只读副本是合适的。你可以利用只读副本来卸载报表查询。

你可以使用数据库分片技术，为你的关系型数据库创建一个多主架构，并引入横向扩展的概念。分片技术用于通过多个数据库服务器提升写入性能。数据库被结构化并划分为相同的部分，适当的表列作为键，用于分配写入过程。

如下架构图所示，客户数据库可以分成多个分片：

图 4.16：关系型数据库分片

如前图所示，未进行分片时，所有数据都位于一个分区中，例如，所有用户的名字都存储在同一个数据库中。进行分片后，数据会被分割成称为分片的大块。例如，所有名字以A 到 I开头的用户在一个数据库中，J 到 R在另一个数据库中，S 到 Z在第三个数据库中。在许多情况下，分片能提供更高的性能和更好的操作效率。

使用 Amazon RDS 进行分片后端数据库时，需要在 Amazon EC2 实例上安装分片软件，如 MySQL，并搭配 Spider 存储引擎。随后，您可以开始设置多个 RDS 数据库，并将它们作为分片的后端数据库。

然而，如果您的主数据库实例宕机怎么办？在这种情况下，您需要保持数据库的高可用性。让我们更详细地了解一下高可用性数据库模式。

高可用性数据库模式

为了确保应用程序的高可用性，保持数据库持续运行至关重要。由于关系型数据库的水平扩展并非直接可行，因此带来了额外的挑战。为了实现高可用性的数据库，您可以拥有一个主数据库实例的备用副本，如下图所示：

图 4.17：高可用性数据库模式

如前图所示，如果主实例出现故障，您的应用服务器会切换到备用实例。读取副本将分担主实例的负载，以处理延迟。主实例和备用实例位于不同的可用区，因此即使一个可用区完全故障，您的应用程序仍然可以正常运行。这种架构还帮助实现零停机时间，避免了数据库维护窗口期间可能出现的停机。当主实例进行维护时，应用程序可以切换到次级备用实例，继续处理用户请求。

对于灾难恢复，您需要根据应用程序的恢复点目标（RPO）来定义数据库备份和归档策略，决定您希望多频繁地进行备份。您将在第八章，架构可靠性考虑中深入了解 RPO 和 RTO。

如果您的恢复点目标（RPO）是 30 分钟，意味着您的组织只能容忍 30 分钟的数据丢失。在这种情况下，您应每半小时进行一次备份。在存储备份时，您需要确定数据可以存储多长时间以便客户查询。您可以将数据存储六个月作为活跃备份，然后根据合规要求存储到归档存储中。

考虑您需要多快访问备份，并根据公司的恢复时间目标（RTO）确定所需的网络连接类型，以满足您的备份和恢复要求。

例如，如果贵公司的 RTO 是 60 分钟，意味着您应具备足够的网络带宽，以便在一个小时内检索并恢复您的备份。同时，确定您是备份整个系统的快照，还是备份附加到系统的卷。

您可能还需要对数据进行分类，例如，如果数据包含客户敏感信息，如电子邮件、地址、个人身份信息等，您最好根据此定义数据加密策略。您将在第七章，安全性考虑中学习更多关于数据安全的内容。

根据您应用程序的增长和复杂性，考虑将从关系型数据库管理系统（RDBMS）迁移到 NoSQL 数据库。NoSQL 可以提供比大多数关系型数据库更强的可扩展性、管理性、性能和可靠性。然而，从 RDBMS 迁移到 NoSQL 的过程可能既耗时又费力。

在任何应用程序中都需要处理大量数据，例如点击流数据、应用日志数据、评分和评论数据、社交媒体数据等。分析这些数据集并获得洞察可以帮助您以指数级增长您的组织。第十二章，解决方案架构的数据工程将教您更多关于这些用例和模式的内容。

现在，让我们了解如何使用清洁架构构建一个可维护的系统。

清洁架构

清洁架构，也称为六边形架构或端口和适配器架构，是一种用于设计业务应用程序的架构模式。由 Robert C. Martin 提出，强调关注点分离、可维护性和可测试性。清洁架构旨在随着时间的推移创建一个灵活、可适应且易于维护的系统。

清洁架构将您的应用程序分为五个关键组件；让我们通过在线书店的示例来理解它们：

1. 实体（最内层）：实体是封装核心业务规则的业务对象。它们独立于任何特定技术、数据库或框架。实体代表系统中的“事物”及其能够执行的操作。在在线书店中，一个Book实体可能具有诸如标题、作者、价格等属性，并且具有检查可用性或应用折扣的方法。

2. 用例：用例包含应用程序特定的规则，并定义实体如何互动以完成特定的场景或用户故事。它们协调实体与外部接口之间的数据和动作流。它们也是与技术无关的，只关注业务逻辑。例如，结账用例可能涉及验证购物车、应用折扣、计算运费和处理支付等操作。

3. 接口（端口）：接口定义了不同层之间如何交互的契约。它们创建了一个边界，将内层（实体和用例）与外层（适配器、框架和驱动）分开。这种分离提供了灵活性和可维护性。可能会有一个支付处理的接口，定义了处理支付和退款等方法。

4. 适配器：适配器实现接口并在内外层之间进行转换。它们使得应用能够与外部组件（如数据库、API 或第三方库）进行交互。适配器让核心逻辑保持与技术变化或外部依赖的隔离。一个数据库适配器可能会实现一个数据访问接口来处理与特定数据库技术的交互。

5. 框架和驱动（最外层）：这一层包含了构建应用程序所使用的所有技术细节和工具，包括 web 服务器、数据库、UI 框架、第三方库等。这一层通过适配器与核心应用连接到外部世界。这可能包括使用特定的 web 框架实现 RESTful API、设置与 SQL 数据库的连接，或与第三方支付网关集成。

在清洁架构中，每一层都是独立的，允许对一层的修改不影响其他层。你可以更换数据库、更改 UI 框架或修改业务逻辑，而不会在系统中引起连锁反应。由于架构有明确定义的接口，创建模拟对象或存根进行测试变得更加容易。核心业务逻辑可以独立于数据库、UI 或其他外部依赖进行测试。

在使用清洁架构时，确保避免过度工程化。对于简单或小型项目，清洁架构的复杂性和开销可能需要重新评估。需要仔细考虑其带来的好处是否超出了增加的复杂性和开发时间。

清洁架构为开发能够适应不断变化的技术和需求的软件提供了一个稳健且灵活的基础。专注于分离关注点并明确各层之间的边界，有助于提升可维护性、可扩展性和可测试性。这是一个强大的模式，能够在复杂系统中发挥良好作用，但必须在理解具体项目需求和背景的基础上应用，以避免不必要的复杂性。

现在，你已经学习了各种架构模式和最佳实践。让我们了解一下设计应用架构时需要小心的关键反模式。

避免在解决方案架构中使用反模式

在本章中，你学习了使用各种设计模式设计解决方案架构的不同方法。通常，由于时间压力或资源不足，团队可能会偏离最佳实践。建议尽量避免以下架构设计反模式。反模式作为设计不良系统的示例：

• 在反模式中，扩展是反应式和手动处理的。当应用服务器达到最大容量且没有更多可用资源时，用户会遇到访问应用程序的中断问题。只有当用户开始报告问题时，管理员才会意识到这个问题。然后，管理员启动新服务器实例的过程，以减轻现有服务器的负载。然而，这种方法有一个缺点，通常在实例启动和实际可用之间会有几分钟的延迟。在此期间，用户会遇到服务中断，无法访问应用程序。你应该采取主动的方法，使用自动扩展，在服务器达到某个阈值时添加处理能力，例如 CPU 使用率达到 60% 或内存使用率达到 60%。

• 在反模式下，缺少自动化。当应用服务器崩溃时，管理员手动启动并配置新服务器，并手动通知用户。自动化检测不健康资源并启动替换资源可以简化操作。此外，还可以在发生资源变化时实现自动通知。

• 在反模式下，服务器会长时间保持硬编码的 IP 地址，这限制了灵活性。随着时间的推移，服务器配置可能变得不一致，导致资源分配效率低下，部分资源在不需要时仍然运行。你应该保持所有服务器的一致性，并能够切换到新的 IP 地址。你还应该自动终止任何未使用的资源。

• 在反模式下，应用程序是以单体方式构建的，其中所有架构层，包括 web 层、应用层和数据层，都紧密耦合并依赖于服务器。如果某个服务器崩溃，会导致整个应用程序崩溃。通过在应用层和 web 层之间添加负载均衡器，可以保持它们的独立性。如果某个应用服务器不可用，负载均衡器会自动将所有流量重定向到剩余的健康服务器。

• 在反模式中，应用程序与服务器绑定，服务器之间直接通信。用户认证和会话存储在服务器本地，所有静态文件都从本地服务器提供。你应该创建一个面向服务的 RESTful 架构，在这种架构中，服务之间使用标准协议如 HTTP 进行通信。用户认证和会话应该存储在低延迟的分布式存储中，以便横向扩展应用程序。静态资源应该存储在与服务器解耦的集中式对象存储中。

• 在反模式中，会使用单一数据库来满足所有需求。你使用关系数据库处理所有需求，这会引入性能和延迟问题。你应该根据需求使用正确的存储，例如以下几种：

  • 使用 NoSQL 存储用户会话

  • 用于低延迟数据可用性的缓存数据存储

  • 用于报告需求的数据仓库

  • 用于事务数据的关系数据库

• 在反模式中，你可能会发现单点故障，即只有一个数据库实例来为应用程序提供服务。每当可能时，应该从架构中消除单点故障。建立一个备用服务器，并复制数据。当主数据库服务器出现故障时，备用服务器可以接管工作负载。

• 在反模式中，静态内容如高分辨率图像和视频直接从服务器提供，而不进行缓存。最好考虑使用 CDN 来缓存重型内容，靠近用户位置，这有助于提高页面延迟并减少页面加载时间。

• 在反模式中，你可能会发现安全漏洞，导致服务器访问没有细粒度的安全策略。你应该始终应用最小权限原则，即从没有访问权限开始，只给需要的用户组提供访问权限。

上述内容提供了一些最常见的反模式。在本书中，你将学习如何在解决方案设计中避免这些反模式的最佳实践。

总结

本章深入探讨了如何通过各种架构范式构建强大且可扩展的软件架构。首先，讨论了 n 层分层架构，分析了构成 Web、应用和数据库层的基本组件。讨论随后过渡到多租户软件即服务(SaaS)架构，深入探讨了在统一框架中容纳不同用户群体的复杂性和好处。

至于 Web 服务，本章深入探讨了 RESTful 架构风格，阐明了其原则和应用。随后，作者带领读者构建了一个 RESTful 电商架构，提供了关于实际应用的实用见解。

随后讨论了基于缓存的架构，全面探索了缓存分发、代理模式（如缓存代理和重写代理）以及应用缓存等高效缓存策略。对 Memcached 和 Redis 的比较研究揭示了选择最佳缓存解决方案的方法。

通过探索模型-视图-控制器（MVC）方法和领域驱动设计（DDD）方法论，强调了架构模式的重要性，使架构师能够创建结构化、适应性强和可维护的系统。

通过深入讨论断路器模式和实施隔舱模式以提升系统稳定性，涵盖了架构的弹性。进一步介绍浮动 IP 模式丰富了您实现高可用性的工具包。

本章深入探讨了容器化，揭示了容器的多重好处，并提供了有效容器部署的路线图。在应用架构中研究了数据库处理策略，关注高可用性模式以确保数据完整性和持续运行。

本章以突出干净架构原则为主题，并传授避免解决方案架构中有害反模式的策略作为结束语。

通过参与这次架构探险，您深入了解了构建具有弹性、可扩展和未来准备性软件系统的复杂性，并且现在拥有了足够的知识来应对现代技术动态的挑战。

留下评论！

喜欢这本书吗？通过留下亚马逊评论来帮助像您一样的读者。扫描下方的二维码，获取您选择的免费电子书。

第五章：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 上交付安全调查的无服务器架构示例，见下图：

图 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 应用程序：

图 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 函数中包含了应用逻辑，用来聚合所有用户投给他们最喜欢演员的投票数据，并返回最终结果：

图 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 的服务都会生成和监听事件，如下图所示：

图 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 服务为例的服务网格基础设施。

图 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 云服务实现服务网格模式的实现：

图 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 服务实现反应式架构，应用于广告追踪的用例。下图展示了广告技术公司使用的反应式架构：

图 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）：

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

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

任务观察者模式

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

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

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

图 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）模型中，当事件被发布时，通知会发送给所有订阅者，每个订阅者可以根据其数据处理需求采取必要的行动。

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

图 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 函数处理图像。

事件流模型

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

图 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

第六章：6

性能考虑因素

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

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

• 高性能架构的设计原则

• 性能优化的技术选择

• 移动应用性能考虑

• 性能测试

• 性能监控管理

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

高性能架构的设计原则

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

降低延迟

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

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

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

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

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

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

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

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

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

提高吞吐量

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

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

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

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

图 6.2：网络中的吞吐量

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

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

下面是公式的分解：

• 平均 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 大小从字节转换为兆字节：

   • 

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 上进行多任务处理，任务快速切换，给人同时执行的假象），但并行性进一步扩展了这一概念，通过多核处理器或分布式系统真正实现同时执行多个操作。这种方法通过将工作划分为可以并行处理的小块，大大加快了计算密集型任务的处理时间。处理大型数据集、复杂计算或可以分解为独立单元的任务的应用，能从并行性中获得极大的益处，实现更高的吞吐量和效率。

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

图 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 容器之间的网络通信：

图 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），提供具有高可用性和耐久性的无限扩展对象数据存储。你可以通过唯一的全局标识符和元数据文件前缀访问数据。

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

图 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 云中的自动扩展配置示例：

图 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

第七章：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) 简化了用户管理；你可以根据用户的角色创建用户组，并为每个组分配适当的访问策略。如以下图示所示，你可以有三个组——管理员、开发者和测试人员，并为每个组应用相应的访问策略。例如，管理员可以访问任何系统，包括生产环境，而开发者的访问仅限于开发环境，测试人员只能访问测试环境：

图 7.1：用户组组织

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

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

联合身份管理与单点登录

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

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

图 7.2：FIM 认证流程

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

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

Kerberos

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

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

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

图 7.3：Kerberos 认证

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

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

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

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

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

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

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

微软活动目录

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

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

图 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 断言的流程：

图 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 获取其个人资料照片：

图 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：

图 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 攻击：

图 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 缓解示例：

图 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 等公有云服务提供商为例，帮助你理解网络安全。你可以将这个示例应用到你的本地或私有云网络基础设施中。

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

图 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 和阿里巴巴：

图 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 都是安全的最佳实践。你了解了适用于云工作负载的各种合规性和共享安全责任模型。最终，你学习了如何构建威胁模型。

本章介绍了应用安全最佳实践，而可靠性是任何解决方案设计的另一个重要方面。为了使你的业务成功，你需要创建一个始终可用并能处理工作负载波动的可靠解决方案。在下一章中，你将学习如何利用现有技术使应用程序更可靠的最佳实践。你将学习各种灾难恢复和数据复制策略，以提高应用程序的可靠性。

留下评论！

享受这本书吗？通过在亚马逊上留下评价帮助像你一样的读者。扫描下面的二维码，获取你选择的免费电子书。

第八章：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 之间的区别：

图 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）和数据持久性。如果主数据库遇到问题，服务可以自动故障转移到副本，且对业务的影响最小。对于只读副本，则使用异步复制，你可以用它来处理报告和读取请求。

如下图所示，在同步复制中，主数据库实例和备用数据库实例之间的数据复制没有延迟，而在异步复制中，主数据库实例和复制实例之间可能会存在一些数据复制延迟：

图 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 要求和成本之间做出适当的权衡：

图 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 中：

图 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 实例已准备好，但当前未运行：

图 8.5：试点灯数据复制到灾难恢复站点场景

试点灯场景类似于备份和恢复，您将大部分组件进行备份并被动存储。然而，您为关键组件（如数据库或认证服务器）维护低容量的活动实例，这些组件可能需要较长时间才能启动。您需要根据需要自动启动所有必需的资源，包括网络设置、负载均衡器和虚拟机镜像。由于核心组件已经在运行，因此恢复时间比备份和恢复方法更快。试点灯方法非常具有成本效益，因为您仅以完全容量运行部分资源。

您需要启用所有关键数据到灾难恢复站点（在本例中为 AWS 云）的复制。您可以使用 AWS 数据迁移服务在本地和云数据库之间复制数据。对于基于文件的数据，您可以使用 Amazon File Gateway。

许多其他第三方管理工具提供高效的数据复制解决方案，例如 Attunity、Quest、Syncsort、Alooma 和 JumpMind。

如果主系统发生故障，如下图所示，您可以启动带有最新数据副本的 Amazon EC2 实例。然后，您可以将 Amazon Route 53 重定向到新的 Web 服务器：

图 8.6：试点灯方法中的恢复

对于试点灯方法，在灾难发生时，您需要执行以下步骤：

1. 启动处于待命模式的应用程序和 Web 服务器。此外，通过使用负载均衡器进行水平扩展，扩展应用程序服务器。

2. 垂直扩展运行在低容量的数据库实例。

3. 更新路由器中的 DNS 记录，指向新站点。

在引导灯方法中，你会自动启动围绕复制的核心数据集的资源，并根据需要扩展系统以处理当前流量。引导灯灾难恢复模式相对容易设置且成本低。然而，在这种情况下，RTO（恢复时间目标）需要更长的时间来自动启动替代系统，而 RPO（恢复点目标）则主要取决于复制类型。让我们来探讨下一个方法，热备用，它进一步改善了 RTO 和 RPO。

热备用

热备用，或完全运行的低容量备用，代表了一种通过利用云的灵活性提供成本效益灾难恢复解决方案的先进方法。这种方法通过保持环境服务的子集处于持续运行状态，尽管容量低于完整生产环境，从而增强了基础引导灯策略。

热备用方法的关键优势在于它在成本节约和恢复准备之间取得了平衡。通过让必要的服务已经启动并运行，尽管规模较小，但与冷备用或引导灯策略相比，灾难发生时的恢复时间显著缩短，因为冷备用或引导灯策略在恢复过程中需要配置或扩展资源。

组织可以根据其恢复目标和预算考虑，将热备用环境量身定制为处理其生产流量的特定百分比，如 20%、30% 或 50%。这种灵活性使得灾难恢复解决方案能够根据业务需求和风险承受能力水平进行定制。

此外，热备用环境不仅仅局限于灾难恢复（DR）场景；它还可以通过提供一个非生产环境的平台，如测试、预发布或开发工作，发挥双重作用。这种热备用环境的双重使用通过将基础设施用于除单纯备用外的其他目的，最大化了灾难恢复投资的价值，从而优化了资源利用率和成本效益。

下图展示了两种系统在热备用方法下运行——中央系统和低容量系统——在 AWS 云上。你可以使用像 Amazon Route 53 这样的路由器来分配请求到中央系统和云系统：

图 8.7：热备用场景下，运行一个低容量的活动-活动负载

在数据库方面，热备用采取与引导灯（pilot light）类似的方法，即数据不断从主站点复制到灾难恢复站点。然而，在热备用中，你会全天候运行所有必要的组件，但它们并不会扩展以应对生产流量。

通常，组织会选择热备份策略来处理更关键的工作负载，因此你需要通过持续测试确保灾难恢复站点没有问题。最佳做法是 A/B 测试，其中主站点将处理更多的流量。约 1%到 5%的流量将被路由到灾难恢复站点。这将确保在主站点发生故障时，灾难恢复站点能够提供流量服务。同时，确保定期修补和更新灾难恢复站点上的软件，以保持与生产环境的同步。

如下图所示，在主环境不可用时，路由器会切换到次级系统，次级系统设计为在主系统发生故障时自动扩展其容量：

图 8.8：热备份场景中的恢复阶段

假设主站点发生故障，在这种情况下，你可以采取以下方法：

1. 通过将流量从 5%增加到 100%，立即将关键生产工作负载的流量转移到灾难恢复站点。例如，在银行业务中，你必须首先启动面向客户的网站以保持其正常运行。

2. 扩展低容量运行的环境。你可以对数据库进行垂直扩展，对服务器进行水平扩展。

3. 当你扩展环境时，其他在后台运行的非关键工作负载也可以转移，例如仓库管理和发货。

可用于热备份的工具包括 Terraform，这是一个由 HashiCorp 开发的开源工具，因其能够在各种云提供商之间以安全高效的方式构建、修改和版本化基础设施而闻名。与此同时，Veeam 凭借其提供的全面备份和复制解决方案，在云环境、虚拟环境和物理环境中脱颖而出，确保对多云策略的强大支持。Zerto 进一步补充了这些功能，提供了为虚拟化基础设施和云环境量身定制的灾难恢复、备份和工作负载迁移软件。

热备份灾难恢复（DR）模式相对较复杂且成本较高。关键工作负载的恢复时间目标（RTO）比备用灯模式要快得多。然而，对于非关键工作负载，它取决于你能够多快地扩展系统，而恢复点目标（RPO）则主要取决于复制类型。接下来我们将探讨下一种方法——多站点，它提供近乎零的 RTO 和 RPO。

多站点

最后，多站点策略，也称为热备份，帮助你实现接近零的恢复时间目标（RTO）和恢复点目标（RPO）。通过这种方法，你的灾难恢复站点是主站点的副本，且站点之间进行持续的数据复制和流量流动。由于自动化的流量负载均衡，跨区域或本地与云端之间的流量管理，这种方法被称为多站点架构。

如下图所示，多站点是灾难恢复的下一个层级，具有在云端与本地系统同时运行的完全功能系统：

图 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

第九章：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：

图 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 是资产管理的一个组成部分，用于存储单个资产的配置记录。如下面的图所示，配置管理实现了资产管理的集成和维护部分：

图 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 的示例：

图 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）

• 负载均衡器：在给定时间段内的请求数量

还有许多其他可用的指标，组织需要根据其应用监控需求来定制这些监控指标。以下截图展示了一个网络流量的监控仪表盘示例：

图 9.4：基础设施监控仪表盘

从前面的系统仪表盘可以看到，网络输入平均值面板在某一天出现了峰值，并且对不同的服务器应用了颜色编码。运维团队可以深入分析该图表及其他图表和资源，获取更精细的视图，以确定基础设施的整体健康状况。

应用监控

有时候，除了应用程序由于代码中的某个漏洞或第三方软件问题出现问题之外，基础设施本身是健康的。你可能应用了某个供应商提供的操作系统安全补丁，结果影响了你的应用程序。应用监控可以帮助解决这一问题。

应用监控可能包括以下指标：

• 端点调用：在给定时间段内的请求数量

• 响应时间：完成请求的平均响应时间

• 限制：由于系统无法处理更多请求，导致溢出的有效请求数量

• 错误：应用在响应请求时抛出错误

以下截图展示了一个应用端点监控仪表盘示例：

图 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

上述提到的每个工具都有其自己的指标，您需要监控这些指标，以确保您的应用程序整体健康。以下截图显示了关系数据库平台的监控仪表板：

图 9.6：关系数据库管理系统（RDBMS）的平台监控仪表板

在上述仪表板中，您可以看到数据库有大量写入活动，表明应用程序正在持续写入数据。另一方面，读取事件相对一致，除了某些尖峰情况。

日志监控

传统上，日志监控是一个手动过程，组织在遇到问题时采取反应性方法来分析日志。然而，随着竞争加剧和用户期望不断提高，必须在用户察觉到任何问题之前快速采取行动。为了采取积极的措施，您应该能够将日志流式传输到集中位置，并运行查询以监控和识别问题。例如，如果某个产品页面抛出错误，您需要立即了解错误并修复问题，避免用户投诉；否则，您将遭受收入损失。

在发生任何网络攻击的情况下，您需要分析网络日志并屏蔽可疑的 IP 地址。这些 IP 地址可能会发送大量错误的数据包，导致您的应用程序崩溃。像 AWS CloudWatch、Logstash、Splunk、Google Stackdriver 等监控系统提供了可以安装在应用程序服务器上的代理。该代理会将日志流式传输到集中式存储位置。您可以直接查询集中日志存储，并为任何异常设置警报。

以下截图显示了集中存储的示例网络日志：

图 9.7：原始网络日志流式传输到集中式数据存储

您可以在这些日志中运行查询，找出请求被拒绝次数最多的前 10 个源 IP 地址，如下图所示：

图 9.8：通过运行查询从原始网络日志中获得的洞察

如前面的查询编辑器所示，您可以创建图表并设置警报，如果检测到的拒绝次数超过某个阈值（例如超过 5000 次）。

安全监控

安全是任何应用程序的关键方面。在解决方案设计时应该考虑安全监控。如在第七章《安全考虑》一节中所学，安全需要在所有层面进行应用。建议实施安全监控，以便对任何不利事件进行响应和处理。

以下列表显示了安全监控需要应用的地方：

• 网络安全：监控任何未经授权的端口开放、可疑 IP 地址和活动

• 用户访问：监控任何未经授权的用户访问和可疑的用户活动

• 应用安全：监控任何恶意软件或病毒攻击

• 网络安全：监控 分布式拒绝服务攻击 (DDoS)、SQL 注入或 跨站脚本攻击 (XSS)

• 服务器安全：监控任何安全补丁的漏洞

• 合规性：监控任何合规性漏洞，例如 支付卡行业 (PCI) 对支付应用程序的合规性检查或 健康保险流通与问责法案 (HIPAA) 对医疗应用程序的合规性检查

• 数据安全：监控未授权的数据访问、数据屏蔽以及静态和传输中的数据加密

使用 Amazon GuardDuty 进行 AWS 云安全监控的一个示例如下所示：

图 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 的警报仪表板截图示例：

图 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 数据。

它帮助您发现通过查看单个工具无法发现的问题，并帮助您确定各个系统之间的依赖关系，提供全局视图。

如下图所示，每个系统都有自己的监控工具，帮助获得洞察并维护各个系统组件。对于运营分析，您需要将这些数据汇集到一个集中地点。将所有操作数据收集在一个地方为您提供了一个单一的真实数据源，在这里您可以查询所需数据并运行分析，以获得有意义的洞察：

图 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 环境中的敏感数据。

图 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

第十章：成本考虑

在上一章中，你了解了运营卓越和使用自动化来优化后期生产操作，从而减少人为错误、提高效率，并最终实现成本节约。优化架构的成本是维持高效且可持续 IT 环境的重要方面。这包括理解和管理你的应用所消耗的资源，确保你只为所需的内容付费。在本章中，我们将探讨多种成本优化策略，包括资源的适当配置、选择合适的定价模型以及使用预算和成本管理工具。

每个企业的主要目标之一是提高盈利能力，同时服务客户。项目启动时，成本是一个至关重要的讨论话题。应用程序升级和新产品功能的添加在很大程度上依赖于可用资金。产品的成本是每个人的责任，必须在产品生命周期的每个阶段（从规划到后期生产）加以考虑。本章将帮助你理解优化 IT 解决方案和运营成本的最佳实践。

成本优化是一个持续的过程，需要谨慎管理而不牺牲客户体验。成本优化并不意味着降低成本，而是通过最大化投资回报率（ROI）来降低商业风险。在规划任何成本优化策略之前，你需要了解客户的需求，并据此行动。通常，如果客户追求质量，他们愿意支付更高的价格。

在本章中，你将学习关于你解决方案的成本优化的各种设计原则。成本方面需要在架构的每个阶段和组件中加以考虑。你将理解如何在每一层优化成本的正确技术选择。在本章中，你将学习以下成本优化的最佳实践：

• 成本优化设计原则

• 理解成本优化的技术

• 在公共云中推动成本优化

• 绿色 IT 及其对成本考虑的影响

到本章结束时，你将了解各种优化成本的技术，而不会危及业务敏捷性和成果。你将学会如何监控成本并应用治理来进行成本控制。首先，让我们从成本优化的设计原则开始，这将为构建成本意识架构打下基础。

成本优化设计原则

成本优化包括提高业务价值和最小化风险，同时减少业务成本。你需要通过估算预算和预测支出来规划你的应用成本。为了实现成本节约，你需要实施成本优化计划，并密切监控支出。

有几个原则可以帮助你实现成本优化；常见的设计原则将在以下章节中讨论。你会发现，所有的成本优化设计原则是紧密相关并相互补充的。让我们来看看这些原则。

计算拥有总成本

通常，组织往往忽视拥有总成本（TCO），并基于获取软件和服务的前期成本做出决定，这一成本被称为资本支出（CapEx）。虽然前期成本的确定至关重要，但在长期来看，TCO 才是最重要的。TCO 包括 CapEx 和运营支出（OpEx），涵盖了应用生命周期的各个维度。CapEx 成本指组织为获取服务和软件而支付的前期费用，而 OpEx 包括软件应用的运营、维护、培训和退役成本。在计算长期的 ROI 时，考虑 CapEx 和 OpEx 成本有助于做出更具战略性的决策。

例如，当你购买一台全天候运行的冰箱时，你会关注节能评级以保持电费低廉。你愿意支付更高的前期价格，因为你知道，由于节省电费，随时间推移的总成本会较低。现在，让我们以数据中心为例。数据中心有前期的硬件获取成本（CapEx）。然而，数据中心的搭建还需要额外的持续成本（OpEx），包括供暖、制冷、机架维护、基础设施管理、安全等。

对于典型的使用案例，当你购买并实施软件时，考虑以下成本来计算 TCO：

图 10.1：IT 应用的 TCO

让我们更详细地看看。每个 TCO 组成部分都有以下常见成本，适用于现成软件，例如 Oracle 或 MS SQL 数据库：

现成软件是指预构建的、大规模生产的应用程序，旨在满足具有相似需求的大众群体，而不是为特定业务或用户量身定制的定制软件。

• 购买和设置成本：这些是获取软件和部署服务的前期成本。包括以下内容：

  • 软件成本包括软件购买价格和用户许可证

  • 硬件成本包括购买服务器和存储设备以部署软件

  • 实施成本包括使软件准备好投入生产所需的时间和精力

  • 迁移成本包括将数据迁移到新系统

• 运营和维护成本：这些是持续的成本，用于保持软件在业务使用案例中的正常运行，包括以下内容：

  • 软件维护和支持

  • 修补和更新，软件供应商经常发布这些更新来修复潜在的 bug

  • 定制增强功能，以适应软件对组织需求的要求

  • 数据中心维护硬件服务器的成本

  • 安全性

  • 许可证续订

• 人力资源和培训成本：这些是用于培训员工使用软件以满足业务活动的间接费用。包括以下成本：

  • 应用程序管理员

  • IT 支持人员

  • 功能和技术顾问

  • 培训和培训工具

为了优化成本，您有多种选择，包括订阅软件即服务（SaaS）产品，例如 Salesforce 的客户关系管理（CRM）平台。SaaS 模式通常是按用户订阅的方式，因此需要评估是否达到了预期的成本节省。对于大量用户，您可以采用混合模式，通过选择基础设施即服务（IaaS）选项并安装现成软件，利用云服务来处理硬件。总的来说，如果软件不能满足需求，您可以自己开发。在任何情况下，都要计算 TCO（总拥有成本），以决定在哪些地方实现最大化的投资回报率（ROI）。让我们看看预算和预测的规划，它可以帮助控制总成本并实现 ROI。

预算和预测的规划

每个企业都需要规划开支并计算投资回报率（ROI）。预算规划为组织和团队提供了成本控制的指导。组织制定长期预算，通常为 1 至 5 年，帮助他们根据所需资金来运营业务。预算随后会细化到每个具体项目和应用程序。在解决方案设计和开发过程中，团队需要考虑可用的预算并做相应规划。预算帮助量化业务希望实现的目标，而预测则提供了公司当前实际运营的估算。

预算规划是长期战略规划中非常重要的一部分，预测则提供了一个在更具战术性层面上的估算，帮助决定业务方向。在应用开发和运营中，如果没有预算和预测，企业可能会迅速失去方向并超出预估成本。这两个术语可能会让人困惑，下面我们来澄清预算和预测的区别：

方面	预算	预测
定义	一份详细的财务计划，概述特定时期内预期的收入、支出和资源分配。	基于当前趋势和短期预期的公司财务表现更新预测。
时间框架	通常设置为长期，比如按年度。	更具动态性；定期更新（每月或每季度）。
调整频率	不经常调整，可能一年调整一次，或者在重大变更时进行调整。	根据实际业务进展和短期展望定期更新。
目的	用于指导业务决策、战略规划和资源分配。	用于根据最近的趋势和预测做出知情的操作决策和调整。
性能评估	用于通过比较计划与实际成本和收入来确定性能。	通常不用于对目标进行性能评估，而是用于了解潜在的未来财务状况。
示例	决定组织重组、规划年度营销支出和设定年度销售目标。	根据近期表现调整员工配置、修改营销策略和更新收入预期。

表格 10.1：预算与预测对比

预测信息帮助您立即采取行动，而预算可能因市场变化而变得不可实现。如下面的图示所示，当您在处理日常解决方案时，基于历史支出预测的开发可能会促使您调整下个月的成本：

图 10.2：预测报告

如前所示的成本与使用预测报告所示，如果您的月度预算为$450，您将在 2024 年 11 月底前达到预算。这里，预测帮助您采取行动并控制成本，以保持在预算范围内。

在下一节中，让我们看看通过管理需求和服务来提高成本效率的机制。

管理需求和服务目录

几乎每个组织都有一个集中的 IT 团队，该团队与内部业务合作伙伴（如各业务单元的应用开发和支持团队）合作。IT 团队管理 IT 基础设施的需求，包括所有软件和硬件的成本及应用托管支持的管理。业务合作伙伴通常需要更深入地了解其 IT 服务的成本驱动因素。例如，应用开发团队倾向于过度配置其开发或测试环境，导致额外的成本。

您可以提前从各个组织单元获取需求预测，这有助于您更好地协调整个组织的 IT 基础设施供应。通过将所有需求集中在一个地方，组织可以从规模经济中受益。您可能会通过大型合同实现更高的规模经济，从而获得更低的可变成本。通过将所有组织单元的需求聚合在一起，可以实现更低的价格。

例如，在利用公共云服务如 AWS、GCP 或 Azure 时，企业有机会通过私人定价协议（PPAs）或企业折扣计划（EDPs）获得更有利的定价。这些协议对那些通过将资源集中在单一云服务提供商下，承诺更大工作负载的组织尤其有利。通过承诺一定水平的使用或支出，企业可以谈判更低的价格，从而实现显著的成本节约。

组织可以采取以下两种方法之一来管理需求和服务：

• 需求管理：为了在现有 IT 环境中节省成本（如果你发现过度支出的现象普遍存在），你可以采取以需求为主导的方法。这种方法有助于在短期内提高成本效率，因为你可以引入一些新服务。你可以分析历史数据，了解推动需求的因素，并捕捉过度配置的情况。建立 IT 团队与业务伙伴之间的流程，以精简 IT 服务的运营成本。

• 服务目录管理：如果有对新服务的需求且没有太多历史数据，你可以采取以服务为主导的方法。在这种方法中，你需要了解最常用服务的需求并创建一个目录。例如，假设开发团队请求一台带有 MySQL 数据库的 Linux 服务器来创建开发环境，在这种情况下，IT 团队可以创建一个服务目录，帮助开发团队获取一台小型 Linux 服务器和一台数据库服务器。类似地，IT 团队可以识别最常用的一组服务，并附加一个详细的成本。

每种方法都可以在短期和长期内实现显著的成本节省。然而，这些转型带来了巨大的挑战，因为你需要改变项目规划和审批流程。业务和财务团队需要对齐并理解业务增长与增加的 IT 能力之间的明确关系。成本模型需要围绕最有效的方法构建，通过结合云、内部部署和现成的产品。

跟踪支出

你可以通过跟踪支出并将其与系统或业务所有者关联来找到各个系统的成本。透明的支出数据有助于识别投资回报率（ROI）并奖励所有者，优化资源并降低成本。它可以帮助你确定一个部门或项目的月度成本。

节省成本是共同的责任，你需要有一个机制来让每个人都对其负责。通常，组织会引入展示式回溯（show-back）或费用回溯（charge-back）机制，在组织单元之间分担成本责任。

集中账单账户通过展示式回溯（show-back）方法告知每个组织单元其支出，但不收取实际费用。在费用回溯（charge-back）方法中，组织内的每个业务单元在主支付账户下管理其预算。主账户根据业务单元的月度 IT 资源消耗将费用回溯到各个业务单元。这些方法使得每个组织单元在支出上更具成本意识和责任感。

在为组织实施成本控制时，最好从展示式回溯开始作为踏脚石，然后随着组织模型的发展逐步过渡到费用回溯。

对于每个业务单元，你应该通过配置通知来提高开支意识，使团队在接近预期或预算消费金额时能够收到警报。创建机制，通过将开支合理分配到正确的业务计划，来监控和控制成本。为每个团队提供可见性，以创建对成本开支的责任感。成本追踪将帮助你了解团队的运营。

每个工作负载都是不同的；你应该使用适合你工作负载的定价模型来最小化成本。建立机制，确保通过应用成本优化的最佳实践来实现业务目标。你可以通过定义标签策略，将业务单元与特定开支关联起来，避免超支，并采用制衡方法。

持续的成本优化

如果你遵循成本优化的最佳实践，你应该能够与现有的活动进行良好的成本比较。随着时间的推移，减少迁移和成熟应用的成本是始终可能的。成本优化不应结束，直到识别节省资金机会的成本超过你将节省的金额为止。在达到这个点之前，你应该持续监控开支，并寻找节省成本的新方法。你应该不断寻找通过移除闲置资源来节省成本的机会。例如，考虑一个场景，其中一家公司在其开发、测试和生产环境中使用云服务。通过持续监控其云开支，该公司发现开发环境中的一些实例在非高峰时段依然处于低利用率或闲置状态。为了节省成本，该公司实施了一种计划，在实例未被使用时自动关闭它们，例如在夜间和周末。通过这种方式，它们大大减少了云开支，因为只在资源被积极使用时才支付费用。随着时间的推移，识别和消除闲置资源的做法可以带来显著的成本节省，使公司能够更有效地分配预算。

对于在成本和性能方面平衡的架构，确保为资源支付的费用得到充分利用，避免出现显著低利用率的 IT 资源，如服务器实例。

一个偏倚的利用率指标，如果显示异常高或低的成本，将对你组织的业务造成伤害。当组织在评估利用率指标时未考虑上下文时，可能会导致偏颇的解读和决策。例如，基于电子商务网站如黑色星期五等高峰时期的数据来进行基础设施配置，可能导致严重的资源过度配置。在较为清闲的时段，这会导致资源的严重低利用率，这样是成本低效的。必须在正确的上下文中分析这些指标，以避免此类问题，并确保资源的配置与实际需求一致，而不仅仅是根据高峰或非常规使用期间的需求。这种方法可以避免不必要的支出，支持更具战略性和有效的成本管理。

在考虑应用层面的指标以进行成本优化时需要特别小心。例如，制定归档策略以控制数据存储容量。为了优化数据库，你应该检查是否有适当的数据库部署需求，比如数据库是否需要进行多地部署，或者根据你的数据库利用率需求，是否需要预配置每秒输入/输出操作数（IOPS）。你还可以使用 SaaS 模型帮助员工专注于应用程序和业务活动，从而减少行政和运营的开销。

为了识别差距并实施必要的变更以节省成本，你应该在项目生命周期中实施资源管理和变更控制流程。其目的是帮助你的组织尽可能优化和成本效益地设计架构。不断寻找能够直接减少成本的新服务和新功能。

在本节中，你探讨了旨在优化成本的各种设计原则，从有效的预算规划到积极的成本监控和持续的节省成本策略。这些原则对于确保你的架构不仅满足性能和操作要求，而且与财务目标保持一致至关重要，从而使你的组织能够最大化投资的价值并最小化不必要的开支。让我们学习一些能够帮助你优化成本并提高投资回报率的技巧。

理解成本优化的技巧

企业正在加大对技术的投资，以获取竞争优势并跟上快速增长的步伐。在经济不稳定的情况下，成本优化成为一项既必要又具有挑战性的任务。公司花费大量时间在采购、运营和供应商方面进行研究并降低成本。许多公司甚至共享数据中心、呼叫中心和办公空间，作为节省成本的一种方法。有时，组织需要更多时间进行升级，以避免购买新的、昂贵的硬件。

组织通过审视整个 IT 架构可以节省更多的成本。改善现有架构能够为公司带来更多的机会和业务，即使这需要对预算进行一些调整。让我们确定一些关注领域，通过迁移到云端、简化架构、虚拟化和共享资源等技术帮助公司节省开支并获得更多收入。

降低架构复杂性

组织通常需要一个集中的 IT 架构，导致每个业务单元都试图建立自己的工具集。缺乏整体控制会导致大量重复的系统和数据不一致。个别业务单元的 IT 项目往往是由短期目标驱动的。

在这种情况下，业务单元需要与长期的组织愿景更加对齐，例如整个组织的数字化转型。此外，这也增加了维护和升级这些系统的复杂性。定义标准并避免重复的简单步骤有助于节省成本。

下图展示了左侧的复杂架构，业务单元在没有标准化的情况下各自进行应用，导致了许多依赖关系的重复应用——这种架构会导致高成本和高风险。任何新的实验都需要较长的时间才能投入市场，最终失去竞争优势。流程标准化、可复用架构模式的开发以及一整套共享服务的建立共同提供了一个全面且灵活的框架，支持敏捷环境的运行。通过在该框架内应用自动化，组织可以简化操作，避免重复劳动，并大幅降低成本。这种整体性的方法不仅提升了运营效率，还提高了投资回报率（ROI），展现了架构实践与业务目标之间的战略对齐，以实现最佳的财务表现。

图 10.3：架构标准化

首先需要消除重复，识别业务单元之间的功能复用，从而减少架构复杂性。将所有这些可复用的组件跨组织整合到服务目录中，可以显著提升可访问性和效率。服务目录作为一个集中的存储库，团队可以在其中找到并利用预定义的架构模式、服务和资源。在现有架构的差距分析过程中，你会发现有很多代码、许多现有组件，以及一个可以跨组织重用的项目，以支持你的业务需求。为了减少 IT 架构的复杂性，可以考虑一种符合业务需求并提供 ROI 的现成解决方案。如果没有其他选择，定制化应是最后的选择。

任何新应用都需要有一个可访问的集成机制，以便使用RESTful 架构与现有系统进行交互。统一应用程序的 UI 设计提供了一套标准 UI 包，可以在任何新应用中重用。

同样，其他模块可以通过面向服务的设计进行再利用。你在第四章中学习过 RESTful 模式，解决方案架构设计模式；这些有助于保持不同的软件组件单独运行，同时能够相互通信，构建整个系统。

在模块化方法中，每个团队负责开发一个所有团队都可以使用的服务，以避免重复工作。作为架构师，您应帮助团队创建面向服务的设计，每个团队将各自的架构组件作为服务进行处理，且这些服务可以独立开发。在微服务架构的帮助下，您可以模块化地部署整个应用程序。如果某个组件出现问题，可以重新开发该组件，而不影响整个应用程序。例如，开发一个用于从访问电子商务网站的客户处收款的支付服务，也可以用于在供应商管理系统中支付供应商费用。

一旦你建立了集中化的 IT 架构，采取模块化的方法有助于降低成本。赋能你的 IT 架构团队可以帮助将组织单位与公司的愿景对齐，并支持其他并行项目遵循整体战略。它还帮助提供在其他常被忽视的关键服务中的一致性，如法律、会计和人力资源。

在 IT 架构团队的帮助下，你可以获得优秀的反馈，确保项目与业务需求和要求对齐。通过监督跨团队的整体架构，架构师可以建议是否有重复的工作、项目、流程或系统需要与业务需求对齐。集中化的架构将减少复杂性和技术负担，带来更多的稳定性，并提高质量。集中化架构的整体理念是提高 IT 效率，因此让我们深入了解这一点。

提高 IT 效率

现在，每个公司都在使用和消耗 IT 资源。拥有过多的服务器、笔记本电脑、软件许可证以及高存储容量会消耗大量资金。许可证是有时被低估、未发现、闲置或安装不当的资源，且会消耗大量资金。一个集中的 IT 团队可以领导许可证优化工作，通过跟踪已使用的软件许可证并退役多余的许可证来节省成本。他们还可以通过与供应商谈判批量折扣来节省费用。

为了提高 IT 效率，应取消那些需要额外资金和资源的非合规项目。同时，您还应帮助团队重新审视策略，以支持或持续终止未使用和不对齐的项目。

以下方法可以用于成本优化：

• 重新评估高成本项目，因为它们可能需要更好地与业务愿景对接。重新塑造那些高价值但对 IT 战略没有直接影响的项目。

• 降低那些即使与 IT 战略一致但几乎没有商业价值的项目的优先级。

• 取消低商业价值且不合规的项目。

• 停用或退役不再使用的应用程序。

• 通过现代化替换旧的遗留系统，以降低维护成本。

• 通过重新利用现有应用程序来避免重复项目。

• 在可能的情况下，整合数据并开发集成数据模型。你将在第十二章，解决方案架构的数据工程中了解如何维护集中式数据湖。

• 在组织内整合供应商采购，以节省 IT 支持和维护开支。

• 整合所有执行支付和访问管理相同功能的系统。

• 消除昂贵、浪费和过度配置的项目和支出。

迁移到云端是提高 IT 资源效率和降低成本的一个优秀选择。公共云提供商，如亚马逊网络服务（AWS），提供按需付费模式，这意味着你只需为实际使用的部分付费。例如，开发者的桌面可以在非工作时间和周末关闭，从而将工作空间的成本降低高达70%。

批处理系统只需要启动以处理任务，处理完后可以立即关闭。这就像任何不需要时关闭的电器一样，以节省电费。

应用自动化是提高整体 IT 效率的一个很好的机制。自动化帮助消除昂贵的人力劳动，减少执行日常工作所花费的时间，并避免出错。尽可能自动化，进行服务器配置、监控任务和数据处理。

在决定优化成本时，确保做出合适的权衡以改善结果。举个例子，如果你去一个主题公园，想要玩很多好玩的项目，你会愿意支付更高的价格来感受你的消费价值。为了吸引更多顾客，如果供应商决定通过减少好玩的项目数量来降低价格，你可能会选择去另一个主题公园，因为你追求的是愉快的体验。在这种情况下，竞争者会占据优势并吸引现有客户，而当前的供应商则会失去业务。此时，降低成本带来了商业风险，这不是正确的成本优化方法。

您的目标应该是可衡量的，这些衡量标准应同时关注业务输出和系统成本。量化的指标有助于您了解增加输出和降低成本的影响。组织级和团队级的目标必须与应用程序的最终用户对齐。在组织层面，目标将跨越组织的业务单元。在团队层面，目标则会更加与单个系统对齐。例如，您可以在业务单元级别设定目标：每个季度降低 10%的每交易成本，或每六个月降低 15%。定义目标确保系统在其生命周期中得到改善。让我们来看一下如何应用标准化和治理。

应用标准化和治理

组织需要制定策略来分析不一致性和过度消耗，减少复杂性，定义使用合适且高效系统的指南，并在需要的地方实施流程。创建并实施这些指南将帮助公司开发标准化的基础设施，减少重复项目和复杂性。

要实现治理，您必须在整个组织中设置资源限制。通过实施基础设施即代码（IaC）服务目录，有助于确保团队不会因资源超出分配的容量而过度配置。您应该有一个机制，能够快速理解并采取行动应对业务需求。在应用资源限制和定义更改流程时，考虑资源的创建和退役。

使用 IaC，整个基础设施设置，包括网络、服务器、数据库和应用服务，可以通过像 YAML 或 JSON 这样的编程语言在代码文件中定义。然后，这些文件可以进行版本控制，使团队能够追踪变更、回滚到先前的配置，并在不同环境之间应用相同的配置，确保一致性并减少配置漂移。像 Terraform、AWS CloudFormation 和 Ansible 等流行工具支持 IaC，允许团队定义 IaC 并应用这些定义来创建或更改基础设施。

企业由多个团队运营各种应用程序。这些团队可能隶属于其收入来源内的不同业务单元。确定资源成本对于应用程序、业务单元或团队有助于推动高效的使用行为，并帮助降低成本。您可以根据成本归属以及小组、组织单元或部门的需求定义资源容量。您可以使用资源标签和账户结构来组织成本结构。

如下图所示，您可以将账户组织到不同的组织单元（OUs）中，例如人力资源（HR）和财务（Finance），而每个组织单元下的部门可以拥有自己的账户。例如，在此，人力资源有单独的账户用于薪资和市场营销，而财务则有单独的账户用于销售和市场营销：

图 10.4：面向组织单位的企业账户结构

你可以在前述账户结构策略中控制每个业务单元和部门层级的成本。为每个部门采用费用追溯机制可以在更精细的层级增加对成本的问责制，从而有助于优化成本。

账户结构帮助你在整个组织中应用高安全性和合规性标准。由于每个账户都与父账户关联，你可以通过合并整个组织的支出来显著处理供应商资源的大规模使用。

资源成本标签

几乎每个公共云服务提供商都提供开箱即用的标签功能。你可以嵌入服务器元数据，如 DNS 名称或主机名，适用于本地部署。标签有助于你组织成本，并定义容量限制、安全性和合规性。它是库存管理的一个优秀工具，能够随时关注组织各级对资源日益增长的需求。

资源标签是管理和优化云计算环境中成本的强大策略。它涉及将元数据标签分配给云资源，如虚拟机、存储实例或数据库，以根据项目、环境、部门或成本中心等不同标准对其进行分类和跟踪。

如下图所示，为了实现跨资源的完整成本可视化和合并，你可以在团队层级为每个资源添加标签，从而提供更精细的控制：

图 10.5：用于成本可视化的资源标签

在上面的示意图中，你可以看到标签策略，显示给定的服务器是用于应用部署的，并且由开发团队使用。财务业务单元的市场营销部门拥有这台服务器。通过这种方式，组织可以获得精细化的成本支出可视化，团队在支出上会更加节俭。然而，你可以在团队层级采用“展示式”机制，在部门和业务单元层级采用“费用追溯”机制。

你可以定义标签机制，其中可以为任何资源附加名称和值，如资源名称和拥有者名称。以下截图展示了按 aws:createdBy 标签排序的成本，这有助于确定 AWS 自动创建的每个资源的成本：

图 10.6：成本标签的资源支出仪表盘

商业领导者应评估整体需求，以创建高效的 IT 架构。需要协作来开发健全的 IT 架构，并在各职能团队之间定义治理框架，以建立问责机制。同时，还应建立标准来审查架构，为任何新项目倡议创建基准，并解释过程以确保系统符合正确的架构，并识别改进路径。

让所有受影响的利益相关者参与到使用和成本讨论中。首席财务官（CFO）和应用程序所有者必须了解资源消耗和购买选项。部门负责人必须了解整体商业模式和每月账单流程。这将帮助为业务单元和整个公司设定方向。

确保第三方供应商与你的财务目标保持一致，并能够调整其参与模式。供应商应提供其拥有和开发的任何应用程序的成本分析。组织内的每个团队都应能够将管理层的业务、成本和使用因素转化为系统调整，帮助应用程序实施并实现公司的预期目标。

监控成本使用和报告

准确的成本因素帮助你确定业务单元和产品的盈利能力。成本追踪帮助你将资源分配到合适的地方，从而提高投资回报率（ROI）。理解成本驱动因素有助于你控制业务支出。

为了优化成本，你必须了解组织内的支出模式。你需要洞察 IT 支出的历史变化，以确定节省成本的机会。通过创建成本趋势的可视化报告，你可以采取必要的优化措施，并了解其影响，报告将显示按资源和部门划分的历史成本和预测数据。

你的团队需要通过记录所有数据点来收集数据，使用监控工具进行分析，并创建可视化报告。

你需要详细了解工作负载资源的使用情况，以识别节省成本的机会。成本优化依赖于你预测未来支出的能力，并实施方法使成本和使用情况与预测对齐。以下是你应该在数据可视化方面关注的主要领域：

• 确定资源的最重大投资

• 分析并了解你的支出和使用数据

• 预算和预测

• 当你超过预算或预测的阈值时，接收警报

以下报告显示了 AWS 在六个月内的资源支出。可视化图表显示，云计算服务器EC2（在每个月的第五根橙色条形图中表示）从 2023 年 5 月至 2023 年 7 月期间消耗了最高的成本。由于业务单元能够看到持续高成本，系统管理员被提示深入查看成本优化并寻找空闲资源。管理员通过停止这些 EC2 服务器进行了清理，从而在 8 月降低了成本，并从 9 月起完全消除了该成本：

图 10.7：按服务分类的资源成本和使用报告

前述报告帮助业务负责人了解成本模式，并采取反应式成本控制方法。反应式方法导致了隐藏成本，这些成本在特定时间内未被发现。通过主动方法，预测帮助业务负责人提前做出决策。

以下报告展示了用实心条表示的每月成本支出和用空心条表示的预测支出以及估算范围。通过查看报告，你可以看到未来几个月成本可能增加，进而可以采取措施理解成本属性并控制成本：

图 10.8：成本趋势和成本预测报告

监控成本与预算的对比可以为你提供另一个主动控制成本的手段。当支出达到预算的某个比例（如 50%或 80%）时设置警报，有助于你审查并调整持续的成本。

在以下报告中，你可以直观地判断当前成本与预算成本的对比，预算成本在一年前很高。根据以下报告，IT 管理员可以采取措施优化成本，并将其控制在月度预算范围内。

图 10.9：成本和预算报告

成本和预算报告通过采取主动行动帮助你控制成本。将实际运行成本与预算和预测结合起来，为你提供了每日成本控制的极大帮助。

你还可以在实际成本达到预算或预测中的某个阈值时设置警报，这样可以通过电子邮件或短信主动提醒你采取措施控制成本。

以下截图显示，当估算成本超过$500 时，已经设置了警报。你可以设置多个警报，获取当成本达到例如$300 或$400 时的通知：

图 10.10：基于实际成本的警报

控制成本的一种方式是通过资源监控对环境进行调整，并触发过度或不足利用的警报。可以使用Splunk或CloudWatch等监控工具以及自定义日志来进行资源分析，通过监控系统的应用内存利用率等自定义指标来执行调整规模。低资源利用率可以作为识别成本优化机会的标准。例如，CPU 利用率、RAM 利用率、网络带宽和应用程序的连接数可以进行分析和监控。

在调整环境规模时，必须小心确保不会影响客户体验。以下是执行调整规模时应遵循的最佳实践：

• 确保监控反映终端用户的体验。选择正确的时间段。例如，性能指标应涵盖 99%的用户请求响应时间，而不是取平均响应时间。

• 选择正确的监控周期，如每小时、每天或每周。例如，如果你每天进行分析，可能会错过每周或每月的高使用周期，导致系统配置不足。

• 评估变更的成本与节省成本的对比。例如，你可能需要进行额外的测试或调用资源进行尺寸调整。这种成本效益分析将帮助你合理分配资源。

• 根据业务需求识别应用程序的使用情况。例如，查看预计在本月底或高峰季节期间会有多少用户请求。识别并优化利用差距可以帮助节省成本。为此，使用适当的工具，涵盖从节省成本到系统利用率，再到由于变更对客户体验的影响的各个维度，然后利用报告来了解因成本变化而对业务 ROI 的影响。公有云遵循不同的成本模型，通常是按需付费的结构。

在使用云资源时必须非常谨慎，因为每一秒钟都会计入成本，如果忽视了成本优化和监控，可能会造成高昂费用。让我们深入了解公有云中的成本优化。

推动公有云中的成本优化

公有云，如AWS、Microsoft Azure和 GCP，提供了出色的成本优化，采用按需付费模型。此模型允许客户用变动费用替代资本支出，按使用量支付 IT 资源费用。由于规模经济，运营支出通常较低。处于云环境中，并受益于持续的价格下降，通常是具有成本效益的。另一个优势是，你可以立即使用云服务提供商如 AWS 所提供的额外工具和功能，从而帮助你提高敏捷性。

在定义云成本结构模型时，你需要一种不同的思维方式，因为它不同于大多数企业几十年来遵循的传统成本模型。云中有你触手可及的所有基础设施，这要求你进行更大的控制和规范化。云提供了多种成本治理和常规化工具。例如，在 AWS 中，你可以为每个账户设置服务限制，以防开发团队使用超过 10 台服务器，而生产环境可以根据需要设置服务器和数据库的数量，并留有缓冲空间。

所有资源都与云中的账户关联，因此可以轻松地在一个地方跟踪 IT 资源的库存并监控其使用情况。除此之外，你还可以获得跨多个 IT 资源收集数据并提供建议的工具。如以下截图所示，AWS Trusted Advisor会遍历账户中的所有资源，并根据资源使用情况提供节省成本的建议：

图 10.11：AWS Trusted Advisor 的节省成本建议

在前面的截图中，AWS Trusted Advisor 发现一个闲置的负载均衡器，并建议关闭它，以节省每月最高达 40 美元的成本。进一步检查发现一个 Lambda 函数的错误率较高，需修复该函数以减少成本。

云计算可以为节省成本提供出色的价值主张。首先，你可以创建一个混合云，通过在本地数据中心和云之间建立连接，来实现资源共享。你可以将开发和测试服务器迁移到云端，以便确定成本结构和潜在的节省空间。一旦在云中建立了成本治理，就可以根据成本效益分析，迁移更多的工作负载。不过，你需要评估自己的工作负载，并判断它是否适合迁移到云端，如果适合的话，还需制定相应的策略。你在第三章，云迁移与混合云架构设计中学习过云迁移。

越来越多的公有云提供商提供托管服务，消除了基础设施维护成本以及告警和监控配置的管理开销。托管服务通过减少服务采用过程中成本，从而降低总拥有成本。

公有云提供储蓄计划或预留实例，允许组织承诺一定的使用量，以换取比按需计费更低的价格。通过分析资源使用数据，组织可以做出明智的决策，购买这些计划，并根据实际使用模式来调整承诺，从而最大化成本节省。

将储蓄计划纳入云成本优化策略，能够帮助组织在灵活性和成本效益之间找到平衡。它们可以保留按需付费模式在处理变化工作负载时的敏捷性，同时通过储蓄计划在处理可预测、稳定的使用时获得成本节约，从而确保有效优化云支出。

绿色 IT 指的是计算机及其资源的环保使用。它包括减少能源消耗、减少电子废料以及设计低能耗的数据中心等实践。让我们深入了解它。

绿色 IT 及其对成本考虑的影响

绿色 IT，也称为绿色计算，指的是环境可持续的计算或 IT。它是使用计算机和 IT 资源的效率更高、更加环保的研究和实践。绿色 IT 实践可以通过多种方式显著影响成本考虑：

• 能源效率：利用高效能的硬件和实践可以减少数据中心和 IT 基础设施的电力消耗，从而显著节省电费。例如，使用能源之星认证的设备或优化数据中心的布局以提高冷却效率，可以降低能源账单。

• 虚拟化：虚拟化服务器和存储可以减少对物理硬件的需求，从而降低能源消耗和冷却成本，并最小化数据中心所需的空间。

• 云计算：迁移到云服务相比维护本地数据中心可能更加节能。云服务提供商通常拥有规模经济效应，并且拥有更现代、高效和环保的数据中心。这可以转化为较低的电力和冷却成本，并减少碳足迹。

• 硬件回收与再利用：正确的 IT 设备回收和再利用可以节省成本。公司可以通过回收或出售旧设备来收回部分初期投资。此外，购买翻新硬件比购买全新的硬件要便宜得多。

• 远程办公：推广远程工作减少了对办公空间的需求、能源消耗和员工通勤成本。这不仅为组织和员工带来直接和间接的成本节省，同时也有益于环境。

• 电子文档管理：通过电子文档管理系统减少纸张使用，可以节省纸张、打印和存储成本，同时带来减少纸张浪费的环境效益。

• 可持续 IT 采购：选择优先考虑可持续性的供应商和产品可以带来长期的成本节省。设计更加耐用或具有更长保修期的产品可能有更高的初期成本，但随着时间的推移，其总拥有成本较低。

• 维护优化：定期维护和更新可以延长 IT 设备的使用寿命，推迟昂贵的替换需求，并减少电子废弃物。

• IT 资产处置：高效管理 IT 资产处置可以降低废物管理成本，并确保符合环保法规，避免潜在的罚款。

• 碳信用：通过绿色 IT 实践减少碳排放，组织可以获得碳信用，这些信用可以出售或交易，提供潜在的收入来源或碳税节省。

绿色 IT 通过减少能源消耗、最小化废物、优化设备使用和提高整体可持续性，能够为组织带来显著的成本节省。这些节省通常能抵消实施绿色 IT 计划所需的初期投资。让我们看看像 AWS 这样的云服务提供商如何帮助改善你的绿色 IT 态度。

在 AWS 上进行具有成本效益且环保的应用托管

一个涉及 AWS 的绿色 IT 使用案例可能会集中在利用 AWS 的云基础设施来实现环境和成本效益。AWS 提供了支持绿色 IT 计划的服务，如无服务器架构、能源高效的数据中心和资源优化工具。AWS 一直积极支持绿色 IT 和可持续性目标，通过各种计划和服务帮助客户减少碳足迹并优化能源使用。

AWS 启动了一个客户碳足迹工具，如下图所示。该工具提供了历史碳排放数据的可视化、AWS 使用过程中碳排放趋势、使用 AWS 替代本地数据中心所避免的碳排放量，以及基于当前使用情况的预测碳排放量。

图 10.12：碳足迹报告

上述报告显示了过去两年的碳足迹，包括碳排放消耗和节省情况。随着 AWS 计划到 2025 年实现 100% 可再生能源，并在 2040 年实现碳中和，碳足迹将发生变化。

AWS 已经建立了关于构建可持续架构的全面指导。你可以通过访问 AWS Well-Architected Framework 的可持续性支柱页面来获取更多细节：docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html。

假设你计划部署一个预期会有不稳定流量的新 web 应用。你可以通过以下步骤，旨在优化成本并遵循绿色 IT 原则：

1. 规划与设计：

   • 由于 AWS 致力于可持续性并且其基础设施具有能源效率，公司决定使用 AWS。

   • 他们选择了使用 AWS Lambda 进行计算的无服务器架构，这使得他们能够在不配置或管理服务器的情况下运行代码。这一选择具有成本效益并且环保，因为它消除了对未充分利用服务器的需求。

2. 实施：

   • Web 应用程序的前端通过 Amazon S3 托管，并通过 Amazon CloudFront 在全球交付，减少了延迟并通过使用靠近用户位置的能源高效数据中心来提供视频和图像等内容，从而最小化了为最终用户提供服务所需的能源。

   • 应用程序的后端基于 AWS Lambda 和 Amazon DynamoDB 构建，提供了一个无服务器数据库解决方案，可以自动扩展以适应工作负载。

3. 优化：

   • 为了实现持续集成和部署，使用了 AWS CodePipeline 和 AWS CodeBuild，这有助于避免维护专用构建服务器的额外开销。

4. 监控与管理：

   • AWS CloudWatch 监控应用程序的性能和资源利用率，确保高效运行。

   • 应用 AWS Trusted Advisor 的建议，以进一步优化成本并确保公司使用最有效的资源。

5. 成本管理：

   • 公司使用 AWS 预算设置成本阈值，并在其成本可能超过预算时收到警报，从而使其能够主动调整使用情况。

   • 他们使用 AWS 成本探索器来分析和了解他们的 AWS 支出和使用情况，从而确保持续的成本优化。

公司通过利用 AWS 的无服务器服务和资源优化工具，成功地部署了可扩展且具有成本效益的 Web 应用程序。他们通过利用 AWS 节能的全球基础设施，仅在需要时消耗计算能力，遵循绿色 IT 原则，从而减少了碳足迹。此外，AWS 服务的按需定价模型确保他们仅为所消费的资源付费，优化了成本和能源使用。

AWS 可以促进绿色 IT 实践，允许您部署一个可扩展的高性能 Web 应用程序，同时关注环境影响和运营成本。AWS 的无服务器产品和高效的资源管理与公司成本优化和可持续发展的目标相一致。

总结

成本优化是一个持续的努力，从应用程序的开始（从概念验证到实施和生产后）就要进行。您需要不断审视架构和节省成本的努力。

在本章中，您了解了优化成本的各种设计原则。在做出任何采购决策之前，您应该考虑整个软件或硬件生命周期的总拥有成本。预算规划和跟踪预测帮助您保持成本优化的路径。始终跟踪支出，并通过管理需求在不影响用户体验或业务价值的情况下寻找持续成本优化的机会。

您学习了各种成本优化技术，包括通过简化企业架构来减少架构复杂性，并设定一个所有人都能遵循的标准。建议通过识别和整合闲置和重复资源来避免重复，并谈判批量采购成本。将在整个组织中应用标准化，以限制资源提供并开发标准架构。通过跟踪实际成本与预算和预测的对比，您可以采取主动措施。您了解了可以帮助控制成本的各种报告和警报。您还了解了云中的成本优化，这有助于您进一步优化价值。可持续性是当今 IT 工作负载的一个重要方面，您了解了绿色 IT 如何影响成本考虑。您还了解了如何使用 AWS 建立和跟踪绿色 IT 消耗。

自动化和敏捷性是提高资源效率的主要因素，而 DevOps 可以提供大量的自动化功能。在下一章中，您将学习到各种 DevOps 组件和策略，以最自动化的方式高效地部署工作负载。

加入我们书籍的 Discord 空间

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

第十一章：DevOps 和解决方案架构框架

在上一章中，你探索了如何创建一个关注成本的架构，并通过不断优化成本而不妥协性能。自动化和团队之间的协作对于开发强健的应用程序和节省成本至关重要。本章将深入探讨 DevOps，一种促进开发和运维团队协作的方式，同时自动化应用程序部署和监控的过程。

在传统环境中，开发团队和 IT 运维团队各自为政。开发团队从业务负责人那里收集需求并开发应用程序。系统管理员则单独负责操作和满足正常运行时间要求。这些团队在开发生命周期中通常很少进行直接沟通，每个团队也很少理解其他团队的流程和需求。

每个团队都有自己的工具、流程和冗余方法，有时会导致冲突。例如，开发团队和质量保证（QA）团队可能会在特定的 操作系统（OS）补丁上测试构建。然而，运维团队将相同的构建部署到生产环境中的不同操作系统版本上，导致问题和交付延误。

DevOps 是一种方法论，旨在促进开发团队和运维团队之间的协作与协调，以持续交付产品或服务。这种方法在那些依赖于多个应用程序、工具、技术、平台、数据库、设备等的组织中，具有重要意义，尤其是在开发或交付产品或服务的过程中。虽然 DevOps 文化有不同的实践方式，但其核心目标是一致的。DevOps 旨在通过共享责任来提高运营效率，从而以最短时间交付产品或服务。

安全性是任何应用程序的首要任务，安全事件可能对业务造成严重影响。尽管如此，安全性在部署过程中往往被忽视，通常作为一个独立的问题，由组织内部的专业安全团队进行被动处理。

将安全性嵌入到 DevOps 过程中的关键方面，可以通过实施 DevSecOps 来实现。DevSecOps 是将安全性早期且贯穿整个软件开发生命周期的一部分，从而打破信息孤岛，促进开发、运维和安全团队之间的协作。DevSecOps 帮助在不妥协质量、可靠性、稳定性、韧性或安全性的情况下交付产品。

本章将介绍以下 DevOps 主题：

• 介绍 DevOps

• 理解 DevOps 的组成部分

• 持续集成/持续部署（CI/CD）

• 在安全领域介绍 DevSecOps

• 将 DevSecOps 和 CI/CD 结合

• 实施 CD 策略

• 在 CI/CD 流水线中实施持续测试

• 使用 DevOps 工具进行 CI/CD

• 实施 DevOps 最佳实践

• 在云中构建 DevOps 和 DevSecOps

到本章结束时，你将了解 DevOps 在应用部署、测试和安全中的重要性。你还将学习 DevOps 和 DevSecOps 的最佳实践以及它们的不同实施工具和技术。

引入 DevOps

在 DevOps（即 开发与运维）方法中，开发与运维团队在软件开发生命周期的构建与部署阶段协作，共享责任并提供持续反馈。在构建阶段，软件构建会在类似生产环境中频繁测试，从而实现缺陷的早期发现。

DevOps 是文化与实践的结合。它要求组织通过打破产品开发和交付生命周期中各个团队之间的壁垒来改变其文化。DevOps 不仅仅关乎开发和运维，它涉及到整个组织，包括管理层、业务/应用所有者、开发人员、QA 工程师、发布经理、运维团队和系统管理员。

高速度使得组织能够保持领先于竞争对手，并快速响应客户需求。良好的 DevOps 实践鼓励软件开发工程师与运维专业人员更好地合作。这导致了更加紧密的协作与沟通，从而缩短了 上市时间，确保了可靠的发布，提高了代码质量，并改善了维护工作。

有时在 DevOps 中，你会发现软件应用的开发和运维由同一个团队处理，工程师会贯穿整个应用生命周期工作。这样的团队需要培养一系列不局限于单一职能的技能。应用测试和安全团队也可能会在应用的创建到生产发布的整个过程中与开发和运维团队更紧密地合作。

开发人员受益于运维团队提供的反馈，并制定测试和部署策略。

系统管理员不必在生产环境中部署有缺陷或未经测试的软件，因为他们参与了 构建阶段。随着所有软件开发与交付生命周期的利益相关者共同协作，他们还可以在每个步骤中评估计划使用的工具，验证设备之间的兼容性，并判断是否有任何工具可以跨团队共享。

DevOps 正在成为一种日益流行的操作文化，特别适用于那些利用云计算或分布式计算技术的组织。让我们了解一下 DevOps 的一些主要好处，以及它为何对你的应用工作负载至关重要。

了解 DevOps 的好处

DevOps 的目标是实现 CI/CD 模型，利用该模型使软件开发生命周期变得可重复、可靠、稳定、弹性强且安全。这些模型特性有助于提高操作效率。为了实现这一目标，团队必须在开发和交付过程中进行协作与参与。所有技术团队成员应具备开发流水线中涉及的过程和工具经验。

一个成熟的 DevOps 过程提供了许多好处，如下图所示：

图 11.1：DevOps 的好处

DevOps 提供的好处在这里有详细说明：

• 速度：更快地发布产品功能有助于适应客户不断变化的业务需求，并扩大市场份额。DevOps 模型使组织能够更快地取得成果。

• 快速交付：DevOps 过程通过自动化端到端的流水线，提高效率，从代码构建到代码部署再到生产上线。快速交付帮助你更快地进行创新。更快的 bug 修复和功能发布让你能获得竞争优势。

• 可靠性：DevOps 过程提供检查，以确保交付质量和快速应用更新的安全性。像 CI 和 CD 这样的 DevOps 实践嵌入了自动化测试和安全检查，以确保用户体验良好。

• 可扩展性：DevOps 通过在各个环节中引入自动化，帮助按需扩展你的基础设施和应用。

• 协作：DevOps 模型建立了一种所有权文化，团队考虑自己的行动。运维团队和开发团队在共享责任模型中共同工作。协作简化了过程，提高了效率。

• 安全性：在敏捷环境中，频繁的变化需要严格的安全检查。DevOps 模型自动化了安全和合规性最佳实践，监控这些实践，并以自动化方式采取纠正措施。

团队对其交付的服务承担完全责任，通常超出传统角色的范围，并从客户角度思考，解决任何问题。让我们深入了解 DevOps 过程的不同组件。

了解 DevOps 的组件

DevOps 工具和自动化将开发与系统运维结合在一起。以下是 DevOps 实践中的关键组件：

• CI/CD

• 持续监控和改进

• 基础设施即代码

• 配置管理

所有元素中的一个常见最佳实践是自动化。自动化可以包括脚本、模板和其他工具。在一个蓬勃发展的 DevOps 环境中，基础设施以代码形式进行管理。自动化使 DevOps 团队能够快速搭建和调整测试与生产环境。让我们深入了解每个组件的更多细节。

持续集成/持续部署

在CI中，开发者频繁地将代码提交到代码库。代码会频繁地进行构建。每次构建都会使用自动化单元测试和集成测试进行测试。在CD中，你会进一步操作，频繁地将代码部署到生产环境中。构建被部署到测试环境中，并通过自动化或手动测试进行验证。成功的构建通过测试后，会部署到预发布或生产环境中。

下图说明了 CI 与 CD 在软件开发生命周期中的影响：

图 11.2：CI/CD

如前图所示，CI 指的是软件开发生命周期中的构建和单元测试阶段。每次提交到代码库的更新都会触发自动构建和测试。CD 是 CI 的重要组成部分，它将 CI 过程扩展到将构建部署到生产环境中。在 CI/CD 实践中，多个开发者共同参与代码开发，他们都必须使用最新的工作版本进行开发。代码库保持不同版本的代码，并使团队能够访问这些代码。你从代码库中检出代码，进行更改，在本地副本中编写新代码，编译和测试代码，并频繁地将代码提交回主代码库。在 CI/CD 中，代码、构建、部署和测试等软件开发生命周期阶段是通过 DevOps 管道自动化的。

CI 自动化了大部分软件发布过程。它创建了一个自动化流程，完成构建、测试和更新的准备工作。然而，开发者仍然需要触发最终的部署到实时生产环境，这一过程是不可自动化的。CD 通过在构建阶段之后，将所有代码更改部署到测试和/或生产环境，进一步扩展了 CI 的功能。如果 CD 正确实施，开发者将始终拥有经过测试且准备好部署的构建版本。

下图展示了与应用程序自动化相关的所有内容，从代码提交到代码库，再到部署管道。它展示了从构建到生产环境的端到端流程，开发者将代码更改提交到代码库，CI 服务器从中拉取代码。CI 服务器触发构建，生成一个包含新应用程序二进制文件和相应依赖项的部署包。这些新的二进制文件被部署到目标开发或测试环境中。二进制文件还被提交到构件库中，以进行版本控制和安全存储：

图 11.3：CI/CD 与 DevOps

强大的 CD 流水线还可以自动化测试和生产环境的基础设施配置，并使测试和生产环境的监控与管理成为可能。CD 并不意味着开发者提交的每个更改都进入生产环境。而是意味着每个更改都已准备好进入生产环境。当更改在阶段环境中进行预部署和测试时，手动审批流程会启动，并给出绿色信号进行生产部署。因此，在 CD 中，部署到生产环境成为了一个商业决策，且仍然是自动化的工具。

持续监控与改进

持续监控帮助我们理解应用程序和基础设施的性能对客户的影响。通过分析数据和日志，你可以了解代码更改如何影响用户。主动监控在 24/7 服务和不断更新应用程序及基础设施的时代变得至关重要。

你可以通过创建警报并进行实时分析来主动监控服务。你可以跟踪各种指标，以监控并改进你的 DevOps 实践。

以下是与 DevOps 相关的指标示例：

• 变更量：这是开发的用户故事数量、新代码的行数和修复的 bug 数量。

• 部署频率：这表示团队部署应用程序的频率。这个指标通常应该保持稳定或呈上升趋势。

• 从开发到部署的交付时间：从开发周期开始到部署结束的时间可以用来识别发布周期中间步骤的低效之处。

• 失败部署的百分比：失败部署的百分比，包括导致故障的部署次数，应该保持在较低水平。

• 这个指标应该与变更量一起审查。如果变更量较低，但失败的部署次数较高，应分析潜在的失败点。

• 可用性：跟踪导致故障的发布，可能会导致违反服务级别协议（SLA）的情况。应用程序的平均停机时间是多少？

• 客户投诉量：客户提交的投诉工单数量表明了应用程序的质量。

• 用户量变化百分比：新用户注册使用你的应用程序的数量以及随之而来的流量增加，可以帮助你扩展基础设施以匹配工作负载。

在将部署构建到生产环境后，监控应用程序的性能至关重要。正如我们讨论的自动化环境一样，让我们详细探讨一下基础设施即代码（IaC）。

基础设施即代码

提供、管理甚至废弃基础设施在人工成本上是一项昂贵的活动。此外，通过反复尝试手动构建和修改环境，可能会出现错误。无论是基于以往经验还是一本详细的运行手册，人类犯错的倾向始终是一个统计概率。

我们可以通过自动化任务来创建完整的环境。任务自动化有助于完成重复性任务，并能毫不费力地提供显著价值。

使用 IaC，我们可以以 模板 的形式定义基础设施。一个模板可以包含部分或整个环境。更重要的是，这个模板可以反复使用，以便再次创建相同的环境。

在 IaC 中，基础设施是通过代码进行创建和管理的。IaC 模型帮助你以编程方式与基础设施互动，并通过自动化资源配置避免人为错误。这样，你就可以像使用代码一样使用代码工具来处理基础设施。由于基础设施是通过代码管理的，应用程序可以使用标准化方法进行部署，任何补丁和版本都可以反复更新且不会出错。

一些最受欢迎的基础设施即代码（IaC）脚本工具包括 Ansible、Terraform、Azure 资源管理器、Google Cloud 部署管理器、Chef、Puppet、AWS 云开发工具包（CDK）和 AWS CloudFormation。

以下是来自 AWS CloudFormation 的代码示例，它提供了 IaC 功能，可以自动化 AWS 云平台上的基础设施。

`AWSTemplateFormatVersion: '2010-09-09' Description: 'Create an S3 Storage with a parameter to choose own bucket name.' Parameters: S3NameParam: Type: String Default: 'architect-book-storage' Description: 'Enter the S3 Bucket Name' MinLength: '5' MaxLength: '30' Resources: Bucket: Type: 'AWS::S3::Bucket' DeletionPolicy: Retain Properties: AccessControl: Private BucketName: Ref: S3NameParam Tags: - Key: 'Name' Value: 'MyBucket' Outputs: BucketName: Description: 'BucketName' Value: Ref: S3NameParam` 

上述代码创建了 Amazon S3 对象存储，并为用户提供了存储名称的选项，具体如下所示：

图 11.4：使用 AWS CloudFormation 的 IaC

执行代码后，Amazon S3 桶会被创建，正如在资源中看到的：

图 11.5：使用 AWS CloudFormation 自动化创建 AWS S3 对象存储

多个团队可以使用提供的代码创建任意数量的 Amazon S3 存储。由于数据至关重要，管理员选择添加 "DeletionPolicy": "Retain," 来确保当基础设施关闭时存储不会被删除，数据也得到了保护。

你可以看到如何使用 IaC 在组织中实现标准化、一致性和合规性。配置管理是 DevOps 过程中的另一个重要方面。让我们进一步了解它。

配置管理

配置管理（CM）是通过自动化的方式，标准化整个基础设施和应用程序的资源配置的过程。像 Chef、Puppet 和 Ansible 这样的 CM 工具可以帮助你管理 IaC 并自动化大部分系统管理任务，包括资源的提供、配置和管理。

通过自动化和标准化开发、构建、测试和部署阶段的资源配置，你可以确保一致性并消除因配置错误导致的故障。配置管理（CM）还可以通过允许你通过一键操作将相同的配置自动部署到数百台服务器，来提高运营效率。CM 还可以用于部署配置更改。

尽管你可以使用注册表设置或数据库来存储系统配置设置，CM 应用程序还允许你在存储之外进行版本控制。CM 也是一种跟踪和审计配置更改的方法。如果需要，你甚至可以为不同的软件版本维护多个配置设置版本。

CM 工具包括一个控制机来管理服务器节点。例如，Chef 需要在每台服务器上安装客户端代理应用程序进行管理，并且在控制机上安装主 Chef 应用程序。Puppet 也以类似方式工作，通过一个集中的服务器。然而，Ansible 采用去中心化的方法，不需要在服务器节点上安装代理软件。

下表展示了各类流行的配置管理工具之间的高层次对比：

	Ansible	Puppet	Chef
机制	控制机通过安全外壳协议（SSH）将更改应用到服务器	主机将更改同步到 Puppet 节点	Chef 工作站寻找 Chef 服务器中的更改并将其推送到 Chef 节点。
架构	任何服务器都可以是控制机	由 Puppet 主机进行集中控制	由 Chef 服务器进行集中控制
脚本语言	YAML	Ruby 中的特定领域语言	Ruby
脚本术语	Playbook 和角色	Manifests 和模块	配方和食谱
测试执行	顺序执行	非顺序执行	顺序执行

表 11.1 – 流行 CM 工具对比表

CM 工具提供了一个特定领域的语言和一组自动化功能。其中一些工具有陡峭的学习曲线，团队需要学习如何使用这些工具。AWS 提供了一个名为 OpsWorks 的托管平台，用于在云中管理 Chef 和 Puppet。它提供了多种属性来通过自动化管理 IT 基础设施，如下所示：

图 11.6: AWS OpsWorks 服务在管理 Chef 和 Puppet 中的功能

安全性已经成为任何组织的优先事项，因此完全的安全自动化是当务之急。组织正在转向严格的安全实施和监控，以避免人为错误，采用被广泛称为DevSecOps的 DevOps 流程。在下一节中，让我们一起探讨 DevSecOps（即 开发、安全和运营 的缩写）。

引入 DevSecOps 以增强安全性

我们现在比以往任何时候都更加关注安全。在许多情况下，安全是赢得客户信任的唯一途径。DevSecOps 旨在实现安全的自动化，并大规模地实施安全。开发团队不断进行更改，DevOps 团队将这些更改发布到生产环境中（这些更改通常面向客户）。DevSecOps 确保在整个过程中应用程序的安全性。

DevSecOps 不是用来审计代码或 CI/CD 工件的。组织应该实施 DevSecOps 以提高速度和敏捷性，但前提是不能以牺牲安全性为代价，因为安全验证会拖慢开发和部署过程。自动化的力量在于提高产品功能发布的敏捷性，同时实施所需的安全措施。DevSecOps 方法带来了内建的安全性；安全性不是事后才加上的。DevOps 旨在提高效率，以加速产品发布生命周期，而 DevSecOps 则验证所有构建模块，而不会拖慢生命周期。

要在组织中建立 DevSecOps 方法，首先要在开发环境中建立一个坚实的 DevOps 基础，因为安全是每个人的责任。从一开始就将安全嵌入架构设计中，以便在开发和安全团队之间创造协作关系，是最理想的做法。自动化持续的安全测试，并将其纳入 CI/CD 管道，以避免任何安全漏洞。为了跟踪任何安全漏洞，要扩展监控，实时监控设计状态的漂移，确保包括安全和合规性。监控应能够启用警报、自动修复和移除不合规的资源。

对一切进行编码是打开无限可能的关键要求。DevSecOps 的目标是保持创新的步伐，而这种步伐应当与安全自动化的步伐相匹配。可扩展的基础设施需要可扩展的安全性，这需要自动化事件响应修复来实施持续的合规性和验证。

结合 DevSecOps 和 CI/CD

DevSecOps 实践必须嵌入每个 CI/CD 管道步骤。DevSecOps 通过管理每台服务器分配的适当访问权限和角色来确保 CI/CD 管道的安全，并确保构建服务器（如 Jenkins）已加固，能防止任何安全漏洞。此外，我们还需要确保所有工件都经过验证，并且代码分析已经到位。

建议通过自动化持续的合规性验证和事件响应修复来为事件响应做好准备。例如，如果一个组织需要遵守支付卡行业数据安全标准（PCI-DSS），那么持续的合规性验证就包括设置自动化工具和流程，以不断检查信用卡信息的处理、存储和传输是否符合 PCI-DSS 要求。

下图为我们提供了多个阶段，用于测试安全边界、捕获安全问题，并尽早确保符合政策：

图 11.7：DevSecOps 与 CI/CD

在每个集成点，你可以识别不同的问题，如前面的图示所示：

• 在代码阶段，扫描所有代码，确保没有硬编码的秘密或访问密钥在代码行之间。

• 在构建阶段，包含所有安全工件，例如加密密钥和访问令牌管理，并为它们添加标签以便于识别。

• 在测试阶段，扫描配置以确保所有安全标准都已通过测试安全检查。

• 在部署和配置阶段，确保所有安全组件已注册。执行校验和以确保构建文件没有变化。校验和是一种用于确定接收文件的真实性的技术。操作系统提供了checksum命令来验证文件，并确保在文件传输过程中没有任何变化。

• 在监控阶段，监控所有安全标准。执行持续审计和自动化验证。

你可以将多个工具集成到 DevSecOps 管道中，以在不同阶段识别安全漏洞，并聚合漏洞发现结果。

应用安全测试（AST），即使用工具自动化测试、分析和报告安全漏洞，是应用开发的关键组成部分。AST 可以分为以下四个类别，用于扫描软件应用中的安全漏洞：

• 软件组成分析（SCA）：SCA 评估代码库中开源软件的安全性、许可证合规性和代码质量。SCA 尝试检测项目依赖项中包含的公开披露的漏洞。常见的 SCA 工具包括 OWASP Dependency-Check、Synopsys 的 Black Duck、WhiteSource、Synk 和 GitLab。

• 静态应用安全测试（SAST）：SAST 涉及在编译之前扫描应用程序的代码。这些工具为开发人员提供即时反馈，使他们在编码过程中能够尽早发现问题，并在代码构建阶段之前进行修正。作为一种白盒测试方法，SAST 分析源代码，以识别可能导致应用程序受到攻击的漏洞。其主要优势在于它可以在 DevOps 周期的早期阶段，即编码阶段进行集成，因为它不需要一个功能完整的应用程序或代码执行。常见的 SAST 工具包括 SonarQube、PHPStan、Coverity、Synk、Appknox、Klocwork、CodeScan 和 Checkmarx。

• 动态应用安全测试（DAST）：DAST 通过模拟外部攻击来识别应用中的安全漏洞，测试正在运行的应用。它从外部评估应用，探查暴露的接口是否存在漏洞。DAST 也被称为黑盒安全测试或 Web 应用漏洞扫描器，DAST 工具包括 OWASP ZAP、Netsparker、Detectify Deep Scan、StackHawk、Appknox、HCL AppScan、GitLab 和 Checkmarx。

• 互动应用安全测试（IAST）：IAST 在应用被积极测试或使用时检查代码中的安全漏洞，从而实时报告问题而不会导致 CI/CD 管道的延迟。IAST 工具通常在 QA 环境中与自动化功能测试一起实施。著名的 IAST 工具包括 GitLab、Veracode、CxSAST、Burp Suite、Acunetix、Netsparker、InsightAppSec 和 HCL AppScan。

你将会在本章的构建云中的 DevOps 和 DevSecOps部分了解如何将上述一些工具集成到 DevOps 管道中。DevSecOps CI/CD 确保代码符合公司安全政策。

它有助于避免由于不同的安全配置导致后续部署中的基础设施和应用失败。DevSecOps 保持敏捷性，并确保在不影响 DevOps 创新步伐的情况下确保安全。让我们了解 DevOps 管道中的 CD 策略。

实施 CD 策略

CD 提供无缝的应用版本迁移。通过 CD 实现的一些最受欢迎的技术如下：

• 原地部署：在当前服务器上更新应用

• 滚动部署：逐步在现有服务器集群中推出新版本

• 蓝绿部署：逐步将现有服务器替换为新服务器

• 红黑部署：从现有服务器即时切换到新服务器

• 不可变部署：完全搭建一套新的服务器

让我们更详细地探讨每个选项。

原地部署

原地部署是一种在现有服务器集群上推出新版本应用的方法。更新是在一次部署操作中完成的，需要一些停机时间。此更新几乎不需要任何基础设施的变更，也无需更新现有的域名系统（DNS）记录。部署过程本身相对较快。如果部署失败，恢复的唯一选择是重新部署。

简单来说，你是将应用基础设施上现有的应用版本（v1）替换为新版本（v2）。原地更新成本低，且部署速度快。

滚动部署

使用滚动部署，服务器群分成多个组，因此不需要同时更新。部署过程在同一服务器群上同时运行旧版和新版软件，但是在不同的子组中。滚动部署方法有助于实现零停机时间。如果新版本部署失败，那么只有整个群中的一部分服务器受到影响，风险很小，因为仍有一半的群会继续运行。滚动部署有助于实现零停机时间；然而，与原地部署相比，部署时间略长一些。

滚动部署不仅有助于实现零停机时间，提升用户体验，而且在额外资源分配方面成本中性。与需要在一段时间内加倍环境的蓝绿部署不同，滚动部署逐个更新现有资源，避免了额外基础设施的需求。虽然与原地部署相比，部署时间可能稍长，但此方法不会因提供额外资源而产生额外成本，是在不影响预算的情况下进行持续交付的高效策略。现在让我们来学习一下蓝绿部署。

蓝绿部署

蓝绿部署的理念是，您的蓝色环境是承载实时流量的现有生产环境。同时，您提供一个绿色环境，与蓝色环境相同，除了代码的新版本。在部署时，您将生产流量从蓝色环境路由到绿色环境。如果绿色环境遇到任何问题，您可以通过将流量恢复到原始蓝色环境来回滚。DNS 切换和交换自动扩展组是蓝绿部署中重新路由流量的两种常见方法。

使用自动扩展策略，您可以逐步将现有实例替换为托管新版本应用程序的实例，以满足应用程序扩展的需求。此选项最适合用于小版本发布和小代码更改。另一种选项是利用 DNS 路由在不同版本的应用程序之间执行复杂的负载均衡。

如下图所示，创建托管新版本应用程序的生产环境后，您可以使用 DNS 路由将一小部分流量转移到新环境：

图 11.8：蓝绿部署 DNS 逐步切换

使用生产流量的一部分来测试绿色环境，这称为金丝雀分析。如果环境存在功能性问题，你可以立即发现并在对用户产生重大影响之前切换流量回去。继续逐步转移流量，测试绿色环境的负载处理能力。监控绿色环境以发现问题，提供将流量切换回去的机会，从而限制影响范围。最后，当所有指标正常时，停用蓝色环境并释放资源。

蓝绿部署有助于实现零停机时间，并提供便捷的回滚功能。你可以根据需要定制部署时间。然而，这些零停机时间是有成本考量的，因为这种方法需要维持两个相同的生产环境，一个是活动的（蓝色），一个是空闲的（绿色）。环境的重复意味着由于额外资源的需求，运营成本更高。然而，这种成本通常通过它在风险缓解和用户体验持续性方面带来的价值来证明是合理的。

红黑部署

在红黑部署中上线新版本之前，需要进行金丝雀测试。金丝雀将现有生产系统的约 1%替换为最新版本的应用程序，并监控该版本的错误。如果金丝雀测试通过，则认为系统准备好进行部署。新的系统版本与旧版本并排部署，为切换做准备。新系统的初始容量是手动设置的，方法是查看当前在生产环境中运行的实例数量，并将这个数字设为新自动扩展组的目标容量。新系统上线后，两个系统都处于红色状态，当前版本是唯一接受流量的版本。

然后，通过 DNS 服务将系统从现有版本切换到新版本。此时，旧版本被视为黑色；它仍在运行，但不再接收任何流量。如果检测到新版本有问题，恢复操作就像将 DNS 服务器指向旧版本的负载均衡器一样简单。

红黑部署也被称为暗启动，它与蓝绿部署略有不同。在红黑部署中，你通过 DNS 切换将流量从旧版本直接切换到新版本，而在蓝绿部署中，DNS 会逐步将流量转移到新版本。蓝绿部署和暗启动可以结合使用，使两种软件版本并行部署。使用两个独立的代码路径，但只有一个被激活。功能开关激活另一个代码路径。这种部署方式可以作为 Beta 测试，在测试中明确启用新功能。

红黑部署，类似于蓝绿部署，通过运行两个相同的环境来确保零停机并促进轻松回滚。成本主要与部署阶段需要翻倍资源相关。你将拥有一个“红色”环境（当前的在线版本）和一个“黑色”环境（新版本）。这两个环境必须完全正常运行，这实际上将资源需求翻倍——包括计算、存储和网络资源——在过渡期间。尽管这种方法大大减少了部署风险，并提供了无缝的用户体验，但重复的环境会导致成本增加。然而，由于额外的资源仅在部署窗口期间需要，这种成本是暂时的，可以视为对稳定性和可靠性的投资。

不可变部署

如果应用程序具有未知的依赖关系，不可变或一次性升级会更加直接。随着时间的推移，经过多次修补和更新的旧应用基础设施变得越来越难以升级。这种升级技术在不可变基础设施中更为常见。

在新版本发布期间，通过终止旧实例来推出一组新的服务器实例。对于一次性升级，你可以设置一个克隆环境，使用 Chef、Puppet、Ansible 和 Terraform 等部署服务，或者将它们与自动扩展配置结合使用来管理更新。

除了停机时间外，在设计部署策略时，还必须考虑成本。考虑你需要替换的实例数量以及部署频率，以确定成本。根据预算和停机时间，选择最合适的方法。

在本节中，你学习了各种 CD 策略，它们有助于使应用发布更高效、无忧。接下来，我们来看选择正确部署类型的最佳实践。

选择正确部署策略的最佳实践

选择正确的部署策略对成功的应用更新和无缝的用户体验至关重要。以下是选择不同部署策略的最佳实践：

• 就地部署：就地部署适用于简单性至关重要且应用程序相对较小或用户群体有限的场景。例如，使用小团队更新公司内部工具非常适合这种方法。它涉及在当前服务器上更新应用程序，但需要注意的是，这可能会导致停机时间。对于大规模或高可用性的应用程序，这种策略并不适合。一个显著的例子是，晚上更新一个小规模的网页服务，用户流量较低。在更新失败时，恢复到先前版本并快速最小化干扰的回滚策略至关重要。

• 滚动部署：滚动部署适用于需要最小停机时间，但不需要额外资源的应用程序。这种方法会在现有的服务器集群中逐步更新应用程序。例如，可以分阶段将更新部署到电子商务网站的服务器，确保只有一部分用户在任何时候遇到潜在问题。然而，这种方法不适用于无法同时处理不同版本的应用程序。部署过程中对应用程序性能的持续监控是解决问题的关键。

• 蓝绿部署：蓝绿部署最适用于对零停机时间要求极高的关键应用程序。金融服务公司可能会使用此策略更新其面向客户的应用程序。一旦绿色环境经过彻底测试并准备就绪，流量就会从蓝色环境切换到绿色环境。这种方法需要双倍的资源，但提供无缝的用户体验和快速回滚能力。确保负载均衡和 DNS 切换机制的稳健性和可靠性至关重要。

• 红黑部署：红黑部署类似于蓝绿部署，但更注重快速切换到新版本。它特别适用于快速发布新版本，常用于容器化环境中。例如，一个媒体流服务可能会使用此策略部署平台的新版本，确保所有用户能够立即使用新功能。尽管它提供了快速发布和即时切换的优势，但新版本的充分测试至关重要，因为回滚涉及恢复到旧环境。

• 不可变部署：不可变部署确保了云环境中的一致性和可靠性。每次部署都涉及设置新的服务器，保证可预测和稳定的状态。这种方法对具有复杂依赖关系的应用程序尤其有利，因为它避免了长期存在的环境中出现的“配置漂移”问题。此策略要求高效管理基础设施资源，因为每次发布都涉及为新服务器配置和淘汰旧服务器。

在这些策略中，评估应用程序的复杂性、规模、用户群体以及潜在停机的影响非常重要。

此外，资源的可用性、基础设施成本以及应用程序的关键性应引导部署策略的选择。定期根据技术和组织变化更新和优化部署方法也是保持有效部署过程的关键。

你需要在每一步进行应用程序测试，以确保高质量交付，这通常需要大量的工作。DevOps 管道可以帮助你自动化测试流程，提高功能发布的质量和频率。让我们深入了解 CI/CD 管道中的持续测试。

在 CI/CD 流水线中实施持续测试

DevOps 对于基于客户反馈、对新功能的需求或市场趋势变化的持续业务场景至关重要。一个强大的 CI/CD 流水线确保可以在更短时间内加入更多功能/反馈，客户也可以更快地使用新功能。

通过频繁的代码提交，在 CI/CD 流水线中内置一个良好的测试策略可以确保你以高质量完成反馈闭环。持续测试对于平衡 CI/CD 流水线至关重要。虽然快速添加软件功能是好事，但通过持续测试确保功能符合良好的质量标准。

单元测试构成了测试策略中最重要的部分。它们通常在开发人员的机器上运行，是最快且最便宜的。一个通用的经验法则是将 70%的测试工作量集中在单元测试上。在这个阶段捕获的 Bug 可以快速修复，且复杂性较低。

开发人员通常会执行单元测试，一旦代码准备好，就会进行集成和系统测试。这些测试需要独立的环境，有时还需要单独的测试团队，这使得测试过程变得更加昂贵。一旦团队确认所有预期功能按预期工作，运营团队需要进行性能和合规性测试。这些测试需要类似生产环境的环境，且费用较高。此外，用户验收测试（UAT）也需要类似生产的环境，这会导致更多的开销。

如下图所示，开发人员在开发阶段执行单元测试，以测试代码更改/新功能。测试通常在开发人员的机器上完成，完成编码后进行。还建议对代码更改进行静态代码分析，并进行代码覆盖率、遵循编码规范等检查。没有依赖项的小型单元测试运行得更快。因此，开发人员可以迅速发现测试是否失败：

图 11.9：CI/CD 中的持续测试

构建阶段是不同组件和单个组件之间集成的第一次测试。构建阶段也是测试开发人员提交的代码是否破坏任何现有功能并进行回归测试的绝佳时机。

预发布环境是生产环境的镜像。在这个阶段进行端到端的系统测试（UI、后台逻辑和 API 会进行广泛的测试）。性能测试在特定的工作负载下测试应用程序的性能。性能测试包括负载测试和压力测试。UAT 也会在此阶段进行，为生产部署做好准备。合规性测试用于测试行业特定的法规合规性。

例如，假设你正在将持续测试集成到在线流媒体平台的视频个性化功能的 CI/CD 管道中。当你的开发团队提交代码更改时，CI 工具（例如 Jenkins）会自动启动构建过程并进行一系列自动化测试。这些测试包括单元测试，用于验证个性化功能的各个组件，集成测试，确保与现有系统组件的兼容性，以及 UI 测试，以确认用户交互流程顺畅。在这种情况下，性能测试尤为关键，用于验证新功能不会降低流媒体体验。如果在这些测试过程中出现任何问题，管道会被暂停，允许开发人员进行必要的修正，从而确保只有经过彻底审核的代码才会进入下一个阶段。在通过自动化测试后，功能会进入模拟生产环境的预发布环境，进行进一步的测试和验证。这一额外的审查层确保功能能够在各种场景和用户行为下良好表现，并通过用户验收测试后再部署。

A/B 测试

在软件开发中，经常需要明确哪个功能的实现最有可能在现实世界中成功。整个计算机科学学科——人机交互（HCI）——致力于回答这个问题。虽然 UI 专家有多种指南帮助设计合适的界面，但最好的设计选择往往只能通过将其交给用户并观察他们是否能使用该设计完成特定任务来确定。

像 A/B 测试或金丝雀分析这样的策略会在生产阶段测试新版本的应用。在 A/B 测试中，新版本的应用会部署到少部分生产服务器上并进行用户反馈测试。随着用户对新应用的接受度逐步增加，部署会逐渐扩展到所有生产服务器。

如下图所示，A/B 测试是一种方法论，将功能的两个或多个版本分别提供给不同的用户群体。收集关于每个实现的详细使用数据，UI 工程师会分析这些数据，以决定接下来应该采用哪个实现：

图 11.10：通过 A/B 测试进行的特性实验用户拆分

上述图表展示了一个 A/B 测试场景，其中同时测试多个版本的 Web 应用，以评估其性能、用户参与度或其他定义的指标。以下是该架构中 A/B 测试过程的描述：

1. 流量分配：应用程序负载均衡器起着至关重要的作用，它将用户的流量引导到不同版本的网页应用程序。在这种情况下，大部分流量（90%）被引导到稳定的生产版本（V1.1），而正在测试的新版本 V1.2 和 V1.3 则分别接收较小比例的流量，分别为 7% 和 3%。

2. Web 服务器集群：每个版本的应用程序运行在一组独立的 Web 服务器或实例上，确保一个版本的更改不会影响其他版本。这种隔离对于获得准确的测试结果至关重要。接收最多流量的版本作为对照组，而其他带有更改或新特性的版本则作为测试组。

3. 数据库：所有版本的应用程序都与同一个后台数据库进行交互。这在 A/B 测试中很常见，其中底层数据在不同用户体验之间保持一致。然而，必须小心确保数据库架构和交互在所有版本之间兼容，以避免数据处理中的错误或不一致。

你需要确保在整个 A/B 测试过程中，持续监控性能指标，以评估应用程序的每个版本在真实环境中的表现。这包括评估响应时间、错误率、资源利用率等多个因素。在收集到足够的数据后，分析结果以确定哪个版本在测试标准下表现最佳。然后，可以根据 A/B 测试的结果，决定是完全发布新版本、进行进一步修改，还是回滚更改。

使用 DevOps 工具进行 CI/CD

要构建一个 CI/CD 管道，开发人员需要各种工具。这些工具包括代码编辑器、源代码仓库、构建服务器、部署工具以及整体 CI 管道的协调。让我们探索一些流行的 DevOps 开发工具选择，涵盖云端和本地部署。

代码编辑器

DevOps 是一种实践性很强的编码角色，通常需要编写脚本来自动化环境。你可以使用 Ace 编辑器 或 基于云的 AWS Cloud9 集成开发环境（IDE）。Ace 提供了语法高亮和其他对开发人员有价值的功能。Cloud9 与 AWS 平台集成，使得开发人员可以轻松创建无服务器应用程序并使用 AWS 服务。它还支持协作编码，并配备了常用编程语言的基本工具。

你可以在本地计算机上使用基于网页的代码编辑器，或者在本地服务器上安装代码编辑器，连接到应用环境——如开发、测试和生产环境——进行交互。在环境中，你存储项目的文件并运行工具以开发应用。你可以将这些文件保存在实例或服务器上，或者将远程代码库克隆到环境中。AWS Cloud9 IDE 是一种云原生 IDE，作为托管服务提供。

Ace 编辑器让你可以快速、轻松地编写代码。它是一个基于网页的代码编辑器，但提供了类似于 Eclipse、Vim、Visual Studio Code（VS Code）等流行桌面代码编辑器的性能。它具备标准的 IDE 特性，如实时语法和匹配括号高亮、自动缩进和补全、标签之间的切换、与版本控制工具的集成以及多光标选择。它能够处理大文件，拥有数十万行代码也不会出现输入延迟。它内建对所有流行编程语言和调试工具的支持，还可以安装自己的工具。对于桌面 IDE，VS Code 和 Eclipse 是 DevOps 工程师可以选择的其他流行代码编辑器选项。

源代码管理

你有多个选择来设置你的源代码仓库。你可以搭建、运行和管理自己的 Git 服务器，所有操作都由你负责。

你可以选择使用 GitHub 或 Bitbucket 等托管服务。如果你正在寻找云解决方案，AWS CodeCommit 提供了一个安全、高度可扩展且托管的源代码控制系统，用于托管私有 Git 仓库。

你需要为代码仓库设置身份验证和授权，以便授权的团队成员可以访问代码进行读取或写入。你可以应用传输中的加密和静态数据加密。当你推送到代码仓库时（git push），它会加密并存储数据。当你从代码仓库拉取数据时（git pull），它会解密数据，然后返回给调用者。用户必须经过适当访问级别的身份验证才能访问代码仓库。数据可以通过 HTTPS 或 SSH 协议在加密的网络连接中进行传输，从而加密传输中的数据。

CI 服务器

CI 服务器也称为构建服务器。当团队在多个分支上工作时，将代码合并回主分支变得复杂。在这种情况下，CI 发挥着关键作用。CI 服务器钩子提供了一种基于代码提交到仓库时触发构建的方式。钩子几乎在每个版本控制系统中都可以找到，指的是在仓库中根据特定必要操作触发的自定义脚本。钩子可以在客户端或服务器端运行。

拉取请求是开发人员在将代码合并到公共代码分支之前，用于通知和相互审查工作的一种常见方式。CI 服务器提供了一个 web 界面，用于在将变更添加到最终项目之前进行审查。如果提议的变更存在任何问题，源代码可以被退回给开发者，根据组织的编码要求进行修改。

如下图所示，服务器端钩子与 CI 服务器结合使用，用于提高集成的速度：

图 11.11：CI 自动化

如前图所示，使用post-receive，你可以引导新的分支触发 CI 服务器上的测试，以验证新的构建是否正确集成，所有单元是否正常工作。开发者会收到测试失败的通知，并且在修复问题后才知道将他们的分支与主干合并。开发者可以从他们的分支构建，测试那里进行的更改，并获得反馈，了解他们的更改工作得如何，然后再决定是否将他们的分支合并到主干。

运行集成和单元测试能显著减少将该分支合并到主干时的阻力。钩子还可以自定义，以测试合并到主干的变更，并阻止任何未通过测试的合并。集成最好通过 CI 服务器来完成。

Jenkins 是构建 CI 服务器的最流行选择。如下面的图所示，你可以将 Jenkins 集群托管在 AWS 弹性计算云（EC2）服务器的集群中，并根据构建负载进行自动扩展：

图 11.12：Jenkins CI 服务器的自动扩展

Jenkins 控制器在出现负载过重时，会将构建任务转移到代理节点实例。当负载下降时，Jenkins 控制器会自动终止代理实例。

但是，你需要自行维护安全性并打补丁。对于本地云选项和托管服务，你可以使用像 AWS CodeBuild 这样的托管代码构建服务，免去服务器管理的需求，并通过按需付费模式显著降低成本——服务根据需求进行扩展。你的团队可以专注于推送代码，而将所有构建工作交给服务来完成。

虽然 CI 服务器帮助你从源代码仓库中构建正确版本的代码，通过团队成员的协作，代码部署帮助团队将代码准备好进行测试和发布，以便最终用户使用。接下来，让我们更详细地了解代码部署。

代码部署

一旦构建完成，你可以部署 Jenkins 服务器，或者选择 AWS CodeDeploy 作为云原生托管服务。你也可以使用其他流行的工具，如 Chef 或 Puppet，来创建部署脚本。指定部署配置的选项如下：

• OneAtATime：在任何时候，部署组中的只有一个实例会安装新的部署。如果某个实例上的部署失败，则部署脚本会停止部署并返回一个错误响应，详细说明成功与失败安装的数量。

• HalfAtATime：部署组中的一半实例安装新的部署。如果一半实例成功安装该版本，则部署成功。HalfAtATime 是生产/测试环境中的一个良好选择，适用于一半实例更新为新版本，另一半则保持在旧版本中可用。

• AllAtOnce：每个实例在下次轮询部署服务时，都会安装最新的版本。此选项最适用于开发和测试部署，因为它有可能在部署组中的每个实例上安装一个无法正常工作的版本。

• Custom：你可以使用此命令创建自定义部署配置，指定在任何给定时刻必须在部署组中存在的健康主机的固定数量。这个选项是 OneAtATime 选项的更灵活实现。它允许在某些实例因损坏或配置不当而导致部署失败的情况下进行部署。

下图展示了部署过程中的生命周期事件：

图 11.13：部署生命周期事件

部署代理会按步骤执行部署。这些步骤称为生命周期事件。在前面的图示中，浅色框中的步骤可以通过人工干预进行控制；而深色框中的步骤是自动化的，由部署代理控制。让我们详细了解每个步骤：

1. ApplicationStop：触发部署的首个要求是停止应用服务器，以便在复制文件时停止处理流量。软件应用服务器的例子包括 Tomcat、JBoss 或 WebSphere 服务器。

2. DownloadBundle：在停止应用服务器后，部署代理开始从工件库（如 JFrog Artifactory）下载预构建的部署包。工件库存储应用程序二进制文件，可以在新版本发布前进行部署和测试。

3. BeforeInstall：部署代理会触发安装前的步骤，例如通过脚本创建当前版本的备份并进行任何必要的配置更新。

4. Install：在此步骤中，部署代理开始安装过程——例如，运行 Ant 或 Maven 脚本来安装 Java 应用程序。

5. AfterInstall：部署代理在完成应用程序安装后触发此步骤。它可能包括更新安装后的配置，例如本地内存设置和日志参数。

6. ApplicationStart：在此步骤中，代理启动应用程序，并通知成功或失败的运维团队。

7. ValidateService：验证步骤在其他所有步骤完成后触发，允许你快速检查应用程序。它包括执行自动化的健全性测试和集成测试，以验证新版本的应用程序是否正确安装。代理还会在测试成功后向团队发送通知。

你已经了解了各种代码部署策略和步骤，作为独立组件。然而，你必须将所有 DevOps 步骤串联在一起，搭建一个自动化的 CI/CD 管道。让我们深入了解代码管道，它将帮助你构建一个端到端的 CI/CD 管道。

代码管道

代码管道的核心是将所有内容协调在一起，实现持续交付（CD）。在 CD 中，整个软件发布过程是完全自动化的，包括构建和部署到生产环境。经过一段时间的实验，你可以建立一个成熟的 CI/CD 管道。通向生产发布的路径是自动化的，从而实现快速部署新特性并立即获得客户反馈。你可以使用云原生的托管服务，如 AWS CodePipeline，来协调整体的代码管道，或者使用 Jenkins 服务器。

代码管道使你可以向 CI/CD 管道的各个阶段添加操作。每个操作可以与一个执行该操作的提供者关联。代码管道操作类别和提供者示例如下：

• 源代码：你的应用程序代码需要存储在一个中央仓库中，并进行版本控制，这个仓库称为源代码仓库。一些流行的代码仓库包括 AWS CodeCommit、Bitbucket、GitHub、并行版本系统（CVS）、Subversion（SVN）等。

• 构建：构建工具从源代码仓库中拉取代码，并创建一个应用程序二进制包。一些流行的构建工具包括 AWS CodeBuild、Jenkins、Solano CI 等。构建完成后，你可以将二进制文件存储在像 JFrog 这样的制品库中。

• 部署：部署工具帮助你将应用程序二进制文件部署到服务器上。一些流行的部署工具包括 AWS Elastic Beanstalk、AWS CodeDeploy、Chef、Puppet、Jenkins 等。

• 测试：自动化测试工具帮助你完成并执行部署后的验证。一些流行的测试验证工具包括 Jenkins、BlazeMeter、Ghost Inspector 等。

• 调用：你可以使用基于事件的脚本来调用一些活动，比如备份和警报。任何脚本语言，如 Shell 脚本、PowerShell 和 Python，都可以用来调用各种定制化的活动。

• 审批：审批是 CD 中的一个重要步骤。你可以通过自动化的电子邮件触发请求手动审批，或者可以通过工具实现自动化审批。

在本节中，你了解了用于管理软件开发生命周期（SDLC）的各种 DevOps 工具，如代码编辑器、代码库以及构建、测试和部署工具。你还学习了需要集成到 DevOps 流水线中的其他工具，如持续日志记录、持续监控和运维处理，这些内容你在第九章《运维卓越考虑》中学到过。到目前为止，你已经学习了每个 SDLC 阶段的各种 DevOps 技巧。接下来，让我们深入了解最佳实践和反模式。

实施 DevOps 最佳实践

在构建 CI/CD 流水线时，要考虑是否需要创建一个项目并添加团队成员。项目仪表板提供了代码流在部署流水线中的可见性，监控构建，触发警报，并跟踪应用活动。下图展示了一个定义明确的 DevOps 流水线：

图 11.14：CI/CD 工作流最佳实践

设计流水线时，请考虑以下几点：

• 阶段数量：阶段可以是开发、集成、系统、用户验收和生产。有些组织还会包括开发、Alpha、Beta 和发布阶段。

• 每个阶段的测试类型：每个阶段可以有多种类型的测试，如单元测试、集成测试、系统测试、用户验收测试、冒烟测试、负载测试和生产阶段的 A/B 测试。

• 测试顺序：测试用例可以并行执行，也可以需要按顺序执行。

• 监控与报告：监控系统缺陷和故障，并在发生故障时发送通知。

• 基础设施供应：为每个阶段提供基础设施的方法。

• 回滚：定义回滚策略，在需要时回退到先前的版本。

拥有一个需要人工干预的系统会拖慢你的过程，尤其是在可以避免的情况下。因此，通过使用 CD 自动化流程，你将加速流程。

另一个常见的反模式是将构建的配置值保存在代码内部，甚至让开发人员在构建过程中使用不同的工具，这导致开发人员之间的构建不一致。排查为什么特定的构建在某个环境中工作而在其他环境中无法工作，通常需要花费大量的时间和精力。为了克服这一点，最好将构建配置存储在代码之外。将这些配置外部化到能在不同构建之间保持一致性的工具中，可以实现更好的自动化，并允许你的过程更快速地扩展。不使用 CD 流程可能会导致临时的、深夜的赶工来使构建工作正常。设计你的 CD 流程以快速失败，从而减少最后时刻的意外发生的可能性。

外部化特定环境的配置对于在各个构建中保持一致性和可扩展性至关重要。一些促进这种抽象的工具和服务包括：

• AWS Systems Manager Parameter Store：为配置数据管理和机密管理提供安全的分层存储。你可以将密码、数据库连接字符串、许可证代码等数据作为参数值进行存储。

• Kubernetes 中的 ConfigMaps 和 Secrets：Kubernetes 对象，允许你将配置文件与镜像内容分离，从而保持容器化应用的可移植性。

• Docker Swarm secrets：用于管理与 Docker 容器相关的敏感数据，提供在 Swarm 集群中安全传输和存储机密的方式。

• HashiCorp 的 Consul：一种服务网络解决方案，用于通过分布式键值存储自动化网络配置。

通过使用这些工具，你可以将配置和机密管理与应用代码和模板分开，使得在不重新部署或更改应用的情况下更轻松地管理和轮换它们，确保其安全。

为了有效评估 CI/CD 在 DevOps 框架中的影响，监控关键绩效指标（KPIs）是必不可少的。关键的 CI/CD KPI 包括：

• 部署频率，它表示更新到达生产环境的频率，反映了发布过程的敏捷性

• 变更的交付时间，它显示从代码提交到实时部署的持续时间，较短的周期表明更高效的开发周期

• 变更失败率，它识别导致故障的部署比例，较低的比例表示更好的部署稳定性

• 平均恢复时间（MTTR），它衡量从故障恢复的平均时间，较快的恢复时间体现了团队在事件管理上的高效性

• 自动化测试通过率，它通过每个 CI/CD 周期中的自动化测试成功率突出代码的可靠性

十二因素方法论可以在应用开发的每个阶段应用架构最佳实践，正如 The Twelve-Factor App（12factor.net/）推荐的那样，企业在进行 Web 应用的端到端开发和交付时采用该方法。这适用于所有编码平台，无论编程语言如何。如今，大多数应用程序都作为 Web 应用构建，并利用云平台。让我们来学习如何在云中构建端到端的 DevOps 和安全自动化。

在云中构建 DevOps 和 DevSecOps

正如你在前面的章节中学到的，构建 CI/CD 管道需要多个工具，并且在此基础上增加安全自动化会增加复杂性。从头开始集成一系列工具并整合漏洞评估结果可能是一个复杂的任务。像 AWS 这样的公共云服务提供商提供了构建 DevSecOps 管道所需的适应性。这包括云原生工具和第三方工具的直接集成，以及有效聚合安全发现的能力。

DevSecOps 管道架构涵盖了 CI/CD 实践，包括 SCA、SAST 和 DAST 工具：

• 软件组成分析（SCA）工具分析应用程序中的开源组件，识别已知的漏洞、许可问题和过时的库。它们可以自动化检查更新和安全补丁的过程，使得管理应用程序的依赖关系变得更加轻松。

• SAST 工具设计用于分析源代码或编译后的代码版本，以检测安全漏洞。它们可以在不执行代码的情况下识别诸如输入验证错误、不安全的依赖项和潜在的后门等问题。

• DAST 工具评估运行中的应用程序漏洞。与分析静态代码的 SAST 工具不同，DAST 工具从外部与应用程序交互，执行黑盒测试，检测如 SQL 注入、跨站脚本攻击和身份验证问题等问题。

将这些工具集成到 CI/CD 管道中可以实现持续和自动化的安全测试，使团队能够及时发现并解决安全问题，从而提高应用程序的整体安全性。以下图示展示了管道中安全自动化的概念：

图 11.15：AWS 云中的 DevSecOps CI/CD 管道架构

上面的图示显示，当开发者在 GitHub 中提交代码时，CI/CD 管道会被触发。一个事件会生成，启动 AWS CodePipeline，使用 AWS CloudWatch。AWS CodePipeline 协调 CI/CD 管道，包括代码提交、构建和部署。AWS CodeBuild 编译构建，然后将生成的工件上传到 AWS CodeArtifact。为了启动扫描过程，AWS CodeBuild 从 AWS 参数存储中获取身份验证详细信息，包括扫描工具的令牌。

一旦部署成功完成，CodeBuild 启动 DAST。如果该过程发现任何漏洞，CodeBuild 会触发 Lambda 函数。然后，Lambda 函数将把安全发现记录到 AWS Security Hub 中。如果 DAST 没有发现安全问题，构建可以继续进行审批，管道将通知审批人采取行动，将构建推送到生产环境的 AWS ECS 中。在 CI/CD 管道运行过程中，AWS CloudWatch 会监控所有更改，并通过 SNS 通知将电子邮件通知发送给 DevOps 和开发团队。

AWS CloudTrail 跟踪任何关键更改，如管道更新、删除和创建，并将通知发送给 DevOps 团队以供审计使用。此外，AWS Config 跟踪所有配置更改。

在 DevSecOps 中，通过 AWS 身份与访问管理（IAM）角色来实现 CI/CD 管道的安全性，这些角色严格限制对必要资源的访问。加密和 安全套接字层（SSL）被用于保护管道数据的静态和传输安全。敏感信息，如 API 令牌和密码，被安全地存储在 AWS 参数存储中。

将安全发现集中在 AWS Security Hub 中，有助于自动化修复过程。根据安全问题的性质，可以触发 Lambda 函数执行所需的修复操作。例如，如果不小心暴露了 SSH 端口，系统可以自动限制来自互联网的服务器访问。这种自动化减轻了 DevOps 和安全团队的负担，使他们能够通过单一工具解决漏洞，而不需要管理多个仪表板。

在应用程序开发生命周期的早期解决安全威胁，可以显著降低对应用程序进行更改的成本。自动化此过程可以进一步加速这些更改的交付，使得 DevSecOps 管道成为成功应用程序开发的关键组成部分。

DevOps 整合了文化、实践和工具，将应用程序开发与运营结合在一起，从而实现新功能的快速交付。DevSecOps 通过将安全融入 DevOps 过程，扩展了这一概念，确保安全且合规的应用程序更改能够快速交付，并且运营始终实现自动化。这种集成是维护安全、高效和弹性的应用程序开发环境的关键。

总结

在本章中，你已了解了强大 DevOps 实践的关键组件及其好处、CI/CD 和持续监控与改进。CI/CD 的敏捷性只有通过全面应用自动化才能实现。为了自动化，你了解了 IaC 和配置管理。你还了解了各种自动化工具，如 Chef、Puppet 和 Ansible，以自动化配置管理。

由于安全性是优先考虑的，你已经学习了 DevSecOps，即在安全中的 DevOps。CD 是 DevOps 的关键方面之一。你了解了各种部署策略：滚动部署、蓝绿部署和红黑部署。测试是确保产品质量的另一个方面。你了解了 DevOps 中的持续测试概念，并且学到了 A/B 测试如何通过从客户的实时反馈中帮助改进产品。

你已经学习了 CI/CD 管道中的各个阶段。你了解了可以使用的工具和服务，以及为构建一个健壮的 CI/CD 管道可以遵循的最佳实践。你已经了解了各个服务如何工作，并讨论了如何将服务集成以构建一个复杂的解决方案。

到目前为止，你已经学习了关于解决方案架构的各个方面。由于每个组织都有大量的数据，他们会投入大量精力来洞察这些数据。在下一章中，你将学习如何收集、处理和消费数据，以获得更深入的洞察。

留下评论！

喜欢这本书吗？通过留下亚马逊评价来帮助像你一样的读者。扫描下方二维码获取你选择的免费电子书。

第十二章：解决方案架构的数据工程

在上一章中，您了解了 DevOps 过程，它自动化了应用程序部署流水线，并促进了开发、运维和安全团队之间的协作文化。本章将介绍数据工程，包括用于从应用程序的不同部分收集数据的各种工具和技术，从而获得可以推动您业务的见解。

在互联网和数字化时代，数据正在以极高的速度和量级产生。以快速的节奏从这些海量数据中获得洞察力是一个挑战。我们必须不断创新，摄取、存储和处理这些数据，以获得业务成果。

随着云计算、移动技术和社交技术的融合，基因组学和生命科学等多个领域的进展日益增长。从中挖掘数据获得更多见解的巨大价值不断增加。现代流处理系统必须基于高速输入数据在低延迟的情况下持续产生结果。

大数据的概念不仅仅是数据的收集和分析。组织在数据中的实际价值可以用于获得洞察力并创造竞争优势。并非所有的大数据解决方案都必须以可视化为终点。许多解决方案，如机器学习（ML）和其他预测分析，将这些答案以程序化方式输入到其他软件或应用程序中，提取信息并按设计做出响应。

与大多数事物一样，获取更快的结果需要更多的成本，大数据也不例外。有些答案可能不需要立即得到，因此解决方案的延迟和吞吐量可以灵活调整，可能需要几个小时才能完成。其他响应，比如预测分析中的响应，可能在数据可用时就需要立刻得到。

在本章中，您将学习以下主题，以处理和管理您的大数据需求：

• 什么是大数据架构？

• 设计大数据处理管道

• 数据摄取、存储、处理和分析

• 数据可视化

• 设计大数据架构

• 大数据架构最佳实践

本章结束时，您将了解如何设计大数据和分析架构。您将学习大数据管道的步骤，包括数据摄取、存储、处理、可视化和架构模式。

什么是大数据架构？

收集的数据量庞大可能会带来问题。随着数据的不断积累，管理和移动数据及其底层的大数据基础设施变得越来越困难。云服务提供商的崛起促进了将应用程序迁移到云端的能力。多个数据源导致数据量、速度和多样性增加。以下是一些常见的计算机生成数据来源：

• 应用服务器日志：应用程序日志和游戏

• 点击流日志：来自网站点击和浏览

• 传感器数据：天气、水、风能和智能电网

• 图像和视频：交通和安全摄像头

计算机生成的数据可以从半结构化日志到非结构化的二进制数据。计算机生成的数据源可以在数据中产生模式匹配或相关性，生成社交网络和在线游戏的推荐。你还可以使用计算机生成的数据，如博客、评论、电子邮件、图片和品牌感知，来跟踪应用程序或服务的行为。

人工生成的数据包括电子邮件搜索、自然语言查询、产品或公司情感分析以及产品推荐。社交图谱分析可以根据你的朋友圈生成产品推荐、可能感兴趣的工作，甚至根据朋友的生日、纪念日等生成提醒。

来自分析团队的典型障碍是阻止他们为组织提供最大价值的原因：

• 对客户体验和运营的洞察有限：为了创造新的客户体验，组织需要更好地了解他们的业务。复杂且昂贵的数据收集、处理系统和增加的规模成本迫使组织限制其收集和分析的数据类型和数量。

• 需要做出更快的决策：这是一个两部分的问题：

  • 传统数据系统不堪重负，导致工作负载需要很长时间才能完成。

  • 更多的决策需要在秒或分钟内做出，这要求系统实时收集和处理数据。

• 通过机器学习推动创新：组织正在增加并发展他们的数据科学团队，以帮助优化和发展他们的业务。这些用户需要更多的数据访问权限和选择的工具，而不必通过传统的繁琐流程，这些流程可能会拖慢他们的工作进度。

• 技术人员和扩展自管基础设施的成本：需要管理本地基础设施的客户，需要帮助快速扩展以满足业务需求。管理基础设施、高可用性、扩展和运营监控需要时间，特别是在大规模时。

在大数据架构中，一个重要数据管道的整体流程从数据开始，到洞察结束。你从开始到结束的过程取决于很多因素。下图展示了一个数据工作流管道，帮助你设计数据架构：

图 12.1：数据架构设计的大数据管道

如前图所示，大数据管道的标准工作流程包括以下步骤：

1. 数据通过适当的工具被收集（引入）。

2. 数据被持久存储。

3. 数据被处理或分析。数据处理/分析解决方案从存储中获取数据，进行操作，然后再次存储处理后的数据。

4. 数据随后被其他处理/分析工具或同一工具再次使用，以从数据中获取进一步的答案。

5. 为了使答案对业务用户有用，这些答案通常通过商业智能（BI）工具进行可视化，或被输入到机器学习算法中以做出未来预测。一旦适当的答案展示给用户，这将为他们提供能够进一步用于商业决策的数据洞察。

你在管道中部署的工具决定了你的响应时间，即数据创建时与你能够从中获得洞察时之间的延迟。考虑延迟时设计数据解决方案的最佳方式是确定如何平衡吞吐量和成本，因为更高的性能和更低的延迟通常会导致更高的价格。例如，金融交易平台需要实时分析，以便为用户提供即时洞察，从而做出快速决策。

为了实现这一目标，平台可能会采用昂贵的数据处理管道，其中包括内存数据库、实时流处理和高速数据摄取服务。该设置确保低延迟，使交易者能够即时响应市场变化。在这里，实时分析的业务需求证明了与低延迟架构相关的高成本是合理的。

设计大数据处理管道

许多大数据架构犯的一个关键错误是使用一个工具处理多个数据管道阶段。从数据存储和转换到可视化，管理端到端数据管道的服务器群可能是最直接的架构，但也是最容易出现管道故障的架构。这种紧密耦合的大数据架构通常无法为你的需求提供最佳的吞吐量和成本平衡。在设计数据架构时，请使用以下解释的 FLAIR 数据原则：

• F – 可查找性：指的是轻松定位可用数据资产并访问其元数据的能力，包括诸如所有权、数据分类以及其他对于数据治理和合规性至关重要的属性。

• L – 血统：追溯数据来源、跟踪其流动和历史的能力，并理解及可视化数据从源头到消费点的流动方式。

• A – 可访问性：这涉及到请求和获取安全凭证的能力，凭证授予访问特定数据资产的权限。它还意味着需要支持高效数据访问的网络基础设施。

• I – 互操作性：确保数据以大多数（如果不是全部）组织内部处理系统可以访问和使用的格式存储。

• R – 可重用性：数据应使用已知的模式进行文档化，并且数据的来源应清晰注明。这个方面通常包括主数据管理（MDM）的原则，主数据管理关注于来自不同领域的关键数据的管理，以准确性和一致性为基础，提供一个单一的参考点。

大数据架构师建议解耦摄取、存储、处理和获取洞察之间的管道。将存储和处理解耦成多个阶段有几个优点，包括提高容错能力。例如，如果第二轮处理出现问题并且专门用于该任务的硬件发生故障，你就不必从管道的开始重新开始；系统可以从第二个存储阶段恢复。将存储从各个处理层解耦，允许你读写多个数据存储。

以下图示展示了在设计大数据架构管道时需要考虑的各种工具和过程：

图 12.2：大数据架构设计的工具与过程

在确定适合你大数据架构的工具时，应该考虑以下因素：

• 你的数据结构

• 最大可接受延迟

• 最低可接受吞吐量

• 系统终端用户的典型访问模式

你的数据结构不仅影响你用来处理它的工具，还影响你存储它的位置。数据的排序以及每个存储和检索的对象大小也是重要的考虑因素。你的解决方案如何权衡延迟/吞吐量与成本决定了回答问题所需的时间。

用户访问模式是另一个需要考虑的关键因素。有些任务需要定期连接多个相关表，而其他任务则需要进行日常或不太频繁的数据存储。有些任务需要比较来自广泛数据源的数据，而其他任务只从一个非结构化表中提取数据。了解终端用户最常如何使用数据将帮助你确定大数据架构的广度和深度。让我们深入探讨每个过程及其涉及的工具。

数据摄取、存储、处理和分析

为了将原始数据转化为可以为企业决策和战略规划提供信息的可操作智能，数据需要通过几个关键阶段进行管理，从数据摄取开始——即从各种来源收集数据。这可以包括从用户生成的数据到机器日志，或者实时流数据。一旦收集，数据需要存储在数据存储中，这可以通过数据库、数据湖或云存储解决方案来实现，具体取决于数据类型和预期用途。

在存储之后，数据处理和分析进入关键环节，涉及对数据进行排序、聚合或转换为更易用的形式，之后可以对处理后的数据进行分析，提取有意义的洞察。分析可以从简单的查询和报告到复杂的机器学习算法和预测建模等多种形式。让我们详细了解这些阶段。

数据摄取

数据摄取是收集数据以进行传输和存储的行为。数据可以从很多地方进行摄取，主要分为数据库、流、日志和文件这几类。在这些类别中，数据库最为常见。这些数据库通常由应用程序的主要上游事务性系统组成，是数据的主要存储方式。它们可以是关系型数据库或非关系型数据库，并且有多种技术可以从中提取数据。

流是开放式的时间序列数据序列，例如来自网站的点击流数据或物联网（IoT）设备数据，通常通过我们托管的 API 发布。应用程序、服务和操作系统会生成日志。如下面的图所示，使用你所在环境收集的数据类型及其收集方式，来决定最适合你需求的摄取解决方案：

图 12.3：数据摄取类型

如图所示，事务性数据存储必须能够快速存储和检索数据。最终用户需要快速、简便的数据访问，这使得应用程序和 Web 服务器成为理想的摄取方式。出于同样的原因，NoSQL 和关系数据库管理系统（RDBMS）数据库通常是此类过程的最佳解决方案。

通过单个文件传输的数据通常来自连接的设备。与事务性数据相比，大量文件数据不需要快速存储和检索。对于文件数据，通常是单向传输，其中数据由多个资源生成，并摄取到单一的对象或文件存储中以备后用。

流数据，如点击流日志，应通过适当的解决方案摄取，例如Apache Kafka或Fluentd。Apache Kafka 是一个流行的选择，提供强大的发布-订阅功能，能够高效地处理大量数据。Fluentd 是另一种可用于数据摄取的工具，特别以其日志聚合能力而闻名。

最初，这些日志存储在流存储解决方案中，例如 Kafka，这样它们就可以进行实时处理和分析。长期存储这些日志，最好的方式是选择低成本的存储方案，如对象存储。

流式存储将你的数据采集系统（生产者）与处理系统（消费者）解耦。它为你的来数据提供持久的缓冲区。数据可以根据你的需求以不同的速率进行处理和传输。让我们了解一些流行的数据导入技术。

数据导入的技术选择

让我们看看一些流行的开源数据导入和传输工具：

• Apache DistCp：DistCp 代表分布式复制，是 Hadoop 生态系统的一部分。DistCp 工具用于在集群内或集群之间复制大量数据。DistCp 通过利用 MapReduce 的并行处理分发能力，实现了高效和快速的数据复制。它将目录和文件分发为映射任务，从源到目标复制文件分区。DistCp 还在集群间进行错误处理、恢复和报告。

• Apache Sqoop：Sqoop 也是 Hadoop 生态系统的一部分，帮助在 Hadoop 和关系型数据存储（如 RDBMS）之间转移数据。Sqoop 允许将数据从结构化数据存储导入到Hadoop 分布式文件系统（HDFS），并将数据从 HDFS 导出到结构化数据存储。Sqoop 使用插件连接器连接到关系数据库。你可以使用 Sqoop 扩展 API 构建新的连接器，或者使用其中之一支持 Hadoop 和标准关系数据库系统之间数据交换的连接器。

• Apache Flume：Flume 是开源软件，主要用于导入大量日志数据。Apache Flume 可靠地收集和汇总数据，并将其分发到 Hadoop。Flume 促进了流式数据导入，并支持分析。

更多开源项目，如 Apache Storm 和 Apache Samza，可用于流处理，可靠地处理无界数据流。

将数据导入云端

将数据导入云端对于管理和利用大数据至关重要。三大云服务提供商——AWS、Google Cloud Platform（GCP）和 Azure——提供各种数据导入服务。每个服务商都有独特的功能和能力，适用于不同的需求和数据量。让我们来看看这三家云服务商的一些独特特点：

• AWS 数据导入服务：

  • AWS Direct Connect：提供一个高速、私有的网络连接到 AWS，减少延迟并增加带宽。它非常适合转移大量数据，并提供比基于互联网的传输更稳定的网络速度。

  • AWS Snowball 和 Snowmobile：这些服务提供用于将大量数据（以 TB 和PB（PBs）为单位）转移到 AWS 的物理设备。Snowball 适用于数百 TB，而 Snowmobile 则可以处理单次转移高达 100PB 的数据，适合处理庞大的数据集。

  • AWS 数据库迁移服务（DMS）：该服务帮助将数据库迁移到 AWS，支持同构和异构迁移，并能通过变更数据捕获（CDC）处理持续的数据复制。

• GCP 数据摄取服务：

  • Google Cloud 存储转移服务：该服务允许从在线数据源（如 Amazon S3 和 HTTP/HTTPS 位置）以及本地数据存储将大量数据转移到 Google Cloud Storage。

  • Pub/Sub：该服务提供实时消息传递和流数据摄取。它是一个可扩展且灵活的服务，能够摄取如日志和事件数据等流数据，以进行实时分析。

  • 数据流：一个集成服务，既支持数据摄取也支持数据处理。它非常适合提取、转换和加载（ETL）任务以及实时事件流处理。

• Azure 数据摄取服务：

  • Azure 数据工厂：该数据集成服务支持本地和云端数据的迁移与转换。它可以从各种数据源摄取数据，利用计算服务如 Azure HDInsight 和 Azure Batch 处理数据，并将处理后的数据发布到如 Azure SQL 数据仓库等存储解决方案。

  • Azure 事件中心：一个强大且可扩展的数据流平台和事件摄取服务，Azure 事件中心能够每秒处理数百万个事件，使其成为处理来自各种来源（如应用程序、网站或物联网设备）的实时数据分析的理想解决方案。

  • Azure 导入/导出服务：该服务旨在支持大数据量的批量传输到 Azure Blob 存储和 Azure Files，利用物理磁盘进行数据传输，是在网络传输大数据量可能过慢或过于昂贵的情况下的理想选择。

每个云服务提供商都提供一套独特的工具，以满足各种数据摄取需求，从实时流数据到大规模数据迁移，确保大数据管理中的灵活性和可扩展性。

流数据的摄取与分析变得越来越重要。你将在流数据存储部分了解更多关于流数据的内容。让我们进一步了解你可以使用的技术，帮助你选择合适的存储及其可用的选择。

存储数据

在为大数据环境配置存储时，最常见的错误之一是使用单一解决方案，通常是关系数据库管理系统（RDBMS）来处理所有数据存储需求。

你将有许多工具可用，但它们需要针对它们需要完成的任务进行优化。一个解决方案不一定是满足你所有需求的最佳选择；对于你的环境，最好的解决方案可能是多种存储方案的结合，这些方案能够仔细平衡延迟与成本。理想的存储解决方案使用适合特定任务的工具。下图结合了与你的数据和相关存储选择相关的多个因素：

图 12.4：理解数据存储

如下图所示，选择数据存储方案取决于以下因素：

• 你的数据结构化程度如何？ 它是否遵循特定的、格式良好的架构，例如 Apache 日志（日志通常结构不佳，不适合关系型数据库）、标准化的数据协议和合同接口？还是完全任意的二进制数据，例如图像、音频、视频和 PDF 文档？或者它是半结构化的，具有一般的结构，但记录间可能存在较大的变化，例如 JSON 或 CSV？

• 新数据需要多快才能供查询使用？ 是实时场景，决策会随着新记录的流入而做出，例如活动经理根据转化率调整，或者网站根据用户行为相似性做出产品推荐？还是日常、每周或每月批量处理场景，例如模型训练、财务报表准备或产品性能报告？或者是介于两者之间的场景，例如用户参与邮件，它不需要实时响应，你可以在用户行为与触发点之间有几分钟甚至几小时的缓冲时间？

• 数据摄取的大小是多少？ 数据是否随着记录的到来而被摄取，例如 REST API 中的 JSON 负载，最佳情况下至少为几 KB？是大量记录同时到达，例如系统集成和第三方数据源？还是介于两者之间，例如通过聚合几个微批次的点击流数据来进行更高效的处理？

• 数据的总量及其增长率是多少？ 你是在 GB 或 TB 范围内，还是打算存储 PB 或 EB（艾克萨字节）级别的数据？这些数据中有多少是你的特定分析用例所需的？你大多数查询是否仅需要特定的滚动时间窗口？或者，你是否需要一个机制来查询整个历史数据集？

• 存储和查询数据在特定位置的成本是多少？在任何计算环境中，我们通常会看到性能、韧性和低成本之间的约束三角。你希望存储的性能和韧性越好，它的成本就越高。你可以对 PB 级别的数据进行快速查询，但为了满足成本要求，你可以选择以压缩格式查询 TB 级别的数据。

最后，针对数据将运行什么类型的分析查询？它是为具有固定指标集并支持深入分析的仪表盘提供数据吗？它会参与由不同业务维度汇总的大型数值聚合吗？还是它将用于诊断，利用字符串标记化进行全文搜索和模式分析？

当你确定了数据的特征并了解了数据结构后，你可以评估需要使用什么解决方案来存储数据。让我们了解一下用于存储数据的各种解决方案。

数据存储的技术选择

正如我们所讨论的，单一工具只能完成少数任务。你应该根据不同的工作选择合适的工具，数据湖让你能够构建一个高度可配置的大数据架构，以满足你的特定需求。业务问题需要更具体、更深刻、更复杂，单一工具无法解决一切，尤其是在大数据和分析方面。

例如，热数据需要在内存中存储和处理，因此缓存或内存数据库如 Redis 或 SAP HANA 是合适的选择。AWS 提供了 ElastiCache 服务，提供托管的 Redis 或 memcached 环境。当面对高速但小型的记录时，NoSQL 数据库是理想的选择，例如用户会话信息或物联网数据。NoSQL 数据库也适用于内容管理，用于存储数据目录。让我们了解一下最常用的结构化数据存储。

结构化数据存储

结构化数据存储已经存在了几十年，是存储数据最熟悉的技术选择。大多数事务性数据库，如 Oracle、MySQL、SQL Server 和 PostgreSQL，都是基于行的，因为它们需要处理来自软件应用程序的频繁数据写入。组织通常会重新利用事务性数据库用于报告目的，这需要频繁的数据读取，但数据写入较少。随着对数据读取需求的增加，更多的创新正进入结构化数据存储的查询方式，例如列式文件格式，这有助于提高分析需求的数据读取性能。

基于行的格式将数据以行的形式存储在文件中。基于行的写入是将数据写入磁盘的最快方式，但并不一定是最快的读取选项，因为你需要跳过大量不相关的数据。基于列的格式将所有列的值一起存储在文件中，这有助于更好的压缩，因为相同的数据类型会被分组。它通常还提供更好的读取性能，因为你可以跳过不需要的列。

让我们看看结构化数据存储的常见选择。例如，您需要从包含五十列的订单表中查询某个月的总销售额。使用行式架构时，查询将扫描整个表的所有五十列。而在列式架构中，查询将只扫描订单销售列，从而提高数据查询性能。让我们进一步了解关系型数据库，专注于事务数据和数据仓库，以应对数据分析的需求。

关系型数据库

关系型数据库管理系统（RDBMS）更适用于在线事务处理（OLTP）应用。一些流行的关系型数据库包括 Oracle、MSSQL、MariaDB、PostgreSQL 等。这些传统数据库中的一些已经存在了几十年。许多应用程序，包括电子商务、银行业务和酒店预订，都是由关系型数据库支撑的。关系型数据库非常擅长处理需要在表之间进行复杂连接查询的事务数据。从事务数据的需求来看，关系型数据库应遵循原子性、一致性、隔离性和持久性（ACID）原则，如下所示：

• 原子性：原子性意味着事务将从头到尾完整执行，如果发生任何错误，整个事务将回滚。

• 一致性：一致性意味着所有数据在事务完成时应该被提交到数据库。

• 隔离性：隔离性要求多个事务可以并发执行，并且互不干扰。

• 持久性：在发生中断（如网络或电力故障）时，事务应能恢复到最后已知的状态。

关系型数据库中的数据通常会被卸载到数据仓库解决方案中，以进行报告和聚合处理。让我们深入了解数据仓库的更多内容。

数据仓库

数据仓库是存储来自一个或多个来源的数据积累的中央存储库。它们存储当前和历史数据，帮助创建业务数据分析的分析报告。然而，数据仓库集中存储来自各种系统的数据，但不能将其视为数据湖。数据仓库只处理结构化的关系型数据，而数据湖则可以处理结构化和非结构化数据，如 JSON 日志和 CSV 数据。

数据仓库数据库更适用于在线分析处理（OLAP）应用。这些数据库经过优化，能够处理涉及大量数据读取的操作，从而实现数据的聚合和汇总，提取有价值的业务洞察。

以银行场景为例，假设某银行维护一个数据仓库，存储关于客户账户、交易、贷款详情和分支信息的全面数据。此外，银行还收集并存储客户互动、服务使用和在线银行活动的数据，存在于相关系统中。

通过 OLAP，银行可以对这些合并的数据进行复杂分析。它可以查询数据仓库，发现趋势，例如识别最受欢迎的账户或贷款类型、分析交易量随时间的变化，或评估线上与分行银行服务的使用模式。这种分析能力使得银行能够做出有关产品提供、客户服务改进和运营策略的明智决策，从而提升客户满意度并推动业务增长。

数据仓库提供对大量结构化数据的快速聚合能力。虽然像 Amazon Redshift、Netezza 和 Teradata 这样的技术被设计用来快速执行复杂的聚合查询，但它们必须针对高并发写入进行优化。因此，数据需要分批加载，这使得数据仓库无法提供对热数据的实时洞察。

现代数据仓库使用列式存储来增强查询性能。此类数据仓库的例子包括 Amazon Redshift、Snowflake 和 Google BigQuery。由于列式存储和提高的 I/O 效率，这些数据仓库提供了快速的查询性能。此外，像 Amazon Redshift 这样的数据仓库系统通过将查询并行化处理，跨多个节点执行，并利用大规模并行处理（MPP），进一步提高了查询性能。

列式存储通过将数据按列而非按行存储，增强了查询性能，支持更有效的数据压缩、选择性数据读取和更快的操作。该方法允许更有效的压缩，因为相似的数据按顺序存储，这有助于在查询时仅访问必要的列，从而加速数据检索。它还通过将相关数据加载到内存中，优化了 CPU 缓存的利用率，提高了处理速度。此外，列式存储支持大规模并行处理，多个处理器可以同时处理不同的数据片段，显著提升了涉及大型数据集并需要快速聚合和过滤的分析任务的性能。

像 Amazon Redshift 这样的数据仓库解决方案可以处理 PB 级别的数据，并提供解耦的计算和存储能力以节省成本。除了列式存储，Redshift 还使用数据编码、分布和区域映射来提升查询性能。更传统的行式数据仓库解决方案包括 Netezza、Teradata 和 Greenplum。

数据仓库导致不同应用程序的数据物理分离，迫使数据架构师围绕这些仓库构建新的基础设施。随着企业数据的多样性增加，包括文本、物联网数据、图像、音频和视频，传统数据仓库的局限性变得更加明显。此外，机器学习和人工智能（AI）的出现带来了迭代算法，这些算法需要直接访问数据，而不依赖 SQL，从而突显了传统数据仓库模型的局限性。你将在本章后续的设计大数据架构部分了解如何克服这些挑战。

NoSQL 数据库

NoSQL 数据库，如 DynamoDB、Cassandra 和 MongoDB，解决了你在关系型数据库中常遇到的扩展性和性能问题。顾名思义，NoSQL 是一种非关系型数据库。NoSQL 数据库存储数据时没有明确和结构化的机制将来自不同表的数据链接起来（没有连接、外键或强制规范化）。

NoSQL 利用多种数据模型，包括列式、键值、搜索、文档和图形。NoSQL 数据库提供可扩展的性能、高可用性和弹性。NoSQL 通常不强制执行严格的模式，每个项可以有任意数量的列（属性），这意味着同一表中的一行可能只有四列，而另一行可能有十列。分区键用于检索包含相关属性的值或文档。NoSQL 数据库高度分布式，可以进行复制。它们是持久的，并且在高度可用的情况下不会遇到性能问题。

SQL 与 NoSQL 数据库的对比

SQL 数据库已存在数十年，大多数人已经熟悉关系型数据库。让我们了解一下 SQL 和 NoSQL 数据库之间的一些显著区别：

属性	SQL 数据库	NoSQL 数据库
数据模型	SQL 数据库中的关系模型将数据规范化为包含行和列的表。一个模式包括表、列、表之间的关系、索引以及其他数据库元素。	NoSQL 数据库在不强制执行固定模式的情况下运行，提供了在数据存储和检索方面的灵活性。它们通常利用分区键从列集访问值。这种类型的数据库非常适合存储半结构化数据，包括 JSON、XML 等格式，以及各种其他文档类型，如数据目录和文件索引。
事务	基于 SQL 的传统关系数据库管理系统（RDBMS）支持并符合 ACID 事务数据属性。	NoSQL 数据库有时会牺牲某些 ACID 属性，这些属性是传统 RDBMS 的特征，以便促进横向扩展并增强数据模型的灵活性。
性能	基于 SQL 的关系型数据库（RDBMS）曾用于在存储昂贵时优化存储，并最小化磁盘占用。对于传统的关系型数据库系统，性能主要依赖于磁盘。需要创建索引和修改表结构来实现性能查询优化。	在 NoSQL 系统中，性能受多种因素的显著影响，例如底层硬件集群的规模、网络延迟以及应用程序与数据库交互的方式。
扩展性	基于 SQL 的关系型数据库（RDBMS）在高配置硬件的支持下，垂直扩展最为直接。额外的工作需要将关系表扩展到分布式系统，例如执行数据分片。	NoSQL 数据库旨在水平扩展，利用由经济型硬件组成的分布式集群。该方法旨在提高吞吐量，同时最小化对延迟的影响。

表 12.1 – SQL 与 NoSQL 数据库对比

根据你的数据类型，存在多种类别的 NoSQL 数据存储，用于解决特定问题。让我们了解一下 NoSQL 数据库的类型。

NoSQL 数据库的类型

以下是主要的 NoSQL 数据库类型：

• 列式数据库：Apache Cassandra 和 Apache HBase 是常见的列式数据库。列式数据存储可以帮助你在查询数据时扫描特定的列，而不是扫描整行数据。假设一个商品表有十列和一百万行数据，如果你想查询库存中商品的数量，列式数据库会将查询应用到商品数量这一列，而不是扫描整个表。

• 文档数据库：一些最流行的文档数据库有 MongoDB、Couchbase、MarkLogic、DynamoDB、DocumentDB 和 Cassandra。你可以使用文档数据库以 JSON 和 XML 格式存储半结构化数据。

• 图数据库：流行的图数据库有 Amazon Neptune、JanusGraph、TinkerPop、Neo4j、OrientDB、GraphDB 和 Spark 中的 GraphX。图数据库存储顶点和顶点之间的连接，称为 边。图可以建立在关系型和非关系型数据库之上。

• 内存键值存储：一些最流行的内存键值存储有 Redis 和 Memcached。它们将数据存储在内存中，以支持重度读取应用。任何来自应用的查询首先会访问内存数据库，如果数据已存在于缓存中，就不会访问主数据库。内存数据库适用于存储用户会话信息，这些信息会涉及复杂的查询和频繁请求数据，例如用户资料。

NoSQL 有许多应用场景，但你必须为所有数据建立索引才能进行搜索。让我们来了解一下搜索数据存储。

搜索数据存储

Elasticsearch 服务是最受欢迎的大数据搜索引擎之一，广泛应用于点击流分析和日志分析等大数据场景。搜索引擎非常适合处理可以按需查询的“热数据”，这些数据可以跨多个属性进行查询，包括字符串标记。

Amazon OpenSearch 服务提供数据搜索功能，并支持开源的 Elasticsearch 集群，包括 API 访问。它还提供 Kibana 作为可视化机制，用于搜索已索引的数据存储。AWS 负责集群的容量管理、扩展和补丁处理，消除了任何操作上的开销。日志搜索和分析是 OpenSearch 的一个热门大数据应用场景，它帮助你分析来自网站、服务器群集、物联网传感器等的日志数据。银行、游戏、营销、应用监控、广告技术、欺诈检测、推荐系统以及物联网等行业的各种应用都利用 OpenSearch 和 Elasticsearch。基于机器学习的搜索服务，如 Amazon Kendra，也提供更先进的搜索能力，利用自然语言处理（NLP）。

非结构化数据存储

当你考虑非结构化数据存储的需求时，Hadoop 是一个完美的选择，因为它可扩展、可扩展且非常灵活。它可以运行在消费者硬件上，拥有庞大的工具生态系统，并且看起来具有成本效益。Hadoop 使用主从节点模型，其中数据在多个子节点之间分配，主节点协调任务以对数据进行查询。Hadoop 系统基于 MPP（大规模并行处理），使得在所有数据类型（无论是结构化还是非结构化数据）上执行查询变得快速。

当创建一个 Hadoop 集群时，从服务器创建的每个子节点都会附带一块称为本地 HDFS 磁盘存储的磁盘存储块。你可以使用常见的处理框架（如 Hive、Pig 和 Spark）对存储的数据进行查询。然而，本地磁盘上的数据仅在相关实例的生命周期内存在。

如果你使用 Hadoop 的存储层（HDFS）来存储数据，你就将存储和计算结合在一起。增加存储空间意味着需要添加更多的机器，这也增加了计算能力。为了最大化灵活性和成本效益，你需要将计算和存储分开，并独立扩展它们。总体而言，对象存储更适合用来存储数据湖中的各种数据，能够以成本效益高且高效的方式存储数据。由对象存储支持的基于云的数据湖提供灵活性，可以将计算和存储解耦。让我们进一步了解对象存储。

对象存储

对象存储指的是使用单元（通常称为对象）存储和访问的数据，这些对象存储在桶中。在对象存储中，文件或对象不会被拆分成数据块，而是将数据和元数据一起存储。桶中存储的对象数量没有限制，且它们是通过 API 调用（通常通过HTTP、GET 或 PUT）来读取和写入桶中的数据。通常，对象存储不会作为操作系统上的文件系统挂载，因为基于 API 的文件请求的延迟以及缺乏文件级锁定会导致作为文件系统的性能较差。

对象存储提供了扩展性，并且具有平坦的命名空间，减少了管理开销和元数据管理。随着公共云的普及，对象存储变得越来越流行，并且是构建云中可扩展数据湖的首选存储方案。Amazon S3、Azure Blob Storage 和 Google Cloud Storage（GCP）是最受欢迎的对象存储选项。

向量数据库（VectorDB）

VectorDB 最近因为生成式 AI 和机器学习的关注度提高而变得非常流行。向量数据通常指高维数据点，通常用于机器学习模型的上下文中。例如，图像、文本或音频文件可以被转换为向量表示（一个数字列表），以捕捉其核心特征。这些向量被用于机器学习任务，如相似性搜索（寻找最相似的项目）、聚类或分类。例如，如果你想进行客户细分，可以使用向量嵌入将客户根据其购买行为或偏好聚类成不同的群体。通过分析客户的购买历史或与网站的互动的向量表示，企业可以识别出相似客户的不同群体。这样，企业可以定制营销策略、个性化优惠，或为每个特定客户群体开发有针对性的产品，从而提升客户满意度和忠诚度。

VectorDB 或向量数据库是数据库技术领域中新兴的一类，主要聚焦于高效处理向量数据。这种数据类型通常与机器学习相关，尤其是在图像识别、自然语言处理（NLP）和推荐系统等领域。

向量数据库的核心功能是高效存储和管理向量数据。这涉及到存储高维数据点，并优化数据库架构，以支持快速高效的查询，通常以最近邻搜索的形式进行。

高级向量数据库可能会将机器学习模型直接集成到数据库中，从而实现实时将原始数据（如图像或文本）转换为向量，然后可以存储或查询这些向量。

一个常见的使用案例是找到与给定查询项相似的项目。例如，数据库可以快速检索与查询图像最相似的图像用于图像搜索。向量数据库可以通过将用户资料与产品向量匹配来为推荐引擎提供支持，从而建议相关的商品。它们还可以高效地处理和查询大规模的文本数据，将其转换为向量空间，以支持各种自然语言处理应用。以下是VectorDB的优点：

• 速度和效率：专门针对处理高维数据优化的向量数据库，比传统数据库执行相似性搜索要快得多。

• 可扩展性：它们设计为能随着数据量的增长进行扩展，这对于机器学习应用尤为重要，因为数据集通常非常庞大。

• 与 ML/AI 管道的集成：与 ML 工作流的无缝集成，允许直接查询和操作向量数据。

让我们也来看看VectorDB的一些缺点：

• 复杂性：管理和索引高维向量数据可能会非常复杂。

• 资源密集型：这些数据库可能需要大量计算资源，尤其是在处理大规模数据集时。

• 新兴技术：由于相对较新，围绕向量数据库的生态系统可能不如传统数据库成熟，这可能是企业采用时需要考虑的因素。

向量数据库是朝向专门化数据库的一部分趋势，专为特定类型的数据和工作负载设计，尤其是在机器学习和人工智能领域。它们代表了数据库技术发展的重要一步，跟上数据科学和分析进展的步伐。随着这项技术的成熟，它很可能成为重度投资于机器学习和人工智能的组织数据基础设施的核心组成部分。

区块链数据存储

区块链技术通常与加密货币相关联，提供了一种在金融以外的多个行业中变革性的数据管理和交易处理方法。区块链数据存储为去中心化验证提供了一种强大的机制，根本改变了交易如何在各个行业中记录和验证。在基于区块链的土地登记系统中，例如，每一笔涉及房地产买卖的交易都会记录在共享的账本上，所有网络参与者可以即时访问和验证。这种透明性与传统的中心化系统形成了对比，后者由单一权威机构管理数据，从而减少了欺诈风险，并增强了参与者之间的信任。

区块链的不可篡改性和安全性特点进一步增加了其在各个行业中的应用。例如，在医疗领域，区块链确保一旦患者记录被录入系统，就保持不变且安全。这种不可篡改性对医疗专业人员至关重要，因为他们依赖于准确的历史数据来做出治疗决策。此外，区块链的加密安全性保护了敏感的健康信息，只允许授权用户访问，从而确保患者隐私。这些特性使区块链在数据完整性和安全性至关重要的行业中成为宝贵的工具。

为了实现不可篡改性，区块链网络发挥了关键作用。区块链是一种去中心化的数字账本，用于记录多个计算机中的交易，从而确保数据的完整性和安全性。在区块链网络中，交易被打包成区块，每个区块都与前一个区块相链接，形成一条链。这种结构使得没有网络参与者的共识，几乎不可能事后修改信息。以下是区块链网络的几种类型：

• 公有区块链：以太坊通常用于去中心化应用（DApps）和智能合约。以太坊是开放的，任何人都可以加入并参与网络。例如，开发者可能会在以太坊网络上创建一个去中心化金融（DeFi）的 DApp，允许用户进行不依赖传统银行的金融交易。

• 私有区块链：这种类型的区块链由一个组织进行限制和控制，提供更多的隐私性和控制权。例如，一家制药公司可能会使用私有区块链来管理其药物研发过程。区块链的访问权限仅限于公司研究人员和监管机构，确保敏感数据保持机密。

• 联盟区块链：这涉及多个组织共同管理一个区块链网络，平衡去中心化和控制的关系。一个例子是，一群航运公司组成联盟，共同管理一个共享的区块链。这个区块链可以用于追踪全球范围内的货物运输，每家公司在网络中维护一个节点。

像亚马逊网络服务（AWS）这样的云服务提供商提供区块链即服务，简化了区块链网络的设置和管理。亚马逊量子账本数据库（QLDB）是一个集中的账本数据库的例子，它提供不可篡改和加密验证的交易记录。流行的托管区块链服务包括亚马逊托管区块链（AMB）、R3 Corda、以太坊和Hyperledger，满足从金融交易到供应链管理等各种需求。

流数据处理曾经是一个小众技术，但现在它变得越来越普遍，因为每个组织都希望从实时数据处理中获取快速的洞察。让我们了解更多关于流数据存储的信息。

流数据存储

流数据具有持续的数据流，没有开始和结束。来自各种实时资源的大量数据，如股票交易、自动驾驶汽车、智能空间、社交媒体、电商、游戏、打车应用等，需要快速存储和处理。Netflix 根据你正在观看的内容提供实时推荐，Lyft 利用流技术将乘客与司机实时连接。

存储和处理流数据具有挑战性，因为数据是持续不断流入的，且无法预测存储容量。除了数据量大，流数据的速度也非常快，这需要一个可扩展的存储系统来存储数据并提供回放的能力。随着时间推移，数据流可能会变得非常昂贵且管理复杂。流数据存储的流行服务有 Apache Kafka、Apache Flink、Apache Spark Structured Streaming、Apache Samza 和 Amazon Kinesis。AWS 提供了托管 Kafka 服务，称为 Amazon Managed Streaming for Kafka。让我们深入了解流数据摄取和存储技术：

• Amazon Kinesis：Amazon Kinesis 提供了三种能力。第一种是Kinesis Data Streams（KDS），它是一个存储原始数据流的地方，用于对所需记录进行下游处理。第二种是Amazon Kinesis Data Firehose（KDF），它促进将这些记录传输到常见的分析环境，如 Amazon S3、Elasticsearch、Redshift 和 Splunk。Firehose 会自动缓冲所有流中的记录，并根据你配置的时间或数据大小阈值，或第一个达到的条件，将记录作为单个文件或一组记录刷新到目标位置。

• 第三种是Kinesis Data Analytics（KDA），它使用 Apache Flink 对流记录进行分析。输出结果随后可以流入你创建的进一步流，以构建一个完整的无服务器流处理管道。

• Amazon Managed Streaming for Kafka（MSK）：MSK 是一个完全托管的、高可用且安全的服务。Amazon MSK 在 AWS 云中运行基于 Apache Kafka 的应用程序，无需 Apache Kafka 基础设施管理的专业知识。Amazon MSK 提供一个托管的 Apache Kafka 集群和一个 ZooKeeper 集群，用于维护配置并构建数据摄取和处理的生产者/消费者。

• Apache Flink：Flink 是另一个开源平台，用于流数据和批量数据处理。Flink 由一个流数据处理引擎组成，可以处理有界和无界数据流。一个有界数据流有明确的开始和结束，而无界数据流有开始但没有结束。Flink 可以在其流引擎上执行批处理，并支持批优化。

• Apache Spark 流处理：Spark 流处理帮助以高吞吐量和容错、可扩展的方式摄取实时数据流。Spark 流处理将传入的数据流分成多个批次，然后发送到 Spark 引擎进行处理。Spark 流处理使用 DStreams，DStreams 是 弹性分布式数据集（RDDs）的序列。

• Apache Kafka：Kafka 是最流行的开源流处理平台之一，帮助您发布和订阅数据流。Kafka 集群将记录的流存储在 Kafka 主题中。生产者可以在 Kafka 主题中发布数据，消费者可以通过订阅 Kafka 主题来获取输出数据流。

• 流式存储需要持续保存数据流，并在必要时提供保持顺序的能力。您将在接下来的部分中了解更多关于流式架构的内容，流式数据架构。

云数据存储

云数据存储是现代 IT 基础设施中的关键方面，提供了可扩展性、灵活性和成本效益。领先的云服务提供商 —— AWS、GCP 和 Azure —— 提供了多种数据存储选项，以满足不同需求，从简单的文件存储到复杂的数据库和数据仓库解决方案。以下列出了这些平台上云数据存储的主要特点。

• AWS：

  • Amazon 简单存储服务 (S3)：这是一种高度可扩展的对象存储服务，以其高数据可用性、安全性和性能而闻名。Amazon S3 功能多样，适用于存储各种场景下的数据量，如网站、移动应用、备份与恢复、档案存储、企业应用、物联网设备和大数据分析。

  • Amazon 弹性块存储 (EBS)：EBS 为 EC2 实例提供块级存储卷。它特别适合需要一致和低延迟性能的数据，如数据库或 ERP（企业资源规划）系统。

  • Amazon 关系数据库服务 (RDS)：RDS 简化了在云中设置、操作和扩展关系数据库的过程。它提供具有可调容量的高性价比解决方案，同时自动化了许多与数据库管理相关的耗时任务。

  • Amazon S3 Glacier：此服务为归档和长期备份提供安全、持久和低成本的云存储。Amazon S3 Glacier 适合存储访问频率较低的数据，提供长期数据保留的解决方案。

• GCP：

  • Google Cloud Storage：为各类公司提供对象存储。它高度可扩展且灵活，为高需求应用和工作负载提供安全、持久的存储。

  • 持久磁盘：为 Google Compute Engine 实例提供块存储。它提供高性能的 SSD 和 HDD 存储，可以附加到运行在 Compute Engine 或 Google Kubernetes Engine（GKE）上的实例。

  • Cloud SQL：一个完全托管的数据库服务，使得在 Google Cloud 上设置、维护、管理和操作关系型数据库变得更加简单。

  • Google Cloud Bigtable：一个可扩展、完全托管的 NoSQL 数据库服务，适用于大规模的分析和操作工作负载。

• Microsoft Azure：

  • Azure Blob 存储：这是 Azure 的面向云的对象存储解决方案。它在存储大量非结构化数据（如文本或二进制数据）方面表现卓越。它包括各种类型的内容，如文档、媒体文件、备份和日志，使其在广泛的使用场景中具有高度的灵活性。

  • Azure 文件存储：提供基于云的、完全托管的文件共享，使用标准的 SMB 协议进行访问。此服务对于希望将现有本地文件共享迁移到云环境的企业尤其有用。

  • Azure SQL 数据库：一个全面的、完全托管的云关系型数据库服务。它提供了 SQL Server 的功能，但无需大量的基础设施和数据库管理任务，从而简化了数据库管理。

  • Azure 磁盘存储：这提供了高性能、可靠的块存储，用于 Azure 虚拟机。Azure 磁盘存储包括 SSD 和 HDD 选项，满足从高速性能到成本效益等各种需求。

跨这些平台的云数据存储服务旨在提供安全、可扩展且易于访问的存储解决方案，适应各种应用和使用场景。每项服务都有其特定的优势，适用于不同的性能、可扩展性、数据访问和成本要求。

一旦你采集并存储了数据，按所需结构处理数据是至关重要的，这样才能可视化并分析这些数据，从而得出商业洞察。让我们进一步了解数据处理和转换。

数据处理和执行分析

数据分析是将数据采集、转换和可视化的过程，用于发现有价值的商业决策洞察。在过去的十年里，收集的数据比以往任何时候都多，客户希望能从他们的数据中获得更多的洞察。

这些客户还希望在最短的时间内获得这些洞察，有时甚至是实时的。他们希望能通过更多的即席查询来回答更多的商业问题。为了回答这些问题，客户需要更强大和高效的系统。

批处理通常涉及查询大量的冷数据。在批处理过程中，可能需要数小时才能回答业务问题。例如，你可能会使用批处理在月末生成账单报告。实时流处理通常涉及查询少量的热数据，并且只需很短的时间就能得到答案。基于 MapReduce 的系统（如 Hadoop）是支持批处理作业的平台示例，而数据仓库则是支持查询引擎平台的示例。

流数据处理活动摄取数据序列，并根据每条数据记录逐步更新功能。通常，它们会摄取持续产生的数据流记录，如计量数据、监控数据、审计日志、调试日志、网站点击流和设备、人员及实物商品的定位追踪事件。

以下图示展示了一个数据湖流水线，利用 AWS 云技术栈来处理、转换和可视化数据：

图 12.5：用于大数据处理的数据湖 ETL 流水线

在这里，ETL 流水线使用 Amazon Athena 对存储在 Amazon S3 中的数据进行临时查询。来自各种数据源（例如，Web 应用服务器）摄取的数据生成日志文件，这些日志文件会持久化到 S3 中。然后，这些文件通过使用 Amazon Elastic MapReduce（EMR）进行转换和清洗，形成一个有意义洞察所需的统一格式，并加载到 Amazon S3 中。Amazon EMR 提供了一个托管的 Hadoop 服务器，用于在云中使用各种开源技术（如 Hive、Pig 和 Spark）进行数据处理。

这些转换后的文件通过 COPY 命令加载到 Amazon Redshift 中，并使用 Amazon QuickSight 进行可视化。通过使用 Amazon Athena，你可以在数据存储和转换后（包括汇总数据集）直接从 Amazon S3 查询数据。你可以通过 Amazon QuickSight 可视化 Athena 中的数据。你可以轻松查询这些文件，而无需改变现有的数据流。

让我们来看一些流行的数据处理工具。

数据处理与分析的技术选择

以下是一些最受欢迎的数据处理技术，它们帮助你对大量数据进行转换和处理：

• Apache Hadoop 使用分布式处理架构，在该架构中，任务被映射到一群商品服务器上进行处理。分配到集群服务器上的每一项工作可以在任何服务器上运行或重新运行。集群服务器通常使用 HDFS 将数据本地存储以供处理。Hadoop 框架将一个大任务拆分为离散的任务，并进行并行处理。它支持在大量 Hadoop 集群上进行大规模扩展。它还设计了容错机制，每个工作节点定期将其状态报告给主节点，主节点可以从未响应的集群重新分配工作。与 Hadoop 一起使用的一些最受欢迎的框架包括 Hive、Presto、Pig 和 Spark。

• Apache Spark 是一个内存处理框架。Apache Spark 是一个大规模并行处理系统，具有不同的执行器，可以将 Spark 作业拆解并并行运行任务。为了提高作业的并行度，可以向集群添加节点。Spark 支持批处理、交互式和流式数据源。Spark 使用 有向无环图（DAGs）来执行作业的所有阶段。DAGs 可以跟踪作业期间的数据或血统变换，并通过将 DataFrames 存储在内存中有效地最小化 I/O。Spark 还具有分区感知功能，以避免网络密集型的洗牌操作。

• Hadoop 用户体验（HUE）允许你通过基于浏览器的 用户界面（UI）而不是命令行，在集群上运行查询和脚本。HUE 提供了 UI 中最常用的 Hadoop 组件。它支持基于浏览器的查看和跟踪 Hadoop 操作。多个用户可以通过 HUE 的登录门户访问集群，管理员可以手动或通过 轻量目录访问协议（LDAP）、可插拔认证模块（PAM）、简单和保护的 GSSAPI 协商机制（SPNEGO）、OpenID、OAuth 和 安全声明标记语言 2.0（SAML2）认证来管理访问。HUE 允许实时查看日志，并提供元存储管理器来操作 Hive 元存储内容。

• Pig 通常用于在将大量原始数据存储为结构化格式（如 SQL 表格）之前进行处理。Pig 非常适合用于 ETL 操作，如数据验证、加载、转换和将来自多个来源的多种格式的数据进行合并。除了 ETL，Pig 还支持关系型操作，如嵌套数据、联接和分组。Pig 脚本可以输入非结构化和半结构化数据（如 Web 服务器日志或点击流日志）。相比之下，Hive 始终对输入数据强制执行模式。Pig Latin 脚本包含过滤、分组和联接数据的指令，但 Pig 并不打算作为查询语言。Hive 更适合用于查询数据。Pig 脚本会根据 Pig Latin 脚本中的指令编译并运行，以转换数据。

• Hive 是一个开源的数据仓库和查询包，运行在 Hadoop 集群之上。能够使用 SQL 是一项有助于团队轻松过渡到大数据世界的技能。Hive 使用一种类似 SQL 的语言，称为 Hive 查询语言（HQL），使得在 Hadoop 系统中查询和处理数据变得容易。Hive 抽象了在像 Java 这样的编码语言中编写程序以执行分析任务的复杂性。

• Presto 是一个类似 Hive 的查询引擎，但它更快。它支持 美国国家标准协会（ANSI）SQL 标准，这是一种易于学习且最受欢迎的技能集。Presto 支持复杂查询、联接和聚合函数。与 Hive 或 MapReduce 不同，Presto 在内存中执行查询，这减少了延迟并提高了查询性能。选择 Presto 的服务器容量时需要小心，因为它需要较高的内存。在发生内存溢出时，Presto 作业会重新启动。

• HBase 是一个 NoSQL 数据库，作为开源 Hadoop 项目的一部分开发。HBase 运行在 HDFS 上，为 Hadoop 生态系统提供非关系型数据库功能。HBase 帮助以列式格式存储大量数据，并支持压缩。此外，它还提供了快速查找，因为大量数据缓存保存在内存中，同时集群实例存储仍然被使用。

• Apache Zeppelin 是一个基于 Web 的数据分析编辑器，建立在 Hadoop 系统之上，也被称为 Zeppelin 笔记本。它使用解释器的概念作为其后端语言，并允许任何语言插入到 Zeppelin 中。Apache Zeppelin 包含一些基本图表和数据透视图表。在任何语言后端的输出都可以被识别和可视化的情况下，它在灵活性方面非常强。

• Ganglia 是一个 Hadoop 集群监控工具。然而，你需要在集群启动时安装 Ganglia。Ganglia UI 运行在主节点上，可以通过 SSH 隧道进行访问。Ganglia 是一个开源项目，旨在无影响地监控集群性能。Ganglia 可以帮助检查集群中单个服务器的性能，以及整个集群的性能。

• JupyterHub 是一个多用户的 Jupyter Notebook 环境。Jupyter Notebook 是数据科学家在进行数据工程和机器学习时最常用的工具之一。JupyterHub 提供的笔记本服务器为每个用户提供一个基于 Web 的 Jupyter Notebook IDE。多个用户可以同时使用他们的 Jupyter Notebook 来编写和执行代码，进行探索性数据分析。

云端数据处理

云端数据处理是现代大数据和分析战略的基础。三大主要云服务提供商——AWS、GCP 和 Azure——提供了多种数据处理服务，每种服务都有独特的功能和能力。以下是它们各自的一些独特功能：

• AWS 数据处理服务：

  • Amazon EMR：提供云原生的 Hadoop 环境，支持多种大数据框架，如 Apache Spark、Hadoop、HBase 和 Presto。EMR 非常适合处理大规模数据集，并通过将计算与存储分离，提供灵活性，支持按需扩展，实现高效的成本控制。

  • AWS Glue：一项完全托管的 ETL 服务，简化了数据准备工作，以便进行分析。它自动化了繁琐的数据准备任务，生成 ETL 脚本，并促进在不同 AWS 服务之间的数据移动。Glue 在数据目录管理和作业调度方面尤其高效。

  • Amazon Athena：一项无服务器的交互式查询服务，允许直接在存储在 Amazon S3 中的数据上执行 SQL 查询。它非常适用于临时数据分析和商业智能查询，无需基础设施管理。

• GCP 数据处理服务：

  • Google BigQuery：这是一款完全托管的无服务器数据仓库解决方案，旨在对大规模数据集进行快速、成本高效的 SQL 查询。BigQuery 特别适用于实时分析，并且能够有效处理流式数据。

  • Cloud Dataflow：一项完全托管的服务，专门用于流式和批处理模式下的数据处理。基于 Apache Beam，Cloud Dataflow 提供统一的编程模型，简化了并行数据处理管道的开发。它擅长处理从复杂的 ETL 过程到批量和实时流处理工作负载等各种任务。

  • Cloud Dataprep：一项高级数据服务，允许用户直观地探索、清理并准备结构化和非结构化数据进行分析。与 BigQuery 和 Cloud Dataflow 无缝集成，Cloud Dataprep 增强了数据探索和转换的能力。

• Azure 数据处理服务：

  • Azure HDInsight：一个完全托管的云服务，使得使用流行的开源框架（如 Apache、Hadoop、Spark、Kafka 和 HBase）处理海量数据变得简单。它适用于各种场景，如 ETL、数据仓库、机器学习和物联网。

  • Azure Databricks：一个快速、简便且协作的基于 Apache Spark 的分析平台。它与其他 Azure 服务深度集成，为 ETL 过程、流式分析、机器学习和数据仓库提供统一平台。

  • Azure Synapse Analytics：这是一个全面的分析服务，融合了大数据和数据仓库的功能。它为数据的摄取、准备、管理和交付提供了一个统一的体验，便于即时的商业智能和机器学习应用。Azure Synapse Analytics 支持同时查询数据湖和数据库，简化了数据分析过程。

每个云服务提供商的数据处理服务都旨在满足数据生命周期中的特定需求，从处理和转换大数据集到交互查询和实时分析。这种多样性确保了企业可以根据其特定的数据处理需求和目标选择最合适的工具和平台。

数据分析和处理是一个庞大的主题，值得专门成书。本节提供了关于数据处理中常用和流行工具的高层次概述。还有许多其他专有和开源工具可供选择。作为解决方案架构师，你必须了解各种可用工具，以便为你的组织选择合适的工具。

商业分析师需要创建报告和仪表板，执行临时查询和分析，以识别数据洞察。我们将在下一部分学习数据可视化。

数据可视化

数据洞察用于回答重要的业务问题，例如按客户收入、按地区的利润或按网站的广告推荐等。在大数据管道中，来自不同来源的大量数据被收集。然而，企业很难找到关于各地区库存、盈利能力以及增加的欺诈账户支出等信息。你为合规目的持续收集的一些数据也可以被用于生成业务。

商业智能工具的两个重大挑战是实施成本和实现解决方案所需的时间。让我们来看一下数据可视化的技术选择。

数据可视化的技术选择

以下是一些最受欢迎的数据可视化平台，它们帮助你根据业务需求准备包含数据可视化的报告：

• Amazon QuickSight 是一个基于云的 BI 工具，适用于企业级数据可视化。它提供多种可视化图表预设，如折线图、饼图、树状图、热力图和直方图。Amazon QuickSight 拥有一个名为 超快并行内存计算引擎 (SPICE) 的数据缓存引擎，有助于快速渲染可视化图表。你还可以执行数据准备任务，例如重命名和删除字段、改变数据类型以及创建新的计算字段。QuickSight 还提供基于机器学习的可视化洞察以及其他机器学习功能，如自动预测功能。

• Kibana 是一个开源数据可视化工具，用于流数据可视化和日志探索。Kibana 与 Elasticsearch 紧密集成，并将其作为默认选项，用于在 Elasticsearch 服务上搜索数据。与其他 BI 工具类似，Kibana 也提供流行的可视化图表，如直方图、饼图和热力图，并且提供内建的地理空间支持。

• Tableau 是最受欢迎的数据可视化 BI 工具之一。它使用一个视觉查询引擎，这是一个专门构建的引擎，可以比传统查询更快速地分析大数据。Tableau 提供了一个拖放界面，并且能够将来自多个资源的数据进行混合。

• Spotfire 使用内存处理来加快响应时间，使得可以处理来自多个资源的大型数据集。它允许你在地理地图上绘制数据，并将其分享在 Twitter 上。借助 Spotfire 的推荐功能，它会自动检查你的数据，并建议最佳的可视化方式。

• Jaspersoft 使自助报告和分析成为可能。它还提供了拖放设计器功能。

• Power BI 是微软提供的一个流行的 BI 工具。它提供了自助式分析功能，并提供多种可视化选择。

数据可视化是解决方案架构师的一个重要且庞大的主题。作为一名解决方案架构师，你需要了解可用的工具，并根据你的业务需求为数据可视化做出正确的选择。

你已经学习了各种数据管道组件，从数据摄取、存储、处理到可视化。在接下来的章节中，让我们将这些组件结合起来，学习如何协调大数据架构。

设计大数据架构

大数据解决方案由数据摄取、存储转换、数据处理和可视化组成，并以循环的方式支持日常业务操作。你可以使用之前章节中学到的开源或云技术来构建这些工作流。

首先，你需要通过从业务用例倒推的方式，了解哪种架构风格适合你。你需要了解大数据架构的最终用户，并创建用户角色，以便更好地理解需求。为了识别你要针对的大数据架构的关键角色，你需要理解以下一些要点：

• 他们属于组织内的哪些团队、单位或部门？

• 他们的数据分析和数据工程能力如何？

• 他们通常使用哪些工具？

• 你是否需要满足组织中员工、客户或合作伙伴的需求？

作为参考，以零售店连锁分析为例，你可以识别出以下角色：

• 产品经理角色，负责某一产品线/代码，但只能看到该产品的营业额。

• 店长角色，想要了解单个门店的销售营业额和产品组合（只能查看自己门店的数据）。

• 管理员角色，要求能够访问所有数据。

• 数据分析师，希望访问所有数据，同时对包含个人身份信息（PII）的数据进行去标识化处理。

• 客户保持经理，希望了解重复购买的客户流量。

• 数据科学家需要访问原始数据和处理过的数据，以建立推荐和预测模型。

一旦你清楚地理解了用户角色，下一步就是识别这些角色所要解决的业务用例。以下是一些例子：

• 客户消费趋势：分析有多少客户的消费在一段时间内呈上升或下降趋势。根据这些客户的消费模式进行分类。

• 高消费群体中的增长类别：识别出哪些产品或服务类别在支出逐渐增加的客户中呈现更快的增长。

• 低消费群体中的下降类别：确定在支出逐渐减少的客户中，哪些类别的参与度明显下降。

• 人口统计学对消费的影响：调查哪些人口统计学因素，如家庭规模、是否有孩子或收入水平，影响客户的消费习惯。同时，评估哪些人口统计因素对特定产品或服务类别的参与度产生影响。

• 直接营销的有效性：探索是否有证据表明直接营销活动能够提升整体客户参与度。

• 直接营销跨类别的影响：评估一个类别中的直接营销活动是否对其他类别的客户参与度产生积极影响。

在你获取使用案例的详细信息时，构建数据架构的关键方面是理解访问模式和数据保留策略，这些可以通过使用以下查询进行分析：

• 关键用户和角色多久运行一次报告、查询或模型？

• 他们对数据的新鲜度有何期望？

• 他们对数据粒度有什么期望？

• 哪部分数据最常用于分析？

• 你打算保存数据进行分析的时间是多久？

• 数据在数据湖环境中什么时候会过时？

处理数据时总是会涉及一些敏感性问题。每个国家和地区都有其本地的合规要求，解决方案架构师需要了解这些要求，例如：

• 你的业务有哪些合规要求？

• 你是否受到数据本地化、隐私或删除要求的限制？

• 谁有权查看数据集中的哪些记录和哪些属性？

• 如何强制执行在请求时删除记录？

• 你打算将数据存储在哪里，例如，是否按地理位置、本地县域或全球存储？

作为数据架构师，你还必须考虑投资回报以及它如何帮助整体的业务决策。为了理解这一点，你可能需要考虑以下几点：

• 你的数据湖支持哪些主要的业务流程和决策？

• 这些决策需要什么级别的粒度？

• 数据延迟对业务决策的影响是什么？

• 你打算如何衡量成功？

• 投入的时间和资源预期能带来什么样的回报？

最终，你希望构建一个能够提供灵活性的架构，以便做出技术选择。例如，通过使用基于云的托管服务和开源技术的最佳组合，利用现有的技能和投资。你希望构建大数据解决方案，利用并行性实现高性能和可扩展性。最好确保大数据管道的任何组件都能独立地进行水平或垂直扩展，以便根据不同的业务工作负载进行调整。

为了充分利用解决方案的潜力，你希望提供与现有应用程序的互操作性，以便大数据架构的组件也能用于机器学习处理和企业 BI 解决方案。这将使你能够在数据工作负载之间创建集成解决方案。让我们了解一些大数据架构模式。

数据湖架构

数据湖作为一个集中式存储库，能够容纳结构化和非结构化数据，涵盖了公司中存在的各种数据类型。它已经成为将所有企业数据转移到一个成本效益高的存储系统（如 Amazon S3）的解决方案。在数据湖中，数据可以通过通用的 API 和开放文件格式进行访问，包括 Apache Parquet 和 优化行列式存储格式 (ORC)。这种存储方式以数据的原始形式保存数据，利用开源文件格式，从而便于直接进行分析和机器学习应用。

数据湖正成为在一个集中式存储库中存储和分析大量数据的流行方式。数据可以以当前的格式直接存储，无需将数据转换为预定义的模式，这提高了数据摄取速度。正如下面的示意图所示，数据湖是你组织中所有数据的单一真实来源：

图 12.6：数据湖的对象存储

以下是数据湖的好处：

• 来自各种来源的数据摄取：数据湖让你能够在一个集中位置存储和分析来自多个来源的数据，如关系型数据库、非关系型数据库和数据流，作为单一的真实数据来源。这解决了诸如：为什么数据分布在多个地方？ 和 单一真实数据来源在哪里？ 这样的问题。

• 高效收集和存储数据：数据湖可以摄取任何数据结构，包括半结构化和非结构化数据，无需模式。这解决了诸如：如何从多个来源快速摄取不同格式的数据并高效地进行大规模存储？ 这样的问题。

• 随着生成数据量的增加进行扩展：数据湖允许你将存储和计算层分开，单独扩展每个组件。这解决了诸如：如何随着生成的数据量进行扩展？ 这样的问题。

• 对来自不同来源的数据应用分析：借助数据湖，你可以在读取时确定模式，并创建一个关于从各种资源收集的数据的集中式数据目录。这使你能够进行快速的临时分析。解决了诸如：我能否对相同的数据应用多个分析和处理框架？ 这样的问题。

你需要一个无限可扩展的数据存储解决方案来支持数据湖。解耦处理和存储带来了许多好处，包括能够使用各种工具处理和分析相同的数据。虽然这可能需要额外的步骤将数据加载到正确的工具中，但作为中央数据存储的 Amazon S3 提供的好处超过了传统存储选项。以下示意图展示了使用 AWS 服务的数据湖视图：

图 12.7：AWS 平台中的数据湖架构

上面的图示描述了一个使用 Amazon S3 存储的数据湖。数据从各种资源（如关系数据库和主数据文件）摄取到集中存储中。在数据湖的原始层中，所有数据都保持其原始格式。随后，这些数据通过 AWS Glue 服务进行目录管理和转换。AWS Glue 是一个无服务器的数据目录管理和 ETL 过程解决方案，基于 AWS 云平台中的 Spark 框架构建。在这里，AWS Glue 爬虫帮助进行数据存储的目录管理。它会自动扫描你的数据源，识别数据格式，并推断模式，创建并填充包含元数据的信息的数据目录。爬虫对数据进行分类，以了解其格式和结构，并在数据目录中创建表定义，从而简化了数据分析查询的构建。一旦数据被转换，它会存储在数据湖的处理层中，供各种用途消费。

数据工程师可以使用 Amazon Athena 运行临时查询，这是一种基于托管 Presto 实例构建的无服务器查询服务，并使用 SQL 直接从 Amazon S3 查询数据。业务分析师可以使用 Amazon QuickSight、Tableau 或 Power BI 为业务用户构建可视化，或将部分数据加载到 Amazon Redshift 中以创建数据仓库模型。最后，数据科学家可以使用 Amazon SageMaker 消耗这些数据，进行机器学习（ML）。

没有一个工具能做到所有事情。你需要为正确的工作使用合适的工具，而数据湖使你能够构建一个高度可配置的大数据架构，以满足你的特定需求。业务问题必须更加具体、深入且复杂，才能由一个工具来解决，尤其是在大数据和分析的领域。

然而，随着时间的推移，组织意识到数据湖有其局限性。由于数据湖使用廉价存储，组织将尽可能多的数据存储在数据湖中，从而提供了开放、直接访问文件的灵活性。很快，数据湖因数据质量问题和细粒度的数据安全性而开始变成数据沼泽。然而，为了解决数据湖的性能和质量问题，组织将数据湖中的一小部分数据处理到下游数据仓库中，以便在 BI 应用程序中用于重要决策。

数据湖和数据仓库之间的双重系统架构需要持续的数据工程来维护和处理这两个系统之间的数据。数据处理的每一步都存在故障的风险，这可能会影响数据质量。此外，保持数据湖和数据仓库之间的一致性既具挑战性，又成本高昂。用户面临支付双重存储费用的负担——一次是数据存储在数据湖中的费用，另一次是数据在数据仓库中的复制费用。这还不包括与持续数据处理相关的持续费用。

为了解决双系统问题，一种新的架构类型——数据湖仓架构被提出。让我们深入了解湖仓架构。

湖仓架构

湖仓架构作为一种解决方案应运而生，旨在弥合传统数据湖和数据仓库之间的差距，集成了两者的优势。该架构旨在利用数据湖的广泛存储容量，用于摄取和存储大量数据，并采用开放格式，这对分析至关重要。同时，它也旨在提供基于 SQL 的查询便利性和与数据仓库相关的可靠性。湖仓架构的关键特性包括：

• 开放数据格式的存储：湖仓架构采用开放格式存储数据，促进数据处理和分析中的互操作性和灵活性。

• 解耦存储和计算：它将存储和计算资源分离，允许各自独立扩展和优化，从而提高成本效率和性能。

• 事务性保障：为了确保数据完整性，湖仓架构提供了事务性保障，类似于传统数据库系统中的保障，支持可靠的并发访问和修改。

• 支持多样化的消费需求：湖仓架构旨在满足各种数据消费需求，支持从批处理到实时流处理的不同数据分析和处理方式。

• 安全与治理：该架构强调安全性和治理，确保数据访问受到控制，并保持符合数据隐私法规的合规性。

• 统一平台：湖仓架构提供一个统一的平台，涵盖从 ETL 过程、机器学习到商业智能和报告的各类数据操作，消除了对多个系统的需求。

• 增强查询性能：通过利用索引、缓存和数据聚类等技术，湖仓架构提升了查询性能，使其适用于复杂的分析工作负载。

• 成本效益的可扩展性：该架构提供成本效益的可扩展性选项，在性能需求和预算限制之间实现平衡，尤其对日益增长的数据量非常有益。

• 灵活的数据管理：湖仓架构支持灵活的数据管理实践，能够适应不断变化的数据模式和结构，非常适合敏捷和动态变化的业务环境。

湖仓架构代表了数据管理的一次重要进化，提供了一种全面、可扩展且高效的方法来处理庞大且多样化的数据集，同时确保数据的完整性、安全性和易访问性。

下图展示了一个使用 Redshift Spectrum 进行数据共享的样本湖屋架构。Amazon Redshift Spectrum 提供了从数据湖查询数据的能力，而无需将数据存储在数据仓库中。假设你已经在使用 Amazon Redshift 进行数据仓储，在这种情况下，你无需将所有数据加载到 Amazon Redshift 集群中，仍然可以使用 Spectrum 直接从 Amazon S3 数据湖查询数据，并将其与数据仓库中的数据结合使用。

图 12.8：使用 Redshift Spectrum 在 AWS 云平台上的湖屋架构

数据通过 S3 API 从本地 企业数据仓库 (EDW) 导入到 S3，如上图所示。AWS Glue 存储了元数据以及信用和贷款数据。贷款部门的数据分析师将被授予只读权限，以访问贷款数据。同样，信用分析师将被授予只读权限，以访问信用数据。在数据共享方面，如果信用分析师需要访问贷款数据，信用分析师可以获得贷款数据的只读模式。

Lakehouse 架构有其优势；然而，对于那些由地理位置分散的业务单元驱动的复杂应用程序环境的大型组织来说，还需要更多的支持。这些业务单元已经构建了数据湖和数据仓库作为其分析来源。每个业务单元可能会合并多个内部应用程序数据湖，以支持其业务。由于变更速度通常较慢，且难以满足不同业务单元的所有需求，中央化的企业数据湖或数据湖屋难以实现。为了解决这个问题，你需要基于领域的去中心化数据所有权和架构。这就是数据网格的作用所在。让我们深入了解数据网格架构。

数据网格架构

数据网格与数据湖架构之间的主要区别在于，数据故意保持分布式，而不是试图将多个领域合并到一个集中管理的数据湖中。数据网格提供了一种模式，使大型组织能够连接多个数据湖/湖屋，并促进与合作伙伴、学术界甚至竞争对手的共享。

数据网格代表了在架构和组织管理广泛分析数据集方面的重大转变。它建立在四个基本原则之上：

• 基于领域的去中心化所有权和架构：这一原则强调将数据所有权和架构决策去中心化到特定的业务领域。它鼓励各个领域对其数据负责，从而产生更具针对性和有效的数据解决方案。

• 数据作为产品提供：将数据视为产品意味着它会被维护、改进，并以最终用户为中心展示。它将焦点从数据作为单纯的资源转变为作为有价值的资产，能够提供实用性并解决用户问题。

• 联邦数据治理与集中审计控制：这一原则在去中心化的数据管理和对全面治理需求之间找到平衡。它允许进行特定领域的数据治理，同时保持集中控制以便审计和合规性。

• 数据可消费的公共访问：确保数据在整个组织中可访问且可用，这一原则专注于创建一个通用框架，以便轻松高效地消费数据。

它鼓励数据驱动的敏捷性，并通过轻量级的集中政策支持领域本地治理。数据网格通过明确的责任界定隔离数据资源，从而提供更好的所有权。数据网格的核心概念是将数据领域作为数据湖账户中的节点。

数据生产者将一个或多个数据产品贡献到数据网格账户中的中央目录，并在此应用联邦数据治理，以便共享数据产品，提供可发现的元数据和可审计性。数据消费者通过接受资源共享来搜索目录并访问数据产品，这遵循数据网格模式。以下是 AWS 云中的数据网格架构：

图 12.9：AWS 云平台上的数据网格架构

以下是为构建数据网格而实施的组件，如前面的图示所示：

• 中央 AWS 账户是注册数据产品的地方，包括数据库、表、列和行。

• 访问控制标签和标签访问策略由中央管理。

• 它存储执行与消费者共享的数据权限。权限可以是直接的或基于标签的。

• 将安全性和治理政策应用于生产者和消费者账户及其发布的数据产品。

通过数据网格架构，您可以加速业务领域湖仓的独立交付。数据网格增强了领域内的数据安全性和合规性，并允许自助服务的数据产品创建、发现和订阅，消费者可以透明地访问数据产品。随着基于客户需求提供快速洞察和迅速行动的需求不断增加，流数据分析已成为任何业务的关键组成部分。让我们深入了解流数据分析架构的更多细节。

流数据架构

流数据是数据中快速扩展的一个部分，它需要具备从各种来源快速接收和处理实时数据的能力。这些来源包括视频、音频、应用日志、网站点击流和物联网遥测数据，所有这些数据旨在提供及时的商业洞察。流数据的典型应用场景遵循一致的模式：

1. 数据生成：数据源持续不断地生成数据。

2. 数据摄取：这些数据随后通过摄取阶段传送到流式存储层。

3. 流存储：在这一层，进入的数据被持久化捕获，并为实时处理提供访问。

4. 流处理：在这一层，存储层中的数据被处理。这个处理可能涉及到数据的过滤、聚合或分析，随着数据的流动而进行。

5. 数据输出：处理后的数据随后被发送到指定的目的地，可能是数据库、数据湖或其他存储解决方案，用于进一步使用或长期存储。

这个流程确保数据不仅在生成时被捕获，而且在及时的过程中被处理，从而实现更快速的决策制定和更即时的业务洞察。

流数据架构与传统架构不同，因为它需要处理连续的大量数据流，并且数据流速非常高。通常，这些数据是半结构化的，需要大量处理才能得出可操作的见解。在设计流数据架构时，你需要快速扩展数据存储，同时从时间序列数据中获得实时模式识别。

最好从产生数据流的生产者角度考虑问题，比如物联网传感器，如何使用实时数据处理工具存储和处理数据，最后如何进行实时数据查询。以下图示展示了在 AWS 平台上使用托管服务的流数据分析管道：

图 12.10：物联网数据的流数据分析

在前面的图示中，数据从风电场采集，以了解风力涡轮机的健康状况和转速。实时控制风力涡轮机非常重要，以避免在风速超过涡轮机的限制时发生高昂的维修费用。

风力涡轮机的数据通过 AWS IoT Greengrass 输入到 Kinesis 数据流。Kinesis 数据流可以保留流数据长达一年，并提供回放功能。采用分发技术将数据发送到多个资源，在那里你可以使用 Lambda 发送数据消息，并将数据存储到 Amazon S3 中，进一步使用 Amazon Kinesis Firehose 进行分析。

你可以使用 Kinesis 数据分析 SQL 对流数据进行实时查询，并且可以通过 Kinesis 数据分析 Java Flink 来自动化数据管道，实时转换流数据，并将处理后的数据存储到 Amazon OpenSearch 中，以获取数据洞察。你还可以将 Kibana 添加到 OpenSearch 中，实时可视化风力涡轮机数据。

前述的解决方案是数据无关的，并且易于定制，客户可以快速修改预配置的默认设置，并开始编写代码来包含特定的业务逻辑。

选择合适的大数据架构

在选择数据湖、湖仓和数据网格架构时，需要根据具体的业务需求、数据战略和技术能力来决定。每种架构都有其独特的优势，适用于不同的数据管理和分析场景。为了帮助做出正确的选择，以下列表列出了每种架构的优势、重要考虑事项和理想使用案例：

• 数据湖架构：数据湖主要用于以原始格式存储大量数据。

  • 优势：它提供了高可扩展性和灵活性，能够处理各种数据类型。它在存储大量数据方面具有成本效益，并且可以作为所有组织数据的中央存储库。

  • 考虑事项：如果没有适当的治理，数据湖可能会变得难以管理（“数据沼泽”）。它们需要谨慎管理，以确保数据质量和可访问性。

  • 使用案例：它适用于大数据分析、机器学习以及需要存储和分析大量多样化数据的场景，且成本低廉。特别适合需要存储多种类型数据——包括结构化、半结构化和非结构化数据——且在数据输入时没有预定架构要求的情况。

• 湖仓架构：该架构结合了数据湖和数据仓库的元素。

  • 优势：它旨在提供数据湖的低成本可扩展性，并结合数据仓库的强大架构和性能优化。它提供了一个统一的平台，支持各种类型的数据处理和分析，减少了数据孤岛现象。它还支持 ACID 事务和架构强制执行，提升了数据的可靠性和质量。

  • 考虑事项：实施湖仓架构可能较为复杂，需要集成各个组件并确保不同工作负载之间的一致性和可靠性。

  • 使用案例：它最适合需要大数据处理和传统 BI 分析的组织，并且能够从单一平台进行操作。它特别适合需要实时分析和报告大规模多样化数据集的使用场景。

• 数据网格架构：它侧重于去中心化的数据架构和所有权。它将数据视为产品，由面向领域的团队拥有并向整个组织提供他们的数据产品。

  • 优势：它鼓励更敏捷和灵活的数据管理与分析方法。它还促进了数据民主化，使得各领域内的决策更加快速，创新得以推进。

  • 考虑事项：它需要在数据管理和共享的文化上发生转变。它要求在各个领域间进行强有力的治理和标准化，以确保数据的互操作性和质量。

  • 使用案例：它适用于拥有多个独立团队或部门的大型组织，在这些组织中，不同领域生成并消费数据。

以下是一些关键的决策因素：

• 组织结构：考虑你的组织是集中化还是去中心化的。数据网格更适合后者。

• 数据量与多样性：数据湖适用于大规模、多样化的数据集，而湖仓则为此类数据提供更结构化的环境。

• 分析需求：如果你需要将实时分析与大数据处理相结合，湖仓可能是最合适的选择。

• 治理与合规性：评估你的数据治理、质量和合规需求。湖仓架构通常提供更强大的治理机制。

• 技术专长：实施和管理数据网格或湖仓架构需要特定的技术专长和资源。

最终，选择取决于将架构与业务目标、技术能力和数据战略对齐。每种架构都有其优势，最好的选择可能是混合方法，具体取决于你的特定需求。

大数据架构最佳实践

你在前面的章节中学习了各种大数据技术和架构模式。让我们看一下下面的参考架构图，了解数据湖架构不同层次的最佳实践。

图 12.11：数据湖参考架构

上图展示了使用 AWS 云平台的端到端数据管道架构，包含以下组件：

• AWS Direct Connect 将在本地数据中心与 AWS 之间建立高速网络连接以迁移数据。如果你有大量归档数据，使用 AWS Snow 系列产品将其迁移到离线环境更为合适。

• 一个数据摄取层，包含多个组件，用于使用 Amazon Kinesis 摄取流数据，使用 AWS 数据迁移服务（DMS）摄取关系数据，使用 AWS Transfer for 安全外壳文件传输协议（SFTP）进行安全文件传输，以及使用 AWS DataSync 在云端与本地系统之间更新数据文件。

• 使用 Amazon S3 存储所有数据的集中化数据存储，其中数据存储分为多个层次，存储原始数据、处理后的数据和归档数据。

• Amazon Redshift 是一种云原生的数据仓库解决方案，配合 Redshift Spectrum 支持湖仓架构。

• 使用 Amazon Athena 进行临时查询功能。

• 基于 Spark 使用 AWS Glue 实现快速 ETL 流水线。

• Amazon EMR 将重新利用现有的 Hadoop 脚本和其他 Apache Hadoop 框架。

• 使用 Amazon Lake Formation 在数据湖级别构建全面的数据目录和细粒度的访问控制。

• 使用 Amazon SageMaker 的 AI/ML 扩展。

其他组件包括用于数据加密的 Amazon 密钥管理服务（KMS），用于访问控制的 Amazon 身份与访问管理（IAM），用于 PII 数据检测的 Amazon Macie，以遵守支付卡行业数据安全标准（PCI DSS）等数据合规要求，CloudWatch 用于监控操作，CloudTrail 用于审计数据湖活动。

您需要使用以下标准验证您的大数据架构：

• 安全性：

  • 对数据进行分类，并使用基于资源的访问控制定义相应的数据保护策略。

  • 使用用户权限和单点登录（SSO）实施强大的身份基础。

  • 为审计目的启用环境和数据可追溯性。

  • 在所有层次实施安全性，并使用 SSL 和加密保护数据在传输和静态状态下的安全。

  • 将人员与数据隔离，例如锁定生产数据集的写访问权限。

• 可靠性：

  • 通过自动化数据剖析和数据目录化，强制执行数据卫生。

  • 管理数据资产的生命周期，使用数据仓库和数据湖之间的数据分层来进行过渡和过期管理。

  • 通过维护数据目录中数据流动的历史记录来保留数据血缘。

  • 为分析管道设计弹性，并通过自动恢复 ETL 作业失败来监控系统 SLA。

• 性能效率：

  • 使用数据剖析提高性能，进行数据验证，并构建一个数据清理层。

  • 持续优化数据存储，例如使用 Parquet 格式的数据压缩、数据分区、文件大小优化等。

• 成本优化：

  • 采用消费模型并确定是否需要特定的或快速查询模式。

  • 删除不再使用的数据；定义数据保留规则，并删除或归档超过保留期的数据。

  • 使用基于数据湖的解决方案解耦计算和存储。

  • 通过针对不同数据源和数据量采用不同的迁移策略，实施迁移效率。

  • 使用托管和应用级服务降低拥有成本。

• 操作卓越：

  • 使用 CloudFormation、Terraform 和 Ansible 等工具以代码方式执行操作。

  • 自动化操作，例如通过 Step Functions 或 Apache Airflow 构建编排层。

  • 通过持续监控并自动恢复 ETL 作业失败，预见故障并提前做好准备。

  • 衡量工作负载的健康状况。

您可以使用前面的检查清单作为验证大数据架构的指南。数据工程是一个广泛的主题，值得编写多本书来深入探讨每个话题。

在本章中，您了解了数据工程的各种组件及其流行架构模式，这将帮助您入门并深入探讨该主题。

总结

在本章中，你学习了大数据架构以及大数据管道设计的组件。你了解了数据摄取和用于收集批量数据与流式数据进行处理的各种技术选择。由于云存储在今天处理海量数据中至关重要，你了解了 AWS 云生态系统中可用的各种数据摄取服务。

数据存储是处理大数据的核心之一。你学习了各种数据存储类型，包括结构化数据和非结构化数据、NoSQL、以及数据仓库，并了解了每种存储方式所需的技术选择。你还了解了来自主流公有云提供商的云数据存储。

一旦你收集并存储了数据，就需要对其进行转化，以获得对数据的洞察并可视化业务需求。你学习了数据处理架构和技术选择，以便根据数据需求选择开源和基于云的数据处理工具。这些工具帮助你根据数据的性质和组织需求，获得数据洞察和可视化。

你学习了各种大数据架构模式，包括数据湖、湖仓、数据网格、流式数据架构、参考架构，并了解如何根据数据需求选择合适的架构。最后，你通过结合所有学习的知识，了解了大数据架构的最佳实践，并在参考架构中进行了应用。

随着数据的收集，获取未来的洞察总是非常有益的，这对于业务发展尤其重要。你通常需要机器学习来基于历史数据预测未来的结果。在下一章中，让我们深入了解机器学习以及如何让你的数据架构具有未来保障。

加入我们的书籍 Discord 空间

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

第十三章：机器学习架构

在上一章中，你了解了如何摄取和处理大数据，并通过洞察数据来理解你的业务。在传统的商业运营方式中，组织的决策者会查看过去的数据，并通过他们的经验来规划公司未来的发展方向。这不仅仅是设定商业愿景的问题，还包括通过预测和满足最终用户的需求或自动化日常决策活动（例如贷款审批）来改善用户体验。

然而，随着如今可用数据量的庞大，人类大脑已经很难处理所有数据并预测未来。正是因为这样，人工智能（AI）和机器学习（ML）才应运而生。人工智能是机器以智能方式执行任务的更广泛概念，比如 Siri 和 Alexa 能够理解你的问题并给出答案；而机器学习是人工智能的一个特定子集，涉及让计算机通过数据学习并做出决策。它们帮助我们通过查看大量的历史数据来预测未来的行动方向。如今，大多数企业正在投资机器学习，主要是因为生成式人工智能（GenAI）带来的加速发展。机器学习正迅速成为帮助企业脱颖而出的技术——通过创造新产品、服务和商业模式，使企业能够创新并获得竞争优势。

人工智能（AI）和机器学习（ML）非常适合解决商业问题，因为它们在公司不同业务领域中提供了无数的应用场景，并且这些应用场景所带来的影响程度也很高。例如，通过机器学习，你可以通过呼叫中心智能化提升客户服务水平，或者帮助市场营销团队通过使用基于机器学习的个性化营销活动实现个性化目标。

在本章的范围内，我们将涵盖以下主题来处理和管理你的机器学习需求：

• 什么是机器学习？

• 与数据科学和机器学习的合作

• 云中的机器学习

• 构建机器学习架构

• 机器学习架构的设计原则

• MLOps

• 深度学习

• 自然语言处理（NLP）

到本章结束时，你将对机器学习架构有一定的了解。你将学习各种机器学习模型以及机器学习工作流。你将理解通过特征工程、模型训练、推断和模型评估等过程创建机器学习模型管道的过程。

什么是机器学习？

机器学习推动了更好的客户体验、更高效的业务运作以及更快速、更准确的决策制定。随着计算能力的提升和数据的泛滥，机器学习已从外围技术发展为各行业企业和组织的核心竞争力。机器学习的应用场景可以涵盖大多数企业，例如个性化产品和内容推荐、呼叫中心智能化、虚拟身份验证和智能文档处理等。也有为特定行业量身定制的应用场景，如制药行业的临床试验或制造业的生产线质量控制。

机器学习通过技术来发现新趋势，并基于过去的事实数据建立数学预测模型。机器学习能够帮助解决一些复杂问题，诸如以下问题：

• 您可能需要学习如何创建复杂的代码规则来做出决策；例如，如果您想识别图像和语音中的人类情感，目前没有简单的方式编写逻辑来实现这一目标。

• 当需要分析大量数据以做出决策，而数据量过大，人类无法高效处理时。例如，虽然人类可以进行垃圾邮件检测，但数据量大到使得快速完成这一任务变得不切实际。

• 相关信息可能仅在您需要时动态生成，此时需要根据个人数据调整和个性化用户行为；例如，个性化的产品推荐或网站个性化。

• 当有大量数据任务需要处理时，无法足够迅速地跟踪信息以做出基于规则的决策——例如，欺诈检测和自然语言处理（NLP）。

人类基于分析结果和经验进行数据预测。通过机器学习，可以训练计算机根据可用数据提供专业知识，并基于新数据进行预测。以下是机器学习在各行各业的几种普遍应用场景：

• 预测性维护：根据传感器数据预测组件是否会提前发生故障。常用于估算剩余使用寿命（RUL）的预测，适用于汽车车队、制造设备和物联网传感器。其主要好处是提高车辆和设备的正常运行时间，显著节省成本。这一应用广泛存在于汽车和制造行业。

• 需求预测：利用历史数据更快速、准确地预测关键需求指标，从而帮助做出关于生产、定价、库存管理以及采购/补货的更准确商业决策。其主要优势包括满足客户需求、通过减少多余库存来最小化库存持有成本，以及减少浪费。金融服务、制造业、零售业以及消费品包装商品（CPG）等行业经常使用这一应用场景。

• 欺诈检测：自动识别潜在的欺诈活动并标记以供进一步审查。其主要好处是减少与欺诈相关的成本，并保持客户信任。这个用例在金融服务和在线零售行业得到了应用。

• 信用风险预测：解释信用申请中的个体预测，以预测是否会按时还款的可能性（通常称为信用违约）。其好处在于识别偏见并遵守监管要求。这个用例主要用于金融服务和在线零售行业。

• 从文档中提取和分析数据：理解手写和数字文档中的文本，提取信息用于分类和决策。这种用例在医疗、金融服务、法律、机械、电气和教育等行业中广泛应用。

• 个性化推荐：基于历史数据做出定制化推荐。这种方法在零售和教育行业中很常见。

• 流失预测：估算客户停止使用服务的概率。这通常应用于零售、教育和软件即服务（SaaS）提供商等行业。

机器学习的主要思想是为机器学习算法提供一个训练数据集，让其从新的数据集中进行预测，例如，将一些历史股市趋势数据提供给机器学习模型，并让其预测市场在未来六个月到一年的波动情况。

在开发机器学习系统时，重要的是要谨慎地结合数据和代码。两者必须有组织地结合在一起，并且应该以受控的方式发展，以朝着构建一个强大且可扩展的机器学习系统的共同目标迈进。

你用来训练、测试和进行机器学习系统推断决策的数据会随着时间的推移发生变化，因为数据来自不同的地方。你的代码也需要随着数据的变化而改变，以适应来自不同来源的数据。如果没有系统的方法，代码和数据的变化可能会发生偏离。这种不匹配可能会在你尝试将机器学习系统应用于实际任务时引发问题。它还可能妨碍平稳部署，并导致难以理解、追溯或后续重现的结果。机器学习有多种类型，让我们来探索一下。

机器学习的类型

机器学习帮助计算机无需我们编写每个细节就能学会某些东西。就像教狗狗一个新动作：你展示给它看，之后它学会了并且做出来！通过机器学习，计算机可以从数据中学习，然后利用这些学习做出决策。让我们来看看计算机学习的不同方式。

监督学习

在监督学习中，算法被提供一组训练示例，其中数据和目标决策是已知的。然后，它可以预测包含相同属性的新数据集的目标值。在这种学习类型中，算法通过一个输入数据附带正确答案或目标的数据集进行学习。算法通过这些示例学习将输入与其正确输出关联起来。

这种学习类型通常用于需要将事物分类到不同类别或预测数字的任务，例如分类和回归任务。例如，它可以用来将电子邮件分类为垃圾邮件或非垃圾邮件，或根据房屋的特征预测房价。

无监督学习

在无监督学习中，算法会提供大量数据，并应在数据中发现模式和关系。然后，它可以从数据集中推断出结论。

在无监督学习中，不需要人工干预，例如根据上下文进行文档的自动分类。它解决了正确输出无法用于训练示例的问题，算法必须通过聚类在数据中发现模式。

在无监督学习中，模型使用未标记的数据集进行训练。算法自主工作，发现数据中的模式、结构或关系，而无需任何特定的指导或标记示例。此类学习常应用于聚类、降维和密度估计任务。新闻机构或法律事务所通常处理大量数据。通过无监督学习，它们可以实现文档自动分类，高效管理数字存储库，并改进信息检索过程，例如向读者或研究人员推荐相似的文章或案例。

半监督学习

这种方法结合了监督学习和无监督学习的元素。它涉及使用少量标记数据与大量未标记数据一起使用，以提高模型性能。半监督学习特别有用，尤其是在获取标记数据既昂贵又耗时的情况下。通常应用于标记数据有限但未标记数据充足的场景。例如，在生物医学领域，半监督学习可以非常有利。例如，标注医学图像需要大量时间和资源，这使得半监督学习成为一种实用的解决方案。模型可以先在一小部分标记图像上进行训练，然后使用更多未标记的图像进行微调，从而最大化效用并最小化成本和资源消耗。

强化学习

这种学习类型涉及训练代理（或计算机程序）在特定环境中做出一系列顺序决策。目标是让代理学会采取最佳行动，以便在时间推移中最大化累积奖励。代理通过采取行动、接收反馈（奖励或惩罚）并调整策略来学习。强化学习广泛应用于自主机器人、游戏对抗（例如 AlphaGo）和推荐系统。自动驾驶车辆通过在交通中导航，并根据环境调整行动，来应用强化学习，从而确保在各种情境下做出最优决策。车辆会做出一系列决策（如变换车道、调整车速等），对于安全高效的行动给予正向强化，而对于不良行为给予负向强化。

自监督学习

这是一种无监督学习类型，其中算法从数据中生成标签或目标。它通常涉及预测数据中的缺失部分等任务。自监督学习在自然语言处理（NLP）和计算机视觉中广受欢迎，常用于在大规模数据集上预训练模型，然后对特定任务进行微调。在图像处理或计算机视觉中，自监督学习可以用于预测视频序列中的下一个帧，从而帮助模型理解视觉数据中的运动和发展。通过这种方式对模型进行预训练，再针对具体任务（如物体检测）进行微调，能够获得令人印象深刻的结果。

多实例学习

在多实例学习中，每个数据点是一个包含多个实例（子数据点）的袋。目标是从数据袋中学习，同时仅能访问袋级别的标签。多实例学习在药物发现、图像分类和基于内容的图像检索中有应用。在电子商务平台中，多实例学习可以用于预测用户在一次会话（一个数据袋）中是否会购买产品，使用的不同实例如页面浏览量、点击的产品以及在页面上的停留时间。袋级标签可能会指示该会话期间是否发生了购买，从而为预测和个性化内容推荐提供了坚实的基础。

这些多样的学习范式，每种都有其专长和应用领域，使得机器学习成为一个多才多艺的领域，能够适应各个行业和领域中的不同场景与挑战。通过选择一个与特定问题的特点和可用数据相匹配的范式，机器学习从业者能够推导出有洞察力的模型，并推动智能化、自动化决策的应用。关键在于选择最适合现有数据和问题的学习类型，确保模型既强健又具有可应用性。

在接下来的部分，我们将学习数据科学是如何与机器学习（ML）紧密结合的。

与数据科学和机器学习合作

机器学习（ML）完全是关于数据的工作。训练数据的质量对 ML 模型的成功至关重要。高质量的数据可以带来更准确的 ML 模型和正确的预测。

数据常常存在多个问题，如缺失值、噪声、偏差、离群值等。探索数据使我们意识到这些问题，为我们提供有关数据质量和清洁度的信息，揭示数据中的有趣模式，并在开始建模后指引可能的前进路径。数据科学包括数据收集、数据准备、分析、预处理和特征工程。

数据准备是构建 ML 模型的第一步。它耗时且占据了 ML 开发中高达 80% 的时间。由于数据本身“脏”且未经处理，数据准备一直被认为是繁琐且资源密集型的。“脏”数据可能包括缺失值、错误值和离群值。通常需要进行特征工程来转换输入数据，从而提供更准确和高效的 ML 模型。

数据准备的第一步是理解业务问题。数据科学家通常急于直接跳入数据中，开始编写代码并产生洞见。然而，如果没有清楚地理解业务问题，任何产生的洞见都有很大的可能变成无法解决实际问题的方案。比起陷入数据的细节，先从简单的用户故事和业务目标出发显得更有意义。

在深入理解业务问题之后，你可以缩小 ML 问题的类别，并确定 ML 是否适合用来解决你的业务问题。

数据准备通常包括多个步骤，如数据清理、处理缺失值、数据规范化/标准化和数据标注。在本章后续的构建机器学习架构部分，你将详细学习这些步骤。大多数独立的数据准备工具都配备了数据转换、特征工程和可视化功能。数据转换可能包括诸如货币转换（例如，从美元转换为欧元）或单位转换（例如，从千克转换为磅）等任务。特征工程则涉及从现有数据中创建新的数据列（特征），以增强数据集在 ML 模型中的有效性；例如，从日期列中提取星期几或月份信息可以帮助模型识别与时间相关的模式。尽管这些工具在数据准备上表现出色，但它们通常缺乏内置的模型验证功能，而模型验证是评估 ML 模型性能的关键步骤。所需的是一个能够提供所有这些功能，并且与 ML 流水线其他部分紧密集成的框架。因此，数据准备模块在部署到生产环境之前需要经过整理和整合。

如下图所示，数据预处理和学习以创建机器学习模型是相互关联的——数据准备将深刻影响你的模型，而你选择的模型也将深刻影响你将进行的类型的数据准备。找到正确的平衡是一个高度迭代的过程，实际上非常像一门艺术（或试错法）：

图 13.1：机器学习工作流

如前图所示，机器学习工作流包括以下几个阶段：

• 预处理：在这一阶段，数据科学家会对数据进行预处理，并将其划分为训练集（占数据的 70%）、验证集（占数据的 10%）和测试集（占数据的 20%）。你的机器学习模型将使用训练集进行训练，这有助于它学习并给出正确的预测。一旦训练完成，模型将使用单独的验证数据集进行评估，以评估其性能和泛化能力。模型准备好后，你可以使用测试数据集对其进行测试。特征是数据集中的独立属性，可能会影响结果，也可能不会。特征工程包括寻找正确的特征，这可以帮助实现模型的准确性。标签是你的目标结果，依赖于特征选择。你可以应用降维方法来选择正确的特征，从而筛选和提取出最有力的特征。

• 学习：在这一阶段，你根据业务用例和数据选择合适的机器学习算法。这是机器学习工作流的核心，你将在训练数据集上训练你的机器学习模型。为了实现模型的准确性，你需要尝试各种超参数并进行模型选择。超参数是用来控制机器学习算法学习过程的配置设置。

• 评估：一旦你的机器学习模型在学习阶段完成训练，你需要使用已知数据集来评估其准确性。为了评估你的模型，你将使用在预处理步骤中保留的验证数据集。如果模型预测的准确性需要根据验证数据的预期进行修订，则需要根据评估结果进行必要的模型调优。

• 预测：预测也叫做推理。在这一阶段，你将部署模型并开始进行预测。这些预测可以是实时进行的，也可以是批量进行的。

GenAI 引领了机器学习和人工智能领域的范式转变。其核心是基础模型（FMs），如 GPT-4，这些模型已经在庞大的互联网级数据集上进行了训练，重新定义了数据标注和模型定制的传统规范。这项开创性技术使得组织能够在有限的数据令牌下微调基础模型，从而大大减少了传统数据准备过程中所需的人工努力和时间。

然而，必须认识到，生成式人工智能（GenAI）并非灵丹妙药，因为它并非设计来解决所有的人工智能和机器学习问题。此外，生成式模型（FM）的开发是一项资源密集型的工作，需要大量的计算能力和广泛的数据集。因此，许多企业选择利用由知名第三方公司提供的生成式模型，例如 OpenAI、谷歌、Meta 和 Anthropic，这些公司在这些模型的开发中处于领先地位。

然而，故事并不止于此。定制化模型训练仍然是一个有吸引力的选择，特别是当需要特定的定制解决方案时。尽管生成式人工智能提供了一种创新的问题解决方法，但采纳它的战略决策应与组织的独特目标、资源和约束相一致。您将在第十四章《生成式人工智能架构》中了解更多关于生成式人工智能的内容。

根据您的数据输入，机器学习模型常常会出现过拟合或欠拟合问题，您必须考虑这些问题以获得正确的结果。让我们深入了解一下这个问题。

评估机器学习模型——过拟合与欠拟合

在过拟合中，模型需要进行泛化，这意味着它不仅要在其训练过的数据（训练集）上表现良好，还要在新的、未见过的数据（测试集或验证集）上也能表现出色。如果模型发生过拟合，实际上它已经记住了训练数据，捕捉了噪声和底层模式，这会导致在任何新数据上的表现较差。如果模型在训练数据上的表现指标很高，但在测试数据上的指标显著较低，这就是过拟合的标志。

这通常表示模型对训练数据的灵活性过高，使其能够记住数据，包括噪声。过拟合对应于高方差，在这种情况下，训练数据的微小变化会导致结果的显著变化。

在欠拟合中，模型未能捕捉训练数据集中的重要模式。通常，欠拟合表示模型过于简单或解释变量过少。欠拟合模型需要更加灵活，以便能够建模真实的模式，并对应于高偏差，表明结果在某个区域系统性地缺乏拟合。

以下图表清晰地展示了过拟合与欠拟合之间的区别，因为它们对应于一个拟合良好的模型：

图 13.2：机器学习模型的过拟合与欠拟合

该机器学习模型将数据点分为两类，前面的图表中通过圆环和叉号来进行说明。该机器学习模型试图确定顾客是否会购买某个产品。图表展示了三种不同机器学习模型的预测结果。你可以看到一个过拟合的模型（右侧）在训练过程中穿过了所有带圆环的数据点，但无法将算法推广到训练数据集之外的真实世界数据。另一方面，欠拟合的模型（左侧）忽略了若干数据点，准确性不足。一个好的模型（中间）通常能够提供清晰的数据点预测。创建一个好的机器学习模型就像创作艺术；通过调优模型，你可以找到合适的适配方式。

流行的机器学习算法

算法的受欢迎程度通常取决于其在多种应用场景中的适用性和性能、易于理解和实现的程度，以及其扩展性和对不同类型数据的适应能力。让我们来看一些流行的机器学习算法。

线性回归

线性回归试图通过找出它们之间的线性关系来理解某个事物（比如X）如何帮助预测另一个事物（Y）。假设你在农贸市场上。当你观察南瓜的价格时，你会注意到随着南瓜尺寸的增大，其价格也随之上涨。线性回归就像是在所有南瓜价格点之间画一条直线，确保这条线尽可能接近所有的点。

房地产是一个线性回归发挥重要作用的行业。例如，如果一家公司想预测一座房子的售价，它会考虑房间数量、位置和房产年龄等特征。如果过去有更多房间的房子通常卖得更贵，模型就会预测未来更多房间的房子售价较高。这就像根据南瓜的大小预测它的价格一样。

逻辑回归

逻辑回归告诉你某件事情发生的概率或机会，给出的是“是”或“否”的答案。假设你正在预测一本书是否会成为畅销书。逻辑回归将考虑诸如页数、作者的知名度和书籍类型等特征，以预测其成为畅销书的可能性（介于0和1之间）。

在医疗健康领域，逻辑回归可以根据各种症状和检查结果预测患者患病的可能性。例如，通过考虑年龄、血压和胆固醇水平等因素，逻辑回归可以预测一个人患心脏病的概率。如果概率较高，医生可能会进行进一步检查，确保早期发现并积极管理潜在的健康风险。

决策树

决策树通过提问的方式帮助你做出一系列决策。想象你想决定穿什么。决策树可能会问：“下雨吗？”如果回答是“是”，它可能会建议穿雨衣。如果回答是“否”，它可能会问下一个问题，比如“天气热吗？”，然后根据回答建议合适的衣服，帮助你在各种选项中做出最佳选择。

决策树可以帮助预测零售行业中顾客是否会购买某个产品。例如，它可能会问：“顾客在过去一个月内是否购买过商品？”如果回答是“是”，他们可能很快会再次购买。如果回答是“否”，它可能会考虑其他因素，比如最近的网站访问或点击的促销活动，以预测顾客的购买行为，从而帮助零售商通过相关广告和优惠来精准地锁定顾客。

随机森林

顾名思义，随机森林就像是创建了一片森林，每棵树都是一棵决策树，它们通过投票来决定结果。每棵树会得到一个数据的随机子集并做出最佳决策。然后，所有的树“投票”得出最终答案。这种方法通常比单一决策树产生更好、更稳定的预测。

在金融领域，随机森林可以用来预测是否批准或拒绝贷款申请。例如，树可能会考虑不同的因素，如信用评分、收入和债务，做出各自的决策。通过所有树的多数投票，最终的决策比依赖单一模型更准确和稳健，从而减少了糟糕贷款审批的风险。

K-最近邻（k-NN）

使用k-NN 就像是观察一个新事物并尝试通过将它与我们已经知道的相似事物进行比较来理解它。如果你发现了一种以前从未见过的水果，你可能会通过与其他你熟悉的口味相似的水果进行比较，来判断它是甜的还是酸的。如果它看起来像其他甜的水果，你可能会猜它是甜的。

K-NN 广泛应用于推荐系统，如电子商务网站中的推荐系统。如果用户购买了某个特定产品，k-NN 会找到其他相似用户也购买过的类似产品，并将它们推荐给该用户。例如，假设某个用户购买了一本侦探小说，那么 k-NN 会寻找其他也购买了这本小说的用户，并推荐这些用户购买的其他书籍，从而通过展示相关产品增强用户的购物体验。

支持向量机（SVM）

支持向量机（SVM）是一种决定性的算法，旨在保持事物的清晰和分离。想象你有一张大桌子，把苹果放在一边，香蕉放在另一边。SVM 会尝试找到一条最宽的线（或空隙）来分开这两种水果，以确保所有苹果都在一边，所有香蕉都在另一边，避免混淆。

在手写识别领域，支持向量机（SVM）非常有帮助。例如，如果你写了一个数字“4”，SVM 能帮助计算机判断它是“4”还是“9”，通过查看大量人们如何书写这些数字的例子，并找到最佳的边界，将“4”和“9”区分开来，从而帮助计算机准确识别手写数字。

神经网络

将神经网络视为计算机内部的一个迷你大脑，它通过大量的例子学习以做出决策。当你学骑自行车时，最初可能会摔倒，但随着时间的推移，你会通过理解之前失败的原因来学习如何保持平衡和蹬踏。神经网络的学习过程也类似，它通过调整错误来做出更好的决策。

例如，社交媒体平台使用神经网络进行图像识别，帮助识别并标记照片中的人物。网络通过查看许多该人的照片，并注意像鼻子形状和眼睛颜色等特征来进行学习。当上传一张新照片时，它将这些特征与已学到的知识进行对比，做出最合适的判断，识别照片中的人物。

K-means 聚类

K-means 聚类是一种将相似的数据点进行分组的方法。这就像组织一个大型派对，你想把那些兴趣相似的朋友分成几个小组（或簇），让他们互相之间更好地享受彼此的陪伴。你反复尝试不同的方式来分组，确保每个小组内的人尽可能相似，从而确保每个人都能玩得开心。

k-means 的一个流行应用是用于市场营销策略中的客户细分。企业可以使用 k-means 根据顾客的购买行为将其分组。例如，一个群体可能是那些频繁购买但每次消费较少的顾客，而另一个群体则可能是那些不常购买但每次购买金额较大的顾客。每个群体可以通过不同的营销策略进行精准定位，从而最大化销售。

XGBoost

XGBoost 从过去的错误中学习，每做出一次决策，它都会变得更加聪明。如果你在解决数学问题时答错了题，XGBoost 会分析这个错误，理解出错的原因，并记住这个错误，以便下次面对类似问题时不会重复同样的错误。

在信贷行业，XGBoost 被广泛用于预测客户是否会违约贷款。通过分析收入、年龄、以往贷款历史等多个因素，预测客户违约的可能性。如果一个申请人的违约风险较高，那么贷款可能会被拒绝，从而减少银行的风险。

这些算法是许多机器学习项目的基础，选择时会根据具体问题和数据类型（例如文本、图像、数值数据）来决定。像神经网络这样的算法可能需要更多的计算资源和数据，而像决策树或 k-NN 这样的算法，即使在较小的数据集上也可能适用。

我们继续探索机器学习，接下来将介绍流行的机器学习工具和框架。

流行的机器学习工具和框架

机器学习使用各种工具和框架来完成，每种工具和框架都旨在帮助开发机器学习模型的不同方面——从数据处理、算法设计到模型训练和部署。以下是一些流行的工具和框架。

数据准备和探索的流行工具和框架包括：

• NumPy：核心的 Python 科学计算库。数值 Python，或称 NumPy，是一个多维数组对象库，并提供一组用于操作这些数组的运算。

  数组是相同类型的数据项集合，存储在连续的内存位置中。

  NumPy 使在大数据集上进行数值和逻辑操作变得更加容易和高效。假设某零售公司希望计算月度平均销售额，以分析业绩并决定未来的策略。他们拥有以数字格式存储的每日销售数据。使用 NumPy，他们可以轻松通过将每日销售数据组织成数组、求和并除以天数来计算月度平均销售额。

• Pandas：一个为 Python 用户提供简单、高性能数据结构和数据分析能力的库，使用户能够分析和操作数据。它呈现了 Series 和 DataFrame 两个基础数据结构，它们是构建在 NumPy 之上的。

  Series 是一列，DataFrame 是由多个 Series 组成的多维表格。

  Pandas 的功能使数据清洗、分析和可视化变得简单。例如，假设某个超市希望分析其销售数据，以了解哪些产品销量最好，哪些产品销量不佳。他们拥有一个包含每笔交易信息的大数据集，其中包括产品名称、销售数量和价格。使用 pandas，他们可以轻松操作这些数据，计算每个产品的总销售额，对其进行排序，并找出最畅销的商品。

• Scikit-learn：一个简单有效的预测数据分析工具，支持与 pandas 和 NumPy 一起使用。scikit-learn 支持许多监督学习和无监督学习技术。它在机器学习（ML）、数据挖掘和数据分析中得到了广泛应用。Scikit-learn 拥有许多内置工具，用于模型选择、评估、数据导入和改进。假设某银行希望预测客户是否会违约。他们拥有关于以前客户的历史数据，包括年龄、薪水、婚姻状况以及是否违约。使用 scikit-learn，他们可以建立一个模型（如决策树、逻辑回归或其他合适的算法），从这些数据中学习，然后利用该模型预测新客户违约的可能性。

数据可视化的流行工具和框架包括：

• Matplotlib：一个流行且功能丰富的 Python 库，用于制作静态、互动和动画可视化图表。除了线图、散点图、误差条图、直方图、条形图、饼图、箱形图和 3D 图表外，Matplotlib 还提供了一个极为多功能的基础，能够创建各种各样的可视化图表。这个工具使开发者和数据科学家能够以多种图表形式可视化他们的数据，这对理解数据分布和模式、调试问题或可视化数据之间的关系非常有用。假设一位老师希望直观地展示班级学生的成绩，以便快速突出总体表现和异常值。使用 Matplotlib，老师可以创建多种图表，如条形图、散点图或直方图，以易于理解的可视化格式表示成绩分布。

• Seaborn：一个基于 Matplotlib 的统计数据可视化库，提供了一个高层接口，用于设计美观的图表。Seaborn 具有多个内置主题和配色方案，使得创建美观且信息丰富的图表变得容易。由于它支持创建多图布局并能够可视化多个变量之间的关系，因此特别适合用于可视化具有多个变量的复杂数据集。假设一家零售公司希望了解其在不同时间段内在不同产品类别中的客户购买行为。通过 Seaborn，分析师可以创建热力图，以可视化表示各月不同产品类别的购买频率，从而快速洞察趋势和客户偏好。

• 商业智能（BI）工具：如 Tableau、Microsoft Power BI、Amazon QuickSight 和 MicroStrategy 等 BI 工具用于将原始数据转换为易于理解的格式。这些工具帮助人们可视化、理解并基于数据做出决策。与其他工具不同，这些工具提供图形用户界面，允许用户通过拖放项目来分析数据，使得没有编程背景的人也能轻松使用。BI 工具可以连接多个数据源，提供实时的数据洞察。你可以创建并分享仪表板，提供嵌入分析的互动式可视化图表。假设一家餐饮连锁企业希望根据客户购买行为和季节性趋势优化供应链和菜单。通过使用 BI 工具，公司可以在不同维度（如时间、客户人口统计和产品类别）上可视化销售数据，从而识别模式并为决策过程提供支持。

模型开发和训练的流行工具和框架包括：

• TensorFlow：一个全面的开源平台，旨在管理各种机器学习任务。TensorFlow 支持一系列 API，用于构建、训练和部署 AI 模型。TensorFlow 的一个关键特点是其创建数据流图的能力。这些图展示了数据如何在一系列处理步骤或节点中流动。在这些图中，每个节点代表一个数学操作，节点之间的连接，称为边，表示张量，张量是多维数据数组。TensorFlow 为开发者提供了工具，支持大规模机器学习，并拥有广泛的库，方便不同水平的学习者和开发者构建 AI 模型。假设一个医疗初创公司想要利用机器学习，根据患者的年龄、基因、体重和生活习惯等多项指标预测疾病的发生。他们可以利用 TensorFlow 构建一个神经网络模型，综合考虑这些因素，预测疾病发生的可能性。

• PyTorch：一个流行的机器学习库，因其灵活性、易用性和动态计算图而广受欢迎，特别适用于深度学习。开发者、研究人员和数据科学家都因其灵活性和广泛的功能在研究和生产中青睐它。动态计算图使用户能够随时更改网络行为，而该库提供了丰富的 API，适用于分类、回归、强化学习等各种机器学习任务。比如，一个电商公司想要开发一个聊天机器人来提升客户体验。使用 PyTorch，他们可以开发一个深度学习模型，理解客户语言，并实时提供有用且准确的响应。

• Keras：一个开源软件库，作为构建和训练深度学习模型的易用 API。它可以运行在其他流行的机器学习库如 TensorFlow 之上，使其具有高度的灵活性。Keras 特别因其简洁性和易于实验而受到青睐。借助 Keras，数据科学家和开发者可以在最短的时间内将想法转化为成果，这在创新项目中至关重要。假设一家零售公司试图根据客户的历史购买记录向其推荐产品。该公司可以使用 Keras 创建一个推荐系统，分析客户的购买模式，建议他们可能会购买的产品。

• Apache Spark 的 MLlib：这是 Apache Spark 的一部分，是一个机器学习库，旨在扩展以满足大数据的需求。MLlib 提供了多种机器学习算法，包括分类、回归、聚类和协同过滤，还提供了模型选择和评估工具。它还提供了保存模型以供后续使用的 API。MLlib 的设计旨在高效处理大规模机器学习任务。凭借其分布式计算能力，MLlib 能够迅速处理庞大的数据集，使其在大规模数据分析和模型训练至关重要的场景中尤为有价值。此外，MLlib 能够与不同的数据源和格式配合使用，提供了处理各种数据类型的灵活性。假设有一个金融机构希望实时识别信用卡交易中的欺诈行为。通过使用 MLlib，数据科学家可以利用大量的交易数据训练模型，识别出不寻常的购买模式或表明欺诈的异常交易，从而实现欺诈行为的实时检测和缓解。

常见的模型部署工具和框架包括：

• Docker：一个旨在简化使用容器创建、部署和运行应用程序的的平台。Docker 本身并不是一个机器学习工具，但它在高效、一致地部署机器学习模型和应用程序中发挥着关键作用。Docker 允许开发人员和数据科学家将应用程序及其所有依赖项（库、工具和脚本）打包成一个“容器”。这个容器可以在各种计算环境中进行传输并一致运行，这意味着无论在什么地方运行，应用程序都会表现相同。假设有一个软件开发团队正在创建一个机器学习应用程序来预测股价。他们有数据科学家使用各种工具和库来创建模型，同时有软件工程师使用不同的技术来构建应用程序。通过使用 Docker，他们可以创建一个统一的工作流程，在这个工作流程中，团队中的每个人都能在一致的环境中工作，确保模型和应用程序在开发、测试和部署过程中表现一致，尽管使用了不同的工具进行开发。

• Flask：一个用 Python 编写的微型 web 框架。它易于学习和使用，非常适合初学者，但不包括全栈框架可能提供的附加功能（如表单验证或数据库抽象层）。然而，正是因为其简单性和易用性，使得它在部署轻量级 web 应用程序和 API，尤其是在数据科学和机器学习社区中非常受欢迎。设想一个数据科学家的场景，他开发了一个机器学习模型来预测电子邮件是否为垃圾邮件。这个模型可以通过 web 应用程序来使用，用户提交电子邮件后，应用程序会告诉他们邮件是否为垃圾邮件。通过使用 Flask，数据科学家可以创建一个简单的 web 服务器，接收电子邮件文本，利用机器学习模型预测是否为垃圾邮件，并通过 web 界面将结果返回给用户。

常见的集成开发环境（IDEs）包括：

• Jupyter Notebook：一个开源的 web 应用程序，能够创建和共享互动文档。这些文档可以包含实时代码、方程式、可视化内容和解释性文本，使其成为数据分析、科学研究和教育用途的多功能工具。它支持多种编程语言，如 Python、R 和 Julia，并因其互动计算环境广泛应用于数据清理、统计建模、机器学习等领域。Jupyter 在数据科学、学术研究和科学计算中至关重要，因为它使用户能够创建可复现的分析，并通过可视化和叙述性文本有力地传达其结果。我们可以考虑一个生物学家分析鸟类物种及其迁徙数据的场景。该生物学家可以使用 Jupyter Notebook 编写 Python 代码，加载数据、可视化迁徙模式，甚至可能利用机器学习根据历史数据预测未来的迁徙时间或路径。

• RStudio：一个开源的 R 语言集成开发环境（IDE），适用于统计计算和图形编程语言 R，它可以与 R 的标准版本以及云端提供的 R 版本配合使用。RStudio 提供了一整套强大的功能，用于脚本开发、数据可视化和统计分析，支持 R 语言的全面应用。设想一个零售公司希望了解其客户的购买行为。通过使用 RStudio，数据分析师可以输入销售数据，进行统计分析，并创建可视化图表（如散点图、直方图或柱状图）来识别购买趋势、热门商品和高峰购物期，并可能利用机器学习预测未来的销售趋势。

• Apache Zeppelin：一个开源的基于笔记本的环境，类似于 Jupyter，允许数据工程师、数据分析师和数据科学家开发、组织、执行和共享数据工作流，并协同执行代码。Zeppelin 支持多种数据处理后端，如 Apache Spark、Python 和 JDBC。用户可以使用 Scala、Python、SQL 等创建数据驱动的、互动式和协作式的文档。Zeppelin 的一个特别优势在于其内置的数据可视化功能，以及一些 Jupyter 用户无法直接使用的集成。例如，在医疗健康领域，分析师希望探索患者数据以理解疾病爆发的模式。通过 Zeppelin，他们可以互动式地探索数据集，整合各种数据处理后端，并创建如热力图或折线图等可视化效果，以便在地理区域或时间线中直观展示疾病爆发的情况。

Zeppelin、RStudio 和 Jupyter Notebook 是数据工程师用于数据发现、清理、增强、标注和为机器学习模型训练做准备的最常见环境。

随着云计算成为机器学习模型训练的首选平台，接下来让我们了解一些现有的机器学习云平台。

云中的机器学习

机器学习开发是一个复杂且昂贵的过程。在机器学习工作流的每个步骤都有采纳的障碍，从收集和准备数据（这是一项耗时且没有差异化的工作），到选择正确的机器学习算法（通常依赖于试错法），再到漫长的训练时间（导致成本更高）。然后是模型调整，这可能是一个非常长的周期，需要调整成千上万种不同的组合。一旦模型部署完成，还必须对其进行监控，随后进行扩展和管理其生产环境。

为了解决这些挑战，所有主要的公共云供应商都提供了一个机器学习平台，便于在任何地方以低成本进行训练、调整和部署机器学习模型。例如，Amazon SageMaker 是其中一个最受欢迎的平台，提供端到端的机器学习服务。SageMaker 通过 SageMaker Studio 将用户所需的各种工具集成在一个工作台中，提供了一个统一的工作环境。用户可以通过 SageMaker Studio 即时启动 Jupyter Notebook 和 JupyterLab 环境。SageMaker 还提供完整的实验管理、数据准备以及管道自动化和编排，帮助数据科学家提高生产力。SageMaker 还提供完全托管的 RStudio 平台，这是 R 开发者在机器学习和数据科学项目中最受欢迎的 IDE 之一。SageMaker 提供完全托管的云端服务器。除了笔记本，SageMaker 还提供其他托管基础设施功能。从分布式训练任务、数据处理任务，甚至是模型托管，SageMaker 负责所有与构建、训练和托管模型相关的扩展、修补、高可用性等工作。

类似地，GCP 提供了 Google Cloud AI 平台，包含不同的服务来执行机器学习实验，而 Microsoft Azure 提供了 Azure ML Studio。

除了托管的机器学习平台，云服务商还提供现成的人工智能服务。人工智能服务让开发者无需具备机器学习技能，就能轻松地为任何应用程序添加智能。预训练的模型为您的应用程序和工作流提供现成的智能，帮助您个性化客户体验、预测业务指标、翻译对话、提取文档中的意义等等。例如，AWS 提供了 Amazon Comprehend AI 服务，其内置的预训练模型支持多语言的关键短语检测和情感分析。

云计算越来越成为访问和使用 GenAI 基础模型的主要平台，提供一个具成本效益和可扩展的环境，用于测试和部署这些先进的人工智能系统。这些基础模型在庞大的数据集上进行了训练，并可以针对特定任务进行微调，使其成为广泛应用的多功能工具。云的可扩展性和资源可用性使其成为处理这些大型、资源密集型模型的理想环境。开放源代码和商业 GenAI 基础模型都可用，提供了适应不同需求和预算的选项。

通过云端访问 GenAI 基础模型的可获取性，正在使先进的人工智能能力更加普及，使得企业和开发者能够在无需大规模前期投资计算基础设施的情况下，利用最前沿的人工智能技术。例如，使用 API，Amazon Bedrock 允许您访问来自稳定性.ai、Meta、Mistral、Anthropic、Amazon 和 AI21 等公司的多个第三方基础模型。同样，Azure 提供了对 OpenAI GPT-4 的 API 访问，而 GCP 提供了对其基础模型 Gemini 的访问。您将在第十四章 生成式 AI 架构 中了解更多。

数据科学家可以利用托管的云环境来加速数据准备和模型训练。完成后，他们可以一键部署模型，并开始通过 HTTP 提供推理服务。

让我们进一步了解设计机器学习架构时需要考虑的一些关键事项。

构建机器学习架构

从一堆松散的代码集合中构建一个健壮且可扩展的工作流是一个复杂且耗时的过程，许多数据科学家需要积累构建工作流的经验。一个机器学习工作流可以定义为一个包含多个步骤的有序序列。数据科学家和机器学习开发者首先需要将众多代码片段进行打包，然后指定它们执行的顺序，并追踪每个步骤之间代码、数据和模型参数的依赖关系。

机器学习工作流中的复杂性增加了对训练和预测数据变化的监控需求，因为数据变化可能引入偏差，从而导致不准确的预测。除了监控数据外，数据科学家和机器学习开发人员还需要监控模型预测，确保预测的准确性，并防止随着时间推移模型的预测结果趋向某些特定方向。因此，可能需要几个月的自定义编码才能确保单独的代码能够按照正确的顺序执行，并按预期工作。

机器学习架构需要保护模型工件，并提供自服务功能来支持模型开发和训练。确保您的机器学习架构能够自动化、全面地记录整个模型开发生命周期的每个阶段，包括开发、训练和部署。

机器学习应用程序还应该采用与变更控制系统无缝集成的持续集成和持续部署（CI/CD）管道。这种集成对于模型管理和部署至关重要。此外，这些环境需要预定义的安全配置。

以下是来自AWS机器学习平台的机器学习架构组件，帮助您理解机器学习架构。

其他机器学习平台包括 Azure ML Studio、H2O.ai、SAS、Databricks 和 Google AI 平台。

准备与标注

为机器学习准备数据时，您需要运行数据处理工作负载，例如特征工程、数据验证、模型评估和模型解释。特征工程还会预处理数据集，将输入数据集转换为机器学习算法所期望的格式。例如，如果您正在处理一个包含日期的数据集，您可能会将星期几、月份和一年中的时间提取为单独的特征，因为这些特征可能对您的模型具有预测价值。您可以使用前面提到的各种工具和技术，根据您的机器学习需求处理数据。像 Amazon SageMaker 这样的托管机器学习平台还提供数据处理工具和特征存储功能，简化数据处理工作。SageMaker Data Wrangler 允许您通过可视化界面访问、合并、清理和转换数据，轻松准备数据用于机器学习。此工具帮助您在不编写代码的情况下执行常见的数据准备任务，加快了处理过程，并减少了出错的机会。

此外，SageMaker 特征存储是一个集中式仓库，用于存储、共享和管理机器学习模型的精选特征。这样可以确保不同模型之间的一致性，并减少特征工程工作中的冗余。特征存储有助于保持训练和推理过程中一致的特征集，从而促进更好的模型性能和更易于维护的模型。

在数据处理阶段，对数据进行标注是一个至关重要的步骤。这个过程有助于组织和构建准确的机器学习数据集。为了简化这一过程，你可以使用专门从事数据标注的第三方服务，如 Labelbox、CrowdAI、Docugami 和 Scale，它们在图像标注和其他类型的数据注释方面有丰富的经验。此外，像 Amazon SageMaker Ground Truth 这样的平台也提供了图像数据标注的自动化解决方案。

一旦数据准备好，下一步就是选择合适的算法并构建模型。

选择并构建

在创建机器学习模型之前，你需要清楚地理解业务问题，这将帮助你选择合适的算法。如前面所述，你可以从一系列算法和机器学习框架中选择，广义上包括监督和无监督机器学习算法。选择的算法可能会受可用数据的影响。一旦你为你的应用场景选择了合适的算法来构建机器学习模型，你就需要一个平台来训练和开发模型。

Jupyter Notebook 和 RStudio 是数据科学家中最流行的构建机器学习模型的平台。你可以使用云平台，如 Amazon SageMaker，来启动 Jupyter Notebook 或 RStudio Workbench。AWS 提供了 SageMaker Studio 和 RStudio，这是一个基于 web 的可视化界面，在这里你将执行机器学习的所有开发步骤。

为了选择模型，你可以选择几种内置的机器学习算法，这些算法可以用于各种问题类型，或者在云市场上找到一系列可用的模型和算法，这使得快速入门变得更加容易。

下一步是训练和调优模型。让我们进一步了解这个过程。

训练和调优

为了加速训练过程，建议利用分布式计算集群。这样的设置可以让你将训练负载分配到多个计算资源上，从而显著加快训练阶段。通过使用这样的集群，你可以实现计算的并行化，这意味着训练数据的不同部分可以同时处理。因此，模型训练完成得更快，应用程序可以使用的输出也更快地可用。这种方法不仅提高了效率，还使得处理更大的数据集成为可能，有助于开发出更准确、更强健的机器学习模型。模型调优，也被称为超参数调优，是实现结果精度的关键。

你需要通过在数据集上运行多个训练任务，使用所选算法并调整超参数范围，来找到最有效的模型版本。接着，选择正确的超参数值，从而获得表现最佳的模型，这个性能是通过你选择的度量标准来确定的。

在调整模型时，拥有调试功能至关重要，这可以帮助捕捉训练阶段的实时指标，例如训练和验证准确率、混淆矩阵以及学习梯度。这些指标对于提高模型的准确性至关重要。此外，生成文档以帮助提升模型准确性也是非常重要的。你需要捕获输入参数、配置和结果，并将它们归类为不同的实验。这种组织方式使你能够根据特征高效地搜索先前的实验，查看先前实验的结果，并直观地比较各种实验的结果，从而指导进一步的调整和改进。大多数托管的机器学习平台，例如 Amazon SageMaker，都会为你提供这些功能。

Amazon SageMaker 还提供了 Autopilot，这是一个自动化模型开发的功能。Autopilot 会检查原始数据并应用特征处理技术。然后，它会选择最合适的算法，进行训练，调优多个模型，并监控它们的性能。这些模型会根据其性能指标进行排名。

在最终确定你的模型后，你需要将其部署并在生产环境中进行管理，以便获取有价值的洞察并实现预期的结果。

部署和管理

你必须将训练好的机器学习模型部署到生产环境中，以实现实时或批量数据预测。为你的机器学习实例在不同位置实施自动扩展，以确保高冗余性，并为你的应用程序建立一个 RESTful HTTPS 端点。该应用程序应配置 API 调用机器学习端点，以实现低延迟和高数据处理速度。这种架构方法有助于将新的模型快速集成到你的应用程序中，因为模型的更改不需要修改应用程序代码。

数据由于季节性或不可预见的事件等因素可能发生快速变化，因此持续监控你的模型以确保其准确性和与业务的持续相关性至关重要。一个可能影响部署模型准确性的关键因素是，用于生成预测的数据与用于训练模型的训练数据有所不同。例如，经济条件的变化可能带来新的利率，这可能会影响到房屋购买预测。这种现象称为概念漂移（concept drift），即模型训练时所依赖的模式和关联在当前数据环境中已不再成立。为了解决这一问题，你需要自动检测部署模型中的概念漂移，并通过详细的警报帮助 pinpoint 问题的具体来源。

模型兼容性是部署过程中另一个关键因素。一旦使用 MXNet、TensorFlow、PyTorch 或 XGBoost 等构建并训练了模型，您可以从 Intel、NVIDIA 或 ARM 中选择目标硬件平台。您需要编译您的训练好的 ML 模型，以便在部署编译后的模型到边缘设备时能够优化并高效运行。此步骤确保您的模型不仅能提供高性能、低成本的推理，还能保持成本效益。

您应该能够运行大规模的 ML 推理应用程序，包括图像识别、语音识别、自然语言处理（NLP）、个性化推荐和欺诈检测等任务。当您在构建和部署 ML 模型的不同阶段取得进展时，了解如何对它们进行微调和调整以实现高效部署和操作变得尤为关键，特别是对于那些需要实时处理和响应的应用程序。让我们看看一个参考架构，连接所有组件。

ML 参考架构

以下示例架构描述了一个基于客户数据的银行贷款审批工作流，该工作流建立在 AWS 云平台上。

客户数据被摄取到云中，ML 框架决定客户贷款申请的审批结果。

图 13.3：AWS 云中的 ML 架构

在设计上述架构时，需要考虑的一些基本设计原则包括：

• 训练工作流：

  1. 数据集通过 S3 进入流程。此数据可以是原始输入数据或从本地数据集预处理后的数据。

  2. Ground Truth 用于构建高质量的、有标签的训练数据集以供 ML 模型使用。如有需要，Ground Truth 服务可以为数据进行标注。

  3. AWS Lambda 可用于数据集传递到 SageMaker 之前的数据集成、准备和清理。

  4. 数据科学家将与 SageMaker 接口，训练和测试他们的模型。SageMaker 使用的 Docker 镜像存储在 ECR 中，可以是通过构建流程步骤创建的自定义镜像，或者使用预构建的亚马逊镜像。

  5. 用于部署阶段的模型工件输出到 S3。SageMaker 模型的输出也可以用来使用 Ground Truth 标注数据。已经在本地或其他平台预先构建并训练的模型可以存储到模型工件 S3 桶中，并通过 SageMaker 部署。

  6. AWS Lambda 可以基于新的模型工件被存储到 S3 桶中触发审批工作流。

  7. 亚马逊简单通知服务（SNS）可以用于提供基于人工干预的自动或手动审批工作流，以部署最终模型。支持的 Lambda 函数从 SNS 获取输出并部署模型。

  8. DynamoDB 存储所有模型元数据、操作和其他相关数据，用于审计跟踪。

  9. 为了托管最终模型，我们在工作流的最后一步部署关联的配置作为终端节点。

• 构建工作流：

  1. SageMaker Notebook 实例用于准备和处理数据，并训练和部署机器学习模型。这些笔记本可以通过 SageMaker 服务的 VPC 终端节点进行访问。

  2. CodeCommit 提供源代码的存储库，用于触发 SageMaker 所需的构建作业，以便使用任何自定义的 Docker 镜像。

  3. CodePipeline 服务管理自定义 Docker 镜像的端到端构建管道，并在构建/测试阶段使用 CodeBuild 服务。

  4. CodeBuild 将构建并执行自定义 Docker 镜像的单元测试，并将其推送到 Amazon ECR（该过程可以由中央管理或需要工具的业务功能来管理）。

• 部署工作流：

  1. 由于 SageMaker 终端节点是私有的，Amazon API Gateway 将模型终端节点暴露给最终用户以进行推理。

批量转换作业通常用于获取整个数据集的推理结果。通过使用训练好的模型和数据集，批量作业的输出将存储在 S3 中。此外，您可以利用 SageMaker Model Monitor 来监控生产模型，并在出现质量问题时发送警报。

本节介绍了具有 CI/CD 管道的机器学习架构。接下来，我们将讨论机器学习架构的设计原则。

机器学习架构设计原则

设计有效的机器学习架构需要采取战略性的方法，优先考虑可扩展性、可维护性、效率和可靠性。以下是开发机器学习架构时，专业人士通常遵循的一些设计原则。

将机器学习系统组织成模块

模块化 将机器学习系统拆分为独立的、可互换的组件或模块，每个模块负责特定功能。例如，在一个机器学习模型中，您可以有一个模块用于数据摄取，另一个用于预处理，一个用于模型训练，再有一个用于预测服务。以零售推荐系统为例：数据摄取模块可能负责收集用户交互和购买历史，而另一个模块使用这些数据训练一个推荐产品的模型。其优点在于，如果开发出更好的推荐算法，训练模块可以被替换或更新，而不会干扰数据摄取模块。

在 金融欺诈检测系统 中，模块化使开发团队能够在发现新的欺诈模式时，隔离并更新预测模型，而无需改变数据收集或交易监控模块。采用这种分隔式方法，有助于简化故障排除、进行有针对性的升级，并普遍增强系统的可管理性。

确保可扩展性

可扩展性是指机器学习架构在处理工作负载或需求增加时，能够优雅地应对，确保性能的一致性。当管理更大数据集或用户请求显著增加时，这一点尤为重要。例如，在像 Netflix 这样的流媒体服务中，推荐系统必须能够扩展，以适应不断增长的用户数量和他们的观看历史，同时不影响推荐的速度和准确性。可扩展性确保了即使数据和需求增长，服务依然能够保持不间断且持续高效。

另一个现实世界中的例子是电子商务平台在黑色星期五大促期间。系统必须能够扩展，以处理和分析成倍增加的交易和用户数据。

确保可重复性

确保机器学习模型能够可靠地再现结果至关重要。这意味着，如果用相同的数据、代码和参数重新训练模型，它应该产生相同的结果。一个电子学习平台可能会使用机器学习模型为每个用户个性化学习内容。如果某个特定版本的模型产生了显著的结果，能够再现这一结果就能确保一致的用户体验，并有助于未来的调试和开发。

以一个用于诊断医疗状况的机器学习模型为例，这个模型利用医疗影像数据。在医疗保健领域，确保可重复性意味着诊断结果在模型的不同实例中保持一致且可靠，从而增强医疗专业人员和患者对自动化系统的信任，并确保使用该模型的科学研究有效且可验证。

实施数据质量保证

数据质量保证是指实施机制，以验证并确保输入到机器学习模型中的数据的准确性、完整性和可靠性。对于像语音激活虚拟助手这样的系统，它会不断从用户交互中学习以提高响应准确性，确保输入数据的准确性和相关性对于有效训练模型至关重要。故障或低质量的数据可能导致模型学习到错误的模式，从而降低用户体验。

以自动驾驶汽车导航系统为另一个例子，确保数据质量至关重要，因为基于这些数据做出的决策直接影响车辆的安全性和效能。

确保灵活性

灵活性在机器学习架构中指的是系统能够轻松修改和适应数据、技术和需求变化的能力。一个灵活的系统可以整合新的数据源，管理不同的数据类型，并根据需要适应不同的算法或技术。比如，假设有一款新闻聚合应用，使用机器学习为用户个性化推荐内容。灵活性使得该应用能够轻松地将其模型适应新的数据源（如新的新闻网站），或整合新的数据类型（如视频新闻或播客），而无需进行全面的架构重设计。

以客户支持聊天机器人为例，拥有灵活性可以让聊天机器人根据不断变化的用户期望和语言趋势调整其回应和互动风格。假设模型识别到用户互动风格的变化或特定询问的激增，灵活的架构使其能够整合新数据或调整算法，从而提高用户互动和满意度。

确保稳健性与可靠性

确保稳健性与可靠性意味着机器学习架构应产生一致、可靠的结果，并能抵御输入数据变化或系统干扰。例如，一个稳健的电子邮件提供商的机器学习模型应始终如一地过滤垃圾邮件，无论垃圾邮件的技术手段或消息内容如何变化。即使垃圾邮件发送者更改策略或使用不同的语言和术语，它也应始终可靠地保护用户的收件箱。

在自动化股票交易中，机器学习模型的稳健性与可靠性至关重要，以确保交易决策的一致性，并能保护交易免受市场波动或欺诈性交易行为的影响。机器学习系统必须能够识别并应对市场噪声、错误数据或操控性交易活动，从而保护投资并维持投资者的信任。

确保隐私与安全

隐私与安全包括保护数据和机器学习模型免受未经授权的访问，并确保个人或敏感数据的处理符合伦理，并遵守相关法规。例如，在一款使用机器学习提供财务建议的个人财务应用中，保护用户的财务数据并确保模型的预测免受恶意攻击，既能保护用户隐私，也能维护模型的完整性。

将个性化营销作为一个应用场景，处理用户数据，如购物历史、偏好和个人信息时，必须确保隐私和安全。确保生成个性化营销内容的机器学习模型遵守数据保护法规，并能抵抗数据泄露，从而保护最终用户。这同时也维护了品牌的声誉和法律合规性。

确保效率

效率是指在最大化机器学习系统性能的同时，最小化资源的使用。一个高效的机器学习模型确保计算、数据存储和其他资源的使用得到优化，同时不影响模型输出的质量。在使用机器学习功能如图像识别或语言翻译的移动应用程序中，高效的模型可以提供快速准确的结果，而不会过度消耗设备的电池或使用过多的计算资源。

实时欺诈检测在在线交易中的一个例子突显了效率的必要性。机器学习模型必须快速分析交易数据并准确识别欺诈活动，以提供即时警报或采取行动，同时管理计算资源以处理每秒发生的无数交易。效率确保了快速、准确的欺诈检测，而不会在交易处理时带来不可持续的计算成本或延迟。

确保可解释性

确保机器学习架构中的可解释性意味着模型输出对人类来说是可理解和可解释的。例如，使用机器学习帮助医生诊断疾病的医疗平台应该提供对其预测的解释，使医生能够理解诊断建议背后的推理，从而为患者护理做出明智决策。

考虑一个信用评分的机器学习应用。可解释性对最终用户至关重要，他们可能希望理解影响他们信用评分的因素，同时对监管机构也很重要，监管机构确保评分模型不具有偏见并符合法律标准。一个可解释的机器学习模型可以阐明哪些因素（例如，交易历史、贷款偿还等）影响信用评分，从而提供透明度并促进用户和监管机构之间的信任。

实施实时能力

实时能力指的是机器学习架构能够实时或接近实时地处理数据并产生输出的能力，这在需要即时决策的场景中至关重要。例如，自动驾驶汽车利用机器学习根据来自各种传感器和摄像头的实时输入做出即时决策，如识别障碍物并决定最佳路径。该架构必须处理、评估并根据实时数据做出决策，以安全地导航动态环境。

在虚拟助手和聊天机器人提供的客户支持中，实时能力确保客户的查询能够立即并准确地得到解决，从而提升用户体验和满意度。机器学习模型必须理解用户输入、处理相关数据，并生成实时响应，以促进顺畅和连贯的互动，即使用户的查询和对话不断变化和升级。

确保容错性

容错性意味着 ML 架构应该在某些系统组件发生故障或遇到意外输入数据时，依然能保持其功能并产生合理的输出。例如，即使某些数据源（如最近的浏览历史）暂时不可用，电子商务推荐系统也应该继续向用户提供产品推荐，从而确保持续的用户参与和潜在销售。

在使用 ML 进行工业设备监控，以预测维护需求和检测故障时，容错性确保即使某些传感器发生故障或提供不稳定数据，系统仍能提供有价值的洞察。ML 模型应能够识别并处理这些异常，提供可靠的设备健康评估，确保工业环境中的安全和持续运作。

通过遵循这些 ML 架构原则，模型可以在各种实际应用中稳健地运行，从确保行业中的安全高效运作到在客户支持中提供实时且富有洞察力的互动。

ML 无处不在；例如，它可以应用于解决客户问题，如预测性维护、为企业提供准确的预测，或为最终用户构建个性化推荐。ML 的应用场景不仅限于客户问题，还可以帮助你管理 IT 应用程序，通过预测性扩展优化工作负载、识别日志模式、在问题产生之前修复错误，或进行 IT 基础设施的预算预测。因此，解决方案架构师必须了解 ML 的应用场景和相关技术。

在本书的早期部分，你学习了如何使用 DevOps 来自动化并使开发工作流实现操作化。随着 ML 的普及，MLOps 已成为在生产环境中大规模学习 ML 的关键。让我们进一步探索如何通过 MLOps 来实现 ML 工作流的操作化。

MLOps

ML 工作流是一系列开发和执行的操作，旨在生成一个数学模型，最终用于解决实际问题。但这些模型在没有部署到生产环境之前，除了作为概念验证外，并没有实际价值。ML 模型几乎总是需要部署到生产环境中才能为业务提供价值。

从本质上讲，MLOps 主要关注将一个实验性的 ML 模型转变为一个完全操作化的生产系统。MLOps 是一种新兴的实践，区别于传统的 DevOps，因为 ML 的开发生命周期具有独特性，并且它生成的特定 ML 工件也有所不同。ML 生命周期围绕从训练数据中发现模式进行，这使得 MLOps 工作流对数据变化特别敏感，尤其是数据量和质量的变化。

一个完善的 MLOps 实践应支持对 ML 生命周期活动的监控，以及对已投入生产环境的模型进行持续监督。这一双重关注确保了开发过程的效率和部署模型的有效性。

MLOps 的实施使组织能够轻松自信地建立成熟的 MLOps 框架，消除大量的编码工作。像其他工作负载一样，你希望通过应用最佳实践，如安全性、可靠性、高可用性和性能，同时考虑 ML 生命周期部署阶段的成本，来开发 MLOps。让我们看看一些 MLOps 原则。

MLOps 原则

代码、训练数据或模型的任何变化都应触发 ML 开发流程中的构建过程，以确保通过立即适应变化，模型能够良好运行。

在开发 ML 系统时，ML 流水线应遵循这些 MLOps 原则：

• 自动化：ML 模型的生产部署应当实现自动化。MLOps 团队应当自动化端到端的 ML 工作流，从数据工程到生产中的模型推理，且不需要人工干预。这种自动化确保了在训练数据发生变化时，生产模型不会中断，且模型始终保持相关性。MLOps 流水线可以根据事件触发模型训练和部署，事件如日历调度、消息传递、监控、数据变化、模型训练代码变化和应用代码变化。

• 版本控制：版本控制是 MLOps 的重要方面。每个 ML 模型及相关脚本版本都应保存在版本控制系统中，如 GitHub，以确保模型可复现且可审计。

• 测试：机器学习（ML）系统需要进行广泛的测试和监控。每个 ML 系统至少应该包括以下三个测试范围：

  • 特征和数据测试，包括验证数据质量并为你的 ML 模型选择合适的特征

  • 模型开发测试，包括业务指标测试、模型老化测试和模型性能验证测试

  • ML 基础设施测试，包括 ML API 使用测试、完整的 ML 流水线集成测试以及训练和生产服务器可用性测试

• 可复现性：ML 工作流的每个阶段都应是可复现的，这意味着 ML 模型训练、数据处理和模型部署必须对相似输入得出相似的结果。这将确保构建一个健壮的 ML 系统。

• 部署：MLOps 将机器学习的原则与 DevOps 的文化相结合，强调 CI/CD 以及 持续训练/持续监控（CT/CM）。通过自动化部署和测试，MLOps 有助于尽早发现问题，从而快速修正并进行迭代学习。这种方法简化了将 ML 模型部署到生产环境的过程，确保它们保持有效并与时俱进。

• 监控：随着时间的推移，由于数据漂移等因素，模型的性能可能会在生产环境中下降。这种情况要求不断部署新的或更新的模型，以应对任何性能下降；必须持续将其推向生产环境，以应对性能下降或提升模型的公平性。在部署 ML 模型后，至关重要的是实施监控系统，以确保 ML 模型的表现符合预期，并保持其在提供准确可靠的输出方面的有效性，这对于维护 ML 应用的整体质量和可信度至关重要。

在本节中了解了 MLOps 设计原则后，让我们考虑一些最佳实践，帮助你在 ML 工作负载中应用 MLOps。

MLOps 最佳实践

由于许多动态因素（数据、模型或代码）以及通过 ML 解决业务问题的挑战，MLOps 可能是一个具有挑战性的任务。

根据上一节中概述的原则，以下是 ML 工程师/全栈数据科学家在将 ML 解决方案部署到生产环境时应遵循的最佳实践，这将有助于减少技术债务和维护开销，并从中驱动出最大的业务价值：

• 设计考虑因素：为了开发一个可维护的 ML 系统，架构/系统设计应当是模块化的，并尽可能松耦合。实现松耦合架构可以使组织内的不同团队能够独立运作。这意味着他们不必依赖其他团队提供支持或服务。结果是，每个团队可以更迅速高效地工作，从而推动整个组织的价值和生产力。

• 数据验证：数据验证对于成功的 ML 系统至关重要。在生产环境中，数据可能会带来若干挑战。其中一个问题出现在生产数据的统计特性与训练数据的统计特性不同，这表明可能存在属性、训练数据本身或数据采样过程的问题。此外，数据漂移也可能发生，这可能导致随着时间的推移，数据的统计特性在连续的批次中发生变化。这种漂移可能影响模型的表现，因为它是基于具有不同统计特征的数据进行训练的。

• 模型验证：重用模型与重用软件不同。最好根据每个新场景调整模型。确保模型在投入生产之前经过充分验证非常重要。为了确认模型在实时数据上有效运行，进行在线和离线数据验证是必要的。这一过程有助于确保模型的预测在实际操作条件下是准确且可靠的。

• 模型实验跟踪：仔细记录所有与 ML 模型相关的实验是至关重要的。ML 中的实验可能涉及尝试不同的代码组合（包括预处理、训练和评估方法）、数据集和超参数。每种独特的组合都会生成度量指标，你应当将其与其他实验的结果进行比较。这一比较是理解哪些方法最有效，并相应地优化你的 ML 模型的关键。

• 代码质量检查：每个 ML 模型规范（创建 ML 模型的 ML 训练代码）都应经过代码审查阶段。作为由拉取请求激活的管道的初始路径检查代码质量是一种良好的实践。

• 命名约定：在 ML 编码实践中遵循标准的命名约定（如 Python 编程的 PEP8）是一种有效的策略，能够帮助缓解 任何改变都会改变一切（CACE）原理带来的挑战。一致且清晰的命名约定有助于更容易理解和修改代码。这不仅有助于在进行更改时保持项目的完整性，还能帮助新团队成员快速熟悉你的项目。

• 模型预测服务性能监控：除了计算模型行为与业务目标相关的项目指标（如 均方根误差（RMSE））外，操作性指标如延迟、可扩展性和服务更新也至关重要，必须进行监控，以避免业务损失。

• CT/CM 过程：在生产环境中，由于数据漂移等因素，模型性能可能会下降。这就需要持续部署更新的模型，以增强或保持模型的公平性和准确性。为了有效管理这一过程，CT/CM 过程至关重要。CT 确保模型定期更新，并用最新数据进行训练，而 CM 则实时跟踪模型的性能，识别由于数据模式变化而可能出现的任何问题或偏差。CT 和 CM 共同构成了一个强大的框架，确保 ML 模型在生产中的长期可靠性和有效性。

• 资源利用：理解系统在训练和部署阶段的需求对于高效运作至关重要。这样的洞察帮助团队有效优化实验中使用的资源，从而实现显著的成本节省。合理的资源管理确保你为任务分配适量的计算能力、内存和其他必要的资源，避免资源的浪费或过度承诺。保持资源使用的平衡是确保机器学习项目性能与成本效益的关键。

MLOps 在 AI 产业化中发挥着至关重要的作用。MLOps 将机器学习（ML）、数据工程和 DevOps 相结合，能够有效地构建、部署和维护生产中的 ML 系统。

深度学习如今已成为解决复杂机器学习问题的首选方法。让我们进一步了解深度学习。

深度学习

机器学习（ML）是通过自然语言处理（NLP）来预测和解决复杂问题，使计算机能够以有价值和有意义的方式理解、解释和生成自然语言。NLP 被广泛应用于语言翻译、情感分析、聊天机器人和语音助手等多个领域，使得与机器的互动更加直观、类似人类。虽然机器学习需要一个预定义的标注数据集来进行监督学习，但深度学习使用神经网络进行无监督学习，模拟人脑的行为，利用大量数据发展机器学习能力。神经网络是一系列算法，通过模仿人脑的工作方式识别数据集中的潜在关系。

深度学习涉及一个多层的神经网络，在这个过程中，你无需提前进行数据标注。然而，根据你的使用场景，你可以结合标注数据和未标注数据来进行深度学习。以下图示展示了一个简单的深度学习模型：

图 13.4：深度学习层的概述

在前面的图示中，深度学习模型有相互连接的节点，其中输入层通过不同的节点提供数据输入。这些数据通过多个隐藏层进行计算，最后通过输出节点层给出最终的模型推理。输入层和输出层是可见层，学习发生在中间层，通过权重和偏差来实现，如下图所示：

图 13.5：深度学习神经网络模型

在前面的图示中，你可以看到一系列隐藏层，每一层都会对相互连接的节点应用某些权重函数，以学习模式，这与人类大脑的工作方式相同。你可以看到作为输入的标签数据，经过神经网络节点并通过它们的权重（0.2、0.4、0.3和0.9）在顶点之间传递。

权重是神经网络中的一个参数，在输入数据经过隐藏层时起着转换作用。实质上，权重决定了某一输入对输出的影响程度。它可以看作是表示网络中节点之间连接强度或密切程度的指标。

例如，如果从节点 A 到节点 B 的权重很高，意味着神经元 A 对神经元 B 的影响更大。接近零的权重表示改变这个特定的输入对输出的影响很小或没有影响。相反，如果权重为负，则表明存在反向关系——这意味着增加输入会减少输出，反之亦然。权重机制是神经网络处理和学习数据的基础。

前述的学习方法叫做前向传播，其中数据从输入层流向输出层。在这里，一个层的输出作为下一个层的输入，直到最终输出。

另一方面，还有一种技术叫做反向传播。这涉及到计算网络预测中的误差（即网络预测结果与实际结果之间的差异）。网络使用算法来计算预测误差，然后根据这个误差调整其内部参数——权重和偏差。这种调整是反向进行的，从输出层开始，逐层向后调整，这就是为什么它叫做“反向传播”。

通过前向传播和反向传播的结合使用，神经网络能够学习和改进。它处理数据（前向传播），识别预测中的任何不准确之处（反向传播），然后调整其参数以减少这些误差。这个循环是训练神经网络逐渐变得更加高效和准确的关键，使用的是训练算法。

深度学习包含不同类型的神经网络，每种神经网络适用于不同的应用。最常用的两种是：

• 卷积神经网络 (CNNs)：这些网络擅长处理具有网格状拓扑的数据，如图像，使其在涉及视觉输入的任务中非常有效，如计算机视觉和图像分类任务。

• 递归神经网络 (RNNs)：RNN 在处理序列数据方面表现出色，使其非常适合涉及语言和语音理解的任务，如自然语言处理（NLP）和语音识别。

构建这些神经网络模型的最流行框架之一是 TensorFlow，它内置支持各种神经网络架构；另一个是 MXNet，它也支持多种网络架构，并以其高效性和可扩展性而著称，特别是在高性能深度学习应用中。此外，其他流行的深度学习框架还包括 PyTorch、Chainer、Caffe2、ONNX、Keras 和 Gluon。

本节为您提供了深度学习的高层次概览。它是一个复杂的话题，需要整本书才能涵盖基础内容。每种框架都有多本书籍可供参考。深度学习模型的训练需要大量的计算资源，并且可能非常昂贵。然而，像 AWS、GCP 和 Azure 这样的公共云服务提供商通过按需付费的方式，使得使用高性能 GPU 实例训练这些模型变得更加容易。

深度学习在现实世界中的应用

深度学习广泛流行，并且在各行各业中有着多个应用案例。让我们来看看一些例子。

医疗：诊断与预后

深度学习模型通过提供第二意见，甚至有时能够发现人类可能忽略的细节，帮助医疗领域的专业人士。这些模型在庞大的医学图像数据集上进行训练，学习识别与疾病和病症相关的特征，并能预测患者患某种疾病的概率。例如，Google 的 DeepMind 开发了一种模型，能够在扫描中发现眼部疾病。通过分析患者眼睛的 3D 扫描，深度学习系统能够推荐如何将患者转诊治疗。

自动驾驶车辆：导航与安全

深度学习模型帮助自动驾驶车辆理解其周围环境、做出决策并进行导航。它们在各种驾驶场景的庞大数据集上进行训练，学习识别物体（如行人和其他车辆）、理解交通标志，并做出安全的驾驶决策（如何时刹车或转向）。深度学习本质上使这些车辆能够解释并理解它们周围的世界，从而使自动驾驶成为可能，并随着技术的进步变得越来越安全。

特斯拉、Waymo 和其他公司利用深度学习来支持其自动驾驶车辆。这些车辆配备了许多传感器，将数据输入到深度学习模型中，使其能够实时做出决策。

制造业：质量控制与预测性维护

在制造业中，深度学习模型优化操作并提升质量控制。通过分析制造过程中的数据，模型可以在生产链早期识别制造异常或产品缺陷，确保高质量产出。通用电气公司采用深度学习进行预测性设备维护，使用模型分析机器数据，以预测设备可能发生故障或需要维护的时间，从而减少停机时间。

通过从庞大且复杂的数据集中提取洞见的能力，深度学习在各种真实世界场景中得到了广泛应用，推动了创新，并优化了多个行业的运营。从医疗保健领域的诊断辅助，到制造业中的优化操作与质量控制，深度学习已成为众多行业技术进步的关键组成部分。

自然语言处理（NLP）

自然语言处理（NLP）的目标是理解、读取并有效利用人类语言。它结合了人工智能和计算语言学，使计算机能够通过口语或文本处理人类语言。让我们来看一些 NLP 的应用案例。

聊天机器人与虚拟助手

NLP 的一个常见应用是创建聊天机器人和虚拟助手，如 Siri、Alexa 或各大网站上的客服聊天机器人。

聊天机器人与用户进行互动对话，通常帮助用户查找信息、回答问题或促进交易。它们利用 NLP 技术理解用户输入（问题或命令）并生成相关回应。通过分析文本，NLP 模型能够辨识用户消息背后的意图并作出相应回应。这种应用在零售、银行和客户服务等行业被广泛应用，以提升用户体验并及时回应顾客询问。

情感分析

企业使用情感分析，也称为意见挖掘，通过分析顾客的书面或口头语言，如顾客评价和社交媒体评论，来评估顾客对品牌、产品或服务的情感态度。

情感分析模型，利用自然语言处理（NLP）技术，分析文本数据以确定其中的情感基调，将情感分类为正面、负面或中立。例如，一家公司可以分析产品评价，以识别顾客是否普遍满意或不满意。这些信息对于企业理解顾客的认知并相应地调整其产品或服务至关重要。现代的联络中心解决方案，如 Amazon Connect，通过整合实时分析顾客对话，彻底改变了客户服务。这些系统可以分析语音互动，以确定顾客的情感，从而在通话中帮助客户支持代表，推动客户参与。

文本摘要

自动摘要工具利用 NLP 有效理解和浓缩内容，从而生成简洁的摘要，适用于冗长的文档或文章。

文本摘要涉及在不丢失关键信息的情况下减少文本内容，并以简洁的形式呈现。NLP 模型从文档中提取关键信息和要点，提供一个保留核心信息的摘要版本。这在法律或研究等领域尤为有用，专业人士必须高效地审查大量文档并提取相关信息。

机器翻译

Google Translate 可以将文本翻译成不同语言，极度依赖 NLP 来准确理解和翻译文本。

机器翻译模型利用 NLP 理解源语言中的文本及其上下文，并生成目标语言中的等效文本。NLP 确保翻译遵循语法和句法规则，并保持原始信息的意义和上下文。这具有全球性影响，打破了语言障碍，促进了国际间的沟通和信息交流。

通过让机器理解和处理人类语言，NLP 开启了许多应用，增强了沟通、提供了洞察力，并简化了多个领域的流程，包括客户服务、市场营销和全球沟通。

大语言模型（LLMs），如生成预训练变换器（GPT）模型，已成为 NLP 中的变革性工具，在各种 NLP 任务中展示了令人印象深刻的能力。这些模型旨在理解、生成并处理类人文本，使它们能够参与文本补全、摘要和翻译等活动。在下一章，你将了解更多关于各种 LLMs 的信息。

总的来说，ML 和 AI 是广泛的主题，值得写多本书才能更深入地理解。在本章中，你只了解了 ML 模型、类型和工作流程的概述。

总结

在这一全面的章节中，你深入了解了 ML 的基本概念和实际应用。你从理解 ML 的核心原则以及它与数据科学的紧密关系开始，强调了数据在训练和评估 ML 模型中的关键作用。你探讨了不同类型的 ML，从监督学习和无监督学习到强化学习和深度学习。每种类型都通过实际案例和常见算法进行了说明，使你能够理解何时以及如何应用它们。

接下来，你深入探讨了模型过拟合和欠拟合的关键概念，探索了实现模型泛化所需的微妙平衡。你还研究了应对这些挑战的各种策略和技术。

本章介绍了流行的人工智能工具和框架，还深入探讨了基于云的机器学习（ML），展示了利用云平台进行机器学习项目的优势和能力。详细阐述了数据在机器学习中的作用，重点讲解了特征工程和选择，以及构建、训练、调优、部署和管理机器学习模型的精细过程。我们讨论了机器学习架构的设计原则，并提供了构建可扩展且高效的机器学习系统的最佳实践。

机器学习运维（MLOps）被探讨作为机器学习项目开发的关键组成部分，提供了一个结构化框架，用于设计和实施稳健的机器学习系统。

深度学习成为核心话题，揭示了它对各行各业的深远影响，从图像识别到自然语言处理。我们解析了深度学习模型的架构，并探索了其在实际应用中的使用。

本章的高潮部分是探索自然语言处理（NLP）和大型语言模型（LLMs），展示了这些模型如何改变沟通、翻译和内容生成。进一步而言，生成型人工智能（GenAI）是下一个发展阶段的关键技术。在下一章中，您将学习关于生成型人工智能架构、各种基础模型（FMs）以及可用产品的知识，帮助您在生成型人工智能领域获得专业知识。

加入我们书籍的 Discord 空间

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

第十四章：生成性 AI 架构

生成性 AI 技术不仅仅是行业术语——它是一种先进的工具，用于通过自动化关键任务（如内容生成、图像创建和知识辅助）来重塑商业运营。生成性 AI 代表了技术世界的重大飞跃，激发了那些热衷于技术创新的人的极大热情。生成性人工智能（GenAI）作为这一技术的缩写，其显著特点在于能够独立地生成新内容，如文本、图像、音乐、视频、代码等，其能力与人类创造力十分相似。

生成性 AI 在不同的商业领域中的使用正在增加。若使用得当，它可以大大减少运营业务所需的时间、资源和成本。例如，ChatGPT 可以协助创建产品的营销活动或充当旅行规划师，而 Midjourney 可以在一秒钟内生成图像。

你可能已经接触过一些生成性 AI 应用，如 ChatGPT、Midjourney、Gemini（前身为 Bard）、Amazon Q 和 Claude.ai 等。这项技术从大量收集的信息中学习，包括互联网信息，并利用这些知识创造新内容。就像拥有一个智能助手，能够在无需每个细节都由人类输入的情况下生成各种内容。然而，必须理解，这不是魔法——它是经过大量聪明思维和技术领域进步的结果。

但最令人兴奋的部分是，我们可以通过多种方式使用这些基础模型。例如，它们可以用于生成创意内容、通过聊天机器人自动化客户服务、增强数据分析、提供个性化推荐、简化语言翻译，甚至通过总结复杂文档来帮助研究。在本章中，你将更详细地了解生成性 AI，包括：

什么是生成性 AI？

• 生成性 AI 使用案例

• 生成性 AI 系统的基本架构

• 流行的生成性 AI 基础模型

• 如何开始使用生成性 AI

• 生成性 AI 参考架构

• 实施生成性 AI 的挑战

准备好踏上激动人心的生成性 AI 世界之旅吧。我们将揭开它在影响新世界发展方向方面的非凡能力背后的奥秘。

什么是生成性 AI？

生成性 AI 是一种人工智能，具有非凡的能力，能够开发新内容和创意。这包括进行对话、创作故事、制作图像和视频，甚至创作音乐等。

2022 年 12 月，位于香港的人工智能设计实验室（AiDLab）的设计团队策划了一场突破性的时尚展览——Fashion X AI（www.fashionxai.com/event-highlights-fashionshow）。这场展示的独特之处在于，展会中展示的每一件设计作品都是由人工智能创造的，灵感来自人类设计师提供的情感板、色彩调色板和概念。

像其他类型的人工智能一样，生成性人工智能依赖于机器学习（ML）模型。这些模型通常非常庞大，并且通过大量数据进行预训练。我们通常将这些模型称为基础模型（FMs）。

我们现在拥有的 FMs（例如用于大型语言任务的 OpenAI GPT-4 或 Google Gemini，来自 Stability AI 的用于将文本转换为图像的 Stable Diffusion，以及 OpenAI 的 Sora 文本到视频生成器）可以执行多个领域中的各种任务。它们可以撰写博客文章、生成图像、解答数学问题、进行对话，甚至根据文档中的信息回答问题。这些模型非常多功能，并有可能彻底改变我们创建和互动内容的方式。

生成性人工智能有潜力对全球经济带来深远的变化。根据高盛的报告，生成性人工智能可能推动全球 GDP 增长 7%（或近 7 万亿美元），并在 10 年内提升生产力增长 1.5%。你可以在高盛的人工智能（AI）报告中了解更多详细信息，链接：www.goldmansachs.com/intelligence/artificial-intelligence/。

FMs 因其规模和通用性而独树一帜，与传统的机器学习模型不同，后者通常是针对情感分析、图像分类和趋势预测等特定任务设计的。与这些传统模型不同，FMs 不需要为每个任务收集标注数据、训练和部署，而是提供了更为多样化的处理方式。一个经过预训练的 FM 可以适应多种任务。此外，这些模型还可以针对特定领域的功能进行定制，以适应各个企业的独特需求。重要的是，这种定制化可以仅使用一小部分数据，并结合所需的计算资源，而无需从头开始训练一个全新的模型。

FMs 的成功可以归因于三个关键原因：

• 变压器架构：变压器架构是一种神经网络，发挥着至关重要的作用。它高效、可扩展且可并行化，能够有效地建模输入和输出数据之间的关系。

• 上下文学习：一种突破性的训练范式——上下文学习已经出现。这种方法允许预训练模型通过指令或少量示例来处理新任务。这消除了对标注数据额外训练的需求，使得模型能够立即应用于新任务。

• 大规模的新兴行为：随着模型规模的增大和使用更大的数据集，模型开始展现出以前未见的能力。这一现象被称为“新兴能力”。例如，更大的模型能够生成更连贯、与上下文更相关的文本，识别数据中的复杂模式，甚至执行图像识别和语言翻译等任务，且准确性更高。它们还能够处理多步骤推理问题，提供详细的解释，甚至生成创意内容，如作曲或创作艺术作品，展现出细腻的理解和创造力。更大的模型在达到临界规模之前，具有执行超出其能力范围的任务的潜力。

为了更好地理解，让我们来看一些生成式人工智能可以帮助的使用案例。

生成式人工智能使用案例

让我们来看一下不同类别的各种使用案例，如客户体验、员工生产力和业务运营效率，并了解生成式人工智能如何增强现有的人工智能能力，并带来全新的可能性：

客户体验转型

生成式人工智能正在改变客户与企业互动的方式。假设你在网上购买鞋子。一个基于生成式人工智能的虚拟助手会在网站上迎接你，并根据你的风格和尺码偏好帮助你找到完美的鞋子。它甚至可以展示鞋子的图片，并回答你任何问题。让我们来看一些更多这样的使用案例，看看生成式人工智能如何帮助提升客户体验和互动：

• 聊天机器人和虚拟助手：想象一下，你访问一个网站时，聊天机器人弹出来帮助你。生成式人工智能为这些聊天机器人提供支持。它们可以像人类一样与您对话，理解您的问题，并提供有帮助的答案。

• 智能联络中心：当你拨打客户服务热线时，生成式人工智能在发挥作用。它确保你的互动更加个性化、高效和令人满意。你的问题会迅速且准确地得到解决。

• 个性化：你是否注意到像 Netflix 和 Amazon 这样的平台推荐能够理解你的偏好？这就是生成式人工智能的作用。它通过学习你的行为，并根据你的口味调整其推荐内容。

• 内容审核：生成式人工智能帮助社交媒体和其他平台保持清洁和安全。它扫描用户生成的内容，如评论和帖子，确保它们遵守规则和指导方针。

员工生产力提升

生成式人工智能不仅仅适用于客户，它还提升了员工的生产力。想象一下，你正在处理一个项目，并且需要撰写关于它的报告。与其从头开始，你可以利用生成式人工智能帮助你撰写介绍和关键点。这让你提前了解情况，可以集中精力添加自己的见解和专业知识。以下是一些生成式人工智能帮助提升员工生产力的用例：

• 对话式搜索：当你需要信息时，可能会使用搜索系统。生成式人工智能使这些系统更加智能。你可以用日常语言提问，AI 会理解并给出正确的答案。

• 内容创作：撰写报告和文章可能需要大量时间。生成式人工智能在这方面也大有帮助。它可以生成内容部分，如摘要或解释，帮助你创建精炼的文档。

• 文本摘要：想象一下你正在阅读一篇长篇研究论文。与其浏览所有页面，生成式人工智能可以总结主要观点。这样可以节省时间，并帮助你更快地掌握基本信息。

• 代码生成：对于程序员来说，编写代码是工作的重要组成部分。生成式人工智能可以根据你想要实现的目标建议代码片段。这加快了编码任务，使开发过程更加顺畅。

将生成式人工智能整合到企业场景中时，重要的是要处理其生成内容周围的法律考虑。你需要理解内容的来源，建立清晰的所有权是防止知识产权纠纷的关键。采用这种方法可以帮助企业避免法律问题，同时确保生成的内容符合组织的特定需求并保持其独特价值。

优化业务运营

生成式人工智能不仅局限于客户互动，它还增强了各种运营方面。在制造厂中，机器通过传感器进行监控。生成式人工智能分析这些传感器的数据，并预测机器可能出现问题的时间。这使得维护可以主动安排，预防意外故障和生产中断。以下是一些生成式人工智能帮助改善业务运营的用例：

• 智能文档处理：在企业中，有许多文件需要处理。生成式人工智能可以自动读取和理解这些文件，提取有意义的信息。这节省时间并减少错误。例如，生成式人工智能模型可以处理抵押贷款文件，并回答关于抵押利率、付款条件、期限等的问题。

• 预测性维护：对于使用机器的公司来说，预测设备何时需要维护至关重要。生成型 AI 分析来自机器和系统的数据，以预测维护需求，防止故障发生并最小化停机时间。

• 质量控制与视觉检查：确保产品符合高标准是制造业中的重要环节。生成型 AI 可以检查产品的图像，识别出人眼可能忽略的缺陷或不一致之处。

• 数据增强：训练 AI 模型需要大量的数据。生成型 AI 通过创建合成数据来帮助提高这些模型的准确性和可靠性。

在这一部分，你了解了生成型 AI 的应用场景。现在，让我们通过了解生成型 AI 的架构，来探究背后的原理。

生成型 AI 系统的基本架构

生成型 AI 系统的核心是一种大规模的 FM。FM 是经过大规模数据集预训练的大型模型，可以针对各种任务和应用进行微调或适配。为了理解生成型 AI 系统的架构，让我们将其拆解为简单的组成部分：

• 生成器：生成新数据的核心元素，无论是图像、文本、音乐还是其他形式的内容。生成器从现有数据中学习模式和关系，并利用这些知识生成新的、相似的内容。例如，生成器在图像生成中接受随机噪声，然后生成类似训练数据的图像。

• 潜在空间：一个概念空间，在这个空间中，模型以压缩形式表示数据。这就像是生成器用来创造新内容的数据的紧凑表示。它是一个低维向量空间，生成器从中生成数据。这就像是艺术家使用的秘密食谱本。它帮助生成器创作出不同类型的作品。例如，在文本生成中，潜在空间可以代表不同的写作风格；在图像合成中，潜在空间可能代表颜色和纹理等不同特征。

• 损失函数：衡量生成内容与期望输出之间匹配程度的指标。损失函数通过最小化生成数据与真实数据之间的差异，帮助模型随着时间推移不断学习和改进。可以想象，一位教练在告诉艺术家他们的作品与完美之间的差距。艺术家通过遵循这个指导，不断学习并提高。

• 训练数据：模型学习的现有数据。它可以是图像、文本、音频或任何其他类型的内容，模型从中学习。就像厨师通过品尝不同的食物来学习一样，生成器通过示例学习应该创造什么。例如，如果生成器正在创作歌曲，它就会通过聆听现有的歌曲来学习。

生成模型的类型

在了解生成模型之前，我们先了解它们与典型的机器学习判别模型有何不同。典型的机器学习判别模型，也称为判别模型，旨在区分不同类别或种类的数据。与目标是生成新数据点的生成模型不同，判别模型的重点是根据数据的特征区分现有数据点。这些模型基于输入数据预测某个结果的概率。常见的判别性机器学习模型包括逻辑回归、支持向量机等。你在第十三章《机器学习架构》中详细学习了这个概念。

生成模型与判别模型有所不同，后者专门用于根据预定义的分组对文本进行分类或标注。判别模型通常应用于面部识别等任务，在这些任务中，模型的训练重点是识别一个人面部的特定特征或属性。

图 14.1：生成模型与判别模型

如前面的图示所示，生成模型试图理解数据中的模式和结构。就像它们在学习游戏的潜规则，然后用这些规则创造出一个看起来像原始游戏的新事物。而判别模型则侧重于区分不同的事物。它们就像是侦探，训练用来识别事物之间的差异。判别模型通常用于监督学习任务，其中目标是分类或回归，而生成模型则用于理解数据分布或生成新数据点。

生成性人工智能涵盖了各种创建新内容的模型。我们将在接下来的子章节中讨论一些重要的类型。

生成对抗网络（GAN）

GAN 由两个组件组成：生成器和判别器。生成器的角色是生成内容，而判别器的任务是判断该内容的真实性，确定其是“真”还是“假”。它们进行一种“竞争”，生成器的目标是创造出足够有说服力的内容以欺骗判别器。随着这个过程的进行，生成器会逐渐提高其创造出看起来越来越逼真的内容的能力。下面的图示展示了 GAN 模型的工作原理：

图 14.2：GAN 的训练流程

上面的图示表示了生成对抗网络（GAN）的基本结构。我们以图像创作为例，逐步了解每个步骤：

• 生成器：GAN 的这个组件接收随机噪声作为输入。这种噪声通常被称为“潜在随机变量”。生成器的作用是生成与它所接受的真实数据相似的数据。可以把它想象成一个正在学习的艺术家，最初根据一些基本的艺术模式创作随机草图。例如，生成器开始通过创建随机图像，试图让它们看起来像著名的画作。

• 真实数据样本：这些是 GAN 设计来模仿的真实数据实例。它们作为生成器创建的数据质量的基准。在我们的例子中，这些是真正的历史名画，是生成器尝试模仿的艺术杰作。例如，像梵高或毕加索这样的艺术家的真实画作被输入到 GAN 中，作为“真实”艺术作品的例子。

• 生成的虚假样本：生成器使用输入的噪声生成新的数据样本。这些样本旨在与真实数据样本难以区分，尽管它们完全是由模型生成的。这些是生成器创建的新图像，试图复制真实艺术作品的质量和风格。例如，生成器生成的图像模仿梵高或毕加索作品的笔触和色调。

• 判别器：这个组件接收来自真实数据样本和生成器生成的虚假数据样本。它的工作是区分这两者，决定它收到的每个样本是现实的还是伪造的。可以把它看作一个艺术评论家，检查真实的艺术杰作和生成的图像，以判断新的图像是原作还是仿制品。例如，判别器审查这些图像，试图确定哪些是梵高或毕加索的真实画作，哪些是模仿品。

• 条件：判别器对数据是否真实或虚假做出判断，并将此信息作为反馈提供给生成器。艺术评论家（判别器）评估生成的图像并给予反馈，例如指出哪些方面让图像看起来像假的。例如，判别器注意到生成图像中的色调与原艺术家的风格不完全匹配，并将其标记为伪造。

• 微调训练：根据判别器的评估，生成器调整其参数，努力生成更有可能骗过判别器的更好的假样本。这个反馈回路继续进行，判别器也在不断提高自己辨别真实与虚假的能力。这个对抗过程持续进行，直到生成器能够熟练地生成逼真的数据。根据反馈，正在训练中的艺术家（生成器）从批评中学习，并改进技巧，以创作出更具说服力的艺术作品。例如，考虑到反馈，生成器调整技巧，可能改变颜色搭配或画笔风格，更好地模仿大师级作品。

生成器和判别器本质上处于一个持续的博弈中，生成器试图生成越来越逼真的数据，而判别器努力提高自己区分真实数据和虚假数据的能力。 “训练”完成的标志是判别器无法可靠地区分真假数据，这意味着生成器的输出足够逼真。

GAN（生成对抗网络）在各个商业领域有许多实际应用，许多流行工具都利用了这一模型。

变分自编码器（VAE）

想象一下，你有一堆各种形状和大小的乐高积木，你的任务是把它们整齐地存放在一个小盒子里。但有一个限制：你只能存放关于如何重建原始乐高结构的说明，而不能存放这些积木本身。这就类似于 VAE 处理数据的方式。

在这个类比中，“编码器”就像你将每个乐高结构拆解，找出用更少积木重新构建它的最佳方法，然后将这些说明写下来。你放置这些说明的盒子里的空间，就像是“潜在空间”——原始结构的压缩版本。

后来，当你想重建一个乐高结构时，你会查看盒子里的说明书。“解码器”就像你按照那些说明书，用一套新的积木来建造一个与原始结构非常相似的新乐高结构。

因此，VAE 将大型复杂的数据（原始乐高结构）压缩成一个更简单、更小的形式（盒子里的说明），然后利用这个压缩后的形式生成类似原始数据的新数据（重建乐高结构）。这个过程在技术领域非常有用，适用于创建新图像、音乐或任何模仿原始数据风格的数字内容。如下图所示，一个手写图像通过 VAE 进行编码和解码：

图 14.3：使用 VAE 进行图像重建的流程

上面的图示描述了使用变分自编码器（VAE）进行图像重建的流程。以下是 VAE 如何通常在这个任务中工作的解释，举一个重建人脸的例子：

• 输入图像：这些是你输入到 VAE 系统中的原始图像。目标是能够在编码和解码之后重建这些图像。假设我们有一组面部照片。每张图像都是一个清晰的高分辨率人脸照片。

• 编码器：VAE 的编码器部分接收输入图像，并将其压缩成一个更小、更紧凑的表示，称为潜在空间或图像编码。这个过程涉及学习输入图像中的基本特征和模式。编码器分析输入的照片，将每张图像压缩成一个包含面部关键特征的数字集，如眼睛、鼻子和嘴巴的形状。可以将其想象为创建一个独特的编码，能够代表一个面孔，而占用的空间远小于原始图片。

• 图像编码：在这一阶段，编码器已将输入图像转换为一组编码，这些编码代表图像的关键特征，相比原始图像，维度大大缩小。在变分自编码器（VAE）的背景下，这些编码还捕捉了输入数据的概率分布。这些数字集（编码）是照片的精髓，以紧凑的形式存储，可以看作是图像的详细特征。在面部的情况下，这些特征可能捕捉到不同个体之间面部特征的变化。

• 解码器：解码器接收这些编码，并尝试重建原始图像。它使用压缩数据生成尽可能接近原始输入图像的图像。解码器的作用就像一位艺术家，任务是绘制一个人的面部。它接收这些数字编码，并利用它们重建面部的照片。它尝试仅凭这些紧凑的编码尽可能准确地绘制每一张面孔。

• 重建图像：VAE 的最终输出。这些是由解码器从图像编码中重建的图像。这些图像的质量取决于 VAE 压缩和重建数据的能力。结果是一系列由 VAE 生成的新面部照片。这些重建的图像应该与原始输入照片非常相似。如果将它们与原始图像并排比较，你会发现它们很相似，尽管由于压缩过程中的细节损失，它们可能略显模糊或有轻微的差异。

本质上，流程描述了 VAE 学习高效数据表示的能力，并生成与原始输入相似的新数据。这个过程广泛应用于各种场景，包括图像去噪、图像修复，并作为生成模型创建与训练数据集具有相似特征的新图像。

基于 Transformer 的生成模型

这些模型，如 GPT-4，基于变压器架构构建，擅长理解和生成文本序列等数据。它们学习语言和上下文中的模式，使其能够生成连贯和上下文相关的文本。以下图显示了模型中变压器的工作方式：

图 14.4：基于变压器的生成模型组件

上图显示了变压器模型的工作流程，这是一种用于自然语言处理（NLP）任务，如翻译、文本生成等的先进神经网络类型。让我们通过语言翻译的示例来看每个步骤：

• 输入嵌入层：过程始于输入嵌入层，其中单个元素（如句子中的单词）被转换为模型可以处理的数值向量。例如，句子“How are you?”输入模型，每个单词转换为数值向量。这就像给每个单词分配一个唯一的可识别的徽章编号，以便模型可以理解和处理它们。

• 位置编码：将这些向量添加到位置编码中，以向模型提供有关句子中每个单词位置的信息，因为变压器本身并不理解单词的顺序。例如，除了徽章编号外，每个单词还分配了一个位置标签。“How”标记为第一个单词，“are”标记为第二个，“you”标记为第三个。这帮助模型考虑单词的顺序。

• 编码器：将组合的嵌入（输入嵌入加上位置编码）输入编码器。编码器处理输入数据，捕获每个单词相对于序列中其他单词的上下文。就像编码器阅读句子并理解每个单词在整个句子上下文中的含义。编码器通过它们的徽章编号和位置标签来理解句子的含义。例如，它注意到第一个位置的“How”通常用于开头问句。

• 多头自注意机制：在编码器内部，多头自注意机制允许模型以不同方式权衡输入的影响。就像模型通过观察周围的其他单词考虑单词含义的不同方面。编码器特别关注句子中每个单词如何与其他单词相关联。例如，它注意到“How”与“you”相连形成一个有礼貌的询问关于某人的健康状况。

• 前馈神经网络：接下来，处理后的信息通过前馈神经网络传递，这些网络在每一层顺序处理数据，以精炼和抽象表达。这些网络从注意机制中细化信息，几乎像一组编辑人员在修改草稿以更好地传达句子意图。

• 归一化和残差连接：在此过程中，应用归一化和残差连接，以帮助保持数据流并减少在网络深层中的数据变换错误的风险。这些元素确保通过模型流动的信息既不被削弱也不被放大。为了防止错误在网络层中扩展，这些组件像是检查点，确保数据沿着正确的轨迹前进。

• 解码器：在编码器处理完输入后，解码器使用这些信息来生成输出。它接收来自编码器的处理数据，并开始生成转换后的序列，如将句子翻译成另一种语言或在对话中生成回应。解码器从编码器接收处理过的信息，并开始生成输出。如果正在进行翻译，它会开始生成翻译后的句子。

• 输出层：解码器的最终输出会发送到输出层，输出层将高级神经网络的输出转回可读格式，如人类语言的句子。此时，最终的输出开始形成。如果模型正在翻译句子，这一层将根据所有处理过的信息开始构建翻译。

Transformer 模型读取并理解输入数据（如句子、段落等），处理这些数据以理解上下文，并根据这些理解生成相关的输出。对于“你好吗？”，模型的编码器部分处理问题，而解码器则根据编码器提供的信息以及已生成的内容，一次生成一个单词的回答或翻译。

可以把编码器看作是负责查看输入信息的部分，而解码器则是负责生成输出的部分。例如，GPT-4 就是基于 Transformer 模型的。当你给它一个起始点时，它可以生成符合上下文且有意义的文本。

该模型使用“自注意力”来确定起始点中的哪些单词是重要的，以及它们之间是如何连接的。通过这种方式，模型能够真正理解你的需求并给出合适的回答。

其他重要的生成模型

除了前面提到的类型外，还有其他值得注意的生成模型：

• PixelCNN 和 PixelRNN：这些模型像素逐个生成图像，捕捉图像中的细节和相互依赖关系。可以想象你在逐个像素地绘制一幅画，确保每个像素都与周围的像素相协调。

• 基于流的模型：这些模型学习如何将一种数据分布转换为另一种数据分布，使其能够生成与目标分布匹配的样本。这就像是根据具体的步骤，用简单的原料制作一道精美的菜肴。

这些生成模型具有优势和应用，使其适用于从图像生成到文本创作的广泛任务。它们的多样化能力为生成式 AI 的丰富领域做出了贡献。

超参数调优和正则化在架构中的重要性

超参数调优和正则化是生成式 AI 架构的微调和安全措施。例如，在图像生成中，您可能会调整诸如学习率等超参数，学习率决定了模型学习的速度；如果学习率过高，模型可能会学习到错误的模式，就像有人在钢琴上弹奏一首曲子时按键力度过大或过小。正则化可能涉及像 dropout 这样的技术，在训练过程中随机忽略模型的一些神经元，以使模型更强健，就像训练一支足球队时让一些球员休息，这样球队就不会过于依赖某一个球员。它们在使这些系统良好运作并生成高质量内容方面起着至关重要的作用。让我们理解它们的重要性。

超参数调优

可以把超参数看作是控制生成式 AI 系统学习和创造方式的旋钮和开关。它们会影响学习速度、输出的细节程度，以及创造力与准确性之间的平衡。

想象一下，您正在寻找烘焙蛋糕的最佳烤箱温度。温度太高会烧焦；温度太低则会保持黏糊糊的状态。超参数调优类似于此。它有助于调整参数，以便 AI 系统以最佳方式学习，创造出恰到好处的内容。

例如，超参数可能控制音乐生成系统中旋律的长度、节奏或所用的乐器。调整这些超参数可以确保音乐听起来和谐，并且与期望的风格相匹配。

正则化

正则化就像给走钢丝的人加上安全网。它防止 AI 系统过于放纵，生成过于夸张或不真实的内容。它是一种控制输出并确保其行为得当的方式。

在生成式 AI 系统中，正则化有助于防止过拟合。过拟合是指系统在模拟训练数据时过于优秀，但在处理新的、未见过的数据时表现不佳。正则化技术通过模拟对学习过程中的某些部分施加轻微惩罚，帮助系统更好地泛化，创造出更具多样性和创意的内容。

例如，在图像生成系统中，正则化可以确保生成的图像具有一致的颜色和形状，防止它们看起来过于嘈杂或奇怪。

超参数调优和正则化很重要，因为它们微调生成式 AI 系统的性能，确保其生成高质量、一致且真实的内容。如果没有它们，系统可能会创造出过于单调的内容，或是过于混乱且毫无意义的内容。

就像厨师调整烹饪时间并加入合适的调味料来制作完美的菜肴一样，超参数调整和正则化会微调生成性人工智能系统，创造出既富有创意又符合预期输出的内容。它们确保系统始终保持正确的轨道，创作出令人兴奋且可靠的内容。

流行的生成性人工智能基础模型

生成性人工智能领域正在迅速发展，各种组织推动技术边界，并推出强大的基础模型以促进创新。像 ChatGPT 这样的模型的发布无疑加速了这一趋势。无论是已有的科技巨头，还是新兴的初创公司，都在积极参与生成性人工智能的浪潮，旨在开发更复杂、更强大的基础模型。以下是一些在生成性人工智能中最受欢迎的基础模型：

• Amazon：亚马逊网络服务（AWS）是全球顶级的云服务提供商之一，并在机器学习和生成性人工智能领域提供大量产品。AWS 推出了一项生成性人工智能服务，名为 AWS Bedrock，用户可以通过 API 以无服务器的方式访问流行的基础模型。Amazon SageMaker JumpStart 是另一项服务，提供访问各种基础模型的功能，并可以根据需要对其进行调优。Amazon Titan 是 AWS 的旗舰生成性人工智能模型。亚马逊的 Titan 套件包括一系列适用于各种生成任务的基础模型，其中包括：

  • Titan 文本嵌入：用于上下文文本表示

  • Titan 多模态嵌入：用于解读文本和图像之间的数据

  • Titan 文本精简版：用于资源受限环境中的高效文本处理

  • Titan 文本极速版：用于快速文本处理任务

  • Titan 图像生成器：用于根据文本输入创建或修改视觉内容

你可以通过访问亚马逊床岩（Amazon Bedrock）页面来了解亚马逊标题模型，并关注未来的相关发展：aws.amazon.com/bedrock/titan/。

• OpenAI：OpenAI 是一个致力于创建和推广开放且符合道德标准的人工智能的研究机构。它已经创建了多个生成性人工智能模型，包括：

  • DistilGPT2：高效的文本生成模型

  • GPT-3：多功能文本生成与问答模型

  • GPT NeoXT：用于多样语言任务的先进模型

  • GPT-3.5：高效地生成更长、更连贯的文本

  • GPT-4：具有类人表现的多模态模型

  • CLIP：学习文本与图像之间的关系

  • CLIP 引导扩散：根据文本提示创建对齐的图像

  • DALL·E：根据自然语言提示生成图像

  • MuZero：通过自我对弈学习玩游戏

  • 文本转语音（TTS）：将文本转化为自然听起来的语音

  • Whisper：音频转文本的转录模型

  • 嵌入：将文本转换为数值数据

  • 内容审核：评估文本中的敏感内容

  • Sora：根据书面提示生成视频

OpenAI 正在开发 GPT-5，这是他们最新且最先进的训练模型。要了解更多关于 OpenAI 模型的信息，您可以访问他们的官方网站：openai.com/。OpenAI 在其平台上提供了关于模型、研究、出版物和 API 访问的详细信息。

• Google：Google 是 AI 和机器学习的先驱。它已经开发出多个生成型 AI 模型，如：

  • Google Gemini：用于语言翻译、内容创作和查询回答的大型语言模型

  • BERT：一种提高语言处理中的上下文理解的模型

  • BigGAN：生成高分辨率、逼真的图像，用于视觉内容创作

  • Text-to-Text Transfer Transformer (T5)：自动化生成各种 NLP 任务的内容

  • Flan T-5 模型：针对特定语言处理任务，包括文本和代码进行定制

  • Pathway Language Model (PaLM)：其中之一最大的语言模型，在文本生成和翻译方面表现出色

  • LaMDA：为对话应用设计，模拟人类对话

  • Falcon-7B 和 Falcon-40B：专为语言翻译、问答和文本生成设计的模型

  • Chinchilla by DeepMind：一个专注于文本生成和语言翻译任务的大型语言模型

Google 目前专注于 Gemini，并正在构建一个更先进的版本，扩展到订阅模型。您可以通过访问 Google AI 网站(ai.google/)或 DeepMind 网站(deepmind.com/)，了解更多关于 Google 的 AI 模型和研究。

• Anthropic：Anthropic 是一个研究机构，致力于创建能够与人类价值观和偏好对齐的通用和可扩展 AI。它已获得来自多家大型科技公司，包括 Amazon（投资 50 亿美元）和 Google（投资 20 亿美元）的重大投资。它已开发出一个名为 Claude 的生成型 AI 模型系列，包括以下模型：

  • Claude：一个提供先进语言理解和生成能力的 FM

  • Claude 2：Claude 的增强版本，具有改进的语言处理能力和上下文理解

  • Claude 2.1：进一步优化的版本，提供更细腻的语言生成和理解能力

  • Claude Instant：为速度而设计，提供快速响应，同时保持有效的语言理解

  • Claude 3：最新的模型系列，设定了各类认知任务的新行业基准，并且提供三种变体——Haiku、Sonnet 和 Opus。

Anthropic 通过不同平台提供这些模型，例如 Amazon Bedrock 和 Google Vertex AI，以及他们自己的 Claude AI 网页聊天界面。 要了解最最新、最全面的模型列表，请直接访问 Anthropic 的官方网站：www.anthropic.com/claude。

• Meta (Facebook) AI：Meta AI 是一个研究组织，开发并应用 AI 技术用于与社交媒体、通讯、内容创作等相关的各种产品和服务。它开发了多个生成式 AI 模型，如：

  • RoBERTa：一种增强版的 BERT 模型，通过更广泛的训练和微调实现了更好的性能

  • DETR：通过将卷积神经网络与 Transformer 架构结合，简化了图像中的目标检测

  • Llama：一系列旨在理解和生成类人文本的语言模型，提供不同大小的版本以满足不同的计算和应用需求

  • BlenderBot：一种对话 AI，可以进行有意义且连贯的互动，模拟类人对话

  • Faiss：一个用于高效相似度搜索和聚类的库，特别适合处理大规模数据集和复杂的相似性任务

你可以访问 Meta 的官方网站，了解其在生成式 AI 领域的最新发展：ai.meta.com/。

• Microsoft：Microsoft 广泛使用 OpenAI 的产品，并进行了 100 亿美元的投资，同时提供OpenAI 模型即服务（MaaS）。然而，它也开发了生成式 AI 模型，如Turing-NLG和MPT-7B。在 Microsoft 的 MaaS 模型下，它提供 OpenAI 模型，如 GPT4、GPT3.5、DALL-E 和 Whisper。你可以访问他们的生成式 AI 产品页面，在这里了解 Microsoft Azure 模型目录：azure.microsoft.com/en-us/products/machine-learning/generative-ai。

• AI21 Labs：AI21 Labs 是一个专注于自然语言理解和生成的研究组织。它创建了多个生成式 AI 模型，如潜在逻辑深度扩展（DELL）、Jurassic-1和Jurassic-2。它推出了 AI21 Studio 来普及其模型的使用，并与 Amazon 合作通过 Amazon Bedrock 提供这些模型。你可以在这里访问 AI21 的官方博客，了解最新的产品：www.ai21.com/blog。

• Nvidia：Nvidia 专注于图形处理单元（GPU）、游戏、云计算、AI 等领域。它开发了多个生成式 AI 模型，例如 StyleGAN2 和GANVerse3D。你可以在这里了解更多关于 Nvidia 模型的信息：www.nvidia.com/en-us/ai-data-science/generative-ai/。

• Jasper.ai：Jasper.ai 是一家为市场营销人员提供生成式 AI 解决方案的科技公司。它开发了一个名为 Jasper 的生成式 AI 模型，并推出了 Jasper AI Copilot 以扩展其产品。你可以在这里了解更多关于 Jasper 的信息：www.jasper.ai/。

• Hugging Face：Hugging Face 是一家提供开源工具和平台的科技公司，专注于自然语言处理（NLP）。它创造了多个生成式 AI 模型，如Bloom 模型、BloomZ 176B、Lyra-Fr 10B和Lyra-Mini。想要了解更多关于 Hugging Face 及其生成式 AI 模型的内容，可以访问其官方网站并探索 Model Hub，在那里可以获取详细信息并访问其模型。以下是帮助你入门的链接：huggingface.co/docs/hub/en/models-the-hub。

上述列表并不完整，但涵盖了一些最流行的模型。生成式 AI 中的 FM（功能模型）正在经历巨大的发展。随着这一领域的研究不断深入，我们可以期待未来会开发出更强大、更通用的模型。

如何开始使用生成式 AI

开始使用生成式 AI 需要选择适合自己需求的工具和平台。无论你是希望参与 AI 生成对话的终端用户，还是作为开发者/机器学习科学家想要创建复杂应用程序，许多不同提供商的资源都可以帮助你踏上生成式 AI 的旅程。开始使用生成式 AI 是令人兴奋的！以下小节将介绍不同类型的用户如何开始探索生成式 AI。

面向终端用户

对于希望在日常活动中利用生成式 AI 的个人，如内容创作、营销材料、电子邮件撰写和高效学习，可以使用几种易于访问的工具：

• ChatGPT提供了一个由 GPT-3.5 驱动的用户友好型聊天机器人体验。该工具根据接收到的输入以自然语言进行响应，从而使各种话题的互动对话成为可能。在撰写时，ChatGPT 可以免费访问，网址为chat.openai.com，也可以选择升级到 GPT-4，获得更多高级功能，月费为 20 美元。你还可以探索 GPT 商店中由开发者社区创建的各种定制应用程序。

• Claude是由 Anthropic 开发的生成式 AI 模型。Claude 专门生成电子邮件、摘要、故事等文本。它的功能可以在claude.ai/chat/找到，旨在支持内容创作，并与人类价值观相一致。

• Google Gemini（前身为 Bard）是谷歌推出的一款聊天机器人。像 ChatGPT 一样，Gemini 能够全面且非正式地回答你的问题，并生成各种创意文本格式，如诗歌、代码、脚本、音乐作品、电子邮件、信件等。你可以在gemini.google.com/app探索它的功能。Gemini 是谷歌首个问答应用的继任者，原名为 Bard。

• Copilot是由微软提供的生成式 AI 服务，利用如 GPT-4 等模型。它通过自然语言促进对话，使得与 AI 驱动系统的互动和沟通变得更加容易。此服务可以通过www.bing.com/chat访问，用户可以无缝、直观地进行对话。

• Amazon Q，由 AWS 提供的服务，旨在显著提升组织内的生产力和决策能力。它作为一种先进工具，可以迅速提供相关答案，帮助解决问题、生成内容并执行任务，利用公司数据库、代码库和企业系统中丰富的知识。你可以通过访问 AWS 页面了解更多关于 Amazon Q 的信息：aws.amazon.com/q/。

• Perplexity AI代表了搜索技术的突破，作为一个先进的 AI 驱动聊天工具，它超越了传统搜索引擎。作为一个对话式搜索引擎，Perplexity AI 运用 NLP 和 ML 技术，准确地回应各种问题。它为用户提供了快速访问各类主题信息的途径，简化了搜索过程。此外，它邀请用户通过提问后续问题或寻求更多细节，深入了解感兴趣的主题，从而丰富用户的理解和学习体验。你可以通过访问www.perplexity.ai/来探索它。

还有许多其他 AI 应用可用于不同的目的，来自像 Jasper、Midjourney、Canva 和 Luminar 等公司。通过利用这些生成式 AI 工具，个人可以简化任务，激发创造力，并提高日常工作的生产力，从创作内容到进行互动对话。每个工具都有其独特的功能，使其成为简化和提升日常生活各个方面的多功能资产。

对于开发者

像应用开发者、数据科学家和机器学习工程师等开发者可以利用生成式 AI 通过生成代码、调整已开发模型和通过 API 访问现有模型，将他们的生产力提高多倍。让我们深入了解一下：

• 通过代码生成提高生产力：生成式 AI 工具提供了生成代码的能力，使你能够专注于业务逻辑，而不是编写重复的代码。一些最受欢迎的代码生成工具包括：

  • Amazon CodeWhisperer：AWS 提供的这项服务使用自然语言处理（NLP）和机器学习（ML）技术，根据自然语言查询生成代码片段。例如，你可以让 CodeWhisperer 创建一个使用 SES 发送电子邮件的 Lambda 函数，它会为你生成以下代码：

    `#create a Lambda function that sends an email using SES def lambda_handler(event, context):     client = boto3.client(‘ses’)     response = client.send_email(         Source=’XXXXXXXXXXXXXXXXXXXXX’,         Destination={             ‘ToAddresses’: [                 ‘XXXXXXXXXXXXXXXXXXXXX’,             ],         },         Message={             ‘Subject’: {                 ‘Data’: ‘Hello from SES!’,             },             ‘Body’: {                 ‘Text’: {                     ‘Data’: ‘Hello from SES!’,                 },             },         },     )     print(response)     return response` 
    

    CodeWhisperer 支持 15 种以上的编程语言，包括 Python、Java 和 JavaScript 等，以及流行的 集成开发环境 (IDEs)，如 VS Code、IntelliJ IDEA、AWS Cloud9、AWS Lambda 控制台、JupyterLab 和 Amazon SageMaker Studio。你可以在这里了解更多关于 Amazon CodeWhisperer 的信息：aws.amazon.com/pm/codewhisperer/。

• Azure Copilot：此工具使用 OpenAI Codex，一种经过数十亿行代码训练的大型语言模型，在 VS Code 中生成代码建议。你可以使用 Azure Copilot 编写多种语言的代码，如 Python、JavaScript、TypeScript 等。以下是 Azure Copilot 工作的示例：

  `# Suppose you want to write a function in JavaScript that takes an array of numbers and returns the average # You can start by typing the function name and parameters function average(numbers) { # Then you can press Ctrl+Space to trigger Azure Copilot suggestions # Azure Copilot will suggest the following code based on the context and common patterns   // initialize the sum to zero   let sum = 0;   // loop through the array of numbers   for (let number of numbers) {     // add the number to the sum sum += number;   }   // calculate the average by dividing the sum by the length of the array   let average = sum / numbers.length;   // return the average   return average; }` 
  

• ChatGPT 解释器：此工具使用基于 GPT-3 的聊天机器人 ChatGPT，根据自然语言输入交互式地生成代码。你可以使用 ChatGPT 解释器编写 Python、Java 和 C# 等语言的代码。以下是 ChatGPT 解释器工作原理的示例：

  `User: Write a function in Python that takes a list of numbers and returns the sum of the squares of the odd numbers. Chatgpt: def sum_of_squares_of_odd_numbers(numbers):     # initialize the sum to zero sum = 0 # loop through the list of numbers for number in numbers:         # check if the number is odd if number % 2 == 1:             # square the number and add it to the sum sum += number ** 2 # return the sum return sum` 
  

• Google Codey：Codey 支持超过 20 种编程语言，包括 Python、Java、JavaScript 和 Go 等流行语言。Codey 的主要目标是显著加快软件开发生命周期。它通过实时代码完成和生成功能来实现这一目标。开发人员可以根据具体的代码库定制 Codey，从而增强其在各种编程项目中的实用性。

如果你有兴趣在应用程序中利用生成式 AI FMs 的强大功能，恭喜你！许多这些模型可以通过著名云平台和组织提供的 API 轻松访问。让我们详细了解一下它们。

使用公共云服务商提供的生成式 AI FMs 在你的应用程序中。

由于一系列云平台提供 API，将生成式 AI FMs 集成到你的应用程序中现在比以往任何时候都更容易了。下面我们将详细了解一些这些流行的平台，以及如何利用它们：

• AWS：AWS 推出了 Amazon Bedrock 和 Amazon Bedrock 代理的正式发布，作为其致力于引领云 AI 领域的承诺的一部分，通过提供先进的 AI 解决方案和与行业领先的 FM 提供商的合作伙伴关系。Amazon Q 是一款新的生成式 AI 助手，专为专业用途设计，并在超过 17 年的 AWS 专业知识基础上进行训练，展示了 AWS 将 AI 集成到工作场所的创新方法，承诺提升企业的生产力和创造力。

• Amazon Bedrock：Amazon Bedrock 是 AWS 提供的一个强大的基于云的平台，旨在训练、构建和部署机器学习模型。它提供了广泛的 API 套件，支持包括自然语言处理、计算机视觉和语音识别等多种任务。Bedrock 还提供访问来自 Amazon 和领先 AI 组织的基础模型（FM），如 AI21 Labs、Anthropic、Cohere、Meta 和 Stability AI。要开始使用 Amazon Bedrock 开发生成式 AI 应用程序，首先需要选择一个适合你需求的基础模型。这可以通过 Amazon Bedrock 控制台或 API 完成。选择基础模型后，你可以通过 Amazon Bedrock API 轻松将其集成到你的应用程序中。可用的基础模型示例包括 Amazon Titan 用于文本摘要、Jurassic-2 用于遵循指令的语言模型，以及 Claude 3 用于深思熟虑的对话和内容创作。你可以通过以下链接开始使用 Amazon Bedrock：aws.amazon.com/bedrock/。

• SageMaker JumpStart：SageMaker JumpStart 是 AWS 的另一项服务，旨在简化机器学习开发过程。它提供了预构建的机器学习模型和工作流，加速你的机器学习项目。SageMaker JumpStart 为各种任务提供 API，例如自然语言处理（NLP）、计算机视觉和语音识别。要通过 SageMaker JumpStart 开始使用生成式 AI 应用程序，你需要选择一个与项目需求相匹配的预训练模型。选择后，你可以通过 SageMaker JumpStart API 将该模型部署到你的应用程序中。可用的模型包括 Hugging Face 用于 NLP、ImageNet 用于图像分类，以及 YOLOv5 用于目标检测。你可以通过以下链接了解如何开始使用 SageMaker JumpStart：docs.aws.amazon.com/sagemaker/latest/dg/studio-jumpstart.html。

• Microsoft Azure：微软正在积极将生成式 AI 技术嵌入其整个产品套件，包括 Azure、M365、Dynamics 365、Power Platform、Windows 和 GitHub，展示生成式 AI 对其产品线的变革性影响。对于企业客户，微软通过 Azure OpenAI 服务推出了其生成式 AI 计划，与 OpenAI 直接提供的服务不同，它专注于私有网络、顶级安全性、可扩展性和区域服务可用性等特性，从而将其服务与众不同。

• Azure OpenAI：Azure OpenAI 是微软的产品，提供访问各种基础模型，用于自然语言处理、计算机视觉和语音识别。你可以利用 Azure OpenAI API，接入像 GPT-3 这样的 NLP 模型、DALL-E 的基于文本描述的图像生成模型，以及 Speech Services 的语音识别和合成任务模型。Azure AI Studio 包括一个模型目录，类似于亚马逊的 SageMaker JumpStart。微软在 Azure AI 中引入了 MaaS，具有与亚马逊 Bedrock 相似的功能，包括即用型 API、托管微调和集成工具。你可以通过此链接注册 Azure OpenAI：azure.microsoft.com/en-us/products/ai-services/openai-service。

• 谷歌云平台（GCP）：GCP 将其生成性 AI 能力集成到 Vertex AI 中，展示了其增强解决方案套件的承诺。其 AI 计划的基石是 PaLM 2 FM，现在支持超过 25 个谷歌产品，并通过 PaLM API 向 GCP 客户提供。谷歌还开发了行业特定的 FM，包括用于医疗的 Med-PaLM 和用于安全应用的 Sec-PaLM，并推出了一系列名为 Duet AI 的 AI 助手，涵盖了 Google Workspace 和 Google Cloud。

  在其 FM 产品组合的重要扩展中，谷歌云宣布了 Gemini，这是其最新的第一方 FM。Gemini 将以多种配置形式提供，包括 Ultra、Pro 和 Nano，以满足广泛的应用需求。此外，谷歌云还提供了 Model Garden 和 Generative AI Studio，它们通过 Vertex AI 促进了对自家和第三方模型的访问。尽管提供了广泛的模型，但目前谷歌云仅通过 API 提供自家 PaLM 2 模型的直接访问，用于托管使用，这突显了其将专有技术与开放创新相结合，推动生成性 AI 解决方案的战略。谷歌云将其 Duet AI 产品策略分为两个部分：Duet AI for Google Workspace 和 Duet AI for Google Cloud。Duet AI for Google Workspace 将直接与微软的 M365 Copilot 竞争。Duet AI for Google Workspace 已经全面发布，并且有趣的是，它的定价恰好与 M365 Copilot 相同，至本文写作时为止。

• 谷歌云生成性 AI：谷歌云生成性 AI 为谷歌强大的生成预训练变换器模型打开了大门。你可以利用谷歌云生成性 AI API，接入像 DALL-E 2 这样的图像生成模型、T5 的 NLP 任务模型以及 BigGAN 的高分辨率图像生成模型，通过简单的自然语言提示生成图像。欲了解更多关于谷歌 AI 服务的信息，请访问此链接：cloud.google.com/ai/generative-ai。

下表展示了目前主要公共云服务提供商通过 API 提供的 FM 模型：

公共云提供商	可用的 FM 提供商	可用的 FM
AWS	Amazon AnthropicAI21 LabsCohereMetaStability.ai	Titan 文本嵌入 Titan 多模型嵌入 Titan 文本轻量版 Titan 文本快递版 Titan 图像生成器侏罗纪-2 超版侏罗纪-2 中版 Claude 2Claude 2.1Claude 即时版 Cohere 命令 Cohere 命令轻量版 Cohere 嵌入 Llama 2Llama 2 13BLlama 2 70B 稳定扩散 XL 1.0
Microsoft Azure	OpenAI 作为服务的模型 Meta	GPT-4GPT-4 Turbo,GPT-4 视觉版,GPT-3.5GTP-3.5 Turbo 嵌入模型 DALL-EWhisperLlama
GCP	Google	PaLM 2ImagenCodey 嵌入模型

表 14.1：通过公共云提供商访问的 FM

虽然这些平台是 GenAI 应用开发的顶级选择，但还有其他一些云服务商提供类似的能力，包括 IBM 云、阿里云和腾讯云。

为您的项目选择最佳平台将取决于您的具体需求，无论您是需要无服务器环境（Amazon Bedrock）、广泛的预训练模型（SageMaker JumpStart）、访问 OpenAI 的 GPT-3 模型（Azure OpenAI），还是 Google 的 LaMDA 模型（Google Cloud 生成 AI）。每个平台都具有独特的优势，可以帮助您创建适应多种用例和行业的生成 AI 应用程序。虽然您可以访问许多 FM，但选择适合的模型对于应用程序的成功至关重要。让我们一起学习如何根据您的需求选择最佳 FM。

选择合适的 FM

选择适合您项目的 FM 是确保生成 AI 应用成功的关键步骤。以下是选择最合适 FM 时需要考虑的一些关键因素：

1. 问题识别：首先明确您希望通过生成 AI 解决的具体问题。确定您的项目是涉及自然语言处理（NLP）、计算机视觉、语音识别还是其他任务。这一步有助于将您的选择范围缩小到专为您的特定领域设计的 FM。假设您正在为客户支持应用程序开发智能助手，将问题识别为一个专注于聊天和通话交互的 NLP 任务。寻找专门为 NLP 任务设计的 FM。

2. 数据考虑因素：可用数据的性质和规模至关重要。一些 FM 需要大量数据集才能有效训练，而其他模型则能在较小或专门的数据集上表现良好。确保您拥有适当的数据资源进行训练和评估。对于您的智能助手应用程序，获取一个包含大量客户询问和回应的数据集。如果数据集庞大且多样化，您可以考虑那些在大量数据上表现优秀的 FM。

3. 性能评估：一旦你确定了与你的问题和数据相符的潜在 FM，就需要在验证数据集上评估它们的表现。这项评估能帮助你了解每个 FM 在解决你的挑战和数据特点方面的效果。寻找在你的使用案例中表现出色的 FM。假设你将 GPT-3、GPT-4 和 BERT 列为应用程序的潜在 FM。通过衡量诸如响应连贯性、准确性和用户满意度等指标，在验证数据集上评估每个 FM 的性能。选择为你的特定聊天机器人需求获得最高分的 FM。这能确保你的聊天机器人为客户提供有价值且与上下文相关的回应。

4. 微调：微调是指在你的数据集上训练 FM，以提高其性能并使其与问题领域对接。这个过程有助于定制模型，以生成更准确和相关的输出。假设你决定使用 GPT-4 作为你的 FM，但你发现它在理解客户特定的行话时有困难。你可以对 GPT-4 进行微调，使用客户支持数据集，以增强其对行业特定术语和短语的理解。这种适应确保你的聊天机器人能提供更准确和相关的响应，从而改善整体用户体验。

5. 迭代：机器学习本质上是一个迭代过程。准备好根据需要对模型进行迭代。这可能涉及改进数据集、调整超参数，或尝试不同的 FM，以达到预期的性能水平。持续的改进通常是优化生成型 AI 应用程序所必需的。假设你的代理助手应用已部署，但你收到关于偶尔出现不相关响应的用户反馈。通过改进数据集、调整超参数以及解决用户提出的具体问题，持续迭代你的 FM。这一迭代过程有助于随着时间的推移保持和提升聊天机器人的表现，确保持续的客户满意度。

6. 提示工程：提示工程是一种技巧，通过精心设计提示词来引导生成型 AI 模型，如聊天机器人或文本生成器，生成特定的、期望的结果。这个人类参与（HITL）的方法至关重要，因为提示词的措辞会极大地影响 AI 的响应，确保其相关、准确且与上下文相符。它在优化与 AI 的交互中发挥着重要作用，能够有效地根据特定任务或目标定制其响应。

通过遵循这些扩展步骤，你可以有效地导航选择、调整和优化适合你生成型 AI 项目的 FM，同时考虑现实世界的例子和使用案例。当 FM 在一个非常大的数据集上进行训练时，它可能会产生混淆并给出不准确的回答。接下来，我们将更详细地了解如何防止这种情况的发生。

防止模型幻觉

在生成型 AI 模型中，模型幻觉是指模型生成不正确、不相关或虚构的响应或输出的情况。当模型遇到无法充分理解的输入，或超出其训练数据范围进行推断时，往往会产生幻觉。模型幻觉可能导致错误、荒谬或潜在有害的信息呈现给用户。例如，考虑一个基于生成模型的医学诊断 AI 工具。如果模型开始出现幻觉，可能会根据患者的症状提供错误或不相关的医学建议或诊断，导致潜在的危险健康后果。同样，在金融领域，某个用于预测市场趋势的 AI 模型可能会产生幻觉，给出不准确的预测，导致依赖其预测的用户遭受重大财务损失。解决模型幻觉问题对于确保 AI 系统的可信度和可靠性至关重要，特别是在那些决策可能带来重大后果的关键领域。

为了防止模型出现幻觉并提高生成型 AI 模型的准确性和可靠性，可以采用一些技术和策略，例如：

• 数据质量和数量：确保用于训练模型的数据具有高质量、多样性，并且能够代表目标应用领域。拥有一个庞大且多样化的数据集有助于模型理解广泛的上下文，并减少出现幻觉的可能性。多样化的数据集可能包括来自不同领域、语言和风格的文本。在训练聊天机器人时，丰富的数据集有助于模型理解不同的用户查询并提供上下文相关的回应。

• 微调：在对大规模数据集进行初步训练后，对模型进行领域特定的数据微调。微调使模型适应特定任务或知识领域，减少生成幻觉内容的机会。例如，将预训练语言模型如 Amazon Titan 或 GPT-4 微调到医学文献上，从而创建一个医学聊天机器人，能够回答问题、提供信息并帮助医疗专业人员理解复杂的医学文本。

• 提示工程：在与模型交互时，编写清晰且具有上下文相关性的提示或输入查询。结构良好的提示能够引导模型生成更准确的响应，符合用户期望。例如，避免使用模糊的提示“告诉我关于历史的事”，可以改为“总结第二次世界大战的关键事件”。针对教育材料的内容生成，使用清晰和具体的提示有助于确保信息传递的准确性。

• 检索增强生成（RAG）：实施诸如 RAG 之类的技术，从知识库或文件中检索相关信息，并利用检索到的上下文生成响应。这种方法有助于将模型的输出基于事实和领域特定信息，减少幻觉，从数据库中检索相关产品详情，并用于生成准确的产品描述。电子商务平台可以实施 RAG 以创建详细且真实的产品描述。

• 阈值过滤：为响应质量或相关性设置阈值。仅接受模型输出达到一定置信度或相关性水平的响应，并丢弃或重新提示那些低于此阈值的响应。拒绝置信度低于 0.8 的响应可以确保高质量的答案。客服聊天机器人可以使用阈值过滤来为用户查询提供可靠的响应。

• 人工审查：整合人工审查和审核，以过滤潜在的幻觉响应。人工审查员可以评估和纠正模型输出，确保准确性和安全性。内容生成平台可以使用人工审查来维护内容质量并防止误导信息。

• 持续监控和反馈：监控模型的性能并收集用户反馈。利用这些反馈来识别和解决模型幻觉的情况，并随时间改进模型。收集关于聊天机器人交互的用户反馈，并分析以进行改进。聊天机器人和虚拟助手可以基于用户反馈持续演进，以提供更好的帮助。

• 安全措施：在模型内部实施安全措施和限制，防止其生成有害、偏见或不适当的内容，并在聊天机器人中实施脏话过滤器，以屏蔽冒犯性语言。在线社区和社交平台采用安全措施维护尊重和安全的环境。

• 领域限制：明确定义并向用户传达模型的范围和限制。这有助于管理用户期望，并减少当面对超出范围查询时模型产生幻觉响应的可能性。它告知用户天气聊天机器人无法提供医疗建议。专门的聊天机器人，如天气或旅行助手，通过设定清晰的界限来避免误导用户。

• 定期更新和维护：保持模型与 AI 领域的最新数据和进展同步。定期更新和维护可以提高模型的整体性能并减少幻觉的发生。更新语言模型的最新词汇和语言趋势。新闻机构使用更新的语言模型生成实时新闻摘要。

通过结合这些策略，开发人员和组织可以最小化模型幻觉的风险，并创建更可靠和值得信赖的生成式 AI 系统。

企业在内部战略性地部署生成式 AI 应用程序，作为在更广泛的外部部署之前的谨慎初步步骤。这种方法充当了缓冲区，降低了向客户提供错误或不适当内容的风险。内部部署使组织能够在受控环境中优化 AI 模型，在这里错误的后果较为轻微，且可以迅速解决。熟悉业务背景和细微差别的员工能够为模型的输出提供有价值的反馈，识别 AI 生成的任何不相关或不正确的回应。

例如，一家公司可以内部部署一个 AI 驱动的聊天机器人来协助 IT 支持或人力资源咨询。随着员工与聊天机器人的互动，他们可以报告任何异常或机器人提供奇怪或不准确答案的情况。这个反馈循环使公司能够微调 AI 模型，在推出到面向客户的场景之前提高其准确性和相关性。

这种分阶段的方法不仅减轻了与 AI 幻觉相关的风险，而且还增强了对技术的信心，无论是在组织内部，还是在其客户之间。到生成式 AI 应用程序面向外部用户时，它已经经过了广泛的验证和优化，从而确保了更加可靠和有效的用户体验。

让我们了解一个参考架构，它将帮助您构建基于生成式 AI 的应用程序。

构建房贷助手应用的生成式 AI 参考架构

购房过程通常对于潜在买家来说显得令人生畏，主要是因为涉及大量的文书工作。买家经常发现自己需要更多的时间来深入理解这些文件中的复杂细节。因此，他们常常感到不知所措、困惑，甚至偶尔会因难以理解所签署内容的意义而感到沮丧，尤其是在涉及按揭相关文件时。

解决这些挑战对于提升整体客户体验至关重要，并且在贷款申请和结算过程中建立买方与贷方之间的信任。为了减轻这种负担并赋能购房者，生成式 AI 解决方案可以帮助他们更好地理解贷款条款和条件，而无需依赖按揭专家或律师。

本节深入探讨了构建虚拟房贷代理应用程序的架构。该应用的核心是对关键按揭文件的文本摘要。所呈现的架构采用了无服务器方法，使用 AWS 并借助 Amazon Bedrock 访问生成式 AI FM。值得注意的是，您可以使用您选择的技术实现此架构。

图 14.5：基于生成式 AI 的房贷虚拟助手应用

我们在前述架构图中设计了一个基于 Amazon Lex 的虚拟助手（VA）应用程序。Amazon Lex 是 AWS 提供的一个服务，用于构建无服务器的聊天机器人。这个虚拟助手是一个直观的界面，用户可以在其中互动并寻求有关他们抵押贷款文档的具体答案。通过自然语言理解和处理功能，虚拟助手可以解读用户的问题和提示，随后访问由 Amazon Kendra 索引的领域特定文档片段。

Amazon Kendra 的智能搜索功能对于高效检索相关文档片段至关重要。这些精心策划的文档片段随后被传输到 Amazon Bedrock FM Claude 2，生成具有信息性且连贯的回答来回应用户的查询。通过这种方式，生成式 AI 解决方案简化了复杂抵押贷款文档的理解。它通过为购房者提供可靠且知识丰富的资源，提升了整体购房体验，最终增加了客户满意度，并增强了借贷机构的信任度。

实施生成式 AI 解决方案时，重点确保用户仅接收到严格符合所使用文档范围的回答。为预防模型幻想或不准确回答的发生，该架构利用了 RAG。RAG 基于的方法的一个关键部分是将公司独特的知识库或内容作为一个重要的上下文组件进行整合。该知识库与用户请求无缝结合，形成一个全面的提示。然后，这个综合的提示被传递给 Amazon Bedrock FM，生成高准确度和简洁的总结作为回应。

利用 RAG 的能力，同时无缝结合领域特定的知识，确保用户始终获得不仅与上下文相关而且非常精确的回答。这种精确度是提供卓越用户体验并增强生成式 AI 应用程序在整个抵押贷款文档审查过程中可信度的关键。

该解决方案简化并优化了这些文档中的内容，确保购房者能够快速访问他们所需的相关信息。这不仅节省了时间，还帮助显著减少了混乱。

实现生成式 AI 的挑战

实施生成式 AI，尽管前景广阔，但也面临一系列挑战和考虑事项。在以下小节中，我们将深入探讨与生成式 AI 相关的主要挑战。

培训稳定性问题

在生成式 AI 中遇到的一个重大挑战是培训稳定性问题。这些问题可能表现为收敛问题、训练缓慢，甚至发散，导致很难获得高质量的生成模型。

生成式 AI 的一个常见应用是使用生成对抗网络（GAN）创建高清图像。在训练 GAN 进行图像生成时，可能会出现训练稳定性问题。例如，生成器可能会生成没有意义或高度扭曲的图像。这些问题可能会阻碍 GAN 收敛到一个令人满意的解决方案，导致图像生成质量差。

解决和防止生成式 AI 训练稳定性问题需要多方面的方法。技术如谱归一化和渐进式生长可以稳定训练过程。适当的权重初始化和仔细监控损失曲线有助于防止像模式崩溃和收敛过慢的问题。此外，使用批量归一化和正则化技术可以促进训练的稳定性。通过结合这些策略并微调超参数，开发者可以增强生成式 AI 模型的稳定性，确保其在各种应用中的更可靠和更强的性能。

模式崩溃

生成式 AI 在各个领域创造类人内容方面取得了显著进展。然而，它仍然面临一些困难，比如模式崩溃，这会影响输出结果的多样性和质量。当生成模型由于无法完全捕捉目标分布的多样性而产生少量或重复的输出时，就会发生模式崩溃。模型会集中在一个数据子集上，忽视数据集内更广泛的变异性。

想象一种场景，你正在训练一个文本生成模型来生成多样化的内容，比如创作新闻文章。在这种情况下，模式崩溃可能表现为模型反复生成相同的标题或内容，未能探索大量可能的文章。

假设你正在使用文本生成器来创作新闻文章。尽管拥有多样化的新闻主题数据集，模型却总是生成只有少数几种变化的标题，反复呈现相同的新闻故事，极大地降低了生成内容的质量和实用性。

通过引入多样性促进目标、微调超参数以及加入随机性，开发者可以有效应对并防止模式崩溃，从而增强生成式 AI 在众多应用中的实用性和丰富性。

潜在空间插值挑战

潜在空间插值是生成式 AI 中一个引人入胜的方面，它允许模型在潜在空间的两个点之间生成中间输出。然而，它也带来了与生成输出的意义性和质量相关的挑战。潜在空间插值的核心挑战在于，在潜在空间的两个点之间生成输出可能并不总是能产生语义上有意义或连贯的内容。实质上，生成的过渡可能缺乏连续性和相关性。

假设你想创建一个生成式模型，能够生成不同艺术风格之间平滑过渡的图像——例如，在保持视觉一致性的前提下，将一幅图像从梵高风格过渡到毕加索风格。当在两种风格迥异的图像之间进行插值时，生成的过渡可能显得模糊、扭曲或语义不连贯。这会削弱艺术质量和风格过渡的平滑感。

为了使生成式模型表现得更好，特别是在创建中间结果时，开发者使用特定技术来改善这些模型的学习和输出方式。以下是一个简单的概述：

• 解耦表示学习：这种方法帮助模型以清晰分离的方式学习特征。例如，如果模型正在学习人脸，它会学会独立区分年龄、发型或眼镜等特征。这种清晰度有助于模型生成更准确和逼真的过渡或变化。

• 微调插值方法：插值就像是填补两个已知点之间的空白。在生成式模型的上下文中，微调这些方法意味着使一个输出与另一个输出之间的步骤或过渡更加平滑和合理。这有助于避免模型生成一系列图像或声音时出现突兀、不真实的变化。

• 利用半监督学习：这种技术在训练过程中使用已标注（已知）和未标注（未知）数据的混合。它通过从已标注数据中学习模式，帮助模型更好地推测未标注数据。这种方法有助于模型在填补空白或进行过渡时，生成更连贯和逼真的输出。

通过使用这些技术，开发者确保当生成式模型生成一系列输出（如视频中的帧或转换中的步骤）时，结果能够平滑过渡并且合乎逻辑，从而提升模型在创作任务中的整体质量和实用性。

伦理问题和滥用

在当今的数字环境中，生成式 AI 技术的伦理问题和潜在滥用已成为重要挑战。生成式 AI 强大的内容创建和操控能力可能会被恶意利用，比如制作深度伪造视频、传播虚假信息或生成令人反感的内容。这些行为引发了严重的伦理问题，并对信任和公正构成威胁。

假设有一个场景，生成式 AI 创建深度伪造视频，冒充个人，包括公众人物、名人或政治人物。恶意行为者可能会制作包含政治人物发表虚假言论或进行不当行为的深度伪造视频。这些视频能够武器化虚假信息，操控公众舆论或破坏声誉。

解决生成式 AI 中的伦理问题和防止滥用是保持数字时代信任与诚信的关键。通过结合严格的内容审核、身份验证措施、负责任的 AI 指南、监管框架、反取证技术和公众教育，我们可以防范生成式 AI 技术的恶意滥用。这种集体努力确保生成式 AI 以负责任和伦理的方式造福社会。

这些挑战突显了使用生成式 AI 的复杂性。应对这些挑战需要技术增强、伦理考量和监管措施的结合。此外，AI 领域的持续研究与发展对于缓解这些挑战、确保生成模型的负责任和有益使用至关重要。

总结

在本章中，我们深入探讨了生成式 AI 的迷人世界，从全面探索它是什么开始。我们探讨了生成式 AI 启用的多样化应用场景，从转变客户体验到提升员工生产力，再到优化业务运营的各个方面。

为了理解生成式 AI 系统的基本架构，我们分解了不同类型的生成模型，包括 GANs、VAEs 和基于变换器的模型。我们强调了超参数调优和正则化在构建有效生成式 AI 架构中的重要性。

在 FMs 的背景下，我们提供了对一些由该领域主要参与者提供的流行生成式 AI FMs 的深入分析，如 Amazon、OpenAI、Google、Nvidia 等。这些模型是生成式 AI 应用的支柱。

对于那些渴望开始生成式 AI 之旅的人，我们提供了针对不同用户群体的指导。最终用户可以通过聊天机器人体验生成式 AI，开发者可以利用它生成代码，而开发人员可以将生成式 AI FMs 集成到他们的应用程序中。

我们还讨论了选择合适 FM 对于项目的关键性，确保它与特定要求和数据特征一致。为了保持模型的准确性并防止模型幻觉，我们探讨了指导生成式 AI 工作的策略。

此外，我们介绍了使用生成式 AI 构建抵押贷款助手应用程序的参考架构。这个架构简化了复杂抵押贷款文档的理解，提升了整体购房体验。

最后，我们检查了实施生成式 AI 的挑战，包括训练稳定性问题、模式崩溃、潜在空间插值问题，以及与潜在滥用相关的伦理问题。

在本章中，我们为全面理解生成式 AI、其应用、模型和挑战奠定了基础，为进一步探索和在人工智能领域的实际应用奠定了基础。

留下评论！

喜欢这本书吗？通过留下亚马逊评论来帮助像你一样的读者。扫描下面的二维码，获得你选择的免费电子书。

第十五章：重构遗留系统

当今的组织在一个充满挑战的环境中运营。变革的速度前所未有。监管机构和机构正在施加新的报告和安全要求，新技术正在颠覆消费者的期望和认知，生态系统也在不断变化，新玩家不断进入市场。因此，组织正在重新定义其商业模式，以提供客户需求、敏捷性和技术，吸引人才，保持竞争力并实现增长。

应用程序现代化已经成为这些新商业模式的关键组成部分，可以快速建立开发/测试环境，实验新想法，开发新产品和服务。除了消除对昂贵和繁琐基础设施的投资需求外，新系统还通过提供一套广泛的可用技术来促进创新。

遗留系统是那些已经在您的数据中心部署了几十年且未进行过多次更改的应用程序。这些系统过时且在快速变化的技术环境中难以维护。遗留系统的定义通常基于其年龄以及由于底层架构和技术的限制，无法满足日益增长的业务需求。

通常，大型企业使用遗留应用程序来处理日常关键业务任务。这些遗留系统广泛应用于多个行业，如医疗保健、金融、交通运输、制造业和供应链等。公司通常需要在这些系统的维护和支持上花费大量资金，这也促使了对遗留系统重构的需求。重构和现代化遗留应用程序帮助组织提高敏捷性和创新力，并优化成本和性能。

在本章中，您将了解与遗留应用程序相关的挑战和问题，以及重构它们的技术。重写复杂的遗留应用程序可能会带来额外的业务中断风险，因此您将了解重构应用程序或考虑迁移到更灵活的基础架构的选项。本章将涵盖以下主题：

• 了解遗留系统的挑战

• 定义系统现代化的策略

• 探讨遗留系统现代化技术

• 定义遗留系统的云迁移策略

• 大型主机迁移到公共云

• 使用生成性人工智能现代化遗留代码

到本章结束时，您将了解遗留系统的各种挑战和现代化驱动因素。您将学习遗留系统现代化的各种策略和技术。随着公共云成为许多组织的首选策略，您还将学习遗留系统的云迁移方法。

了解遗留系统的挑战

遗留应用程序给组织带来了重大挑战。一方面，组织有一些关键应用程序已经使用了数十年。另一方面，遗留应用程序限制了组织创新的步伐。

终端用户在竞争激烈的环境中寻求最现代、技术最先进的应用程序。所有新功能通常都伴随最新的软件，而遗留应用程序限制了你添加那些有益于终端用户的功能的能力。

下图展示了组织在使用遗留系统时面临的一些重大挑战：

图 15.1：遗留系统的挑战

在深入探讨解决方案之前，清晰地理解问题是至关重要的。让我们更深入地探讨遗留系统所面临的挑战，以便更好地理解它们。

难以跟上用户需求

客户至上是商业成功的关键，无法跟上最新的技术趋势会严重损害企业。你可以拿诺基亚作为例子，它曾经主导全球手机市场。随着智能手机的出现，诺基亚仍然坚持使用遗留系统，导致几乎破产。柯达也有类似的故事——它曾是全球相机行业的龙头企业。柯达未能跟上数字化创新，并未将其整合到自己的系统中，最终导致柯达在 2012 年破产。许多大型企业都因未能进行遗留系统现代化和创新而未能生存下来。

在当前快速变化的技术和激烈竞争的环境中，用户的需求非常苛刻。现在，组织必须按照用户的需求进行变革，因为用户有多个选择。随着技术的发展，用户也随之变化，开始使用最新和最流行的应用程序。如果你的竞争对手提供了用户所需的新功能，他们就能迅速超越你。最近的一个例子是 Google，作为 AI/ML 的先驱，可能更早就开发了生成性 AI（GenAI）技术。然而，OpenAI 迅速推出了 ChatGPT，迫使 Google 处于下风并进入了追赶的局面，最终在 GenAI 市场上失去了竞争优势。这些例子凸显了采用新兴技术以保持竞争优势的重要性。

遗留系统也对有内部用户基础的企业应用程序带来挑战。一个建立在主机上的旧系统主要使用命令行，这在数字时代可能不太适合用户友好性。相比之下，新一代员工要求更用户友好的方式来执行日常任务。然而，你可能得不到管理层的支持，因为他们可能已经使用遗留系统工作了数十年，并且习惯了这些系统。

大型企业核心技术需要更新，其中包含许多已有几十年历史的系统。运行核心系统的组织在启用现代客户体验时面临严峻挑战。许多系统是多个并购的产物，导致数据孤岛碎片化、基础设施成本过高以及开发周期缓慢。这造成了低效的处理和决策，缺乏业务敏捷性，客户响应不及时，维护成本高昂。在这种情况下，IT 很难满足内部利益相关者和客户的现代需求。

更高的维护和更新成本

由于遗留系统已运行多年，它们可能看起来成本较低。但随着时间的推移，整体拥有成本反而变得更高，因为旧系统的支持和更新通常更加昂贵。

这些更新通常无法开箱即用，需要大量手动解决方法来维护系统。大多数遗留系统不支持自动化，导致更多的人工工作。

遗留系统通常包含大量专有软件，这导致许可证费用显著增加。除此之外，旧软件不再得到供应商的支持，购买生命周期之外的额外支持可能非常昂贵。另一方面，现代系统主要采用开源技术，降低了成本。由于技术债务和难以调试的代码，遗留系统的操作停机时间可能更长，并且会增加运营费用。维护遗留系统的技能（如 DB2、COBOL、Fortran、Delphi 和 Perl）的人才非常稀缺，导致招聘成本和系统风险显著增加。

遗留应用程序已运行数十年，随着时间推移，许多更改已被接纳，但未移除未使用的代码，积累了大量技术债务。任何减少技术债务的措施都可能存在风险，因为其影响和依赖关系未知。因此，组织不得不为维护不必要的代码和系统投入资金，以避免因做出重大更改而破坏系统。

然而，由于未知的依赖关系和停机时间，现代化遗留系统可能会非常昂贵。在决定是否进行现代化时，需要仔细进行成本效益分析（CBA），并确定投资回报率（ROI）。由于利益相关者需要看到现代化的即时效益，获取遗留系统现代化的资金可能会具有挑战性。

技能和文档短缺

传统技术（如大型主机）具有多个相互依赖的复杂组件。它们是庞大的专有且昂贵的服务器，如果有人希望独立开发技能，这些服务器并不容易获得。保持应用程序开发资源是一项挑战，而招聘具有旧技术和操作系统实际操作经验的人则更具挑战性。

传统系统通常已有数十年历史，大多数具有相关技能的员工已经退休。此外，这些系统可能缺乏文档，未能记录投入的多年工作。随着老一代员工的更替，知识流失的风险很大。缺乏知识使得更换系统变得风险很大，因为依赖关系不明确。由于系统复杂性和技能短缺，任何小的功能需求都难以满足。

新的前沿技术，如高级分析、机器学习、生成型人工智能和物联网（IoT），是建立在新的技术平台上的。由于新技术与传统系统整合不良，组织可能会因为无法充分利用新兴技术的全部功能而输给竞争对手。现代化系统有助于塑造一个创新型企业的品牌，而大多数新一代的劳动力都希望在这样的公司工作。对于传统技术而言，开发和培训是一个更为重要的支出。

自动化通常有助于通过减少人工劳动来降低成本。现代系统中有许多工具可以用于构建自动化——如 DevOps 流水线、代码审查和自动化测试——而这些工具可能是传统系统无法利用的，从而导致额外的成本。

企业安全问题的漏洞

安全性是任何组织和系统的首要任务。运行在旧操作系统上的传统应用程序（如 Windows XP 或 Windows 2008）由于缺乏供应商支持，容易受到安全问题的影响。软件供应商会不断确定新的安全威胁，并发布补丁以应对最新版本的软件。任何被供应商宣布为生命周期结束（EOL）的传统软件将不再获得新的安全补丁，这会使你的应用程序在运行旧版本软件时暴露于多种安全威胁之中。

传统应用程序的系统健康检查常常被忽视，这使得它们更容易受到安全攻击。技能差距使得持续提供支持和帮助变得困难，因此系统需要更加安全。一旦出现漏洞，就有可能使你的应用程序、数据库和关键信息暴露给攻击者。

除了安全漏洞，传统应用程序在维护上也因合规性问题而变得复杂。随着监管要求的不断变化，强制执行严格的数据处理和使用安全，传统系统需要做出更改以遵守当地的治理和合规性要求。

例如，遵守欧盟的通用数据保护条例（GDPR）要求每个系统都必须使用户能够请求删除其数据。虽然现代系统可能会提供开箱即用的自动化和自助服务功能，但在遗留系统中，这一操作可能需要手动执行，并变得更加复杂。

遵守合规需求可能会导致更多的运营成本和耗时的维护工作。

与其他系统的不兼容

除了终端用户外，系统之间经常需要进行集成。这些系统可能涉及不同的部门、客户、合作伙伴或供应商。不同的系统需要以标准格式交换数据，而这些格式会不断演变。几乎每隔几年，文件和数据格式标准就会发生变化，以提高数据交换效率，而大多数系统需要进行调整以适应这些变化。那些坚持使用旧格式的难以变更的遗留系统可能会导致系统不兼容，成为供应商和合作伙伴不愿使用的系统。无法满足标准需求会增加显著的业务风险，因其需要复杂的解决方法并降低生产力。

为了满足简单的业务需求而添加解决方法可能会使系统更加复杂。现代系统采用面向服务的架构，通过独立添加新服务来更轻松地适应任何新需求。旧系统通常采用单体架构，添加任何新功能都意味着需要重建并测试整个系统。

现代架构是基于 API 的，可以轻松地与其他系统集成，以减轻繁重的工作负担。例如，一款出租车预订应用程序使用 Google 地图进行全球定位系统（GPS）导航，并使用 Facebook 或 X 进行用户身份验证。如果没有 API，遗留系统中的这些集成就会更加困难，导致复杂的定制代码。

遗留应用程序在随着来自上游依赖系统的负载增加时，可能会面临可扩展性问题。遗留应用程序通常采用单体架构，且依赖硬件。由于硬件依赖性，单体系统在可扩展性方面面临重大挑战，因为它不能水平扩展，垂直扩展的能力也受到最大系统容量的限制。此外，单体系统的某一部分需求增加时，整个系统都需要扩展。将单体应用程序拆分为微服务可以帮助解决扩展性挑战，并应对负载压力。

除了软件维护，遗留应用程序对硬件基础设施也有较高的成本，因为它们依赖于特定版本的运行。这些系统分布在多个数据库中，存在重复数据和相似的功能。由于它们的单体结构，难以整合并利用基于云的基础设施的灵活性来节省成本。此外，分散的系统允许软件团队根据微服务的需求选择软件技术栈，而无需为所有系统功能统一选择一个技术栈，从而使得每个微服务的技术选择和/或支持该微服务的团队的需求多样化。

让我们来看一下系统现代化的一些关键优势。

定义系统现代化的策略

通常，遗留系统会被排除在企业整体数字化战略之外，问题只在需要时才得到解决。被动的做法阻止了组织实施整体系统现代化和获得好处。

如果你的遗留系统面临严重的业务挑战，例如安全性和合规性问题，或者无法满足业务需求，你可以采取大爆炸方法。在大爆炸方法中，你从头开始构建一个新系统，并关闭旧系统。此方法风险较大，但可以解决现有遗留系统无法缓解的业务需求。

另一种方法是分阶段方法，即一次升级一个模块，同时保持旧系统和新系统的并行运行。分阶段方法风险较小，但需要较长时间，并且可能更昂贵，因为需要维护两个环境，并且增加网络和基础设施带宽。

处理应用程序组合、优先考虑特定应用程序并制定整体计划是第一步。当你使用云时，你设计了一个新的运营模式，并最终形成了一种工具组合。你可以使用第三方工具来框定需求和工具偏好。最后，你可以使用咨询合作伙伴来更成功、快速地完成迁移和现代化项目。

采取这些方法中的任何一种，在应用程序现代化完成后都能带来各种好处。

遗留应用程序的评估

一个组织可能有多个遗留系统，包含数万到数百万行代码。在现代化过程中，遗留系统必须与业务战略和投资成本相一致。此外，可以重新利用某些部分或完全从零开始编写，但第一步是进行评估，更好地理解整体系统。

在评估阶段，解决方案架构师需要使系统易于评估并做出明智决策。评估可以在几天或几周内完成，这取决于工作负载的大小和复杂性。以下是解决方案架构师在进行评估时需要关注的主要领域：

• 技术评估：你需要了解现有系统所使用的技术栈。如果当前的技术已经过时并且缺乏供应商支持，可能需要替换它。如果有更好的技术版本可用，可以考虑升级。通常，新版本与旧版本是向后兼容的，所需的更改很少。

• 架构评估：你需要了解整体架构，以确保其能够适应未来发展。可能存在需要对技术进行小规模升级的情况，但整体架构需要更单体化和可扩展。最好对架构进行审计，考虑成本、可扩展性、可用性、性能和安全性。可能需要进行重大架构更改，以使应用程序与业务需求对齐。

• 代码和依赖性评估：传统系统通常在单体环境中拥有数十万行代码。各个模块之间的紧密联系使得系统变得非常复杂。如果在不充分审查的情况下删除某个模块中看似未使用的代码，可能会影响到其他模块。这些代码行可能是几十年前编写的，并且需要定期重构和审查。即使技术和架构看起来没有问题，你仍然需要判断这些代码是否可以升级和维护。你还需要了解是否需要进行与 UI 相关的升级，以改善用户体验。

作为解决方案架构师，你需要确定各个模块和代码文件之间的依赖关系。模块可能紧密耦合，在现代化整体架构时，你必须定义一种方法，进行同步升级。在评估过程中，你可能会发现以下模式：

• 首先，许多客户意识到他们有很多老旧应用程序，这些应用程序与未来的商业模式不太匹配；它们可以被淘汰。例如，大约 10-20%的应用程序组合可以被淘汰。

• 其次，五到七年前不存在的成千上万的 SaaS 供应商，如今可以替代许多本地应用程序。例如，大多数客户已经选择 Salesforce 作为 CRM 平台。转向 SaaS 可以缩减 IT 运营管理的操作组合——它仍然涉及安全性和身份管理的工作，但操作成本较低。

然后，可以做出决定，选择提升并迁移，在迁移过程中重新平台操作系统、数据库或编程语言，以减少成本。例如，客户可能选择将平台从 Windows Server 迁移到 Linux，或将数据库从 Oracle 迁移到 Postgres，以减少数据库许可费用。你在第三章《云迁移与混合云架构设计》中学到了这些技术。

如果选择现代化，你应该专注于现代化那些能使你业务差异化的应用程序。我们来探讨一下现代化的方式。

定义现代化方法

对于利益相关者而言，应用程序现代化可能没有立即的激励。你需要选择最具成本效益的方法，并更快地交付结果。

下图展示了现代化方法：

图 15.2：遗留系统现代化方法

在进行系统评估后，您必须了解现有架构模式及其限制。根据您的技术栈，您需要评估迁移工具。例如，如果您将应用程序重新托管到 VMware 上，您可能会使用模拟器进行主机迁移，或使用 vCenter。选择各种现代化方法并创建概念验证（POC）以识别差距。以下是一些方法：

• 架构驱动的现代化：架构驱动的方法是实现最大灵活性的必要条件。通常，架构方法是语言无关且平台无关的，通过应用面向服务的模式，赋予开发团队更多的创新灵活性。如果您的评估显示您需要进行重大架构更改，可以选择这种方法。首先实现最关键的功能，然后构建一个突出差距和所需努力的 POC。根据您的遗留应用程序，采用微服务方法以实现可扩展性，并确保与其他系统的更好集成。

• 系统再工程：在再工程方法中，您必须深入了解遗留系统并进行逆向工程，以构建新的现代化应用程序。您需要确保做出有助于创建面向未来系统的技术选择。如果遗留系统过于复杂并且需要长期项目，则应采取这种方法。首先进行应用现代化，然后在分阶段的方式中将数据库作为最终切换的目标进行升级。您需要建立一个机制，使得遗留和升级模块能够共存，并具有以混合方式进行通信的能力。

• 迁移和增强：如果您现有的系统技术相对有效，但由于硬件限制和成本问题受到制约，您可以选择迁移和小幅增强的方法。例如，您可以将整个工作负载迁移到云端，以获得更好的基础设施可用性和成本优化。此外，云服务提供商提供了多个现成的工具，帮助您更频繁地进行更改并应用更好的自动化。迁移方法使您能够以较少的努力现代化应用程序，并确保它面向未来，使其长期保持相关性。然而，迁移方法有限，可能只适用于某些工作负载。

在你计划迁移和现代化时，要考虑那些需要大量重新设计和现代化的特定 IT 领域。这一现代化包括开发人员的操作系统环境，因为它们会影响补丁管理。接下来是安全性、网络和身份，它们为扩展性、弹性和成本降低提供了绝佳机会。然后是存储、备份和数据库工具，随着更多应用迁移到云端，它们也需要现代化。此外，你还需要现代化监控和管理工具，这需要培训和重新技能提升。让我们来看看各种现代化遗留系统的策略。

系统现代化的好处

通过解决遗留系统现代化日益增长的需求来制定未来的数字战略，可以带来许多优势，正如下图所示：

图 15.3：遗留系统现代化的好处

以下是应用现代化的显著好处：

• 客户满意度：使用最新的技术提供更好的用户界面（UI）、用户体验（UX）和全渠道体验。消费者已经习惯于通过个人体验从任何设备、位置或时间实时访问信息。你不需要为 UI 构建不同的变体；它可以一次构建并部署到笔记本、平板和智能手机等设备上。快速且流畅的 UI 带来更好的客户体验和商业增长。

• 面向未来的商业战略：现代化你的应用程序使你能够更加灵活和创新。团队可以轻松应对业务需求的变化，并与新技术一起发展。

• 保持领先竞争：用户总是寻找最新的东西，并转向那些提供更好体验的新应用。应用程序的现代化帮助你通过跟随最新趋势保持领先竞争。例如，语音集成在应用中被广泛提供，你可以通过人脸识别增强安全性。只有当你的应用采用最新技术时，这才是可能的。

• 应用程序的可靠性和性能：每个新的软件 API 和操作系统版本都尝试解决和改进性能问题。使用最新的软件和硬件有助于你实现更好的性能、可扩展性和高可用性。应用现代化帮助你减少运营中断并增强安全性。

• 使用前沿技术的能力：遗留系统阻止你从数据中获得可以帮助你发展业务的洞察。通过现代化你的数据库并创建数据湖，你可以使用大数据和机器学习获得各种洞察。这还帮助你留住员工，因为人们有机会使用新技术。

• 成本节省：总体而言，任何现代化都能通过减少运营维护成本和提供更自然的升级带来成本节省。利用开源软件可以降低许可成本，硬件灵活性有助于采用云按需付费模式，自动化减少了日常工作所需的人力资源，并提高了整体效率。

通过迁移遗留核心系统，组织可以现代化其核心系统，从而降低拥有成本，自动化手工后勤流程，消除数据孤岛，改善客户体验，并更快地推出面向市场的新应用程序。

遗留系统现代化有许多好处，但可能非常复杂，需要大量努力。需要进行仔细评估，以采取正确的方法。让我们探讨一下遗留应用程序的评估技术。

查看遗留系统现代化技术

根据现有应用程序分析，您可以采取各种方法来升级您的遗留系统。最直接的方法是迁移和再托管，您无需更改现有系统。然而，简单的迁移可能无法解决长期问题或带来任何好处。

如果系统不再满足业务需求，您可以采取更复杂的方法，例如重新架构或重新设计整个应用程序。下图说明了各种方法的影响：

图 15.4：遗留系统现代化技术

让我们来看看前面图表中展示的各种现代化技术。

封装、再托管和再平台化

封装 是最直接的方法。如果系统对业务至关重要且需要与运行在最新技术上的其他应用程序通信，则应使用此方法。通过封装，您需要在遗留系统周围构建 API 包装器，允许其他业务应用程序与遗留应用程序通信。API 包装器是一种常见的方法，您可以开始将应用程序迁移到云端，但保留遗留应用程序在本地数据中心进行后续现代化。如果您的遗留代码编写良好且得到维护，您可以选择封装选项，但同样，您无法从技术进步和硬件灵活性中获益。

再托管 方法是其中最直接的策略之一，您可以将应用程序迁移到另一个硬件提供商（如 AWS 云），而无需进行任何代码更改。与封装一样，再托管选项可以通过供应商合同减少成本，但您可能无法从技术进步和硬件灵活性中获益。

组织通常在需要快速摆脱现有合同时采用这种方法。例如，你可以在第一阶段开始迁移到云端，并在第二阶段应用现代化。

重新平台化方法可能比重新托管方法更为复杂，但能够提供即时的收益。如果服务器已经达到 EOL（生命周期结束），无法获得支持，需要进行升级以处理安全问题，组织通常会选择这种方法。例如，如果 Windows Server 2012 即将达到 EOL，可以考虑将操作系统升级到 Windows Server 2022 版本。你需要使用新的操作系统重新构建二进制文件，并进行测试确保一切正常运行，但不会有重大的代码更改。同样，与重新托管类似，重新平台化可能无法享受技术进步带来的好处，但它将使你继续获得供应商的支持。

虽然前面提到的三种方法是最简单的，但它们无法提供应用程序升级的全部优势。让我们来看看一些能够帮助你充分利用应用程序现代化的方式。

重构与重新架构

你可以在重构方法中调整代码以适应新系统。重构后的整体架构保持不变，但你会升级代码以适应最新的编程语言和操作系统版本。你可以重构部分代码以实现自动化并增强功能。如果你的技术仍然相关，并且通过代码更改可以满足业务需求，那么你应该选择这种方法。

在重新架构方法中，你通过尽可能重新利用现有代码来改变系统架构。例如，你可以从单体架构创建微服务架构。你可以一次性迁移一个模块，将其转化为面向服务的架构，并为每个模块提供一个 RESTful 接口。重新架构有助于你实现所需的可扩展性和可靠性；然而，由于仍然使用现有代码，整体性能可能会较为一般。

重设计与替换

重设计方法是最复杂的，但能够提供最大的收益。如果遗留系统需要更新且无法满足业务需求，可以选择这种方法。通过重设计，你必须从头开始构建整个系统，同时保持整体范围不变。

以下图示展示了遗留大型主机系统迁移到 AWS 云端的过程：

图 15.5：遗留大型主机系统现代化到云端

传统主机系统经过重新架构和重构，转变为类似的云服务，作为现代化方法。构建云原生应用程序有助于你在可扩展性、性能、可靠性和成本等方面充分利用并从云服务中受益。它帮助你的团队更加灵活和创新，能够适应系统中迅速变化的技术。你在第三章，云迁移与混合云架构设计中学习了云迁移策略和其带来的好处。

重新设计一个传统系统需要长期的项目投入，伴随着大量的工作量和增加的成本。在启动现代化之前，作为解决方案架构师，你应当仔细分析是否有任何 SaaS 产品或商业现成产品（COTS）能够以较低的成本满足你的业务需求。在进行重新设计选项之前，进行重新设计与购买之间的成本效益分析（CBA）是至关重要的。

有时，替代传统系统以新的第三方软件更为有利。例如，你的组织可能拥有一个已有十年历史的客户关系管理（CRM）系统，它无法扩展并提供所需的功能。你可以订阅像 Salesforce CRM 这样的 SaaS 产品来替代传统系统。SaaS 产品是基于订阅的，并提供按用户计算的许可，因此如果你的用户较少，它们可能是合适的选择。对于一个拥有成千上万用户的大型企业，构建应用可能更具成本效益。你应该进行 CBA 以了解投资 SaaS 产品的投资回报率。我们来简要看一下云迁移策略。

为传统系统定义云迁移策略

随着云计算的日益普及，越来越多的组织希望将其传统应用迁移到云端以满足现代化需求。你在第三章，云迁移与混合云架构设计中学习了各种云迁移技术。云计算让你在保持低成本的同时扩展应用，并帮助你实现理想的性能、高可用性和可靠性，同时保障应用的安全性。

云服务提供商，如 AWS、微软 Azure 和 GCP，提供了许多帮助你现代化系统的选项。例如，你可以采用无服务器方法，利用 AWS Lambda 和 Amazon API Gateway 构建微服务，并以 Amazon DynamoDB 作为后端。

在上一节中，我们讨论了各种传统系统现代化技术及其在迁移到云端过程中的应用。下面的图表所示的流程将帮助你决定是否采用云迁移来现代化你的传统应用：

图 15.6：传统系统现代化的云迁移路径

如前图所示，如果你的应用程序仍然被业务大量使用并创造收入，你应继续保持最小的变更。在这种情况下，如果服务器即将结束生命周期，你可以将应用程序重构到云端，或者将其重新平台化。

如果你希望保持现有应用程序不变以支持业务，并且仍然希望完全迁移到云端以节省和优化成本，那么可以采用 提升与转移策略 将传统应用程序重新托管到云端。如果你的传统应用程序可以替代，你可以购买云原生的 SaaS 版本并淘汰旧的应用程序。如果传统系统存在过多的业务依赖，并且由于不兼容无法迁移到云端，你可能会选择将其保留在本地数据中心。

你应该进行 总体拥有成本（TCO）分析，以了解迁移到云端的优势。分析内容包括：

• 基础设施费用：比较本地基础设施的费用，包括服务器、存储、网络和数据中心设施费用，和云服务的费用。

• 维护和管理成本：考虑与维护和管理本地基础设施相关的费用，例如 IT 员工薪资，与云端托管服务相比，后者减少了对内部管理的需求。

• 可扩展性和灵活性：评估云端根据需求调整资源的能力所带来的成本影响，相比于固定成本的本地基础设施，这可能会带来成本节省。

• 许可和订阅费用：包括软件许可费用和云服务订阅费用。

• 迁移费用：考虑迁移工作负载到云端的单次费用，包括数据传输费用、工具费用以及可能的停机时间。

• 安全性和合规性：评估在本地环境和云端实现和维护安全性与合规性标准的费用。

建议选择传统应用程序中最复杂的模块，构建一个 POC，以确保在启动整个项目之前，您的系统能够与云端兼容。涵盖关键业务案例的详细 POC 将帮助你识别差距并显著降低迁移风险。

在评估云兼容性时，应该考虑几个关键因素。首先，评估架构的适配性，确保应用程序的设计符合云计算原则，如可扩展性、弹性和解耦性。接下来，识别是否存在对特定硬件或本地资源的依赖，而这些资源在云环境中可能无法得到最佳支持。还需要确认云环境是否能够满足应用程序的性能要求，考虑到诸如网络延迟和资源可用性等因素。此外，确保应用程序的安全性和合规性要求能够在云中得到充分满足。最后，评估迁移到云端的成本效益，确保其与组织的财务目标一致。这种全面的方法有助于确定应用程序是否适合云环境，从而为迁移决策提供依据。

文档和支持是任何应用程序维护的重要组成部分。让我们深入了解它们。

文档和支持

为新系统的长期可持续性和顺利迁移准备适当的文档和支持。提供符合大家可以遵循的编码标准文档，帮助保持新系统的最新状态。将架构文档作为工作文档，随着技术趋势的变化，保持它们的更新。保持系统更新将确保你避免再次面临遗留系统现代化的问题。

准备一个全面的运行手册，以支持新旧系统。你可以保留旧系统一段时间，直到新系统能够满足所有业务需求并正常运行。更新支持运行手册，确保你不会因员工流失而失去知识，且整体知识库不以依赖人员的方式运作。

跟踪系统依赖关系有助于你确定未来任何更改的影响。你将会在第十六章，解决方案架构文档中学到更多关于文档的内容。准备培训内容，培训员工掌握新系统，并确保他们能够在发生操作故障时提供支持。

主机是许多组织仍在本地运行的遗留工作负载之一。让我们来了解一下如何将它们迁移到云端。

公有云下的主机迁移

许多企业正在将他们的大型主机工作负载迁移到云端，以利用成本降低、提高灵活性、减少技术债务、支持数字化战略、解决遗留的主机技能差距以及数据分析。与基于 x86 的工作负载相比，大型主机工作负载的迁移更具挑战性，因为遗留的主机应用程序通常是紧密耦合的方式开发和部署的。例如，一个大型主机应用程序可能包含多个子系统使用的程序，或者直接被其他应用程序调用。在这些情况下，对底层程序所做的更改也会影响相关的子系统和应用程序。

从大型主机系统迁移到云端提供了一个独特的机会，尽管云服务商可能不支持完全相同的主机硬件架构。对于组织来说，这一过渡涉及战略性选择：他们可以在 x86 平台上模拟主机环境，或者重新构建他们的应用程序以实现与 x86 的兼容性。虽然重新构建需要更多的前期投资，但它为云中的可扩展应用环境铺平了道路，最终与数字化转型目标对接，并推动创新。

对于遗留应用程序，必须采取增量方式进行迁移，这是最佳实践。这种方法有助于降低风险，因为您可以选择并优先考虑紧密相关的应用程序一起迁移。然而，对于主机迁移，这种方法有时可能更复杂，因为主机应用程序代码可能使用时间耦合（同步调用）或部署耦合（链接模块）。

让我们来看看在主机迁移过程中可能面临的一些独特挑战。

大型主机现代化的挑战

现代化大型主机面临着独特的挑战，原因在于它们的规模、复杂性以及它们常常运行的关键应用程序。这些系统通常使用过时的编程语言，具有复杂且未记录的依赖关系，并且需要越来越稀缺的专业知识。以下是一些主要挑战：

• 过时的编程语言：大型主机通常运行在使用较老编程语言的遗留代码库上，而现代 IT 专业人员可能对这些语言不太熟悉。

• 复杂的系统依赖关系：许多大型主机应用程序经历了数十年的发展，具有复杂且未记录的依赖关系，这使得在不破坏功能的情况下解开并现代化它们变得困难。

• 专业知识要求：操作和维护大型主机系统所需的专业知识正变得稀缺，因为熟悉这些旧技术的员工正逐步退休。

• 数据完整性和安全性：在现代化过程中，维护数据的完整性和安全性至关重要，而在从封闭的安全大型主机环境迁移到更加开放的系统时，这一任务可能变得更加具有挑战性。

• 业务连续性风险：主机通常管理着关键的业务操作。现代化工作必须小心规划，以避免中断这些对业务至关重要的过程。

• 与现代技术的集成：将主机应用程序与更新的基于云的服务和技术集成可能会变得复杂，因为它们具有不同的架构和通信协议。

• 扩展性挑战：将主机应用程序适应现代云环境，特别是这些应用程序通常未设计为支持水平扩展，而云环境中的弹性扩展已成为常态。

• 成本影响：评估并证明现代化所需的财务投资是合理的，特别是在短期内，这笔投资可能非常庞大。

• 性能考虑：确保现代化系统在性能上与高度优化的主机系统相当或有所提升。

• 文化与组织的抵触：您可能需要克服组织内部的抗拒，因为主机系统深深嵌入了公司的运营结构中，变革可能会引发习惯于现有系统的利益相关者的忧虑。

在过渡过程中确保数据的完整性和安全性也是一个重大问题，尤其是在主机通常处理核心业务流程的情况下，存在中断业务运营的风险。

迁移耦合的应用程序代码会影响到依赖的应用程序，并且会带来一定的风险。为减少这些风险，您可以在不影响依赖应用程序的情况下，解耦主机应用程序代码。从代码迁移的角度来看，主要有两种类型的遗留主机应用程序：独立应用程序和共享代码的应用程序。让我们详细了解每种迁移模式。

迁移独立应用程序

假设有两个独立的应用程序 A 和 B，它们是独立的主机应用程序。每个应用程序由它独有的程序和子程序组成。

由于应用程序是自包含的，您可以按照应用程序将COBOL程序和子程序分组进行代码重构，如下图所示。

图 15.7：独立应用程序的主机现代化

在前面的图示中，主机程序和子程序是用 COBOL 编写的，代码迁移到了 AWS 上的 Java。然而，您可以使用这些解耦模式，选择您偏好的编程语言进行迁移。迁移模式是遗留的自动重构，其中代码、数据和依赖关系会自动转换为现代编程语言、数据存储和框架，同时保证与相同业务功能的功能等效性。重构涉及使用自动化工具将主机编程语言（如 COBOL）转换为现代编程语言（如 Java 或.NET）。

重构后的应用程序部署在由 AWS Fargate 提供和管理的容器中。Fargate 是一个无服务器容器计算引擎，可与 Amazon Elastic Container Service (ECS) 和 Amazon Elastic Kubernetes Service (EKS) 配合使用。在此，主机数据库表和主机文件与应用程序一起迁移。

分组后，你可以在同一波次或不同波次中迁移应用程序 A 和 B。无论哪种情况，都将每个应用程序的重构现代组件打包，并一起部署到运行时环境中。迁移后，退役本地主机应用程序及其组件。接下来，让我们看一下多个应用程序共享代码的更复杂场景。

迁移具有共享代码的应用程序

假设主机应用程序 A 和 B 运行共享代码程序 AB。你需要对共享程序 AB 进行影响分析，以便一起迁移应用程序 A 和 B 以及程序 AB。根据影响分析，确定使用共享程序（如程序 AB）的依赖应用程序数量。你需要完成业务领域分析，判断是否可以将共享程序聚合到包含应用程序的领域中，并作为领域服务之一暴露为 API。接下来，让我们看一下你可以采取的一些方法来解耦应用程序，为迁移做好准备。

使用独立 API 解耦应用程序

使用这种方法，你通过将共享的 COBOL 程序 AB 转换为 Java 程序来实例化独立的 API。你可以使用提供的自动化重构工具生成该程序的网络 API，以尽量减少重构工作量。当共享程序可以作为独立服务实例化时，你可以采用这种方法。应用程序 A 和 B 的其他组件将被重构为 Java 并迁移到云端。你可以在同一波次中迁移应用程序，具体如以下图所示：

图 15.8：使用独立 API 迁移共享程序应用程序

在这种方法中，你必须重构两个应用程序及其各自的程序，并将它们迁移到云端。你需要使用分析阶段的影响分析报告，帮助开发人员和团队识别调用共享程序 AB 的重构应用程序。用网络 API 调用替换内部程序调用。迁移后，退役本地主机应用程序及其组件。

使用共享库解耦应用程序

共享程序 AB 被转换为 Java 标准库，并与迁移应用程序一起打包。在这种方法中，当共享程序是支持库而不是独立服务时，应该采用此方法。应用程序 A 和 B 的其余组件被重构为 Java 程序并迁移到云端。

这种方法将应用程序 A 和 B 及其相关程序重构为 Java，并迁移到云端。您应该将应用程序的源代码保存在完全托管的源代码控制服务中，例如 AWS CodeCommit。使用共享程序的团队可以通过拉取请求、分支和合并来协作进行代码更改，并控制对共享程序代码所做的更改。迁移完成后，停用本地主机应用程序及其组件。

当应用程序过大，无法归入同一迁移波次时，您可以将其分成多个波次迁移，并在迁移过程中保持服务连续性。采用这种方法，您可以分阶段地现代化应用程序，而无需将它们捆绑在一起。将应用程序分波次迁移，能够解耦它们，而不需要对主机上的代码做出重大修改。

使用消息队列进行应用程序解耦

在这种方法中，共享程序 AB 被转换为 Java 程序，并作为应用程序 A 的一部分迁移到云端。使用消息队列作为云端重构应用程序和本地遗留应用程序之间的接口。采用这种方法，您可以将紧密耦合的大型主机应用程序拆分为生产者和消费者，并使其更加模块化，从而独立运行。额外的优势是，您可以分波次迁移这些应用程序。

当主机上的应用程序能够通过消息队列与迁移到云端的应用程序通信时，您可以采用这种方法。最佳做法是确保排队架构模式满足主机应用程序的业务需求，因为这涉及到重新架构现有的应用程序。

如果不属于第一波迁移的应用程序需要更长时间（六个月或更长时间）才能迁移到云端，则应该采用消息队列方法。当应用程序过大，无法归入同一迁移波次时，您可以将其分成多个波次迁移，如下图所示，并在迁移过程中保持服务连续性。

图 15.9：使用消息队列迁移共享程序应用程序

如前图所示，您需要遵循以下步骤进行迁移：

1. 将应用程序 A 及其相关程序迁移（重构）到云端，同时应用程序 B 继续保留在本地。

2. 重构应用程序 A（在云端），通过消息队列与应用程序 B（本地）进行通信。

3. 在本地重构应用程序 B，用代理程序替换共享程序，通过消息队列发送和接收来自应用程序 A 的消息。

4. 在成功迁移应用程序 A 之后，退役本地应用程序 A 及其组件（包括共享程序）。应用程序 B 及其组件将继续保留在本地。

5. 在下一波迁移过程中，迁移应用程序 B 及其组件。松耦合的队列架构继续在云中作为应用程序 A 和 B 之间的接口。这减少了对应用程序 B 的重构工作，而不影响应用程序 A。

作为最佳实践，您应该执行代码分析，以生成主机应用程序的依赖关系图，并识别由应用程序共享的程序列表。之后，将共享相同程序的应用程序分组在同一迁移波次中，以减少本地环境与云之间的程序调用。在规划阶段，进行影响分析，识别与您计划迁移的应用程序共享程序的应用程序，并选择适合的解耦模式进行应用程序迁移。在本节中，您会注意到我们使用了 AWS 的示例来进行主机现代化。让我们详细了解公共云对主机现代化的好处。

使用公共云进行主机现代化的好处

利用公共云进行主机现代化带来了众多好处，例如增强的可扩展性、灵活性和成本节省。云的按需付费模式降低了资本支出，而其先进的服务促进了创新，尤其是在人工智能（AI）、机器学习（ML）和分析等领域。云环境还提供了更强的灾难恢复能力，并有机会重新设计应用程序，使其更具弹性，能够适应不断变化的业务需求。让我们看看公共云迁移主机工作负载的一些关键好处：

• 增强的可扩展性：云平台能够自动调整资源以应对工作负载峰值，这与需要手动扩展的主机不同。例如，电商网站能够在假日购物高峰期间应对流量峰值，而不会出现停机。

• 成本效益：借助云的按需付费模式，公司可以节省高昂的前期硬件和维护成本。例如，初创公司可以在无需投资昂贵的主机基础设施的情况下启动新的应用程序。

• 灵活性和敏捷性：云服务使企业能够快速实验和部署新应用程序。例如，一家公司可以迅速在不同市场测试一个新的客户服务应用，而无需经过长时间的设置过程。

• 创新加速：云服务提供商提供尖端的人工智能（AI）、机器学习（ML）和分析工具。零售企业可以利用这些工具分析消费者数据并个性化营销策略，这些都可以在传统主机上得到提升。

• 改进的灾难恢复：云平台具有内置的冗余和备份解决方案。例如，金融机构即使在本地发生灾难时，也能确保持续运行和数据完整性。

• 资源优化：云使计算资源的使用更加高效。一家公司可能只在需要时使用云服务来运行应用程序，从而减少了主机环境中常见的空闲计算资源。

• 更快的市场响应时间：云的灵活性缩短了开发周期。移动应用开发者可以迅速部署和更新应用，保持在竞争激烈的市场中的领先地位。

• 全球覆盖：凭借全球范围的数据中心，云服务使企业能够将应用程序部署在离用户更近的地方。例如，在线流媒体服务可以向全球用户提供低延迟的内容。

• 更好的安全特性：主要云服务提供商在网络安全上投入大量资金。这意味着小型企业可以享受到与大型企业相当的安全措施，而这些在本地主机环境中是难以实现的。

• 更容易与现代技术集成：云简化了与现代应用程序和服务的集成。例如，医疗保健提供商可以将基于云的 AI 诊断工具与其患者管理系统集成，而在主机环境中，这一任务将复杂且资源密集。

AWS 提供了主机现代化（M2）平台，旨在将本地主机应用程序迁移并现代化为 AWS 上的云原生、完全托管的运行时环境。以下是 AWS M2 平台的关键特性：

• 自动化重构：使用 AWS Blu Age 将遗留语言应用程序转变为灵活的基于 Java 的服务，遵循现代 Web 框架和云 DevOps 最佳实践。

• 重新平台化：使用集成的 Micro Focus 工具链迁移 COBOL 应用程序，现代化基础设施，同时保持编程语言以实现 DevOps 云原生操作的灵活性。

• 数据复制与文件传输：通过精准的数据实时复制和 BMC 软件的文件传输能力，增强主机功能。

• 应用程序测试：通过自动化现代化主机应用程序的验证，降低成本，并利用可扩展的云原生服务加速测试进程。

本服务与日益增长的遗留系统现代化需求相契合，为企业从传统主机基础设施过渡到更加灵活、具有成本效益的云环境提供了全面的解决方案。你可以通过参考此 AWS 页面了解更多：aws.amazon.com/mainframe-modernization/。

如果可能，逐步进行大型机迁移，以减少复杂性和风险。通过增量迁移，迁移团队能够更快地提供有关迁移进度的反馈，企业可以利用这些反馈来优化内部流程，从而加快迁移的步伐。随着 GenAI 变得越来越流行，并提供许多现成的解决方案，它可以帮助加速你的现代化进程。让我们深入了解一下。

使用生成式人工智能现代化遗留代码

使用生成式人工智能（GenAI）现代化遗留代码代表了一种前沿的软件开发方法。GenAI 工具可以分析并理解遗留代码，通常是用过时的编程语言编写的，并协助将其重写或转换为现代、更高效的编程语言或框架。这一过程加速了代码现代化，同时有助于在利用当前技术优势的同时保持遗留系统的功能。

通过自动化部分代码转换过程，GenAI 减少了所需的人工工作量和专业知识，使得现代化过程更加容易接近且不易出错。这一方法主要有利于那些希望在不打乱运营效率的情况下更新遗留系统的企业。使用 GenAI 现代化遗留代码涉及到如 Codex 这样的工具，Codex 是 OpenAI 提供的工具之一（它为 GitHub Copilot 提供支持），以及可能的基础模型。这些工具利用 AI 来理解和重构遗留代码，转换为更现代、高效的编程语言或框架。例如，Codex 可以解析较旧的、较少使用的编程语言，并提供建议或直接将其转换为更新的语言，如 Python 或 JavaScript。这有助于更新遗留系统，使其更加易于维护，并与当前的开发实践兼容。

类似地，Amazon CodeWhisperer 是 AWS 的 AI 驱动编码助手。像 GitHub Copilot 一样，它通过提供代码建议和自动化某些编码任务来帮助开发人员。CodeWhisperer 利用机器学习模型理解代码的上下文，并提供相关的推荐。这款工具可以提高开发人员的生产力，帮助编写最佳实践的代码，并通过建议现代的编码技术和解决方案来帮助现代化遗留代码。CodeWhisperer 集成到开发人员的工作流程中，能够显著简化维护、更新和优化代码库的过程，包括遗留系统的翻译或重构。CodeWhisperer 还提供上下文推荐，确保代码库重用和编码模式的一致性。

此外，基础模型通过在多个领域的多样化数据上进行训练，可以帮助理解复杂的遗留代码库，识别冗余或低效的代码段，并建议优化或现代的编码模式。

将这些工具整合到现代化过程中能够加速遗留代码的转化。这有助于构建更易维护、可扩展和安全的软件系统，对于那些希望在快速发展的数字化环境中保持竞争力的企业来说至关重要。

摘要

在这一章中，你了解了遗留应用程序面临的各种挑战，以及为什么它们需要进行现代化。你了解了通过将应用程序升级到最新技术，组织可以获得的好处。应用程序现代化可能复杂且充满风险，但它通常是值得的。

从升级中获得的结果是你所投入的投资和精力的权衡。在定义现代化方法之前，彻底了解你的遗留系统至关重要，你学习了应用程序在技术、架构和代码方面的各种评估属性。

在评估之后，下一步是定义现代化方法，你了解了多种现代化方法，包括以架构为驱动的、系统重构和迁移方法。你还了解了系统现代化的多种技术，包括直接方法（封装和重托管）和复杂方法（重新架构和重新设计）。云计算可以提供显著的价值主张，你还学习了在云端进行现代化时需要采用的决策方法。你了解了大型机现代化的挑战，以及云计算如何帮助简化大型机现代化的过程。最后，你学习了 GenAI 如何通过作为编码助手更新遗留代码来提高开发者效率。

你专注于解决方案架构的各个技术方面；然而，文档是架构设计中至关重要的元素之一，它能使你的系统在长期内保持可维护性。下一章将讨论解决方案架构师需要准备、参与和维护的文档，以实现最大的业务价值。

加入我们书籍的 Discord 空间

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

第十六章：解决方案架构文档

在前几章中，你学习了解决方案架构设计和优化的各个方面。当解决方案架构师进行设计时，与其他利益相关者保持一致的沟通至关重要，以确保应用程序的成功交付。解决方案架构师必须将设计传达给所有技术和非技术利益相关者。

解决方案架构文档（SAD）提供了应用程序的端到端视图，帮助所有人保持一致。在本章中，你将了解 SAD 的各个方面，SAD 解决了与应用程序开发相关的所有利益相关者的需求。

你将学习 SAD 的结构以及解决方案架构师需要了解的其他类型文档，例如提案请求（RFP），在其中解决方案架构师需要提供输入以做出战略决策。我们将涵盖以下主题，以深入了解涉及解决方案架构的文档：

• SAD 的目的

• SAD 的视图

• SAD 的结构

• SAD 的生命周期

• SAD 最佳实践和常见的陷阱

• 解决方案架构的 IT 采购文档

在本章结束时，你将了解 SAD、其结构以及文档中需要包含的各种细节。你将学习各种 IT 采购文档，如提案请求（RFP）、信息请求（RFI）和报价请求（RFQ），在这些文档中，解决方案架构师参与并提供反馈。让我们从 SAD 的目的开始，了解其基本内容。

SAD 的目的

通常情况下，架构文档需求没有得到解决，团队在没有理解整体架构的情况下就开始实施。SAD 提供了整个解决方案设计的广泛视图，以便让所有利益相关者保持知情。

SAD 对各方利益相关者至关重要，包括项目经理，他们依赖 SAD 来监督项目协调和进度。业务分析师用它来将项目与业务需求对齐。技术团队，包括开发人员和 IT 专业人士，参考它来实施和维护提议的解决方案。高级管理层利用该文档做出明智的战略决策。最后，客户或最终用户作为最终受益人，依赖该文档来确保项目结果符合他们的需求和期望。

SAD 有助于实现以下目标：

• 向所有利益相关者传达端到端的应用程序解决方案。

• 提供架构的高层次概述和应用程序设计的不同视图，以满足应用程序的服务质量要求，如可靠性、安全性、性能和可扩展性。

• 提供解决方案与业务需求之间的可追溯性，并审视应用程序如何满足所有功能性和非功能性需求（NFRs）。

• 提供设计、构建、测试和实施所需的所有解决方案视图。

• 定义解决方案对估算、规划和交付的影响。

• 定义解决方案在生产发布后能够持续运作所需的业务流程、延续性和操作。

SAD 定义了解决方案的目的和目标，并涉及关键组件，如解决方案的约束、假设以及常常被实施团队忽视的风险。解决方案架构师必须确保文档使用简明的语言，便于业务用户理解，并将业务背景与技术设计关联起来。文档有助于保留知识，以防资源流失，使整个设计过程不依赖于特定人员。

对于需要现代化的现有应用程序，SAD 展示了当前和未来架构的抽象视图以及过渡计划。解决方案架构师需要了解现有系统的依赖关系，并记录下来，以便提前发现潜在的风险。迁移计划帮助企业了解处理新系统所需的工具和技术，并据此规划资源。

解决方案架构师在解决方案设计过程中，通过构建概念验证（POC）或进行市场调研，开展各种评估。SAD 应列出所有架构评估及其影响，并包括技术选择。SAD 展示了解决方案设计当前状态和目标状态的概念性视图，并保持变更记录。接下来，我们将了解 SAD 的各个视图。

SAD 的视图

解决方案架构师需要创建一个既能让业务用户也能让技术用户理解的 SAD。SAD 弥合了业务用户与开发团队之间的沟通鸿沟，使他们理解整体应用程序的功能。捕获所有利益相关者意见的最佳方式是将自己置于他们的位置，从利益相关者的角度看待问题。解决方案架构师评估架构设计的业务和技术方面，以充分考虑所有技术和非技术用户需求。

如下图所示，SAD 的全面概述包括多个视图，涵盖从业务需求中衍生出的不同方面：

图 16.1：SAD 视图

解决方案架构师可以选择标准图表，如统一建模语言（UML）图表或Microsoft Visio中的框图来表示各种视图。这些工具被广泛认可，帮助将复杂的架构概念以易于理解的格式传达。总体来说，图表应易于阅读，且对所有业务和技术利益相关者可理解。SAD 应该包括以下视图，以尽可能满足每个人的需求：

• 业务视图：架构设计关注商业问题并解决商业目标。业务视图展示了整体解决方案和产品的价值主张。为了简化，解决方案架构师可能会选择识别与业务相关的高级场景，并将其呈现为用例图。业务视图还描述了项目执行所需的利益相关者和资源。你也可以将业务视图定义为用例视图。

• 逻辑视图：此视图展示系统中的各种包，以便业务用户和设计师理解系统中的各个逻辑组件。逻辑视图提供了系统构建的时间顺序。它展示了系统中多个包是如何连接的，以及用户如何与它们交互。例如，在银行应用程序中，用户首先需要使用安全包进行身份验证和授权，使用账户包登录账户，使用贷款包申请贷款，等等。每个包代表不同的模块，可以作为微服务构建。

• 过程视图：此视图展示了更多细节，展示系统的关键过程如何协同工作。可以使用状态图来反映这一点。解决方案架构师可以创建一个序列图，展示更多细节。在银行应用程序中，过程视图可以展示贷款或账户的审批过程。

• 部署视图：此视图展示了应用程序在生产环境中的工作方式。它显示了系统组件（如网络防火墙、负载均衡器、应用服务器和数据库）之间的连接方式。解决方案架构师应创建一个简洁的框图，便于业务用户理解。你可以向 UML 部署图中添加更多细节，向技术用户（如开发和 DevOps 团队）展示各种节点组件及其依赖关系。部署视图表示系统的物理布局。

• 实现视图：这是 SAD 的核心，表示架构和技术选择。解决方案架构师需要在此处放置架构图——例如，如果是 3 层、N层或事件驱动架构，并附上其理由。

• 您还应该详细说明技术选择——例如，使用 Java 与 Node.js 的优缺点。在实现视图中，您需要证明执行项目所需的资源和技能。开发团队利用实现视图创建详细设计，例如类图，但这不需要包含在 SAD 中。

• 数据视图：大多数应用程序是数据驱动的，因此数据视图至关重要。数据视图展示了数据如何在不同组件之间流动，以及如何存储。它还可以用于解释数据安全性和数据完整性。解决方案架构师可以使用实体关系图来展示数据库中不同表和模式之间的关系。您将在数据架构部分进一步了解实体关系图。数据视图还解释了所需的报告和分析。

• 操作视图：这部分解释了系统在上线后的维护方式。通常，您会定义服务级别协议（SLA）、警报和监控功能、灾难恢复计划以及系统支持计划。操作视图还详细说明了系统维护的执行方式，例如通过部署错误修复、打补丁、备份与恢复、以及处理安全事件等。

所有列出的视图确保 SAD 覆盖了系统和利益相关者的各个方面。您还可以根据利益相关者的需求，添加其他视图——例如，物理架构视图、网络架构视图或安全（控制）架构视图。作为解决方案架构师，您必须以全面的方式来看待并理解系统的功能。接下来我们将在下一部分深入探讨 SAD 的结构。

SAD 的结构

SAD 的结构可以根据项目的利益相关者需求和项目的性质有所不同。您的项目可能是从头开始创建新产品，现代化一个遗留应用，或者将整个系统迁移到云端。

每个项目的 SAD 文档可能有所不同，但总体上，它应考虑各种利益相关者的观点，并包括如下截图所示的多个部分：

图 16.2：SAD 的结构

在前面的 SAD 结构中，您可以看到涵盖多个解决方案架构和设计方面的不同部分。解决方案架构师可以根据项目需求选择添加额外的小节或删除某些部分。例如，您可以添加另一个介绍部分，讨论文档的目的和总结。对于过渡项目，您可能会添加一个小节，展示现有架构，并与目标架构进行对比，等等。接下来我们来详细了解每个部分的内容。

解决方案概述

在解决方案概述部分，我们简要介绍了解决方案，并在几个段落中描述了其功能以及不同组件的高级概况。添加一个显示各种组件的高级框图会很好。下图展示了一个电子商务平台的解决方案概述：

图 16.3：电子商务平台解决方案概述

你需要用简化的语言提供每个组件的简介，以便业务用户能够理解解决方案的整体运作。例如，上面的图示简单地概述了一个典型的电子商务订单和供应链管理流程：

• 客户订单：

  • 该流程始于客户通过网站或在线市场下单。

  • 客户服务在协助客户下单、处理咨询以及解决订单过程中可能出现的问题方面发挥着重要作用。

• 供应链与订单管理：

  • 销售订单：一旦下单，订单将被记录为销售订单，并触发订单履行过程。

  • 库存数据：系统检查库存数据，以确保所订商品有货。

  • 发货通知：订单处理完毕并准备好发货后，系统会发送通知，可能包括客户的跟踪信息。

• 订单处理：

  • 付款：处理客户的付款，包括税费的计算和促销代码的处理。

  • 税费：根据客户所在位置和购买商品计算并应用正确的销售税。

  • 运输：安排物流将订单送达客户指定位置。

  • 订单履行：实际的拣货、包装及准备发货的过程。

  • 发货：将订单送出并准备交付的过程。

  • 促销：应用可能包含在销售订单中的折扣或特别优惠。

  • 通知：向客户提供订单状态更新，确保其知晓订单进展。

  • 退货：处理客户不满意购买或订单有问题时的退货事宜。

  • 取消：处理客户决定在发货前取消订单的情况。

这些元素使客户订单能够从下单到交付的整个过程得到高效处理。

接下来，我们通过以下子章节概述解决方案概况：

• 解决方案目的：这一部分简要概述了该解决方案将解决的业务问题及构建此解决方案的理由。在我们之前提到的场景中，解决方案的目的是简化并自动化供应链内的订单管理流程。它旨在解决有关订单履行中的效率、准确性和客户满意度等业务关注点。

• 解决方案范围：在这里会明确列出所提议解决方案的业务范围，清楚地描述解决方案不会涵盖的内容。该范围包括从客户下单到发货通知的订单管理系统的端到端自动化。它不包括交付后客户互动，如反馈收集或退货处理。

• 解决方案假设：列出解决方案架构师在提出解决方案时所做的所有假设。例如，在我们的场景中，解决方案假设网络带宽至少满足实时数据处理的需求。它还假设能够与各种市场平台、运输承运商进行集成，且客户能使用数字支付方式。

• 解决方案约束：列出所有技术、业务和资源的约束条件。通常，约束来自行业和政府的合规要求，这些内容需要在此部分列出。你还可以强调风险和应对计划。该解决方案必须遵守数据保护法规，如欧盟的 GDPR（通用数据保护条例）以保障客户数据隐私，以及美国的 PCI-DSS（支付卡行业数据安全标准）以保护客户的支付信息。资源约束包括固定的预算和部署时间表。也可能存在与遗留系统集成相关的技术约束。

• 解决方案依赖：列出所有上游和下游的依赖关系。例如，一个电子商务网站必须与运输系统（如 UPS 或 FedEx）进行通信，以将包裹运送给客户。该解决方案依赖于来自库存管理系统的实时库存数据，以确保准确的订单处理。它还需要与支付网关进行集成，以处理金融交易。

• 关键架构决策：列出重要的议题和拟定的解决方案。描述每个选项的优缺点，为什么选择某个决策，以及背后的理由。

例如，假设我们决定使用基于云的平台来实现可扩展性。选择它是因为它能够处理不同的订单量，并且需要较少的前期资本投资。权衡的结果是持续的运营开销。

另一个决策可能是采用 API 优先的方法进行集成。之所以选择这种方法，是为了确保灵活性并简化与各种合作伙伴和服务的集成。然而，这也增加了 API 管理的复杂性。

在提供了解决方案概述后，你需要将其与业务背景联系起来。在接下来的部分中，我们将更详细地查看业务背景视图。

业务背景

在业务上下文部分，解决方案架构师必须提供一个高层次的概述，说明解决方案将要解决的业务能力和需求。此部分仅包含需求的抽象视图。详细需求需要在单独的文档中提及和记录。然而，可以在此提供指向需求文档的外部链接。你应包括以下主要子部分：

• 业务能力：简要描述为该解决方案设计的业务能力。确保包含能力的好处以及它们如何满足客户需求。

• 关键业务需求：列出解决方案将要解决的所有关键业务问题。提供关键需求的高层次概述，并添加指向详细需求文档的参考。

• 关键业务流程：解决方案架构师应通过业务流程文档展示关键流程。下图展示了一个简化版的电子商务应用业务流程模型：

图 16.4：电子商务平台的业务流程图

• 业务利益相关者：列出直接或间接受项目影响的利益相关者。这包括赞助人、开发人员、最终用户、供应商和合作伙伴。

• NFRs：解决方案架构师必须更多关注 NFR（非功能性需求），因为这些需求通常会被业务用户和开发团队忽视。从高层次来看，NFR 应包括：

  • 可扩展性：随着工作负载波动，应用程序如何扩展？（例如，从每天或每月 1,000 笔交易扩展到 10,000 笔交易。）

  • 可用性和可靠性：系统可用性的可接受停机时间是多少？（例如，99.99%的可用性或每月 45 分钟的停机时间。）

  • 性能：性能要求是什么？系统在哪些地方可以处理负载增加而不影响最终用户体验？（例如，目录页面需要在 3 秒内加载。）

  • 可移植性：应用程序是否可以在多个平台上运行而无需额外工作？（例如，移动应用程序必须能够在 iOS 和 Android 操作系统上运行。）

  • 容量：应用程序可以处理的最大工作负载是多少？（例如，最大用户数、请求数、预期响应时间和预期应用负载。）

架构的概念视图是一个关键点，为业务和技术利益相关者提供了良好的系统概述。让我们更详细地了解概念视图。

概念解决方案概述

概念解决方案概述部分提供了一个抽象级别的图示，捕捉了整个解决方案的大局视图，包括其商业和技术方面。它为分析和权衡研究提供了基础，有助于在足够细节的层面上完善和优化解决方案架构，以支持解决方案设计和实施。以下图示展示了电子商务平台的概念架构图：

图 16.5：电子商务平台的概念架构图

上述图表展示了一个抽象视图，展示了重要模块及它们之间的信息流动。概念架构为商业用户和技术用户提供了对整体架构的良好理解。然而，技术用户需要更深入的架构细节。接下来我们将深入探讨解决方案架构。

解决方案架构

解决方案架构部分深入探讨了架构的各个部分。它提供了技术团队可以用来创建详细设计并进行实施的不同视图。这些视图可能面向其他用户群体，如开发人员、基础设施工程师、DevOps 工程师、安全工程师和用户体验（UX）设计师。

让我们进入以下主要子部分，了解更多细节。

信息架构

本节提供了应用程序的用户导航流。解决方案架构师需要在高层次上构建一个应用程序导航结构。如以下图示所示，对于一个电子商务网站，用户需要点击三次才能导航到目标页面：

图 16.6：电子商务平台的信息架构图

解决方案架构师可以添加更多细节，例如网站导航、分类法或 UX 设计师可以用来生成详细线框图的高层次线框图。

应用架构

本节面向开发团队。它为软件架构师或开发团队提供了更多的实施细节，以便构建详细设计。以下图示展示了一个电子商务网站的应用架构，包括缓存、网络、内容分发和数据存储等技术构建模块：

图 16.7：电子商务平台的应用架构图

如前所示，你需要列出云基础电子商务平台所需的应用架构组件，以提供理想的在线购物体验。这些组件包括：

• 用户交互： 客户通过 Web 界面与电子商务平台进行互动，首先通过安全套接层（SSL）进行加密通信的安全购买请求。

• 内容交付： 亚马逊 CloudFront，一个内容分发网络（CDN），高效地为用户提供静态内容，如图像、样式表和客户端脚本。通过将内容缓存到离用户位置更近的地方，减少了延迟。

• 域名系统（DNS）：亚马逊 Route 53 用于 DNS 管理，将用户请求导向最合适的终端，如 CloudFront 分发或应用负载均衡器。

• 应用处理： 在虚拟私有云（VPC）内部，电子商务应用服务处理动态请求，如基于用户个人资料和购物历史的页面渲染。VPC 内的产品推荐服务根据用户的行为和偏好，向用户提供个性化的产品建议。

• 缓存机制： 亚马逊 ElastiCache 被用于通过缓存频繁访问的数据，如会话状态和常看产品信息，加速数据检索。这减少了后端数据库的负担，并提高了应用程序的响应时间。

• 数据存储与处理： 购物车结算服务管理用户购物车交互和交易。目录和会话缓存数据存储以便快速访问。基于亚马逊 Elasticsearch 构建的搜索引擎提供强大的产品目录搜索功能。

• 用户资料和交易数据： 用户的资料信息以及交易数据存储在亚马逊 DynamoDB 中，提供快速和可扩展的 NoSQL 数据库功能。

• 数据日志： 亚马逊 S3 用于记录数据，如点击流数据、产品互动和系统日志，便于深入分析和洞察用户行为及系统性能。

本部分列出了所有需要退役、保留、重新平台化和转换的应用模块，以适应应用现代化架构。

数据架构

本部分主要由数据库管理员和开发团队使用，以了解数据库模式及表之间的关系。此部分通常包括一个实体关系图（ERD），展示数据库中存储的实体集之间的关系，如下所示：

图 16.8：电子商务平台的 ERD

实体关系图（ERD）是实体（通常对应数据库表）及其之间关系的可视化表示。它是数据库设计中用来说明数据库逻辑结构的图形工具。上面的图示是一个订单处理系统的 ERD 示例。该 ERD 展示了发生的事件与系统内处理的订单之间的关系。以下是组件及其关系：

• 事件实体：表示系统中的某个事件或操作，具有Event_ID（主键）、Event_Type、Event_Name和Event_Loc等属性。这些属性可能描述事件的类型、发生地点以及其他特征。

• 订单实体：表示客户订单，包含Order_ID（主键）、Order_Number、Order_Type、Order_Quantity、Order_Date和Ship_Address等属性。这些属性存储与每个订单相关的信息，如订购数量、运输详情和订单下单时间。

• 订单处理实体：这是一个关联实体（或连接表），用于将事件与订单连接，表示一个事件将导致订单处理。它有自己的主键（Processing_EventID），并包含外键Event_ID和Order_ID，分别与事件和订单实体相连接。Order_Event_date属性的存在表明，它还记录了事件导致订单处理的时间。

实体之间的连线表示关系。在此 ERD 中，关系线的“乌鸦脚”符号表示“多”，而单线表示“一个”，表示关系的基数。

数据架构部分列出了在应用开发过程中需要考虑的所有数据对象。

集成架构

集成架构是指扩展的框架，使得不同的软件应用、系统和服务能够有效地进行通信与协作。它涉及设计和实现促进数据和流程在组织内或组织与外部各方之间交换的方法和中间件。本节主要面向供应商、合作伙伴和其他团队。例如，以下图示展示了电子商务应用程序与其他系统的所有集成点：

图 16.9：电子商务平台的集成架构图

集成架构部分列出了所有向您的应用程序提供数据的上游系统。任何您的应用程序接收数据的平台、服务或数据库都在此列出，并附上数据流的性质以及您的应用程序向下游系统发送数据的详细信息。这些下游系统可能包括其他应用程序、数据库或服务，这些系统依赖于您的应用程序生成或处理的数据。您需要列出所有关于应用程序的系统依赖关系。

基础设施架构

本节主要面向基础设施团队和系统工程师。解决方案架构师必须包括一份部署图，概述逻辑服务器位置及其依赖关系。

例如，以下图示展示了一个电子商务应用程序的生产部署图。你可以为其他环境（例如开发环境、质量保证（QA）和用户验收测试（UAT）环境）制作单独的图示：

图 16.10：电子商务平台的部署图

本节列出了部署应用程序所需的所有服务器配置、数据库、网络和交换机。

安全架构

本节包括应用程序的所有安全性和合规性方面，包括：

• 身份和访问管理（IAM），例如Active Directory（AD）、用户认证和授权管理

• 基础设施安全性，如防火墙配置、入侵防御系统（IPS）/入侵检测系统（IDS）和防病毒软件

• 应用程序安全性，如Web 应用防火墙（WAFs）和分布式拒绝服务（DDoS）防护

• 使用 SSL、加密算法、密钥管理等对数据安全进行保护，无论是在静态状态还是传输过程中

总体而言，解决方案架构师可以包括应用程序安全威胁模型，以识别潜在的漏洞，例如跨站脚本（XSS）和SQL 注入（SQLi），并规划保护应用程序免受任何安全威胁。

解决方案实施

解决方案交付部分包括开发和部署解决方案时需要考虑的关键事项。它可以包含以下主要子部分：

• 开发：本节对开发团队至关重要。它讨论了开发工具、编程语言、代码库、代码版本管理和分支策略，以及背后的选择依据。

• 部署：本节主要关注 DevOps 工程师，讨论部署方法、部署工具、各种部署组件和部署清单，以及背后的选择依据。

• 数据迁移：本节帮助团队理解数据迁移和摄取的方法、数据迁移的范围、各种数据对象、使用的数据摄取工具、数据来源和数据格式等。

• 应用退役：本节列出了需要退役的现有系统，并为当前系统提供了退出策略，如果投资回报（ROI）未实现。解决方案架构师必须提供退役旧系统的方法和时间表，并评估整体影响。

SAD 包括了开发方法和工具。然而，它没有详细的应用级设计，例如类图或伪代码。这些细节需要由软件架构师或高级开发人员在相应的软件应用详细设计文档中处理。随着解决方案的部署，它需要在生产环境中进行管理。让我们了解一下解决方案管理部分的详细内容。

解决方案管理

解决方案管理部分专注于生产支持和其他非产品环境中的系统维护。此部分涵盖了解决方案的运营方面，包括监控、事件管理、用户入职以及支持和恢复流程。解决方案管理部分主要面向运营管理团队。此部分涉及以下内容：

• 操作管理，如开发、测试、暂存和生产环境的系统修补和升级

• 管理应用程序升级和新版本的工具

• 管理系统基础设施的工具

• 系统监控和警报；操作仪表板

• 生产支持、SLA 和事件管理

• 灾难恢复和业务流程持续性（BPC）

解决方案架构师必须在设计过程中研究并收集数据，以验证正确的解决方案。这些额外的细节可以放在附录部分。让我们进一步了解 SAD 的附录部分。

附录

像所有商业提案文档一样，SAD（解决方案架构文档）也有一个开放的附录部分，其中包含支持整体架构和解决方案选择的任何数据。在此部分中，解决方案架构师可以包括未解决的问题以及任何研究数据，例如 POC 的结果、工具对比数据以及供应商和合作伙伴的数据。

关于 SAD 结构的这一部分为您提供了关于 SAD 结构及不同部分的良好概述。一个 SAD 应包括前面提到的主要部分；然而，解决方案架构师可以根据组织或项目的具体需求排除某些部分或加入其他部分。像其他文档一样，持续迭代 SAD 并寻找改进机会至关重要。更强大的 SAD 有助于制定明确的实施指南，减少任何失败的风险。

SAD 是一个在初始阶段创建并在应用程序生命周期中的各种变化基础上不断更新的文档。现在，让我们深入了解 SAD 的生命周期。

SAD 的生命周期

SAD 的生命周期与项目生命周期的不同阶段相一致。在本章之前，我们探讨了 SAD 的各个部分，这些部分在不同阶段创建。SAD 的生命周期通常包括以下几个阶段：

图 16.11：SAD 生命周期

让我们更详细地了解 SAD 生命周期中的各个阶段，如前面的图表所示：

1. 启动：启动阶段是在项目构思时，通常会意识到需要 SAD。此阶段定义了目标，例如为新企业应用程序概述软件架构。此步骤为文档设置了方向和范围，确保它与项目的目标和利益相关者的期望一致。

2. 需求收集：在这一关键阶段，从关键利益相关者处收集详细的需求。对于一个零售电商平台，这可能涉及收集关于用户体验、支付处理和库存管理的见解。此阶段确保 SAD 涵盖项目的所有关键方面。

3. 起草：起草阶段涉及创建 SAD 的初始版本。该文档可能会详细描述基于云的系统架构，指定某些 AWS 服务的使用、数据库模式以及安全协议。该草稿作为项目技术实施的蓝图。

4. 审查与反馈：草稿准备好后，会与利益相关者共享进行审查。例如，在医疗管理系统的情况下，临床医生、IT 人员和行政人员可能会就患者数据流和健康法规合规性等方面提供反馈。

5. 最终确定：在吸收反馈后，SAD 进入最终确定阶段。这可能涉及根据利益相关者的反馈调整网络架构，以提高数据流动效率。

6. 实施：最终确定的文档指导项目的实施。例如，开发人员和项目经理使用 SAD 来确保与软件开发项目中计划的架构和技术栈保持一致。

7. 维护：随着时间的推移，SAD 会被重新审视并更新，以反映技术变化、业务目标或外部因素。例如，推出新的数据隐私法律可能需要对 SAD 进行更新，以确保持续合规。

现在让我们来看看制定 SAD 时的一些最佳实践和需要避免的陷阱。

SAD 最佳实践与常见陷阱

有效管理 SAD 需要遵循某些最佳实践。保持文档简洁明了至关重要，使其易于理解，同时避免使用技术术语。定期让利益相关者参与过程，确保文档符合业务和技术需求。保持 SAD 与最新的项目变更和发展同步更新，对于其相关性和实用性非常重要。此外，将 SAD 中概述的架构与组织的更广泛业务目标对齐至关重要，确保提出的技术解决方案能够支持并增强业务目标。

在使用 SAD 时也有一些常见的陷阱需要避免。过度复杂化架构可能会导致实施和维护上的挑战。文档缺乏灵活性可能会妨碍其适应项目范围或目标变化的能力。利益相关者参与不足可能会导致与实际业务需求和要求的不匹配。

此外，不良的文档实践可能导致误解、实施错误以及项目执行中的挑战。积极解决这些问题对于确保解决方案架构的成功至关重要。

除了 SAD 之外，解决方案架构通常还涉及一个具有特定要求的重大采购提案，该要求被称为请求 x（RFx）文件。让我们来了解一下 RFx 文件。

解决方案架构的 IT 采购文档

IT 采购文件通常被称为RFx 文件。这是一个包含采购过程不同阶段的术语。RFx 指的是正式的请求过程。RFx 文件可以分为请求提案（RFP）、请求信息（RFI）和请求报价（RFQ）文件。

解决方案架构师通常参与采购过程，可能是领导这一过程，也可能是提供自己的建议。这些采购可能涉及外包、合同、采购数据库或开发工具等软件，或购买 SaaS 解决方案。

由于这些文件可能涉及高度技术性内容，并且可能会产生广泛且长期的影响，解决方案架构师需要通过回应任何采购要求来提供输入。

让我们了解不同 RFx 文件之间的区别：

• RFI：RFI 出现在采购过程的早期阶段，买方邀请不同的供应商提供信息，以便在后续采购阶段做出明智的决策。RFI 文件收集有关各供应商能力的信息，买方可以根据相似的参数对所有供应商进行比较，并从中筛选出供应商，进入下一步的提案环节。例如，假设一家公司正在探索市场，寻找符合其培训需求的学习管理系统（LMS）。该公司发布 RFI，收集关于 LMS 平台的功能、集成能力和用户体验的详细信息。

• RFP：在这个过程中，从 RFI 流程中筛选出的供应商将获得关于项目结果的更多信息。与 RFI 文件相比，RFP 文件更加开放，供应商可以提供最佳的方式来为买方获取解决方案。供应商可以包括多种选择，并列出每种方法的优缺点。例如，假设一个政府机构希望升级其 IT 基础设施。它发布了一份 RFP，概述了当前系统、所需改进和性能标准。供应商则响应并提交包括技术解决方案、项目时间表和成本估算的提案。

• RFQ：在这个过程中，买方将与 RFP 相比缩小要求范围，列出工作的具体需求、设备和供应品。供应商必须为列出的需求提供报价，买方可以选择最佳报价来授予合同。例如，假设一家技术初创公司正在准备扩展其 IT 基础设施，以适应日益增长的用户群。

启动公司需要采购额外的云计算资源以应对增加的负载。公司已经确定了在计算实例、内存、存储和带宽方面的需求。RFQ 要求 IT 基础设施提供商提交月度和年度定价选项的最佳报价，以及长期承诺的折扣。启动公司还要求提供额外服务的信息，如支持、监控和安全功能，这些可以包括在报价中。

RFP 是最常见的选择，因为为了加速过程，买方组织通常只要求潜在供应商提交 RFP 文件。在这种情况下，RFP 文档需要使用清晰的结构，以便买方可以根据能力、解决方案方法和成本等方面，快速比较首选供应商并做出决策。

由于 IT 组织采购的技术性，解决方案架构师在评估供应商能力和方法时起着至关重要的作用，并且在供应商方响应 RFP 文档时也扮演着重要角色。在 IT 工作负载的 RFP 过程中，解决方案架构师的专业知识至关重要。以下是他们可能的贡献方式：

1. 需求理解：解决方案架构师首先彻底理解项目的技术和业务需求，这些需求可能包括增强现有系统、迁移到云端或集成新技术。

2. 设计解决方案：他们起草一个初步的 IT 架构设计，解决已识别的需求。这包括选择适当的技术、设计基础设施布局，并考虑与现有系统的集成。

3. 协作贡献：架构师通常与跨职能团队合作，包括业务分析师、项目经理和技术负责人，以确保提案在业务目标和技术可行性方面的一致性。

4. 资源估算：他们估算项目所需的资源，这些资源可能包括硬件、软件、云服务和人力工时，确保提案具有竞争力且现实可行。

5. 风险评估：解决方案架构师识别项目中的潜在风险，并提出减轻风险的策略，以便在 RFP 响应中包含这些策略。

6. 文档编制：他们帮助创建详细的技术文档，解释提议的解决方案如何满足 RFP 要求。这些文档通常包括系统图、数据流图以及对提议环境的详细描述。

7. 定价策略：解决方案架构师可能与财务团队合作，为提案制定定价策略，确保成本与所提供的价值相符。

8. 演示：解决方案架构师可能是团队的一部分，负责向潜在客户展示提案，解释技术方面，并回答他们可能有的任何技术问题。

解决方案架构师的角色对定制一个不仅满足客户需求而且确保技术可行性和成本效益的解决方案至关重要。例如，如果一家公司正在寻求关于新云端 CRM 系统的提案，解决方案架构师会首先分析现有的 IT 基础设施，并评估诸如可扩展性和数据安全等必要功能。

他们会设计一个与现有系统（如 ERP）无缝集成的云解决方案，并与营销策略保持一致。通过与潜在供应商的合作，架构师确保所选的 CRM 平台符合公司的特定需求，并评估其兼容性。此外，他们还将与法律团队密切合作，确保解决方案符合严格的合规性和数据管理要求。

关键任务之一是创建迁移策略，将数据从旧系统迁移到新的 CRM 系统，目标是尽量减少对业务的干扰。这还涉及估算总拥有成本，并考虑订阅费用、定制需求、数据迁移和培训需求等因素。解决方案架构师还参与起草 RFP 回应中的技术部分，详细说明所提议的架构、数据策略和安全措施。他们会制定实施路线图，解决系统如何随时间扩展以及部署后将如何提供支持结构的问题。

此外，解决方案架构师向客户的决策者展示并辩护技术战略，阐明所提议解决方案的优势和实用性。这确保客户投资于一个可靠、安全、可扩展的系统，以支持业务增长并适应不断变化的市场需求。

总结

SAD 旨在使所有利益相关者达成一致，并对解决方案设计和需求达成正式协议。由于利益相关者包括业务和技术用户，你了解了解决方案架构师需要考虑的各种 SAD 视图。你必须为非技术用户包含业务、流程和逻辑视图；对于技术用户，需包括应用程序、开发、部署和运营视图。

本章内容中，你了解了 SAD 的详细结构，主要部分和子部分。

SAD 的各个部分包括解决方案、业务和概念架构的概述等详细信息。你还了解了架构图中的各种架构视图，如应用程序视图、数据视图、基础设施视图、集成视图和安全视图。你还学习了 SAD 的其他部分，涵盖了解决方案交付考虑因素和运营管理。

这是一次漫长的学习旅程，你已经接近书的结尾，但在结束之前，我们将提供一些成为解决方案架构师并提升知识的建议。

在接下来的最后一章，你将学习各种软技能，如沟通风格、责任感、批判性思维和持续学习技巧，以帮助你成为一名更优秀的解决方案架构师。

加入我们书籍的 Discord 频道

加入书籍的 Discord 工作区，与作者和其他解决方案架构专业人士交流提问：packt.link/SAHandbook

第十七章：学习软技能以成为更好的解决方案架构师

在前面的章节中，你学习了解决方案架构师如何满足所有利益相关者的需求。即使解决方案架构师的角色是技术性的，他们仍需要跨部门工作，从高层管理到开发团队。软技能是成为一名成功解决方案架构师的关键因素。

解决方案架构师应该随时跟进当前的技术趋势，持续提升自己的知识，并始终保持对新事物的好奇心。通过不断学习，你可以成为一名更优秀的解决方案架构师。在本章中，你将了解如何学习新技术，并且如何回馈和贡献给技术社区。

解决方案架构师需要定义并呈现一个整体的技术战略，以应对业务问题。他们需要跨业务和技术团队工作，协商出最佳解决方案，这需要优秀的沟通技巧。在本章中，你将学习解决方案架构师必须具备的软技能，包括沟通：

• 软技能在解决方案架构中的重要性

• 获得售前技能

• 承担责任和问责制

• 灵活性与适应性

• 设计思维

• 通过参与编程实践来成为一名建设者

• 通过持续学习来变得更好

• 成为他人的导师

• 成为技术传道者和思想领袖

本章结束时，你将了解解决方案架构师成功所需的软技能。你将学习获得战略技能（如售前和高层沟通）的方式，并培养设计思维和个人领导力技能（如宏观思维和责任心）。你还将学习如何建立自己的领导者身份并持续提升自己的技能。

软技能在解决方案架构中的重要性

软技能在解决方案架构中的重要性不容忽视，因为这些技能对于解决方案架构师的有效性和成功至关重要。

首先，有效的沟通至关重要。解决方案架构师必须将复杂的技术细节简化，以便非技术相关方理解，确保技术和业务目标之间的清晰度与对齐。这项技能在弥合技术团队与业务单位之间的沟通差距、促进相互理解和协作设定目标中至关重要。

合作与团队合作也扮演着关键角色。鉴于解决方案架构师经常在跨学科团队中工作，能够与来自不同背景和专业领域的个体和谐合作至关重要。这种合作还包括冲突解决、达成共识和营造共享责任与集体成功的环境。

此外，解决问题和批判性思维是解决方案架构师必备的软技能。他们的工作性质通常涉及应对复杂的技术挑战，并找到与业务战略相契合的创新解决方案。这需要技术理解力、创造力、分析思维以及面向解决方案的思维方式。

最后，领导力和适应力至关重要。解决方案架构师经常在项目团队中担任领导角色，指导技术方向并做出关键决策。这需要技术领导力以及激励、激发和引导团队朝着共同愿景迈进的能力。此外，技术领域不断发展变化，适应力和学习心态使解决方案架构师能够保持与时俱进，及时响应新趋势和技术变化。这些软技能和技术专长使解决方案架构师成为任何组织的宝贵资产。

在接下来的章节中，我们将探讨解决方案架构师应具备的一些关键软技能，这些技能与本文所提到的总体技能相关或包含其中。

获得售前技能

售前是复杂技术采购的关键阶段，客户在此阶段收集详细信息以作出购买决策。在客户组织中，解决方案架构师参与售前周期，验证来自不同供应商的技术和基础设施资源。在供应商组织中，解决方案架构师需要回应客户的提案请求（RFPs），并展示潜在解决方案，以帮助公司获取新业务。实现这一目标需要一套特定的技能组合。

关键技能

售前阶段要求具备独特的技能组合，将强大的技术知识与软技能结合起来，主要包括以下内容：

• 沟通与谈判技巧：解决方案架构师需要具备出色的沟通能力，以便向客户传递正确且最新的信息。提供精确的解决方案细节和行业相关性有助于客户理解您的解决方案如何解决他们的业务问题。解决方案架构师在销售团队和技术团队之间架起了沟通的桥梁，因此沟通与协调能力是至关重要的技能。解决方案架构师还需要通过与客户和内部团队的合作来制定协议，这要求具备出色的谈判技巧。特别是，战略层面的决策会对多个团队产生重大影响。解决方案架构师需要在团队之间进行谈判，处理权衡问题，并制定优化的解决方案。

• 倾听与问题解决技能：解决方案架构师需要强大的分析能力，以根据客户需求识别合适的解决方案。解决方案架构师倾听并理解客户的使用案例，通过提出正确的问题来创造出好的解决方案，这一点非常重要。解决方案架构师需要理解差距，并开发出对业务产生即时影响且具有长期投资回报率（ROI）的解决方案。对于一些客户，性能更为重要，而其他客户可能更关注根据其应用用户群体的成本。解决方案架构师必须根据客户的主要关键绩效指标（KPI）目标提供正确的解决方案。

• 面向客户的技能：解决方案架构师通常需要与内部和外部客户团队合作。他们在各个层级影响利益相关者，从 C 级高管到开发工程师。他们向高级管理层展示解决方案和演示，后者从商业角度审视你的提案。C 级高管的支持和承诺总是能促成所采用解决方案的成功，这使得面向客户的技能变得非常重要。C 级高管需要在确定的时间限制会议中了解解决方案的细节，而解决方案架构师需要充分利用分配的时间。你将在本章的下一节——向 C 级高管汇报中了解更多关于高层对话的内容。

• 与团队合作：解决方案架构师与业务团队和产品团队建立关系。为了准备一个最佳的应用程序，解决方案架构师必须与各级业务和技术团队合作。解决方案架构师需要成为一个优秀的团队成员，分享想法，并找到跨团队合作的方法。

上述技能是售前所需的，并适用于解决方案架构师的日常工作职能。解决方案架构师通常有技术背景，并且在这样的角色中，他们需要获得与高管层沟通的关键技能。让我们在接下来的章节中深入了解高层对话。

向 C 级高管汇报

解决方案架构师需要从技术和商业角度应对各种挑战。其中最具挑战性的任务之一可能是获得高管的支持。

高级管理人员如首席执行官（CEO）、首席技术官（CTO）、首席财务官（CFO）、业务部门负责人（LoBs）和首席信息官（CIO）被视为 C 级高管，因为他们的日程非常紧张，需要做出许多高影响力的决策。

作为一名解决方案架构师，你可能有很多细节需要展示，但高层管理会议的时间是有限的。解决方案架构师需要在规定的时间内最大化会议的价值。主要的问题是：我们如何在有限的时间内获得高级管理人员的关注和支持？

从解释议程和计划的会议结构开始。高层管理人员会提出很多问题，以便有效利用他们的时间，你的议程应表明他们将有机会提出澄清问题。随后，执行高层展示的关键是用前 5 分钟总结主要观点。你应该做好准备，以便如果原本的 30 分钟会议时间缩短到 5 分钟，你仍然能够传达你的要点并争取到下一步的支持。

用与他们所在行业和组织相符的事实和数据支持你的总结。保留细节，以便他们需要深入了解某个特定领域时，你可以随时调出并展示所有相关数据。

不要在细节上做过多展示，避免陈述那些从你角度看似相关但对高层管理人员并不重要的信息。例如，作为解决方案架构师，你可能会更多关注技术实施的好处。然而，高层管理人员更关注的是通过降低运营成本和提高生产力来获得的投资回报率（ROI）。

根据客户的行业和领域术语调整你的演示或展示。将他们熟悉的术语和概念融入其中，不仅能建立信任，还能表明你已经根据他们独特的行业挑战量身定制了技术解决方案。

你应该准备好回答以下与高层管理人员相关的问题：

• 提议的解决方案如何使我们的客户受益？ 业务围绕客户展开。高层管理人员关注公司增长，而公司增长只有在客户满意的情况下才能实现。确保对他们的客户群和需求进行充分研究，并准备好以可靠的数据支持所提的利益。

• 你在制定解决方案的基准时做了哪些假设？ 通常，这些会议处于初期阶段，你可能需要更多的细节。解决方案架构师总是需要做一些假设来为解决方案奠定基准。将你的假设列出，并为假设不成立的情况准备缓解计划。

• 我的投资回报率（ROI）是多少？ 高层管理人员总是通过确定总拥有成本（TCO）来寻找 ROI。准备好提供数据，估算所有权成本、解决方案维护成本、培训成本、整体节省成本等。

• 如果我们照目前的状态继续下去不做任何改变，会发生什么？ 高层管理人员可能会进入极为严格的审查模式，以识别投资回报率（ROI）。他们希望了解这项投资是否值得。你应该准备好你的市场研究资料，例如，技术趋势、客户趋势以及竞争形势。

• 我们的竞争对手对你的解决方案会作出什么反应？ 竞争无处不在，且高层通常会对此感到担忧。他们希望了解你的解决方案是否具有创新性，能够击败竞争对手并为他们的组织带来优势。最好事先进行一些研究，并加入关于他们行业和客户群体的竞争数据。

• 你的建议是什么，我能如何帮忙？ 在提供建议时，你应该始终列出清晰的行动项作为下一步。你需要获得高层的支持，并通过寻求帮助让他们感到参与其中。例如，你可以请求 CIO 将你与工程或产品团队联系，以便将整体解决方案推进到下一步。

接下来，我们来看看作为技术领导者，解决方案架构师应该具备哪些领导能力。

承担责任与担当

承担责任并将自己定位为领导者，帮助你通过责任感赢得信任。责任感并不意味着你需要单独执行任务；它更多的是指采取新举措并为组织坚持这些举措。你可以有一些能够提高组织生产力、灵活性、节省成本并增加客户群的想法。有时，你可能需要更多的时间或资源来执行你的想法，但你应该将其作为新举措提出来，并邀请他人共同执行。

责任感是指承担责任以推动结果的实现。拥有责任感和担当是密切相关的，你需要主动去采取行动并努力实现结果。人们可以信任你完成任何工作并推动结果。责任感帮助你与客户和团队建立信任，从而创造更好的工作环境并实现目标。

作为解决方案架构师，拥有责任感能帮助你从客户和赞助商的角度看待问题。你会感到有动力，并且成为一个有意义且你喜欢做的事情的一部分。确保定义并创建关键成功因素和目标关键结果。目标/指标应该可以通过特定的关键结果来衡量，并且必须是有时间限制的。让我们进一步了解目标与关键结果（OKRs）。

使用 OKRs 来定义战略执行

执行战略是复杂且具有挑战性的。卓越的战略执行对于实现组织的愿景、使命和目标至关重要。这个理念需要转化为可执行的元素，以确保团队一致并朝着相同的方向前进。目标设定和目标管理是一些最行之有效的完成任务的方式。

OKR（目标与关键结果）是目标设定的原则和实践（愿景和执行）。OKR 是一种专注于战略执行的战略管理系统，是一个简单的框架，让你能够定义组织的主要战略和优先事项。目标是原则，关键结果是实践——即组织愿景的什么和如何。OKR 基于四项超级能力，如下图所示：

图 17.1：OKR 的超级能力

OKR 的超级能力包括：

• 聚焦：从这个问题开始：我们的主要优先事项是什么？人们应该把精力集中在哪里？ 致力于真正重要的事情，并明确什么是至关重要的。

• 对齐：使目标公开透明。与团队连接，并实现跨团队、底向上和横向对齐。

• 跟踪：直观地跟踪每个目标的关键结果，精确到百分比。

• 挑战性目标：设定雄心勃勃的目标，去实现一些卓越的成就。挑战性目标让人们重新构想和思考。

OKR 设置了清晰的、可衡量的目标，并将其与组织的战略使命对齐。在解决方案架构中，OKR 可以指导系统的设计和实施，确保它们有助于业务的整体目标。

对于解决方案架构师，OKR 可能涉及如下内容：

目标：提高系统的韧性和容错能力。

关键结果：

• 在下个季度内将系统停机时间减少 30%。

• 在下一个发布周期内，为关键服务实施多区域部署策略。

• 在六个月内实现面向用户的应用层 99.99% 的可用性。

在这里，架构师使用 OKR 来设定系统性能和可靠性的明确目标，这些是他们职责中的关键方面。OKR 还帮助优先排序任务，衡量进展，并将架构决策的影响传达给利益相关者。

OKR 为各级利益相关者提供了可见性和有意义的成果，从执行赞助人到团队。OKR 使得组织的愿景和使命变得清晰。日常工作的团队成员需要看到并理解使命。他们需要知道他们的日常工作如何影响组织的目标。OKR 框架允许你定义这种联系，并为团队中的每个人提供可见性和意义。

思考宏大

解决方案架构师应当具备宏观思维并能够预见未来。解决方案架构师为团队提供基础，团队在此基础上建立模块并启动产品。思考宏大是解决方案架构师应具备的关键技能之一，能够考虑应用程序的长期可持续性。

思考宏大并不意味着你需要设定一个非常不切实际的目标。你的目标应该足够大，能够挑战自己并把你推离舒适区。

思考大局意味着预测组织的需求，保持技术进步的领先地位，确保今天的设计能够适应并保持在未来的有效性。思考大局对个人和组织层面的成功至关重要。

在思考大局时，你应始终对自己的能力充满信心。虽然最初可能看起来很有挑战性，但你会发现，当你朝着目标努力时，你会找到前进的道路。相信自己，你会发现别人也开始支持并相信你。思考大局有助于激励你周围的人成为你成功的一部分。设定长期目标，例如你希望在下一个十年看到自己和组织在哪里？ 一步步前进，将短期目标与长期目标对接。

一旦你通过思考大局设定了一个有挑战性的目标，它将帮助你主动探索新的挑战。然而，最好是你能获得同行和团队的支持，以实现结果，他们能为你提供正确的反馈并在需要时伸出援手。成为一个别人愿意帮助的人；这是一个双向的过程。要获得帮助，你需要愿意帮助别人。适应性是解决方案架构师与他人合作的另一个关键技能。让我们更深入了解它。

灵活且具有适应性

适应性和灵活性是密切相关的，作为解决方案架构师，你必须具备灵活性以适应新的环境、工作文化和技术。适应性意味着你始终对新思想保持开放，并愿意与合适的团队合作。

团队可以采纳最适合自己的过程和技术。作为解决方案架构师，你必须灵活地在解决方案设计过程中满足团队需求。例如，在微服务架构中，每个服务通过标准的 RESTful API 在 HTTP 协议上进行通信。团队可以使用不同的编程语言或工具编写代码，如 Python、Java、Node.js 或 C#。唯一的要求是，团队需要安全地暴露其 API，以便整个系统能够基于这些 API 构建。

你需要不同的思维方式和视角来看待问题，并获得更具创新性的解决方案。鼓励团队快速失败并进行创新，有助于组织保持竞争力。

灵活性的人格特质表现如下：

• 与团队一起思考各种解决方案来解决问题，并采取最佳方法

• 帮助团队成员分担工作

• 在团队成员因个人原因需要请假数周时，自愿填补空缺

• 能够与不同地点和时区的团队有效合作

你需要保持开放的心态，适应技术和流程的变化。当你为团队或组织带来变化时，可能会遇到抵抗。你需要鼓励他人保持灵活，并传达变化的重要性。例如，当一个组织希望将其工作负载从本地服务器迁移到云端时，通常需要更多的支持，因为人们必须学习一个新平台。你需要解释云计算的价值主张，以及它如何帮助他们变得更加敏捷并加快创新速度。

作为解决方案架构师，你必须适应多种任务，并设定正确的执行优先级。你应该能够根据情况调整工作方式，并在压力下工作。

解决方案架构师需要具备关键的设计思维能力，以创建创新的解决方案。让我们在下一节了解更多关于设计思维的内容。

设计思维

解决方案架构师的主要职责是系统设计，这使得设计思维成为一项至关重要的技能。设计思维是各行各业为解决具有挑战性和模糊问题而采用的最成功的方法之一。设计思维帮助你从不同的角度看待问题和解决方案，这些角度可能是你在第一次接触问题时没有考虑到的。设计思维更注重通过提供基于解决方案的方法来解决问题，从而实现结果。它有助于质疑问题、解决方案和相关的风险，以制定最优化的策略。

设计思维通过将自己置于最终用户和客户的位置，帮助你以更以人为本的方式重新定义问题。以下图表说明了设计思维的主要原则：

图 17.2：设计思维原则

以下是一些设计思维原则：

• 经常进行实验：创建原型以了解想法在现实情境中的实施。采用快速失败的策略并更多地进行实验。

• 跨部门协作：邀请不同背景的人加入，共同以多元化的方式寻找问题，确保解决方案能够满足每个人的需求。

• 重视人群：从不同用户那里收集反馈，并站在他们的立场上，从不同的角度理解问题。

• 展示与讲解：通过视觉化展示你的想法，以便在场的每个人都能更容易理解。

• 明确定义问题：为给定的挑战创建一个明确且清晰的愿景，这有助于他人清楚地理解并鼓励他们参与其中。

• 深入思考设计过程：理解整体设计过程，并设定明确的目标和方法。

• 行动偏好：最终的设计是为了交付解决方案，而不仅仅是思考。要主动推动进程，创造能够带来可行解决方案的活动。

设计思维为应用同理心并创建问题的整体视图提供了坚实的基础。为了采纳设计思维，d.school（dschool.stanford.edu/resources/getting-started-with-design-thinking）提出了一个五阶段的模型。它们是设计思维教学和应用的先驱。下图展示了设计思维的五个阶段：

图 17.3：设计思维的五个阶段

设计思维是一种迭代的过程，需要不断演进。一个阶段的输出可以反过来作为其他阶段的输入，直到解决方案得以巩固。以下是各个阶段的简要概述：

• 同理心：同理心是设计中的基础和构建块，尤其是在人的背景下。为了培养同理心，你需要观察用户的行为并与他们互动，以了解实际问题。试着将自己置身于情境中，体验问题。

• 定义：同理心有助于定义问题，因为你通过体验用户的需求和他们面临的问题来帮助定义问题。在定义阶段，你运用洞察力清晰地定义问题，这为头脑风暴提供了动力，从而找到一种创新而简单的解决方案。

• 创意：创意阶段是从问题到解决方案的过渡阶段。你与团队一起通过挑战假设，寻找各种替代解决方案。你需要把显而易见的解决方案从脑海中去除，并通过协作找到所有可能的解决方案，从而激发创新。

• 原型：原型阶段有助于将想法转化为具体的解决方案。原型制作可以提供大量学习机会，并通过展示概念验证（POC）来帮助解决分歧。它帮助你发现差距和风险。你应该构建一个快速原型，投入不多，这样可以处理失败并增加学习机会。

• 测试：测试阶段是获取反馈并根据反馈对解决方案进行迭代。测试阶段帮助你重新定义解决方案，并更深入地了解用户。

设计思维涵盖了所有阶段，以便开发出一个逻辑且实用的解决方案。在设计应用架构时，你可以将设计思维的各个阶段和原则与现实生活联系起来。特别强调原型制作，因为这是唯一能通过数据和事实将你的提案和现有解决方案落实的方式。解决方案架构师的主要工作是理解业务需求，并创造一个技术解决方案设计，团队可以根据该设计进行实施。为了构建原型，解决方案架构师必须亲自参与实践编码。让我们深入了解一下。

通过亲自参与编码成为一名建设者

解决方案架构师是一个通过实践学习的建设者。构建一个原型胜过千言万语。它有助于减少误解并构思解决方案。展示一个概念验证（POC）并进行原型设计是解决方案架构师角色中不可或缺的部分。

原型设计是解决方案阶段的前期工作，它有助于加深你对应用设计和用户的理解。它帮助你思考并构建多个解决路径。通过测试一个原型，你可以改进你的解决方案，并通过演示你的愿景来激励其他人，如团队、客户和投资者。

解决方案架构师是一个技术领导者，与开发团队紧密合作。在一个有赋能的敏捷开发团队中，解决方案架构师除了展示 PowerPoint 演示文稿外，还需要展示一段代码作为 POC。解决方案架构师不需要成为开发团队的一部分，但需要与他们协作，用他们的语言将解决方案传达给开发团队。如果解决方案架构师能够理解解决方案的深层技术方面，并拥有持续编码和实践经验，成功交付才有可能。

解决方案架构师通常被视为导师和球员教练；具备一定的实际编码经验有助于他们建立可信度。解决方案架构师需要决定团队应该使用哪些编程语言和工具。亲自参与实际操作有助于识别可能不符合团队或解决方案需求的差距——不断学习新技术能让你代表组织做出更好的决策。让我们进一步了解持续学习的技巧。

通过持续学习变得更好

解决方案架构师需要不断吸收新知识，提升自己的技能，以帮助组织做出更好的决策。持续学习保持你的技能与时俱进，增强自信心。它开阔了你的思维，改变了前景。

结合全职工作和繁忙的家庭生活，学习可能会变得具有挑战性。持续学习是培养一种始终学习新知识的习惯，你需要保持动力和自律。你首先需要设定学习目标，并运用有效的时间管理来实现这些目标。当你忙于日常工作时，这通常会被忽略。

每个人都有自己的学习方式。有些人可能喜欢正式的教育；有些人喜欢读书；还有些人可能喜欢听或看教程。你需要找到最适合你且符合你生活方式的学习方式。

例如，你可以在上下班通勤时听有声书和教程。你可以在商务航班上阅读书籍，或者在健身房锻炼时观看视频教程。总的来说，你需要做一些调整，腾出时间从繁忙的工作生活中抽出时间来进行持续学习。以下是一些让自己保持持续学习的方法：

• 通过实际尝试学习新技术、框架和语言：解决方案架构师是准备好动手实验的构建者。作为一名成功的解决方案架构师，你必须通过构建一个小型 POC 来不断学习新技术。了解现代编程语言和框架将帮助你为组织和团队提供最佳的技术采纳建议。

• 通过阅读书籍和教程学习新技能：传统的阅读纸质书籍方法在专注学习方面具有显著优势。它能让读者从在线活动的干扰中脱离出来，促进更深的专注。这种方法对那些整天坐在电脑屏幕前的人尤其有益，因为它为眼睛提供了休息的机会。通过阅读纸质书籍，能够减少数字疲劳，增强对材料的专注，从而提高学习体验。

同样，Kindle 上有数百万本书可以随时随地阅读。像 Audible 和 Google Play 的有声书平台可以帮助你在通勤时听书。如此多方便的资源可供利用，完全没有理由不进行持续学习。

在线学习具有革命性意义，使得理解并深入学习任何领域变得更加容易。现在，你可以随时通过触手可及的巨大知识库学习任何东西。像 Udemy 或 Coursera 这样的在线平台提供了成千上万的视频教程课程，涵盖各个领域，你可以在线观看或下载到设备上进行离线学习。

• 通过阅读网站和博客上的文章跟进技术新闻和发展：保持自己更新技术趋势的最佳方式是订阅技术新闻和博客。TechCrunch.com、Wired.com 和 Cnet.com 是一些热门网站，你可以在这些网站上找到最新的技术趋势。主要报纸如 CNBC、纽约时报 和 BBC 新闻以及 CNN 频道也有技术类文章，为行业趋势提供了很好的见解。你还可以订阅相关技术领域的博客进行新学习。例如，对于云平台学习，你可以订阅 Amazon Web Services (AWS) 博客，这些博客有成千上万的关于 AWS 云的文章和用例，类似的博客也可以在其他公共云平台上找到，如 Azure 和 Google Cloud Platform (GCP)。

• 写博客、白皮书或书籍：分享知识是最好的学习方式，因为在试图向他人呈现时，你会思考用例。通过在流行的博客平台如 Medium、Blogger 和 LinkedIn 上发布博客和文章，帮助你分享自己的学习成果，并向他人学习。积极参与问答平台，使你能够为任何给定的问题找到替代方案。一些流行的问答平台包括 Quora、Reddit、Stack Overflow 和 Stack Exchange。

• 通过教授他人巩固你的知识：教授他人有助于你与他人合作，并从不同的角度理解你的知识。参与者提出的用例常常给你提供解决问题的新思路。举办一整天的工作坊，进行实践实验和概念构建，有助于你巩固学习并与他人共同学习。

• 参加在线课程：有时候，你希望通过正式的学习来更有纪律，同时也需要灵活性。在线课程提供了灵活性，帮助你调整其他优先事项，并节省时间。在线课程为学习新技术和增强知识提供了有组织的方式。

• 向队友学习：队友共享相同的工作环境，你大部分时间都会和他们一起工作。与队友一起学习可以加速你的学习过程。团队可以采用分而治之的策略，成员们可以分享各自的主题，并开展深入的午餐学习会议。这些会议是许多组织用来定期进行团队成员学习的标准方法。每个团队成员在每周的学习会议上分享他们的新学习，大家能够快速了解新话题。

• 参加并参与用户组和会议：所有大型行业和技术组织都会举办会议和实践课程，以提供新技术趋势的见解。参与行业会议和用户组会议有助于发展人脉并了解技术趋势。一些来自行业领导者的大型技术会议包括 AWS re:Invent、Google Cloud Next、Microsoft Ignite、SAP SAPPHIRE 和 Strata Data Conference。你还可以创建一个本地用户组，在本地举办聚会，这将有助于你与来自不同行业和组织的专业人士进行合作。

持续的职业发展对于解决方案架构师至关重要，随着技术的快速发展，需要定期更新资质和认证，以跟上新技术进展和行业标准。

解决方案架构师扮演着技术领导者的角色，而优秀的领导力要求培养更多像你一样的领导者，这可以通过导师制度实现。解决方案架构师应担任球员兼教练的角色，辅导他人。让我们更详细地看一下这一点。

成为他人的导师

导师关系是通过你的学习和经验帮助他人，并为他们的成功奠定基础。这是一种有效的方式来培养领导者，通过一对一的导师/学员关系。成为一名好导师，你必须建立一种非正式的沟通风格，让学员能够建立舒适的交流区域。学员可以在多个方面寻求建议，比如职业发展或个人问题，如工作与生活的平衡。你应该进行非正式的需求评估，设定共同的目标和期望。

导师关系更多的是倾听，而非讲话。有时，人们需要的是有人聆听他们的想法，并在需要时给予建议。你应该先认真倾听，并理解他们的观点。

帮助学员做出自己的决策，让他们感到更有成就感。作为一名优秀的导师，在建议他人职业发展时，你需要接受有关学员最合适选择的意见，即使这未必是对公司最合适的选择。始终提供诚实、建设性的反馈，帮助他们识别并克服差距。

一名导师的关键特质是激励他人的能力。通常，人们会选择你作为导师，如果他们在你身上看到了榜样的力量。帮助学员意识到自己的全部潜力，而不把自己的观点强加给他们，帮助他们实现他们之前从未想过的目标。成为导师总是有互惠的好处；你也会从学员身上学到关于人类行为和成长的东西。做别人的导师最终会帮助你成为一个更好的领导者和人。

为了将你的专业知识提升到一个新的水平，你可以成为一名技术传播员和思想领袖。让我们接着探讨这一点。

成为技术传播员和思想领袖

技术传播是关于成为一名倡导技术和产品的专家。一些拥有广泛产品线的组织会推出专门的技术传播员角色。然而，解决方案架构师通常需要在其工作中承担传播员的角色。作为一名技术传播员，你必须了解当前的技术趋势，以理解现实世界中的问题，并倡导你的技术来解决业务挑战。

技术传播包括作为公开演讲者参加行业会议并推广你的平台。它可以让你成为思想领袖和意见领袖，这有助于组织增加平台和产品的采纳度。公开演讲是解决方案架构师与不同公共平台互动，并在大规模观众面前展示的关键技能之一。

传播者还会创建并发布博客、白皮书和微博，以推广他们的产品。他们通过社交平台传播内容，增加用户的采纳度，并与用户互动，了解他们的反馈。传播者从客户需求出发，将反馈传达给内部团队，以帮助改进产品。随着时间的推移，作为传播者，您将逐步完善对组织最有利的信息传递方式。

解决方案架构师是一个责任多重的角色，承担更多的责任将有助于您在职业生涯中取得成功。

总结

在这一章节中，您学习了作为一名解决方案架构师，成功所需的软技能及其重要性。解决方案架构师需要具备售前技能，帮助他们支持组织的售前周期，例如参与 RFP。

您了解了高层沟通与支持所需的演讲技巧，以及解决方案架构师应该具备的战略理解，以便为组织定义关键目标和成果。为了在各个层级执行，解决方案架构师需要具备宏大的思维能力，并且灵活、适应变化。您还了解了解决方案架构师如何承担责任并对自己的行为负责。

解决方案架构师的主要职责是架构设计。您了解了设计思维及其原则和阶段。您还了解到持续学习的重要性，以及各种方法帮助您不断学习并跟上市场趋势。您还探索了解决方案架构师的其他职责——作为导师和传播者。

这是一本漫长的旅程，涵盖了关于解决方案架构师的一切，从他们的角色与职责到解决方案设计与架构优化的不同方面。我希望您学到了很多，并且这些内容能够帮助您在解决方案架构师的职业发展中取得进步，或帮助您在当前的岗位上获得成功。

祝学习愉快！

留下评论！

喜欢这本书吗？通过在亚马逊上留下评论帮助像您一样的读者。扫描下面的二维码，获取您选择的免费电子书。