很多公司技术支持岗位的工作，如配置域名，部署环境，修改复位配置，服务重启，扩容缩容，梳理和完善监控，根据开发的需要查找日志等工作，需要和开发进行大量的沟通，如什么是外网域名，什么是内网域名、A name、C ...

很多公司技术支持岗位的工作，如配置域名，部署环境，修改复位配置，服务重启，扩容缩容，梳理和完善监控，根据开发的需要查找日志等工作，需要和开发进行大量的沟通，如什么是外网域名，什么是内网域名、A name、C name，防火墙规则该如何设定，操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点，导致沟通困难，效率很低。而且这样的需求还很多，把运维压的喘不过气，占用了几乎所有的时间，但是开发的需求可能还是迟迟不能满足。

这样的公司可能遇到了以下问题：

系统架构过于陈旧，性能、可靠性无法满足现有的需求；
原有IT架构不灵活，业务模块新增或变更带来巨大成本压力；
系统功能繁杂，结构紊乱，定制的代码与系统耦合性极高；
服务种类繁多，各种技术栈横行；
人员流动交接不充分，新接手的团队对部署环境不了解，只能做周边的修补，不敢迁移。

如何才能解决？答案是流程化、标准化、自动化、平台化。

流程化

即主动梳理运维工作任务，形成标准化的操作流程，尤其是针对需要多人协作完成的任务，比如应用的发布部署，把流程固化到流程平台系统中，保证每个人执行都能按照流程严格执行，不会有哪些环节遗漏，而且当前的流程状态对所有人都可见，能清晰的看到谁正在处理，处理人也会更主动尽快的完成该任务。

标准化

从架构角度按照应用类别制定应用的部署标准，比如Web类型的应用，服务化的应用（我们内部用的.NET Core），或者是比较新的微服务的应用（.NET Core等），部署脚本和工具平台按照约定好的规范进行设计开发(基于Kubernetes)，减少了因为应用种类繁多导致工具和平台的复杂。

自动化

很多公司早期写了非常多的脚本，任务执行机到要执行任务的服务器之间通过SSH免密钥认证，再根据需要批量执行命令。随着服务器规模和应用数量的扩张，很快脚本执行的方式无法满足业务发展，难以理解，同一个类型的任务多个脚本并存，存在误操作，缺乏清晰的操作历史记录和回滚机制，即使后续替换了如Puppet，Saltstack，Ansible这样的配置管理工具，但根本问题并没有解决。

平台化

平台化一定要在前面三条的基础上进行建设，如果没有清晰的流程，明确的标准，平台建设起来也只是自动化工具的集成，解决不了公司核心问题。

以下说的平台化内容主要是PaaS平台化，即主要从应用和中间件的角度，这里不讨论IaaS的内容。

PasS平台化将问题的关注点从基础资源上升到了应用层面，目标是提供一个帮助开发人员运行、管理应用的平台，让使用者更关注运行的代码（业务逻辑）。
PaaS能解决的问题：

应用聚合：如开发需要一个Redis，直接启动一个Redis容器即可
服务发现、快速伸缩、状态管理等
服务监控、恢复、容灾
安全管控：不管什么平台，安全都非常重要，例如A应用可以访问B,B不允许访问A以及安全审计等。
快速部署。

随着Docker容器技术的出现，让我们有了更合适的工具建设PaaS平台，具备了基于应用构建服务的能力。在Docker容器调度框架上，我们自然选择了Kubernetes平台。Kubernetes具有资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA等。Kubernetes的核心是如何解决自动部署，扩展和管理容器化（containerized）应用程序。

下图是一张最小化的PaaS 架构图：

最上面的Ingress服务跟传统的负载均衡器的功能类似，提供请求分发的功能,分为两类：对外提供API服务的API网关以及对外提供服务的站点,对外的API网关采用Ocelot 进行开发，Ocelot完成了对Kubernetes的集成工作，这个功能已经在我们的平台上工作一段时间了，上个月把代码合并进入Ocelot主干，已经可以通过Nuget包下载，具体参见 kubernetes 客户端KubeClient使用及常用api。
Service相当于后端Pod的一个代理服务器，Service需要通过Ingress服务才能被外部Client访问, Service 提供了服务的注册和服务发现。
Pod则相当于我们传统的一个服务。
最小化PaaS平台还用到了DNS组件，在内部服务运行起来之后，我们会通过DNS组件分配一个内部域名供访问时使用。

Kubernetes 选用腾讯云 TKE ，TKE 服务在集群内默认启用了基于腾讯云负载均衡器实现的 l7-lb-controller，支持 HTTP、HTTPS，同时也支持 nginx-ingress 类型，可以根据业务需要选择不同的 Ingress 类型。

平台关键能力说明

应用持续部署，平台实现快速、可视化自动部署功能。支持对应用的快速、可视化部署。用户仅需在界面中选择相应的镜像和组件，并填写简单的配置信息，点击部署按钮，即可完成整个应用的安装或者升级。
应用弹性伸缩，构建具有需求预测和容器按需供给能力的弹性伸缩子系统，具有基于应用的负载和资源情况进行弹性伸缩能力，以应对互联网用户高并发的特点，应对流量冲击。其中，包括容器弹性伸缩、物理机弹性伸缩功能。
容器和组件的统一管理，从整体应用的角度出发，平台不仅管理镜像和容器，而是将一个应用涉及的所有组件均做了统一管理，通过对系统相关组件和容器统一管理，平台将可以实现系统的全局统一部署、配置、升级/回滚、监控、故障处理等功能。
高可靠性，容器的故障恢复，当服务器宕机时，平台系统会自动在其它服务器上重新启动容器并为其分配资源，从而达到秒级启动，恢复业务。保障业务不掉线，高可靠运行；
应用Docker化封装，系统支持如下几类常见应用：.NET Core、Jexus、Nginx、Redis、Mongodb等。

PaaS平台功能组件

具体实施时，主要有几个基础组件需要开发：

镜像管理，实际运行的应用镜像由 “基础中间件镜像”+“应用包”+“配置” 自动构建，借助于Visual Studio 2017/2019以及Visual Studio Code，以及微软开源的Helm、Draft，通过标准化内部培训，让开发人员快速理解镜像概念和制作镜像以及开发流程；
DNS管理，定制化公司内部使用的DNS管理平台，对公司的DNS进行统一管理；
服务管理，需要定制化一套Kubernetes的Deployment模板，从Ingress到Service再到RC都定义在这套模板里面，方便对容器进行扩容、缩容、删除操作；
服务内Pod管理，属于Kubernetes自有范畴，查看Service内的Pod运行情况、Pod日志输出等功能；
日志管理，将日志输出到公司的日志平台（如ELK平台），对接研发人员排查问题、数据埋点使用；
监控管理，参考方案：cAdvisor + InfluxDB + Grafana/ Heapster + Grafana/Prometheus/Zabbix：https://www.cnblogs.com/Cherry-Linux/p/9144650.html。

虽然我们属于创业公司，我们相信技术的力量，技术帮助我们实现业务的持续健康发展，从发展的初期就规避很多公司的一些困境，一个中小企业做成这样后，日常运维的工作量即可大量减少，两三个人就能完成日常的应用运维工作，有兴趣地话可以去挑战一下。当然做完这些后，还只是一个小型的PaaS平台，我们基于腾讯云的TKE 平台构建这样一个小型的PaaS平台。
如果是再复杂一点的PaaS平台，应该还有哪些要继续做的呢？环境管理：即一套平台管理多套不同的Kubernetes集群、安全管理、流程管理、计费管理等功能模块。还有因为规模增加和更高的可靠性要求，对应的网络，IO等各种优化。其实还有很多功能就不一一列举了，可以根据自己的实际情况添加功能模块，设计有自己公司特色的PaaS平台。

相关文章：