面向应用的云端迁移方法

本文要点

• 在向云端迁移时，如果使用的是以架构为中心的方法，那么并不会提供用户想象中的优点。
• 尽可放心使用那些无需自己管理架构的甲方云服务。
• 在规划故障时，确保考虑了应用故障、服务故障、架构故障和设施故障。
• 认真考虑所需的服务规模，充分利用云所提供的弹性，一些时候，还需要考虑能节约费用的长效合同。

最近我参与了一个企业 IT 资产组合向云端的迁移，其中包括了基础架构和应用。我注意到我们过分注重于基础架构方面，而忽视了云端对应用本身的影响。在我看来，应用架构在云时代扮演着更重要的角色。根据自己在云端实施方面的经验，我提出了一些专注于应用程序架构的原则。遵循这些原则，将有助于用户真正地获得云计算的优势。如果你仅依赖于以基础架构为中心的方法，那么迁移到云端将只会是又一次转变，而非转型。

松耦合。云使得我们可以按需扩展和缩小容量。但这只有当我们的系统（或子系统）是无状态时才可以实现。系统（或子系统）应是松耦合的，这样各个部分可以根据各自的负载需求分别进行缩放。

如果应用程序和 Web 服务器是松耦合的，那么两者均可独立地缩放。要实现这一点，需使用云原生的负载均衡器或队列机制。这允许系统缩放到任意规模，去除了依赖约束。此外，在混合云场景中，队列机制是连接系统的最好选择之一。

单一职责的服务器。这个概念是我从面向对象编程中借鉴而来的。一般来说，我们倾向于将一台服务器用于多个目的。然而，云使得我们可以创建不同规模的服务器，从非常小到非常大。反过来，这使得我们可在指定的服务器上仅部署一个代码库或可执行单元。通过这样的做法，一个应用程序组件的更改就不会影响到其它任何组件。要实现上述模式，请遵循蓝绿部署（Blue-Green Deployment）方法，确保对一个组件的部署不会造成其它组件的停机。

自动部署。云使我们具备了按需提供资源的能力。但是除非我们可以做到无需任何手动干预就在动态配置的基础架构上运行应用程序，我们才能充分利用这种能力。这意味着我们不能交互式登录到服务器去部署应用，应该使用编程的方式去应用配置和设置。换句话说，应禁用主机登录，通过云提供商提供的脚本或 API 完成所有的配置和设置。

使用本地云服务。许多云实施依然专注于将云主要用作“基础架构即服务”（IaaS）的托管模式。在自治（Self-managed）模式中，定义用于横向和纵向扩展的触发器是我们自身的职责。对于许多原生云服务，云提供商负责底层硬件设施的横向和纵向扩展。云服务提供商负责硬件的配置、构建和设置、复制，以及一些情况下的软件打补丁和集群扩展。云的真正优势所在，只能通过使用原生云服务实现。

例如，使用 AWS Lambda、Azure Functions、SQS 或类似的原生云（Cloud Native）服务，就可以摆脱对基础架构的定义。将这个工作交给云提供商！使用托管数据库服务，例如 AWS RDS，DynamoDB 或 Azure DocumentDB，避免使用自治的数据库。这种做法存在一个缺点，它会将应用程序绑定到相应的云平台。事实上，如果使用了云互操作（Cloud Interoperability）模型，就无法充分地利用云。这类似于不同的操作系统以自身的方式提供了类似的功能（例如，文件系统访问，网络，编解码器等），每个云提供商都对通用的功能给出了自身独有的建议方法。

将本地存储看做是临时存储。作为扩展或部署实验的组成部分，托管在云虚拟机上的应用可随时丢弃。重要的是，应用不会在虚拟机本地存储任何值。虚拟机的本地存储应被视为临时存储。它会与虚拟机一并丢弃。在传统方法中，应用将配置、日志文件、图像等存储在本地存储中。然而，需要改变这种做法，任何持久信息都应转移到一个持久的服务上，实现数据块或对象的存储。云应用程序应支持蓝绿部署，这只有在当前执行的代码没有绑定到本地存储时才可能实现。

设计应始终针对故障。在云中，我们不知道应用运行所在的位置。硬件会易于出现故障，软件更新和补丁也会易于出错。最好是在架构和设计时，就考虑到对应用故障的处理，而不是去考虑并力图实现稳健性。稳健性是永远也不可能实现的。消除单点故障（SPOF，Single Point Of Failure），逐层构建弹性。这样，即使底层硬件发生故障，应用也可正常运行。

AWS Availability Zones（AZ）和 Regions 简化了冗余能力的设计，类似的服务还有 Azure Locally Redundant Storage（LRS）、Zone-redundant Storage（ZRS）、Geo-redundant Storage（GRS）和 Read-access geo-redundant storage（RA-GRS）。与传统手段相比，构建弹性云的基础设施更为简单，代价更低。在数据库存储设计时，应保证至少一个区域或可用区（Availability Zone）可容错。应用可通过使用灾难恢复模式的最佳实践变得更为高可用。这些最佳实践包括指示灯（Pilot Light）、暖待机（Warm Site）和热待机（Hot Site）部署模型等。可在 AWS 白皮书《使用 AWS 进行灾难恢复》（“ Using Amazon Web Services for Disaster Recovery ”）中看到更多的详细信息。

重启和重加载的弹性。在应用设计中，应对重启和重加载具有弹性。在组件重启或重加载时，系统必须保持正常可用。不要假定任何组件会是健康的、可用的或是固定位置的。使用动态配置引导实例。在启动实例时，应该质疑一下“我是谁，我的角色 / 目的是什么？”此外，对启动配置内容进行精简，以使新的基础设施可以快速地适用于工作。

在每一层上应用安全。在构建安全性时，应根据云中无任何天生安全的事情这一假设，为每一层加入安全性。云中的环境安全是工作于一种供应商和消费者间的共同职责模式下。云提供商确保底层基础设施的安全，而消费者负责自身工作负载的安全。消费者应该在数据传输和驻留时应用适当层级的加密。应始终强制执行最小权限原则，不要赋予用户（或其它系统！）其所不需要的权限。利用云提供商所提供的安全特性。

受控密钥服务 AWS Key Management Service（KMS）和 Azure Key Vault 简化了对数据加密所用密钥的创建和控制。此外，还可使用 Hardware Security Modules（HSM）保护密钥的安全性。KMS 和 Key Vault 可与各种云服务集成，随时可用。让用户自己去设置这样的 HSM 基础设施，这无疑是复杂的，并需要特殊的技能。尽可能地利用可用的原生服务，这样也易于实现与其它应用的集成。安全是云采纳与集成中所面临的最大挑战之一。为了克服这一挑战，采用安全密钥服务对实现的每一层做加密，使用云提供的身份验证和授权服务（AWS IAM 和 Azure Directory Services）来控制和保护云资源。不要将其用于应用程序内的身份验证或授权，这是一个反模式（anti-pattern）。因为一个应用可能会有成百上千的用户，为所有的用户管理云资源将会是一个繁琐的任务，我们并不需要这样做。如果应用是一个内网应用，推荐使用 Active Directory 认证。对于关键云资源的保护，强烈建议使用多重身份验证（Multi-Factor Authentication）。一个应用的主要安全风险，就是在源代码中对密码或其它安全凭证（例如 AWS 中的 Access Key Id 和 Secret Access Key）做硬编码。这不仅会使密码和安全密钥轮转（Rotation）复杂化，而且一旦代码提交到源代码仓储后，会将秘密暴露给无关人员。 从应用访问云资源时，始终使用由 AWS Security Token Service（STS）等服务所生成的临时凭据。

确定基础设施的规模。在云中，由于云提供了内置的扩展功能，确定基础设施的最初规模不再是最重要的，但依然很重要。如果一个企业能确定自身的需要，例如需要 100 或 1000 台的服务器，这将有助于企业选择备用容量来降低成本，因为企业无需为最低工作负载支付更高的价格。最低工作负载即对于三层架构的应用，至少需要四台服务器（即两台数据库服务器，一台应用服务器和一台 Web 服务器）。在这种情况下，你可以长期租用四台服务器。小规模负载可以节省支出。也就是说，云费用将会继续下滑，因此我们要限制具有未来扩容需要的长期合约。一年时间的长期租赁通常足以获得定价上的优势。云允许我们超越基础设施的限制。按需付费适于通过横向和纵向扩展云基础设施支持可变的需求。

边缘站点（Edge Location）的缓存。缓存是一种传统的技术，针对重复请求改进应用性能。 AWS 边缘站点（Edge Location）或 Azure PoP（Point of Presence）将缓存提升到了一个新的级别，并降低了延迟。尽可能地使用支持经由边缘站点进行内容传送的云原生服务（例如，AWS Cloudfront 或 Azure CDN）。采用 AWS API Gateway 或 Azure API 应用，将自身的 REST API 服务公开给外部的和内部的消费者。这免除了所有的操作负担，通过点击几下鼠标，就可提供安全、缓存、管理等特性。

标记资源，用于问责（Accountability）。我们的整体云目标，是通过应用程序和基础架构的敏捷化，提高业务的敏捷性。随敏捷性而来的是，云提升了业务部门的责任心。云使我们能将成本与每次业务交易相关联。云提供商允许我们标记每个单独的基础设施，并提供各自相应的帐单。多年前，Melvin Conway 就提出，企业结构会对企业所创造的所有系统产生巨大的影响。在标记中使用企业结构，使每个业务部门和应用所有者更具责任和透明性！

从环境（例如开发，测试，分期，生产等）的角度看，对每种环境都应有一个独立的帐户。这确保了环境暴露给正确的人，并得以良好的维护。也会避免任何意外的损坏。

对大多数应用，应用上述原则并不需要做重大的重编码。许多原则可以通过设置、配置和严格的部署过程来解决，其它的原则可以通过对应用做微小的更改而实现，并不涉及核心的功能。过去我们曾假定，服务器硬件一旦购买将继续永久使用。而云是根据每次使用而付费，并在不需要时关闭。不要将你当前的部署模型复制到云部署上。因此在采用云时，我们应重新审视应用和基础设施模式，避免简单的升级转换（lift-and-shift）操作。对于任何在云上的新部署，至少应遵循上述原则。

我建议，不应该仅将云计算看作是另一种技术平台，而应将云用于产生竞争中的优势。云资源类似于业务中的信用可用性。一个小公司也可以高瞻远瞩，并实现自己的想法。因为当前一个想法的实现，并不需要做前期的投资和很高的生产周期。使用上述原则，构建具有自身竞争优势的应用和产品。

本文作者简介

Amit Kumar是 DXC（由 CSC 和 HP ES 合并成立）的主管架构师。他具有计算机应用硕士学位，并拥有 15 年以上的 IT 行业经验。Amit 是 AWS 认证解决方案专业架构师（AWS Certified Solution Architect - Professional）和 TOGAF 认证 EA 执业者（TOGAF Certified EA practitioner）。他热衷于云计算，曾历时 18 个多月时间将客户端 IT 基础设施和应用程序转变到云端。过去六年中，Amit 领导并指导了 DXC 印度分公司的架构师团队，任项目交付团队和 DXC 最终客户的顾问。他还负责培训解决方案架构（Solution Architecture），应用指导（Application Guidance）和归档（Archimate）。他的突出贡献是将架构定义划分成四个步骤，即战略（Strategy）、需求（Requirement）、定义（Definition）和验证（Validation）。他在 LinkedIn 上提供了联系方式。

查看英文原文： Taking an Application-Oriented Approach to Cloud Adoption