12306系统升级对电力营销系统改造的启示
中国铁路客服中心12306网站，是集全国铁路客运与货运一体的实时交易系统，为社会和铁路客户提供客（货）运服务、行包服务、餐饮/特产等服务业务。
网站承载着千家万户出行重托的相关服务业务，每逢节假日尤其是春运期间的访问高峰，系统压力巨大。据相关报道， 2012年春运高峰期间，日点击量最高达到14亿，访问人数达2000万，高并发访问导致12306几近崩溃。
自2012 年3月开始，经过多方论证与体验测试，12306系统最终通过运用云计算与分布式内存数据库，历经三年，逐步升级改造，终于破解了“高流量和高并发”的难题，更好的为务广大民众便捷出行服务，同时，也为国内大型公共事业服务系统技术升级提供借鉴。
1、12306系统业务之痛点与难点
通过分析铁路官网公开的相关数据，导致12306系统崩溃的主要原因是海量的查询请求没得到及时响应。造成海量的查询请求的原因主要有两个方面，一是购票刚需，没有购到票的用户会不停的去操作系统；二是12306系统余票查询业务十分复杂，这两个因素耗尽了系统的I/O与CPU资源。
2、12306余票计算、查询的烦恼
首先，网络阻塞的困扰。在电商时代“秒杀”对大家来说已经不陌生了，“秒杀”成功与否往往取决于网络的快慢。网络是12306购票系统的唯一入口，春运期间12306的网络24小时都处于高拥堵状态，只有幸运儿才能够“秒杀”成功。
其次，服务器集群资源不能按业务量的情况灵活弹性伸缩。技术革新前的12306系统服务器集群是典型传统的三层架构设计，由数百台Web服务器集群和应用服务器集群构成应用前端，64台数据库小型机余票计算集群和订单处理服务器集群构成后端[1]，如此庞大的服务器集群管理、维护和扩展都是棘手的问题。
3、12306系统技术破冰之旅
为改善旅客网络购票体验，12306在铁科院与铁路总公司，建设了两个生产中心，同时为解决有计划、短暂性、难预测的业务量带来的系统高负载、高并发的问题，将消耗服务器资源最大的大部分查询业务放在公有云上；将网络带宽从1.5G逐年扩充到12G；应用架构上，在不改变业务逻辑的基础上，将订单生成与订单查询分开处理，使订单查询速度提高了十倍；每日放票次数由4逐步提高到了21次；在线人数限制从1万次到2014年后不再做限制；订单处理速度从每秒200张逐步提升到每秒1032张，至此这个处理速度足以满足旅客的购票需求[1]。
自2012年春运后到2015年春运前，12306客票系统在网络带宽、服务器资源、系统架构等方面做出一系列尝试，在2015年春运期间，12306网站基本满足了旅客购票需求，证明了这一系列技术升级改造是成功的。
4、12306系统技术改造经验总结
参考铁道科学研究院朱建生副所长的观点[2]，12306系统在2015年顺利通关，主要归功于系统采取了以下升级措施：
租赁公有云计算资源分担系统查询业务，在业务高峰期间分担了大部分查询请求压力。
双中心运行机制，增强系统的可靠性、保障系统持续稳定运行的同时提升了系统性能。
扩充网络带宽，同时建立监控调度机制，依据流量情况灵活调整，实时响应旅客的购票诉求。
运用新技术手段，屏蔽抢票软件恶意操作消耗流量，保证系统健康运行。
制订多视角的应急预案，实时响应突发情况。
技术改造之后的12306系统，查询时间缩短了75倍以上，单次查询时间从之前的15秒左右下降到0.2秒以下，效率显著提高[3]。改造后的技术架构体系用十几台X86服务器解决了以前数十台小型机都解决不了的余票查询问题，既提升了系统性能，又节省了设备投资成本。显然，以云计算和分布式内存数据库为主体的可弹性扩展平台架构改造，在这次成功的技术改造中功不可没。
二、改造后12306技术架构剖析
从2011年上线至2015年春运顺利通关，12306网站的五年技术升级改造及演进，其系统架构示意图如下：
1、”混合云“架构设计
铁路总公司数据中心和铁科院数据中心为12306系统的两个内部生产中心，阿里云为12306系统互联网端应用作为余票查询功能的补充。
2、75%的查询业务都放在“云”上
将非核心业务的查询请求采用租赁的方式托管给阿里云，在不改变业务逻辑的基础上，既解决了75%查询流量消耗难题，又避免系统大面积改造的困境。
3、高可用性的容灾设计
铁路总公司与铁科院两个生产中心互为备用、互为灾备，部分查询请求操作由阿里云提供服务，解决了海量查询引起的高并发负载问题，减轻生产中心负载压力，提升了系统的可靠性。
4、可持续的服务应用保障
铁路总公司与铁科院两个生产中心并行运行，同时提供购票服务，当其中某个生产中心发生故障时，另一生产中心可以瞬间接续服务，从而保证应用不中断，不会影响到用户正常购票。
5、查询业务托管
租赁第三方服务资源，将需要最耗资源的余票查询请求托管给阿里云处理。为了保护用户的信息安全，用户在12306上注册的档案资料不同步阿里云上，采用WEB服务器集群、缓存服务器集群、余票查询/计算集群三大集群服务与阿里云进行服务交互[1]，从而保护了用户的隐私信息。
三、对电力营销系统技术升级的启示
1、电力营销业务应用系统面临的挑战
电力营销业务应用系统管理的用户数量巨大，业务多且逻辑复杂，实时性要求高，社会影响力深远，与当初的12306系统一样，同样面临着海量事务高速并发处理的问题。
当前运行以存储过程为核心的营销业务应用系统采用传统三层技术架构体系，自2008年上线以来，经过不断的优化与完善，各方面性能已经尽其所能的优化，再提升的空间十分有限了。
由于目前大部分功能为电力公司内部应用，系统面临的负载压力尚未明显体现。随着售电市场进一步开放，电力营销服务也将由相对单一封闭的供电服务走向开放多元的能源互联网市场，服务方式也由原来的单一柜台业务趋向多元化、智能化、互动化、可视化发展。当电与普通商品一样参与到市场交易时，会有越来越多的原内部操作功能，开放给用户互联互通，进行数据交互。系统的用户数也将由内部作业人员操作走向消费者自主操作。
由此可见，在以客户为中心的“互联网+新型营销”体系下，电力营销系统的用户数、系统的并发操作量将以几何级倍数增长，这对当前单体数据库集群的架构，以内部使用为主的核心系统来说是个严峻考验。
2、电力营销系统技术升级是势之所趋
随着能源互联网新生态的逐步构建，电力营销系统在支撑传统供电服务的基础上也需要注入“互联网+”基因，参与到电商时代各类运营活动中，在稳固既有电力市场的同时，拓展新兴能源市场。
处于转型时期的电力营销系统将面临着海量查询诉求带来的高流量、高负载、高并发的压力，主要将体现在以下几个方面：
外部客户访问电力营销系统已经成为现实需要，随着更多业务向运营发展，客户互动需求还会大量增加，如紧随当前消费潮流，仿效电商平台做一些类似于“双十一”的秒杀促销活动，这种临时性、高并发、高负载的访问量是当下架构体系难以支撑的；
能源物联（如智能电网）和综合能源服务的发展会产生大量的采集计量数据，围绕着以客户为中心的业务应用将明显提升数据处理时的关联度。此外，电力交易的开展要求营销电费核算与交易结算的交互实时、准确，这些都将对传统营销的三层架构和业务及数据的处理能力提出新的挑战；
随着市场的进一步发展，电力营销业务的多变和快速迭代特点将更加明显，例如微服务等应用将越来越多，这也促使传统营销系统必须升级以应对这些变化。
因此，电力营销业务系统需要顺应当前的潮流，未雨绸缪，做好信息化支撑的技术变革以迎接新的挑战。
3、电力营销业务应用系统破解业界难题的设想
当企业级客户服务系统架构体系无法满足爆炸式增长的业务需求时，通常从以下两个方面着手解决，一是替换硬件设备，更换性能更高的服务器，这种做法操作起来很简单，但需要以高昂的更换成本以及承担巨额的机房与网络建设投资。二是从软件平台架构着手,需要对系统进行深度技术升级改造，采取弹性可伸缩的架构设计，改造后可以起到持续发展的效果。
针对软件平台，如果要推翻以前的架构，重建系统，那是个大工程，除非有下列三种情况：
组织结构进行了重构，业务流程也发生了重大变化。原有系统已不能再支撑业务的正常开展，不得不弃用原有系统，重建新系统。
原来的技术体系已经不能适应时代发展需求了，软件生命周期面临结束，就算升级改造也没有多大意义。
当前正在运行的系统已经做了充分优化，虽然还可以继续优化，但无法满足日益增加的业务需求，更无法适应用户极致体验的时代诉求。
很显然电力营销业务应系统就属于上面第三种情况。12306系统在不改变子系统业务逻辑的情况下，成功的完成了技术升级改造，为电力营销业务应用系统升级改造提供了很好的启示。以下为笔者对电力营销业务应用系统技术升级改造提出的设想：
（1）用云平台架构解决资源弹性伸缩需求
目前的营销业务应用系统最大的痛点在于：随着业务的扩大，服务器集群无法弹性伸缩扩展，限制了营销业务的发展。借鉴12306的经验，可以应用云计算搭建一个虚拟化云平台，构建一个可扩展的云应用平台架构，提升硬件设备的灵活扩展能力，从而实现服务器资源可动态配置，应用程序可灵活、快速灰度发布的机制；当网络带宽不够用时，可以根据访问流量自适应增加带宽；当服务器 CPU 到达预警临界值时，可以从云平台资源池获取虚拟机资源来分摊负载，从而化解系统负载压力。
借鉴12306系统业务改造思路，可以将核心业务拆解逐步演进。现有营销业务应用系统的22个功能模块，根据当前业务发展的热点诉求及业务逻辑划分优先级，逐步拆解成多个子系统，改造完善后循序迁移到资源丰富的云平台上。
上云后的业务子系统可根据业务开展情况，“按需”获取虚拟服务器资源，网络带宽可以根据云平台监控中心进行灵活的适应性调整。这样可以将高流量、高并发的业务功能逐渐放在云上处理，从而减轻核心数据库的压力，并为未来临时性，难预测、高并发，高负载业务开展做好铺垫。例如在开展缴电费发红包促销，“电力双十一”秒杀等“互联网+”运营活动时，系统就可以通过弹性可伸缩的架构体系来灵活配置系统资源，保证电力营销业务持续、稳定的开展。云化后的电力营销系统示意图如下：
（2）用分布式内存数据库技术为查询提速
面对海量、高并发的实时查询请求，现有的单体数据库集群架构是无法实现数据资源弹性伸缩，当大量实时的请求没有及时响应，内存资源将耗尽，这会导致数据库服务器崩溃。
为解决单体数据库系统集群的性能瓶颈，12306系统在改造过程中引入分布内存网格数据库技术，这给电力营销业务应用系统数据库分布式改造做了很好的启示。
电力营销系统因其业务逻辑十分复杂，加上数据量庞大，导致其数据库模型也异常繁杂。数据库核心实体之间、核心实体与外部系统实体之间存在着强依赖关系。应用虚拟化技术，加上成熟的分布式数据库架构，将若干台PC服务器集群的内存集中起来，组成数十TB的内存资源池供实时计算使用，可以将全部数据加载到内存中，进行内存计算，解决电力营销系统海量高并发的数据存储与访问问题。
由于内存计算过程全部在内存中进行，不需要频繁的读写磁盘，只需定期将数据写入到磁盘，并且通过分布式集群架构保障，同一数据将在集群中备份多份，万一其中某台设备出现故障，其它设备上还有同步或异步备份的数据，不用担心数据丢失。经过分布式数据库改造后，为企业共享数据中心建设打下良好的基础。
（3）借鉴混合云思路为促销助力
在互联网+营销时代，通过红包促销是必不可少的手段之一。2015年春晚期间，微信摇一摇互动总量超过了110亿次，峰值达8.1亿次/分钟，送出红负1.2亿个，同一时间段，支付宝红包首页被点击次数为8.832亿次/分钟[5]，当前企业级的客服系统是无法支撑如此巨大的并发量的。
如今电力营销业务应用系统正处在从幕后逐步走向前台阶段，注册用户数将会越来越多。如果在此基础上再做一些促销活动，势必会吸引广大用客户在活动期间集中频繁的注册，当前系统的架构与设备负载能力显然无法实时响应。
虽然电力营销业务系统可能不会遇到像12306网站这么大的压力，但是作为大型公用事业服务的电力营销业务应用系统，不得不提前做好预防工作，化解海量用户并发访问给系统带来的高负载压力。通过混合云为广大用电客户提供注册账户与业务查询的入口，缓解核心数据库的性能压力将是一个良好之措。
4、技术改造后的电力营销业务应用系统架构设想
经过改造后的电力营销业务应用系统架构设想示意图如下：
经过技术改造后的电力营销系统应当具备以下特征：
资源调度弹性灵活。系统能够随时处理高并发，大量流用户访问需求，资源能够实时弹性扩展，不再受硬件扩容受限的困扰。
应用交付快速敏捷。能够有效切分系统模块，通过服务化解耦，使服务提供者与服务使用者分离，满足新业务快速迭代开发的需要，并在出现故障能够快速隔离，不影响业务正常开展。
服务集成统一高效。采用分布式异步消息队列服务访问，提高服务响应能力，实现系统间解耦隔离，上、下游业务逻辑分离，降低系统间依赖关系。
数据资源灵活共享。运用分布式数据库，支持内存计算、批量计算、流计算，支持服务集群弹性扩展，保证业务持续、稳定开展。
业务开展高效稳定。应用混合云架构，在业务极端高峰期时期分流登录、查询等功能，减少生产库压力。
结论
12306技术升级改造，为新时代下大型公共事业客户服务系统带来了升级新思路：为避免设备重复建设，提高系统资源的利用率，先建设云计算中心，然后结合行业与业务的特点将核心业务拆分成独立的子系统，逐步改造迁移到云平台架构（私有云、公有云或者混合云）上。系统经过全面技术升级改造后，由于其逻辑相对隔离，每个子系统都相对独立，这些子系统可以像“云”一样，随着业务需求变化灵活弹性伸缩，或者在不改变业务逻辑的情况下，将一个环节拆分成多个，不同数据中心来协同合作支撑业务正常开展。
电力营销业务应用系统是查询业务量大，实时性要求高的大型公共事业客服系统之一，笔者通过12306系统成功演进分析，提出电力营销业务应用架构的设想，以期探索能源互联网时代的电力营销系统升级之路，欢迎大家交流和指正。谢谢！