转载自: 金融电子化

引言

席卷而来的以第三方支付、互联网消费金融为代表的互联网金融科技浪潮正在促使金融与实体经济深度融合,推动金融朝着互联化、数字化、移动化、智能化方向发展。交通银行作为大型股份制商业银行,这几年主动出击,着手构建自身的互联网金融生态,探索“互联网+ 金融”的创新发展模式,以继续引领技术创新。交通银行副行长侯维栋曾指出,商业银行应从四个方面应对互联网金融的挑战:

  • 一是积极拥抱互联网,以用户为中心,优化客户体验,提升客户黏性;
  • 二是要创新 O2O 模式,注重线上线下的结合实现转型;
  • 三是重视营销模式的转型,从大宗销售转向精准销售;
  • 四是要搭建综合平台,将银行所涉及的个人、商铺等信息集中到一个平台上,实现信息共享,成为信息服务提供商。

交通银行 IT 新布局

作为商业银行业务转型的基础平台,IT 转型面临较大压力,这主要由于互联网应用的开发、架构、运维模式与传统的商业银行 IT 模式有着巨大差异。具体来讲,体现在以下几点。

1. 在开发上线方式上: 过去商业银行采用的生命周期法,通常包含从需求到设计、开发、测试、投产、运维、下线等过程。这种方式最大的弊端是无法在较短的时间内验证商业策略是否满足市场要求,对于银行“互联网+”业务来说有较强的滞后性,以及高度的不确定性。如何不断提升产品投放市场的速度是实现“互联网+”转型对 IT 的核心需求。

2. 在应用架构上: 为了适应“互联网+”潮流下高并发和业务规则快速变化的目标,“互联网+”的应用架构已经从依托 WebSphere、MQ、ESB 等中间件的单体分层架构演变为分布式的服务架构,如今“微服务”架构更有一种重新确定面向服务应用架构标准的趋势。架构的变化对现有应用的服务整合、基础设施等方面都提出了不小的挑战。

3. 在应用运维方式上: 随着以微服务架构为代表的分布式架构不断深化,以及业务端不断敏捷化的倒逼,以往大量依靠手工运维的方式逐渐被淘汰,取而代之的是运维全自动化、服务化和智能化。在这种背景下,交通银行 IT 依据互联网特点重新布局,谋求转型发展。2015 年,交行新一代系统“531 工程”境内分行全面上线,其技术上采用了以客户为中心的新型架构,IT 开发与业务结合更为紧密,一定程度上实现快速迭代开发、快速响应,为业务发展提供了强力支撑。一般商业银行在技术架构领域进行技术选型时,需要重点关注架构模式与新技术的适用性。在向以客户生态系统为中心的应用架构转型过程中,银行应结合自身的业务特点、技术特性、基础设施能力及开发实施能力等关键因素,合理选择设计与银行应用最匹配适用的技术架构。同时,技术架构设计需要兼顾考虑银行业务成熟度与 IT 能力的综合平衡,考虑业界发展趋势、监管要求等外部影响,并跟随时代的发展与技术的变革,不断重检、持续优化 IT 系统架构。

交通银行容器技术调研

为此,在“531 工程”基础上,面对方兴未艾的容器技术,交通银行开展了技术调研和行业评估工作。以 Docker 为代表的容器技术以其轻量化、标准化、简单化以及面向应用的特征在一定程度上满足了交行近几年实现“互联网+”转型的战略要求。但在具体业务落地上,仍有一些问题亟待克服。

1. 基础架构的不匹配 。我行的基础架构主要以 IBM 小型机为主,原有的大量应用负载运行在 AIX 系统上。虽然近几年伴随着“531 工程”的建设推广上线,在基础架构上逐步向 X86 平台倾斜,但总体来看小型机仍然占据了较大比例。

Docker 容器技术目前只能支持 Linux 平台,且对于 Linux 内核版本也有一定要求,这在一定程度上限制了应用范围。同时,新技术引入还需从运维成本、安全可控、结合开发周期整体进行考虑,这在一定程度上也增加了 Docker 的应用难度。Docker 技术毕竟发展时间较短,当前主要还是侧重在功能层面的考虑,在监控、日志、CMDB、ITIL 流程整合等方面并没有形成太多实践,还需要一段时间才能完善。

2. 人员能力不匹配 。这个问题其实是和基础架构环境息息相关的,新技术引入首先要确保人员能力跟得上。随着国家对于银行自主可控要求的不断深化,运维人员不仅要熟悉 Docker 的日常运维,还要对于 Docker 的深层次运作模式进行学习,甚至要融入开源社区平台的交互,对开源代码进行学习理解,这无疑会带来更大的挑战。

3. 运维机制待更新 。交通银行从 2004 年开始引入 ITIL,到如今已经过了 12 个年头。而经过我们调研,容器行业内普遍认为伴随着 Docker 技术产生的 DevOps 是一种更能匹配 Docker 和云计算的新型运维模式。ITIL 和 DevOps 如何定位,又如何实现与 Docker 等新技术的有效结合,这一系列问题都有待逐步摸索解决。

上述问题的落实不是一蹴而就的。我们认为商业银行应用 Docker 这类新技术首先需要一个良好的顶层设计,明确容器技术的应用场景,梳理并确认与现有架构、运维的关系,建立新的人员职责和技能要求,先期做好相应的技术储备。在应用场景的具体选择上,首先选择具备“互联网+”特征的应用进行试点,采取快速验证、快速迭代的策略逐步推进。其次,针对现有应用架构,采取逐步剥离热点应用模块的策略,借助容器化技术提升应用运维的自动化水平,达到降低运维风险,提升运维效率的目的。

当然,容器化不等于云化。我们清晰地知道容器化只是迈出了应用“云化”的第一步。近几年,我们发现简单把应用放到云上,效果并不是很好,因为原有的应用并不适合云。后来我们开始研究云的应用要具备什么样的特征,现有应用该如何改造才能发挥云的价值。从 2013 年开始,交通银行数据中心对业界云计算概念和相关实践进行了深入研究,结合运维现状,开展了系统运维云服务平台项目的建设,迈出了 IaaS 云的坚实一步,有效支撑了“531 工程”的快速、稳定推进。当然,我们的系统运维云还是 IaaS 云,不是 PaaS 云。对于应用的真正云化还有相当长的道路要走。商业银行的应用云化,首先要把传统的大应用拆成小的应用,小的应用再通过容器封装,借助容器实现快速部署、弹性扩缩容、服务降级、灰度发布升级等高阶的应用智能化运维场景,即在 IaaS 基础上构建一个基于容器的 PaaS 管理平台。

品高云在最新推出的 7.0 版本中,有专门针对容器自动化运维的 ECS(云容器服务),主要解决了客户在构建微服务架构、DevOPS、应用持续交付等场景中面临的:容器高可用、图形化管理、灰度升级、容器安全等问题,具体介绍和 demo 视频可参考文章:[深度分析 7.0 系列]01 弹性容器服务