2016云栖大会上海峰会于2016.1.20日在上海科技馆顺利举办。本文是根据朗新科技首席架构师林海潮在2016云栖大会上海峰会《互联网+架构及实践专场》的演讲中分享内容整理而成，林海潮分享了传统行业在使用云架构时采用的技术和一些心得收获。
下面是演讲内容整理。
业务场景及挑战
从13年的费控到双向电表，传统的电力行业正向互联网转型，目前采用的方式是以一个小时为基准，对整体数据处理，整体流程为：根据测算规则从采集主站获取抄表数据进行电费测算和与用户实时缴费信息进行比较计算剩余电费，通过剩余电费和基准比较，应用费控策略，开展预警、停电或复电控制等业务。
其计算流程图如下：
图1 数据计算流程
在数据贮备到电费测算再到数据回写的整个过程的关键指标有两个：一是千万级别数据量计算与性能需求呈线性增长；二是数以百万计的高并发实时查询以及其他异构平台的接入。
传统的企业系统多采用IOE架构，核心逻辑在数据库中实现，数据库是系统最为关键的部分。其处理方式基本是从客户端到应用中间件集群再到数据库叠加的SQL+存储过程；架构的存储横向扩展能力和实时快速处理能力不足；并且数据库多采用Oracle RAC，导致其扩展性有限，采用的国外的小型机服务器进一步增加成本。传统企业架构进行优化面临以下四个挑战：
（1）去中心化，将集中系统拆分成不同的节点，每个节点独有的开放性、完整法、独立性；
（2）实时处理，接收到数据后实时响应计算，一个小时完成三千万计算；
（3）高并发，数以百万计的实时查询；
（4）高可用，在高并发的情况下保持每个计算问题完整且平稳。
应对机制
针对上文中的不同挑战，提出不同的解决方案。
微应用，以阿里云平台为基础，依托云平台的扩展能力和服务体系，针对整体业务特点进行细小化的功能部署，保证微应用针对独立的业务。与偏向小颗粒度和较少代码的微服务相比，微应用偏向于业务应用逻辑以及对内部相互依赖或者关联度较高的业务继承，是组件化与服务化结合。
图2 微应用开发简图
如上图所示，微应用开发过程首先把系统中业务功能组件化和服务化，然后将微应用整合到云平台形成统一的服务管理。在整体的服务化过程中，业务拆分时需要对业务进行梳理。整体业务流程繁多，从代码服务的角度考虑把耦合度降低，无须细分颗粒度相互之间的耦合度。微应用是将原业务应有场景切分成许多不同的小的服务，每个服务具有自身的特性，单个服务可以直接部署在系统中，单点故障不会影响整体系统的能力，提高系统的可用性。与传统的大型管理系统相比，微应用的形态呈现出功能少、体积轻，能够快速交付和敏捷响应需求变化。
图3 多维度分表分库方式
分表分库，微应用提交数据交互内容时，正常的维度是以Hash和时间做分表分库，也可以从业务特色和业务特点进行拆分。原则上遵循两种方式：第一种，基于较大的表拆分到不同的小表，根据不同业务属性和业务关联程度分到不同的库；第二种，小表拆分的方式，现实中会产生大量小表如配置表、基础信息表，虽然这类表量不大，但是许多操作需要频繁的查询调用。此类情况应将小表以广播的方式同步复制到各个库当中，解决配置表、微量表访问比较频繁的问题。
图4 消息事件驱动过程
事件驱动，每个微应用即是消息的生产者也是消费者。在整体微应用的调度中，通过ONS来驱动整体业务的串联。整体的数据是经过一小时左右的时延的数据，微应用集群和分布式消息集群在配置中心和协同组件的控制下进行数据交互。微应用间的交互通过消息时间驱动，在应用解耦的同时，满足应用扩展以及实时性的要求。
图5基于大数据平台的数据分析流程
大数据，相对互联网企业而言，实际上用到的大数据并不是很多。系统跟外部关联特别多，单独专注于某一特定模块具有较大的局限性。所以系统要与短信系统、产业系统相连接，仅专注于中间层是不行的。上图是基于大数据技术对档案及电费数据分析处理的过程：数据库中，对动态数据进行全量同步和增量同步，生成与之对应的全量库和增量库，再通过ELT整合成统一库进行业务调度，然后计算引擎完成整体数据离线清洗、计算，再将同步库数据返回到整体业务数据库。在这里，统一库和同步库没有太大的差异，只是逻辑定义不同。通过整体思想，定义业务访问数量标准和规则，统一化数据的存储和使用方式。
图6 弹性扩展架构
弹性扩展，整体依托阿里云的基础上，全面提升数据库层面和应用层面的的弹性扩展能力。数据库层面弹性扩展，采用数据路由方式，不同数据节点调用方式各异。整体应用层的弹性扩展，采用的阿里云对服务治理来解决服务调用的过程，微应用通过长连接到注册中心进行注册，在微应用调用方订阅注册中心的前提下，注册中心同样以长连接的方式通知不同的微应用调用方，微应用调用方直接调用提供方所提供的微应用，同时监控中心以短连接的方式对微应用进行监控，微应用提供方也可进行弹性扩展增加新的微应用。
基于阿里云的架构优化
图7 基于阿里云的架构优化
上图是基于阿里云的架构优化，正中间是集群，将传统服务拆成很多微服务。从营销系统将用户档案、电价参数等数据同步到费控数据库集群中，DTS负责数据传输，监听DRDS集群中数据变更的内容，并将变更的内容放到整体的集群里。在ONS集群中为了保证整体应用的协同，应定义出相应的消息包括测算通知消息、档案变动消息等。接下来把数据准备和数据分析传到ODPS集群中，ODPS集群把相应数据整体推送给采集系统，然后采集系统将消息推送到数据采集终端，发送到不同用户的电表上进行停电或者复电操作。
面向企业应用
任何技术的进步无外乎两种驱动力：第一是社会进步发展的驱动；第二更多是个人用户对应用差异性体验驱动。
图8 基于阿里云平台的企业云应用开发平台
企业应用本身的具有相当多的特点，如统一资源、数据打通、统一打包、快速开发、降低成本、节能环保等等。因此整个应用开发过程中不免存在相当多的问题，如Case随着时间的推移不断的简化；原业务积累整体的可复用性等等问题。对于公共行业的业务，在整体服务化、组件化的过程中，企业可依托阿里云平台的技术，结合本行业的流程构建整体快速开发的平台。同时在快速开发平台中也可以引申到平台设计、服务组建复用以及整体数据分析上再构，通过定制化软件，降低成本。
传统的行业在面向企业应用时同样做出了很多努力，包括整体资源统一、数据打通、以及面向定制化产品快速的开发。对用户层，随着海量数据处理的实现，成本逐渐降低。通过阿里云平台，企业可以实现从整体服务到整体业务应用服务再到整体的组建化、服务化的过程。
所遇到的困难
做整体的过程中，遇到相当多的问题。
首先，从习惯的ROE的方式转移到整体层面，整个技术转型存在很大的挑战。以前将目光聚焦在数据层、数据库，每日AWR出来分析性能优化，方向不太正确。现在对系统的整体架构进行优化后，仅从现场运维服务角度来看，现有系统相比原系统体验提升很多。
2016云栖大会上海峰会回顾专题（含演讲视频）：http://yunqi.aliyun.com/2015/shanghai/review.html