伴随着公司业务的快速发展，公司很多业务线的服务架构以及服务运行时环境也有了很大变化。之前的资源管理和应用生产流程主要是半自动化，不管是服务器相应的资源利用率还是技术人员的个人生产力仍然有很大的提升空间。

　　一、运维面临的痛点

　　1、业务的扩展，团队服务器资源也越来越多，我们常常会听到这样的声音：“我的服务器怎么又卡死了?”、“我点击开始构建后项目就一直502了?”“帮忙看看，某某项目怎么又挂掉了无法访问了，我正在测试呢?”

　　2、在代码管理方面，没有较好的命名规范，代码仓库没有友好的UI界面进行管理，我们常常需要对照一个或多个复杂的excel表格来找到那些不常使用的或者近期未开发的项目代码;

　　3、本地手工打包，手动创建虚拟机，手工部署和升级，这些重复和低效率的研发部署模式导致开发人员不能高效的专注于业务需求;

　　4、线上业务在运行时会出现并发问题，根据怎么样的指标、怎样去对业务进行扩缩容?业务迁移如何更为高效、准确和快速;

　　5、在之前项目的运行环境中，我们使用了Rancher1.6版本及其自带的Cattle作为我们的容器平台。由于rancher对docker容器的进一层封装，常常会出现很多问题，例如网络为什么不通了?dns为什么无法解析等等，这种类似问题的根本原因不得而知。

　　二、问题分析

　　首先想到能解决其中代码仓库管理的办法就是将原有代码仓库迁移到更为强大的git上，并且制定统一的规范准则。

　　其次大部分问题的解决办法最容易想到的就是通过脚本来帮我们做一些手动重复性的工作。没错，在前期我们写了很多脚本，不同服务的运行环境随着命名的规范也会变得更加统一。但是在需求没办法确定的情况下，如何评判脚本的好坏与完整性却没有思路，我们只能做到的是脚本如果遇到某个bug那就去改一个版本。

　　至于Rancher，我们发现在1.6版本之后便丢掉了原有的编排引擎，转而拥抱的是更为强大的Kubernetes。因此我们决定抛弃Rancher，使用更为原生的Kubernetes容器编排。

　　三、解决方案

　　目前，Kubernetes已经成为市场上事实上领先的容器编排工具，不仅对技术公司如此，对所有公司都是如此，因为它支持快速且可预测地部署应用程序、动态地伸缩应用程序、无缝地推出新特性，同时有效地利用硬件资源。

　　如何用好Kubernetes?应用如何迁移到k8s?对相应技术人员是一大挑战，因为它更为原生，没有像Rancher提供的在界面上更为便捷的操作。

　　最终我们基于现有服务器环境，自建了多套原生且高可用的Kubernetes集群

　　应用的改造方面，调研并使用了Minio分布式对象存储，优化统一了应用配置方法和日志输出规范

　　应用的迁移与DevOps工作流的实现，基于Jenkins2.X版本开发了多套更为便捷的流水线，真正实现应用的部署通用参数选择、一键快速部署、回滚、扩缩容等更为强大的功能

　　至今，公司超过80%的项目已经全部迁移且稳定运行在新环境下，回顾过去一年多的成果，为我们带来了诸多好处：

　　自动化的集成解放了大量的重复性劳动

　　更快的交付效果和更快的发现并修复问题

　　减少了等待时间与人工错误

　　更为持续、稳定的运行环境

　　。。。。。。

　　四、下一步规划

　　畅想未来，在容器化技术及 Kubernetes 统一的时代，企业应用也逐步向微服务架构转变，这中间包含着服务注册、服务发现、服务网关、配置中心、集成框架、分布式事务等等。随着“云原生”这个概念的诞生和落地，我们会将更多的工作与业务相结合，实现更多更好更强的服务发布方式，根据更多的数据指标和服务中链路的追踪来进一步优化业务，最终实现业务的快速迭代、自动部署、独立高效。