面向应用的云端迁移技巧

　　最近我参与了一个企业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 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）等服务所生成的临时凭据。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!