梗概

Kubernetes相比传统的集群管理方式，表现出更多优势，因而国内互联网公司也都已经大规模使用 Kubernetes。

Kubernetes 拥有大量的用户群体和落地实践，做为生产环境的编排系统在成熟度和稳定性上已得到业界的认可。对于开发工程师来讲，把服务部署到k8s中，将会是运维工作的常态。

把服务迁移到K8S集群之前，需要对服务本身进行一些升级，对K8S进行适配。本文对升级过程中的一些常见问题，以及注意事项进行总结。

把服务迁移到K8S的意义是什么？

先说K8S有哪些特性呢？依据官方文档，有自我修复、弹性伸缩、自动部署和回滚、服务发现和负载均衡、机密和配置管理、批处理等特性。

这些特性无疑解放了开发工程师运维服务器集群的人力，可以把节省出的精力投入到系统设计、编码开发等价值更高的工作当中。

不要只看收益，不看风险。

K8S带给我们诸多收益的同时，也要注意到K8S给我们带来新的问题。

容器漂移

容器漂移是最常见的问题。容器在一台机器关闭，然后再另外一台机器上被启动。发生容器漂移的原因有滚动发布、物理机故障被回收、手工关闭容器、K8S集群进行碎片整理等。

容器漂移会给系统带来的负面影响有，节点一段时间内不可用、IP地址变化、缓存丢失、临时数据文件丢失等。

资源碎片

总有机器的一部分小块资源被闲置，却又不能满足有大块资源需求的服务。资源碎片会影响K8S集群的机器利用率，严重时会影响服务的发布。

资源隔离不完善-IO不能隔离

目前容器技术，没有实现对磁盘IO的资源隔离，因此同一宿主机上如果存在两个磁盘IO密集型的服务，有很大概率会相互影响。

尽管当前的容器技术已经实现对网络IO资源的隔离，但是可能受限于K8S的版本，以及公司内部CICD系统不提供对网络IO隔离的设置，因此对于网路IO资源密集的服务，部署到K8S时也要谨慎处理。

不能隔离的 IO 类型有：

• 内存带宽
• 网络带宽
• 文件带宽

root权限

一些服务会调用只能root才有权限访问的接口，比如mlock。这些服务如果迁移到K8S，需要重新进行设计，因为公司里的CICD服务往往不会允许k8s中的容器以root用户运行。

系统调用失效

物理机和容器里面的接口发生了很大变化，举例说明：

• CPU核数，获取物理机器核数的接口要替换成获取容器CPU核数的接口
• 可用内存大小，获取物理机器内存大小的接口要替换成获取容器内存大小的接口

集群机器性能差异

k8s集群中，服务器可能来自不同厂商，采购的新旧型号不同，配件性能也可能会有差异。尤其不同cpu型号的性能差别巨大。而K8S不能把这种性能差异对应用变得透明。

一般方法是：

• 添加机型约束
• 把资源量化，比如1core 等于100算力（K8S暂未实现此功能）。

把服务迁移到K8S之前需要做哪一些升级？

支持容器化运行和部署

K8S本身就是容器的编排系统，所以服务要能在容器中运行起来。需要编写Dockerfile或docker-compose.yaml文件来实现编译镜像。

服务本身要具有良好的可伸缩性

服务本身需要具有容错机制，其上游也要有失败访问后的重试。除此之外，服务检测、坏点摘除、服务发现，也是必不可少的，所以需要把服务接入名字服务。

支持日志的集中采集

不同于传统的运维方法，我们难以进入每一个容器来查看进程的运行状况。把服务要接入日志中心的系统，在日志中心查阅、追踪系统状态是最好的选择。

监控指标集中上报

和把日志上报到日志中心的原因相同，把服务的监控指标，上传到监控平台/系统。而且为了减少依赖，尽可能使用SDK通过网络的方式上传监控指标，避免通过采集容器内日志文件的方式上报。

数据分片

对于一些数据分片的服务，需要有一个统一的分片管理模块。

可用性

K8S集群不总是可用的，我们在设计服务时，就要考虑对服务进行同城双活、异地多活等方式的部署。为了保证服务的可用性，把服务部署到同城不同K8S集群或者异地不同的k8s集群当中。

其他的注意事项

服务的日志自动清理，不然宿主机的磁盘会被用满，引发故障。

使用分布式文件系统来共享文件，比如ceph、OSS等。

程序异常时产生的coredump文件保留下来，以便排查问题。

自动弹性扩缩容

这是k8s的一个能大大节省运维工作，以及提升资源利用率的功能。

但自动弹性扩容在某些场景下会影响服务的可用性。以故障的灾后恢复为例，有问题的服务，被上线后，CPU负载降低，被自动缩容；问题修复后，开始重新扩容，扩容服务的时间可能是漫长的（可能加载内存数据慢、可能机器较多），服务不可用的时间也会变长。

总结

K8S也是一把双刃剑，一方面把开发工程师从繁琐的运维工作中解放出来；另一方面如何运维部署在K8S上面的服务，K8S较传统方法有较大的不同，开发工程师面对K8S这个新工具，要不断学习和总结。

背景和意义

目前团队对图搜业务使用的服务器的磁盘IO性能没有量化的数据，不能准确把握服务器的磁盘IO性能。

同机型机器的磁盘IO性能表现并不相同，在磁盘IO性能表现差的机器，往往存在故障隐患。

因为不能准确把握服务器的IO性能，对图搜引擎能否支持多少业务量时，不能做出准确评估。在运维团队系统的过程中，会存在不可预知的风险，最终导致系统故障。

机器预算收紧，把索引全部加载到内存的方案暂时无法推行，在图搜引擎检索过程中引依然有磁盘IO操作。对磁盘IO测试仍有重要意义。

测试目标

• 测试现有机型机器的磁盘IO性能（日常、极限）。
• 对测试新型存储介质的性能，建立测试方法。
• 针对图搜业务，建立服务器磁盘IO性能基线标准。

有了磁盘IO性能基线标准，有如下好处：

• 在系统扩容的过程中，对加入集群的新机器，做磁盘IO性能准入测试，降低线上环境的硬件故障发生率。
• 以后引入新型服务器，在评估其性能时，做对比和参照。
• 在搭建新的图搜服务，预估系统可承受的最大业务量时，可以做为参考依据。

测试方法

测试方法分析

图搜搜索引擎磁盘IO读写特点

对于图搜搜索引擎，主要有三种IO操作，分别是随机读、顺序写和顺序读。

• 随机读

图搜引擎在提供线上服务时，磁盘IO操作主要来自于读取磁盘中存储的正排字段， 随机存储于正排索引文件当中。

• 顺序写和顺序读

顺序写和顺序读，分别为索引同步和索引加载这两个过程中的磁盘IO读写特点，频率为1天各执行1次。

索引文件打开方式主要为mmap

测试注意点

针对图搜引擎操作磁盘时的IO特点，在做磁盘IO性能测试时需要注意下面几点：

• 测试随机读、顺序写和顺序读三种读写情况，重点是测试随机读的磁盘IO性能。

• 随机读测试中，文件大小要到500G,并做96路并发测试。每次读写块的大小为4k

• 要使用mmap方式打开文件。

• 在测试的过程中，要排除linux cache机制的影响，只对磁盘IO性能进行测试。

测试指标

重点关注在3种磁盘读写方式（随机读、顺序写和顺序读）下的IO指标：

名称备注
BW平均IO带宽
IOPSInput/Output Operations Per Secondlatency响应时间complete latency完成延迟
CPU CPU使用率

测试工具

FIO 2.1.10
top/vmstat

测试步骤

测试步骤注意要点

• 相同的测试必须测试3遍，并记录下每次的测试结果数据。
• 每组性能测试的时间不能少于60秒。
• 测试前检查服务器上的应用进程，关闭无关进程，减少无关影响。

具体测试步骤

以测试服务器 x.x.x.x 的磁盘IO性能为例：

• 关闭所有无关进程。
• 下载编译和安装FIO。
• 编写fio job文件
• 此fio job文件，包含3个job，分别是随机读、顺序读、顺序写。
• 执行测试命令
  ./fio fio_jobs.ini

测试结果如下：

• 解读并记录测试结果。
• 测试结果分析方法
• 对照手册，解读FIO的测试结果。
  

  如何建立图搜引擎服务器磁盘IO性能基线标准

对目前拍立淘图搜引擎使用的机型，依据本文的方法做性能测试。并统计磁盘IO性能测试结果。

对各个机器磁盘IO性能测试结果中，剔除误差数据，取中位统计结果做平均值为IO性能基线标准。

参考资料

• http://freshmeat.sourceforge.net/projects/fio/
• ./fio –help
• https://blog.csdn.net/sch0120/article/details/76154205
• http://www.361way.com/linux-cachestat/5894.html
• http://www.brendangregg.com/blog/2014-12-31/linux-page-cache-hit-ratio.html

内容梗概

• 从简单到复杂，推演后台服务的底层通信框架的进化过程，包括网络IO模型、多线程模型的选择和组合。
• 推演的最基础模型是IO同步阻塞+单线程模型，然后逐步进化。推动网络框架进化的3个因素是，每秒请求量的增大，并发量的增大，逻辑计算量的增大。
• 本文使用的底层通信协议以TCP为基础，因此所有推演方案不考虑适用于UDP的信号驱动模型和适用于于文件操作的异步IO模型。
• 只考虑同步阻塞、同步非阻塞、IO多路复用。
• 本文不讨论多进程和多线程的区别，在提高cpu利用率上，这两个模型的作用是一致的，因此本文只选择多线程模型进行讨论。
• 本文主要讨论单机网络通信框架的设计演化，不考虑分布式场景下。本文各项性能对比指标也仅指单台服务器的性能。

推演之前，需要一些系统相关数据支撑。

现有的硬件条件，2017年：

• 单台服务器处理网络连接请求数，每秒约10W量级。
• 单机并发处理网络长连接数上限在10W左右（C100K）。
• CPU 单核，3000MHz，一台服务器以24核计，单核每秒亿次运算。
• 抛离单次请求的网络处理过程，单核每秒处理每个请求的业务计算量在0-10000W之间。

最简单的网络通信模型， 同步IO阻塞+单线程

此模型是我们推演的基础模型。

适用场景，最简单的网络请求、处理和返回。每秒处理请求量低，并发处理请求数只有1，计算量小。系统硬件、网络IO都不会构成瓶颈。

实例，各类demo、模拟后台服务的测试服务、大型系统中开发的调试接口、数据接口、监控接口。

开始推演：

1. 假如处理单个请求的计算量不变（依然很小），但请求量增大，并发量增大，网络IO成为瓶颈，这种模型是不能满足需求的。因此需要使用 IO多路复用 + 单线程模型。

2. 假如 请求量、并发量不变，但是处理请求计算量变大，单核CPU成为瓶颈，这种模型也是不能满足需求的。此时需要使用 IO阻塞 + 多线程模型，利用CPU多核提高计算能力。

3. 假如请求量、并发量变大，而且处理单个请求的计算量也变大，这种模型更是不能满足需求，但此种情况比较复杂，下面需要详细论述。不过一般情况下也可以使用 IO多路复用 + 多线程模型。

IO同步阻塞 + 多线程

使用这种模型，则是计算量变大，单核CPU往往成为瓶颈，必须使用多核来提高计算能力，但并发度低。数据举例，24核CPU处理每秒处理请求数小于1W，并发度小于24，请求量小于1000/s。

实例，各类 FastCGI 后台服务、php-fpm，用于机器学习模型计算的服务，图像处理服务。

开始推演：

IO同步阻塞 + 多线程，并发度受限于线程数，不适合处理并发，一旦并发量变高，则网络模型应该改用IO多路复用。

IO多路复用 + 单线程

使用这种模型，请求量大，并发量大，但处理每个请求的计算量小。数据举例，qps 5W以上，并发数高，但单核cpu每秒处理也在5W以上。

实例， redis和memcache的网络模型。

IO多路复用 + 多线程

经过上面的推演，IO多路复用 + 多线程模型应该是推演过程的终点。既能处理大量请求，又能提升并发度，提高CPU的利用率解决计算量大的问题。

实例， 大型网络应用。

总结

无论选择什么样的模型，最终的目的就是提高服务器硬件的利用率，并避免资源浪费。

选择合适模型，必须依据其所在的业务场景，根据请求量、并发量、计算量这个3个指标，选择合适的模型。

问题总结

1. 为什么不是所有情况都选择IO多路复用 + 多线程模型，IO多路复用 + 多线程解决了高访问量、高并发、计算量大的业务？

主要是因为在一些非高访问量、非高并发、非计算量大的业务场景下，IO多路复用 + 多线程是一种过度设计，容易造成资源浪费。

1. 为什么同步IO非阻塞并没有在推演过程中使用？

   非阻塞的编码，会让代码逻辑复杂，一般不会使用。

猜想假设

memcached这种系统的瓶颈在网络，不在计算和存储，而使用多线程，只能优化计算。用了多线程，反而会有上下文切换的代价。

测试概要

测试目标

让 Memcached 分别采用 单线程模型 和 多线程模型， 并对其性能进行对比

测试方法

测试软件

实验组 Memcached 1.2.2 （IO 多路复用 + 单线程）

对照组 Memcached 1.2.2 （IO 多路复用 + 多线程）

Memcached 1.2.2 是 Memcached 众多版本中的一个临界版本，在Memcached 1.2.2 之前的版本采用 “IO 多路复用 + 单线程” 模型， 在Memcached 1.2.2 之后的版本则采用 “IO 多路复用 + 多线程” 模型。

测试工具

memslap 1.0

测试环境

• 软件 Ubuntu 15.10
• 硬件 Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz 4核 2G 内存

测试步骤

搭建

• 编译 memcached

先编译单线程的 memcached 版本。(正常编译，作为实验组)

再编译支持多线程 memcached 的版本（作为对照组）， 编译方法如下：

修改configure.ac文件，将下面一行

AC_DEFINE([USE_THREADS],,[Define this if you want to use pthreads])

改为

AC_DEFINE([USE_THREADS],1,[Define this if you want to use pthreads])

执行 sh autogen.sh , 然后执行 ./configure --enable-threads ,最后执行 make

• 分别运行 实现组和对照组的memcached， 然后对其进行基准测试

命令示例： memcslap --servers=localhost:11211 --concurrency=5000 --execute-number=10 --tcp-nodelay --non-blocking --flush

–concurrency=5000 –execute-number=10 这两个数据多次选型，反复测试。

实验结果

选取典型实验结果数据

• 实验组 （单线程）

• 对照组 （多线程）

实验推导结论

从上面的实验结果看，单线程的性能要比多线程性能略高。

本文测试用的kestrel版本是2.4.1

下载

• 下载官网已编译的包

  wget http://robey.github.com/kestrel/download/kestrel-2.4.1.zip
  unzip kestrel-2.4.1.zip

• 下载源代码自行编译

环境配置

Java 的运行环境配置为1.60版本，以保持兼容

修改配置文件

修改 config/development.scala 和 config/production.scala，一个是开发环境，一个生产环境的配置

监听的IP和端口

队列持久化路径

queuePath = "/home/liuzuocheng/var/spool/kestrel"

日志目录

loggers = new LoggerConfig { 
    level = Level.INFO handlers = new FileHandlerConfig { 
        filename = "/home/liuzuocheng/var/log/kestrel/kestrel.log" roll = Policy.Never 
    }  
}

修改启动命令

生产环境启动脚本scripts/kestrel，将APP_HOME目录修改为实际目录地址

APP_HOME="/home/liuzuocheng/local/kestrel"

运行kestrel

调试环境启动脚本

sh script/devel.sh

生产环境后台启动kestrel服务，使用如下命令

nohup .script/devel.sh &