容器云平台是为了承载企业业务应用服务的，业务应用管理是其核心能力。云计算很重要的一个特性是多租户，每个业务应用都可能是一个租户，每个租户关注的是自己的业务应用。比如建设的客户中心可以是一个租户，服务中心是一个租户。但是这些业务应用需要云计算资源，这些资源是在云平台上统一来维护的。另外还有就是要构建这些业务应用需要的DevOps工具链和标准化交付流程等。这里就涉及到多租户应用管理的租户视角，容器云平台资源管理等的平台管理员视角，以及标准化的业务应用镜像交付流程标准化交付视角三个视角。
另外基于对容器云的横向层次理解，我们将容器云平台划分为4层：基础设施资源层、基础设施资源调度层、平台层和业务应用层。再者基于DevOps的持续集成、持续部署、持续发布、持续监控、持续反馈、持续改进的需求（服务和应用全生命周期管理），定义整个DevOps链路为一个闭环。
基于这些探索，我们把容器云平台能力归纳为“三视角四层次一闭环”，简称“三纵四横一回路”。
容器云平台架构
开源虽然免费，但离真正的生产就绪还有很长的路要走，这也是我们重新设计实现容器云平台架构的原因。
一、三视角
从容器云平台功能来看，可以划分为平台员管理视角（重点是资源管理）、租户视角（重点是应用管理）和标准化交付视角（标准化镜像交付）。不管私有容器云或公有容器云，都可以这么去考虑。使各部分职责清晰，功能明确，这也是DevOps协作与整合的要求。不能因为是私有容器云平台就不分本地和云端，否则从技术上讲那就没有云计算的意义了，从业务上讲也难以满足复杂的业务场景管理需求。
1. 租户视角从云计算租户的视角来看，是利用云计算的资源来托管运维自己的业务应用，所以租户不应该去关注资源的运维，租户关心的是容器云平台提供的服务能力和保证自己业务应用的正常运营所需要的能力。如果两者匹配，将有助于租户去运营自己的业务应用。租户的需求就是我们建设容器云平台的建设需求。
租户可能来自不同的团队、不同的部门、不同的项目组、甚至不同的公司。那从租户视角看，首先可能需要支持不同的组织架构管理，组织架构下面有人员，每个人员或者每个组织有相应的角色，角色对应着权限。这就是支持多租户首先要解决的权限管理问题。我们和厂商重构了多租户权限体系，推出权限中心 组件服务，来支持不同的用户、组、团队、部门、公司等对于权限管理的需求。
应用管理
有了权限体系的支撑，我们重点构建对业务应用的功能支撑。这里有几个概念：应用、服务、服务实例。服务我们可以简单理解为微服务，也就是提供某项能力的一个组件服务，服务通过编排为业务应用，而每个服务为了支持高负载又可能部署多个服务实例，所以就形成了应用——服务——服务实例三层关系。
服务也可以独立部署为一个应用。微服务的基本原理就是让一个小型应用专注地做好一件事情。比如说我们的权限中心，是一个独立的微服务组件，但也可以部署为权限中心应用，提供权限管理服务。
应用管理主要是对服务的管理，服务的注册发现、配置、流控、路由、负载均衡、转换、熔断、日志、监控、告警等都需要相应的组件支持，这是容器云平台能力建设的重点。容器云平台建设的目的就是旨在支撑业务应用。
需要注意的是，我们建设容器云平台，为了应用开发、应用托管和应用运维的能力，所以更确切的说是利用容器技术建设应用平台，因此“容器”并不是主角，所以我们也一再强调并不需要在容器云平台非要列出“容器”二字，我们仅仅使用容器技术而已。建设容器云平台是为了承载业务应用，因此应用管理能力是核心。
谈应用管理不得不先谈多租户，因为我们不可能一个“admin”就部署管理所有的业务应用服务。那是很恐怖的事情，特别采用了微服务，有没有考虑过一个人能管理多少微服务？不要人为复杂化了。我们说了，复杂不是我们设计的初衷。所以我们需要考虑使用多租户机制来隔离租户之间的应用和资源，简化运营管理。
应用管理分为两个阶段，在容器云平台只实现运维管理，以镜像仓库为起点，完成应用生命周期管理。持续集成阶段在标准化交付流程实现，终点是镜像仓库。因此镜像仓库是我们开发（Dev）和运维（Ops）的媒介。
2. 平台管理员视角理论上平台管理是云端的功能，由云计算提供商来维护，但容器云本地化部署，不得不自己运维。虽然自己运维，也需要考虑本地云端和租户的明确职责划分。我们几乎调研了所有的初创容器云厂商，这点做的都不好。就象刚才��̥,����我们提到的，一个“admin”干了所有的事情。因此我们也重构了平台管理服务能力。
平台管理
平台管理重点在于基础设施资源管理。当然平台管理首先也会涉及权限管理，可以直接使用权限中心服务。这就是基于微服务架构构建容器云平台（注：《以微服务的思想实施容器云》）的好处。基础设施资源包括计算资源、存储资源、网络资源以及操作系统。操作系统也是资源，不管物理机或者虚拟机，容器都需要运行在其之上，需要操作系统来支撑。平台管理员负责这些资源的管理和运营运维，分配资源给租户并监控租户资源的使用情况。平台管理员根据租户需求分配相应的资源。如果基础设施层做了虚拟化，可能无法直接从虚拟机层面区分其宿主机配置差异，这可能需要我们做一些工作。比如我们在部署应用时，可能需要考虑其高可用部署，理论上就不应该部署两个实例到一台宿主机上，最好分布这些实例到不同的宿主机上，在部署的时候策略选择需要能区分这些不同宿主机上的虚拟机，采用反亲和性部署。
为了更好的支撑用户的业务应用，需要提供一些通用或常用的中间件工具，比如kafka、MySQL、Tomcat等，因此我们规划了公共镜像仓库，由平台管理员来提供全平台所有租户可用的中间件工具，可以一键部署，快速完成环境配置，特别适合测试环境的快速构建。
租户账户由平台管理员来创建并由平台管理员来维护。平台管理员为每个租户创建租户账户并分配资源。每个租户下的用户和角色，由租户自己管理维护。平台管理只为每个租户创建一个且仅有一个租户账户。租户账户全局唯一。
平台管理除了对资源的基本的日志、监控、告警能力之外，还有一点可能需要考虑平台设置 能力。对于平台全局性的一些配置提供用户接口，用户根据实际运行情况进行调整。
3. 标准化交付视角采用容器技术，很大程度上是为了标准化。容器引擎实现了基础设施的标准化，容器镜像实现了应用交付的标准化，而容器可以实现运维调度管理的标准化，镜像仓库则实现了分发部署的标准化。标准化交付的结果是Docker镜像，我们希望一次构建，可以在任何地方运行（build once， run anywhere）。标准化交付流程也就是持续集成流程的终点是镜像仓库，镜像仓库作为持续集成和持续部署的媒介，完成测试的镜像可以通过生产镜像仓库发布到生产环境。然后就是租户视角的应用管理，持续的监控应用服务的运行情况，并保持持续的反馈运行情况，以便及时的改进，形成一个良性循环。
我们之所以定义镜像仓库作为持续集成和持续发布的媒介，也是因为持续集成是开发阶段，在这个阶段我们往往关注的是“项目”，其所涉及的人员角色和运营阶段不同，运营阶段关注的是“应用”、“服务”，一个项目可能包含很多服务，甚至多个应用。为了更清晰的划分职责，也简化容器云平台研发的难度，我们把标准化交付流程分离，成为一个独立的组件或产品，类似于阿里的云效。复杂性永远不是我们设计的初衷。用最简单方式解决最复杂的问题才是我们所追求的。
标准化也带给我们了敏捷研发能力。开发人员只关注业务逻辑的研发，不在考虑运行环境和非业务逻辑处理，比如路由和转换，所有非业务逻辑的服务治理可以在API网关层实现。同时利用容器的特性，实现弹性伸缩等能力。运营人员对服务的运行情况保持持续的监控，持续反馈服务运行状况，比如服务运行异常，改进建议等，由开发人员持续改进服务，从而形成一个闭环流程。这就是我们期望的DevOps。
标准化交付
二、四层次
容器云平台四层架构
在容器云平台架构设计时，为了更好的保证松耦合等特性，纵向从三个视角来看，横向根据相对独立的基础设施资源、资源调度管理框架、为了支撑业务应用需要建立的各项功能、以及业务应用概念，划分为四层：基础设施资源层、资源调度层、平台层（业务应用支撑层）、业务应用层。
基础设施资源层指的是基础设施资源，也就是计算资源（CPU、内存）、存储资源、网络资源以及操作系统资源。在这一层通常我们面对的是选择物理机或者虚拟机的问题，是否选择分布式存储的问题，以及选择什么容器网络模式的问题等。这些问题讨论的也很多，仁者见仁、智者见智，我们认为最终还是要基于自身的实际需求确定。另外需要考虑尽可能用简单的方式来解决这些看起来复杂的问题。刚开始接触容器或容器云，不理解不知道该怎么选择很正常，但首先一点需要明确，就是需求定位问题：拿容器或容器云来做什么？然后基于需求可以确定这些基础设施资源方案。
这里可能会忽略的一个问题是操作系统资源问题。不同操作系统会有差别，但对Linux来说，文件描述符等操作系统资源是需要根据实际需求做一些调整的。
2. 资源调度层基础设施资源，你用或不用，它就在那里。资源调度层最重要的是对资源的抽象能力。有效并且安全的利用资源是我们在这层追求的目标。这其实应该算是IaaS层的能力，但目前容器似乎和IaaS的结合还不是很理想，所以直接管理IaaS的资源有些难度。通常情况下如果基于Vmvare虚拟化会相对简单些。因此不管怎么争论容器是基于物理机或者虚拟机，具体实际的情况最有发言权。脱离实际注定是不合适的。
Kubernetes提供了对集群、节点、CPU、内存、存储、网络等的抽象支持，实现了对容器运行所需资源的调度管理。但某些节点可能需要预留一部分资源，也有一些应用需要限制它使用的资源量，这可能会涉及资源限额的配置。另外我们提到在为容器调度资源时，可能会面临着亲和性和非亲和性的一些调度策略需求。物理机还好，对于经过虚拟化抽象之后的虚拟机来说，会失去一些东西，因此容器调度可能会存在一些潜在的问题，这也是我们最初倾向于使用物理机的原因之一。不过由于我们的服务器都是很高的配置，为了有效且安全的利用资源，我们选择虚拟化了一层实现更细的资源隔离。这和微服务的设计思想相同：化大为小，而容器通过编排调度实现了以小拼大。
要调度资源就需要知道调度哪些资源是合适的，需要对资源进行标注、打标签。比如一台物理服务器虚拟出了10台虚拟机，在部署应用的时候两个实例可能需要考虑反亲和性策略，选择10台中的一台部署应用实例，然后再选择其他物理服务器虚拟出来的虚拟机中的一个，保证一个应用的两个实例不会落在同一物理服务器之上。这要求我们在分配虚拟机时就要能标识其物理服务器属性。
3. 平台层平台层是容器云平台建设的核心能力，是支撑业务应用的功能实现层。首先需要考虑和资源调度层实现松耦合架构。不管是Kubernetes或是Openshift，都面临这快速迭代的问题，一年好几个版本的迭代，如何能轻松的跟上这些产品版本迭代，是选择容器云平台不得不考虑的问题。因此与资源调度层必须采用松耦合架构，尽可能减少版本的迭代更新对平台的影响。
多租户机制实现租户之间的隔离，也是为了化大为小，化繁为简的需要。提供给每个租户有相同的能力不同的资源，租户按需使用资源运营应用。权限、认证、注册发现、服务配置、日志、监控、告警、API网关、部署管理、负载均衡、弹性伸缩、灰度发布、健康检查、DNS服务、审计计费、统计分析等服务支撑能力都需要在这一层实现。可以采用微服务组件服务的形式实现，组件部署也可以根据实际采用非容器化部署，比如API网关，以非容器化集群方式部署，提供对7层服务调用的治理能力。
对于这些组件 的详细设计和能力，我们也基本上都探讨过，这里不在赘述。
4. 业务应用层业务应用层是企业真正关心的地方，也是我们构建容器云平台的目的：支撑业务应用。在我们平台层提供的能力完备的情况下，随着微服务的建设，业务应用的研发将越来越敏捷。可以通过简单的服务编排就可以实现新的业务功能，部署为新的业务应用。就像乐高积木一样，可以拼出不同的服务和应用。真正实现了敏捷！
三、一闭环
从租户视角容器云平台更多是定位于一个应用管理和运营的平台，它只是应用生命周期管理的一部分，应用的开发尚未纳入进来。我们把应用的开发阶段和流程分离，作为一个持续集成的组件，以镜像仓库为媒介，完成持续集成和持续部署的衔接，从而使持续集成-持续部署-持续发布-持续监控-持续反馈-持续改进流程形成闭环DevOps链路。
持续集成完成标准化镜像交付，持续部署完成测试和生产环境的镜像部署，持续发布根据定义的发布规则发布生产可用服务，持续监控实现对已发布服务和应用的持续健康检查、异常告警等，持续反馈则实现健康检查数据、异常告警数据等的收集分类、反馈，如果是代码错误则自动记录缺陷并转研发人员（根据角色定义），启动新一轮的流程（持续改进）。
容器云平台的设计直接决定着其建设的能力，从不同角度分析和理解容器云的设计，融合微服务架构和DevOps方法论，来支持业务服务和业务应用的完整生命周期管理和治理，可以满足不同复杂业务场景的需求，同时也支撑了客户中心、服务中心系统的上线和运营。