证券容器云平台项目建设全程要点和难点
【分享专家】汪照辉，某证券研发中心，专注容器云与微服务。
一、证券企业为什么要上容器云平台？
针对本问题，根据我相关的项目经验，我将从以下三个方面进行阐述：
1、企业业面临的问题和挑战--现状分析
互联网金融的出现和迅速发展，给予传统金融企业极大的压力，被迫考虑转型和调整。互联网金融，关键点在于互联网：互联网思维、互联网技术。先进的思想引领先进的技术，先进的技术支撑先进的架构，先进的架构提升先进的业务，先进的业务更好的服务客户、更多的赢得客户！
对于我们传统的金融企业，还存在传统的思维、落后的技术。一项新业务从提出需求到立项、招标、实施、上线，一年半载已经过去了。最最关键的是，开发出来的可能已经不是最初的样子了，似是而非，一线员工不满意，IT人员觉得委屈，客户失望流失。这种传统的IT研发方式已经无法适应新业务发展的要求。
我们提出建设容器云平台也是基于现实的挑战：
受厂商影响，开发测试部署交付等环节各不相同，各Team有各异的环境、工具、方法、规范，团队之间难以实现共享和高效合作。
传统单体应用各系统独立，互连互通、共享难，虽有ESB可以实现集成，但对一些需求无法满足性能、扩展、低延迟、快速上线等要求。
自动化测试、自动化运维程度低；一个系统通常从立项到运维都是由一个人来负责，形成了大大小小上百个系统，占用大量的人力资源。在系统出现异常时定位问题慢，经常受到多个系统的影响，处理起来很慢。
一台PC一套环境，资源利用率低，而且PC有限；虚拟化后虚拟机OS消耗大量的计算、存储资源；虚拟机OS实际运维管理成本等同于物理服务器，虚拟机数量增加导致管理成本增加。
不易复制，搭建环境麻烦。生产与测试环境不一致，脏环境的问题，无法保证每次运行的环境完全一致。在测试环境可以，在生产环境可能怎么都不行。
扩容慢，遇到突发流量，疲于奔命；迁移慢且比较繁琐。
系统重载，应用伸缩周期长，对VM做伸缩，系统负载大，APP的VM环境无法快速复制，无法满足应用的大规模快速弹性部署需求。
不支持快速迭代，业务上线效率低，不支持在线应用环境申请和配置及切换、频繁发布、频繁升级背后的人力投入巨大，缺少在线验证机制、难以快速定位修复线上问题。出现问题后的解决问题的手段非常有限，且低效；
2、上容器云项目的原因
为了解决面临的问题和挑战，重要的是在快速变化的时代生存下去，要变革，要与时俱进。
首先要改变思想，重视IT技术投入，认识到科学技术是第一生产力。已经不能靠人海战术来赢得未来。IT系统和平台是业务的基础，可以极大的协助人来提高业务处理能力。互联网、移动业务、物联网的发展，必须靠强大的基础设施来支撑，需要强大的互连互通能力、强大的运算分析能力、针对性的服务能力、瞬时的响应能力、舒适的客户体验能力等等，这些都需要IT系统和平台的支撑。
业务建立在平台之上！没有好的平台就难以推出好的业务。传统单体应用彼此独立，所采用的技术、开发语言、开发框架各不相同；数据分离，各自有自己的一套数据库；数据冗余导致浪费，最重要的是数据不一致造成很多问题。数据是一个企业的核心资产，所以企业的重要数据不能轻易放到公有云，需要建设自己的私有云平台、建设企业内的基础设施平台来支撑企业业务的运行和发展。从而实现基础设施平台为数据和业务服务；数据层建立通用数据模型，实现全局唯一数据源，解决数据不通、不一致、冗余等问题；业务层实现服务共享，在基础服务的基础上快速构建业务应用，快速部署发布投入运营。
SOA技术的发展，微服务被大家接受并受到推崇。其解决了单体应用系统大而重的问题，也很好的避免了ESB集成存在的瓶颈。其采用组件服务化、分布式的部署方式，非常贴合容器技术的特点，小而轻量，以小拼大。
具体的，为了配合正在进行中的客户中心、账户中心、产品中心等的建设，适应公司互联网业务发展，满足业务应用快速开发及迭代的需求，采用微服务架构，逐步建立标准化的开发、测试、运维环境，形成适用于公司的DevOps（开发和运维一体化）过程，完善开发、测试、部署、运维监控工具链，提升自主开发技术和管理水平。
3、项目潜在收益
容器云平台作为基础设施平台，可以实现资源共享，实现了共享，就能适应快速的业务变化，企业能生存、能发展、员工能有高收入，为社会公众带来便利和利益：
技术上，初步搭建容器云平台，建立统一的服务托管、部署、运维平台，逐步建立并完善统一的权限管理体系、授权认证体系、服务配置治理体系、日志收集分析体系、监控告警预警体系等，实现公司内统一的应用服务部署运维监控生态系统。
管理上，通过引入DevOps理念，根据公司实际逐步建立开发、测试、运维等适合自身发展需要的流程，定义相关数据、业务、技术等标准、规范，实现开发、测试、生产环境的一致性，提升敏捷开发的能力，提升自动化运维的水平。
业务上，提供快速业务原型的开发以支持业务变化需求，让业务人员更早的介入，熟悉使用并有效持续反馈，形成业务和开发的良性循环。总的来说，容器轻量化PaaS平台可以利用容器技术的特点，其技术特点非常适合互联网化应用的快速迭代开发、弹性伸缩部署、基于标签体系的灰度发布机制等需求。我们同时考虑采用目前分布式的微服务架构，结合容器云平台，实现提高开发端的响应能力，自主开发；统一技术路线，逐步实现技术积累和共享；实现持续集成，开发测试与生产环境一致；持续部署能力，提高发布速度；实现弹性伸缩能力，快速的实现扩容和缩容；解放运维、实行自动化运维等以满足公司互联网应用业务发展的需要以及传统应用改造和集成的需求。
二、证券企业上容器云平台的多吗？现在是什么形势？
从金融行业容器云的部署来看，有不少企业已经上了容器云并且应用规模很大，达到几千容器规模，部署几十套生产系统。也有不少企业在测试或规划上容器云平台，这是云计算私有化发展的一个趋势。
云计算作为基础设施，在IaaS大部分都已建成的情况下，构建PaaS平台是发展的需求。容器化PaaS是一种轻量快捷的实现方式。可以满足企业应用开发、应用部署和应用托管的大部分需求。同时考虑到目前比较火热的中台建设思路，基于平台化战略构建企业中台，依托容器化PaaS平台将会节省不少的资金投入和时间成本，因此，容器化PaaS平台建设在金融行业可能会越来越多，当然要求也会越来越高，对产品化的要求也会越来越明确。
不同公司对容器云的建设侧重点可能会不一样，有的可能以持续集成CI为切入点，有的可能先把容器用起来，通过CLI命令来管理容器。但我们觉得要用好容器必须关注容器的管理和调度，要支撑应用必须提供应用的管理和监控，因此容器云平台建设重点应该在于应用管理和基础设施资源管理方面，而CI/CD是糅合于这些能力只能的一部分。
三、如何评估证券容器云平台项目的回报？
项目回报比较难确定，难以量化，是一个长期的过程。从证券行业项目实施回报来看，大体上可以考虑有这几个方面的回报：
1） 环境准备节省的时间成本。采用容器云平台可以只关注证券业务应用逻辑研发，不用自己准备搭建环境，这通常可以节省很多人天成本，对比以往环境准备时间，比如以往购买安装准备环境需要3-7天，采用容器云可能只需要几分钟申请资源就可以了。
2） 应用运维节省的人力成本。容器云平台应用运维是证券研发团队不需要关注基础设施资源的运维，基础设施资源通过统一的资源管控来实现高效运维，节省大量应用系统的运维力量。
3） 应用弹性扩展的回报，比如证券公司也经常会搞一些活动，理财促销等。这也和资源相关，应用的扩展可以实现实时的弹性伸缩。提高应用的可用性和响应能力。
4） 共享资源的回报。证券公司基本上有大大小小上百套系统和应用，其执行高峰时段可能是错开的，所以不同的应用可以在不同的时段分别占用资源，实现资源共享，从而节省资源的投入和避免资源浪费。
5） 应用敏捷研发的支持。传统证券行业开发运维分离，各管一摊。通过容器平台支撑DevOps流程，实现持续集成，支撑应用敏捷研发和运维的流程，促进开发运维一体化建设。
总的来说，容器云平台提供统一的基础设施资源服务，使应用研发人员关注业务逻辑，节省了资源准备、安装、运维的大量时间和资金成本，更实现了资源的统一管控和共享。
四、如何评估证券容器云平台项目的整体成本？
容器云项目成本有直接成本和间接成本，直接成本主要是购买容器云产品及实施成本和硬件服务器的成本。间接成本包含员工工资、运维运营成本、外包服务成本等。
评估成本通常可以通过询价的方式和多家厂商沟通，了解软硬件的大致投入。用于项目预算。同时要考虑人员的工资、外包服务费、实施费、服务运维费等其他费用。
通常容器云产品软件一套约XX万元，另外按节点数量产生授权使用费用，每节点约XX万元，根据节点数的量提供一定的折扣比例。容器云产品部署、配置、测试、调试等实施费用约XX万元。服务器硬件根据应用部署需求确定，目前需要XX台PC服务器，XXG内存和XX颗Xeon 6150 CPU，以及硬盘、网卡等（例如下表）。容器云厂商后期服务费首年免费，后期约按项目总额的10%-20%收取。经过总的测算，大概可以知道实施容器云项目总预算包含软硬件、实施和1年维保服务大概在XX万。不同的厂商价格会有差别。
项目预算XX万元，用于购置服务器硬件、容器云软件产品授权及实施服务，详见下表：
五、在证券容器云平台项目中，针对证券业的业务特征，容器产品的选型原则有哪些？
产品选型也是考虑自身的实际需求和限制条件。比如资金投入不大，可选的产品可能就会受到限制。或者需求不一样，选择的产品侧重点也不一样。适合的就是最好的。
证券公司通常体量还不是很大，所以在节点量等方面可能不会很庞大。产品适合轻量而精致。
容器云产品选型首先需要考虑技术选型。不过目前几乎都是基于Kubernetes的实现，Openshift、pks等以及初创厂商的产品几乎都是k8s。
然后考虑产品的docker和Kubernetes的版本，以及产品更新的能力和时间间隔。新的版本通常特性更多，如果没有特殊要求，可以关注产品功能。如果对某一特性有需求，则考虑支持此特性的最新版本产品。
第三考虑产品功能是否满足需求和建设目标，以及产品的可靠性、可扩展性、容灾备份、文档等生产就绪能力。
第四则看产品价格、实施成本、环境、技术要求等。
六、在证券容器云平台项目中，如何进行devops技术路线的选型？
针对你的问题，分享一些我司做相关项目的经验。
1.DevOps技术路线
DevOps技术实现路线也有多种方式，最简单的是选择Jenkins。同时可以选择源码管理工具SVN或Git等，打包构建工具Maven或Gradle等，单元测试工具Junit等。和容器平台集成，实现持续集成和持续部署能力。项目初期可以使用Jenkins等开源组件构建自己的DevOps能力，等达到合适规模再重构DevOps. 通常有不少团队都开始使用容器环境并且需要持续的更新测试，就非常适合构建DevOps流程。
也有不少公司在容器平台上实现了流水线，不过在我们看来更多是PoC概念验证的功能，不具备生产就绪能力。我们不建议流水线构建在容器平台，首先容器平台适合轻量多变的场景需求，DevOps流水线通常一次配置，持续使用，其稳定性要求还是有的，不用频繁的构建流水线。另外生产环境也不适合持续的集成和部署，所以我们提出了标准化交付流程：以镜像仓库为媒介，开发交付标准化镜像，以镜像仓库为终点；部署以镜像仓库为起点，实现自动化部署和自动化运营监控，自动的告警反馈。
也有像阿里的云效，做了东西很多，把项目管理的内容也都放在DevOps中。从我们个人观点，不建议把DevOps搞的过于复杂，流程过于繁琐。DevOps的目的是为了敏捷和高效，因此我们认为要尽可能的简化和便捷。可以把Jira、Swagger等集成进去，实现整个流程的闭环。不过DevOps并不是完全自动化，借助一些自动化的步骤来提升开发测试运维效率，比如我们采用容器平台可以快速构建应用测试所需环境，这样就大大减少了应用测试环境准备的时间，可以做到分钟级环境就绪。
2.DevOps思想和方法论
我们认为DevOps重点不在于选择什么样的工具，而是团队间的协调和配合意识和能力，流程工具只是个辅助。因此DevOps思想的传播和介绍可能首先要做起来，让各个团队有DevOps意识。然后根据企业实际选择DevOps工具链和实现DevOps流程。
3.DevOps标准化
DevOps标准化难度非常大，但也不是不可以做。很多公司在考虑开发运维工具的统一化，这样可以减少很多的学习时间和资金成本。目前DevOps标准化更多需要从我们提出的标准化交付思路出发，以镜像仓库（或标准化交付库，比如交付jar文件或war文件等）为媒介，标准化CI和CD。
七、在证券容器云平台项目中，如何进行微服务技术路线的选型？
我将从下面两个方面进行阐述，给大家做个参考：
1.微服务框架
目前比较流行的微服务框架是SpringCloud和Dubbo。SpringCloud是Pivotal公司基于SpringBoot框架的基础上推出的微服务开发开源框架，它提供相对完善的服务配置、注册发现、服务网关、服务消息总线、熔断、日志收集等能力。Dubbo是阿里公司的开源产品，相对简单，国内用的较多，但中断了一段时间维护，缺乏Pivotal公司系统的支持能力。阿里的产品总的来说是阿里自身需求的结果，所以往往缺乏标准化规范化的考虑，只是为了追求某方面的性能。综合来看，选择SpringCloud来开发微服务是比较好的选择。
2.微服务设计方法
直到目前位置，大家对微服务概念的理解和微服务实现方式都有不同的看法，微服务设计通常采用thoughtworks提倡的DDD，Domian-Driven Design方式；不过从我们个人观点来说，DDD概念和设计有点繁杂，如果没有充足的DDD设计经验很难掌握其设计技巧，很可能设计出来的微服务不伦不类。因此我们提出了采用主数据思想的设计方法，以主数据建设的思想设计数据模型，抓主要的数据实体，抽取共性的实体模型作为微服务设计的原型。
附上之前我写的一些微服务方面的文章，可以阅读参考
微服务规划：
http://www.talkwithtrend.com/Article/242783
微服务构建：
http://www.talkwithtrend.com/Article/242631
微服务协同：
http://www.talkwithtrend.com/Article/242793
微服务发布运营：
http://www.talkwithtrend.com/Article/243003
微服务测试及生产就绪：
http://www.talkwithtrend.com/Article/243275
微服务生命周期：
http://www.talkwithtrend.com/Article/242721
微服务设计二三事：
http://www.talkwithtrend.com/Article/243401
微服务设计案例分析：
http://www.talkwithtrend.com/Article/243423
微服务设计评估：
http://www.talkwithtrend.com/Article/243497
八、在证券容器云平台项目中容器引擎和编排调度框架如何进行选型？
抛开其他因素，单从技术角度上说，在规划容器云项目的时候面对多种技术路线选择，即便同样的技术也可能有多种实现方式。首先可能是容器引擎技术以及容器编排调度技术、微服务框架、DevOps实现方法等。这里主要谈下容器引擎和容器编排调度框架的选择，同时要明白项目往往会受到资金、利益相关方等的影响。
1. 容器引擎
容器引擎技术主要有Docker公司的docker引擎和CentOs的rkt引擎，rkt理论上在安全性和兼容性方面更好，但缺乏生产实践，目前用户大部分使用Docker。Docker社区也更活跃，这可能跟Docker发布比较早和参与的人更多有关。目前大部分容器厂商都首选Docker支持，rkt的成熟度仍显不足，因此容器引擎我们选择Docker引擎。
2. 容器编排调度框架
容器编排调度框架主要有Mesos、Docker Swarm、Kubernetes、Openshift、Pivotal Kubernetes(PKS)等。
Docker Swarm简单易用。原生支持Docker，安装Docker后开启Swarm模式即可使用。比较适合小型的集群管理。
Kubernetes除支持主流Docker容器（需单独安装Docker组件）以外也支持CoreOS rkt等容器技术，目前社区最活跃，受厂商支持也最多，基本上所有的容器云厂商都已转向支持Kubernetes。
Mesos上无需安装docker程序也可以运行docker容器，mesos可以自己解析docker镜像来启动容器。Mesos应该来说更成熟，Kubernetes已经测试了数千个节点，而Mesos已经测试了成千上万的节点。Mesos社区不再活跃，对超大集群的支持Mesos更合适。
Openshift是Redhat基于Docker和Kubernetes之上做了封装的开源容器应用平台。RedHat增加了很多新的特性以支持应用的快速开发、部署、扩展等生命周期管理能力。Openshift的实施一般是由RedHat合作伙伴执行。合作伙伴的能力决定着项目的质量。
Pivotal在其PCF的基础上对Kubernetes进行了支持。微服务框架SpringCloud及SpringBootdd等框架也是来自于Pivotal，另外也支持Serverless 函数及服务等，相对来说采用微服务比较便利。
考虑到技术的快速变化，为了后期升级维护的需要，适合选择社区活跃、支持度高的容器编排调度框架，综合考虑，Kubernetes或者Openshift是目前比较好的选择。
九、如何解决证券容器云平台项目管理中的项目认知问题？
我们一直认为项目管理中最大的不可控风险就是项目人员。因此在项目开始之前必须统一认识，让所有参加项目的人员都能认识到项目的价值和意义，明白自己的价值和意义。以及项目成功的收获和如果由于自己的原因导致项目意外或延迟所造成的损失所应付出的代价。让每个人在项目过程中都有敬畏感，而在项目成功之后又有成就感。使整个团队能劲往一处使，心往一处用，形成合力。
如何解决：
（1） 让项目中的每个都要明确了解并理解项目目标，明确自己的职责，并且清晰的知道自己在项目成功后的收益，除了工资奖金，还有技能提升。以及如果由于自己的原因导致项目意外所应承担的责任和付出的代价。
（2） 人员任用。项目人员选用往往决定着项目成败。这是重点也是难点。因为往往无人可用。巧妇难为无米之炊。这是很多项目的共同点，所以项目交付会是个问题。在起一个项目时一看产品，二看交付能力，第三还要考虑备份。项目负责人需要考虑人员风险问题，一考察项目负责人的调度能力，二看项目负责人的项目掌控和预测分析能力，三看项目负责人的备份资源掌控力。这也是很关键的一点。项目给你并不代表你就可以高枕无忧，合作双赢，不合作你会输。
（3） 以身作则，令出必行。项目管理人员必须严格要求自己完全遵守项目规定，不能特殊化，否则难以服众。一个团队就像一支军队，必须令行禁止，这样才有战斗力。
（4） 保有激情，劳逸结合。很多时候一些创造性思维是在睡梦中闪现的。因此不提倡加班，除非特殊情况，但不能长期加班，透支所带来的损失可能远远大于收益。程序员做的是创造性工作，在有激情的情况下其创造力、创意和效率是被迫情况下的很多倍。让项目成员有时间思考，并懂得思考。避免出工不出力。
十、如何解决证券容器云平台项目管理中的风险管控问题？
项目管理认知问题其实涉及风险管控的一方面，项目实施人力风险。我们在容器云生产就绪一文中提到过容灾和备份，这就是生产部署风险管控的部分。风险无处不在，所以我们说安全意识时刻需要有。
从容器云项目实施过程中的风险分析来说，包括技术风险，人力风险，资金投入风险、时间风险等。风险管控也就是通常在资源有限的情况下如何保证项目的顺利执行。首先明确风险因素以及风险参与者，确定主风险因素。比如技术风险因素是对技术的掌控能力，其参与者是相关的项目管理设计实施人员，对于新技术掌控能力可能就比较弱，新技术大家可能都不是很熟悉很精通，理解和认知各不一样，就存在一定失败的风险。所以项目首先需要确定选择合适的技术体系。然后选配合适的人员，需要有高技能的专家指导和参与。如果缺乏这样的人员，就存在人力的风险。而人力投入又和资金投入相关，时间要求和技术选择及人力投入都相关。因此在考虑不同的风险因素和风险参与者，需要明确主风险因素是什么，然后确定风险管控的重点。比如是技术问题，还是资金问题，还是时间问题等。
其次需要确定相应的风险管控措施和备份措施。比如对于新技术可能都不熟悉，很大程度上需要依靠厂商的技术力量，在时间要求又比较紧，资金有限的情况下，可能没有更多的选择，那就只能看项目管理人员的个人能力了。可以通过竞争让厂商保持压力，如何能让多方多赢考验着项目管理人员的能力。一个项目不管投入多少，合适的方法是让两家厂商参与，保持竞争，做不好就被替换掉，也算是一种研发容灾和备份。
最重要的是协调和使多方多赢。让参与的厂商有压力有动力有收益。不只是项目费用，还有比如产品化，人员能力和意识的提升等等。拉长一个项目周期，从发展的观点来寻找合作共同点。
十一、如何进行证券容器云平台项目的系统方案设计？有哪些具体的设计内容？
所有的设计方案通常都要基于实际的需求和限制条件来确定。这样才能设计出适合自身实际情况的解决方案。也就是要对自身的实际情况和预期目标非常清楚。因此首先要明确容器云平台的功能需求和定位，确定设计原则，明确设计目标，然后完成设计及设计文档。
容器云平台设计内容通常会包括平台架构设计、平台功能组件设计、部署架构设计、容器网络方案设计、容器存储方案设计等。不同的需求侧重点可能不一样，所需的功能组件也会不一样。
例如，我们在方案设计中有以下内容，可以参考：
一、容器云平台需求概述
平台需求可以分为功能性需求和非功能性需求两部分。
平台功能需求概述
根据容器云平台项目需求说明书，功能性需求总共分为三个部分，容器云平台管理和资源管理、多租户管理和应用管理，标准化交付和管理。各部分的关系梳理如下：
平台管理要求具备平台资源管理和资源隔离、租户账户管理、公共镜像库（中间件商店）、分层安全机制、高可用、易于扩展/更新/迁移能力。预留将来可扩展支持多云管理等能力。重点在于资源管理，具备向租户按需提供基础设施资源的能力。平台管理同时创建租户账号，维护公共镜像仓库和仓库中镜像。
多租户特性需求要求具备租户管理、租户资源管理、租户应用管理、微服务及服务治理、私有镜像库、租户安全等能力。重点是租户应用管理及服务治理能力，以及安全能力。同时提供维护租户下用户、权限、角色、组织架构、分配的资源，租户私有镜像仓库的能力。租户账号由容器员平台管理员创建，租户使用租户账号登录容器云平台租户管理界面，维护租户下的组织架构、用户、角色、权限、资源、应用、服务等。
标准化交付的对象是镜像，向公共镜像仓库或私有镜像仓库构建镜像。公共镜像是指对所有租户可用的镜像，通常由平台管理员来维护。私有镜像是租户自己的镜像，仅对租户自身可见。同时支持镜像上传下载同步等能力。重点是构建持续集成工具链（使用Jenkins），持续集成止于镜像仓库，以镜像仓库为媒介实现持续部署、持续反馈、持续改进闭环DevOps流程。
根据每部分的详细需求，我们定义平台管理员视图和租户视图，以及持续集成流程实现标准化交付能力，详细功能如下：
平台初始化之后只有平台管理员账户，租户账户平台管理员按需创建。安全需要覆盖全方位，确保每个层次都具备可靠的安全机制。
容器云平台面临着支持客户中心和服务中心的上线需求。必须建立基于SpringCloud框架的微服务支持。
非功能性需求概述
容器云平台非功能性需求最重要的是安全性、可扩展性和稳定性以及满足业务服务部署管理的性能需求、用户操作友好性需求。以满足容器云平台升级、迁移、更新、扩展需求。
可用性：可用性是平台可靠性、稳定性等的综合体现，可靠稳定的平台可用性才高。通常可用性是评判一个平台或系统的最重要维度，可用的平台才能考虑性能等其他维度。
可扩展性：可扩展性或者弹性是容器云平台或者云计算平台的价值所在。容器云平台需要提供弹性的基础设施资源，用于业务应用的弹性扩展。
界面友好：在每一个用户登录后都有个Dashboard来总括该用户的资源分配使用、应用部署运行、系统组件运行状况等；然后通过链接可以直接跳转查看详情。各环节相关联成为一个闭环。需要注意的是诸如“项目”等是开发测试阶段的概念，在运维过程中统一使用应用或服务。在采用微服务架构之后，统一是服务和应用建设，不再有“项目”概念，一切皆是服务。服务编排为应用。
性能：性能分两个方面，一是平台的性能需求，另一个是服务的性能需求。平台的性能往往决定着其上部署的单个服务实例的最大性能。平台的性能往往取决于平台基础设施资源的能力。也就是平台的硬件设施配置。另一方面，服务的扩展能力，负载均衡能力也是实现高性能的重要方式。
二、容器云平台方案设计原则
建设容器云平台的目的是用来承载业务应用的，为了实现IT融合、应急响应、敏捷开发、应用交付、权限认证、弹性伸缩、异常迁移、环境一致性、高可用、网络隔离、资源配额、日志收集、健康检查、监控告警等能力；中远期目标是通过采用微服务架构、DevOps方法论等逐步构建企业的服务中台。
容器云平台的方案设计需要遵循建设容器云的目的和需求，满足以下设计原则：
高可用原则：关键核心组件，都要求高可用设计、高可用部署，保障在服务器宕机等故障情况下，应用不受影响。
先进性原则：平台的建设所采用的技术是业界主流云计算技术，确保平台在一定时间内具备稳定的更新和保持先进性。
成熟性原则：技术选型确保先进性的技术上，采用成熟的技术，确保平台功能稳定。
开放性和兼容性原则：标准化或通用的技术手段兼容主流的设备和系统、软件、工具等。
可靠性原则：提供可靠的计算、存储、网络等资源，在平台、服务、应用、组件等方面实现高可用，避免单点故障，保证业务的连续性。
可扩展性原则：采用分布式架构，支持在不更改整体架构的前提下进行系统扩容和业务范围的扩展。平台的计算、存储、网络资源等根据业务应用工作负载的需要进行动态伸缩。
松耦合原则：容器云平台架构采用松耦合架构，平台各组件提供开放标准的API接口，方便客户已有系统的集成或平台组件的扩展和替换。
安全性原则：安全无处不在。支持覆盖全方位的安全机制。横向：弹性伸缩、负载均衡、异常迁移等；纵向：协议层加密、网关、访问控制、过滤、限流、熔断、禁用root用户运维权限、系统资源用户受限访问、资源隔离、网络策略等。容器云平台应该在各个层面进行完善的安全防护，确保信息的安全和私密性。
用户友好原则：注重用户体验，提供简洁便利的操作体验，避免二义性，界面操作保证流畅简单。
隔离性原则：容器云平台租户之间实现隔离，租户和平台管理之间实现隔离。
生态原则：容器云平台需要构建生态体系，提供和集成认证、权限、配置、日志、监控、告警、注册发现、网关等能力，支撑真正的企业业务应用。
三、容器云平台项目方案设计目标
容器云平台项目方案设计是为了基于容器云平台需求说明书来实现建设容器云平台的目标。容器云平台需求包括平台和资源管理、租户和应用管理和标准化交付和管理三部分，方案设计目标就是为了满足这些部分的需求，实现业务目标。同时对于平台重点组件和能力进行设计，指导项目实施和运营，解决技术难点和疑点问题。
容器云平台项目方案设计的目标定义如下，也就是需要设计的内容：
1． 定义容器云平台范围，需求分析
2． 定义容器云平台总体架构和组件
3． 定义容器云平台各组件能力
4． 定义容器云平台交互UI界面
5． 定义容器云平台的部署架构
6． 确定容器云平台的关键技术选型
7． 定义微服务技术架构、服务治理框架和模型（基于容器平台）
然后根据项目设计目标完成项目设计及设计文档书写。
十二、在证券容器云平台项目中，各模块如何进行设计？
容器云平台模块可能比较多，建议采用松耦合的设计，各模块通过编排而成为一个平台，也可根据需要快速进行调整重编排，比如菜单模块设计，菜单可以是动态的，根据组件需要自动生成菜单项。其他比如说权限、认证、日志（可能包括采集、传输、整合、显示等）等也是一样，松耦合。可以参考以下设计：
容器云平台各模块及组件功能定义
容器云平台是一个生态体系，包括容器云平台及支撑其上的业务应用和服务体系架构所需的各项组件，所有的组件可以定义为平台级和服务级，但也有些组件既服务于平台也服务于业务应用，比如日志中心组件。我们也曾和厂商深入讨论过相关组件建设，相互都有受益。
集中日志中心
集中日志中心是容器云平台日志的采集、存储、汇聚、分析、展示的组件，采用基于ELK + Graylog等工具来实现集中日志中心的能力。提供基于中性化集群的管理、查询功能。支持标准输出日志采集、文件日志采集、log4j日志文件采集，kafka数据采集等。
日志采集工具除了logstash，另外采用filebeat、metricbeat、packetbeat、winlogbeat、auditbeat、heartbeat等工具。
数据采集组件支持Fluentd、Logstash、filebeat等。
详细设计请参阅《集中日志中心方案设计》。
需要注意的是，平台日志和应用日志是两个层次，可以用集中日志中心来集中管理平台和应用的日志，因此，集中日志中心的权限体系需要支持租户权限体系，平台管理员就是一个特殊租户，需要实现和打通各组件之间的统一认证和权限能力。
监控告警中心
监控告警中心是容器云平台监控平台各组件运行状况、监控告警规则定义、收集并展示平台运行情况的组件。监控告警中心是运维的重要助手，没有它就如同两眼一抹黑，难以有效保障容器云平台的正常运行，无法预测系统运行资源使用，就无法保障其可用性。
监控告警中心采用Prometheus + AlterManager工具，使用Grafana实现监控面板，展示监控内容项，另外自定义实现一些监控面板，以更好的集成到平台不同的组件中展现相关监控内容。
API网关
API网关是实现业务应用安全和服务治理的重要组件。可独立于容器云平台，但由于其独立性，我们把它作为一个独立服务组件来建设。API网关也是实现OpenAPI管理和提供稳定的接口能力的组件，通常包括API网关、API 管理工具，API集市等组件。
服务注册中心
服务注册发现中心是提供服务注册和查阅的地方。一个服务要给其他客户使用，就需要根据注册机制注册到注册中心，提供一个公开的地址，方便客户查阅。客户如果想使用某些服务，通过注册中心进行查阅，找到合适的服务及其地址，就可以在自己的服务中调用。
服务注册发现中心和容器云平台自身的注册发现组件不是一个内容，通常作为容器云平台的外部组件来支撑整个服务或微服务体系。和API网关等组件紧密结合实现服务治理。
服务配置中心
服务配置中心是容器云平台支撑微服务必不可少的组件，也是为了更好的利用容器的特性，支持运行时服务配置更新，解耦合服务配置和服务实现框架。服务配置中心是独立的组件，也可应用于其他平台和系统。在容器云平台，可以扩展支持不同层级的配置，比如应用层、服务层、实例层，根据实际需要来定义和管理业务应用和服务的配置。Config Client 和Config Server之间采用JMS或Kafka等消息组件作为通信组件。
统一认证中心
认证中心首先支持容器云平台各生态组件之间的统一认证和授权，和权限中心组件集成实现各组件的访问控制。认证中心提供单点登录能力。
平台管理
平台管理是容器云平台管理员视角或平台管理员角色所能操纵的功能。重点是基础设施资源管理和租户账户管理。理论上这一块更象是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端。目前有众多的开源实现。安全性有待加强。
资料/文章推荐：
金融企业容器平台建设-需求和设计实践经验分享
http://www.talkwithtrend.com/Document/detail/tid/416049
金融保险行业容器云平台实践
http://www.talkwithtrend.com/Document/detail/tid/409413
欢迎关注社区 "容器云"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/98447
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场