传统金融业IT真相揭秘：“动物园”“牛群”玩法大不同

在互联网金融成为IT领域炙手可热新业态的今天，传统金融行业的IT团队似乎还蒙着一层神秘的面纱。他们在做什么?思考什么?对于互联网金融又有什么样的感想?它们与互联网行业有哪些区别和交融?未来的发展方向会是如何?本文由长期在传统金融行业为用户提供开源专家服务的国内领先开源解决方案服务商——上海富麦信息科技有限公司开源解决方案总监余军为大家详细分析了传统金融IT行业的IT技术情况，并分享了团队如何借助Golang之上的优秀开源技术，尝试进入云计算领域的动态资源管理和容器领域，去应对金融行业实际面临的业务挑战和激烈的行业变化。

1.基础架构真相：纵向复杂的集中式“烟囱”结构

对实际项目中复杂的拓扑图进行抽象后，金融业IT基础架构如图1所示。

图1 金融业IT基础架构

从图1可以明显地看出，整个系统是标准的IOE结构。事实上，在过去的二三十年间，全国最优势资源的投放点一直都是传统的金融IT领域而非互联网领域，因此金融业的IT系统一点都不落后，并且无论是团队技术还是具体构成，都可以说是非常先进的，只是外界很少有机会去接触和了解它的整个架构。在之前阿里巴巴去IOE的浪潮中，有些人存在着一些误解，觉得金融业IOE的系统比较低端，但真实情况恰恰相反。

那么，为什么与互联网电商行业相比，金融业的服务器部署规模会小一些呢?其原因在于，架构是根据业务生长出来的，所以传统金融业与互联网、电商行业在架构上的差别取决于业务形态的不同。在互联网领域，如一些大的平台化的电商，在横向上的每一层(如Web接入层、数据库层)都会布置很多台机器，但这些机器在同一层上做的都是类似业务，所以从纵向上的业务种类来说其数量却是有限的。而作为传统行业，金融业IT业务的种类和复杂度要远超过大家所熟知的一些电商类应用，它们在纵向上有很多犬牙交错的复杂的业务关联，但每个业务线都是在单独的一套系统里的，彼此隔离，并不要求有太多的横向传播。所以金融业的IT架构不是做不到大规模的多机器布置，而是业务没有这个需求。在过去的二三十年当中，由于业务不断往下生长，国内外绝大部分的金融IT业最后的形态都是像烟囱一样垂直的结构，系统之间是上下层的关系。这样的确是有限制的，但是它的合理性支撑了过去30年内中国的金融秩序和正常运行。举个例子，大家在上门户网站或电商网站时，有些会出现网页打不开的情况，但是到银行取钱时从来没有遇到过银行无法操作的事情，金融业的交易一直保持非常平稳，这就需要业务背后的系统的有效支撑。

2.IT环境真相：分而治之，严格管控

传统金融业的IT环境包括三个部分：Dev/Test、Staging和Production，如图2所示。

图2 金融业IT环境构成

图2中环境的设定与互联网行业叫法类似，但物理上的表现可能会完全不同。而在传统金融业内部，不同项目组技术团队成员在开发流程和方法上有比较大的差异。比如Dev/Test场景，金融业内部有多样的团队可能为同一个项目服务，有自己的技术开发团队，有做产品的金融专业团队，还有外包团队，这就导致了在流程上无法高效融合。此外，金融业对于以上环境的安全管控也会非常严格。在 staging 环境中，银行会导入一些经过脱敏的真实的交易数据，有一些业务网点甚至会直接来到staging环境里做实验性业务，或者完成完整的业务视角的UAT测试。因此它的安全性、可用性、容量等都是严控制的，甚至在一些大型金融行业的数据中心staging机房设置有多门岗，对进出人员进行管控。而 Production环境就不用说了，只会在管控上更加严格。

3.技术发展真相：互联网做的，他们都懂

2000年，金融业开始了从RISC到IA的架构转变，这场变化进行得如火如荼，大家都在探讨是否要在系统核心外围和边界上面把大型的UNIX系统替换成Linux。这个过程持续了四五年的时间，UNIX To Linux在一些机构开始推行。接下来是开源架构，2004-2005年用户开始在一些网银系统外围的生产环境中使用一些工具。后来分布式架构出现了，2005-2007年间金融客户开始在前端核心的外围和渠道业务(如银证、银基、银保，水电煤支付或者代理的当他交易)中使用开源架构，甚至有一些走得比较快的金融用户，会从国外学习。国内的金融及证券交易所跟美国的互联网公司、电商企业一直都在进行着交流，双方的专家也会互相深入到对方的实际工作环境中进行分享。从2008年开始，虚拟化出现了，接下来就是云计算和大数据。这时，银行的业务受到了所谓的影响，实际上金融行业最熟悉如何包装市场需要的金融产品。早在四五年前金融互联网化刚刚出现苗头时，相当一部分的金融企业向对口监管机构申请，并且做出了类似余额宝的业务，当时某些产品的投资回报率还是相当可观的。但是后来监管机构从整个市场的运行安全角度考虑，同时政策指引层面也需要时间去了解和消化，这些业务开展提案大多数都没有通过。

后来移动业务开始兴起，基本上每个银行都在做并且越做越好。然后是敏捷和DevOps的来临，敏捷在很多走在前面的金融机构早已开展，但是DevOps对于金融行业来说跟进是比较困难的，这不是技术上或是人力上的原因，而是在管理上更多的考虑和限制。

接着开始了所谓的“去IOE”话题，大型金融企业也纷纷投身到了IT建设自主可控的大潮当中。所以，从金融行业的IT基础架构建立起至今，技术和结构上的革新从来没有停止过，而是保持了对新技术的高度关注，顺时而动。到现在出现了 Docker，出现了自动化运维等一批新兴技术，这些金融机构的IT团队也在积极的研究。但是在金融行业实际的场景中，对于这些目前停留在调研阶段，因为金融业的业务场景中风险控制和生产安全是首位的。

4.技术选型真相：从集中式到分布式，“动物园”的资源分配

这里需要引入一个关于架构模型的问题，即“动物园”跟“牛群”之间的关系。由于业务的特点，金融行业形成了目前这种集中式的结构，它具有和电商、互联网领域完全不同的业务形态——业务种类繁多，但每个业务的IT结构中的每一层规模相比于代行互联网企业的结构来说没有那么大，不同业务之间边界相对比较清楚。所以实际上这样的场景是一个“动物园”场景，管理者要去精细分类管理照料这些动物。而在互联网及电商领域，IT系统多采用分布式架构，架构的每一层都是一个“牛群”。在这样的一个模型里，每一头“牛”对整体来说都几乎是同质的。同一层的 “牛群”中的“牛”，获得资源是尽可能平均的。但是“动物园” 模式里就不一样，由于不同“动物”对资源的消耗存在差别，会产生不同的管理模式。将“动物园”和“牛群”的具体模型对比如图3所示。

图3 金融业与互联网行业的IT模型示意图

所以在“动物园”，即传统金融领域，解决的是在这样一个环境里面如何实现资源的高效合理分配的问题，这是集中式“烟囱”模型向分布式结构转换时必须要重点解决的。那么，针对资源管控的解决，结合开源精神，需要进行以下思考。

1)是否存在已知的解决方案

目前可以选择的方案有HPC中的PBS，Conder及Platform的资源调度和服务管理技术，这是传统分布式计算领域的;还有来自现代互联网领域的分布式资源调度和服务管理技术，比如Hadoop YARN、Apache Mesos和Google Kubernetes等。

2)它们是否适合金融业的问题场景

然后要看看一下这些解是不是能解决我们实际面临的问题，如果可以，就能直接做一些实施集成的工作来实现了。下面依次对这些产品进行分析。

Condor

Condor是过去十年里，传统IT领域在大型集群调度方面做得非常好的产品。Condor系统是面向高吞吐率计算而设计的，它的主要目的就是利用网络中工作站的空闲时间来为用户服务。

• Condor采用集中式调度模式,且不能保障用户服务质量。
• 最小完成时间算法MCT(Minimum Completion Time)是以任意的顺序将任务映射到具有最早完成时间的主机上，它并不保证任务被指派到执行它最快的主机上，而仅关心如何最小化任务完成时间，因而可能导致任务在资源上的运行时间过长，从而潜在地增加了调度跨度。
• 以MCT算法为基础演伸出了Min-Min算法，它是利用MCT矩阵，先分别找到能够最短完成该任务的机器及最短完成时间，然后在所有的最短完成时间中找出最小的最短完成时间对应的任务。Min-Min算法存在着一个很大的缺点，就是算法的资源负载均衡性能(Load Balancing)不高。
• Max-Min算法与Min-Min算法相似，都是将任务指派给具有最小预测完成时间的主机，不同的是Max-Min算法从所有任务的最小完成时间中选取一个最大值，然后进行相应任务。主机映射，之后重复此过程直至待调度任务集合为空。
• 轮询调度(Round Robin Scheduling)算法就是以轮询的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况,而且当请求服务时间变化比较大时，轮询调度算法容易导致服务器间的负载不平衡。

Mesos和YARN

• Mesos 采用了DRF(Dominant Resource Fairness)调度机制。YARN自带FIFO、Capacity Scheduler和Fair Scheduler(借鉴了Mesos的DRF)。
• Mesos中的DRF调度算法过分的追求公平，没有考虑到实际的应用需求。在实际生产线上，往往需要类似于Hadoop中Capacity Scheduler的调度机制，将所有资源分成若干个queue，每个queue分配一定量的资源，每个user有一定的资源使用上限。
• Mesos采用了Resource Offer机制，这种调度机制面临着资源碎片问题，即每个节点上的资源不可能全部被分配完，剩下的一点可能不足以让任何任务运行，这样便产生了类似于操作系统中的内存碎片问题。
• YARN适合Long running job和数据分析类资源的调度，对于数据库类等短运行时场景资源调度效果较差。
• YARN采用了增量资源分配机制(当应用程序申请的资源暂时无法保证时，为应用程序预留一个节点上的资源直到累计释放的空闲资源满足应用程序需求)，这种机制会造成浪费，但不会出现饿死现象。
• Mesos和YARN的调度器的扩展和定制在开发上都比较繁琐。

Kubernetes

• Kubernetes仅仅是实现了一个极其简单的调度器。鼓励开发者编写自己的调度器注册进框架。
• 调度策略分为两大类：Predicates和Priorities，其中Predicates判断是否将pod调度到特定 minion(host)上运行，而Priorities则是在Predicates的计算基础上，通过积分Score方式，决定调度量。
• redicates包括：PodFitsPorts、 PodFitsResources、NoDiskConflict、MatchNodeSelector和 HostName，即一个minion能够被选中的前提是需要经历前面提到的这5个Predicates的检验，而Priorities又包括：LeastRequestedPriority、ServiceSpreadingPriority和EqualPriority，分别为通过 Predicates检验的minion计算优先级(score)，score是一个范围是0-10的整数，0代表最低优先级，10代表最高优先级。
• 调度机制还是过于平均，Predicates本质上作为一个过滤器，带有太多资源的物理属性。
• 调度机制非常适合公有云场景，对于私有云领域欠缺灵活性。

5.求解之路：基于场景的加权算法SWF

很可惜，以上提到的这些技术都分别有不适合传统金融业的应用环境的地方，但开发人员也从对他们的分析中得到了一些启发。比如，Kubernetes算法跟其他算法相比最大的优势在于关注到了服务使用资源的需求是不一样的，但是它的调度做得非常简单，基本上还是个平均的调度。因此，我们开发团队进行一段时间的深入研究，设计了一套基于场景数据的加权算法(SWF，Scene Based Weighted Fairness)，即将性能和一些场景数据按照时间片采集下来，然后经过算法计算，用短期和中长期分类来对应应用在资源池内投产的不同阶段，因为基础项目建设一开始资源用得相对少，后面会逐步增多，也可能出现业务爆发，支撑平台出现资源请求高峰。而且通过和业务场景对应的权重，实现人工干预调度里面的资源的均衡状况。还可以通过权重比, 从利用率优先、容量优先和可用性优先进行调控。SWF具体的开发实现采用了较为独立的模块方式，方便将来开源后被第三方用户使用、定制和集成。它具备以下特性：

• 适合金融行业架构和业务场景的资源调度机制，围绕各种对资源有不同分配使用要求的应用开展调度工作;
• 针对不同生产区域(devops/test，staging，production)实现基于权重比的调度调整方式;
• 实现局部调度的个性化和全局调度的公平性 ;
• 杜绝简单粗暴的调度，对关键业务应用的运行影响降低。

目前该算法正在面向金融行业应用场景，进行持续地开发演进和代码调整。

雏形与未来：将容器技术运用到实际场景

目前，余军的团队在围绕容器技术正在做一些面向金融行业场景的严肃而有趣的尝试。

首先，他们构建了一套资源池管理系统，所有工作都围绕资源池的调度来进行。在其上做了一层开放层的资源池的调度工具，包括资源调度、弹性伸缩、服务发现等，如图4所示。

图4 资源池及调度工具示意图

然后，构建了调度批处理的作业调度、性能管理，此外还基于算法以及资源池的调度系统做了一个跨逻辑数据中心的方案，如图5所示。

图5 数据中心方案示意图

值得一提的是，以上所有工作均采用Go语言编写，并且100%自主研发，并逐步完整开源给社区，希望帮助到那些有同样业务场景需要解决资源调度的开发人员和团队。相信未来这些方案的具体实现会为云计算领域提供一个优秀的金融行业场景落地案例。