下载掌阅APP，畅读海量书库
立即打开
制定好DevOps体系的路径规划后，下一步就是实际落地执行。DevOps是为云原生服务的，云原生的第一步是容器化，从KVM到Docker，全部容器化打响了自如云原生落地的第一枪。
2019年，自如的服务器大概有400台，每个业务线分布不均，而且使用率不均，整体数据在CMDB（Configuration Management Database，配置管理数据库）平台上也没有准确的统计，服务器的使用量和缺口完全是个黑盒，每次做服务器的预算都是一项极其艰难的挑战。
宏观上，微服务的使用率是伴随业务的增长而增加的，针对不同的微服务，运维团队给出了相应的资源使用标准。例如，从环境角度来看，生产环境的应用服务一般建议配置为4C8G，测试环境配置为2C4G，数据库配置为8C32G。
我们分析了一些微服务的资源使用情况，发现CPU使用率基本在10%以下，即便是大数据计算型应用，CPU使用率也很低，不会超过20%；内存使用率相对较高，但也参差不齐，平均在60%左右；硬盘使用率一般。服务以Java微服务居多，是典型的内存密集型服务。具体使用情况如表3-1所示。
表3-1 资源使用情况表
导致资源使用率低的原因有如下3点。
微服务的冷热不均必然会导致调用程度不一样，一个后端应用可能每天只有1位管理员使用，4C8G的配置就会造成浪费。
当时整个公司只有800多个应用，以部门为单位盘点了微服务数量，发现有一个部门居然有120个微服务，微服务数量与业务的重要程度完全不成正比。大约从2016年开始，很多技术团队都开始关注服务解耦，原来1个大的服务被拆成了5个、10个，滥用架构理念导致了微服务的泛滥。
前两个原因是从研发的视角来分析资源使用率低的问题，从硬件革新视角来看，我们都知道摩尔定律，18个月甚至更短时间内，服务器的性能会翻一番。为什么我们的服务器承载的应用量依然没有降低？核心原因还是单机的使用率太低。KVM的虚拟技术限制了单机的潜能，它基本上把一台宿主机的能力根据虚拟机的配置限制在了一个固定的范围内，很难有倍数的提升。
当时自如服务器的第二个痛点是可运维性差，具体表现为两个方面。
标准化程度低会导致两个问题。
第一，对运维人员来说，会有重复而低效的劳动。比如一次线上故障，EMQ（Elastic MQTT）中有一个Topic无法消费消息，而其他Topic都正常，想了很多解决方案都无法解决，最后决定保留现场，重新搭建一套同样配置的EMQ。首先尝试二进制包复制的方式，结果启动后报错；然后尝试官方安装方式，虽然可以正常启动，但是生产者无法连接。后来对比两套环境，发现是由于一个Namespace参数未配置导致的。类似这样的配置问题还有很多，标准化程度过低就会导致零碎的问题分散到服务器的各个角落，无故障时风平浪静，一旦出现紧急问题就会导致运维人员手足无措。
第二，对于研发人员来说，会出现令人迷惑的诡异故障。我们经常会在故障群里听到研发人员反馈，同样的代码为什么在测试环境运行没问题，上了生产环境就问题连连，排除研发侧的合并代码、配置项等问题，很多时候也是由非标准化导致的两端环境不一致所致。
微服务设计理念的普及导致产生大量的微服务。虽然微服务的耦合性大大降低，但是微服务之间的调用关系越来越复杂，调用链路越来越深，原来的整体服务可能是简单的A→B→C链式结构，现在就变成了一个网状结构。
KVM的种种不便和低效，加上云原生的风生水起，使运维团队有了尝试新技术的想法，于是我们开启了云原生的第一步——全部容器化。当然，从传统的虚拟技术过渡到全新的技术栈，要实现全量且稳定的容器化覆盖，的确不是一件一蹴而就的事，我们大概分了两个维度来做迁移，一是按环境迁移，二是按业务线迁移。
从物理上划分，环境包括测试环境和生产环境。大的原则是先做测试环境的切换，测试环境以10%为梯度逐步从0加到100%，验证2个月后，再开始进行生产环境的切换，切换迁移如图3-6所示。
图3-6 环境迁移图
环境迁移时要避免大规模迁移，我们进行业务线切割，按照各业务线进行迁移，迁移计划如表3-2所示。
表3-2 业务线迁移计划
通过一段时间的迁移试点，部分服务从KVM迁移到Docker，研发人员对服务器的使用是零感知的，Docker的覆盖为后续使用Kubernetes进行服务编排奠定了基础。