传统金融企业的探索之路——上交所业务系统Docker化实践分享

今天小数带来的的干货来自上海证券交易所架构师黄成,在数人云产品战略发布会上,黄成分享了上交所业务系统Docker化的探索和实践。以下是小数整理的演讲实录:

选择Docker的四个原因

首先介绍一下上交所业务系统,这是一个除了交易平台外,对业务数据进行处理的系统。在该系统的开发与运维过程中,我们遇到了开发和运维分工的问题。我们的开发和运维属于两个独立的部门,这两个部门之间的技术沟通一般都是通过公文或者备忘录等渠道来进行,无法做到密切、高效地进行沟通。为了提高资源的利用率,我们的业务系统在一个节点上共享部署。在这个节点上,开发和运维的分工比较细,图中蓝色部分是运维部门负责的内容,主要是针对操作系统等的基础运维,而应用的运维则由开发部门来负责。在这样的沟通架构之下,把运维的工作分得这么细,给公司带来了很多问题,因此我们一直在寻找一个解决方案。

之所以选择Docker,主要有四个原因。第一,虚拟化。开发和运维部一致认为,用虚拟化来解决资源复用的环境管理问题是正确的方向,这是有共识的。第二,Docker非常热门,包括微信朋友圈、网站上都能看到相关介绍,Docker和DevOps、微服务这样的热门话题也密切联系,通过接触Docker也可以获得一些额外的收益。第三,Docker入门简单,只要装上Docker daemon,写一个两到三行的Dockerfile,就能够看到效果。最后是开发主导,从开发和运维的分工来说,运维基本上是做基础运维,我们把Docker看做应用层技术,由开发来主导,可以节省很多沟通成本。

搭建容器云

当我们真正开始实践的时候,我们发现Docker并不能完全解决我们的问题。首先上交所的基础设施相对落后,操作系统无法友好地支持Docker的操作系统。其次,我们的网络环境跟外网是完全隔离的。另外,我们想改变集群管理手工运维的方式,想做自动化的集群管理。用了Docker之后,现有的应用监控系统无法满足需求,还需要建设一套体系。对于上层来说,现有的软件规范,包括安全配置都没有覆盖Docker。此外,我们还关注到微服务还有分布式架构,也想把它们引入进来。为了满足分布式架构,我们决定构建一套自动化、且更高效的软件架构。

首先,我们做的是容器云。经过一段时间和数人云密切地交流和合作,我们建立了自己的私有容器云。这个容器云主要解决三个方面的问题,第一个方面是资源调度,之前的集群基本上都是手工管理的,使用容器云之后,想做统一的自动化资源调度。当一个应用要上线的时候,不再需要去跟其它项目沟通协调资源,也不需要去跟运维协调,减少了很多的成本,提高了效率。第二个方面是软件发布,我们希望借助Docker的特性来制定标准化的软件发布过程。目前,我们的软件发布过程可谓五花八门,经常有下游团队抱怨为什么这个包运行不起来,是不是因为发布的包不够充分,或者为什么两次运行的结果不一样,所以我们希望用Docker来解决这样的问题。第三个方面是集群的监控与部署,我们希望制定一个比较标准化的监控平台,让所有的应用都按同一个方式去处理。另外,我们也希望把运维监控到的数据及时反馈给开发,来促进软件水平的发展和软件能力的提升。

有了容器云之后,我们自然就会想到软件分布式架构,也在尝试将微服务的架构引入到这个软件体系里面来。目前上交所的业务系统基本上是单体的MVC架构,这种架构主要有两个问题:第一,我们有的项目是三十个人的团队,功能也比较多,非常赶时间,所以采用敏捷的开发迭代交付方式,但是到了版本发布的时候还是非常困难。第二,软件的质量基本都是在功能测试的最后一关去把握,导致业务系统的质量很难提升。而在微服务架构中,基于微服务的方式,每个服务都有自己的版本,在整个软件来看每个服务的小版本都可以有序地去协调。微服务架构把软件做前端、API接入和微服务进行分层,在每一层都会加入质量控制手段,可以在软件开发的每个过程中规避质量风险。

有了容器云、有了新的软件架构,接下来我们想把软件过程做得更加自动化、更加高效。在软件过程自动化里,我们非常期待容器云。在开发阶段,容器云能够便利地提供开发工具,比如说Jenkins,之前的Jenkins节点管理都是松散的,基本上每个项目各有一套。Jenkins on Cloud方案能够在启动项目的时候,不需要申请主机、不需要部署,直接在Jenkins上新建一个Job就可以了。对于测试环节,如接口测试、UI测试、功能测试,我们希望通过Docker或者容器云应用编排的能力在几分钟之内构建一个测试环境去自动测试,这样可以极大地降低测试门槛。最后在软件发布的时候,由于Docker标准化的环境特性,也可以加速这个部分的进程。目前,上交所的业务系统采用的是主备灾的架构、多节点部署,此前,我们需要一到两个小时的时间部署一套操作系统,通过Docker,我们希望把时间降到半个小时以内。

传统企业面临的挑战

我们希望容器云能够把软件过程发展的核动力提上去。下面分享传统企业会碰到哪些挑战。

第一,我们的网络环境是隔离的,开发网络、外网是完全物理隔离的,这对于构建一个自动化的软件过程是很头疼的问题。另外我们的开发网、生产网和外网又是完全隔离的,安装一个开源包本来只需要5秒钟,而在我们这里需要5小时,这些都是非技术的困难。

第二,我们的技术标准是十分严格的,我们的操作系统目前允许用的是RedHat6,我们想更好地用Docker,那么就必须说服相关的人去用RedHat7。另外,Docker用sudo方式来管理应用,我们认为这种方式是无法接受的,因为这里会有一个问题——用sudo的方式,无法知道修改了哪些东西,会不会让操作系统崩掉?所以我们还要详细地列出容器云运行的最小权限。我们是一个业务导向的单位,在技术基础设施投入方面一般都是以小投入或者试点为主,所以我们找了一些像数人云这样的外部合作伙伴一起完成这个目标。

最后是Docker的局限性,它更多的是与基础设施相关联,现在做容器云,对于IaaS层的资源管理,包括网络以及分布式存储都是空白的,或者说不是很能满足我们的需求,我们也在探索一些新的解决方案。