当某个组织设计第一次将工作负载迁移到云端的方案时，他们往往会错误地将公有云视为解决所有IT挑战（包括可扩展性、可用性、成本等）的灵药，继而可能在推进云迁移的过程作出糟糕的架构决策。

本文将回顾组织常犯的一些架构错误。

依照原样将本地遗留的整体工作负载迁移到公有云可能能够正常运行（除非有许可证或特定的硬件要求），但这也会产生不良影响。

尽管虚拟机可以在云中完美运行，但大多数情况下，必须随着时间推移，及时测量虚拟机的性能，并调整实例大小以匹配实际运行的工作负载，才能满足客户需求。

选择提升和转移策略作为临时解决方案是可行的，尤其是在组织没有时间和资源来重新构建工作负载，也没有选择其他架构的备选方案的情况下。

但长期来看，直接迁移（与本地部署相比）将是一种成本高昂的解决方案，并且无法获得云的全部功能，比如水平扩展、缩容至零（scale to zero）、托管服务弹性等。

在设计现代应用程序时，组织倾向于遵循行业趋势。

行业最热门的趋势之一是，选择容器来部署各种应用程序组件，同时相当多情况下，组织选择Kubernetes作为容器编排引擎。

尽管Kubernetes确实有很多好处，且所有超大规模云提供商都提供托管Kubernetes控制平面，但Kubernetes也带来了许多挑战。

Kubernetes的学习曲线非常长，相关人员需要花费相当时间才能完全理解如何配置和维护Kubernetes。

对于由少量不同容器构建的小型或可预测的应用程序，云厂商提供了更好且易于部署和维护的替代方案，它们都完全能够运行生产工作负载，并且比Kubernetes更容易学习和维护。

当组织开始搜索使用公有云的第一个用例时，就会立即考虑使用云存储作为备份，甚至可能用于灾难恢复场景。

尽管这两种用例都是有效的选择，但组织往往也忽略了更远的未来——即一旦在组织的备份站点使用对象存储（或托管NFS/CIFS存储服务），就必须考虑恢复阶段的方案。从云环境拉回本地的大型二进制备份文件将花费大量时间，更不用说出口数据成本、读取对象API调用成本等消耗。

灾难恢复场景也是如此——如果我们将本地虚拟机甚至数据库备份到云端，但在云中没有类似的基础设施环境，那么在发生灾难性事故时，冷灾难恢复站点能给什么帮助？

大多数应用程序都是从前端/应用程序层和后端持久存储层构建的。

在传统或紧密耦合的体系结构中，应用程序层和数据存储层之间需要低延迟，特别是在读取或写入后端数据库时。

常见错误之一是创建混合架构：前端位于云中，从本地数据库中提取数据，或者旧的本地应用程序连接到托管数据库服务的架构（罕见场景）云端。除非目标应用程序不易出现网络延迟，否则强烈建议将所有架构组件排列相邻，以减少各个应用程序组件之间的网络延迟。

很多组织担忧的常见风险是供应商锁定，客户被锁定在特定云提供商的生态系统中。进一步说明就是，供应商锁定与云提供商之间切换的成本有关。

多云不会解决风险，但会带来更多挑战，包括技能差距（熟悉不同云提供商生态系统的团队）、中央身份和访问管理、多个云环境上的事件响应、出口流量成本等。

不要设计复杂的架构来减轻理论或潜在风险，而是设计解决方案来满足业务需求，熟悉单个公有云提供商的生态系统。随着时间的推移，一旦您的团队对多个云提供商有了足够的了解，就可以扩展您的业务范围。

架构，无需在最初就转向多云。

根据经验，除非有特定的数据驻留要求，否则请选择靠近客户的区域，以降低网络延迟。

成本是重要的考量因素之一，但仍应设计一个应用程序与数据靠近客户的架构。

如果您的应用程序为全球或多个位置的客户提供服务，请考虑添加CDN层，结合多区域解决方案（例如跨区域复制、全局数据库、全局负载均衡器等），让所有静态内容更接近客户。

在以往传统的数据中心中，往往只设计一个应用程序架构，并在应用程序的整个生命周期中保持静态。

设计云端的现代应用程序时，我们应该拥抱动态思维，这意味着不断重新评估架构，审视过去的决策，看看新技术或新服务是否可以为运行应用程序提供更合适的解决方案。

云的动态特性及不断发展的技术，提供了革新的能力与方式，使我们能以更快、更有弹性、更经济高效的方式运行应用程序。

这是许多架构师都会陷入的陷阱——具有特定云提供商的背景，围绕该云提供商的生态系统设计架构，将偏见决策和服务限制嵌入到架构设计中。

相反，架构师应该充分了解业务需求、云解决方案的整个范围、服务成本和限制，然后才开始选择最合适的服务，参与应用程序的架构。

成本是使用云服务时的重要考量，影响成本的因素之一是按需使用服务的能力（也不为未使用的服务付费）。

架构设计中的每个决定（选择正确的计算节点、存储层、数据库层等）都会产生成本影响。一旦获知每种服务的定价模型以及特定工作负载的潜在增长，就可以估算潜在的成本。

云的动态特性可能会导致每个月的成本不同，因此，我们需要定期评估服务成本，不时更换服务，并进行调整以适应特定的工作负载。

在选择正确的服务和架构来满足特定的工作负载要求和用例方面，公有云还面临着许多挑战。架构设计没有对错之分，但避免“糟糕”的架构决策，需要在设计时着眼大局。

个人对读者的建议是，不断扩展在云和架构相关技术方面的知识，并不断质疑当前架构，用这些知识判断是否有更适合现有业务的架构替代方案。