0 引言
随着信息安全事件的频发以及业务对数据存储、需求响应能力要求的提高,各行各业都在进行去IOE尝试,即去掉业务系统架构的IBM小型机、Oracle数据库、EMC存储。文献[1]中介绍了阿里巴巴去IOE的初衷、IOE的技术替代等,最终阿里巴巴以其强大的技术团队成功实现去IOE;文献[2]中介绍了电信运营商去IOE的进程：针对核心系统逐步实现去IOE,针对非核心新建系统直接采用非IOE架构建设,并且还介绍了电信运营商在去I、去O、去E中存在的技术难点和对策方案;文献[3]中介绍了电信运行商存在去IOE的诉求,但是同时也存在很多困难,如内部技术实力缺乏、数据混乱不易迁移以及电信级服务具有不能出错的要求等;文献[4]对阿里巴巴去IOE进行了分析和评价,介绍了金融业的现状,并讨论了金融业去IOE的必要性,最后提出了金融业可借鉴的阿里巴巴去IOE的经验;文献[5]国网黑龙江电力从信息安全方面考虑,研发了一套高性能数据库方案实现了财务管控系统的去O;文献[6-8]对国内企业如互联网、电信运营商、金融、能源在去IOE中面临的问题以及采用的解决方案进行了综合讨论,提出应该结合自身的成本、技术积累等决定是否去IOE,不能盲从。
即使已经有不少行业针对去IOE做了很多研
究[9-12],但是针对电力信息业务去IOE的研究还不是很多,尤其结合信息业务的特点来决定是否去IOE的研究基本没有,因此本文首先分析成功去IOE的系统的业务特点,基于研究结果,探讨电力信息系统中满足去IOE条件的业务,为电力信息业务去IOE指明方向,具有重要参考价值。
1 去IOE业务本质研究
1.1 阿里巴巴去IOE
由于IOE技术体系架构已经不能满足海量数据处理、大规模并发访问等业务,并且一个企业过于依赖专用的硬件设备比较危险,因此,阿里巴巴于
2008年提出去IOE战略。
1999年底,随着互联网高潮来临,中国网络购物的用户规模不断上升;从2009年开始,中国网络购物市场交易规模开始突飞猛进,2009年到2016年间中国网络购物市场延续用户规模、交易规模的双增长态势,2009—2016年中国网络购物市场交易规模增长趋势如
图1 2009—2016年中国网络购物市场交易规模增长趋势Fig.1 The trade scale growth trend of China online shopping market among 2009-2016
淘宝、天猫在所有网络购物平台中交易量居首,因此,随着网络交易规模的扩大,阿里巴巴业务量急剧增长,尤其是“双11”购物狂欢节,日交易量达到顶峰。2009—2016年淘宝天猫双11成交额如
图2 2009—2016年淘宝天猫双11成交额Fig.2 The double 11 turnover of Taobao and TMALL websites among 2009-2016
爆炸式增长的业务,对阿里巴巴传统IT系统的计算能力以及存储能力带来了很大的挑战。阿里巴巴传统IT系统的搭建采用IBM小型机、Oracle数据库、EMC存储设备,业务的增长造成系统规模扩大、复杂度提高,其管理和维护都面临极大的困难。在处理海量数据的并发访问时,“IOE”体系就像是一个集中式的强大单点,这个集中式的强大单点具有稳定性差、容灾切换复杂、扩容能力有限等缺点,严重制约了阿里巴巴业务的发展。此外,由于阿里巴巴处于业务高速增长的阶段,对IT系统和架构的灵活性具有较高的要求,因此,产品体系相对封闭的“IOE”架构也限制了其自身技术潜力的发挥。
在这种情况下,阿里巴巴集团于2010年1月正式启动了“去IOE”战略。阿里巴巴的“去IOE”行动是在不断地尝试过程中循序渐进、依次深入进行的,主要分为以下3个阶段。
1）淘宝商品库尝试“去O”。实现商品库Oracle数据库的读写分离,把不重要的业务迁移到MySQL上,梳理核心业务接口,为其未来迁移到MySQL做准备。
2）淘宝三大库“去IOE”。2011年7月,淘宝最核心的用户中心库、商品库完成从集中式到分布式的迁移,标志着用户库和商品库实现了“去IOE”;此外,淘宝的交易库也逐步向MySQL迁移,2011年9月交易库完成“去IOE”。
3）阿里巴巴内部全面推行“去IOE”。2013年5月,阿里巴巴的最后一台IBM小型机在支付宝系统中下线;2个月之后,淘宝的最后一个Oracle数据库在淘宝重中之重的广告系统中下线。
图3 阿里巴巴集团去IOE进程Fig.3 The removing IOE process of Alibaba
阿里巴巴集团去IOE进程如
阿里巴巴去“IOE”的成功实施,不仅保证了集团快速增长的业务需求,而且能够应对“双11”零点的单点极大峰值情况,同时,阿里巴巴团队积累了大量的技术经验,业务架构更加开放灵活,降低了对设备厂商的依赖,提高了框架和技术的自主把控能力。
1.2 12306网站去IOE
铁道部的12306网上购票系统于2011年年底全面投入使用,新颖的在线购票方式方便了大家的出行,然而由于2012年春运访问量超出设计预期,导致网站出现页面访问过慢、用户无法登录、查询和下单出错、后台系统过载等一系列问题,引起用户怨声载道。
针对该问题,2012年,中国铁道科学院电子计算技术研究所选择Pivotal GemFire分布式内存计算平台（Distributed In-memory computing）对12306网站的余票查询系统和订单查询系统进行改造,大大加快了查询速度;但是由于12306网站访问峰谷的查询流量有天壤之别,在成本和并发能力之间不能做出好的平衡,2015年,通过阿里云的弹性和按量付费的计量方式,12306网站把查询系统放在云上,实现了查询系统的去IOE[13]。
查询业务占12306网站访问流量的90%,与阿里云的合作大大减少12306网站的压力,根据访问峰谷弹性购买云服务的机制,不仅保证访问高峰时期网站具有高效的查询效率,而且在访问低谷时期节省资源、减少成本,有效地化解了12306面临的困境。
1.3 去IOE业务本质
上述2个实例表明,阿里巴巴实现了全网的去IOE,12306网站仅是实现了查询系统的去IOE。去IOE能够以较低成本根据业务流量比较容易地实现横向扩展,而且可以摆脱对国外产品的依赖,保证系统的安全性。为什么12306网站的订票系统不采用此技术,而仍然采用传统的IOE架构呢?可以从以下3点进行讨论。
1）业务的关联性。阿里巴巴中每一类商品的交易都是独立的,交易操作只会造成该类商品的数量发生变化,而不会影响其他商品的数量;而12306网站中的车票一旦发生交易操作,则会影响该次列车所有里程之间的车票数量发生变化,假设一次列车所经站点为北京、保定、石家庄,此时下单一张北京—石家庄的车票,那么北京—石家庄、北京—保定、保定—石家庄的所有余票数量都会发生变化,这些余票数量通过复杂的算法计算得到。由此可知,阿里巴巴中商品的交易业务没有关联性,无关联的业务可以进行并行处理,采用分布式架构对此类业务是很好的解决方案,随着业务量的加大,只需横向增加计算、存储资源就可以轻松应对;而12306中车票的交易业务之间具有强关联性,采用串行处理方式：一次业务的执行,必须对其他业务加锁,直到此次业务执行完成,才能对其他交易解锁执行,此类业务采用去IOE技术时,采用的x86处理器性能远远低于小型机,而且增加了I/O开销,反而降低了业务处理速度。
2）数据库读写速度。IOE中的Oracle是一个高效率的适应高吞吐量的数据库,适应各种安装环境;去IOE则是使用MySQL代替Oracle,MySQL在不需要事物化处理时被认为是一个较好的管理工具。对于关联性业务,一个业务数据的改变,使其他业务数据也一定会发生变化,需要对数据库进行多次读写操作,因此数据库需要具备较快的读写速度,通过大量实验证明,Oracle读写速度优于MySQL,因此串行业务需要谨慎考虑去O。
3）系统性能。阿里云系统是典型的分布式架构,和HPC系统相比具有可伸缩性强的优点,随着并行业务的增多,分布式系统通过增加成本较低的计算节点以满足要求,但是处理串行业务时,重点考验单个节点的计算能力,此时只有HPC系统才能保障业务处理效率。
上述论述证明,串行任务对单个计算节点的数据处理能力、数据库的读写速度等都具有较高要求,而去IOE的分布式系统因为采用低性能的x86处理机、MySQL数据库而不能达到性能要求,所以该类业务系统不适合实施去IOE;独立的、无关联性的业务可以并发处理,可以通过横向扩展计算节点来提高业务处理速度、数据存储空间,因此该类业务系统可以进行去IOE尝试。
2 电力信息业务去IOE探讨
电网具有生产方式多样、运行方式复杂的特点,而且随着国家电网公司提出建设坚强智能电网、建设“三集五大”体系,电网积累了大量运营数据：体量大、类型多、价值高、速度快。面对电力负荷的快速增长以及基于大数据进行电力分析和预测的需求,国家电网现有系统已经不能满足业务变化需求,通过考察借鉴互联网公司的架构变迁经验,电网公司决定实施去IOE,转而采用具有弹性结构的分布式系统。
国家电网公司SG-ERP平台按5条主线实现了对“SG186”八大业务的融合,5条主线如下：人财物集约化管理、能量全过程管理、资产全寿命管理、客户全方位管理
