了解如何使用 Microsoft Azure 架构完善框架的支柱在 Azure 中设计和构建安全、可扩展、高性能的解决方案。
介绍
想象一下，您正在云上构建新系统或将现有系统迁移到云。如何让客户相信他们的数据是安全的？ 您的架构能否应对流量激增？您的架构能否处理一个或多个关键组件的故障？您是否以最有效的方式使用资源？
Azure 架构完善的框架可帮助你设计、构建并持续改进安全、可靠且高效的应用程序。在本模块中，我们将向您介绍该框架，以及对于出色的Azure体系结构至关重要的支柱和原则。
学习目标
学完本模块后，您将能够：
- 描述 Azure 架构完善的框架的支柱。
- 确定创建坚实架构基础的关键原则。
先决条件
- 体验使用数据存储、计算和网络等核心基础设施技术构建或运营解决方案。
- 拥有构建或运营技术系统来解决业务问题的经验。
Azure 架构完善的框架支柱
云改变了组织解决业务挑战的方式以及应用程序和系统的设计方式。解决方案架构师的角色不仅限于通过应用程序的功能需求提供业务价值。他们还必须确保解决方案的设计方式可扩展、有弹性、高效且安全。
解决方案架构涉及技术系统的规划、设计、实施和持续改进。系统架构必须平衡业务需求和执行这些需求所需的技术能力，并使之保持一致。最终的架构是整个系统及其组件的风险、成本和功能的平衡。
Azure 架构完善的框架
Azure 架构完善的框架是一组在 Azure 上构建高质量解决方案的指导原则。 没有一种放之四海皆准的架构设计方法，但有一些通用概念适用于任何架构、技术或云提供商。
这些概念并不包罗万象，但关注它们可以帮助您为应用程序构建可靠、安全和灵活的基础。
Azure 架构完善的框架由五个支柱组成：
- 成本优化
- 卓越运营
- 性能效率
- 可靠性
- 安全
成本优化
您希望设计云环境，使其对于运营和开发而言具有成本效益。识别云支出中的低效和浪费，以确保您将钱花在可以最大程度利用的地方。
卓越运营
通过利用 DevOps 等现代开发实践，您可以实现更快的开发和部署周期。 您需要有一个良好的监控架构，以便您可以在故障和问题发生之前或至少在客户注意到之前检测到它们。自动化是该支柱的一个关键方面，可以消除差异和错误，同时提高运营敏捷性。
性能效率
为了使架构性能良好且可扩展，它应该将资源容量与需求正确匹配。传统上，云架构通过根据应用程序中的活动动态扩展应用程序来实现这种平衡。服务需求不断变化，因此您的架构能够根据需求进行调整非常重要。通过在设计架构时考虑性能和可扩展性，您可以在经济高效的同时为客户提供出色的体验。
可靠性
每个架构师最担心的就是架构失败而无法恢复。成功的云环境的设计方式可以预见各个级别的失败。 预测故障的一部分是设计一个可以在利益相关者和客户要求的时间内从故障中恢复的系统。
安全
数据是组织技术足迹中最有价值的部分。在此支柱中，您重点关注通过身份验证保护对架构的访问，并保护您的应用程序和数据免受网络漏洞的影响。您还应该通过加密等工具保护数据的完整性。
您必须考虑应用程序整个生命周期的安全性，从设计和实现到部署和操作。云提供针对各种威胁的保护，例如网络入侵和 DDoS 攻击。但您仍然需要将安全性构建到您的应用程序、流程和组织文化中。
一般设计原则
除了这些支柱之外，您还应该在整个架构中考虑一些一致的设计原则。
- 实现架构演进：没有架构是静态的。 通过利用可用的新服务、工具和技术来实现架构的发展。
- 使用数据做出决策：收集数据，分析数据，并使用它来围绕您的架构做出决策。从成本数据到性能，再到用户负载，使用数据可以指导您在您的环境中做出正确的选择。
- 教育和支持：云技术发展迅速。教育您的开发、运营和业务团队，帮助他们做出正确的决策并构建解决方案来解决业务问题。记录并共享组织内的配置、决策和最佳实践。
- 自动化：手动活动的自动化可降低运营成本，最大限度地减少手动步骤引入的错误，并提供环境之间的一致性。
共同责任
迁移到云引入了责任共担的模型。在此模型中，您的云提供商管理您的应用程序的某些方面，而您则承担剩余的责任。
在本地环境中，您负责一切。当您转向基础设施即服务 (IaaS)、然后转向平台即服务 (PaaS) 和软件即服务 (SaaS) 时，您的云提供商将承担更多的责任。
这种共同责任在您的架构决策中发挥着重要作用，因为这些决策可能会对成本、安全性以及应用程序的技术和操作能力产生影响。通过将这些责任转移给您的提供商，您可以专注于为您的业务带来价值，并摆脱非核心业务功能的活动。
设计选择
在理想的架构中，您将构建最安全、高性能、高可用性和高效的环境。 然而，与所有事情一样，都需要权衡。
要构建一个具有所有这些支柱最高水平的环境，需要付出一定的成本。该成本可能是金钱、交付时间或运营敏捷性。 每个组织都有不同的优先级，这些优先级会影响每个支柱中所做的设计选择。 在设计架构时，您需要确定哪些权衡是可以接受的，哪些是不可以接受的。
构建 Azure 体系结构时，需要牢记许多注意事项。您希望您的架构安全、可扩展、可用且可恢复。 为了实现这一点，您必须根据成本、组织优先级和风险做出决策。
成本优化
您的组织已将大部分系统迁移到云端，但您现在发现某些领域的成本出现了意想不到的增加。 经过一番观察，您发现您的整个环境效率很低，而且您仍在进行手动操作工作。
在本单元中，您将了解成本优化并寻找减少不必要开支和提高运营效率的方法。
什么是成本优化？
成本优化是确保您的组织花费的资金得到最大的利用。 云服务将计算作为一种实用工具提供。 云中的技术是在服务模型下提供的，可以按需使用。 按需服务产品推动了根本性变革，直接影响规划、簿记和组织。
当一个组织决定拥有基础设施时，它会购买作为资产进入资产负债表的设备。 由于进行了资本投资，会计师将此交易归类为资本支出 (CapEx)。 随着时间的推移，为了考虑资产有限的使用寿命，资产会被折旧或摊销。
另一方面，云服务因其消费模式而被归类为运营费用 (OpEx)。 根据该计划，没有资产可供摊销。 相反，运营支出对净利润、应税收入以及资产负债表上的相关费用有直接影响。
当组织采用云平台时，它必须从以资本支出为导向的预算转向以运营支出为导向的预算。 此举反映了从拥有基础设施到租赁解决方案的转变。 一些组织可以从这种新的会计模型中获得价值。 例如，初创公司可以通过大规模展示有利可图的想法来吸引投资者，而无需预先进行大量投资来购买基础设施。
要优化组织架构中的成本，您可以使用多种原则。
计划和估算成本
对于任何云项目，无论是新应用程序的开发还是整个数据中心的迁移，估算成本都很重要。此估计包括确定当前要移动或重新开发的资源、了解可能影响规模的业务目标以及为项目选择适当的服务。
确定需求后，您可以使用成本估算工具对所需资源进行更简洁的估算。透明度在这里很重要，以便所有利益相关者都可以审查准确性并了解与项目相关的成本。
提供优化
从一开始就配置针对成本进行优化的服务可以减少您未来的工作量。 例如，您应该确保为您的工作负载选择适当的服务级别，并利用可让您调整服务级别的服务。 您还应该在可用时使用折扣，例如预留实例和自带许可证优惠。
如果可能，您希望从 IaaS 服务迁移到 PaaS 服务。 PaaS 服务的成本通常低于 IaaS，并且通常会降低您的运营成本。
借助 PaaS 服务，您不必担心修补或维护虚拟机，因为云提供商通常会处理这些活动。 并非所有应用程序都可以迁移到 PaaS，但由于 PaaS 服务可以节省成本，因此值得考虑。
使用监控和分析来获得成本洞察
如果您不监控自己的支出，您就不知道可以节省什么。 利用成本管理工具并定期查看账单，以更好地了解资金花在哪里。
花时间对各个服务进行定期成本审查，以了解支出是否适合工作负载的资源需求。 根据需要调整支出。 识别并追踪帐单或警报中可能出现的任何成本异常情况。 如果您发现与网络流量相关的成本大幅上升，则可能会发现成本节省和潜在的技术问题。
最大限度地提高云支出的效率
效率的重点是识别和消除环境中不必要的开支。 云是一种即用即付的服务，可避免的费用通常是由于配置的容量超出您的需求而导致的。 运营成本也可能导致不必要或低效的成本。 这些低效的运营成本表现为时间的浪费和错误的增加。 在设计架构时，请识别并消除整个环境中的浪费。
浪费有多种表现形式。让我们看几个例子：
- 始终处于 90% 空闲状态的虚拟机。
- 当已拥有许可证时，为虚拟机中包含的许可证付费。
- 将不经常访问的数据保留在针对频繁访问而优化的存储介质上。
- 手动重复构建非生产环境。
在每种情况下，您都花费了超出应有的钱。 每个案例都提供了降低成本的机会。
在评估成本时，请抓住机会优化环境。 容量需求可能会随着时间的推移而变化，许多云服务可以手动或动态调整所配置的资源以满足需求。 这些调整可以推动运行良好的应用程序和最具成本效益的大小之间的平衡。
在各个层面优化您的系统。在网络层面，确保数据传输高效并满足客户的期望。使用服务缓存数据以提高应用程序性能并减少数据存储服务上的事务负载。识别并停用未使用的资源。 利用成本较低的数据存储层来归档不经常访问的数据。
卓越运营
仅将您的资源转移到云中只是利用了云能为您的组织带来的一小部分资源。 除了云提供的技术功能之外，您还可以提高运营能力。从提高开发人员敏捷性到提高应用程序运行状况和性能的可见性，您可以使用云来提高组织的运营能力。
在本单元中，我们着眼于卓越运营的支柱。
什么是卓越运营？
卓越运营是指确保您全面了解应用程序的运行情况，并确保为用户提供最佳体验。 卓越运营包括使您的开发和发布实践更加敏捷，从而使您的业务能够快速适应变化。 通过提高运营能力，您可以缩短开发和发布周期，并为应用程序的用户提供更好的体验。
在通过架构推动卓越运营时，您可以使用多种原则。
采用现代实践进行设计、构建和编排
现代架构的设计应考虑 DevOps 和持续集成。 现代架构允许您使用基础架构即代码来自动化部署、自动化应用程序测试以及根据需要构建新环境。 DevOps 既具有文化性，又具有技术性，但可以为采用它的组织带来许多好处。
无论您管理的项目类型如何，您都可以将 DevOps 实践引入您的组织。 无论您的项目是使用完整的持续集成和持续部署 (CI/CD) 和容器的应用程序，还是您要继续提供服务的遗留应用程序。
打破组织内的孤岛是整个 DevOps 的共同主题。 项目各个阶段的协作也是如此，包括变更管理。 通过创建共享、协作和透明的文化，您可以为您的组织带来卓越的运营。
使用监控和分析来获得运营洞察
在整个架构中，您希望拥有一个全面的监控、日志记录和仪表系统。 通过创建一个有效的系统来监控架构中发生的情况，您可以确保在用户受到影响之前知道出现问题。 通过全面的监控方法，您可以识别性能问题和成本效率低下、关联事件并获得更强的问题故障排除能力。
从操作上来说，制定强有力的监控策略非常重要。 监控可帮助您识别浪费区域、解决问题并优化应用程序的性能。 多层次的方法至关重要。 从每一层的组件收集数据点将有助于在值超出可接受范围时向您发出警报，并帮助您跟踪一段时间内的支出。
使用自动化来减少工作量和错误
您应该尽可能多地自动化您的架构。 人为因素的成本高昂，会给运营活动带来时间和错误。 时间和错误的增加导致运营成本增加。 您可以使用自动化来构建、部署和管理资源。 通过自动化常见活动，您可以消除等待人工干预的延迟。
测试
您应该在应用程序部署和正在进行的操作中包含测试。良好的测试策略可以帮助您在部署应用程序之前识别应用程序中的问题，并确保依赖的服务可以与您的应用程序正确通信。
良好的测试策略还可以帮助识别预生产和生产部署中的性能问题和潜在的安全漏洞。强大的测试计划可以发现可能影响用户体验的基础设施部署问题，并且测试可以帮助您为用户提供良好的体验。
性能效率
想象一下，发布了一篇有关您组织最近发布的产品的新闻报道。新闻报道的增加宣传为您的网站带来了大量流量。您的网站可以应对这种流量增长吗？您的网站能否承受额外负载而不会变得缓慢或无响应？
在本单元中，我们将了解确保出色的应用程序性能的一些基本原则。特别是构成性能效率支柱的扩展和优化原则。
什么是性能效率？
性能效率是将应用程序的可用资源与其接收的需求相匹配。性能效率包括扩展资源、识别和优化潜在瓶颈以及优化应用程序代码以获得最佳性能。
让我们看看一些可以增强应用程序的可扩展性和性能的模式和实践。
纵向扩展和横向扩展
计算资源可以在两个方向上扩展：
scaling up是指向单个实例添加更多资源。也称为垂直缩放。
scaling out是添加更多实例。也称为水平缩放。
纵向扩展涉及向单个实例添加更多资源，例如 CPU 或内存。该实例可能是虚拟机或 PaaS 服务。
向实例添加更多容量的行为会增加应用程序可用的资源，但它确实有限制。虚拟机受到其运行所在主机的容量的限制，并且主机本身也有物理限制。 最终，当您扩展实例时，您可能会遇到这些限制。它们限制您向实例添加更多资源的能力。
横向扩展涉及向服务添加更多实例。它们可以是虚拟机或 PaaS 服务。我们不是通过使单个实例更强大来增加容量，而是通过增加实例总数来增加容量。
横向扩展的优点是，如果您有更多机器要添加到架构中，您可以想象永远横向扩展。 横向扩展需要某种类型的负载分配。 例如，在可用服务器之间分配请求的负载平衡器，或者用于识别要向其发送请求的活动服务器的服务发现机制。
在这两种类型的扩展中，都可以减少资源，从而实现成本优化。
自动缩放是动态分配资源以满足性能要求的过程。 随着工作量的增加，应用程序可能需要更多资源来维持所需的性能级别并满足服务级别协议 (SLA)。 当需求减弱并且不再需要增加的资源时，可以重新分配它们以最大限度地降低成本。
自动缩放利用云托管环境的弹性，同时减轻管理开销。 它减少了操作员持续监控系统性能并做出有关添加或删除资源的决策的需要。
优化网络性能
当您优化性能时，您会查看网络和存储性能，以确保它们的水平在可接受的范围内。 这些性能级别会影响应用程序的响应时间。 为您的架构选择正确的网络和存储技术可帮助您确保为消费者提供最佳体验。
在服务之间添加消息传递层可以提高性能和可扩展性。消息传递层创建一个缓冲区，以便在接收应用程序无法跟上时，请求可以继续流入而不会出现错误。当应用程序处理请求时，它们会按照收到的顺序得到答复。
优化存储性能
在许多大型解决方案中，数据被划分为可以单独管理和访问的单独分区。必须仔细选择分区策略，以最大限度地提高效益，同时最大限度地减少不利影响。分区有助于提高可扩展性、减少争用并优化性能。
在架构中使用缓存有助于提高性能。缓存是一种存储常用数据或资产（网页、图像）以便更快检索的机制。您可以在应用程序的不同层使用缓存。您可以在应用程序服务器和数据库之间使用缓存来减少数据检索时间。
您还可以通过将静态内容放置在更靠近用户的位置，在用户和 Web 服务器之间使用缓存。这种类型的缓存减少了将网页返回给用户所需的时间。它还具有从数据库或Web服务器卸载请求的次要效果，从而提高其他请求的性能。
识别应用程序中的性能瓶颈
在云中运行的分布式应用程序和服务是由许多移动部件组成的复杂软件。在生产环境中，能够跟踪用户使用系统的方式非常重要。跟踪资源利用率并总体监控系统的运行状况和性能也很重要。您可以使用此信息作为诊断辅助来检测和纠正问题。您还可以使用此信息来帮助发现潜在问题并防止其发生。
性能优化包括了解应用程序本身的执行情况。错误、性能不佳的代码以及依赖系统中的瓶颈都可以通过应用程序性能管理工具来发现。通常，这些问题可能对用户、开发人员和管理员来说是隐藏的或模糊的，但它们可能会对应用程序的整体性能产生不利影响。
查看应用程序的所有层并识别和修复性能瓶颈。这些瓶颈可能是应用程序中内存处理不佳，甚至是向数据库添加索引的过程。这可能是一个迭代过程，因为您消除了一个瓶颈，然后又发现了另一个您不知道的瓶颈。
通过全面的性能监控方法，您能够确定您的架构可以从中受益的模式和实践类型。
可靠性
想象一下，您为一家医疗保健组织运行一个临床系统。 临床医生和护理人员对停机时间的容忍度很低。 他们需要全天候访问临床 IT 系统，以确保始终提供最高质量的护理。
为了满足临床医生全天候的需求，应用程序必须能够处理故障，同时将对用户的影响降至最低。 他们如何保持应用程序在局部事件和大规模灾难中保持运行？
在本单元中，您将学习如何将可靠性支柱中的元素纳入架构设计中。
什么是可靠性？
在复杂的应用程序中，任何规模的问题都可能发生。个别服务器和硬盘驱动器可能会出现故障。 部署问题可能会无意中删除数据库中的所有表。整个数据中心可能变得无法访问。勒索软件事件可能会恶意加密您的所有数据。您的应用程序保持可靠并能够处理局部和广泛影响的事件至关重要。
可靠性设计包括在小规模事件和部分网络中断等临时情况下维持正常运行时间。您可以通过将高可用性集成到每个组件中来确保您的应用程序能够处理局部故障。此应用程序设计消除了单点故障。 这样的设计还最大限度地减少了基础设施维护的影响。高可用性设计通常旨在快速、自动地消除事件的影响，并确保系统可以继续处理请求，而影响很小甚至没有影响。
可靠性设计还重点关注数据丢失和大规模灾难的恢复。从这些类型的事件中恢复通常需要积极干预，尽管自动恢复步骤可以减少恢复所需的时间。这些类型的事件可能会导致一定程度的停机或数据永久丢失。灾难恢复既涉及仔细的规划，也涉及执行。
在架构设计中包含高可用性和可恢复性可以保护您的企业免受因停机和数据丢失而造成的财务损失。 它们还可以保护您的企业免受因客户失去信任而造成的声誉损失。
可靠性架构可确保您的应用程序能够满足您对客户做出的承诺。您希望确保您的系统可供最终用户使用并且可以从任何故障中恢复。
构建高可用架构
为了获得可用性，请确定您承诺遵守的服务级别协议 (SLA)。 检查应用程序相对于 SLA 的潜在高可用性功能，并确定哪些地方有适当的覆盖范围以及哪些地方需要改进。您的目标是为架构组件添加冗余，以便减少发生中断的可能性。
高可用性设计组件的示例包括集群和负载平衡：
集群将单个虚拟机替换为一组协调的虚拟机。当一台虚拟机出现故障或无法访问时，服务可以故障转移到另一台可以处理请求的虚拟机。
负载平衡将请求分散到服务的多个实例，检测失败的实例并防止请求路由到它们。
构建可以从故障中恢复的架构
为了可恢复性，您应该执行分析来检查可能的数据丢失和主要停机情况。您的分析应包括对恢复策略的探索以及每种策略的成本/收益权衡。通过此练习，您可以深入了解组织的优先级，并有助于阐明应用程序的角色。分析结果应包括应用程序的以下持续时间值：
- 恢复点目标 (RPO)：可接受的数据丢失的最长持续时间。 RPO 以时间为单位而不是体积来衡量。 例如"30 分钟的数据"、"4 小时的数据"等等。 RPO 是关于限制数据丢失并从中恢复，而不是数据被盗。
- 恢复时间目标 (RTO)：可接受的停机时间的最长持续时间，其中您的规范定义了"停机时间"。 例如，如果发生灾难时可接受的停机时间为八小时，那么您的 RTO 就是八小时。
定义 RPO 和 RTO 后，您可以在架构中设计备份、还原、复制和恢复功能来满足这些目标。
每个云提供商都提供一套服务和功能，您可以使用它们来提高应用程序的可用性和可恢复性。 如果可能，请使用现有的服务和最佳实践，并尽量避免创建自己的服务和最佳实践。
硬盘驱动器可能会发生故障，数据中心可能无法访问，并且黑客可能会发起攻击。 通过利用可用性和可恢复性在客户中保持良好声誉非常重要。可用性侧重于在网络中断等情况下维持正常运行时间，可恢复性侧重于在灾难后检索数据。
安全
医疗保健组织存储个人和潜在敏感的客户数据。 金融机构存储帐号、余额和交易历史记录。 零售商存储购买历史记录、帐户信息和客户的人口统计详细信息。 安全事件可能会暴露这些敏感数据，这可能会导致个人尴尬或经济损失。 您如何确保客户数据的完整性并确保您的系统安全？
在本单元中，您将了解安全支柱的重要元素。
什么是安全？
安全性最终是为了保护您的组织使用、存储和传输的数据。您的组织存储或处理的数据是安全资产的核心。此数据可能是有关客户的敏感数据、有关您的组织的财务信息或支持您的组织的关键业务线数据。 保护数据所在的基础设施以及用于访问数据的身份也至关重要。
您的数据可能需要遵守更严格的法律和监管要求。这些额外要求取决于您所在的位置、您存储的数据类型或您的应用程序运行的行业。
例如，在美国的医疗保健行业，有一项名为《健康保险流通与责任法案》(HIPAA) 的法律。 在金融行业，支付卡行业数据安全标准涉及信用卡数据的处理。 存储适用这些法律和标准的数据的组织必须确保采取某些保护措施来保护该数据。 在欧洲，《通用数据保护条例》(GDPR) 规定了如何保护个人数据的规则，并定义了与存储数据相关的个人权利。某些国家/地区要求某些类型的数据不得出境。
当发生安全漏洞时，可能会对组织和客户的财务和声誉产生重大影响。安全漏洞会破坏客户愿意向您的组织灌输的信任，并可能影响组织的长期健康。
纵深防御
保护环境的多层方法可增强其安全态势。俗称纵深防御，我们可以将层层分解如下：
数据
应用领域
虚拟机/计算
联网
政策和访问
物理安全
每一层都专注于可能发生攻击的不同区域，并在某一层发生故障或攻击者绕过它时创建深度保护。 如果您只关注一层，那么攻击者只要通过这一层，就可以不受限制地访问您的环境。
分层解决安全问题会增加攻击者为访问您的系统和数据而必须做的工作。每个层都有不同的适用的安全控制、技术和功能。当您确定要实施的保护措施时，成本通常是值得关注的问题。 您需要平衡成本与业务要求以及业务的总体风险。
没有任何单一的安全系统、控制或技术能够完全保护您的架构。 安全不仅仅是技术； 它还与人员和流程有关。 创建一个全面考虑安全性并将其作为默认要求的环境有助于确保您的组织尽可能安全。
防范常见攻击
在每一层，都有一些您想要防范的常见攻击。 以下列表并未包含全部内容，但它可以让您了解每一层如何受到攻击以及您可能需要什么类型的保护。
-
数据层：如果发生未经授权的访问，暴露加密密钥或使用弱加密可能会使您的数据容易受到攻击。
-
应用层：恶意代码注入和执行是应用层攻击的标志。 常见的攻击包括 SQL 注入和跨站脚本 (XSS)。
-
虚拟机/计算层：恶意软件是攻击环境的常见方法，其中涉及执行恶意代码来危害系统。 系统上出现恶意软件后，可能会发生进一步的攻击，导致凭证暴露和整个环境中的横向移动。
-
网络层：利用不必要的互联网开放端口是一种常见的攻击方法。 开放端口还可能包括让 SSH 或 RDP 协议对虚拟机开放。 当这些协议开放时，当攻击者试图获得访问权限时，它们可能会允许对您的系统进行暴力攻击。
-
外围层：拒绝服务（DoS）攻击经常发生在这一层。 这些攻击试图淹没网络资源，迫使它们离线或使它们无法响应合法请求。
-
策略和访问层：该层是对应用程序进行身份验证的地方。 该层可能包括现代身份验证协议，例如 OpenID Connect、OAuth 或基于 Kerberos 的身份验证（例如 Active Directory）。 凭证的暴露是这一层的风险，限制身份的权限非常重要。 您还希望进行监控以查找可能受到威胁的帐户，例如来自异常位置的登录。
-
物理层：通过门绘图和盗窃安全徽章等方法对设施进行未经授权的访问可能发生在这一层。
共同承担安全责任
重新审视共同责任的模型，我们可以在安全的背景下重新构建这个模型。 根据您选择的服务类型，服务中内置了一些安全保护措施，而其他安全保护措施则由您负责。 必须仔细评估您选择的服务和技术，以确保为您的体系结构提供适当的安全控制。