灵活的云计算：可移植性架构的多维优势-Toy模板网

这篇具有很好参考价值的文章主要介绍了灵活的云计算：可移植性架构的多维优势。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Bottom of Form

从敏捷开发的视角来看，大多数场景下，我们在构建应用程序时，都会希望实现快速开发、缩短上线周期，并充分利用云提供商的成型组件服务，来获得更好的稳定性。若想要达成理想成果，我们在具体过程中，还会遇到诸多的问题，譬如：

云服务提供商各项服务和组件的学习时间与成本、架构是否可以符合最佳实践？
更值得关注的是，一旦部署云服务，是否彻底会被该供应商锁定？
如果考虑灾备场景，或是更多的业务跨地域扩展需求，企业架构团队是否要将工作负载部署到其他云上？

面对上述问题，如果答案为“是”的话。那我们将再次经历一遍上述的步骤——学习、部署、转换。这将消耗企业宝贵的时间与人力成本。若能时光倒转，我们为什么不将应用，从一开始设计为如乐高一般、易拆解、易迁移的“灵活的架构”呢？

如此一来，便将会帮助我们免去“返工”流程，同步消除供应商的锁定，并让我们更有信心地应对未来增长的业务需求。在本文中，我们将探讨云中可移植性架构的标准化方法及其优势，帮助大家了解构建弹性应用的最佳实践。

如果工作负载被设计为易于迁移、组件化的形式，那么使用哪家云提供商将不再成为上云、用云的限制条件。因此，在考虑整体工作负载的标准化设计时，首先要确定存在哪些供应商的“锁定点”，或云供应商有可能阻止您转向其他提供商的因素。

例如，围绕 Kubernetes 之类的容器化设计，并不总是完善的。试想一下，那些 Kubernetes 集群可能与之交互、或需要与之交互的其他系统。评估这些需求，并使用开源解决方案和核心云基础设施基元，来基础设计您的架构，您可以在任何云提供商处，获取相应解决方案和核心云基础设施基元基础。

保持关注标准 API，可以确保应用程序与其他系统之间的兼容性。以使用同步（请求/响应）通信组件的RESTful API 为例，它们之所以受欢迎，便是因为使用了HTTP这一更常见和支持范围更广泛的协议类别。虽然可选的其他协议层出不穷，尤其未来在视频流等领域愈加显著，但基于 HTTP 的协议，始终具有高可用性。

采用微服务或容器的模块化设计，可将应用程序分解为更小、更易于管理的组件，更容易按需添加或删除功能，并让应用程序变得更具灵活性和可扩展性。云原生的优势，正在于它提供了轻松更新和替换组件的高效流程，同时不会影响整个工作负载架构的效能。

一旦建立起可移植性的弹性架构，下一步我们需要切换至管理运维视角，来保障该架构未来一直能够保持足够“轻盈”。答案正是自动化。通过自动化，可以简化应用程序的部署和管理。具体路径上开发者可配合使用持续集成/持续部署 (CI/CD) 管道和基础设施即代码 (IaC) 工具。

声明式部署方法，允许您对工作负载的每个部分进行编码：应用程序、软件、系统配置以及在开发、预发布和生产环境中运行的所有内容。因此，您可以在一个新的云环境中，快速启动、进行故障转移或切换到另一家云提供商的环境中。拥有了一个完全可编码且版本化的环境，您可以记录所有内容，了解所有文件记录的设置方式。换言之，您拥有记录所有更改以及更改人信息的透明历史记录。

当然，我们必须牢记安全的重要性。踏上弹性之路，有利于支持您开发出更标准的安全方法，消除“一旦完成设置便抛诸脑后”的危险心态。此类高频风险行为，表现为用户在虚拟私有云(VPC) 中部署工作负载后，即假设它是“安全”的。

在同类“一切皆代码”方法中，我们实现了可移植的标准化架构；用户的全域安全态势，也可以实现标准化和编码。除了自动化反馈循环、漏洞测试等的 DevSecOps 实践之外，还可以考虑访问控制策略和强化的配置模板，这些策略免受底层平台的影响，因此可以确保跨环境资源保护的一致性。尤其面对多云环境，这种安全方法性能强劲，，能够高效承担并转移工作负载，这是灾难恢复中的可靠防御策略。