当我们在说云架构的时候，通常指的并不是云平台的自身架构，而是基于云平台的软件系统基础架构。云平台的自身架构满足了很多通用层面的需求，例如对象存储，弹性主机，虚拟网络等等，只有云服务厂商的工程师才会涉及。对于一般企业中的工程师而言， 鉴于云服务的各种优势，基于云平台构建软件系统才是工作的内容之一，尤其是面向混合云的基础架构才是云架构的关键要素。

无论是公有云和私有云的融合，还是多个公有云的混合环境，其基础架构模式分为两种：分布式部署模式和冗余部署模式。在决定合适的架构时需要考虑的5个相关方面: 变更的敏捷性、规模的伸缩性、网络拓扑选择、安全性和可靠性。

分布式部署模式

当我们需要利用云服务的某些特性、属性或功能时，这些模式最为有用。

分层混合模式

经典的分层通常由前端和后端应用程序组成。前端处理终端用户/客户，消费者或他们的组合。一般地，前端是无状态的，在这种情况下，性能和灵活性对于处理不可预测的工作负载是非常重要的。另外，通常还要处理大量的变化，因此可以从敏捷思维中受益。后端根据监管要求安全地存储数据，并且应该不那么频繁地进行更改。

这种架构模式的思想是迁移每个应用程序，首先选择一个不太复杂的应用程序，然后逐个进行。一般地，有6种云迁移策略，通常称为“6R”：主机更新、平台更新、重新购买、重构、保留、停服。因此，需要针对每种情况做出架构决策。迁移之后，它们通过 API 网关访问后端，这个网关集中关注交叉问题，如安全性、速率限制、 API 策略等。

如果正处于迁移过程的中期，而公司不能承诺同时完成所有工作时，这是一个很好的模式，除非情况很简单，否则总是如此。

分区多云模式

如果关注可移植性，那么这种模式提供了将工作负载从一个云平台转移到另一个云平台的能力。该模式的优势是锁定风险并进行缓解，能够从每个供应商挑选最佳功能并完成监管。

实现跨多个云环境的工作负载可移植性和一致性的工具增加了开发、测试和运维的工作。可移植性性是有代价的，为了使可移植性最大化，一般会考虑容器和K8S。

云分析模式

一般地，企业架构通常由事务系统和分析系统组成。事务系统用于执行每天的财务、销售、库存、定价等操作，而分析系统通常由于变化的性质和速度不同而与其他系统解耦。

此模式的核心思想是在云中拥有分析工作负载，并在需要时反馈数据。云存储可以使用数据湖来实现，并通过BOS引入流量。

边云混合模式

有些时候，我们的业务不可能能100% 的依赖于连接，比如车辆间的连接性，工厂的可用性服务水平超过了现场链接的能力，商店需要处理关键事务并且链路的宕机是不可能的。

面对这些挑战，边云混合模式通过在网络边缘运行时间敏感和关键业务的本地工作负载，同时使用云处理所有其他类型的工作负载。在边云混合模式的设置中，互联网连接是一个非关键组件，只用于管理的目的和同步或上传数据，通常是异步的，但不涉及时间敏感或关键业务的事务。

另外，CI/CD的实践在边缘环境和云之间保持一致也是明智的选择。

冗余部署模式

当需要为整个架构增加容量或弹性时，这些模式非常有用。

混合环境模式

在这种模式中，公共云环境用于开发、测试和 UAT，然后生产环境使用私有云。使用这种架构的原因一般包括：监管限制、第三方许可证的使用，而这些许可证阻止了云中的生产工作负载。如果想要首先替换较低的环境，或者在需要时轻松地创建和关闭环境，那么这种模式可以很好地工作。

所有环境在功能上都是等价的，即架构、 API 以及操作系统和库的版本都是等价的，并且系统在不同环境中的行为是相同的。但是，性能测试需要在本地实现。

业务连续性混合模式

在这种模式下，灾备环境在云中实现，提供了能够为创建灾难恢复环境并将其关闭的成本效益。另外，在触发灾备的情况下，使用IaaS可以更快地创建灾备环境，从而减少实际的恢复时间。

另一种替代方法是将生产环境放在一个程序中，然后故障转移到另一个程序中，但是，这种方法不太常见，因为通常可以在一个程序中实现可用性需求。

面向业务爆发的混合云模式

如果应用程序的工作负载突然增加，不可预测，并且不希望在大部分时间里为某些密集的工作负载期间提供过多的服务，这种模式可能是一种选择，对于可以向上和向下扩展的前端无状态应用特别适合。

面向业务爆发的混合云模式使用一个私有计算环境进行基线负载，并在需要额外容量时暂时爆发到云中。这种模式保留了基础的内部投资，而且不需要维持全年的额外容量。

一句话小结

这些混合云架构模式的决策是复杂的，通常会涉及到几个不同情况的关注程度，每种情况都需要全面的权衡分析，甚至可以使用多种模式来实现企业的解决方案。

那么——

如何进行混合云的架构决策？

如何保持架构的可持续性呢？