金融企业PaaS解决方案选型原则及标准

随着互联网金融的迅猛发展，双模IT建设是目前金融行业发展的必然趋势。在确保稳态业务稳定性的同时，也要积极拥抱互联网金融，以应对日益激烈的竞争。处理敏态业务的核心要点是持续集成、持续交付与持续部署，而持续部署的关键就在于建设一个功能完善、稳定且高效的PaaS平台（Platform as a Service）。将Docker作为容器引擎，将Kubernetes作为容器的编排与资源调度工具，基于K8S+Docker建设PAAS平台已成为业界的主流共识。

虚拟机是IaaS平台的基础，而PaaS平台的基础则是容器引擎。容器引擎较之于虚机而言，优势极其明显：可以更轻便、更快速、更加标准化地封装应用，实现一次构建、到处移植，适用于打包封装、自动化测试、持续集成与持续发布等场景。

容器引擎技术主要有Docker公司的Docker Engine和CoreOS公司的Rocket。rkt虽然在安全和兼容性设计上更胜一筹，但在安装便利性与社区活跃度上，Docker遥遥领先。从两者在Github中的统计数据可以发现，Docker社区无论在贡献者数量还是提交次数上都远多于rkt社区。说明目前Docker技术被更加地广泛使用，产品成熟度更高，社区活跃度也更高。因此，绝大部分互联网公司与同业金融机构都选择Docker作为容器引擎解决方案。

容器引擎最重要的特点之一是轻量，为了适应这个特点，对应用有一定的要求。对于稳态业务系统而言，其架构为集成式的，即完成整个应用逻辑的功能模块都集中在少数几个应用包中。这种情况下，部署在传统物理机或者虚机上是没有问题的，但部署在容器上则略显笨重，会影响容器的启动效率以及稳定运行。需要进行与容器技术所匹配的微服务改造，对应用架构进行解耦，从稳态IT的紧耦合架构转换为适用于互联网金融系统的松耦合架构。微服务改造之后，会将原本集成式的应用包拆分成若干个微服务模块。在分布式架构与微服务架构下，一个系统会从原本的四路虚机应用，拆分成8、16甚至32个容器应用模块。面对这种数量级的扩张，就需要对容器集群进行管理。容器服务编排工具应运而生，一个高效的编排工具对应用系统的稳定运行至关重要。

容器集群管理平台即PaaS平台，涉及容器集群资源调度与编排、集群高可用性、容器存储、容器网络、容器镜像管理、容器集群监控与日志管理。这些模块构成了PaaS平台的核心功能。

就PaaS平台选型而言，与互联网金融企业略有不同，要确定适合于金融机构的PaaS需求并妥善制定PaaS平台建设路线。做到既面向未来，又不过于激进，既求稳定，又不过于保守，从而实现已有系统向PaaS平台的平稳演进。

金融机构选型时宜主要从产品功能性、稳定度、自主可控度、成本、习得曲线与技术团队建设等多角度进行评估分析。

PaaS平台产品选型首先可以从开源与闭源这个角度切入。目前市面上最成熟的闭源产品是Pivotal公司的企业级PaaS平台Cloud Foundary，简称PCF。PCF在技术上拥有完整的企业级套件，提供一体化解决方案，功能覆盖全面。但该产品无法进行自定义裁剪，只能整体采购，会造成大量资源浪费。由于其为闭源产品，不但习得曲线较陡峭，自主可控性也较差，易受制于供应商。相较而言，使用成熟的开源生态圈技术，在保持产品稳定性与功能性的同时，可以有效降低成本，提高产品自主可控性。

开源产品中，选型时要以资源调度器与编排工具为核心，兼顾考虑各产品外围生态圈的成熟性以及开源产品社区的活跃性。目前主流解决方案有Kubernetes、Mesos(Marathon)与Docker Swarm三种。

Kubernetes由 Google 开发，其前身为其内部编排工具Borg。Kubernetes 开源之初还尚与Mesos、Docker Swarm呈齐头并进之势。但最近一年大放光彩，一时间风头无量，一骑绝尘，几乎统治了容器编排领域。主要有以下几点原因：
1、 来自社区以及基金会的强力支持
Kubernetes是最大的开源社区之一，在GitHub 上超过28000 多个星标。得到来自上千个组织的贡献（1,409 个贡献者），社区活跃度在同类产品中遥遥领先。并且被纳入原生云计算基金会CNCF。
CNCF是Linux 基金会的一部分，拥有一些顶级企业成员，其中包括微软、谷歌和亚马逊。同时，CNCF 的企业成员队伍也持续增长，包括SAP、Oracle等知名企业持续加入。
Mesos和Docker Swarm在这方面与Kubernetes差距较大。
2、 产品的可用性与功能性
就产品习得曲线而言，Docker Swarm是最简单的，Mesos次之，Kubernetes具有最陡峭的学习曲线。Docker Swarm只是将单节点Docker的使用概念扩展到Swarm集群，两者一脉相承。Mesos与Kubernetes均完全使用自己的术语和概念，区别在于前者的功能与设计并没有后者丰富，故前者的学习难度也弱于后者，后者的功能更加丰富与成熟。
Kubernetes考虑了很多生产中需要的功能，包括包含资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA以及有状态应用的容器化处理。较之于Mesos，二次开发场景较少，且具较强的扩展性。
Kubernetes也是三个产品中发布更新频率最高的产品，产品稳定性不断加强，功能不断丰富，目前已发布至1.8版本。

3、部署规模匹配性
就集群规模而言，一般规模金融机构都需要具备千点规模的集群，在这个规模之上，Kubernetes与Mesos均可以较好的提供服务能力，
Kubernetes已经测试了数千个节点，而Mesos已经测试了成千上万的节点。对于数万节点规模的集群，Mesos更为合适，它的双层调度机制可以支撑大规模集群。
4、未来发展趋势
近一年Kubernetes发展极其迅猛，业界各大巨头纷纷向Kubernetes靠拢，与其展开合作，已有一家独大之势。
微软近日宣布，其2016年4月正式上市的（ACS）云端容器服务Azure Container Service在今年2月整合的Kubernetes调度编排工具后，近日宣布改名AKS，将以Kubernetes服务为主。两周前Docker也宣布在后期版本开始增加K8S编排工具，用户安装Docker时可自主选择Swarm或Kubernetes。另外，数据中心操作系统厂商Mesosphere也宣布采用了Kubernetes。

综上所述，某城商行结合自己的业务规模，经过比对分析，最终选择基于Docker的容器引擎技术。使用Kubernetes实现集群管理系统，实现应用部署、维护、扩展机制等功能，方便管理跨机器运行容器化的应用。同时使用Etcd、HAproxy、ELK实现容器的服务发现、高可用与日志处理。

金融行业建设PAAS平台的需求

金融行业由于监管要求严格，故对基础平台的稳定性、高可用性以及业务连续性有较高的要求。对于平台的建设需求，建议着重从以下几个方面进行考虑规划：
1、 多租户管理方面
 根据组织架构，不同租户可以发布和使用不同的应用容器。
 多租户权限方面，管理员可以管理集群和主机资源，成员用户可以进行应用部署和管理。

2、 容器调度策略方面
 需要能够自动按照主机资源用量进行容器调度，默认选择最空闲节点调度运行。
 可以指定具体的部署主机。
 可以通过标签策略进行容器调度。
 可以通过配置调整单次下发的容器任务数量。
 可以在指定的容器宿主机上运行，支持亲和性与反亲和性策略。

3、 镜像仓库方面
 镜像仓库具备服务高可用和存储高可用。
 提供镜像多版本管理。
 镜像误删除时可进行恢复。
 可基于角色进行权限管理。
 提供镜像的增删改查等日常管理功能。
 可对镜像仓库中的镜像进行漏洞扫描，保证镜像安全。

4、 应用及服务管理方面
 可对应用模板进行管理，并可进行应用编排。
 应用中具备对其进程服务的健康检查。
 提供应用组的容器视图服务，可展示容器逻辑关系视图。
 提供负载均衡服务、SSL支持、会话保持功能及特定环境如用户SESSIONID保持功能。
 容器地址的动态更新时服务不间断。

5、应用发布方面
 平台提供应用不同版本的显示，且最新版本的提示。
 对应用进行滚动升级、回退，支持应用流量控制。
 提供多种应用发布方式，包括灰度发布、蓝绿发布、金丝雀发布等。

6、系统高可用方面
 支持控制节点高可用，保证无单点故障。
 支持主机节点高可用，如宕机可快速将应用切换到其他主机，且保证容器实例数目。
 支持操作系统的升级和平台插件升级而不影响当前业务。

7、两地三中心建设方面
 支持多中心部署及管理，各个数据中心可独立建立集群，由平台统一管理所有集群。
 支持多数据中心健康监测，具备统一管理平台对所有集群的健康监测功能。
 具备多数据中心容灾功能，应用可以在多数据中心迁移。

金融行业建设PaaS平台过程中所遇到的难点:
1、 团队建设、人才培养方面
PaaS平台生态圈涉及技术种类较广，而且大部分都是开源产品，且习得曲线较陡峭，对员工提出较高的要求，需要在短时间内快速学习。
2、IT治理方面
由于PaaS平台主要服务于敏态类型的互联网业务，故与现有的ITSM等治理体系差异较大，需要探索研究能够同时管理两种IT模式的变更管理流程。