PaaS就是一个为应用提供自动化研发，部署，调度，运维的管理平台。

PaaS

paas的定位

平台即服务（PaaS）与基础设施即服务（IaaS）是不同的，PaaS并不是IaaS的一个扩展特性，对于基础设施即服务（IaaS）来说，基础单元就是资源，这里的资源是指服务器，磁盘，网络等，IaaS所做的一切就是按照需要提供这些资源。例如，亚马逊（amazon）的EC2服务，所有的工具都以资源为中心，所有的文档都是关于资源的，所有的开发都是专注于资源，同时人们也因为需要这些资源而使用它。

对于平台即服务（PaaS）来说，基础单元就是应用。那么什么是应用？就是一个系统，就是代码以及所有那些在任何时候都与这些代码通信的服务。这不仅仅是资源，事实上，一个应用是由很多单独的资源绑定在一起组成的。将所有这些资源连接在一起所需要付出的工作量通常被低估了。从一个单一的运行Apache和Mysql的服务器转移到一个拥有单独的负载均衡服务器，缓存服务器，应用服务器，数据库服务器以及冗余的失效恢复的系统架构需要大量的工作，包括前期投入以及后期维护。一个成熟的PaaS平台可以为用户提供上述的所有功能，在减少用户大量工作的前提下，大幅度提升用户应用的开发速度，运行稳定性，可靠性，极大的降低了用户的开发，测试及运维的成本。

利用PaaS可以做的另外一件事，就是从应用的角度来管理IaaS。通常情况下，使用者对于IaaS的资源需求实质上是来源于运行在IaaS之上的应用，如何根据应用的需求动态的使用IaaS资源又成为摆在云使用者面前的一个难题，PaaS作为SaaS与IaaS的沟通者，可以根据SaaS的需求动态的协调IaaS资源，使IaaS按需分配资源的理念变得更智能，更有实际意义。

IaaS为云使用者提供了按需分配的能力，用户可以按照自己的需求定制计算资源，存储资源，网络资源，并且利用云端的海量资源随时快速的开启资源，并在工作完成时，随时释放资源，在享受云带来的高可靠性的同时，也最大化的降低了使用成本，提升了资源利用率。

但是IaaS为云使用者带来的便利只局限在资源这个层面上，云使用者可以快速，稳定，海量的使用资源，但是一旦获取到资源后，云使用者依然要为运行在资源之上的应用搭建各种适配环境（部署），解决应用的各种依赖，安装应用要使用的各种服务，维护应用的运行生命周期。这些问题IaaS都没有解决，或者说，这些问题本质上也不是IaaS需要解决的问题，而是PaaS需要解决的问题。

综上所述

  • IaaS关注于硬件资源的自动化管理，目标是人与机器的解耦合，提升了效率和性能。
  • PaaS关注于应用的自动化管理，目标是应用与操作系统的解耦合，提升了弹性和控制。在应用的角度，paas可以管理iaas的资源。
  • Paas可以是kvm的虚拟化技术，只不过kvm太重，目前容器技术才是Paas平台的首选。

补充

其实现在paas的发展已经渐渐的下沉，开始涉及到iaas的领域，其实我们现在更加习惯于把cncf生态以及k8s重paas中剥离出来，位于paas和iaas之间 做的是基础平台的能力，而paas更加偏向于应用serverless，在cncf生态以及k8s的基础之上，建设自己的应用微服务化，然后主要建设发布的流程也就是devops 这个是目前各个公司做paas的的主要方向，而k8s的建设更加偏向于使用公有云，有云服务厂商来提供基础能力，当然也有基于iaas的基础云能力，在这个上面 建设调度和workload的建设，而iaas层的网络和存储的基础能力已经可以单独建设，这些公司更加偏向于直接使用csi和cni的建设。总之

  • 使用公有云的公司，直接建设devops+微服务
  • 基于公有云的公司，建设自己的基础能力，主要调度+workload，来提高利用率，降低成本
  • 私有云公有云厂商，完全建设自己的底层iaas和上层paas，提供内部和外部的能力，包括网络，存储，调度，workload等等。

所以下面的paas平台都应该换成容器平台比较合适，希望大家能理解，我就不操作了。

PaaS的分类

我们需要了解一下PaaS平台自身的分类。Gartner把它们分为两类

  • 一类是应用部署和运行平台APaaS（Application Platform As a Service）
  • 一类是集成平台IPaaS（Integration Platform As a Service）。

APaaS是一种面向IT企业和机构的云计算应用开发与部署平台。APaaS主要为应用提供运行环境和数据存储，能够将本地部署的传统应用直接部署到APaaS上。

IPaaS是用于集成和协同的PaaS平台，不仅可以支持与现有云服务间的连接性，而且可以以安全的方式提供企业应用的访问能力。IPaaS主要用于集成和构建复合应用。

大数据厂商的PaaS实际上是属于IPaaS，而容器厂商和IaaS厂商的PaaS大致为APaaS。我们经常见到的云平台建设也是APaaS，APaaS的一般特性：

1、大规模分布式系统：

  • 完全模块化的分布式系统，保证云平台可靠性；
  • 每个模块单独存在和运行，通过消息总线进行通讯；
  • 系统耦合度低，便于弹性动态扩展；

2、弹性伸缩框架：

  • 平台自身组件支持实时横向扩展;
  • 根据应用的负载情况，动态加载应用实例；
  • 应用实例支持实时水平扩展；

3、运维自动化：

  • 日常运维操作简化;
  • 故障自动恢复;

4、应用部署简单化：

  • 一键式应用快速部署;
  • 支持多种应用开发框架，包括Spring、.NET、Ruby on Rails，Node.js等;
  • 通过buildpack扩展运行不同语言应用的能力;

5、支持多种服务：

  • 支持多种数据服务，包括MySQL、mongodb、PostgreSQL等;
  • 通过service broker组件扩展多种应用服务能力，包括数据库、中间件、缓存、云存储等。

主流PaaS平台架构及对比

了解了PaaS的分类，我们再来看看PaaS的具体技术对比。由于IPaaS具有很强的业务属性，因此这里我们主要来看一下更通用的APaaS，也是目前被大家最多提起的。说到PaaS，相信很多人都会把他和容器、Docker关联起来，下面来看一下这张图：

这张图很清晰的划分出了XaaS以及各种概念对应的平台。大家所熟知的基于docker的编排工具搭建的基础平台在这里实际上是CaaS的一种。

CaaS

CaaS其实就是容器云平台，提供直接管理操作基础设施的性能，带来基础设施层面的灵活性。用户通过直接操作容器可以更灵活的实现应用迁移、部署。但这个更加轻量的平台带来了用户学习成本和使用复杂度的增加。

容器云平台的搭建只依托 Swarm/Mesos/K8s 等容器编排调度系统就可以实现，同时还需要引入大量的第三方解决方案，例如日志、监控、网络等。这就意味着一定的试错成本，另外第三方系统的成熟度发展不一，组成一套统一的云平台后进入生产环境的应用需要经过一定周期的论证和验证。

但是这个算是基础平台，下面的平台都是基于这个平台之上进行封装整合其他第三方组件组成一个完成的生态平台，所以这些基础编排工具很重要。

Cloud Foundry 平台

Cloud Foundry 隐藏了基础设施层面的复杂度，提供应用层的管理操作，简化基础设施和应用的构建管理，平台也使用容器技术，但仅仅是平台架构中的实现细节。通过 CF 可以更加敏捷的实现应用开发、部署、业务实现等。

Cloud Foundry 的架构是一个相当完整的 PaaS 架构，模块丰富，平台自身可以提供对于平台节点、应用的监控、管理，日志，自动化运维等完整的解决方案。每个模块都部署在一个或多个虚拟机上，在经过长时间的应用，Cloud Foundry 已有很多在生产环境的案例。CloudFoundry是基于容器技术打造。相比于虚拟机，容器带来的系统开销非常低，所以，从经济性来说，容器的技术远远好于虚拟机。另外一个比较的标准是性能，容器的性能相对而言更好一些，但是，从安全性和隔离型来说，虚拟机是远远好于容器的。

CloudFoundry的架构设计如下图所示。

  • 首先，CF也提供了一个路由模块(Router)，该模块基本是基于ngnix打造，只是在ngnix技术上提供了动态注册的功能。在部署时，由于CF会同时部署非常多的应用实例，所以需要一个router集群来满足应用的需要；
  • 其次，CF的应用容器基于自己开发的warden技术，warden也是基于LXC技术，但是使用c和ruby作了一层简单的封装。Docker的大热让CloudFoundry很纠结；
  • 第三，CF使用service broker来集成各种资源服务，如mongo、mysql、rabbitmq和redis等。最后，CF使用消息总线NATS/GNATS来完成应用之间的通讯。

我们简单看一下Cloud Foundry的特性

优势

  • 支持各种各样的语言、web框架、数据
  • 为开发者和云供应商提供简易和快速的自服务部署
  • 应用程序容器、服务和节点都被监视，如果在预期状态之外会自动重启
  • PaaS支持大数据和移动服务
  • 可以使用命令行、Eclipse、Spring Tools Suite、Maven、Gradle 进行部署

缺点

  • 虽然自动横向扩展只存在测试版，但是已计划在第三季度的Pivotal CF中释放；另一个Cloud Foundry发行版ActiveState的Stackato已经支持这一特性
  • Cloud Foundry v2版本尚未提供可下载“微型”VM，但是你可以下载Stackato Micro，或者使用其中一个Cloud Foundry安装程序在本地VM中进行安装
  • 只支持 Ubuntu Linux上的有限应用程序，除下你使用Cloud Foundry的Uhuru Windows版本，这个并未评测

平台

  • Pivotal CF：VMware vSphere，OpenStac，Amazon Web Services，Google Cloud Platform

我们简单的对比一下传统的编排工具打造的容器平台和容器平台项目的差距

特性          Cloudfoundry             Docker／CaaS
部署          直接部署程序Release包  需要制作Docker镜像
监控          完整解决方案          需要集成第三方工具
日志          完整解决方案          需要集成第三方工具
网络          完整解决方案          需要集成第三方工具
自动化运维       可以和IaaS联动       不支持IaaS联动

但是CF底层并没有使用docker，相对于想docker一统天下的局面就有点显得落后和不友好了。所以目前使用的已经不多了，所以我们再来看看最新兴起的以docker为基础的paas平台项目：openshift和rancher。

openshift

Cloud Foundry 是一个常被用于和 Openshift 对比的产品，前者由 Pivotal 公司开发(大名鼎鼎的 Springboot，SpringCloud就是他们家的)，后者由 Redhat 开发。很难用一两句话说清两个 PaaS 孰优孰劣，但就我个人的使用体验而言，Cloud Foundry 自动化程度更高一些，而 Openshift 可定制化程度也更高。但是由于cf底层基础并不是k8s+docker的生态，所以现在并不具有可比性。目前主要的对比对象是国内的rancher项目。

Openshift 实际上由三部分组成

  • 核心部分实现容器的调度是封装的 Kubernetes
  • 除此之外还有一个内置的镜像仓库（Image Registry），这个仓库是可选的，Openshift 也可以配置使用 Dockerhub 或者企业自己的镜像仓库
  • 最外层部分是一个友好的 Web 界面，用于展示和操作 Openshift 的资源。

如下图所示，Openshift 要成为一个完整的数字化平台需要依赖于两个外部系统，一个代码库，一个是持续集成服务，事实上这两个外部服务也是可以跑在 Openshift 里面的。右边的灰色矩形就是 Openshift 的主要架构了，它的上层是一个路由（Router），用于 DNS 解析和转发，确保用户能够调用到 Openshift 集群中的服务。红色的部分是跑在 RHEL 操作系统上的 Kubernetes 集群，侧面是外部存储服务，因为集群里的计算单元是漂浮的，所以通常 Kubernetes 集群只提供计算能力，数据持久外需要依赖外部的比如说 S3，EBS 等云服务商提供的存储服务。最下层同样也是由云服务商提供的基础设施服务。

我们简单看一下OpenShift的特性

优势

  • 支持各种各样的语言、web框架、数据、应用程序堆栈
  • 为开发者和云供应商提供简易和快速的自服务部署
  • 自动应用程序扩展
  • 在开源代码等级整合Git，通过git push出发自动部署
  • 闲置gear终止允许更高的应用程序密度
  • 只要支持Red Hat Enterprise Linux就可以运行在任何硬件、云或者是虚拟机上

缺点

  • 很大程度受限于只支持 Red Hat Linux上运行的应用程序，除非你使用Uhuru OpenShift.Net产品，这一点并未评测

平台

  • OpenShift Enterprise：Red Hat Enterprise Linux。
  • OpenShift Origin：KVM、VirtualBox、VMware Fusion/Player

rancher

虽然 Kubernete 在容器调度方面表现出众，但他的功能还元不构成一个 PaaS 平台，于是很多厂商开始基于 Kubernetes 开发自己的 PaaS 平台，其中就有目前在国内创业公司被大量使用的 Rancher，值得注意的是 Rancher 是在2016年才开始发布第一个版本，而 Openshift 则早在13年就开始基于 Kubernetes 的开发，但目前看来国内市场对 Rancher 的接受度是远高于 Openshift 的，就使用体验上看，Rancher 也确实更简单易用。

这边需要详解的了解一下rancher。

它们俩各有各的特点。我们来简单的做一下对比

OpenShift:

  • OpenShift有开源版本，是免费的。但是真的在企业级的使用情况下，还是要花钱的，比较贵。这个应该是相比于rancher比较不受欢迎的地方。
  • 一般版本会落后K8S一个大版本，对原生K8S改进较大，这个也是影响paas平台选择的一个重要因素。
  • 一般为只管理单个OpenShift集群
  • 设计了ImageStream，BuildConfig与DeploymentConfig等资源对象，及s2i构建方法，方便了开发者实施Devops。
  • 添加了一个内部镜像仓库。
  • 使用Route资源，为应用提供了一个公共统一的访问入口。类似于Ingress，使用起来比Ingress方便。
  • 提供了一个友好的可视化界面。
  • 对容器有更多的安全策略，更安全
  • 有更高的可靠性。 作为RedHat的企业级容器平台，红帽会对集群做详细的测试，修复bug。

Rancher:

  • 具有良好的界面，rancher 的中文化做的比较好，对k8s的一些组件重新做了打包，在国内安装比较方便
  • 方便管理多个K8S集群
  • 对网络插件的选择会比OpenShift更加灵活
  • 与K8S版本同步，及时拥有K8S最新的特性，对K8S自身改动较少

个人认为，单集群管理使用OpenShift，更稳定，更简单，也更安全，而如果是要管理多集群，选择Rancher。不过OpenShift 4起红帽也支持多集群管理，但还不能私有化部署。

两种方案都有不少的企业客户选择，因为都是基于K8S， 功能上都差不多 。不管是构建DevOps流水线，还是生产部署原生应用上。

容器云平台

现在各大企业搭建的容器云平台都是基于k8s+docker的paas平台。基本上都是基于rancher，openshift搭建，或者使用k8s自己管理，容器云平台自下而上分别覆盖了云计算的 IaaS 层和 PaaS 层涉及的各类问题，包括资源调度、服务编排、应用部署、监控日志、配置管理、存储网络管理、安全等。

PaaS平台架构

上图是我认为比较完全的一个paas平台的架构，我觉得主要分为四大块建设：DevOps，基础集成，监控日志，安全。

DevOps

DevOps我个人理解就是字面意思，敏捷开发（微服务），标准交付（镜像），快速部署（编排），其实就是一套微服务开发后，测试，部署，运维的自动化流程的思想。所以devops可大可小，大了其实就是整个容器云平台的生态，小了说就是我们常说的CDCI。

DevOps主要就是用于研发的持续集成和标准交付，实现敏捷开发迭代部署，就是基于gitlab，jenkins，harbor，helm搭建的开发部署平台。

CI/CD

CI/CD 要求每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件，减轻了软件发布时的压力。

  • 持续集成：持续集成是一种实现产品和应用快速迭代的一种实践方式，这种实践要求开发人员所提交的每一次代码都能够快速被合并到生产线，并进行自动构建和上线。能够容易定位 Bug 并提前发现和解决，降低开发成本。
  • 持续交付：持续交付的缩短了需求完成周期，满足小粒度交付需求，打造自持敏捷开发，精益迭代和持续交付的研发基础设施。此外，提高了产品迭代速度，提升了应用软件质量。并且支持容器扩容、收缩、升级和回滚，轻松实现应用灰度发布，还拥有更快的应用交付和Go-to-Market能力。

CI/CD流水线式实现流程：应用从代码编译、测试、打包和部署的过程，流水线管理一般使用常用的 Jenkinsfile 来表述一组 CI/CD 流程。从代码仓库 、代码编译、镜像制作、镜像安全、推送到仓库、应用版本、到定时构建的端到端流水线设置。

持续集成、持续交付、持续部署提供了一个优秀的 DevOps 环境。对于整个开发团队来说，能很大地提升开发效率，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。

  • 持续集成（Continuous integration，简称CI：频繁地（一天多次或者N次）将代码集成到主干。将软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。
  • 持续交付（Continuous delivery）：指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。
  • 持续部署（continuous deployment,简称CD）：是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。

核心

Jenkins

交付中心

容器镜像实现容器运行时标准化，应用模板（helm）实现编排文件的标准化。镜像和应用模板是开发（Dev）和运维（Ops）的媒介，完成测试的镜像、应用模板可以发布到生产环境；然后在容器云平台上部署和管理应用，持续监控应用服务的运行情况，并保持持续的反馈运行情况，以便及时的改进，形成一个良性循环。交付中心实现镜像、应用模板的集中安全统一管理，实现企业软件资源积累和沉淀。让所有用户都可以自由地下载为服务组件，这为开发者提供了巨大便利。

  • 镜像仓库：提供了多种构建镜像的方式，支持对接 CI/CD 工具，能够简化企业应用容器化的难度，轻松实现应用的容器化。并提供日常镜像维护的功能，比如镜像扫描、镜像同步和镜像清理等。其实就是镜像仓库，目前最常用的Harbor。
  • 应用模板：基于 Helm 标准的应用模板提供统一的资源管理与调度，高效地实现了模板的快速部署与后期管理，大幅简化了Kubernetes资源的安装管理过程。

核心

harbor

helm

基础集成

基础集成就是基于docker+k8s的搭建的资源调度平台，是paas平台的核心和基础。

k8s

docker

基础设施管理

容器云平台的基础设施资源主要包括主机、网络、存储资源等。

  • 主机：容器云平台的计算能力由节点 (Node) 提供，节点类型分为控制节点和容器节点，业务应用的容器组都运行在容器节点。节点可以是物理机或虚拟机，平台可根据业务需求组建一定规模的节点集群。容器云平台的节点管理需满足企业对集群运维监控的需求，支持实时查看集群资源使用情况和节点状态，查看任意节点上 CPU 和内存的消耗、容器组数及状态。并且提供对节点的全方位细粒度的资源监控如 IOPS、磁盘吞吐、网卡流量，让用户一目了然所有节点资源状态。其实这个就是IaaS层面的管理了。
  • 网络：容器云平台的容器需要进行网络隔离或者网络连通，网络的管理功能需要支持标准的容器网络模型，还需要支持扩展的网络技术。以此来提供丰富的网络功能，更好的为业务服务提供最佳网络服务方案。不同的选择在网络性能、网络节点规模等方面各不相同。网络方案主要有 Bridge 网络模式、Host网络模式、Overlay网络模式等方案。容器调度管理应支持图形化管理网络，减轻网络配置技术难度，弱化对指定硬件厂商的依赖。此外，网络通信安全方面应支持创建安全加密网络，保障网络通信信息安全。
  • 存储：容器是无状态的，当容器崩溃重启时，容器中临时存放在磁盘的文件将会丢失。 其次，当在一个容器组中同时运行多个容器时，需要在这些容器之间共享文件。但是生产业务应用大部分都是有状态，容器云平台通过存储卷解决存储问题，并支持对接多种存储方案，比如采用 Ceph、NFS、glusterfs 等。

这块一般是云服务厂商需要建设，比如阿里云，腾讯云等，如果直接使用云服务，一般直接使用其能力就可以，重点就在调度发布的能力建设了。

核心

k8s网络

分布式存储

应用管理

容器云平台其实主要是针对应用（serverless），最核心的功能就是应用全生命周期管理。应用通常是一个独立完整的业务功能，一个应用可能由多个服务组件组成，对于微服务而言每个组件都可以独立于其他组件部署、启动、运行和治理。容器云平台需要提高对应用的一键式部署、健康检查、弹性扩缩、升级发布、资源管理、访问管理、监控管理等功能，从而保证应用的整体服务能力。

  • 一键式部署：一般支持通过镜像、应用模板和 YAML 等方式部署应用，让用户可通过多种应用交付物快速便捷的部署。
  • 健康检查：由于容器启动后应用还需要较长时间才能接受请求，容器正常运行但容器中的应用服务异常等原因。需要支持应用健康状态的检查，健康检查结果会指导负载均衡、滚动发布和弹性伸缩，实现更平滑的过程 。
  • 弹性扩缩：支持通过手动、自动和定时等方式对容器的实例进行弹性的扩缩，保证应用运行的稳定性。
  • 升级发布：支持通过单一服务按照指定实例数滚动升级实现滚动发布；通过建立跨服务的 4 层负载均衡实现灰度发布／蓝绿发布；并支持一键回滚；基于预定义镜像规则自动发布，支持 DevOps 自动化流水线场景。
  • 资源管理：对容器部署或运行过程中的的 CPU、内存等计算资源、网络和存储资源的分配进行集中管理。
  • 访问管理：容器的外部接入访问入口，和平台内部访问容器的控制台入口的管理。
  • 监控管理：对容器产生的日志进行统一查看和导出，并且配置容器的日志管理服务器；对容器的资源包括CPU、内存、网络、存储等的使用情况进行可视化监控。

核心

k8s控制器

k8s调度

服务治理

服务治理是主要针对分布式服务框架的微服务，处理服务调用之间的关系、服务发布和发现、故障监控与处理，服务的参数配置、服务降级和熔断、服务监控等。

为什么需要服务治理？

  • 过多的服务配置发现困难，需要服务注册和发现机制
  • 服务规模大，要求高，需要服务发布策略
  • 过多服务，导致性能指标分析难度较大，需要监控定位
  • 过多流量需要管控

服务治理通过提供完整的非侵入式的微服务治理解决方案，支持完整的服务生命周期管理（发布，发现，监控）和流量治理。能够很好的解决云原生服务的管理、网络连接以及安全管理等服务网络治理问题。

  • 灰度发布：灰度发布是迭代软件产品在生产环境安全上线的重要手段。允许用户按照标准制定一套流量分发规则，平滑稳定的实现灰度发布功能。主要有金丝雀、蓝绿、A/B Testing 等典型灰度发布功能。
  • 流量治理：应用流量治理提供可视化云原生应用的网络状态监控，并实现在线的网络连接和安全策略的管理配置。提供策略化、场景化的网络连接、安全策略管理能力。支持基于应用拓扑对服务配置负载均衡、熔断容错等治理规则，并提供实时的、可视化的服务流量管理。
  • 流量监控：通过流量监控可以监控流量概况、组件运行状态、调用链等信息，并在系统业务异常时快速定位到问题点，这块在监控日志告警那边实现。
  • 服务发现：解决服务调用的问题，不在需要配置大量的调用地址，直接使用DNS解析。

核心

服务发布

服务发现

流量治理控制

监控

云原生的监控主要重三种方式采集监控，分别是：metrics、log、train，在容器平台中我们通常使用的就是基于prometheus+EFK+调用链生态搭建的监控日志告警平台。其实所有的监控都是重这三个方面进行采集处理的，三种相互辅助的完整监控体系。

  • 日志：日志模块需收集平台组件、业务应用、业务服务以及云上中间件的日志，可采用平台统一日志管理系统EFK生态，进行采集，存储，展示。
  • 监控告警：监控模块需提供对集群和应用的资源状态等监控metrics，支持大规模系统监控、多指标监控、多维度监控，为每一个层级资源的运行状态都提供实时的多种指标监控，并且收集资源实时监控数据和历史监控数据，帮助用户观察和建立资源和集群性能的正常标准，通过不同时间、不同负载条件下监测集群各项基础指标，并以图表或列表的形式展现，监控模块可采用平台的自有监控体系，或对接外部监控系统，比如 Prometheus。
  • 调用链：调用链模块就是对请求调用的链路的各种情况进行采集，存储，并用图表进行展示。

核心

监控体系（metrics,log,trace）

安全

安全就是基于RBAC的权限管理平台，主要是针对用户，权限，多租户等机制。

  • 多租户管理：不同租户中的资源彼此隔离。使得它们既可以共享同一个平套资源，也能够互不干扰。多租户管理的核心是分配好人员 (组织) 和资源之间的权限关系。对于容器云平台来说，需要将平台的计算资源、存储资源和网络资源，分配给各租户，让租户根据自身使用场景管理应用、用户、角色和资源。
  • 用户管理：用户管理模块，可对企业用户进行增删改查等操作，以及配置用户密码安全策略，保证用户和平台安全；同时可对接企业用户目录，同步企业现存用户管理系统，避免重复操作。
  • 权限管理：权限管理是在 Kubernetes 的角色访问控制（RBAC）的能力基础上，打造的细粒度权限管理功能。支持集群级别、租户级别的权限控制，能够从集群和租户层面对用户组或用户进行细粒度授权。
  • 第三方登录认证：当容器云平台中具有多系统，或者对接企业现有用户中心时，需要实现第三方登录认证。用户只需要登录一次，就可以访问所有相互信任的应用系统。解决企业不同业务应用之间的身份认证问题。

核心

rbac

PaaS组件

以上就是对PaaS平台基本架构进行了一个整体的划分，在每个部分都有其实现的基本组件，我们可以查看下图

容器化推广发展过程

  1. 搭建强稳定性的容器云平台，这是企业内部应用上容器云平台的基石；
  2. 完成单体应用的容器化，开展企业应用容器化之路；
  3. 开展企业内部应用容器化推广，培养企业内部对于容器标准化意识，明晰容器化应用与平台运维的边界；
  4. 开始 DevOps 企业组织架构建设，完善应用自动化构建、测试、部署、发布全流程；
  5. 开展中间件层面支持，完成企业数据中台；
  6. 引入微服务流程，完成微服务相关治理能力。

容器云平台建设意义

为什么企业建设容器云平台？

传统企业在数字化转型进程中，已完成物理机虚拟化的进程，虚拟化技术一定程度上降低了运维复杂性，提升资源的使用率。但这仅解决了 IaaS 层面基础设施的问题。业务应用研发还面临很多挑战：

  • 业务应用不够稳定，响应效率低下，业务流程复杂，导致用户体验较差； 

  • 业务应用规模复杂，组件间耦合度高；庞大的部署架构使得应用的开发、测试、发版和升级也比较复杂，使得业务升级停机时间和部署成本增加；
  • 在面临互联网企业的激烈市场竞争时，业务部门的需求变化越发频繁，同时希望研发部门的软件交付周期越来越短。但研发工作量大、周期长等问题，难以支持需求的快速响应和敏捷开发。
  • 基础设施薄弱，缺乏支撑互联网快速迭代的云环境，资源分配效率低。生产环境缺乏互联网监控手段等。

总结就是

  • 趋势：比如业务复杂不稳定耦合度高，维护迭代交付困难，资源使用效率低。
  • 降本：机器成本和人力成本

容器云平台可以解决以上问题，并且实现以下的作用：

标准化交付

容器镜像实现应用运行环境的一致性和标准化，屏蔽了应用部署过程中遇到的不同环境需要的环境配置、安装步骤等复杂问题。把原先部署、配置的运维工作提前到开发交付阶段，在制作镜像的阶段解决运维上线中出现的问题。提供了企业开发、测试和生产环境的一致性，对于自主研发能力和效率的提升会有极大的帮助。

应用微服务化

微服务架构可轻量级构建冗余，可扩展性强。容器云平台提供应用微服务化的能力，将现有的大型应用程序通过微服务架构拆成多个独立模块，每个模块使用一个应用镜像进行微服务部署；支持镜像级别的升级发布；支持容器粒度的隔离，且容器被平均分布在底层宿主机上，保证应用每个微服务的安全和稳定。助力企业一步实现微服务架构，实现应用云原生转型。

弹性扩缩

应用的访问流量是不确定的，需要避免因流量激增导致应用挂掉；以及避免因为流量减少导致大量资源浪费。容器云平台支持对主机、应用服务级别的双重扩缩，可根据用户的业务需求和预设策略，自动调整计算资源，使主机或服务数量自动随业务负载增长而增加，随业务负载降低而减少。实现业务应用的快速弹性扩缩，提升资源使用效率，保证应用运行稳定性。

敏捷开发快速上线（DevOps）

DevOps 将开发团队与运维团队通过一套流程或方法建立更具协作性、更高效的的关系，使得开发、测试、发布应用能够更加敏捷、高效、可靠。容器的 build、ship、run 的理念及其技术特点，更够更好的与 CI/CD 技术进行融合，从技术手段上保证项目管理方式和管理理念的真正有效落地。同时容器云平台提供代码构建、镜像打包、服务快速部署、灰度发布、自动伸缩、负载均衡等持续交付工具链，大大简化了持续集成、测试和发布的过程。使开发者专注业务的开发和测试无需关注运行环境和运维，加速应用的快速迭代和上线。

跨平台

容器可运行在多种云平台环境中，目前支持容器的 IaaS 平台包括但不限于亚马逊平台（AWS)、Google云平台（GCP）、微软云平台（Azure），企业无需担心应用和第三方云平台绑定。并且实现对企业已有异构基础资源的统一化管理，屏蔽环境差异性。实现应用多云混合部署，降低系统运维难度。

提高资源利用率

容器是基于操作系统的轻量级虚拟化技术，多个容器可以共享操作系统的内核进程和内核资源，从而有效节省操作系统级资源开销。容器具有资源隔离与限制的能力，可以精确地对应用分配 CPU 和内存等资源，保证了应用间不会相互影响。并且容器云平台将资源进行池化管理，按需分配、快速调度、环境隔离和及时回收，改变企业 IT 资源使用方式，提高整理利用率。

应用资源积累

镜像仓库可集中式存放、管理企业的业务应用镜像，并且很好的分发到不同的环境进行部署。业务应用镜像经过安全扫描、部署测试等流程化审核后，可将业务应用镜像进行售卖和运营。并且容器云平台内置应用商店，可将社区容器化应用、常用中间件等一键部署，减少对非业务组件的研发和维护。

总体来说，就是可以解决环境平台问题，降低耦合度，快速迭代交付，还可以提供资源利用率，实现自动化运维，所以建设容器云平台很有意义。

PaaS平台和SaaS应用市场的关系

大家有没有发现一个现象？10年以前，SaaS应用市场是非常少的。现在各大平台都会有自己的SaaS应用市场。出现这种现象的原因无外乎技术的进步，搭建SaaS应用市场的成本降低了。更确切的说：SaaS应用市场是PaaS平台的一种外延。在底层PaaS技术的支撑下，SaaS应用的开发、交付、运营的门槛大幅度的降低了。

基于PaaS平台构建的SaaS应用市场会逐步加快SaaS应用生态的发展，有了PaaS平台帮我们解决底层平台的问题，那么我们的应用开发者要怎么做才能开发出云原生应用呢？

  • 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
  • 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
  • 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
  • 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
  • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

下面我们一起来看看具体包含哪些要素：

基准代码：一份基准代码，多份部署
依赖：显式声明依赖关系
配置：在环境中存储配置
后端服务：把后端服务当作附加资源
构建，发布，运行：严格分离构建和运行
进程：以一个或多个无状态进程运行应用
端口绑定：通过端口绑定提供服务
并发：通过进程模型进行扩展
易处理：快速启动和优雅终止可最大化健壮性
开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同
日志：把日志当作事件流
管理进程：后台管理任务当作一次性进程运行

PaaS的未来发展

先抛一个结论：PaaS是云的未来。

IaaS是一个资源转售的生意，PaaS代表了云计算的未来，PaaS解决的是平台架构的问题，同时也是真正做到按需付费。对于业务客户而言，底层技术不会给他们带来直接的业务价值，这也就决定了软件开发商更应该聚焦在业务层。高并发、高可靠、存储服务、应用自身维护等和业务不直接关联的平台服务都可以借助PaaS技术来完成。现在的创业团队可以借助各类PaaS技术快速的创建高并发、高可靠的应用，未来这种模式也会进一步普及。

更融合的调度 物理机、虚拟机和容器各有优势，一个复杂的应用场景会用到各计算平台的优势，融合调度未来必然会成为主流框架。

更融合的编排 说到调度，就离不开编排。当前阶段上云是大趋势，私有云加公有云的模式会长期持续。那么融合的编排框架也必然会成为解决成本问题的一个重要选择。

更细粒度的弹性 IaaS解决了基础设施的弹性，但是还不够。技术的发展会进一步细化弹性的粒度，往更节约的方向发展。

更高的资源利用率 当前的技术及架构下，计算资源很大一部分时间都是闲置的。以有限的资源来应对更高的数据处理要求，资源利用率会随着云技术的发展进一步提高。