高并发金融应用架构优化与平台创新
本文作者：李亚琼，博云BoCloud CTO
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅2016年《程序员》
小微金融、场景金融等新兴银行金融业务亟需一种新型的弹性架构来应对高并发、大流量的业务冲击，同时，要满足应用快速版本迭代升级、敏捷运维管理等需求。本文分享了BoCloud博云如何利用互联网应用架构与Docker容器技术帮助银行业应对“互联网+”挑战，建设基于PaaS平台的敏捷IT架构。
移动互联网渠道创新是传统企业无法也不能躲避的业务变革，无论是接入或者自建互联网渠道都需要回答如下问题：现在的IT架构能否应对互联网渠道创新业务的爆炸性冲击？什么样的IT架构才能够解决这个问题并具备应对未来需求的良好扩展能力？以银行业为例，传统的银行渠道比较单一，基本上围绕各个分支机构和营业网点运营，整个IT系统的建设中性能指标在整个指标体系中的重要性往往要低于业务可靠性。然而，这一切正在发生改变，围绕互联网渠道的渠道创新业务已经改变了这种现状。
新金融IT需求
银行业已经告别了传统的以银行业务为中心的业务模式，开始转变成以客户需求为核心进行业务设计与金融创新，这也正是场景金融的内涵。无论是传统的电子银行业务，还是渠道创新的直销银行业务，以及互联网金融的各种宝们，都是满足客户各种场景金融需求而建立的金融业务。下图是现代银行的一些业务及其基于的运营平台。
围绕客户、渠道、数据和平台，银行业CIO们需要解决三个主要问题：
- 如何快速实现业务上线来应对快速变化的市场？
- 应用架构如何应对互联网渠道带来的瞬时大规模并发请求带来的负载压力？
- 如何实现大量业务应用、服务与数据的统一化管理并确保上述两个问题的解决？
采用过去烟囱式建设模式具有如下三个弊端：
建设周期过长。传统的建设模式从规划、采购、开发、上线、试运行等阶段才能上线一个新的业务应用，时间跨度可以实现从几个月到几年，十分漫长。像基于互联网事件的营销类应用需要及时对事件作出响应，对业务上线周期具有十分苛刻的要求，传统模式显然无法满足。
扩展性不能满足业务需要。传统的应用一般都是基于规划容量进行设计与开发，用户的规模是可以估计，在极端的条件下可以通过排队等机制降低负载压力。然而，“秒杀”、“抢购”等应用模式却不具有这样的前提条件，用户规模会在极短的时间内爆炸性增加。简单的排队策略会让用户大大降低产品和服务的质量评价，无法满足快速扩展的需要。
业务封闭。传统的业务与业务之间很少互相访问，业务服务在设计与运营过程中也缺乏复用的考虑，更不用说满足多个场景并发访问的需求。
建设思路
为了解决上述问题，我们和多家银行架构部门合作，规划了“重平台、轻应用、服务化”的新金融IT基础平台。
新一代的IT架构应该具备如下特点：
- IT基础设施与服务平台已经集成了应用程序所需要的基础件或服务，比如资源申请服务、调度服务、消息服务、数据服务等等。重平台的概念的内涵就在于大量的基础服务或者经验数据能够在“沉积”在平台中，构成应用基础架构的核心。
- 应用的开发、上线、迭代升级都需要足够的敏捷。这一方面依赖与平台集成的基础服务，另一方面需要平台能够快速的实现对于应用封装、发布、迭代升级的支持，具备一键式部署、升级等特性。
- 应用的架构需要由平台服务或组件“封装”而成，服务或组件能够提高系统的并发性，同时具备可并行化特征，除了能降低服务响应延迟外，最重要的是可以通过整个平台服务来支撑大并发访问需求。
从业务需求的角度来说，“轻应用”的平台能够快速“组装”出新的业务形态来满足市场快速变化的需求，“服务化”一方面加强各个业务之间更多的关联提高了服务质量，另一方面可以把优秀的经验和实践固化下来增强企业业务竞争力。“重平台”特性可以通过整个平台的“能力”有效支撑业务负载压力，确保应用的资源需求、扩展性需求、并发需求等得到满足。
当然，上述特性不是天然就具备的，需要从应用架构和平台创新两个方面进行改变来确保目标达到。
应用架构优化
回到移动互联网模式下应用应该具备特点：1，需要能够应对大量用户同时并发访问需求，即应用架构要具有优秀的并发性和弹性；2，应用要能够快速迭代，一方面满足业务发展需要，另一方面可以不断对性能进行调优来改进服务质量；3，应用架构要满足能够快速“组装”出新的业务应用来支撑快速变化的市场需要。也就是说，应用架构要具备：
- 强大的并发能力；
- 灵活的弹性；
- 敏捷的迭代能力；
- 标准化可组装性；
这几种能力的获得需要从多个角度对系统进行优化，典型的优化包括：流量负载均衡、异步IO、消息队列、读写分离、分库分表、对象缓存、服务拆分、索引服务、分布式内容管理、CDN、空间换时间优化等手段。
i.负载均衡
根据业务模型和业务服务协议，一般可选择的负载均衡方案包括：链路层负载均衡、IP层负载均衡、Http反向代理、DNS域名解析负载均衡、Http重定向负载均衡。大型网站或业务服务往往采用多种手段进行流量的负载均衡，比如先基于DNS实现多数据中心的负载均衡，再根据IP实现数据中心内多业务负载均衡，最后在基于反向代理实现统一业务的不同服务器之间的负载均衡。
ii.异步IO
异步IO是提高系统并发性的重要技术，和异步IO共同出现的还有任务（消息）队列、线程池和持久化连接等技术。异步IO技术是事件驱动的编程模型实际应用的典范：用户请求先被放入任务队列，然后唤醒任务分发器，任务分发器从任务队列取下任务分发到空闲的线程上，线程触发异步IO操作并注册回调方法，当IO返回后回调方法重新从任务队列中把任务取下并把结果返回。整个过程如下：
iii.消息队列
消息队列对于提高系统并发性能具有四个方面的作用：1，通过消息队列实现异步处理，如上述异步IO中的任务队列就是可以基于消息队列实现；2，任务并行执行，通过消息队列可以把传统串行执行的任务尽量改造成可并行的程序；3，应用解耦，提高系统的扩展性；
4，流量削峰，通过消息队列引入排队机制，可以把尖峰负载尽量平整化。下图为一个Web网站的消息系统。
iv.数据库读写分离/分库分表
随着访问量的增多，数据库系统的压力会越来越大。在一个信息系统中，数据库系统的性能往往是对系统整体性能影响最为关键的指标。从数据库架构设计的角度，常用的优化手段为读写分离与分库分表。前者是采用读写请求分别路由到不同的库中来降低数据库系统压力的一种技术，采用该技术可以最大程度上提高系统的并发读，特别是对读多写少的访问模式十分有效。两个库之间通过数据同步，可以确保数据的一致性。读写分离模式如下图示：
随着业务的运行，数据库中的数据量随之不断增多。当达到一定的记录条目时，一次查询往往需要消耗很长时间才能返回结果。这是分库分表设计就提到了日程。分库设计一般根据业务把不同的内容存到不同的数据库中，也成为垂直拆分。这种拆分模式比较灵活，也易于操作，不足之处在于需要考虑跨多数据库的符合业务查询join问题。分表设计也叫水平拆分，就是把同一个表中的数据拆分到两个甚至多个数据库中。产生数据水平拆分的原因是某个业务的数据量或者更新量到达了单个数据库的瓶颈，这时就可以把这个表拆分到两个或更多个数据库中。Mycat是最为常用的分库分库中间件，下图为Mycat的架构，有兴趣的同学可以前往Mycat官方网站学习了解。
v.服务拆分
服务拆分是把过去全部运行在一个应用容器内部的业务逻辑子系统拆分出来，单独运行在独立的容器内部。这样做有两个好处：1，可以降低系统耦合度，使得业务具备快速迭代能力；2，方便的定位影响性能的子系统，针对性的进行性能优化。例如，短信子系统从整个系统中拆分出来后，系统可以方便的测试短信收发的并发效率及延迟，这样可以针对性的进行设计改进与架构优化。
vi.内存缓存
随着访问量的增加，逐渐出现了许多用户访问同一部分内容的情况，对于这些比较热门的内容，没必要每次都从数据库读取。我们可以使用缓存技术，例如可以使用memcacahe作为应用层的缓存，也可以使用redis作为数据库层的缓存。另外，缓存系统也可以用来保存一些需要分享的数据，比如用户登录的会话信息（Session）。通过缓存系统共享会话是实现单点登录及会话管理的重要技术。加入缓存后的系统架构如下。
vii.索引系统
对于模糊查找，利用读数据库进行查询往往力不从心，即使做了读写分离，这个问题依然是影响性能的一种重要场景。以交易网站型为例，基于关键词查找商品或服务是一种最为常用的功能，尤其是根据商品的标题来查找对应的商品。对于这种需求，在数据库操作中我们都是通过like功能来实现的，但是这种方式的开销很大，且针对大数量查询时非常耗时。此时我们可以使用搜索引擎的索引来完成。
viii.分布式存储系统/CDN
针对非结构化数据的访问优化，一般的策略是构建分布式存储系统。支撑分布式存储系统是具备良好扩展性和并发性能的存储系统，设计良好的分布式存储系统能够实现访问文件的快速定位、加速读写、实现高并发性。例如ceph就是一个优秀的开源分布式存储系统。
CDN是更大尺度的优化手段，通常用户大型或超大型网络服务运营。利用CDN，可以把不常变化的资源放置在网络的边缘，加速终端用户获取资源的速度。
ix. 空间换时间优化
空间换时间的优化一个典型的应用场景是应对不同分辨率屏幕时向用户提供统一图片的不同分辨率的版本，这是根据常见的屏幕分辨率在用户上传图片时自动生成不同分辨率的图片避免用户请求时实时进行转换的开销。这种优化对于视频、多格式存储文件等也非常有用。
综上所述，利用各种优化手段后整个互联网应用架构如下图所示。
平台创新
上述架构的落地还面临一系列挑战，包括：
1.如何部署实施这么复杂的系统？
2.如何快速的定位高负债压力瓶颈子系统并自动进行扩容处理？
3.版本的迭代升级如何可控有序的得到执行？
上述问题如何解决呢？。回顾前文所说的新一代平台架构的三个特性，即“重平台、轻应用、服务化”，其中重平台和服务化的特性就是上述问题解决思路的方向。
重平台和服务化概念的背后是整个平台已经固化了大量可独立对外提供服务的组件或子系统，应用只需要负责业务逻辑的部分即可完成整个系统的部署上线。要实现这一点，需要做到如下三点：
- 应用需要进行业务逻辑、数据存储和服务组件的分离，实现业务逻辑、数据和组件服务的独立运行；
- 平台要具备根据业务、数据和服务（组件）定义（编排）业务架构的能力，能够实现业务的编排部署；
- 平台要能够实现对业务、组件（服务）和数据存储个子系统的运维管理，确保其在负载压力增大时能够自动弹性伸缩提升用户体验。
这就涉及应用封装、业务编排和弹性伸缩（自动运维）等方面的技术。BoCloud博云基于Docker的云应用发布与运维管理平台正是基于这样的理念和需求而开发的。下图为BoCloud的BeyondContainer产品架构：
如图所示，BeyondContainer包括三个主要部分：
- 基础设施子平台：负责管理平台的基础设施，除了服务器、存储、网络等基础设施外，还包括围绕应用相关的基础组件管理，如镜像仓库、容器、组件等。
- 应用管控子平台：负责管理平台上的各类应用，提供应用部署、维护、日志等管理管控，同时实现多租户环境，实现基于服务目录的应用发布服务。
- 一体化监控子平台：负责对整个平台中的资源、应用、通信等进行监控，并以可视化形式对外呈现系统各类监控信息。
限于篇幅，关于BeyondContainer的架构和特性就不再这里进行展开阐述。
总结
本文分享了BoCloud博云在帮助传统企业在应对移动互联网业务冲击时在应用与平台架构上如何进行创新实践的经验，希望能够对大家有所启发。