论文部分内容阅读
[摘 要]随着国家颁布“互联网+”的指导意见，以及系统虚拟化、x86服务器计算能力提升、分布式技术的日趋成熟，简述了电信运营商如何使用互联网云计算平台，满足电信行业业务发展需求，改善运营商的传统IOE体系架构引发的性能问题，实现运营商去IOE的IT系统架构转型。
[关键词]去IOE 互联网+ 分布式 云化架构 虚拟化 服务化
中图分类号：TP3-0 文献标识码：A 文章编号：1009-914X（2016）29-0309-01
第1章 绪论
1.1 现状分析
在中国，最早实践“去IOE”系统转型的，是互联网用户数最多的阿里巴巴公司。阿里公司面临互联网用户交易量成倍增长的趋势，由于IBM小型机、Oracle数据库、EMC高端存储构建的系统架构存在维护成本非常高，源代码冲突，系统部署时间长，数据库连接达到上限等诸多问题，系统不能满足交易的处理要求，阿里CFO王坚在2008年提出“去IOE”概念。阿里以低成本的x86服务器代替IBM小型机，由开源My SQL代替Oracle，使用PC Server代替EMC存储，自主研发了强大的云计算平台以提供云计算服务。2013年，最后一台小型机在阿里的支付宝下线，标识了阿里完成去IOE的架构转型成功。
1.2 发展趋势
2015年7月，国务院颁发《国务院关于积极推进“互联网+”行动的指导意见》，指导传统行业需要利用信息通信技术以及互联网平台，将互联网的创新成果，深度融合传统行业，创造新的经济发展生态。
电信运营商的传统IT架构也采用IOE架构，随用户数量成倍增长，在系统运营维护时也体现出维护成本高，系统部署时间长，响应慢，容易引起用户投诉以及用户流失等诸多问题。
第2章 运营商分布式云架构实践
2.1 运营商传统IT架构
传统IOE架构采用三层架构，Web逻辑层负责接收Web应用请求，应用逻辑层负责处理业务逻辑，并根据数据层提供的数据计算，数据层负责查询返回上层数据。
2.2 分布式云架构
为实践“互联网+”与通信行业的深度融合，消除IOE架构带来的问题，我们用通信行业的号码资源为集中管理对象，构建分布式云架构的号码资源集中系统，创新IT支撑系统。
创新的分布式云架构系统，分为五层，负载均衡层、接入层、业务服务层、技术服务层、数据层。采用高内聚、低耦合、易扩展、服务化的设计原则，由去中心化的服务框架为应用提供服务。下面分别介绍五层架构级重点中间件及功能。
2.2.1 负载均衡层
负载均衡层支持软负载均衡、硬负载均衡及自定义负载均衡。由传统双机工作转变为集群工作。负载均衡通过流量分发扩展系统对外的服务能力，通过消除单点故障提升系统的可用性。负载均衡器主要功能：1、提供4层（TCP协议）和7层（HTTP协议）的负载均衡服务。2、可对后端应用服务器进行健康检查，自动屏蔽异常状态的应用服务器，待该服务器恢复正常后自动解除屏蔽；3、提供会话保持功能，在Session生命周期内，将同一客户端请求转发同一端后台的应用服務器上；4、支持加权轮询（WRR），加权最小连接数（WLC）转发方式；5、支持针对监听来分配其对应服务能达到的带宽峰值；6、可以支持公网或私网的负载均衡。负载均衡层采用集群设计，无单点，可以根据应用负载弹性扩容，不同功能模块分别申请负载均衡实例。
2.2.2 接入层
接入层支持多种接入形式，有Web管理门户，手机应用接入，各外围系统接入。
2.2.3 业务服务层
业务服务层提供多种业务逻辑服务，核心业务服务。业务逻辑服务和核心业务服务包括号段管理：号段入库、号段分配、号段启用、号段下发等；号码库存管理：号码查询、号码上下架、号码回收、号码属性管理、号码出入库、号码调拨、号码状态变更等；号码销售管理：号码选占、号码预占、制作预配预配套包、靓号减免、靓号规则查询、号码返销等；部门信息管理：员工信息同步、渠道信息同步、员工新增、部门新增等；报表管理：号码统计、号码状态统计、靓号统计等；权限管理：菜单管理、角色与员工对应关系、角色维护、菜单权限管理等；日志管理：操作日志、接口日志、号码日志等。
2.2.4 技术服务层
技术服务层包括分布式服务框架，服务生命周期管理、服务日志、服务治理、以及分布式消息服务、分布式缓存服务，分布式文件系统。技术中间件区别于传统架构体系，为了充分体现云架构的能力，需要遵守的原则如下：
1、服务拆分原则：低耦合，高内聚；服务要小，功能单一、完整；每个服务对应一个数据库；采用自下而上的思路进行服务的识别和设计。
2、缓存使用原则：尽量不缓存大对象，拆分为合适的有效的小对象；及时更新缓存中已经变更的数据；不使用不同的键缓存相同的对象，造成内存浪费；分布式缓存服务中，不能在多个线程间共享对象。
3、数据库拆分原则：数据关联的表尽量采用相同的拆分字段，保证分布在同一个数据库中
数据分布尽量均匀；避免数据热点；小数据表、静态数据表不拆分；
4、消息使用原则：没有業务限制的情况下，尽量并行；消息执行与业务系统低耦合；尽量过滤无关消息，提高处理效率；应用使用统一封装接口，无需关心底层组件。
2.2.4.1 分布式服务框架
分布式服务框架，可以采用分布式RPC框架、控制流和数据流分离，替代传统IBM和Oracle服务框架。服务提供者在服务注册中心进行注册，服务调用者就可通过服务注册中心订阅服务。客户端在不知道服务端的IP情况下，只需要知道服务名，就可以调用该服务。当服务调用失败时，框架自动重试分布式架构下其他服务提供者。服务生命周期管理需要实现自动化，经过代码编写（git），代码打包（Jenkins），代码测试，代码发布，代码监控。 2.2.4.2 分布式消息服务
分布式消息服务：分布式消息服务，可集群部署，通过web控制台管理主题、生产者、消费者等信息。消息中间件通过消息分发、消息缓存以及负载均衡技术，可以异步解耦消息，达到削峰填谷的目标。利用消息中间件可实现分布式事务、数据复制、日志同步、延迟队列、广播通知。
2.2.4.3 分布式缓存服务
分布式缓存服务：提供集群版扩展Redis性能，兼容redis协议的key-value存储服务，支持redis开源客户端直接访问。 config server为中心控制节点，负责管理所有的data server，维护data server的状态信息。data server 对外提供各种数据服务， 并以心跳的形式将自身状况汇报给config server。
2.2.4.4 分布式文件系统
分布式文件系统：采用开放存储服务，实现应用的动静态分离，可以像文件夹一样管理网站上的图片，脚本等静态资源，通过BGP网络或CDN加速方式，提供用户就近访问，有效降低云服务负载。
2.2.5 数据层
数据层采用分布式数据库，支持彈性扩展，平滑扩容，垂直拆分，數据库在线扩容、备份回滚、性能监测及分析。建立基于mysql数据库及开源产品cobar、tddl进行整合的一个平台。
第3章 去IOE化后系统提升
经过验证，去IOE后的号码集中系统性能大大提升。上线测试，新系统实时类接口平均每秒能处理订单5000tps，平台每秒处理订单40000tps。相比老系统每秒峰值处理订单2700tps左右，成二十倍提升。
3.1 分布式云化架构特点
采用分布式云化架构的创新系统，能够实现服务平滑扩展，高效灵活处理业务，比较传统的系统架构有如下特点：1、应用拆分解耦：应用可以独立扩展与伸缩，更灵活快速的应用部署，同时隔离错误2、异步与缓存：使用互联网架构的异步与缓存机制，能够降低延迟、提升用户体验；3、最终一致性：尽量不出现跨库事务，如果出现，通过最终一致性来解决；4、容错机制：系统通过故障检测、自动告警、回滚、优雅降级的方式实现容错处理；5、自动化运维：运维规范化和平台化、弹性伸缩自动化、部署自动化、故障处理自动化。
[关键词]去IOE 互联网+ 分布式 云化架构 虚拟化 服务化
中图分类号：TP3-0 文献标识码：A 文章编号：1009-914X（2016）29-0309-01
第1章 绪论
1.1 现状分析
在中国，最早实践“去IOE”系统转型的，是互联网用户数最多的阿里巴巴公司。阿里公司面临互联网用户交易量成倍增长的趋势，由于IBM小型机、Oracle数据库、EMC高端存储构建的系统架构存在维护成本非常高，源代码冲突，系统部署时间长，数据库连接达到上限等诸多问题，系统不能满足交易的处理要求，阿里CFO王坚在2008年提出“去IOE”概念。阿里以低成本的x86服务器代替IBM小型机，由开源My SQL代替Oracle，使用PC Server代替EMC存储，自主研发了强大的云计算平台以提供云计算服务。2013年，最后一台小型机在阿里的支付宝下线，标识了阿里完成去IOE的架构转型成功。
1.2 发展趋势
2015年7月，国务院颁发《国务院关于积极推进“互联网+”行动的指导意见》，指导传统行业需要利用信息通信技术以及互联网平台，将互联网的创新成果，深度融合传统行业，创造新的经济发展生态。
电信运营商的传统IT架构也采用IOE架构，随用户数量成倍增长，在系统运营维护时也体现出维护成本高，系统部署时间长，响应慢，容易引起用户投诉以及用户流失等诸多问题。
第2章 运营商分布式云架构实践
2.1 运营商传统IT架构
传统IOE架构采用三层架构，Web逻辑层负责接收Web应用请求，应用逻辑层负责处理业务逻辑，并根据数据层提供的数据计算，数据层负责查询返回上层数据。
2.2 分布式云架构
为实践“互联网+”与通信行业的深度融合，消除IOE架构带来的问题，我们用通信行业的号码资源为集中管理对象，构建分布式云架构的号码资源集中系统，创新IT支撑系统。
创新的分布式云架构系统，分为五层，负载均衡层、接入层、业务服务层、技术服务层、数据层。采用高内聚、低耦合、易扩展、服务化的设计原则，由去中心化的服务框架为应用提供服务。下面分别介绍五层架构级重点中间件及功能。
2.2.1 负载均衡层
负载均衡层支持软负载均衡、硬负载均衡及自定义负载均衡。由传统双机工作转变为集群工作。负载均衡通过流量分发扩展系统对外的服务能力，通过消除单点故障提升系统的可用性。负载均衡器主要功能：1、提供4层（TCP协议）和7层（HTTP协议）的负载均衡服务。2、可对后端应用服务器进行健康检查，自动屏蔽异常状态的应用服务器，待该服务器恢复正常后自动解除屏蔽；3、提供会话保持功能，在Session生命周期内，将同一客户端请求转发同一端后台的应用服務器上；4、支持加权轮询（WRR），加权最小连接数（WLC）转发方式；5、支持针对监听来分配其对应服务能达到的带宽峰值；6、可以支持公网或私网的负载均衡。负载均衡层采用集群设计，无单点，可以根据应用负载弹性扩容，不同功能模块分别申请负载均衡实例。
2.2.2 接入层
接入层支持多种接入形式，有Web管理门户，手机应用接入，各外围系统接入。
2.2.3 业务服务层
业务服务层提供多种业务逻辑服务，核心业务服务。业务逻辑服务和核心业务服务包括号段管理：号段入库、号段分配、号段启用、号段下发等；号码库存管理：号码查询、号码上下架、号码回收、号码属性管理、号码出入库、号码调拨、号码状态变更等；号码销售管理：号码选占、号码预占、制作预配预配套包、靓号减免、靓号规则查询、号码返销等；部门信息管理：员工信息同步、渠道信息同步、员工新增、部门新增等；报表管理：号码统计、号码状态统计、靓号统计等；权限管理：菜单管理、角色与员工对应关系、角色维护、菜单权限管理等；日志管理：操作日志、接口日志、号码日志等。
2.2.4 技术服务层
技术服务层包括分布式服务框架，服务生命周期管理、服务日志、服务治理、以及分布式消息服务、分布式缓存服务，分布式文件系统。技术中间件区别于传统架构体系，为了充分体现云架构的能力，需要遵守的原则如下：
1、服务拆分原则：低耦合，高内聚；服务要小，功能单一、完整；每个服务对应一个数据库；采用自下而上的思路进行服务的识别和设计。
2、缓存使用原则：尽量不缓存大对象，拆分为合适的有效的小对象；及时更新缓存中已经变更的数据；不使用不同的键缓存相同的对象，造成内存浪费；分布式缓存服务中，不能在多个线程间共享对象。
3、数据库拆分原则：数据关联的表尽量采用相同的拆分字段，保证分布在同一个数据库中
数据分布尽量均匀；避免数据热点；小数据表、静态数据表不拆分；
4、消息使用原则：没有業务限制的情况下，尽量并行；消息执行与业务系统低耦合；尽量过滤无关消息，提高处理效率；应用使用统一封装接口，无需关心底层组件。
2.2.4.1 分布式服务框架
分布式服务框架，可以采用分布式RPC框架、控制流和数据流分离，替代传统IBM和Oracle服务框架。服务提供者在服务注册中心进行注册，服务调用者就可通过服务注册中心订阅服务。客户端在不知道服务端的IP情况下，只需要知道服务名，就可以调用该服务。当服务调用失败时，框架自动重试分布式架构下其他服务提供者。服务生命周期管理需要实现自动化，经过代码编写（git），代码打包（Jenkins），代码测试，代码发布，代码监控。 2.2.4.2 分布式消息服务
分布式消息服务：分布式消息服务，可集群部署，通过web控制台管理主题、生产者、消费者等信息。消息中间件通过消息分发、消息缓存以及负载均衡技术，可以异步解耦消息，达到削峰填谷的目标。利用消息中间件可实现分布式事务、数据复制、日志同步、延迟队列、广播通知。
2.2.4.3 分布式缓存服务
分布式缓存服务：提供集群版扩展Redis性能，兼容redis协议的key-value存储服务，支持redis开源客户端直接访问。 config server为中心控制节点，负责管理所有的data server，维护data server的状态信息。data server 对外提供各种数据服务， 并以心跳的形式将自身状况汇报给config server。
2.2.4.4 分布式文件系统
分布式文件系统：采用开放存储服务，实现应用的动静态分离，可以像文件夹一样管理网站上的图片，脚本等静态资源，通过BGP网络或CDN加速方式，提供用户就近访问，有效降低云服务负载。
2.2.5 数据层
数据层采用分布式数据库，支持彈性扩展，平滑扩容，垂直拆分，數据库在线扩容、备份回滚、性能监测及分析。建立基于mysql数据库及开源产品cobar、tddl进行整合的一个平台。
第3章 去IOE化后系统提升
经过验证，去IOE后的号码集中系统性能大大提升。上线测试，新系统实时类接口平均每秒能处理订单5000tps，平台每秒处理订单40000tps。相比老系统每秒峰值处理订单2700tps左右，成二十倍提升。
3.1 分布式云化架构特点
采用分布式云化架构的创新系统，能够实现服务平滑扩展，高效灵活处理业务，比较传统的系统架构有如下特点：1、应用拆分解耦：应用可以独立扩展与伸缩，更灵活快速的应用部署，同时隔离错误2、异步与缓存：使用互联网架构的异步与缓存机制，能够降低延迟、提升用户体验；3、最终一致性：尽量不出现跨库事务，如果出现，通过最终一致性来解决；4、容错机制：系统通过故障检测、自动告警、回滚、优雅降级的方式实现容错处理；5、自动化运维：运维规范化和平台化、弹性伸缩自动化、部署自动化、故障处理自动化。