DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践

本文讲的是DockOne微信分享( 八十九):恒生金融交易系统的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地址。

以上内容根据2016年10月18日晚微信群分享内容整理。分享人柳正龙,恒生电子研发中心Docker技术负责人。8年来一直专注于金融行业高性能中间件、分布式消息分发系统架构和研发。对于网络通信、服务器性能调优、GDB调试等有丰富的经验。2015年开始研究Docker技术,现负责推进Docker技术在公司内的落地。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

原文发布时间为:2016-10-25

本文作者:柳正龙

原文标题:DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践

时间: 2025-01-23 20:25:38

DockOne微信分享( 八十九):恒生金融交易系统的Docker化实践的相关文章

DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps

本文讲的是DockOne微信分享( 八十八):PPTV聚力传媒的Docker与DevOps[编者的话]DevOps是2009年前后提出的一个概念,提倡开发(Development)和运维(Operations)这两个领域的高度协同.从而在完成高频率部署的同时,提高生产环境的可靠性.稳定性.弹性和安全性.本次分享介绍了PPTV聚力传媒以Docker技术为支撑,在DevOps方面做的优化,包括: DevOps简介 Docker在PPTV的应用 DevOps与Docker的结合 实现方案 DevOps

DockOne微信分享(九十九):海航生态科技舆情大数据平台容器化改造

本文讲的是DockOne微信分享(九十九):海航生态科技舆情大数据平台容器化改造[编者的话]海航舆情监控系统能够为海航集团内部提供监控网络舆情信息,对负面信息.重大舆情及时预警,研判具体舆情或者某一舆情专题事件的发展变化趋势,生成图标报告和各种统计数据,提高舆情工作效率和辅助领导决策.然而,随着项目的持续运行,许多问题逐渐暴露出来,为了解决这些难题,对整个项目重新规划设计,迁移到Hadoop.Spark大数据平台,引进持续化Docker容器部署和发布,开发和运营效率得到显著提升. 一. 舆情平台

DockOne微信分享(一一九):Elastic-Job-Cloud作业云在当当的SRE实践

本文讲的是DockOne微信分享(一一九):Elastic-Job-Cloud作业云在当当的SRE实践[编者的话]本次分享面向对Mesos与SRE感兴趣的听众.随着容器技术在国内的持续流行,关注点已经由容器技术本身向运维方面逐渐过渡,Google一直安利的SRE经验正好契合了这个时代的运维节奏,由此契合SRE概念而衍生的Mesos,Kubernete服务也持续推动着相关理念落地.当当正是在这种背景下研发并推广作业云平台,该平台借助Mesos平台打造高自动化云平台.本次分享将重点为大家带来我们是如

DockOne微信分享(一二九):聊聊Service Mesh:linkerd

本文讲的是DockOne微信分享(一二九):聊聊Service Mesh:linkerd[编者的话]随着企业逐渐将传统的单体应用向微服务或云原生应用的转变,虽然微服务或者云原生应用能给企业带来更多的好处,但也会带来一些具有挑战的问题,如怎么管理从单体应用转向微服务所带来的服务间通讯的复杂性,怎么实现微服务间安全,高效,可靠的访问,如何满足多语言多环境的透明通讯,服务发现.熔断,动态流量迁移,金丝雀部署,跨数据中心访问等等.本次分享给大家引入一新概念服务网格(Service Mesh)以及介绍业界

DockOne微信分享( 一零二):基于容器的日志管理实践

本文讲的是DockOne微信分享( 一零二):基于容器的日志管理实践[编者的话]业务平台每天产生大量日志数据,为了实现数据分析,需要将生产服务器上的所有日志收集后进行大数据分析处理,Docker提供了日志驱动,然而并不能满足不同场景需求,本次将结合实例分享日志采集.存储以及告警等方面的实践经验. 2013年以来Docker迅速火了起来,它的理念带来了非常大的便利性,不过实际应用中会发现还有监控.日志.网络等问题尚待解决,本文会结合实例分享数人云做容器日志系统的经验. 基于ELK的日志管理系统架构

DockOne微信分享(一三九):基于Kubernetes的应用编排实践

本文讲的是DockOne微信分享(一三九):基于Kubernetes的应用编排实践[编者的话]近年容器的使用越来越深入,越来越多的服务采用容器的方式进行部署.但随着服务数量的增加,如何管理服务之间的依赖关系,如何对多个服务之间的更新与部署进行管理,如何在新的环境中实现多个服务的快速部署.这些问题都希望通过基于Kubernetes应用编排管理来解决,从而实现对于复杂多服务系统的快速部署和高效管理. [烧脑式Kubernetes实战训练营]本次培训理论结合实践,主要包括:Kubernetes架构和资

DockOne微信分享(一一六):某股份制商业银行定制化PaaS介绍

本文讲的是DockOne微信分享(一一六):某股份制商业银行定制化PaaS介绍[编者的话]某股份制商业银行的PaaS平台是由Wise2C与Rancher合作,基于Rancher做的定制化开发.基于业务场景和银行业的特殊需求,同时为了兼顾能够实现对以后Rancher版本的平滑升级,我们在Rancher之上做了一层逻辑抽象. [深圳站|3天烧脑式Kubernetes训练营]培训内容包括:Kubernetes概述.架构.日志和监控,部署.自动驾驶.服务发现.网络方案等核心机制分析,进阶篇--Kuber

DockOne微信分享(六十九):微服务选型之Modern Node.js

本文讲的是DockOne微信分享(六十九):微服务选型之Modern Node.js[编者的话]目前Node.js的发展非常快,大家可能还停留在:Node.js性能很好,Node.js里都是回调,写起来很恶心,Node.js只能做前端工具,Node.js是单线程部署会有问题,以及这样的八卦<uber用go替代Node.js重写了地理位置服务>... 可是真相呢? 在微服务盛行的今天,为什么我们要选用Node.js去构建微服务呢?本次分享将试图从以下2个方面给出答案: 被误解的Node.js:除

DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

本文讲的是DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践[编者的话]企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发.应用交付.上线运维等环节,包括代码的管理.持续集成.自动化测试.交付物管理.应用托管.中间件服务.自动化运维.监控报警.日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术.涉及的核心功能模块以及相关方案. 为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能