本文共字，预计阅读时间。

文/东方证券股份有限公司周晓、于琳

（本文为“证券机构数字化转型与证券科技创新”征文活动入围文章。）

1、概要

随着互联网金融的爆发式增长和云计算技术的不断发展和演进，特别是移动互联网为公众提供越来越多方便快捷、稳定高效的金融类服务，对传统的证券业务带来了冲击和挑战。目前证券行业创新转型进程不断加快，在业务上不断创新的同时，面对业务种类增加、业务复杂度提升、软件版本发布频率、迭代速度提高、软硬件规模不断扩大的情况下，传统金融企业要适应互联网环境下IT基础设施资源弹性变化和业务快速部署的需求，需要思考自身的互联网金融战略。

与此同时，国内云计算的渗透正在逐步从互联网领域向传统产业的领域渗透。随着国内云计算产业的发展成熟，云计算技术也越来越成熟，从虚拟化到应用容器化，为传统金融业应用云计算架构的转型和升级找到了突破性的解决方案。特别是以Docker技术为代表的容器技术突飞猛进，颠覆了企业级应用的交付模式，Buildonce，Runeverywhere被越来越多的研发人员、运维人员所认可。同时容器技术作为云计算发展的新阶段正改变着IT服务交付的方式，更影响着云计算的未来。因此跟上云计算技术发展的趋势，建设并推广适合企业自身业务发展需要的容器云平台是促进业务创新、实现业务持续发展的必要手段。

2、建设容器云平台

建设容器云平台，帮我们化解难题的同时，也面临一些难点。

化解难题

• 缩短交付时间，提高交付质量
• 高效虚拟化，提高资源利用率，节约成本
• 妙级部署，提高应用部署效率
• 让微服务成为可能，降低系统复杂性

面临难点

• 容器技术的应用会打破传统运维模式
• 实现应用架构的转型，需逐步推广微服务架构，
• 容器技术不能解决所有问题

3、引入容器技术

Docker是一个开源项目，其作为一种新兴的虚拟化方式，与传统的虚拟化方式相比主要优势包括如下：

1)   环境标准化：容器解决了生产、SIT、UAT和开发环境差异，保证了应用生命周期的环境一致性和标准化。

2)   易于持续集成和持续部署：开发人员使用镜像实现标准开发环境的构建，开发完成后通过封装着完整环境和应用的镜像进行迁移，由此，测试和运维人员可以直接部署软件镜像来进行测试和发布，大大简化了持续集成、测试和发布的过程。

3)   提升资源利用率：与传统虚拟化技术相比，容器技术具有极低的额外资源消耗，与底层共享操作系统，性能更加优良，系统负载更低，在同等条件下可以运行更多的应用实例，可以更充分地利用系统资源。

图1.容器部署

Docker本身非常适合用于管理单个容器，真正的生产应用会涉及多个容器，这些容器必须拥有跨多个主机进行部署的能力，这样必将导致管理和编排变得越来越困难，最终不得不对容器实施分组，以便跨所有容器提供网络、安全、监控等服务。于是，以Kubernetes为代表的容器编排系统应运而生，其支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes的出现让容器的调度管理变的简单。容器提供应用级的主机抽象；Kubernetes提供应用级的集群抽象。

3.1. 建设容器云平台要点

建设一套完整的容器云平台，会涉及与公司的运维体系、监控系统、日志系统、基础网络环境、中间件、持久化存储等方方面面的整合，必须要从更高的维度，结合公司的现状、周边配套，甚至组织架构来整体设计、规划和实施。

建设容器云平台，不仅要具备标准的企业级容器平台管理能力，还要考虑金融行业的业务特殊性和严监管和安全要求。建设容器云的关键能力主要包括如下：

1)   管理大规模容器集群的能力，主要包括：提供容器所需的高可用集群、资源池管理、网络方案、存储方案、编排调度引擎、镜像管理和日志收集等。

2)   满足金融业务监管和安全要求，容器云平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、审计日志。

3)   遵从现有IT技术规范和运维要求，对接LDAP身份验证配置租户，对接统一告警平台，对接大数据日志平台，对接或改造容器云平台的网络，建设完整的监控体系。

4)   结合DevOps提升持续交付能力。

3.2. 容器云平台整体架构

容器云平台是一套对容器化应用进行管理的分布式平台，提供容器化应用资源管理、自动化部署、弹性伸缩，以及通过负载均衡策略实现对应用的管理、发现、访问等能力。

图2.容器云平台架构图

容器云平台提供高可用高性能可伸缩的容器应用管理服务。容器云平台底层是基础设施资源层，包括主机计算节点、网络、存储等资源共同构建的容器集群；基础设施资源层上运行的是容器引擎和容器调度管理组件，比如Docker、Kubernetes等，容器引擎运行在主机节点上，通过容器调度管理组件来实现容器的资源分配、限额、调度管理等能力；业务服务运行在容器中，每个服务可能对应着若干个服务实例（Pods或容器），所有的服务共同构成了服务层；这些应用服务通过服务编排成为业务应用，为客户提供相应的应用服务。

容器云平台与现有系统的对接，主要包括LDAP身份验证服务、统一告警平台、大数据日志平台、现有网络架构、建设完整的监控体系。

图3.容器云平台与现有系统对接

3.2.1.   资源池建设

容器云平台资源池管理负责容器运行所需的计算资源、存储资源的申请、分配、容量管理，以及提供适合的容器网络方案。资源管理包括容器云平台涉及的主机、集群、网络、存储等资源管理。其中涉及资源的增、删、改、查等管理，以及对资源情况在不同维度的数据统计和展示。

图4.容器云平台部署架构

网络建设：

图5.网络逻辑

图6.网络部署架构说明

3.2.2.   镜像仓库管理

镜像仓库负责存储和发布应用的镜像部署版本，在功能上并不复杂，但由于监管要求和业务的特殊性，要求用于生产发布的镜像版本必须通过严格的测试阶段，以及严密的安全检查步骤，因此建议对生产环境运行专用的生产镜像仓库；同时，在持续集成越来越普遍的情况下，为了保证开发和测试的方便，我们需要测试镜像仓库。建议生产镜像库和测试镜像库在物理上分开，网络上的连通通过防火墙策略做限制（只开放必须的端口用于镜像同步）。

图7.镜像仓库和流转架构图

在使用规则上，测试镜像仓库允许随时的镜像上传和更新，通常都会对接持续集成系统；而对于生产镜像仓库，为了保证镜像来源的安全、可控，建议限制为只能从测试镜像同步，规定只有在测试镜像仓库中标记为完成测试、经过安全检查的镜像，由有相应权限的账号，在经过必要的审批或者满足一定规则的情况下，从测试镜像仓库中把镜像同步到生产镜像仓库。一旦镜像进入生产镜像仓库，就被当做正式的生产发布版本，接下来就按照现有的生产发布和变更流程，在指定的变更窗口，从生产镜像库中拉取镜像进行部署。

在一个完整的应用生命周期管理过程中，研发团队使用研发运行一体化平台（DevOps）进行应用镜像的持续构建，生成的镜像推送至基于JforgArtifactory建设的镜像仓库，并通过JfrogXray工具进行镜像安全扫描，各应用负责人从镜像仓库拉取镜像部署至容器云平台（测试环境）当中。测试通过的镜像被同步到生产环境镜像仓库，运维基于具体的镜像和tag标识进行更新部署。镜像流转流程示意图如上图（图7）所示。

3.2.3.   容器化应用管理

容器化应用管理主要核心是提供容器化应用的编排、发布，以及应用发布后的全生命周期的管理，具体包括但不限于应用列表、服务列表、应用和服务拓扑图、灰度发布、弹性伸缩、应用配置等。

3.2.4.   容器监控体系建设

容器监控的核心服务通过Prometheus提供，其可以容器云平台进行全维度监控，主要包括:集群监控、分区监控、节点监控、组件监控、应用监控和Etcd监控。每套K8S集群独立创建Prometheus监控体系，相关数据对接到Grafana进行展示；K8SMaster和Node计算资源通过Zabbix进行基础监控（内存、CPU、网络、磁盘等），K8S中运行的Pod通过Prometheus进行监控，容器平台的Node资源监控逐步过渡至Prometheus监控。

图8.容器云平台监控架构图

3.2.5.   DevOps与容器云平台

DevOps主要用于开发、测试以及运维之间的协作管理，强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。持续集成和持续交付是实现DevOps的一部分，但不等于DevOps。DevOps应该还包括一套完整的持续部署以及持续运营的完整开发测试运维一体化的DevOps方法和工具。DevOps不是一定要用容器，但是有了容器，DevOps变得更加简单更加高效。

图9.DevOps与容器云平台的结合

4、容器云平台人员职责

容器云平台运维和传统IT系统运维不同。传统IT系统由于其变更节奏缓慢，独立性强，所以其运维的体系是以静态的CMDB为核心，以监管控流程化为驱动的手工运维模式。而容器云平台由于其分布式架构的特性和业务需要，已经转变为以动态运行数据为核心的监管控一体化自动运维。系统变更工作也由流程驱动转变为自服务交付。

图10.容器云平台人员职责说明

平台管理员：平台管理员需负责好容器云平台的建设，同时也是平台的超级管理员，负责对整体平台的实际管理及各类管理规范的制定和落实，加速平台在企业内部的落地运行及推广，整合基础设施资源并对上层业务提供更好的支持。

图11.平台管理员职责

租户管理员：租户账户由平台管理员来创建并由平台管理员来维护。平台管理员为每个租户创建租户账户并分配资源。每个租户下的用户和角色，由租户自己管理维护。平台管理只为每个租户创建一个且仅有一个租户账户。租户账户全局唯一。

5、容器化应用管理规范

容器技术作为新技术推广使用过程中，需要相应的管理规范指导工作。

5.1. 应用容器化规范

5.1.1.   Dockerfile编写

Dockerfile是一个用来构建镜像的文本文件，文本内容包含了一条条构建镜像所需的指令和说明。

1)   Dockerfile都必须以FROM命令开始。

2)   优化镜像大小，只添加需要的文件，清理无用数据，使用.dockerignore

3)   打上容易读的镜像仓库名和标签，当构建镜像时使用可理解的标签，以便更好地管理镜像;dockerbuild的“-t”参数可以用来指定所构建镜像的名称，为了便于管理镜像，原则要求构建镜像时必须加上该参数，并指定按如下格式的镜像名称：<镜像仓库地址>/<业务组名称>/<应用名称>:<应用版本>。

4)   避免在Dockerfile中映射公有端口，保证镜像灵活性；

5)   CMD与ENTRYPOINT命令请使用数组语法。

5.1.2.   镜像构建规范

镜像构建是指使用Docker命令根据Dockerfile指令，将应用打包进一个镜像的过程。重要的规范主要包括如下：

1)   明确镜像构建路径：构建路径是dockerbuild的必填参数，通常使用“.”，即当前目录作为构建路径。

2)   不使用缓存的方式构建镜像:dockerbuild默认会使用构建缓存，在某些需要强制刷新缓存的场景下，如Dockerfile文件中包含下载文件等操作，为了更新所需下载的文件，可以使用“--no-cache”参数采取不使用缓存的方式构建镜像。

3)   避免构建依赖特定环境的镜像

4)   构建的镜像不能存放敏感信息

5)   构建的镜像中不存放无用数据和日志文件

6)   减少容器层数，避免安装不必要的软件包

5.2. 容器化应用编排规范

随着单体应用微服务改造，容器化部署，集群中容器实例越来越多，因此需要对环境中的容器化应用进行编排，以更好的支持业务的稳定高效运行，降低运维难度和复杂度。

容器应用编排的目的是为了给容器平台上运行的应用进行建模标准化，描述应用运行的资源需求、部署模式、部署参数、运行时动态规则（弹性伸缩、故障迁移等）。

容器应用编排和管理规范概述：

1)   使用资源时指定最新稳定版的APIVersion；

2)   编排文件应该纳入版本控制，这样可以在必要的时候快速回滚，同样也有利于资源恢复和重建；

3)   使用YAML格式而不是JSON格式，尽管两种格式的文件可以相互转换，但是YAML格式更易读，更友好；

4)   使用单一的文件组织相关资源，单文件比多文件更好组织管理；

5)   很多kubectl命令可以作用于整个文件夹，比如kubectlcreatesomedir，可以对somedir目录中所有的配置文件执行create指令；

6)   对资源的描述可以写到annotations中，便于自省

字段定义说明：

举例说明：

6、使用容器云平台案例

6.1. 常用中间件容器化

应用中间件作为云计算应用架构中的重要一环，在整个业务体系中具有举足轻重的作用。常用的中间件包括Redis、Zookeeper、Kafka、Flink等。如果为每一个业务所需的中间件都配置足量的物理机，极易造成资源的浪费，无法优化资源使用率；而如果部署在虚拟机上，则在高负载情况下虚拟机很难满足快速提高的处理能力要求，无法快速动态扩展提高处理能力。容器化中间件应用，构建中间件应用标准化交付、资源弹性供给、灵活调度和服务隔离等能力，支撑行业服务。

图12.常用中间件容器化

通过对Redis、Kafka、Zookeeper、Flink等中间件进行容器化部署和功能测试、压力测试、高可用测试等测试验证，得出以下结论：

1)   证券行业常用的中间件可以进行容器化改造，容器化后可以保证性能的同时提升效率。

2)   借助容器标准技术，通过容器化应用中间件，可以优化传统业务应用架构，减轻运维压力，提高应用的业务支撑能力。

3)   容器技术一改传统物理机、虚拟机体积庞大、启动速度慢、资源消耗大的问题，提供一个轻量级的运行环境，能更好的实现业务系统更快速的开发迭代、交付部署。在微服务架构中，业务系统对中间件的需求会大量增加，容器化的中间件的交付及运维方式可以高效满足微服务架构下对中间件的快速交付、轻量级管理等要求。而随着DevOps管理体系建设的日趋成熟，容器化中间件开放的服务能力和状态支撑，更能满足面向未来敏态IT建设的需求。

4)   容器技术对底层环境的松耦合特性，对应用环境的标准化封装能力，为解决国产安全可控产品的生态薄弱问题提供了切实可行的解决方案，可促进证券行业的信息技术安全可控。

6.2. 基于容器云平台建设机构投研系统

机构投研系统作为容器云平台的租户之一，独享使用部分K8SNode计算资源，当机构用户登陆投研系统时，机构投研系统使用容器云平台的应用管理功能根据不同机构创建相应空间、部署预制服务、分配相关资源，同时借助网络管理中的NetworkPolicy功能实现不同机构应用的不能互访要求，当机构用户退出投研系统之后，会释放所分配的相关资源。

图13.机构投研系统

7、总结

容器技术发展非常迅速，相关的开源社区和厂商都在不断努力贡献自己的力量，新技术层出不穷。同时，微服务框架的功能越来越完备，随着微服务架构思想不断普及，不久的将来会有越来越多的新业务基于微服务架构的形式出现，而容器是微服务架构应用的最理想运行环境，这就意味着容器云平台未来的应用场景也是不断改变、进化和越来越丰富的。

要引入容器技术首先需要明确企业后续对容器的定位，比如：是在小范围创新应用使用还是准备全面推广？是面向高级技术人员还是面向普通应用用户？企业对应用可用性及业务连续性有何要求？这几个方面都决定了后续在容器云平台建设过程中的投入，包括人员、软件开发、硬件的投入。

在目前阶段，容器云平台的建设是一个不断改进，迭代积累的过程。一开始可能没办法在各个方面都能想得很清楚，不仅在技术方案，更在业务场景、运维方式、安全合规等方面，都需要很多的讨论。循序渐近，无论在平台扩展还是技术学习，都要循序渐进，欲速则不达。项目中遇到的坑要及时解决，防止为后期留下隐患。

参考文献

https://www.docker.com/resources/what-container

[Source]

本文系未央网专栏作者发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文为作者授权未央网发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文版权归原作者所有，如有侵权，请联系删除。