PaaS平台的意义
很多公司技术支持岗位的工作，如配置域名，部署环境，修改复位配置，服务重启，扩容缩容，梳理和完善监控，根据开发的需要查找日志等工作，需要和开发进行大量的沟通，如什么是外网域名，什么是内网域名、A name、C name，防火墙规则该如何设定，操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点，导致沟通困难，效率很低。而且这样的需求还很多，把运维压的喘不过气，占用了几乎所有的时间，但是开发的需求可能还是迟迟不能满足。
这样的公司可能遇到了以下问题：
-
系统架构过于陈旧，性能、可靠性无法满足现有的需求；
-
原有IT架构不灵活，业务模块新增或变更带来巨大成本压力；
-
系统功能繁杂，结构紊乱，定制的代码与系统耦合性极高；
-
服务种类繁多，各种技术栈横行；
-
人员流动交接不充分，新接手的团队对部署环境不了解，只能做周边的修补，不敢迁移 。
如何才能解决？答案是流程化、标准化、自动化、平台化。
流程化
即主动梳理运维工作任务，形成标准化的操作流程，尤其是针对需要多人协作完成的任务，比如应用的发布部署，把流程固化到流程平台系统中，保证每个人执行都能按照流程严格执行，不会有哪些环节遗漏，而且当前的流程状态对所有人都可见，能清晰的看到谁正在处理，处理人也会更主动尽快的完成该任务。
标准化
从架构角度按照应用类别制定应用的部署标准，比如Web类型的应用，服务化的应用（我们内部用的JSF），或者是比较新的微服务的应用（Spring Boot等），部署脚本和工具平台按照约定好的规范进行设计开发，减少了因为应用种类繁多导致工具和平台的复杂。
自动化
早期写了非常多的脚本，任务执行机到要执行任务的服务器之间通过SSH免密钥认证，再根据需要批量执行命令。随着服务器规模和应用数量的扩张，很快脚本执行的方式无法满足业务发展，难以理解，同一个类型的任务多个脚本并存，存在误操作，缺乏清晰的操作历史记录和回滚机制，即使后续替换了如Puppet，Saltstack，Ansible这样的配置管理工具，但根本问题并没有解决。
平台化
平台化是这次分享的重点，一定要在前面三条的基础上进行建设，如果没有清晰的流程，明确的标准，平台建设起来也只是自动化工具的集成，解决不了公司核心问题。
以下说的平台化内容主要是PaaS平台化，即主要从应用和中间件的角度，这里不讨论IaaS的内容。
PasS平台化将问题的关注点从基础资源上升到了应用层面，目标是提供一个帮助开发人员运行、管理应用的平台，让使用者更关注运行的代码（业务逻辑）。
PaaS能解决的问题：
随着Docker容器技术的出现，让我们有了更合适的工具建设PaaS平台，具备了基于应用构建服务的能力。
在Docker容器调度框架上，我们又选择了Kubernetes平台。
Kubernetes
资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA。
Mesos
Mesos是一个分布式内核，目前的发展方向是数据中心操作系统（DCOS），它同时支持 Marathon、 Kubernetes 和 Swarm 等多种框架，Mesosphere 也是 Kubernetes 生态的一员。
注意Marathon的技术栈是Scala语言，而Docker和Kubernetes的技术栈都是Go语言。
Swarm
从Docker1.12版本开始，Swarm随Docker一起默认安装发布，也由于随Docker引擎一起发布，无需额外安装，配置简单。
支持服务注册、服务发现，内置Overlay Network以及Load Balancer。
与Docker CLI非常类似的操作命令，对熟悉Docker的人非常容易上手学习。
每一种工具都有自己的核心理念
。
Mesos理念是数据中心操作系统（DCOS），为了解决IaaS层的网络、计算和存储问题，所以Mesos的核心是解决物理资源层的问题。
Kubernetes的核心是如何解决自动部署，扩展和管理容器化（containerized）应用程序。
所以，个人认为Mesos和Kubernetes是两种维度，对于我们的场景来说，关心应用的状态多于物理资源层管理，因此更关心的是容器化应用程序管理，这是我们选择Kubernetes的主要原因。
另外选择Kubernetes还考虑了其它优势，如：
再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的，即我们PaaS平台上要运行的典型应用是什么样的。
用户端的请求进来以后，首先进入前端的Nginx服务器，再进入Zuul代理网管上，由Zuul将这些任务下发到不同的服务上去。Eureka集群作为注册中心服务，提供服务的发现和注册的功能。服务后端再去调用依赖的其他服务，数据库集群，Redis集群等服务。
微服务架构因为有注册中心自动解决了服务注册发现的问题，所以对内部服务来讲就不用依赖传统的负载均衡器等工具，很容易将各个服务Docker化，迁移到PaaS平台里统一管理。
平台建设原则
在建设PaaS平台之前，参考《高效人士的七个习惯》设定了PaaS平台建设的原则：
-
以终为始
：做一件事情要知道想达成什么样的目的，知道这个目的之后，就能够围绕这个目标采取一些措施。
-
知己解彼
：作为一个运维人员，需要有一个比较大的知识面。只有如此才能够去制定一些适合自己的方案和产品。
-
积极主动
：因为要做PaaS所以要把自己的主观能动性都调起来。
-
要事第一
：上面说了很多PaaS相关的内容，由于时间、人员的限制。如何从众多的基础组建中挑选出来最重要的一些事情，着手建设。
-
双赢
：做出来的系统最好是能够达到对开发、运维、公司都有利。
-
统合综效
：对待同样的一件事，每个人都会有自己的见解。同时也要问同伴，要把所有的观点都收集起来做一个综合分析对比，以收到更好的效果。
-
持续更新
：时刻提醒自己持续学习，拥抱变化，这样才能看到平台的不足。持续迭代出更好的产品。
基于以上的原则，我们团队勾勒了一个最小化的PaaS图：
-
最上面的Ingress服务跟传统的负载均衡器的功能类似，提供请求分发的功能。
-
Service相当于后端Pod的一个代理服务器，Service需要通过Ingress服务才能被外部Client访问。
-
Pod则相当于我们传统的一个服务。
-
最小化PaaS平台还用到了DNS组件，在内部服务运行起来之后，我们会通过DNS组件分配一个内部域名供访问时使用。
Kubernetes对外提供服务，用的是Lvs+Ingress，每次添加一个新的服务之后会调用一次DNS的API，按照规则生成一个内部域名供访问使用。
平台关键能力说明
