大规模微服务场景下的十大痛点问题定位与优化

另外对于容器和Kubernetes层的整合，网络层也需要整合，容器也要融合VPC网络，只有适配了VPC网络才能实现多机房的高可用性，跨机房的负载均衡，以及跨机房的浮动IP漂移和切换。比如说一个机房挂了，则挂在A机房的浮动IP地址要能够切换到B机房的网关上去，并且和核心交换机有联动，路由也要切过来，这些都只有VPC可以完成这个事情。

我们开发了一个自己的CNI插件去做这个事儿，容器没有使用单独容器网络方案，而是直接用了OVS的网络，也即OpenStack的OVS是可以直接看到容器的IP地址的，容器的IP地址和虚拟机的IP是平的，是属于同一个局域网。

这样其实还有另外一个好处，因为我们还有很多没有容器化的应用，如果部分做容器化，是可以和容器内的应用无缝的打通的。一些有状态的PaaS也是部署在虚拟机里面的，也可以实现在同一个局域网内的互通。

另外一个针对Kubernetes的优化就是规模问题，这是其中的一个优化的例子。

重启一个API server的时候会导致一些问题，尤其是在Pod的数目比较多的时候。通过监控图可以看出，中间会重启时间长达七分钟，中间出现429错误并且飙升，是因为流控。为什么会流控?因为它重启的时候，会有大量的请求重新再连上来，由于并发太多，有可能就把它再冲挂了。

那么应该如何改进呢?方法一就是多级流控，根据UserAgent, Resource, Verb几个参数，对于不同的客户端有不同的流控策略，比如说对于master上面的进程优先级相对高一点，对于kubelet结点上的进程，优先级就低一些。不会所有的kubelet节点一股脑上来进行注册。方法二是拥塞控制，Retry-After参数也即多长时间再重试一次，这个原来是一个默认值，我们改成一个动态的值，根据系统的繁忙程度是调节到1秒到8秒之间，这样不同的客户端重试的时间会错开。使得把整个恢复时间大幅度的降低了，这是我们做的规模化的一个例子。

来我们从接入层开始分析。我们在VPC的网关以及负载均衡层也是做了优化的。

优化之一是基于BGP ECMP的等价路由，也即对于LB集群和前面的核心交换机之间配置等价路由，实现横向扩展和负载均衡。如果使用LVS做这个网关的话，可以使用DPDK技术，也即基于DPVS的负载均衡。

电商请求基本上都是基于HTTPS协议的，SSL往往通过offload的方式通过硬件进行加速，在压力大的时候，优化明显。

对于负载均衡这一层的问题，出问题的点往往在于虚拟网关和负载均衡，

我们要中断看这一层的网卡是不是丢包?

另外就是DPDK的PMD进程的CPU占用率是不是特别的高，因为默认的网卡接收网络包是通过中断通知内核来接收包，但是DPDK进行了优化，它通过主动polling的模式减少中断，它在用户态有一个PMD的进程，他会不断地从网卡里面去polling，会占用大量CPU，如果他CPU特别高就说明接收包的速度本身就很高了。这时候要注意观察流量是否存在热点，流量是否突破单台瓶颈。

对于虚拟网关来说，使用的是一致性哈希的方法选择网关，随着持续的浮动IP的创建和删除，分布不一定均衡，就算IP分布均衡，这些IP对应的业务其实没有那么均衡，例如多个热点请求落到一个网关上。

如果说是存在热点，导致DPDK的PMD进程CPU过高，可以采取的策略是高流量的IP地址可以进一步地打散，重新调整哈希的策略。

另外会观察是否超过单台的瓶颈，我们会测试每台机器的IO的瓶颈，也会进行QoS限流，如果是超过了瓶颈，说明这一台的确压力过大，如果其他的节点网络IO还相对比较低，基本上也是热点问题。如果都高，则说明需要扩容。

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!