基于容器技术构建一站式业务支撑平台——实现业务需求快速交付，应用稳定可靠运行
来自2020年全国职业容器云大赛冠军队二二一队作品。
兴业数金 二二一团队成员：潘晓华、方胜、全彬元、徐林、孙佳明
1 建设背景
随着互联网的兴起，互联网企业依托互联网，特别是移动互联网为公众提供越来越多方便快捷、稳定高效的服务，对传统业务带来了很大冲击。作为应对，传统行业也在业务上不断创新，带来对IT基础设施和应用架构方面进行转型升级的要求。例如为了支撑电商促销活动对带来的高峰期海量支付请求，某银行很早就对支付渠道相关业务应用进行微服务架构改造，由此带来了容器技术的研究和运用。经多年实践证明，采用容器技术平台很好地支撑了新的业务模式和业务容量。
基于业务发展的需要，和快速进步的金融科技技术，越来越多的传统企业开始思考自身的互联网战略、上云规划等。其中重要内容之一，是希望从技术层面更有效地支持业务创新，如微服务架构、更好的灵活性、扩展性、高可用性、更高效的业务上线效率等，因此跟上云计算技术发展的趋势，建设并推广适合自身的基于容器技术的云平台是关键任务。
2 需求分析
2.1 业务需求
2.1.1 应用架构****改造需求
某银行的客户交互渠道系统存在以下两点架构问题，制约了其快速迭代，影响了用户体验：第一，竖井式系统架构，各模块各自开发和管理基础功能，存在大量重复开发工作；第二，非分布式架构，横向扩展效率低。
为了缩短系统的迭代周期，增强横向扩展能力，该渠道需要运用DDD思想，重构一套使用微服务架构的新系统。本文设计了一套基于容器的一站式业务支撑平台解决方案，用于部署该渠道系统的微服务版本。
2.1.2 应用架构****概要设计
基于微服务架构的新系统，将服务端在逻辑上分为业务域和通用服务域，业务域是面向客户的交互界面，主要功能是整合微服务向前端提供统一的交互视图；通用服务域是从各业务领域提炼出来的通用服务的集合，与业务域解耦，只提供单一的服务输出即原子服务，业务域可整合不同的通用域服务单元完成相应的业务逻辑处理，同时通用域还包含与业务无关的后台处理模块。
2.2 建设企业级容器平台
容器平台作为企业的新一代IT基础设施，不仅需要为基于微服务架构的新业务提供容器化运行和管控平台之外，还必须非常重视安全需求。因此建设容器平台的需求时，需要考虑包括的方面有：
l 管理大规模容器集群能力，包括：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。
l 为满足安全要求，平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志；如果容器平台还对公网提供访问，那么还需要考虑访问链路加密、安全证书等。
另外，一个重要方面是，容器平台通常是企业IT整个复杂系统中的一部分，因此容器平台还要遵从企业已有IT技术规范和运维要求，例如可能还需要考虑：
l 支持企业自身的应用发布体系、持续集成系统、应用建模规范、高可用管理策略。
l 对接云计算底层资源池（例如IaaS），遵从云计算资源的统一管理和分配。
l 对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对企业现有网络管理模式的冲击。
l 对接统一身份验证、和整个金融云其它系统采用统一的租户定义、角色定义、资源配额定义等。
l 对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统。
2.3 基于容器平台构建DevOps体系
业务市场竞争加剧，业务部门要求业务快速交付，业务系统就要充分复用其它业务应用系统服务：
l 作为业务部门，综合着眼关注业务进度，不关注需求之外的其它交付内容。
l 作为开发部门，期待资源得倒满足，需求明确，交付内容清晰，项目计划到位，资源充足，时间充裕；如何以更有效的方法进行需求调研，更好的架构进行开发，更有效率的测试策略及项目管理方式。
l 云资源交付部门，期待资源容量评估、架构评估、交付内容完整、时间宽裕、安全合规。
l 安全部门，所有各个阶段严格按照网络规范实施交付，并配以持续监测和更新到最新安全机制。
l 运维部门，期待支撑所有交付均考虑运维体系完备性，基于主机和服务两个维度、不同对象目标的运维体系完备；所有运维数据均可以共享互访并使用。
关注在业务场景下，对于容器平台及DevOps要求的需求上，还包括弹性要求、高可用要求、快速交付、需求变化要求等。在 Kubernetes 和容器普及之前，我们通过虚拟机也可以实现DevOps，只是速度相对较慢，因此普及性不高（想象一下通过 x86 虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为 DevOps 工具层面的落地提供非常好的承载平台：
l 容器云平台，需要DevOps以标准化和提升IT研发和交付能力。DevOps可以部署在容器云平台上。
l 基于容器化PaaS平台的DevOps，可以使用容器云的资源，譬如DevOps平台的相关技术组件，可以以容器方式部署在容器云上，以支持多pipeline流水线并发编译所需要的弹性资源。
Openshfit 以容器技术和 Kubernetes 为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（ S2I/Jenkins ）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，实现DevOps落地效率比较高。
3 设计架构
3.1 整体设计
一站式开发交付运行平台提供持续集成、自动部署、弹性伸缩、高可用、监控告警、微服务治理等特性，解决互联网业务爆发性强，难预测，响应要求高，需求变化快的的特点，为应用提供全生命周期的支撑管理能力，从业务需求管理、应用开发、持续构建、持续部署到应用运维保障。
3.1.1 容器平台
l 基础设施
IT基础设施为平台提供计算、网络、存储、安全等资源，支持物理机、虚拟化、私有云和公有云等多种环境。
l 容器引擎Docker
平台使用Docker作为容器引擎层。容器技术是一种进程隔离技术，它通过namespace/cgroup等技术从内核空间、资源和安全等方面对进程做隔离。因为容器是进程级别的，所以它非常轻量，能够实现秒级启动。另外容器镜像将运行环境与应用一起打包，实现了一处构建，处处部署，为应用的交付与运维管理提供了一种标准的方式。Docker是目前使用最为广泛的容器引擎，已被大规模生产环境验证。
l 容器编排层Openshfit
平台使用Openshfit作为容器编排层，Openshfit基于业界容器编排标准Kubernetes技术，并在安全性上进行了增强，同时为了方便开发者使用容器技术，对应用的构建与部署等集成方面也做了功能的增加，有助于快速构建一个功能全面的容器平台。
作为容器编排引擎，Openshfit具备全面的编排相关的功能：应用编排、应用部署、应用配置、应用升级、负载均衡、弹性伸缩、健康检查、权限管理、容器网络、网络存储等；除此之外，Openshfit还提供了更全面的管理功能，如应用构建、日志中心、资源监控，应用商店等。但是Openshfit自带的运维管理功能有它的局限性，平台将会对其日志中心、资源监控等功能进行全面扩展与增强。
l PaaS服务
平台基于Openshfit之上，采用Operator技术实现的可扩展PaaS服务（包括数据库、消息队列、缓存、反向代理等中间件服务）。Operator为PaaS服务提供构建、扩展、监控、备份等能力。研发与运维人员只需要在平台门户进行提交表单，就能方便快速地构建高成熟度中间件服务。
l 容器平台门户
平台基于Openshfit和Docker容器技术，并与DevOps支撑平台进行集成，提供面向应用全生命周期管理的企业级PaaS云解决方案。提供对平台与应用服配置、部署、运维及管理能力；支持多数据中心、多集群、多租户、多项目等多个维度管理；与DevOps平台集成，实现一体化的持续构建与部署的能力。
3.1.2 DevOps支撑
DevOps平台提供了需求管理、CICD流水线、代码配置管理、制品管理、质量管控等功能，提供了从计划到测试的问题持续集成过程，提供了从计划到测试完成的过程持续发布过程，解决了从计划到上线的持续部署过程，覆盖了用户提出价值到用户使用并且监控维护的端到端过程。
通过DevOps平台，实现了在制品的持续流动、持续反馈，进行持续优化，让质量持续提高。
通过DevOps平台，实现了研发数据的度量管理，通过对团队的研发数据进行定量分析，及时发现研发过程中的不足，有助于提高研发团队的效率和质量。
通过AIOPS的接入，通过对日志等数据的持续监控，实现常见问题的自动化运维，保证应用的持续可用。
3.1.3 运维保障
l 资源管理
通过开发Openshfit管理门户，实时管理集群资源使用现状，通过记录资源台账（记录计算、存储、网络ip端口资源）的方式，记录并预分配准备上线的系统，保障集群配额充足，及时提出扩容需求。
租户资源：通过ResourceQuotas对租户资源进行限制，以保障租户间不相互影响。
pod资源：通过LimitRange对pod和container资源进行限制。
l 日志管理
集群日志统一由EFK组件收集、管理和展示，通过统一管理，大大提升了日志查找、故障排查的效率，同时Openshfit管理门户也开发了日志的展示和查询功能，实现了在挂历门户对集群故障的初步定位能力。
l 监控告警
除了集群内部的Prometheus，还将集群资源使用情况、集群组件状态、项目pod状态等信息以标准格式输出给集群外部的监控工具，进行统一管理、告警和展示，具备短信邮件等告警提醒等功能。
l 事件管理
容器平台上运行着成千上万个资源，每个资源在生命周期过程中状态不断变化，每一个状态变化过程中都会涉及到多条事件信息，及时获取到这些信息中有问题的部分能够帮助项目最早时间发现问题，这就是事件管理的重要意义。本方案中，将采用EventRouter收集平台所有事件，对于异常事件会在第一时间通过告警平台发出。
l 网络管理
网络管理包括两个部分：传统网络管理、集群内部网络管理。
传统网络管理，主要集群内外网络访问以及不同网络区域之间底层网络控制策略的管理，主要通过网络防火墙策略的维护。
集群内部网络管理，主要通过NetworkPolicy策略进行控制。平台支持图形化配置该策略，为管理员提供良好的操作体验。
l 数据备份
数据备份包括以下两个方面：集群数据备份、应用数据备份，其中集群数据备份包括有资源对象备份、证书与集群配置备份、集群Etcd数据库全量备份。
集群数据备份通过oc、Etcdctl命令客户端及shell命令实现资源对象、证书、配置及Etcd数据库全量数据的备份与恢复。
引入NBU（NetBackup）备份策略，为应用持久化存储做备份。Veritas NetBackup拥有Docker认证，它能为应用存储提供高效、简便、灵活的应用备份解决方案。
l 巡检机制
通过编写健康检查脚本，对集群核心组件的健康状态、核心组件运行过程中的异常日志以及平台的负载状态等按日进行巡检，将高危风险以邮件形式发送给平台运维和研发人员，并及时分析处理，以确保平台稳定运行。
l 集群升级
平台在日常运维中将定期关注集群的最新补丁与漏洞报告，并及时对集群进行升级，保证平台的安全稳定。
3.2 非功能性设计
3.2.1 高可用性
平台高可用性涉及到五个方面：集群高可用、应用高可用、存储高可用、网络高可用以及制品库高可用。
l 集群高可用
集群的高可用主要有两部分：单集群的高可用和多集群提供双活服务两个部分。
单集群的高可用：控制节点是集群最核心的部分，其上面的组件均采用高可用部署：Etcd集群化部署、Master组件服务均为多副本部署。同时Master组件部署在支持自动迁移策略的虚拟机平台，即当底层物理机发生宕机后，其上运行的虚所机会自动漂移到备用节点，并且多个控制节点分散部署，进一步提升集群的可靠性。
双活机制提升集群服务可靠性：在同一机房部署多套集群，集群业务互为备份，同时提供服务。
l 应用高可用
应用高可用主要有两部分：应用设计和应用部署。
应用设计：应用提供对应的健康检查接口，与容器平台的检查机制配合实现应用自动恢复；容器平台支持应用生命周期控制，例如通过HTTP接口健康探测机制可实现故障的容器实例的自动重启。
应用部署：应用采用多集群多副本部署，容器具有轻量、启动快速等特性能够支持快速扩容；平台为应用提供亲和与反亲和等调度策略，应用部署可选择合适的策略以提升应用的可用性；容器平台支持应用滚动升级保证应用升级过程中服务不中断。
l 存储高可用
平台为不同场景提供多种存储方案。分布式存储、本地存储、共享存储等都考虑多副本机制提高存储的高可用性，并且对于重要数据基于NBU提供定时备份。
l 网络高可用
网络高可用主要有两部分：集群底层网络和集群内部网络。
集群底层网络：交换机、路由器等网络设备采用双活部署，主机双网口绑定bond提供可靠的本地网络；集群将数据网、业务网、管理网分离，减小不同网络数据之的干扰。
集群内部网络：集群提供多副本且支持流量分片的Ingress/Router节点，并通过高可用负载均衡器承载外部包括TCP、HTTP协议的请求流量。平台提供全面的监控体系，对网络服务的异常进行自动监测与诊断，在满足一定的条件下，实现网络服务自动恢复。
l 制品库高可用
制品库采用单地备份、多地同步的机制。单个制品库的服务端采用多活的方案同时提供服务，底层数据则采用冷备方案对应用镜像进行定期备份。同时平台在各地分别部署制品库，各地制品库通过之前的同步机制实现多地镜像的同步，实现互为备份。
3.2.2 易用性
l 可视化管理
平台提供了可视化管理界面，通过界面可以直观地查看集群的状态。同时对于应用开发的整个生命周期都支持可视化，包括需求管理，开发流水线，应用的测试报告，流水线度量指标以及运行状态等。
l 自动化管理
容器平台部分提供自动化运维工具，实现集群自动化部署、自动化升级、自动化备份、定期自动巡检、服务及资源监控告警。DevOps平台部分，自动化流水线实现应用的持续构建，持续部署与持续监控。
l 交互式操作
平台提供表单交互式，实现快速创建PaaS应用以及应用部署。
l 多集群管理
研发人员通过一个入口就可以管理多中心多集群，实现多集群统一管理，同时权限与用户集中化管理，方便容器平台的使用。
l 多系统集成
与监控告警平台、日志平台、DevOps平台等系统集成，实现一站式应用全生命周期的支撑。
l 多租户管理
平台具有丰富的用户与权限管理，支持细粒度的权限控制以满足更多的安全控制的要求。
3.2.3 安全性
平台从主机、容器、平台自身、镜像、网络、应用及数据等方面构建全面的容器安全体系，保障平台及应用的安全。
l 主机
主机操作系统安全加固；系统安全补丁管理机制；针对不同安全要求主机划进行分组管理，不同组的应用间物理隔离。
l 容器
容器引擎漏洞管理；容器最小权限原则，禁用root等用户；容器资源限制；容器日志分析与审计；CIS容器配置基准保证。
l 平台
基于RBAC的权限管理；平台升级机制，修复平台漏洞；平台运行日志分析与审计；CIS平台配置基准保证。
l 镜像
制定安全标准镜像作为应用基础镜像；通过镜像扫描机制防范安全漏洞；镜像签名保证平台运行镜像均已被可靠认证。
l 网络
通过底层网络策略，防火墙和ACL，按照安全等级设计不同安全要求的网络区域；集群采用细粒度网络控制机制NetworkPolicy；通过路由分片实现对不同网络安全要求应用进行隔离；通过EgressIP机制实现集群间网络访问控制。
l 应用
DevOps流水线对应用代码与服务进行持续漏洞扫描，进行安全合规审查，保证应用的安全。
l 数据
对于底层存储数据采用硬件加密；对于应用的敏感配置数据采用vault管理的secret资源保存。
3.3 关键模块设计
3.3.1 容器平台
3.3.1.1 服务编排与管理
服务编排中，需要考虑资源的统一管理、应用部署及应用弹性伸缩。
资源管理：平台通过对项目配额的管理实现对集群资源的统一分配，能够快速响应开发部门的资源需求；针对不同类型应用提供不同的底层计算节点，如计算型、内存型等，以便进一步提高资源的利用率。
应用部署：应用支持多地多集群部署，通过容器平台可以同时指定应用部署的集群及各自的副本数，容器编排引擎将会自动完成应用的部署。
弹性伸缩：应用通过HPA、VPA资源配置，对应用的负载进行监控实现应用资源限制与副本数配置的扩展与收缩，以支持流量激增的互联网场景。
3.3.1.2 网络
网络场景主要考虑以下四种场景：集群内部网络、集群间网络、集群访问外部网络以及外部访问集群间网络。对于金融行业，网络安全非常重要，该方案中充分考虑在任意种场景下的网络安全问题。
集群内部网络：采用OVS-Networkpolicy网络策略实现集群内部服务网络精细化管理，不同项目间的应用默认网络隔离。
集群间网络：平台支持多网络区域下集群的统一管理，不同的网络区域底层通过硬件实现隔离。例如，DMZ区与生产区分别部署Openshfit集群，之间通过硬件防火墙进行隔离。
集群访问外部网络：采用EgressIP机制，为每个Project指定出口IP，该Project下的所有应用都以该IP对外部发送请求，通过集群与外部系统间的防火墙控制网络的访问权限。
外部访问集群：集群服务通过Openshfit Router服务对外提供HTTP/TCP服务。并且根据业务类型对Router进行分片，更大程度提升Router服务的性能与扩展性。
3.3.1.3 存储
单一的存储方式无法满足复杂的业务场景，方案根据不同的场景内容提供对应的存储介质。
场景一：应用内部多容器共享缓存，使用容器自身临时存储。
场景二：应用不同副本间共享存储使用NFS网络存储。
场景三：对于存储IO要求较高，并且支持单节点挂载，使用Ceph RBD分布式存储作为应用持久化存储。
场景四：对于存储IO要求很高，采用本地盘存储方案，将应用与主机通过Node Label进行绑定。
场景五：采用MinIO部署独立的对象存储服务，为容器应用提供相关数据持久化
3.3.1.4 镜像仓库
镜像仓库是一个集中存储容器镜像的空间，在企业中建立企业级的镜像仓库有利于集中管理容器镜像，并且利于实现多个环境之间的镜像资源共享。Openshfit组件中提供了镜像仓库，且它与资源对象DeploymentConfig、BuildConfig等能够联动，以快速实现自动构建与自动部署，但是它与项目强关联并且在镜像安全扫描方面有所欠缺，很难将它作为一个企业级通用的镜像仓库。基于上面的考虑，本方案中将引入Harbor作为平台的统一镜像仓库，并通过镜像仓库命名规范与制品库管理规范集中管理所有环境中的镜像。
开发测试环境与生产环境网络是隔离的，分别部署独立的Harbor服务。其中项目在开发测试环境的镜像会被分别存放在不同的仓库中分别是DEV/SIT/UAT/PROD，镜像只有经过严格测试达到上线标准后才能推送到PROD仓库中，PROD仓库与其它地区的开发测试环境中的PROD仓库同步，同时这与同地的生产环境中的PROD仓库同步，实现应用镜像的多地分发。
为了提高镜像的下载速度，以加快应用的部署，镜像服务还开启P2P预热，生产中将应用镜像提前分发到P2P网络。
3.3.1.5 监控告警
监控告警系统是平台系统运营维护的有利保障，目前云原生生态中较为成熟也是被使用最广的方案是Prometheus套装。通过不同的exporter服务获取相关的指标数据，由Prometheus统一收集，并通过Grafana展示出图表，相关监控项状态与趋势一目了然，下图为Prometheus方案组件架构图。
Exporters：面向全方面资源的监控指标，具体有底层节点的相关指标、平台组件状态与性能指标、集群应用容器资源状态指标、自定义应用性能指标。
Prometheus server：通过pull方式从Exporters收集底层设备、平台组件、容器资源、应用自定义所有监控指标。
Grafana：提供对Prometheus采集的监控数据进行可视化展示。
Alertmanager：接入多种告警渠道（邮件、短信、微信等），统一管理多个来源的告警信息，如Prometheus rules策略触发的告警、日志监控触发的告警、自定检查脚本触发的告警，如下图所示为Alertmanager作为统一告警系统架构。
为了便于对多个集群集中监控，采用Prometheus Federation架构实现多级监控，将不同集群监控指标统一收集，并将历史监控数据持久化在MinIO S3存储中。
3.3.1.6 日志
虽然Openshfit组件中提供了基于EFK的日志方案，但这种方案并不能适应所有的业务场景。它有以下不足之处：应用日志只有标准化输出才能被收集；只能有一个日志输出文件，而真实业务场景中会有多个日志文件；Fluentd的性能并不算太好；Fluented直接发送到ES，当日志量大时，很容易发生堵塞，导致日志延时大甚至丢失日志。基于以上这些考虑，本方案中将对日志方案进行性能与功能的增强。
采用更轻量及性能更好的Filebeat替换掉Fluentd来收集集群组件日志及应用标准输出的日志，仍然以DaemonSet资源的形式部署。
对于没有标准输出的应用，以sidecar的形式共享日志文件并通过filebeat收集日志文件，将其发送到Kafka中，由logstash转发到ElasticSearch服务，最后由Kibana服务展示。
引入Kafka作为日志缓冲层，提高集群应用日志的吞量。应用的标准输出日志，通过DaemonSet FileBeat服务统一收集并转发到Kafka中，由后端logstash转发到Elasticsearch服务中。
该日志方案不仅满足生产业务中的各种场景，而且能够支持高并发日志量。同时使用的组件均可通过横向扩展来扩大整个系统的吞吐量。
3.3.1.7 容器平台门户
为了让架构具有更好的扩展性，云平台设计了四层架构：展示层、业务层、驱动层、数据层，如下图所示。另外为云平台设计了平台控制器，通过它实现容器集群资源对象数据实时缓存到Redis中。
l 展示层
负责平台的页面展示，它为用户提供一套可视化，交互式的界面。研发人员通过查看或者填写表单等操作，调用业务层Restful API接口，获取详细的资源与业务数据，并在页面渲染。
l 业务层
负责平台的业务逻辑，为展示层提供Restful API接口。它会对请求的权限做验证，通过调用驱动层获取请求的资源基础信息，并通过Redis获取底层资源的详细信息，最后以JSON格式数据返回给展示层。
l 驱动层
负责与底层集群的交互，它通过指定的证书可直接访问底层集群的Master API Server，进而实现对容器集群资源的管理。同时它通过Restful API为业务层提供所需的服务。
l 数据层
负责保存容器平台的业务数据，包括有项目信息、用户信息、审计信息、权限配置、集群配置信息等。
l 平台控制器
每个集群都会部署单独的平台控制器，并为它绑定获取该集群的所有资源信息的权限，使用watch API监听底层资源的变化，一旦对应集群有新增的资源，或有资源信息发生更改，或资源被删除，平台控制器都会将信息同步在Redis缓存中，从而收集所有集群的资源对象信息，并确保信息一直处于最新状态。
容器平台门户支持多集群管理，集群信息通过平台管理功能保存在数据库中。业务层请求驱动层时会带上被访问的集群名，驱动层通过查询数据库获取集群的访问信息，定位到正确的集群。
3.3.2 DevOps支撑
DevOps平台采用禅道做为需求管理工具，同时采用Jenkins作为流水线引擎，其它工具链通过Jenkins进行驱动，实现应用自动高效构建与自动部署。同时Jenkins引入k8s插件，所有节点，包括Master节点与slave节点均部署在容器云平台之上，充分利用容器平台的快速部署能力，实现流水线的高效执行。以下是DevOps支撑能力的整体示意图。
3.3.2.1 需求管理
引入禅道开源产品进行产品需求管理，并通过禅道中的电子看板实现需求全生命周期的可视化跟踪，完成需求计划管理。
通过电子看板中的模块管理实现对需求所属功能模块的划分，让产品人员能够从整体上看到需求的功能划分。
通过计划管理实现对需求的统一规划，我们可以定义每个时间节点的目标，根据优先级、工作量等条件把需求规划到每个计划中。
团队成员根据自身情况分析每个需求的工作量大小，并将需求分配到个人，计划开启后，每个人根据需求的实际完成情况修改需求的状态。同时通过与代码库、测试平台的对接，展现需求的代码提交情况、测试情况。
使用统计报表，图形化展现需求的完成速率、历史情况，帮助项目组进行工作回顾。
3.3.2.2 开发
l 代码配置管理
提供组织级的gitlab平台用于研发人员对代码进行配置管理。通过制定配置管理规划能够对提交的代码进行有效管控；通过对代码提交信息的格式约束能够将代码与需求进行关联；通过对代码库的webhook进行配置，代码提交即可触发流水线，对代码进行构建、扫描、测试，能够有效管控代码质量。除此之外，对于关键代码，还进行code review、代码走查等，保证提交的代码质量。
l 代码扫描
提供组织级的静态代码扫描平台SonarQube和Fortify，基于PMD、CheckStyle、FindBugs制订了组织级的代码检查规则。研发人员代码一旦提交到代码库就会触发代码扫描流水线，能够及时发现代码中的Issues和Bugs，可视化技术债务，明确技术债务分布情况、债务点以及改进建议等，从而能够及时得到解决，提高产品质量。
l 制品管理
基于Nexus构建组织级的制品仓库，对制品进行成熟度管理，只有制品满足各项度量指标后，制品才能部署到下一阶段，最终部署生产环境。同时在制品元数据中记录制品的质量数据，确保了部署到生产环境的制品是经过严格测试的、满足质量要求的。
l 单元测试
要求代码的单元测试覆盖率满足一定要求，同时关键代码必须要有单元测试。在实际开发过程中，使用TestNG、Junit等工具进行单元测试案例的编写，并引入Jacoco进行单元测试覆盖率的收集。只有单元测试覆盖率满足一定要求后，代码才能进行打包构建并上传到制品仓库中，进而后期才能进行部署及自动化测试等。
3.3.2.3 测试
禅道平台也作为测试管理平台，对测试案例、缺陷进行统一管理，并且与需求进行关联。同时会将测试的结果数据记录在制品的元数据中，确保部署到生产环境的制品必须要符合质量要求。
l 功能测试
采用selenium工具对于需要上线的系统进行功能测试并且生成测试报告，待评审通过以后才能进行上线。通过对系统进行白盒、黑盒、灰盒、边界值等多维度的测试，确保系统能够满足功能需求。
l 自动化测试
采用selenium工具开发实现自动化测试脚本，并作为Jenkins构建任务的一部分。自动化测试主要包含两个方面，一个是UI测试，一个是接口测试。通过CICD流水线将制品成功部署到测试环境以后，自动会触发自动化测试流水线，通过编写好的自动化测试脚本对系统进行测试。
3.3.2.4 部署
通过打包构建生成制品以后，制品会根据事先定义好的Dockerfile构建成镜像并上传到镜像仓库中。然后使用容器平台将镜像依次部署到SIT、UAT等环境进行测试。测试通过以后将镜像提交到待发布库中。生成下发流程通过以后，触发容器平台进行生产部署。
3.3.2.5 运营维护
通过容器平台，可以很便利的对其中的应用进行日志、性能等多维度的监控，同时提供了预警机制，当机器或应用性能触发阈值以后，会向应用负责人发送短信和邮件提醒。从而应用负责人能够实时掌握应用状态，对出现的一些状况能及时处理。
3.3.2.6 平台度量
对各个能力子域的指标进行量化，在流水线的实际执行过程中收集这些指标，同时对收集指标进行分析、打分，得出此次执行的一个量化数据。通过收集每次流水线执行的指标数据，就可以获取到该应用的整个质量的趋势，从而能够更好的指导应用开发。
4 规范指引
4.1 业务规范
4.1.1 业务需求规范
l 统一语言
业务需求应当使用统一的语言，所谓统一语言，是指项目研发过程中，产品、研发、测试、运维、管理、运营等角色在交流中，对一些专有名词理解达成统一，以保证大家在沟通中没有信息不一致或信息歧异，提高沟通效率和准确度。
l 业务需求格式
业务需求描述中应明确，清晰，不应使用可能、一般等模棱两可的描述，应当体现出业务功能的角色、活动、价值（效果）。此处不应使用技术语言来描述，要使用用户可以理解的业务语言来描述。通常格式为作为一个<角色>, 我想要<活动>,以便于<商业价值。
举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
4.2 应用上云设计规范
4.2.1 应用容器化设计规范
l 应用中不指定Pod的IP
应用容器化部署后，Pod的替换伴随着IP的变化。若应用指定Pod的IP访问目标应用，一旦目标应用的Pod发生变动，目标应用的IP也会随着变化，目标应用将无法被正常访问。为了保证应用访问服务的稳定性，应用中不直接通过Pod的IP来访问目标应用。可以通过注册中心，获得动态IP的方式来实现服务间的调用，也可以直接使用serviceIP来实现不同应用间的调用。
l 同一Pod内的不同容器间使用127.0.0.1相互访问
同一个Pod可以有多个容器，这些容器共享同一个网络命名空间，它们之间推荐直接使用127.0.0.1来实现互相访问。
l 为应用实例提供健康检查接口
应用需提供健康检测接口，用来配置容器的健康检查策略，从而保证滚动升级过程中的服务可用性。
l 应用容器需要考虑优雅退出
为了保证应用服务的稳定，应用容器需要考虑优雅退出，确保容器退出时关闭所有连接。如果应用程序未处理SIGTERM信号,可以在编排文件中设置preStop Hook,即在关闭容器前等待一段时间，让应用程序完成所有请求。
l 使用CronJob代替crontab服务设置定时任务
不建议在容器中使用crontab服务设置定时任务，推荐通过CronJob资源对象来实现定时任务的功能。
4.2.2 应用部署规范
l 应用容器通过使用PV/PVC进行持久化数据
容器本身并不带有持久化存储，被销毁时容器中存储的数据也会被清理。容器中如果需要保存数据，需要通过PV（持久化卷）与PVC（持久化卷请求）资源，使用NAS存储，实现数据持久化。
l ConfigMap挂载到容器内部的文件夹必须为空
配置文件可以保存在ConfigMap中，ConfigMap挂载到容器内部的目录会把目录下的原有文件覆盖，所以需要注意挂载的目录尽量为空目录。
l 每个系统申请一个EgressIP，作为访问外部服务的出口IP
为了对系统网络做更精细化的控制，容器云平台每个系统必须申请并绑定一个EgressIP。该系统下的应用Pod都以该IP为出口IP访问外部服务，通过防火墙设置，可以对系统下的应用访问外部服务的网络进行控制。
l 为应用实例设置健康检查
为了更好地监控应用服务的状态，充分发挥容器云平台为应用带来的自愈能力，提高应用的可靠性，应用必须设置readinessProbe与livenessProbe。其中readinessProbe将检测应用容器是否已准备好接受流量，livenessProbe将检测应用容器是否存活。
l 为应用实例设置资源限制（cpu与memory）
为了对资源进行精细化管理与控制，减少底层资源的竞争，也可避免程序因Bug占用过多底层资源，以提高应用的稳定性，容器基础平台的应用部署时必须为每个容器设置资源限制，包括：limits.cpu、limits.memory、requests.cpu、requests.memory。其中limits.cpu、limits.memory为应用运行过程中占用CPU、Memory资源的上限值；requests.cpu、requests.memory为应用运行过程中请求的CPU、Memory资源值。
4.3 应用开发规范
4.3.1 数据交互规范
l 接口格式
通常每个URI网址代表一种资源接口，网址中不应有动词，尽量使用名词（特殊情况可以使用动词）；网址名称不应大写，若需要分割时使用中杠-不用下杠 _ ；若URI中的名词表示资源集合，使用复数形式。
应当使用url来表达层级，用于按实体关联关系进行对象导航。层级不应过深，复杂场景尽量使用查询参数代替路径中的实体导航。应当将API的版本号放入到URI中。
l HTTP方法
应使用标准的HTTP方法实现对资源的CRUD，包括：
GET：查询（从服务器取出资源一项或多项）；
POST：创建单个新资源。 POST向“资源集合”型uri发起；
PUT：更新单个资源（全量），客户端提供完整的更新后的资源；
DELETE：删除。
其中GET、PUT、DELETE方法应具备幂等性，也就是执行1次和执行N次，对资源状态改变的效果应是等价的。
l HTTP状态码和提示信息
正确设置http状态码，不要自定义http状态码。服务器返回的提示信息应尽量简洁，避免嵌套，采用信息代码（用于日志/问题追查）+错误的描述文本（展示给用户）的形式。
l 接口文档
数据交互应形成良好的接口文档，包括但不限于以下内容：
1) HTTP方法类型：也就是我们常写的GET，POST，PUT，DELETE等。
2) url调用方法：从前端调后端的方法地址。
3) 请求参数：包括字段、说明、类型、备注、是否必填。
4) 返回参数：尽量使用JSON，避免使用XML。
l 异常处理
异常应包括业务异常和非业务异常。业务异常由自己的业务代码抛出，表示一个用例的前置条件不满足、业务规则冲突等，比如参数校验不通过、权限校验失败。非业务类异常 表示不在预期内的问题，通常由类库、框架抛出，或由于自己的代码逻辑错误导致，比如数据库连接失败、空指针异常、除0错误等等。
业务异常应返回200的HTTP响应状态码，并返回指定的错误文本提示信息。非业务异常应返回500的HTTP响应状态码，异常信息应进行统一封装，如“服务器端错误，请稍后再试”，非必要情况不应将错误类型展示给用户。
l 安全
对于API的使用应当有身份认证，同时具备一定的安全手段用于预防常见的安全攻击。
4.3.2 应用镜像构建规范
l 使用统一的基础镜像
基础镜像涉及应用运行所需要的安全可靠的Linux操作系统。基础镜像由基础架构部门负责维护，定期打安全漏洞的补丁，并基于应用要求构建基础环境镜像，维护到公共镜像仓库。
l 公共依赖层
主要是包括运行时（如JDK）、中间件（如Web容器）、其它公共组件等。公共依赖层镜像由基础架构部门负责维护，定期打安全漏洞的补丁，并基于应用要求构建依赖层镜像，维护到公共镜像仓库。
l 应用层
主要包括程序包（jar包、war包）、程序依赖包（jar lib）等。程序包基于代码基线编译打包，应用层镜像由开发部门负责构建。
l 镜像一次构建，多环境部署
为了保证应用的运行环境保持一致，应用容器镜像应在研发环境下构建，在其它环境下部署进行测试与上线均使用同一个镜像。
l 使用非root用户启动应用容器
为保障容器云平台的安全性，禁止应用容器中使用root用户运行应用。
4.3.3 DevOps指引
4.3.3.1 开发流程自动集成
1) 项目配置好CI/CD流水线后，开发人员提交代码；
2) 自动触发CI/CD流水线运行，对项目代码进行代码扫描、单元测试；
3) 获取私服Maven仓库资源（非必须）进行构建；
4) 构建完成后，生成最新的镜像保存到镜像仓库。
下图为开发集成部署流程图。
4.3.3.2 开发提测流程
1) 开发人员用gitlab给代码打上提测Tag；
2) 开发人员手动在Jenkins上提测，执行提测任务；
3) 自动触发工程指定版本代码的构建，并生成指定版本的镜像；
4) 测试人员在测试环境部署指定版本镜像，进行测试。
下图为开发提测流程图：
4.3.3.3 集成测试流程
测试人员在测试环境部署指定版本镜像，进行测试。
下图为集成测试流程图：
说明：以上流程均可在开发测试PaaS集群操作，如果要上生产部署，需搭为生产环境单独部署另外一套PaaS集群，同时两个集群网络与资源隔离。
4.3.3.4 生产部署流程
1) 运维人员从测试环境同步指定版本的镜像；
2) 运维人员在生产环境部署指定版本镜像。
下图为生产部署流程图：
4.4 运维规范
4.4.1 容器平台运维规范
4.4.1.1 定期巡检
将Openshfit集群重要组件的健康状态检查封装在shell脚本中，设定定时任务，实现自动化巡检，按时生成巡检报告，以邮件形式发送至平台运维、研发单位。定期巡检包括：master-api、master-controller、Etcd、router、es、prometheus等组件的状态。
4.4.1.2 扩容评估
设计Openshfit集群资源预申请台账，结合集群管理门户查询到的集群资源实际使用情况，记录Openshfit集群当前的资源总量和计划上线的系统所需资源，根据台账的资源申请比例，安排计算、存储资源扩容。
4.4.1.3 应急预案
根据Openshfit集群特点，制定应急预案：一是记录硬件资源、软件资源、集群逻辑架构、数据备份方案、关联系统、应急联系人等信息；二是记录系统节点及部署模式，便于故障发生时快速查阅节点信息；三是针对平台层11个故障场景（硬件、网络、平台组件）、应用层6个故障（管理门户、sftp等）场景的处置方案，以及故障恢复后的验证方案。
其中平台层故障处置方案主要有以下三个层面：
基础设施故障：物理主机故障、基础网络故障、存储设备故障。
平台服务故障：管理节点集群组件服务异常（Master API、Master Controller、Etcd)，工作节点服务异常（atomic-Openshfit-node、Docker服务），集群间网络异常（sdn、ovs服务）。
运维相关应用故障：监控服务异常（Prometheus服务），日志服务异常（Fluentd、ES服务）。
4.4.2 应用运维规范
4.4.2.1 应用发布
Openshfit集群将部署文件和镜像文件从制品库拉取至本地，再通过oc命令进行发布。该部署过程按场景编排成多个自动化流程，通过在管理端填写发布相关的参数执行。
4.4.2.2 应用回退
Openshfit集群将旧版本的部署文件和镜像文件从制品库拉取至本地，再通过或oc命令进行发布。该回退过程按场景编排成自动化流程，通过在管理端填写版本tag相关的参数执行。
4.4.2.3 应用监控
设计每分钟一次的定时任务，将影响应用可用性的关键指标，结合集群各宿主机节点的系统指标数据统一发送至监控平台进行集中管理、展示、和告警。
4.4.2.4 应用伸缩管理
根据特定的大流量业务场景需要，平台允许在特定时间区间、在平台可以容纳的容量范围内，对应用进行扩缩容处理，扩缩容命令封装后，编排成自动化运维平台的流程，通过填入扩缩容副本数量等参数执行。
4.4.2.5 日志管理
容器应用日志须落盘持久化卷存放，不同容器分不同文件进行存储。日志必须进行合理分级，按时间或大小自动分割，并依据合理的压缩和清理周期管理。
容器应用日志命名合理规范，日志内容要素齐全：时间、日志级别（INFO、WARN、ERROR）、线程名称、交易标识、用户id、日志消息体、异常堆栈等。
容器日志访问须提供两种方式：一是由平台自带的EFK组件统一管理和展示，二是通过应用系统相关虚拟机或物理机节点直接访问。
4.4.3 制品管理规范
4.4.3.1 镜像准入管理
基础镜像使用RedHat操作系统。
公共镜像原则上仅包括一种中间件软件。若同一公共镜像需要包括大于一种中间件软件，必须采用多次构建方式。
应用镜像必须使用镜像仓库统一提供的基础镜像或公共镜像构建。应用镜像必须符合精简原则，应包括且仅包括针对公共镜像的配置修改、可执行的应用包、依赖包介质和启动命令，不得包括其它与应用无关的文件。应用参数配置文件不应包含在应用镜像内部。
4.4.3.2 镜像命名管理
镜像命名使用小写字母，避免下划线，最长64个字符，每段命名间使用“-”连接。
格式如下：
其中：
1)
2)
3)
4)
5)
5 分阶段实施规划
5.1 方案验证阶段
5.1.1 功能测试
设计功能测试验证样例，在测试环境按生产1:1搭建容器云平台，详细测试容器云平台各功能点，并将DevOps体系各模块串连起来，完成持续构建与持续部署链路的验证。并设计集成测试验证样例，模拟生产环境发起业务验证，最终形成《集成测试报告》，所有业务场景验证通过。
5.1.2 压力测试
为保障基于Openshfit构建的容器平台在实际生产运行中符合非功能性要求，在准生产环境部署Openshfit集群，通过测试工具发起压力测试，测试结果满足业务运行要求。以及测试DevOps系统支持并发构建与部署的最大容量。
5.2 技术推广阶段
经过功能测试和压力测试，集群满足上线部署要求，DevOps体系能够完成应用全生命周期的调度后，提交运维单位在生产环境部署集群，部署Openshfit管理门户、配置项目计算资源，对接制品库，从制品库拉取镜像部署应用。通过shell脚本实现监控信息转化，传送至统一监控告警系统，实现分钟级监控集群日常运行状态。
在此阶段中，应不断提升与优化容器平台及DevOps平台，以适应本企业各项目组的实际要求，最终形成最佳实践与标准规范。
5.3 规模化推广阶段
经过技术推广，验证了Openshfit集群在生产环境承载业务的能力，在本地生产环境部署了双活集群，前端业务流量通过F5负载均衡至两个集群，实现集群层面的高可用性。后续，本集群可以针对灾备要求高的信息系统，部署异地灾备集群。诸如企业级短信发送平台这类高可用要求高，但对数据查询实时性要求不高的系统，可以部署在异地双活的Openshfit集群，数据库分别部署在两地，每日日结后再将当日数据合并至历史库。根据部署类型，本方案中设计的容器云平台，可以支持本地双活、异地灾备、异地双活的多种集群部署场景。
同时根据企业在上一阶段形成的最佳实践及标准规范，全面推广DevOps体系，项目优先使用DevOps平台全面支撑应用的开发、测试及部署，并建设DevOps体系成熟度评估模型，标准化推广DevOps建设。
