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

原文：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 提供了许多开箱即用的选项，可以帮助您现代化系统。”

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

提示和技巧如下所示。

与我们联系

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

一般反馈：发送电子邮件至 [email protected]，并在邮件主题中提及书籍标题。如果您对本书的任何方面有问题，请发送邮件至 [email protected]。

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

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

请通过 [email protected] 与我们联系，并提供材料的链接。

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

分享您的想法

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

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

下载本书的免费 PDF 版本

感谢您购买本书！

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

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

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

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

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

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

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

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

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

1. 提交您的购买凭证

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

第一章：1

组织中的解决方案架构师

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

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

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

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

• 什么是解决方案架构？

• 解决方案架构师的角色

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

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

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

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

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

什么是解决方案架构？

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

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

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

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

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

解决方案架构的好处

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解决方案架构师的角色

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

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

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

图 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。

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

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

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

分析功能需求（FRs）

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

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

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

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

定义非功能需求（NFRs）

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

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

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

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

• 性能：

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

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

• 安全性和合规性：

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

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

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

• 恢复能力：

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

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

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

• 可维护性：

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

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

• 可靠性：

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

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

• 可得性：

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

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

• 可扩展性：

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

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

• 可用性：

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

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

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

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

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

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

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

了解并参与利益相关者

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

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

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

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

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

理解架构限制

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

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

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

图 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（概念验证）、设计与交付解决方案、确保上线后的可操作性和维护以及担任技术布道者等重要方面。

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

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

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

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

留下评论！

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

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

第二章：2

解决方案架构设计原则

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

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

本章将介绍以下内容：

• 构建可扩展架构设计

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

• 为性能设计

• 创建不可变架构

• 思考松耦合

• 思考服务，而非服务器

• 思考数据驱动设计

• 在每个地方增加安全性

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

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

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

• 到处应用自动化

• 为操作设计

• 克服架构限制

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

构建可扩展架构设计

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

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

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

• 水平扩展：由于过去十年中计算能力已成为一种指数级更便宜的商品，水平扩展变得越来越流行。在水平扩展中，团队通过增加更多的服务器来处理增加的工作负载，如图 2.1所示：https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_02_01.png

  图 2.1：水平扩展

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

• 垂直扩展：这种方式已经存在很长时间了。这是一种做法，其中团队通过向同一台服务器增加额外的计算存储和内存能力，以应对日益增加的工作负载。如图 2.2所示，在垂直扩展过程中，你将获得一台更强大的服务器——而不是增加更多的服务器——来处理增加的工作负载：https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_02_02.png

  图 2.2：垂直扩展

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

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

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

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

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

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

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

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

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

图 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 云技术栈的三层架构图：

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

图 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 服务器处理，直到流量到达负载均衡器。这样，在整个区域发生故障时，您的应用程序仍然可以继续运行。

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

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

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

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

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

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

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

解决组件故障

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

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

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

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

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

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

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

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

使架构具有容错性

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

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

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

图 2.6：容错架构

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

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

为性能设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

创建不可变架构

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

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

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

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

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

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

思考松耦合

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

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

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

图 2.7：紧耦合架构

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

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

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

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

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

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

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

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

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

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

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

想想服务，而不是服务器

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

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

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

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

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

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

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

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

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

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

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

思考数据驱动设计

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

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

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

在各个方面添加安全性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使应用程序易用且可访问

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

实现可用性

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

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

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

实现可访问性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 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，这意味着几乎没有停机时间和数据丢失。

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

图 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 评估，其中客户最初需要交付的卡车，并根据客户的需求和反馈逐步演变这个过程：

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

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

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

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

总结

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

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

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

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

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

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

留下评论！

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

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

第三章：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所示。为了比较，还显示了本地解决方案。

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

图 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。

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

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

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

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

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

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

图 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 基础设施，这在云迁移和混合云架构中尤为重要，因为在这些环境中，效率和适应性至关重要。

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

保留或退役

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

保留

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

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

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

退休

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

• 很少使用的应用程序

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

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

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

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

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

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

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

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

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

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

选择云迁移策略

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

迁移策略	描述	时间与成本	优化机会
重构	重新设计应用程序，使其更模块化，变得云原生	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_04.png	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_05.png
重新平台化	将应用程序迁移到升级后的平台，但不改变核心架构	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_06.png	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_07.png
重新购买	通过购买云基础解决方案来替代当前环境	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_08.png	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_09.png
重新托管	快速将应用程序迁移到云端，而无需改变架构	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_10.png	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_11.png
保留	暂时将应用程序保留在本地	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_12.png	无
重新定位	快速将应用程序迁移到云端，无需进行任何更改	https://github.com/OpenDocCN/freelearn-devops-pt8-zh/raw/master/docs/solu-arch-hb-3e/img/B21336_03_12.png	无
停用	识别不再有用的资源并彻底移除	无	无

表 3.1 – 云迁移策略对比

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

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

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

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

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

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

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

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

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

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

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

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

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

云迁移步骤

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

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

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

图 3.4：云迁移步骤

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

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

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

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

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

• 迁移：执行迁移策略

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

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

• 运营：规划在云中运营

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 服务器数量的清单

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

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

• 服务器依赖关系

• 总体网络详细信息

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

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

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

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

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

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

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

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

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

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

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

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

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

信息分析

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

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

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

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

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

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

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

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

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

创建迁移计划

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

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

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

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

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

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

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

• 定义迁移的成功标准

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

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

• 确定迁移模式

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

• 创建迁移冲刺团队

• 确定迁移工具

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

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

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

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

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

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

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

设计应用程序

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

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

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

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

• 外部和内部流量路由

• 网络保护的防火墙规则

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

• 整体网络合规性和治理

• 网络日志和流量审计

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

• DDoS 攻击保护与防御

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

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

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

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

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

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

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

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

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

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

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

图 3.5：本地架构映射

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

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

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

现在我们转向 AWS 云设计：

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

图 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 名称解析

• 业务约束，例如切换可以发生的日期或时间以及数据的关键性

• 更改管理指南和批准

实时迁移在业务关键型工作负载迁移中最为流行。让我们深入了解一下它。

实时迁移切换

在此方法中，数据持续复制到目标地，并且你在应用程序仍在运行时进行大多数功能验证和集成测试。下图展示了一个适用于实时零停机迁移的切换策略。

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

图 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 云之间建立高速连接，实现低延迟的混合部署：

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

图 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 工作负载自动化。

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

图 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

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

第四章：4

解决方案架构设计模式

你是否曾想过大型企业是如何设计可扩展的系统的？在开始应用开发之前，解决方案架构师需要跨组织工作，权衡多个选项，制定架构设计以应对业务需求。

设计解决方案有多种方式。解决方案架构师需要根据用户需求以及成本、性能、可扩展性和可用性等架构约束来选择合适的方法。在本章中，你将了解各种解决方案架构模式、参考架构，以及如何将它们应用于实际场景。

在前几章中，你学习了解决方案架构设计的原则。本章既激动人心又至关重要，因为你可以将所学应用于各种架构设计模式。在本章中，你将了解一些重要的解决方案架构模式，如分层架构、事件驱动架构、微服务架构、松耦合架构、面向服务架构和 RESTful 架构。

你将了解各种架构设计的优势，并查看示例，演示何时使用它们。你还将了解架构设计中的反模式以及以下架构设计模式：

• 构建 n 层架构

• 创建基于多租户的 SaaS 架构

• 理解面向服务的架构

• RESTful Web 服务架构

• 构建基于缓存的架构

• 模型-视图-控制器（MVC）架构

• 构建领域驱动设计（DDD）

• 理解断路器模式

• 实现舱壁模式

• 创建浮动 IP 模式

• 使用容器部署应用程序

• 应用架构中的数据库处理

• 清洁架构

• 避免解决方案架构中的反模式

到本章结束时，你将了解如何优化你的解决方案架构设计并应用最佳实践，使得本章成为你学习的中心和核心。

构建 n 层架构

在n层架构（也称为多层架构）中，你需要应用松耦合设计原则，并具备可扩展性和弹性属性。在 n 层架构中，你将产品功能划分为多个层次，例如展示层、业务层、数据库层和服务层，使得每个层次可以独立实现和扩展。

使用 n 层架构，采用新技术并提高开发效率变得容易。这种分层架构提供了灵活性，可以在每一层中添加新功能，而不影响其他层的功能。在安全性方面，您可以确保每一层都安全且彼此隔离，这样如果一层被攻破，其他层不会受到影响。应用程序故障排除和管理也变得更加可控，因为您可以快速定位问题所在，并明确需要进行故障排除的应用程序部分。

最常见的多层设计架构是三层架构，所以让我们进一步了解它。以下图示展示了一个 AWS 示例架构，允许您通过浏览器与 web 应用程序进行交互，并执行所需功能，例如订购您喜欢的 T 恤或阅读博客并留言：

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

图 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，提供对应用层的访问：

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

图 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 原则。服务尽可能独立运行：

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

图 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) 和内存缓存引擎被用来支持应用程序缓存。然而，如果缓存与本地服务器耦合，那么在服务器崩溃时缓存将不会持久化数据。大多数应用程序都运行在分布式环境中，因此最好拥有一个独立于应用生命周期的专用缓存层。如果你对应用程序进行水平扩展，那么所有服务器都应该能够访问集中式缓存层，以实现最佳性能。

下图描述了解决方案架构各层中的缓存机制：

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

图 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、应用和数据库层：

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

图 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 中的这一模式：

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

图 4.6：重命名分发模式架构

如前图所示，使用重命名分发模式与缓存分发模式结合有助于解决更新问题。通过这种模式，服务器上传带有新文件名的更新文件，而不是覆盖原始服务器中的文件并等待 CloudFront 中 TTL 到期，然后更新网页中的新 URL。当用户请求原始内容时，CloudFront 必须从源服务器获取内容，不能提供已缓存的过时文件。

然而，你可以立即使旧文件失效，但这会产生更多成本，因此最好上传文件的新版本，供 CDN 立即获取。同样，你必须在应用程序中更新 URL 以便获取新文件，这相比使失效的选项会增加一些开销。最好根据你的业务需求和预算来做出决定。

你可以使用代理缓存服务器来代替 CDN，尤其是当用户分布在全国各地时。让我们在下一部分中详细了解它。

缓存代理模式

通过添加缓存层，你可以显著提高应用程序的性能。在缓存代理模式中，静态或动态内容会被缓存到 Web 应用服务器的上游。如下面的架构图所示，你在 Web 应用集群前面有一个缓存层：

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

图 4.7：缓存代理模式架构

在前面的图中，为了高效交付，缓存内容由缓存服务器传递。缓存代理模式的一些好处如下：

• 缓存代理模式帮助您通过缓存传递内容，这意味着无需在 web 服务器或应用服务器级别进行修改。

• 它们减少了动态内容生成的负载。

• 可以在浏览器级别设置缓存，例如在 HTTP 头、URL、Cookies 等中。或者，如果不想在浏览器级别存储缓存，可以在缓存层存储信息。

在缓存代理模式中，必须维护多个缓存副本，以避免单点故障。有时，您可能希望从服务器和 CDN 提供静态内容，每个方法需要不同的处理方式。让我们在下一节深入探讨这种混合情况。

重写代理模式

有时，您希望更改静态网站内容的访问目标，如图像和视频，但又不想更改现有系统。您可以通过提供代理服务器来实现这一点，使用重写代理模式。要将静态内容的目标更改为其他存储，如内容服务或互联网存储，您可以在 web 服务器群集前使用代理服务器。如以下架构图所示，您在应用层前放置一个代理服务器，帮助在不修改实际应用的情况下更改内容交付目标：

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

图 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 中，缓存层应用于应用层和数据库层之间：

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

图 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 或其他低延迟持久化存储中。

接下来，我们来讨论隔舱架构模式，它有助于减少服务之间的依赖，并在服务出错的情况下缓解问题。

实现隔舱模式

隔舱是船只上用来创造独立密闭区域的结构隔板。其主要目的是在船体发生破损时，控制进水的后果，防止水在船只中蔓延。这种设计作为一种重要的安全措施，旨在最小化单一区域损坏时整个船只沉没的风险。

相同的概念有助于在大型系统架构中限制故障的范围，在这种架构中，你希望划分系统以解耦服务之间的依赖。其核心思想是一个故障不应该导致整个系统失败，正如下图所示：

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

图 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 地址从一台服务器移动到另一台服务器，如下面的架构图所示：

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

图 4.11：浮动 IP 和接口模式

由于您正在移动 EIP，DNS 可能不需要更新。EIP 可以将您的服务器公共 IP 移动到不同的实例。如果需要移动公共和私有 IP 地址，则可以使用更灵活的方法，例如 ENI，如前图右侧所示。ENI 可以跨实例移动，并且您可以使用相同的公共和私有地址进行流量路由或应用程序升级。

到目前为止，您已经了解了多种架构模式，其中应用程序部署在虚拟机中。但是，在许多情况下，您可能需要帮助来利用虚拟机。为了进一步优化您的利用率，您可以将应用程序部署在容器中。容器最适合于微服务部署。让我们在下一节中深入了解基于容器的部署。

使用容器部署应用程序

随着许多编程语言的发明和技术的进步，这带来了新的挑战。不同的应用堆栈需要不同的硬件和软件部署环境。通常需要在不同平台上运行应用程序并迁移至另一个平台。解决方案需要一种可以在任何地方运行并且一致、轻量且可移植的东西。

就像运输集装箱标准化了货物的运输一样，软件容器标准化了应用程序的运输。Docker 创建一个包含软件应用程序运行所需的所有内容的容器，例如文件系统结构、守护程序、库和应用程序依赖项。

容器为软件提供了相应开发和测试环境中的隔离。这种隔离至关重要，因为它可以防止多个团队在相同底层基础设施上运行各种软件应用时产生冲突。

虚拟机在操作系统级别进行隔离，而容器则在内核级别进行隔离。这种隔离允许多个应用程序在单一主机操作系统上运行，并且仍然拥有各自的文件系统、存储、RAM、库，以及大多数情况下，各自的系统视图：

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

图 4.12：应用程序部署的虚拟机和容器

如前图所示，容器在单个虚拟机中部署多个应用程序。每个应用程序都有其运行时环境，因此您可以在保持服务器数量不变的情况下运行多个独立应用程序。容器共享机器的操作系统内核。它们具有快速启动时间和高效利用计算资源（如 RAM）的优点。容器镜像是通过文件系统的层构建的，可以共享公共文件。这种共享资源的方法减少了磁盘使用量并加快了下载容器镜像的速度。

让我们来看看为什么容器越来越受欢迎，以及它们的好处。

容器的好处

关于容器，经常会有人提出以下问题：

• 当我们已有实例时，为什么还需要容器？

• 难道实例不已经为我们提供了与底层硬件的隔离吗？

尽管前面的问题是有效的，但使用像Docker这样的系统仍然有许多好处。Docker 的一个关键优势是，它允许您通过在同一实例中托管多个应用程序（在不同端口上）来充分利用虚拟机资源。

Docker 利用 Linux 内核的某些特性，特别是内核命名空间和组，来实现每个 Docker 进程之间的完全隔离，正如下图所示：

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

图 4.13：应用程序基础架构中的容器层

如前图所示，实际上可以在同一台机器上运行两个或多个需要不同版本 Java 运行时的应用程序，因为每个 Docker 容器都有自己安装的 Java 版本和相关库。进而，应用程序基础架构中的容器层使得将应用程序拆解为微服务变得更加容易，这些微服务可以在同一实例上并行运行。容器具有以下优点：

• 可移植的运行时应用环境：容器提供平台无关的能力，您可以一次构建应用程序并在任何地方部署，无论底层操作系统如何。

• 更快的开发和部署周期：修改应用程序并快速启动，通常几秒钟内即可运行，几乎可以在任何地方进行。

• 将依赖项和应用程序打包成单一工件：将代码、库和依赖项打包在一起，使应用程序能够在任何操作系统上运行。

• 运行不同版本的应用程序：具有不同依赖关系的应用程序可以在同一服务器上同时运行。

• 一切皆可自动化：容器管理和部署通过脚本进行，帮助减少成本并降低人为错误的风险。

• 更好的资源利用：容器提供高效的扩展和高可用性，同一微服务容器的多个副本可以在服务器之间部署，为您的应用程序提供支持。

• 轻松管理安全性：容器是特定于平台的，而不是特定于应用程序的。

由于其优势，容器部署变得非常流行。有多种方式可以编排容器。接下来，我们将更详细地了解容器部署。

容器部署

使用容器部署，具有多个微服务的复杂应用程序可以迅速部署。容器使得构建和部署应用程序更加可管理，因为环境是一致的。在开发模式下构建容器，将其推送到测试环境，再发布到生产环境。对于混合云环境，容器部署非常有用。容器使得在微服务之间保持环境一致性变得更容易。由于微服务通常不会消耗大量资源，它们可以被放置在同一个实例中以降低成本。

有时，客户的工作流较短，需要临时的环境设置。这些环境可能是队列系统或持续集成任务，这些任务不总是高效地利用服务器资源。容器编排服务如 Docker 和 Kubernetes 可以作为解决方案，允许它们将容器推送到实例并随时弹出。

Docker 的轻量级容器虚拟化平台提供了管理应用程序的工具。它的独立应用程序可以安装在任何计算机上，以运行容器。Kubernetes 是一个与 Docker 以及其他容器平台配合使用的容器编排服务。Kubernetes 允许自动化容器配置，并精心处理安全性、网络和扩展等方面的问题。

容器帮助企业创建更多的云原生工作负载，公共云服务提供商如 AWS 扩展了服务来管理 Docker 容器和 Kubernetes。

以下图示展示了 Docker 使用 Amazon 弹性容器服务 (ECS) 进行容器管理，提供全托管的弹性服务，自动化 Docker 容器的扩展和编排：

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

图 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 数据库中管理会话状态。

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

图 4.15：在容器上部署有状态应用

正如你在前面的图表中看到的，基于容器的架构包含了几个关键组件：

• 一个 Amazon 虚拟私有云（VPC），包含特定的子网：

  • 公有子网：托管负载均衡器

  • 私有子网：用于部署应用和数据库

• 应用负载均衡器，负责提供对托管在容器中的网站的访问。

• 一个 Amazon 弹性 Kubernetes 服务（EKS）集群，包含 Kubernetes 中的托管节点组。这些节点负责运行多个应用容器。

• 一个 Amazon ElastiCache Redis 数据库，用于存储用户会话状态。

这种架构通过将用户会话存储在 Redis 数据库中，支持应用的可扩展性。然而，请注意，实现此解决方案可能需要修改应用代码，这在某些情况下可能不可行。

现在，你已经了解了多种专注于应用开发的架构模式。数据是任何架构设计中不可或缺的一部分，且大多数架构围绕着数据的收集、存储和处理展开。在下一节中，让我们深入了解如何在应用架构中处理数据。

应用架构中的数据库处理

数据始终是任何应用开发的核心，数据扩展一直是一个挑战。高效地处理数据可以提升应用的延迟和性能。在前面一节 构建基于缓存的架构 中，你学习了如何通过在数据库前面放置缓存来处理频繁查询的数据，属于应用缓存模式。你可以将 Memcached 或 Redis 缓存放在数据库前面，从而减少对数据库的多次访问，并提高数据库的响应速度。

在应用部署中，随着应用用户基础的增长，你需要通过关系型数据库处理更多的数据。你需要增加更多的存储或通过增加更多的内存和 CPU 来垂直扩展数据库服务器。通常，当涉及到扩展关系型数据库时，横向扩展会更加复杂。如果你的应用是读密集型的，你可以通过创建只读副本来实现横向扩展。将所有的读请求路由到数据库的只读副本，同时保持主数据库节点处理写入和更新请求。由于只读副本采用异步复制，它可能会增加一些延迟时间。如果你的应用可以容忍几毫秒的延迟，选择只读副本是合适的。你可以利用只读副本来卸载报表查询。

你可以使用数据库分片技术，为你的关系型数据库创建一个多主架构，并引入横向扩展的概念。分片技术用于通过多个数据库服务器提升写入性能。数据库被结构化并划分为相同的部分，适当的表列作为键，用于分配写入过程。

如下架构图所示，客户数据库可以分成多个分片：

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

图 4.16：关系型数据库分片

如前图所示，未进行分片时，所有数据都位于一个分区中，例如，所有用户的名字都存储在同一个数据库中。进行分片后，数据会被分割成称为分片的大块。例如，所有名字以A 到 I开头的用户在一个数据库中，J 到 R在另一个数据库中，S 到 Z在第三个数据库中。在许多情况下，分片能提供更高的性能和更好的操作效率。

使用 Amazon RDS 进行分片后端数据库时，需要在 Amazon EC2 实例上安装分片软件，如 MySQL，并搭配 Spider 存储引擎。随后，您可以开始设置多个 RDS 数据库，并将它们作为分片的后端数据库。

然而，如果您的主数据库实例宕机怎么办？在这种情况下，您需要保持数据库的高可用性。让我们更详细地了解一下高可用性数据库模式。

高可用性数据库模式

为了确保应用程序的高可用性，保持数据库持续运行至关重要。由于关系型数据库的水平扩展并非直接可行，因此带来了额外的挑战。为了实现高可用性的数据库，您可以拥有一个主数据库实例的备用副本，如下图所示：

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

图 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 模式丰富了您实现高可用性的工具包。

本章深入探讨了容器化，揭示了容器的多重好处，并提供了有效容器部署的路线图。在应用架构中研究了数据库处理策略，关注高可用性模式以确保数据完整性和持续运行。

本章以突出干净架构原则为主题，并传授避免解决方案架构中有害反模式的策略作为结束语。

通过参与这次架构探险，您深入了解了构建具有弹性、可扩展和未来准备性软件系统的复杂性，并且现在拥有了足够的知识来应对现代技术动态的挑战。

留下评论！

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

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