某券商容器云项目方案设计最佳实践

作者：王作敬 汪照辉

本方案设计基于我们整理的容器云平台可行性分析陈诉，和对容器云平台需求的详细分析和设计，以及在我们和容器云厂商BoCloud博云在容器云项目实施方案根本上整理而成。本文为非正式实施文档，仅用于技术讨论和交流。我们认为这样的文档是容器云平台生产就绪的一个重要标准，也是和厂商沟通、确认需求和验证功能的重要载体。本文档是容器云项目方案设计主文档，尚有各组件的详细方案设计文档作为增补。


一、容器云平台需求概述
平台需求可以分为功能性需求和非功能性需求两部分。

• 平台功能需求概述
  

根据容器云平台项目需求阐明书，功能性需求总共分为三个部分，容器云平台管理和资源管理、多租户管理和应用管理，标准化交付和管理。各部分的关系梳理如下：

平台管理要求具备平台资源管理和资源隔离、租户账户管理、公共镜像库（中间件商店）、分层安全机制、高可用、易于扩展/更新/迁移能力。预留将来可扩展支持多云管理等能力。重点在于资源管理，具备向租户按需提供根本设施资源的能力。平台管理同时创建租户账号，维护公共镜像堆栈和堆栈中镜像。
多租户特性需求要求具备租户管理、租户资源管理、租户应用管理、微服务及服务治理、私有镜像库、租户安全等能力。重点是租户应用管理及服务治理能力，以及安万能力。同时提供维护租户下用户、权限、角色、组织架构、分配的资源，租户私有镜像堆栈的能力。租户账号由容器员平台管理员创建，租户利用租户账号登录容器云平台租户管理界面，维护租户下的组织架构、用户、角色、权限、资源、应用、服务等。
标准化交付的对象是镜像，向公共镜像堆栈或私有镜像堆栈构建镜像。公共镜像是指对全部租户可用的镜像，通常由平台管理员来维护。私有镜像是租户自己的镜像，仅对租户自身可见。同时支持镜像上传下载同步等能力。重点是构建持续集成工具链（利用Jenkins），持续集成止于镜像堆栈，以镜像堆栈为媒介实现持续摆设、持续反馈、持续改进闭环DevOps流程。
根据每部分的详细需求，我们界说平台管理员视图和租户视图，以及持续集成流程实现标准化交付能力，详细功能如下：

平台初始化之后只有平台管理员账户，租户账户平台管理员按需创建。安全需要覆盖全方位，确保每个层次都具备可靠的安全机制。
容器云平台面临着支持客户中心和服务中心的上线需求。必须建立基于SpringCloud框架的微服务支持。

• 非功能性需求概述
  

容器云平台非功能性需求最重要的是安全性、可扩展性和稳定性以及满足业务服务摆设管理的性能需求、用户操作友好性需求。以满足容器云平台升级、迁移、更新、扩展需求。
可用性：可用性是平台可靠性、稳定性等的综合表现，可靠稳定的平台可用性才高。通常可用性是评判一个平台或系统的最重要维度，可用的平台才能考虑性能等其他维度。
可扩展性：可扩展性或者弹性是容器云平台或者云计算平台的价值所在。容器云平台需要提供弹性的根本设施资源，用于业务应用的弹性扩展。
界面友好：在每一个用户登录后都有个Dashboard来总括该用户的资源分配利用、应用摆设运行、系统组件运行状况等；然后通过链接可以直接跳转查看详情。各环节相干联成为一个闭环。需要注意的是诸如“项目”等是开发测试阶段的概念，在运维过程中统一利用应用或服务。在接纳微服务架构之后，统一是服务和应用建设，不再有“项目”概念，一切皆是服务。服务编排为应用。
性能：性能分两个方面，一是平台的性能需求，另一个是服务的性能需求。平台的性能每每决定着其上摆设的单个服务实例的最大性能。平台的性能每每取决于平台根本设施资源的能力。也就是平台的硬件设施配置。另一方面，服务的扩展能力，负载平衡能力也是实现高性能的重要方式。


二、容器云平台方案设计原则
建设容器云平台的目的是用来承载业务应用的，为了实现IT融合、应急响应、敏捷开发、应用交付、权限认证、弹性伸缩、异常迁移、环境一致性、高可用、网络隔离、资源配额、日志收集、健康查抄、监控告警等能力；中远期目标是通过接纳微服务架构、DevOps方法论等渐渐构建企业的服务中台。
容器云平台的方案设计需要遵循建设容器云的目的和需求，满足以下设计原则：

• 高可用原则：关键核心组件，都要求高可用设计、高可用摆设，保障在服务器宕机等故障环境下，应用不受影响。
  
• 先进性原则：平台的建设所接纳的技术是业界主流云计算技术，确保平台在一定时间内具备稳定的更新和保持先进性。
  
• 成熟性原则： 技术选型确保先进性的技术上，接纳成熟的技术，确保平台功能稳定。
  
• 开放性和兼容性原则：标准化或通用的技术本领兼容主流的设备和系统、软件、工具等。
  
• 可靠性原则：提供可靠的计算、存储、网络等资源，在平台、服务、应用、组件等方面实现高可用，避免单点故障，保证业务的一连性。
  
• 可扩展性原则：接纳分布式架构，支持在不更改团体架构的前提下进行系统扩容和业务范围的扩展。平台的计算、存储、网络资源等根据业务应用工作负载的需要进行动态伸缩。
  
• 松耦合原则：容器云平台架构接纳松耦合架构，平台各组件提供开放标准的API接口，方便客户已有系统的集成或平台组件的扩展和替换。
  
• 安全性原则：安全无处不在。支持覆盖全方位的安全机制。横向：弹性伸缩、负载平衡、异常迁移等；纵向：协议层加密、网关、访问控制、过滤、限流、熔断、禁用root用户运维权限、系统资源用户受限访问、资源隔离、网络计谋等。容器云平台应该在各个层面进行完满的安全防护，确保信息的安全和私密性。
  
• 用户友好原则：注意用户体验，提供简洁便利的操作体验，避免二义性，界面操作保证流通简单。
  
• 隔离性原则：容器云平台租户之间实现隔离，租户和平台管理之间实现隔离。
  
• 生态原则：容器云平台需要构建生态体系，提供和集成认证、权限、配置、日志、监控、告警、注册发现、网关等能力，支持真正的企业业务应用。
  

三、容器云平台项目方案设计目标
容器云平台项目方案设计是为了基于容器云平台需求阐明书来实现建设容器云平台的目标。容器云平台需求包罗平台和资源管理、租户和应用管理和标准化交付和管理三部分，方案设计目标就是为了满足这些部分的需求，实现业务目标。同时对于平台重点组件和能力进行设计，指导项目实施和运营，解决技术难点和疑点题目。
容器云平台项目方案设计的目标界说如下：
1．        界说容器云平台范围，需求分析
2．        界说容器云平台总体架构和组件
3．        界说容器云平台各组件能力
4．        界说容器云平台交互UI界面
5．        界说容器云平台的摆设架构
6．        确定容器云平台的关键技术选型
7．        界说微服务技术架构、服务治理框架和模型（基于容器平台）


四、容器云平台总体架构设计

• 团体架构的设计思绪阐明
  

容器云平台是以承载业务应用为中心的，其设计重点在于为业务应用的运营提供资源和分租户管理运维业务应用。同时为了提拔敏捷开发和测试的能力，提拔持续集成、持续反馈、持续响应的能力，实现合理的DevOps流程和工具选择。
容器云平台架构设计时， 遵循设计原则，明确设计目标，提供真正意义上的企业级方案，权限、职责、范围要明确界说。仅有容器或容器调治管理不敷以支持业务应用，需要构建容器云生态组件体系，包罗认证、权限、配置、日志、监控、告警、注册发现、网关等组件。容器云平台各生态组件松耦合摆设，接纳开放性标准API接口，可以根据需要进行扩展或替换。     

• 总体架构设计图
  

深刻理解容器云平台是承载业务应用的，平台总体架构以业务应用管理为核心，覆盖业务应用全生命周期过程。容器云平台基于容器技术，通过容器编排和调治框架，实现对根本设施资源层的管理和对应用服务的资源供给，提供计算、网络、存储等资源。容器云平台提供平台级日志服务、监控服务、认证服务、权限服务、多租户能力、镜像堆栈等根本组件。

租户管理和租户应用管理提供机动的组织架构、用户、角色、权限的界说和业务应用、服务的运营阶段管理。CI/CD实现业务应用、服务的开发、测试、摆设发布阶段管理，平台完备实现业务应用、服务的整个生命周期管理能力。以支持我司微服务应用客户中心、服务中心以及产物中心的上线，以及互联网应用、大数据应用等。

• 平台管理架构设计
  

平台管理重点在于资源管理，资源分别为集群——节点（CPU、内存）、存储（本地、长途存储）、网络。容器云平台可能有多集群，每个集群在创建时界说集群网络，管理容器云节点，存储。一个集群可能有一到多个逻辑分区，分区是资源的逻辑分别。容器云资源支持标签，通过标签来分类资源，在应用/服务摆设时作为资源选择的依据。根据选择的网络类型来确定是否支持网络计谋界说，网络计谋从网络层实现网络隔离。
容器云平台支持认证、日志、监控告警、计量计费等根本功能，这些组件和平台是松耦合架构，但各组件之间需要实现统一认证、单点登录能力。

容器云平台Dashboard展示平台资源利用环境（总的资源、已利用、可用）以及资源利用最多的top 10租户及利用明细；平台节点环境（节点配置、节点资源占用、可用，节点上Pods或容器数目，资源紧张的予以不同色彩提示）；平台Pods、Containers运行环境（Pods量、状态、异常；平台组件利用的Pods和租户应用利用的Pods，两者要分开）；公共镜像统计；平台组件运行状况。
租户账户由平台管理员创建，包罗租户名称、账号、暗码、租户联系方式、租户资源分配。
公共镜像堆栈由平台管理员来维护，提供平台级的中间件镜像服务等。
系统设置界说容器云平台级配置和设置。
权限管理提供不同级别的平台管理员权限，比如平台管理员为每一个集群创建集群管理员来维护其独立的容器集群。

• 租户管理架构设计
  

租户管理重点在于应用管理和服务治理能力。一切围绕业务应用的运营、治理为中心。

租户Dashboard展示当前租户或用户下主要业务应用或资源利用最多的若干业务应用的运行状况。比如应用的负载、响应时间、并发量、异常请求数；最近5分钟、30分钟、1小时、4小时、8小时、24小时、48小时等运行环境统计；业务应用下服务实例的数目（Pods/容器数目）、运行环境、异常次数，处理请求数、平均响应时间、最大响应时间等；展示业务应用利用的资源环境等，汗青资源利用，总的和分应用图形展示。
权限中心提供对租户下组织架构、用户、角色、权限的管理维护，支持机动的组织架构和角色界说。
租户资源由平台管理员分配，咱不考虑支持自动扩展，分配固定资源，若资源不敷的告警再次申请扩容。
每个租户有自己独立的私有镜像堆栈。服务/应用镜像存储于私有镜像堆栈。租户可以贡献镜像到公有镜像堆栈供全部租户利用，经平台管理员验证后公开可用。
应用管理和服务治理是租户的核心工作。容器云平台为租户提供注册发现机制、服务配置管理中心、服务网关实现访问控制/路由/过滤等安全机制、集中日志中心、链路跟踪、监控告警中心、使命调治中心、弹性伸缩、负载平衡、健康查抄等服务治理能力。

• CI流程设计
  

接纳Jenkins工具构建持续集成流程。JDK1.8.171，代码堆栈是用SVNv1.7，源码查抄工具Sonar ，构建工具Maven 3.3.9 or Gradle 4.0， 镜像堆栈DTR or Clair，镜像扫描工具，缺陷管理工具Jira。单元测试Junit。自动化测试Selenium，自动化运维Ansible， 拓扑关系图支持zipkin。
开发工具Eclipse， 测试工具Jmeter。

Eclipse集成Sonar完成源码查抄，代码完成之后提交到代码堆栈SVN，Jenkins实现对SVN代码更改的监控，自动触发代码编译、构建过程，完成后生成jar 或者war文件或镜像文件（构建服务器需要安装Docker，操作系统版本要求CentOS7.4或以上）。单元测试过程中假如不通过则自动生成邮件通知源码提交人。
测试过程起首构建该服务相干测试域，即该服务依赖的服务的集合(根据配置自动拉取镜像完成摆设)。QA则依据需求提供测试数据，输入测试数据完成测试。有异常则发邮件通知，确认是缺陷转入缺陷管理。
完成测试后镜像文件同步到生产镜像堆栈。测试和生产环境是隔离的，通过跳转机来完成，只有颠末镜像安全扫描确认安全的镜像才可以被同步到生产环境镜像堆栈。
生产环境中镜像根据需要进行摆设和发布。


五、容器云平台各模块及组件功能界说
容器云平台是一个生态体系，包罗容器云平台及支持其上的业务应用和服务体系架构所需的各项组件，全部的组件可以界说为平台级和服务级，但也有些组件既服务于平台也服务于业务应用，比如日志中心组件。我们也曾和BoCloud博云等厂商深入讨论过相干组件建设，相互都有受益。

• 集中日志中心
  

集中日志中心是容器云平台日志的收罗、存储、汇聚、分析、展示的组件，接纳基于ELK + Graylog等工具来实现集中日志中心的能力。提供基于中性化集群的管理、查询功能。支持标准输出日志收罗、文件日志收罗、log4j日志文件收罗，kafka数据收罗等。
日志收罗工具除了logstash，另外接纳filebeat、metricbeat、packetbeat、winlogbeat、auditbeat、heartbeat等工具。

数据收罗组件支持Fluentd、Logstash、filebeat等。

需要注意的是，平台日志和应用日志是两个层次，可以用集中日志中心来集中管理平台和应用的日志，因此，集中日志中心的权限体系需要支持租户权限体系，平台管理员就是一个特别租户，需要实现和打通各组件之间的统一认证和权限能力。
日志中心的设计和BoCloud博云也讨论过很多次，需要支持通用的ELK方案，但又不能和平台紧耦合，任何一个组件的设计都需要实现插拔的能力。

• 监控告警中心
  

监控告警中心是容器云平台监控平台各组件运行状况、监控告警规则界说、收集并展示平台运行环境的组件。监控告警中心是运维的重要助手，没有它就犹如两眼一抹黑，难以有效保障容器云平台的正常运行，无法猜测系统运行资源利用，就无法保障其可用性。
监控告警中心接纳Prometheus + AlterManager工具，利用Grafana实现监控面板，展示监控内容项，另外自界说实现一些监控面板，以更好的集成到平台不同的组件中展现相干监控内容。

博云原来的产物利用的是Zabbix，在新的版本中计划接纳Prometheus和Grafana，更好的实现监控需求。

• API网关
  

API网关是实现业务应用安全和服务治理的重要组件。可独立于容器云平台，但由于其独立性，我们把它作为一个独立服务组件来建设。API网关也是实现OpenAPI管理和提供稳定的接口能力的组件，通常包罗API网关、API 管理工具，API集市等组件。

• 服务注册中心
  

服务注册发现中心是提供服务注册和查阅的地方。一个服务要给其他客户利用，就需要根据注册机制注册到注册中心，提供一个公开的地址，方便客户查阅。客户假如想利用某些服务，通过注册中心进行查阅，找到合适的服务及其地址，就可以在自己的服务中调用。
服务注册发现中心和容器云平台自身的注册发现组件不是一个内容，通常作为容器云平台的外部组件来支持整个服务或微服务体系。和API网关等组件紧密团结实现服务治理。

• 服务配置中心
  

服务配置中心是容器云平台支持微服务必不可少的组件，也是为了更好的利用容器的特性，支持运行时服务配置更新，解耦合服务配置和服务实现框架。服务配置中心是独立的组件，也可应用于其他平台和系统。在容器云平台，可以扩展支持不同层级的配置，比如应用层、服务层、实例层，根据实际需要来界说和管理业务应用和服务的配置。Config Client 和Config Server之间接纳JMS或Kafka等消息组件作为通讯组件。
服务配置中心设计头脑我们也和BoCloud博云做了详细的讨论和交流，由BoCloud博云来完成代码实现。

• 统一认证中心
  

认证中心起首支持容器云平台各生态组件之间的统一认证和授权，和权限中心组件集成实现各组件的访问控制。认证中心提供单点登录能力。

• 平台管理
  

平台管理是容器云平台管理员视角或平台管理员角色所能操纵的功能。重点是根本设施资源管理和租户账户管理。理论上这一块更象是IaaS层的能力，不过现在Kubernetes等实现有些不同，无法做资源捏造化，不过可以利用IaaS层的捏造化能力，但仍然需要做一些额外的工作，比如标签标记不同的资源类型。和IaaS层提供不同的捏造机服务类似雷同。

• 根本设施资源中心
  

根本设施资源包罗计算资源、存储资源、网络资源以及操作系统资源等，为整个容器云平台提供资源服务。通过标签来标记不同的资源，以满足不同的服务对资源的个性需求。根本设施资源不拘泥于物理机或者捏造机的选择，按需进行资源分配和管理。资源分配以节点为基本单元，分区为节点的集合。但对于每个节点可以设置资源限额，设置资源预留额等，以实现更细粒度的资源控制。
有个题目是资源分配面临着分配实际的资源还是理论上的资源的题目，可能需要基于基于根本设置资源层所能提供的能力来决定。现在Kubernetes可能还无法实现资源超分的能力。容器云平台在实现时需要考虑充分的利用和共享资源。但在容器云建设初期资源总量较小的环境下，可能实现资源超分也意义不大。

• 租户账户管理
  

租户账户统一由平台管理，每个租户申请或注册一个租户账户，由平台管理员查抄评估并确认（开通或不开通），分配所需根本设施资源。同时维护租户账户的基本信息、登录暗码、认证方式等。

• 平台权限中心
  

平台权限主要考虑多平台管理员的环境下，对不同平台管理员进行授权，权限中心模块可以和租户权限中心利用同一个组件，平台管理是一个特别的租户（平台管理员看到的权限和租户看到的权限列表是不一样的）。

• 公共镜像堆栈
  

平台管理还有一项重要的工作就是维护公共的中间件镜像，比如Kafka、Redis、JDK、Tomcat、MySQL等，这样全部租户都可以利用这些中间件镜像快速摆设为自己的服务，用于快速的环境搭建、测试，甚至是生产摆设。
企业级中间件的摆设建议统一来考虑，容器云平台提供的中间件更多的得当敏捷的开发测试。

• 平台日志中心
  

平台日志集成到日志中心，只管理查看平台的日志。

• 监控告警中心
  

平台监控告警中心偏重于平台各组件的运行环境监控，不监控业务服务的运行环境，集成监控中心组件。

• 平台设置
  

容器云平台设置包罗Docker、Docker deamon、Kubernetes等配置选项，以及平台集成LDAP、可选组件、界面logo、背景等设置和配置。

• 多租户管理
  

多租户机制和能力是容器云平台的核心，由于最终容器云平台是为了支持业务应用的。平台管理为租户提供根本设施资源，租户利用云资源管理和运营自己的业务应用。租户通过CI持续集成流程构建业务服务镜像，上传到镜像堆栈。镜像堆栈中的镜像颠末安全扫描安全的镜像可以摆设到容器云平台，每个租户都有自己独立的私有镜像库，用于存储租户自己创建的镜像。服务可以摆设为1到多个服务实例，服务摆设后注册到注册中心，通过配置中心来实现服务配置更新，可以实现实例级配置更新。由服务网关层实现服务非业务逻辑功能，比如认证、路由、转换等。

• 应用管理
  

应用管理是租户的核心。能够提供便利、完满的应用和服务管理能力，是能否赢得租户的关键，我们要认识到容器云平台只是个工具，工具的好坏一定有评判标准。用起来顺手，是最基本的要求。
应用管理中镜像摆设为“业务服务”，注册到服务注册中心；每个服务可以摆设一到多个“服务实例”，或者根据业务需要实现自动弹性伸缩，一个或多个服务通过服务编排为“业务应用”。请求通过负载平衡器分发到不同的服务实例上，并行处理，每个服务一个注册地址，不论有摆设有多少服务实例，都通过负载平衡器来实现负载平衡。基于弹性伸缩的需求，负载平衡需要支持多种计谋，以支持不同场景下弹性伸缩要求。

• 服务注册发现中心
  

租户摆设的服务都起首注册到容器云平台服务注册中心，租户内部的调用无需颠末外部的注册中心。租户若需要调用其他租户的服务，则需要从服务注册发现中心查找合适的服务。
这里需要注意的是，为了充分利用容器的特性，我们把服务的注册机制分为两个层次，一个是容器层的服务注册发现机制，一个是容器云平台外的服务注册发现机制。需要明确认识到这两个服务注册发现层次的不同。

• 服务配置中心
  

镜像在摆设过程中，转到服务配置页面进行参数配置，完成配置之后实现摆设并启动。配置共分三层：应用层配置、服务层配置和实例层配置。通常环境下是服务层配置，不需要控制每一个服务实例。但某些环境下也可能需要对每一个服务实例进行配置，或者接纳单实例服务摆设方式。容器云平台需要和服务配置中心组件集成，实现服务在容器云平台的配置和更新。

• 服务网关
  

服务网关是服务实现服务治理的重要组件，全部租户间的服务通过API网关提供统一的API服务（租户内部服务成为私有服务，租户间服务成为公有服务，公有服务通过API 网关界说开放API，供其他租户利用），隔离服务实现和API接口界说，服务网关提供了稳定的API接口层，服务的更新和替换不会影响API提供的服务。非兼容性的更新摆设为新的API服务。服务网关分离业务服务的全部非业务功能，业务开发职员专注于业务逻辑的设计研发，不再考虑认证授权、访问控制等安全机制以及限流、限额、熔断、优先级配置等能力。

• 权限中心
  

权限中心支持租户组织架构、职员、角色、权限的设置需求，以满足不同租户的不同场景要求。权限来自于平台功能项的操作粒度（平台操作员和租户看到的功能项是不同的），不同的权限集合组成界说为一个角色。组织架构和职员可以被赋予某种角色。组织架构下的全部职员继承组织架构的角色权限，一个职员可以被赋予多种角色。租户可以界说基于角色的权限管理体系，支持不同的组织架构和层级。
权限中心可以集成LDAP，证书中心、认证中心等功能实现企业级各系统的统一认证、权限管理服务。

• 链路跟踪
  

以图形化展示服务之间的调用关系，更清晰的定位异常节点，跟踪信息。链路跟踪可以有效避免服务之间的循环调用，尽可能的减少调用链路长度。更短的调用链路也是性能、安全等方面的要求。

• 负载平衡
  

负载平衡分容器层负载平衡和网关层负载平衡。在我们的整个平台生态系统中不建议接纳客户端负载平衡机制。服务实例之间接纳容器层负载平衡，通常可以考虑容器平台的负载平衡机制，但需要考虑弹性伸缩时的伸缩计谋，不能接纳随机计谋来收缩容器，必须确保容器已经完成的业务请求的处理才可以被回收。

• 根本设施资源中心
  

租户的根本设施资源是由平台来分配的。通常环境下租户不需要再对自己的资源进行分配，我们暂不考虑租户的资源管理或再分配需求，只考虑租户利用分配的资源需求。资源中心可以查看已分配资源及在利用资源，空闲资源等信息，也可以再申请资源。

• 镜像堆栈
  

租户自己构建的镜像保存于租户自己的私有镜像堆栈中，同时租户也可以利用公共镜像堆栈中的镜像。两个镜像堆栈是分开的。租户的私有镜像堆栈可能有多个，租户可以通过镜像堆栈配置连接到不同的镜像库。

• 租户日志中心
  

租户日志中心主要收罗租户摆设应用的日志信息。容器中应用服务日志输出到标准输出，通过Logstash的组件来从标准输出中收罗日志，每个服务的每条日志有固定的格式和标签来区分。集成集中日志中心实现租户日志管理。

• 监控告警中心
  

监控告警中心和链路跟踪机制、日志中心等共同实现业务服务、实例运行环境的监控及异常告警，协助定位分析。集成监控告警中心组件。

• 使命调治中心
  

使命调治中心主要支持批量使命、定时使命的处理。

• 标准化交付和管理
  

标准化交付就是从源码到标准化镜像构建的流程，包罗源码开发、单元测试、源码管理、源码查抄、编译、构建、上传镜像堆栈、镜像查抄、测试环境摆设测试、测试用例管理、缺陷管理、文档管理等。主要实验持续集成CI流程。标准化交付作为容器云平台的一个独立组件可独立摆设，和容器云平台之间通过镜像堆栈实现标准镜像传递。

• 持续集成工具及流程
  

持续集成起于源码研发，止于镜像堆栈。持续集成涉及代码编辑工具、源码管理工具、源码查抄、编译、打包、生成镜像，以及缺陷管理、文档管理、API接口管理等众多的工具。

• 镜像堆栈
  

镜像堆栈是容器云平台的关键组件之一，是持续集成和应用摆设运营的媒介，包罗Server端和Client端。现在有众多的开源实现。安全性有待增强。


六、交互UI界面设计
详细可参阅《容器云平台UI 界面原型设计》


七、组件摆设架构设计
容器云平台不是全部组件都得当容器化摆设，也没必要都容器化，有些时间容器化反而复杂化了，以是需要根据详细的环境来确定各组件的摆设方式和摆设架构。


八、关键技术难点、选型

• 统一认证、权限管理
  

容器云平台生态体系涉及众多的组件，大部分都是开源的组件，大部分组件没有默认没有实现认证授权机制。在容器云平台，全部选择的组件都需要考虑接纳统一的认证和权限体系，也就是各生态组件要接纳同样的权限体系和认证方式。在不改变组件架构等根本上实现各组件之间权限打通，实现统一的权限管理和认证，是一个重大的难点。

• 弹性伸缩计谋支持
  

容器平台价值很大程度上在于其伸缩能力，或叫弹性。伸缩不能随便伸缩，必须有一定的规则，按照界说的规则进行伸缩。这就需要界说弹性伸缩的计谋。通常环境下不能接纳随机计谋，支持弹性伸缩计谋配置，不同的服务接纳不同的计谋可能是一个比较好的解决方案，但现在实现也是个难点。

• 安全机制
  

安全是永远绕不开的话题。在容器云平台需要考虑不同层次的安全机制和不同组件的安全机制。需要实现：

• 登录安全，需随机验证码或手机验证码
  
• 租户用户权限管理安全
  
• 代码安全，不仅指安全的代码存储，也包罗编码的安全，预防编码中潜伏的漏洞和Sql注入等。
  
• 根本镜像安全
  
• 服务安全访问，由协议层安全和API Gateway安全共同实现。API Gateway实现认证授权、限流、熔断、路由、服务映射配置、转换等功能。
  
• 统一认证单点登录
  
• 微服务摆设运营安全
  
• 中间件安全设置（Tomcat、Kafka）
  
• 系统、网络安全配置（网络计谋）、存储安全等资源安全
  
• 需要考虑root用户运行容器云组件的题目。
  

安全涉及业务应用和服务、容器平台、容器调治组件、根本设施资源各个层次的安全。这会是一个非常重要不得不做的工作，也是容器云平台建设的难点。

• 应用服务配置管理
  

配置中心的设计实现也可能是个难点，需要支持运行时更新以及多层次的配置。不仅仅是读取配置文件

• 应用管理
  

应用管理是核心也是难点，全部的组件都是围绕应用管理来服务的。在应用管理中需要集成各个组件的能力，而各组件又是松耦合的，又需要考虑多租户机制和权限管理，设计实现会是个难点。

• 监控、故障跟踪定位
  

监控和故障处理永远都是重要的一环，收罗到合适的新监控信息并界说合理的监控规则，在异常环境下能协助快速定位，也不是件容易的事。

• DevOps流程界说
  

不改变现有组织架构的环境下实现DevOps，为了一个项目去期望调解组织架构永远都是稚子的想法。不管场景多复杂，都会有最简单的解决方法。DevOps方法论的指导下实现DevOps流程界说和落地，需要的不仅仅是技术能力，这是一个很难的难点。

• 关键设备选型
  

从容器云平台架构和组件来看，平台关键组件会涉及到根本设施组件、容器调治框架、容器、镜像堆栈、API网关组件、中间件摆设、微服务框架、微服务架构界说等选型。

• 网络技术方案和存储技术方案选型
  

网络和存储方案是在建设容器云平台之前就需要调研确认，详细接纳什么方案，需要进行分析和对比，选择合适的方案。

• 节点（物理机、捏造机选择）方案选择
  

很多人一直在争论建设容器云应该选择物理机还是捏造机，我们也讨论过，不过从后来的实际环境来看，假如企业已经实现了捏造化，接纳捏造机配合标签应该会更方便些。最终需要根据机器配置及企业捏造化建设环境来确定。

• 容器调治管理框架
  

在2018年Kubernetes成为了发展最快的容器调治管理框架，Mesos和Docker Swarm好汉不再。不过基于Kubernetes上的Openshift似乎更胜一酬。基于Openshift的容器云研发相对更容易些。

• 容器
  

Docker已是事实上的标准。

• 镜像堆栈
  

镜像堆栈也有多种方案可供选择，DTR、Harbor、Registry等。重点在于镜像堆栈的镜像安全扫描能力。

• API网关
  

API网关有商用、开源产物，也可自研。不过从自身技术气力和成本投入来说，选择开源和商用比较合适。但从服务和安全角度来说，传统企业更得当成熟的商用产物。

• 中间件摆设方案
  

容器云平台组件摆设原则上变化不剧烈、没有频仍扩展需求的，选择非容器化摆设。对于运维和管理更容易些。也减小整个平台的复杂度。

• 微服务框架和架构
  

微服务框架虽然不是重点，但假如有统一的开发框架，将有利于统一的管控和高效。SpringCould现在应该是比较合适的选择。微服务架构界说存在一定的难度，需要基于实际的业务确定。


九、微服务技术架构、服务治理模型
微服务开发框架选用SpringCloud，一方面由于SpringCloud相对成熟，比如别的框架好不少。另外团队成员也相对比较熟悉。
微服务技术架构我们自行界说了微服务设计原则、路线图、实施模型、微服务成熟度模型等来帮助分拆、重构服务和业务应用。服务间通讯和事务处理也界说了一些原则和规范，借助了系统集成和数据集成技术的一些理念。数据层的设计和界说主要考虑主数据模型和行业通用数据模型。
基于微服务技术架构和容器云平台所提供的特性，界说微服务治理模型：微服务治理模型根据微服务的架构分为数据层、服务层和应用层。数据层支持不同的数据存储方式和数据集成方式，通过服务层来统一直外提供标准的接口微服务；根据业务需求来利用微服务实现业务应用服务；应用接纳Client /Server前后端的方式实现，全部应用的请求通过API Gateway集群分发到相应的业务应用服务上。API网关层同时提供API管理能力、API访问控制能力、负载平衡能力、路由、容错、过滤、映射转换、限流、熔断等，以及团结容器云的多租户管理能力，实现服务的分类管理和权限管理等。为了支持微服务架构，实现服务注册发现机制、提供服务配置能力、服务日志记录能力、服务运行监控和告警能力以及服务访问统一认证、单点登录能力等；在服务的开发、运营等整个生命周期过程中遇到的题目、需求等持续反馈到DevOps中心，并持续的改进这些应用服务，以更好的满足实际业务需求。


十、DevOps方案设计
DevOps目的是为了促进应用开发、应用运维和质量保障（QA）部分之间的沟通、协作与整合。很多人把DevOps成为开发运维一体化，也不能说错，但也不全对。我们认为假如要落地DevOps就必须要求调解组织架构，那无异于纸上谈兵。开发运维一体化不一定是要一个人把业务应用全生命周期都做了，DevOps是一种方法论，根据详细的业务流程，通过选择相应的工具，界说相应的职责，优化业务流程，从而实现敏捷协作和高效整合，这些工具、职责和流程就是“沟通”，目的是为了敏捷协作和高效整合。因此我们界说DevOps中持续集成的终点是镜像堆栈，输出是标准化镜像，持续摆设的起点是镜像堆栈，镜像堆栈是一个标准化的媒介工具。

十一、总结阐明
本文所述与BoCloud博云为我公司容器云项目的实施方案并不完全一致，是本文作者基于该项目环境的研究和探究，不能视为容器云建设的正式实施文档，仅供大家参考。由于项目还在实施中，很多设计细节和实施方式不能详细讲述，我们将通过别的文章进行解说。


长按二维码关注公众号

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！