掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务

恒生金融交易系统的Docker化实践

Docker可以显著改善企业软件研发流程、提升企业DevOps效率。借助Docker,企业可以对现有IT系统进行一次梳理,解决IT软件系统部署、升级难的顽疾,重新释放企业生产力,降低企业成本。本次分享介绍了恒生电子运用Docker技术,加上自研配套工具,实现金融交易系统配置、部署、运维自动化的心得,包括:

  1. Docker的优势以及我们为什么要使用Docker;
  2. 恒生Docker运用现状;
  3. 恒生金融交易系统的Docker化实践过程;
  4. 恒生Docker未来规划。

Docker的优势


随着Docker技术的日趋成熟和完善,越来越多的企业开始考虑使用Docker。Docker在开发、测试、运维部署方面已经展现了其巨大的优势,具有很强的生命力。能够极大的解决过去DevOps的弊病,提高效率,节约成本。

(一)开发测试方面:


在开发测试我们都遇到过这些问题:开发、测试环境不一致,测试出的bug,在开发环境不能重现,需要花费很大的精力在应用环境的维护部署上。应用系统对运行平台有着特定的要求,很难达到在不同的平台间进行安全移植。对于应用的版本控制也比较混乱,不能够方便地对应用进行升级维护。

Docker在持续集成、可移植性和版本控制方面有着天然的优势,很容易解决这些弊端。

  1. 持续集成

    Docker很容易解决环境的一致性问题,对开发、测试和运维人员有着极大的吸引力。由于安装包版本不同和依赖关系,在开发、测试和发布的整个过程中,很容易造成环境的差异。Docker可以通过确保从开发到产品发布整个过程环境的一致性来解决这个问题。

    使用Docker可以确保开发者不需要配置完全相同的环境,可以在自己的系统上建立虚拟机从而运行Docker容器。Docker可以让我们构建、测试和发布镜像,这个镜像可以跨多个服务器进行部署。
  2. 可移植性

    Docker容器能运行在主流公有云提供主机操作系统的平台上,目前Windows也支持了容器的部署。举例来说,运行在阿里云上的Docker容器能够很容易地移植到其他几个平台上,比如说华为云,并且达到类似的一致性和功能性,那这将允许你从基础设施层中抽象出来。
  3. 版本控制

    Docker允许我们提交变更到Docker镜像中并通过不同的版本来管理它们。设想如果你因为完成了一个组件的升级而导致你整个环境都损坏了,Docker可以让你轻松地回滚到这个镜像的前一个版本。这整个过程可以在几分钟内完成,如果和虚拟机的备份或者镜像创建流程对比,那Docker算相当快的,它可以让你快速地进行复制和实现冗余。此外,启动Docker就和运行一个进程一样快。 

(二)运维部署方面:


在对应用进行部署时,一台主机,一般不会在上面运行过多的应用,有时一台主机只运行了一个程序。究其原因,无非是担心用户数据泄露以及程序之间的相互干扰等。

Docker很好的解决了这个问题,首先docker的隔离性隔离了应用和用户数据,使应用更加安全,用户更加放心;而资源限制避免了一个应用过多消耗资源,从而影响其他应用。

我们为什么要使用Docker


恒生是中国领先的金融软件和网络服务供应商,金融IT领域龙头企业,为客户探索领域内的新方案是我们的责任。

Docker作为一项新技术,在短短的时间内受到各个企业的青睐,有着其得天独厚的优势。恒生是一家技术型金融IT企业,技术创新一直是我们所推崇的,将Docker新技术应用在金融领域,为金融行业提供可靠的Docker解决方案,是我们的责任。

传统的方案,在软件开发和测试、运维的过程中存在诸多问题和不便。比如持续集成困难,开发、测试、运维环境不一致,版本管理问题,硬件资源不足等。Docker将应用的依赖集成进镜像中,很容易的解决了开发、运维环境不一致的问题。容器相互之间的、容器与主机之间的隔离性,让一台主机可以运行多个容器,并互不影响,这就很好的解决了硬件资源不足的问题。每一个版本会生成一个镜像,对于版本的维护、升级以及版本回退都极其方便快捷。Docker的一键部署,极大的节约了运维人员的时间成本和精力。

Docker的天然优势,能够极大提高DevOps效率。

恒生Docker运用现状


2015年成立团队专门做Docker相关的研发,到目前为止基础平台和关键应用系统已经Docker化,各个部门都在推进各自产品的Docker化。大部分的测试环境,目前都采用Docker进行部署。

(一) 持续集成


继续集成采用的Jenkins,目前Jenkins服务器已经使用Docker进行部署;集成编译环境由于系统版本低,不能很方便的迁移到Docker环境,所以部分用于集成编译的worker节点还是传统的虚拟机。

在Jenkins任务完成后,会制作镜像推送到镜像中心。当然这些可以通过容器管理工具,在界面上进行操作,或者配置成定时任务。

(二)镜像中心


目前,Docker方面的研发主要包括镜像中心、容器部署管理、PaaS平台等。

镜像中心在开源项目Harbor的基础上,增加了CAS集成和项目的组织架构管理以及高可用等。

增加CAS集成,主要是因为在镜像中心部署在内部域内,为了和现有用户体系打通。

为了方便Linux机器登陆镜像中心,并且不会泄露用户域密码,用户会在镜像中心内部设置一个用于Docker登陆的密码。

Docker镜像增加项目组织信息,方便统计各部门产品Docker使用情况。

部署了2套Harbor来做高可用,使用同一个数据库,避免数据同步,但是需要解决镜像复制的问题。

使用Harbor镜像复制的方式将镜像同步到生产环境和测试环境镜像中心,避免中心镜像中心压力过大。

(三)容器管理


管理方面主要包括机器资源管理、应用管理、容器管理等。

机器资源管理中,用户可以建立多个集群,每个集群管理多台机器,以隔离不同的环境。

应用管理中,用户先创建应用,然后在应用下添加服务,服务可以是单个节点,可以是一个集群。然后在界面上修改服务配置,修改好配置后,再选择要部署到哪个机器集群,进行应用部署。管理工具会将配置文件上传到配置中心,然后启动应用容器,容器启动后,先到配置中心取相应的配置,然后启动应用。

Docker管理供用户查看Docker容器、网络、镜像等。

另外为了兼容低版本操作系统和Windows系统,应用部署也支持用户上传zip包的方式。

PaaS方面,主要是为用户提供更方便的服务,用户可以一键申请MySQL、SLB等常用服务。

恒生金融交易系统的Docker化


(一)挑战


恒生金融交易系统的部署面临诸多挑战:

金融交易系统最重要的是稳定性和性能。系统稳定性和并发性要求高,系统延迟要尽量低。为了满足上面要求,软件的可运维性没有受到重视,存在着以下问题:

  1. 系统复杂,部署困难

    金融交易系统包含的节点数成百上千,对于运维人员来说,部署交易系统面临诸多挑战。

    首先是要求更多的物理机,避免节点混合部署相互影响。其次,每个物理机的环境要求较高,运维人员需花费不必要的精力浪费在主机基础环境的搭建。
  2. 配置复杂

    交易系统的每个节点基本上都有多个配置文件,这些配置也就成百上千,如何管理这些配置文件,如何更新配置文件,都成为了一个难题。
  3. 扩展性

    当交易量大时,需要对交易系统进行动态扩展。 

(二)实现


  1. 网络

    网络方面,为了尽量不影响交易系统的性能,以及支持系统用到的复杂协议如组播等,直接使用了host网络模式。
  2. 存储

    存储方案上,使用host主机存储,避免使用网络存储带来的开销和延迟。文件系统采用OverlayFS存储方案,OverlayFS是一个联合文件系统,并且已并入Linux内核。在镜像的制作,容器的操作都相对较快,而且问题比较少。
  3. 配置管理

    配置管理方面,使用单独的配置中心存储配置,单独管理,避免配置和应用耦合。然后和管理工具集成,提供Web编辑界面。
  4. 服务注册发现

    服务注册和发现,使用改造的Confd和Registrator来实现,根据容器标签来进行注册和发现,避免端口导出太多。
  5. 弹性扩展

    弹性扩展方面利用Compose的Scale,来扩展容器,通过服务注册和发现工具,使新节点加入到现有集群中。

解决了上述的问题后,现在用户可以通过容器管理工具,在Web界面上,一键部署交易系统,给测试和运维带来了极大的便利性。而系统的性能也没有多少的损耗。

恒生Docker未来规划


未来我们将加大Docker的推进力度,继续优化交易系统的Docker部署流程,寻找更优化的方案,同时将更多的服务集成到PaaS平台,给用户更好的体验。

Q&A

Q:请问下,你们现在这个系统容器规模多大?OverlayFS有遇到什么坑吗?

A:现在系统容器是100多个。由于镜像数少,对文件inode占用少,所以OverlayFS基本满足需求。但是需要主机内核高一点,在3.18以上。

Q:请教一下。咱们这个容器管理平台是用什么语言开发的?直接调用Docker Remote API吗,用的是最新的1.24么?

A:Java语言开发,直接调用的Docker Remote API,版本是1.24.

Q:MySQL服务也Docker化了吗,怎么保证存储安全?

A:MySQL这块是我们实现了RDS,底层用MySQL的复制方案。

Q:交易系统应该涉及很多运行组件。在决定哪些组件容器化时有哪些考虑?

A:一般性能要求很高,延迟要求在微秒级的组件,比如高频交易等,基本不考虑Docker化。

Q:核心架构是Swarm+Docker+Confd+Registrator,如何实现动态扩展?

A:组件还包括了Etcd,利用Etcd+Confd+Registrator来做服务注册和发现及配置管理,利用Docker Compose的Scale做服务的扩展。

Q:请问你们用的编排系统都是Docker 1.12的Swarm吗,如何实现容器都是夸主机冗余部署?

A:1.12也在试用,现在主要是老模式的Swarm,利用容器的互斥性,相同集群的2个容器实例,不要部署到同一台主机上。

Q:请教下业务组件的镜像有多大?如何实现跨平台迁移,不如从华为云部署到阿里云之类?

A:镜像大小在几百M,利用镜像中心的远程复制功能,同步到生产环境的镜像中心,比如阿里云和华为云上。

Q:镜像安全如何保证?

A:目前基础镜像都是由我们自己制作,会检查安装的软件和版本。后续会引进镜像安全扫描,来定期检查镜像。

Q:请问网络采用host模式,如果一台主机运行多个同一端口的容器怎么办?比如运行2个Tomcat项目?

A:我们在容器管理工具中增加了端口的配置管理,不会出现这种情况。另外部分网络性能要求不高的应用,也会采用flannel host-gw的方案,这样端口就可以相同了。后续会调研MacVLAN模式,给每个容器分配一个物理IP地址。

docker.gif

原文来自:Docker

声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com

  • 营运车判定查询

    输入车牌号码或车架号,判定是否属于营运车辆。

    输入车牌号码或车架号,判定是否属于营运车辆。

  • 名下车辆数量查询

    根据身份证号码/统一社会信用代码查询名下车辆数量。

    根据身份证号码/统一社会信用代码查询名下车辆数量。

  • 车辆理赔情况查询

    根据身份证号码/社会统一信用代码/车架号/车牌号,查询车辆是否有理赔情况。

    根据身份证号码/社会统一信用代码/车架号/车牌号,查询车辆是否有理赔情况。

  • 车辆过户次数查询

    根据身份证号码/社会统一信用代码/车牌号/车架号,查询车辆的过户次数信息。

    根据身份证号码/社会统一信用代码/车牌号/车架号,查询车辆的过户次数信息。

  • 风险人员分值

    根据姓名和身份证查询风险人员分值。

    根据姓名和身份证查询风险人员分值。

0512-88869195
数 据 驱 动 未 来
Data Drives The Future