云应用成熟度评估
云应用成熟度模型提供了一个简单的方法来评估应用程序的云成熟度水平,正如Richardson成熟度模型用来评估REST API的成熟度一样。成熟度模型为提高应用程序在云中的可靠性、弹性以及扩展性提供了演进路标。
下表列出了四个层次,Level 3表明最高的成熟度层次,Level0表明应用程序还不是云感知的。
成熟度0:虚拟化级
Level 0 是最低的成熟度层次。一个用程序只要正常运行在虚级化资源上(例如虚机)上就算是Level 0。应用程序的实例从某一镜像中启动,或者利用脚本动态启动。这种程序往往耦合紧密,各组件之间显式的依赖于彼此。
成熟度1:松耦合级
Level 1 在 Level 0 的基础上引入松耦合的要求。松耦合意味着组件不需要和彼此紧密地依赖。如果一个组件故障了,其它组件不受影响,整个应用程序依旧能够正常的工作。松耦合的组件之间往往通过异步交互,能让应用程序更容易扩展。
松耦合的另一方面要求组件间提供的接口与具体实现解耦,服务可以透明地从一种实现变更到另一种实现或者同时支持多种不同的实现。
将计算和存储分离也有利于实现松耦合。通过将计算和存储分离,应用程序不再受低层存储机制的影响,使得存储可以独立地不受计算资源约束地去扩展。这对于Level 2中应用程序可以运行在不同云基础设施上的能力来说至关重要。这里将计算和存储解耦,不仅仅指服务所消费和管理的数据存储,还包括log和配置数据等各种存储机制。
成熟度2:抽象级
该层次引入应用程序可以运行在不同云计算基础设施上的能力。这是个挑战,因为现今主要的云计算平台对于相同服务的接口和相同虚机镜像的格式都是不同的。这限制了云计算应用程序可以在不同云提供商的平台上运行迁移。工程师必须实现一层云隔离抽象层,使得应用程序实例可以运行在任何虚拟化基础设施上且功能正常。这是个额外的工作,需要仔细评估成本/受益。这项工作带来的收益是应用程序不再和供应商的特定接口绑定,避免了供应商锁定,为运行时服务迁移提供了可能性。
除了与基础设施解耦,Level 2级别的应用程序不应该依赖特定的服务实例的有效性,完全和其它服务的故障是隔离的。应用程序和它们的用户对于应用程序的组件故障是无感知的,一种实现的方式是采用Netflix在基于亚马逊云计算平台上实现的电路开关(Circuit Breaker)设计模式。
最后,因为服务实例随时可能故障,所以其它实例要能够启动并替代故障实例。这可以通过设计无状态服务来实现。
成熟度4:自适应级
Level 3 表示应用程序被设计得充分符合云计算环境的特有特征。这一层次的应用程序可以部分或者全部地从一个云环境无缝地迁移到另一个云环境,没有任何服务的中断。这要求它们具备所有前一级成熟度的能力要求。云中的某种“主控程序”可以控制应用程序的编排和迁移,决定何时将应用程序迁移到何地。例如,应用程序可以将一部分从一个云环境迁移到另一个云环境中以便降低在高峰值负载时的资源租赁成本或者由于环境不稳定带来的服务质量退化。
Level 3 级别的应用程序可以充分利用云的弹性和可扩展性,根据负载动态的实例伸缩。应用程序可以通过增加实例水平扩展,也可以通过增加虚拟CPU或者内存纵向扩展。应用程序需要提供元数据,使得基础设施可以对特定服务的扩展做出合适决定。
运维策略
本节包含云计算应用程序的关键运维策略。运维策略指应用程序如何部署和操作,以及与别的系统组件进行交互。运维策略重点关注整系统全生命周期端到端的使用过程。
确保冗余
应用程序组件、虚机、网络、存储以及其它云基础设计都有可能发生故障。在运维时考虑冗余,可以降低这些故障带来的影响。例如,如果云环境部署在多个地理地区,应用程序和它依赖的组件可以在多个地区进行冗余,如果某一个地区发生了故障,业务可以被重镜像到正常的区域,保证了业务的持续性。
使用缓存
缓存是一个在传统系统以及基于云环境的系统中都广泛使用的技术。通过将服务经常使用的数据在服务本地缓存可以提高系统性能,同样可以提高容错性,降低网络带宽消耗。当云服务提供商针对网络带宽统计计费时,缓存可以节省运维成本。
安全访问API
安全API访问保证应用和服务只被有权限的客户端进行访问。如早先解释的,不能保证部署在云上的服务是安全的。一个解决方法是在每个服务前面加设一个API管理代理。这不仅仅用来限制访问,还可以认证以及记录API被哪些客户端如何使用。Netflix使用这种方法限制核心共享服务的访问。利用这种方式,Netflix确保服务访问层仅仅路由自己开发的组件发送的请求。
分阶段部署
在大的分布式系统中,软件升级可能因为bug、副作用或者未预见的兼容性问题导致不可知的问题。当系统变得更大、更动态以及更复杂,更需要减少这类事情的发生。在敏捷开发实践中,不同团队更小更频繁地发布也会增加这种风险。
一种控制风险的方式是小范围的升级并且仔细监控新版本的行为。新和旧的版本并存,避免新版本搞挂整个系统。如果小范围的部署成功,则可以在更大范围内部署新实例的虚机,同时老版本的虚机继续运行以支持容错。如果新的版本失败了,则请求被简单地重镜像到老版本实例上。如果新的版本最终一切成功,则老版本的虚机实例可以被关闭下线。
预防区域性故障
按照区域将云资源进行分组,每个区域独立并与其它区域故障隔离。亚马逊就将其EC2按照地理位置进行了区域划分。从亚马逊的云服务中断历史可以看出,中断往往会影响整个地区。因此有必要在云应用部署时考虑弹性以避免区域性的故障。例如,Netflix将其全部服务在不同区域进行冗余,如果一个区域故障了,另一个区域可以接管失败的区域继续处理业务。这需要数据进行跨区域的同步。
应用程序在区域间可以部署成主备或者双活模式。主备模式下,应用程序的实例在两个区域都运行,但是只有一个处于激活态,一个全局的负载均衡器负责决定将客户请求发送到哪一个处理点。
在双活模式下,部署在两个位置的应用程序都处于激活态,同时运行,处理不同用户的请求。如果一个地区故障了,全局负载均衡器负责将所有负载重镜像到仍然正常的区域。双活模式提高了云资源的利用率,并且可以由离用户较近的服务处理相应用户的请求。
减少区域间时延
如果云环境地理位置分布较远,或者一个数据中心被分割到多个区域,网络延迟将会成为一个关键因素。
对于需要低时延的服务,尽量将它们部署在同一区域。一个挑战是云上部署的应用程序并不知道其物理位置。仔细地对数据进行分析可以洞察一些应用在云中的物理位置特征,但是要知道,这些会随着时间发生变化,超出应用所有者的控制。
高带宽消耗服务云外部署
考虑将数据存储到哪里可以降低数据传输开销。例如,亚马逊对于EC2和外部公共网络间的数据传输进行计费。对于某些应用程序,这笔开销可能会非常昂贵。将数据存储在云外,例如CDN上,可以大大降低成本。
对依赖进行抽象
避免建立客户和服务间的静态依赖。例如,应用程序可能依赖于存储服务,但是随着时间推移,接口、实现以及存储服务的位置都可能发生变化。例如应用程序可能迁移到一个新的云服务提供商,它的等价基础设施服务的接口以及地址等都不同。对API进行管理,对底层服务的实现进行抽象,或者采用更加松耦合的REST API,可以让组件彼此独立地进行演进。
总结
当技术持续快速演进,开发者需要持续地提升自己的技能 - 学习以及采用新的技术来进行架构设计和开发,以构建更加鲁邦的云应用程序。为了成功的提升云应用的能力,组织需要做如下事情:
- 为员工的开发能力培训进行投资,确保员工掌握构建云计算应用程序的技巧。
- 找出办法,避免开发人员浪费大量时间从事低层次、低价值的技术活动。
- 发布的大规模复杂应用应该是易于修改且可以容易和已有系统进行集成的。
对开发者的建议
由于云计算领域特有的特征,应用程序开发者需要掌握建立分布式系统的设计原则和新的设计模式。这些原则和模式帮助云应用程序具备弹性扩展、高容错、以及更有效地进行资源利用。
本文描述的策略主要针对分布式系统的内在挑战。这些设计模式都是在大规模云应用程序中被开发人员证明是有效的。毫无疑问,当开发人员面临新的云环境挑战,为了更优雅的处理这些问题,他们会持续地创造出新的设计模式。
云应用成熟度模型则为开发者提供了评估他们云应用成熟度的标准,这可以为云应用程序云成熟度演进做决策。
云平台需求
以下需求提给云计算提供商:
- 支持云计算的行业标准,最好是开发标准或者是被广泛支持的事实标准。这些支持可以防止应用程序锁定到特定的云供应商,以及让应用程序容易地在混合云环境中无缝运行。
- 提供标准的镜像,和其它云计算平台所提供的镜像保持一致。例如要开发一个私有云,考虑创建的镜像和亚马逊EC2提供的镜像一致,如果应用程序有计划未来一部分移植到亚马逊的云平台上。
- 支持数据的亲和性(支持数据的生产/消费者模式)。
- 使用标准的版本控制脚本去创建和配置虚拟机。
我们正处于一个由云计算引起的重大技术变革中,促进开发者和企业进入一个真正的分布式技术的世界。技术人员有机会通过采用新的方法和技术开发适应云计算特点的应用程序,提供业务转型的真正价值。ODCA(OPEN DATA CENTER ALLIANCE)希望本文为学习和研究面向云计算的应用程序架构技术的开发人员提供起点。ODCA认为提升开发人员的开发技能,以满足不断增长的云应用架构的软件需求,需要持续地教育和培训,使开发人员专注于技能发展以及工作领域的创新。
参考
-
“Architectural Patterns for High Availability”
www.infoq.com/presentations/Netflix-Architecture -
C loud Architecture Patterns
www.amazon.com/Cloud-Architecture-Patterns-Using-Microsoft-ebook/dp/B009G8PYY4/ -
“ Cloud Characteristics, Principles and Design Patterns”
www.gartner.com/document/2081915 -
“ Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications”
http://msdn.microsoft.com/en-us/library/dn568099.aspx -
“ Building Cloud-Aware Applications”
www.slideshare.net/cobiacomm/building-cloudaware-applications [slides 17, 18, 19, 31] -
“ Searching for Cloud Architecture…”
http://blog.cobia.net/cobiacomm/2011/11/25/searching-for-cloud-architecture/ -
“ Maximizing Cloud Advantages through Cloud-Aware Applications”
www.intel.com/content/dam/www/public/us/en/documents/white-papers/maximizing-cloud-advantages-through-cloud-aware-applicationspaper.pdf [page 6] -
N etwork Latency between U.S. cities (AT&T)
http://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html -
“ The Fallacies of Distributed Computing Reborn: The Cloud Era – New Relic blog”
http://blog.newrelic.com/2011/01/06/the-fallacies-of-distributed-computing-reborn-the-cloud-era/ -
“ 5 Lessons We’ve Learned Using AWS” – Netflix Tech Blog
http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html -
“ Optimizing the Netflix API” – Ben Christensen
http://benjchristensen.com/2013/04/30/optimizing-the-netflix-api/ -
“ Architecting Applications for the Cloud: Best Practices” – Jinesh Varia, Amazon Technical Evangelist
http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf -
“ Lessons from Distill” – Michael Forhan, AppFirst
www.appfirst.com/blog/lessons-from-distill/ -
“ Understanding Security with Patterns” – Prof. Peter Sommerlad, Tutorial T39 @ OOPSLA 2006
http://wiki.hsr.ch/PeterSommerlad/files/T39-Sommerlad.pdf -
“ How it Works” (Circuit Breaker implementation in Hysterix open source library) – Netflix
https://github.com/Netflix/Hystrix/wiki/How-it-Works -
N etflix Shares Cloud Load Balancing and Failover Tool: Eureka! - Netflix Tech Blog
http://techblog.netflix.com/2012/09/eureka.html -
“ Dystopia as a Service” – Adrian Cockcroft, Netflix
www.slideshare.net/adrianco/dystopia-as-a-service -
“ Netflix and Open Source”
www.eiseverywhere.com/file_uploads/c6b285b64a18cc2742c0fb20061d6530_OBC_BreakoutSession_AdrianCockcroft_1pm.pdf