迁云架构实践

作者：网络转载发布时间：[ 2015/1/4 14:28:00 ] 推荐标签：云计算迁云架构

　　云计算作为信息技术领域的一种创新应用模式，自其诞生以来一直备受关注。由于其具备低成本、弹性、易用、高可靠性、按需服务等特点，近年来被看作是新一代信息技术变革和商业模式变革的核心。互联网、游戏、物联网等新兴行业纷纷积极拥抱云计算，对大部分企业用户来说，受限于传统IT技术架构的束缚，往往缺乏迁移到云计算的动力和技术实现参考。

　　传统IT架构的技术特点和面临的问题

　　企业中核心的系统通常是数据库管理系统，用以满足实时交易和分析的需求。传统的单机数据库采用“向上扩展”（Scale-Up）思路但这种方式一般只能够支持几个TB 数据的存储和处理，远不能满足实际需求。

为了达到高性能和更大数据存储容量的要求，采用集群设计的OLTP系统逐步成为主流。如图1所示，常见的企业数据库集群如Oracle RAC通常采用Share-　　Everything（Share-Disk）模式。数据库服务器之间共享资源，例如磁盘、缓存等。当性能不能满足需求时，要依靠升级数据库服务器（一般采用小型机）的CPU、内存和磁盘，来达到提升单节点数据库服务性能的目的。另外，可以增加数据库服务器的节点数，依靠多节点并行和负载均衡来达到提升性能和系统整体可用性的效果。但当数据库服务器节点数量增大时，节点之间的通信将成为瓶颈，而且处理各个节点对数据的访问控制将受制于事务处理的一致性要求。从实际案例来看，4节点以上的RAC非常少见。

　　另外，根据摩尔定律，处理器的性能约每隔18个月便会增加一倍，而DRAM的性能大约每10年才会增加一倍，使得处理器和内存的性能形成剪刀差。虽然处理器的性能在快速提升，但由于磁盘的机械转速与磁臂的寻道时间的限制，磁盘存储性能提升缓慢，硬盘的IOPS性能近10年基本没有太大提升（HDD磁盘的转速一直在7200-15000RPM)，基于HDD的磁盘阵列存储越来越成为集中式存储架构的性能瓶颈，而全闪存阵列受限于高昂的成本和擦写寿命还远达不到大规模商用的要求。

　　因此，IOE的集中存储（Share-Everything）方式存在性能、容量与扩展性的局限，同时成本居高不下。而互联网化带来的高并发，大数据的处理要求，x86和开源数据库技术的飞速发展， NoSQL、Hadoop等分布式系统技术的逐渐成熟，互联网化带来的高并发、大数据的处理要求，使得系统架构开始从集中式的Scale-up架构向分布式的Scale-Out架构发展。

　　IT互联网化带来的技术挑战与应对之道

　　Gartner的IT专家预测出了2015年的十大信息科技趋势，这些趋势被认为会在未来三年对行业产生重大影响，其中之一是“网络规模IT”，即越来越多的公司会建造类似亚马逊、Google和Facebook的应用和架构。这将使网络规模IT成为商用的硬件平台，使得新模式、云优化和软件定义方法成为主流。开发和操作的协同是向网络规模IT发展的第一步。但传统的IT系统在向互联网化方向转型时，通常需要面对以下几个技术挑战。

　　性能。用户体验是影响转化率的重要因素，据统计如果4秒钟打不开网站，将有60%的顾客会流失，糟糕体验将导致大量的客户选择放弃或从竞争对手处购买服务。如何在高并发访问的情况下保证系统的低延迟响应，以提升用户体验。

　　伸缩性。互联网/移动互联网用户的访问行为是动态的，在一些特殊的热点引爆后，流量能够通常达到平时的10倍甚至几十倍以上。如何快速响应业务爆发时的资源开销需求，提供无差别的用户体验。

　　容错与大可用性。互联网应用系统基于分布式计算架构部署，基于大量的x86服务器和通用网络设备。而机器一定会坏，当机器数量到一定规模时，小概率事件成为常态，当硬件出现故障时应该如何自动化处理，人一定会在开发中写出Bug，怎么进行系统的损害控制。如何基于单机QPS和并发数对服务端和客户端进行限流，实现动态流量分配，识别服务之间的依赖链路风险和系统重要功能点依赖，评估大可能的风险点，分布式系统大可用性故障检测，对故障模块进行隔离，对未完成事物进行Rollback，通过牺牲非关键功能通过优雅降级保证核心功能可用。

　　容量管理。系统性能一定会到达瓶颈，如何进行更科学的容量评估和扩容，自动计算前端请求与后端机器数量的对应关系，对软硬件容量需求进行预测。

　　服务化。如何将业务逻辑功能抽象成一个个原子服务，对服务进行封装和组合，并基于分布式系统环境部署，以实现更灵活的业务逻辑和流程。如何从业务视角厘清这些服务的关系，对大规模分布式系统中的单条服务调用链进行跟踪与展现，并能够及时发现服务调用异常。

　　低成本。随着系统的演进性能指标不断发生变化，如何保证以低成本满足特定访问量的要求。