AICon全球人工智能与机器学习技术大会周四开幕,点击查看完整日程>> 了解详情
写点什么

面向应用的云端迁移方法

  • 2017 年 7 月 13 日
  • 本文字数:4434 字

    阅读完需:约 15 分钟

本文要点

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

最近我参与了一个企业 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

2017 年 7 月 13 日 17:411552
用户头像

发布了 227 篇内容, 共 63.1 次阅读, 收获喜欢 22 次。

关注

评论

发布
暂无评论
发现更多内容

this与super关键字(阿里巴巴面试竟然问道这个了…,ubuntulinux操作系统实用教程

Java 程序员 后端

volatile 和原子类的异同,画个图理解一下,面试官让我下周来上班

Java 程序员 后端

“996”为什么还没实行,mybatis从入门到精通电子书

Java 程序员 后端

SQL:我为什么慢你心里没数吗?,java面试说我基础太差

Java 程序员 后端

synchronized 中的 4 个优化,你知道几个?,rocketmq教程教程

Java 程序员 后端

SSM框架整合过程总结,书籍+视频+学习笔记+技能提升资源库

Java 程序员 后端

《零基础》MySQL 连接的使用(二十),开发多年HashMap原理不知道

Java 程序员 后端

“996”为什么还没实行(1),java零基础教程视频

Java 程序员 后端

Tomcat目录结构,java基础教程第三版

Java 程序员 后端

uniapp props、$ref、$emit,如何保证高可用

Java 程序员 后端

XML简介,kafka教程尚谷

Java 程序员 后端

ThreadLocal内存泄漏分析与解决方案,java语言程序设计基础篇答案第六章

Java 程序员 后端

VBA常用语法,操作系统原理与linux实践教程申丰山

Java 程序员 后端

VIVO一面竟然翻车,含泪整理了这些Java面经,看完我悟了

Java 程序员 后端

《重构 改善既有代码的设计 3》代码的可理解性应该是我们虔诚追求的目标

Java 程序员 后端

Zookeeper原理篇-Zookeeper启动流程分析,从底层开始带你了解并发编程

Java 程序员 后端

Zookeeper系列-我保证!样样聚到!没有一句废话,今日头条面试经历

Java 程序员 后端

《黑马程序员》通讯录管理系统实战,终于搞明白了

Java 程序员 后端

Srping全注解开发---AOP模块,教科书般的排查与分析过程

Java 程序员 后端

Web开发基础:JavaScript常用类、面向对象和BOM,java中锁的实现原理

Java 程序员 后端

Zookeeper(从7个方面来了解Zookeeper基础概念),java新技术网站

Java 程序员 后端

「Java」几种典型的内存溢出案例,linux视频教程迅雷下载

Java 程序员 后端

SSM框架-SpringMVC详解,java反射和注解原理

Java 程序员 后端

String的内存分配与拼接操作,mysql数据库教程课后题答案

Java 程序员 后端

super与this在成员变量,成员方法,构造方法方面的作用

Java 程序员 后端

tomcat优化——并发和Tomcat线程数,mysql集群原理详解

Java 程序员 后端

vivo官网商城开发团队:同城双活与异地多活架构分析,java面试问项目流程

Java 程序员 后端

YYDS,瞬间秒杀全网,这套Java面试笔记可以解决90,kafka基础架构消费模式

Java 程序员 后端

《项目开发团队分配管理软件》,nginx面试题阿里

Java 程序员 后端

Spring面试题整理(1),真是经典中的经典

Java 程序员 后端

Spring面试题整理,springboot视频教程谁的好

Java 程序员 后端

数据cool谈(第2期)寻找下一代企业级数据库

数据cool谈(第2期)寻找下一代企业级数据库

面向应用的云端迁移方法-InfoQ