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

如果需要细致的分析，可以登录到宿主机上看KVM，分析KVM的性能的瓶颈在哪里，在虚拟机里面进行网络监控之外，在宿主机上可以对虚拟网络的组件进行分析，测试两个集群之间的虚拟网络组件是否出现了问题。

分析完了网络和存储虚拟化，接下来看计算虚拟化KVM。可以做一些定制化的一些调优，比如说CPU的BIOS中会把C-States和P-States这种节能开关关掉，如果是核心业务集群，不需要打开这些开关。

另外就是物理CPU和vCPU的绑定，这是为了解决steal的问题，如果把核绑到虚拟机上，基本上就不会存在VCPU在物理CPU之间切换的问题，就会把steal解决掉。

另外是NUMA亲和性的问题，在同一个NUMA Node中，CPU对内存的访问就会快一些，跨NUMA node就会慢一点，分配的时候尽量是同样CPU和同样的内存放在同一个NUMA 节点。

虚拟机网卡可以通过SR-IOV的方式来进行优化，云主机绑定核也是在grub中设定好，一台机器上面能起多少个服务，给宿主肌留多少核，给监控留多少核，然后最后给应用留多少核，都是提前规划好的，例如前几个核是给宿主机自己去用的，然后几个核是留给DPDK去用的，最后几个核是留给监控去用的，中间的核留给服务。

对于限流策略问题，基础设施层和业务层有一个配合的问题，底层的网络有QoS流控的，业务其实也有限流的，这两个值要匹配起来，否则会有问题，比如当业务层把线程数调大的时候，结果基础设施层被限流了会出现丢包。

当我们从监控里面看到有丢包事件的时候，业务层会怀疑是虚拟网络的问题，丢包了以后TCP会重传，重传会使得响应比较的慢。

在没有定位到到底哪个环节丢包的时候，可以先做如下的处理。为了使TCP的丢包重传和流控策略不要用默认的策略，也即一旦出现了丢包，内核协议栈就认为网络拥塞，从而减少拥塞窗口，这时候本来就想加速重传，结果窗口下来了，想加速也加不上去。如果切换成BBR，出现丢包的时候就会好很多。

但是我们还是就要看底层的网络，网络包会丢在什么地方。

最后实在没有办法，就需要登到物理机上去debug整条链路。从集群A到集群B中间抽出两台机器进行测试。测试完毕后通过tcpdump进行分析虚拟机和虚拟机之间的情况，通过ovs-tcpdump可以分析两台物理机上的OVS之间的情况，物理机之间的链路可需要进行分析。如果包的数目比较多，需要写程序比对时间戳序列号。

抓包分析之后，我们发现两个集群之间并不是任何两两个服务之间都会丢包，而是发生在两个集群全部在某一批汇聚交换机出现。

原来从来没有怀疑过是物理硬件的问题，物理交换机的监控网粒度往往不会非常细，而且有堆叠这种高可用策略，在监控调整到分钟级别的时候，看流量根本就没有达到上限。

但是一旦我们发现出问题的两个集群总是要过某一台汇聚交换机的时候，我们就建议网管，你能不能把那台的监控配置到秒级，然后就发现问题了，就是分钟级监控没有超过它的瓶颈，但是秒级的监控就会发现它瞬时流量是超过了瓶颈的，因而会丢包。原因是部署缓存集群的时候，实例过于集中了，两个集群之间的交互基本上都集中在同一个汇聚交换机上，导致出了问题，接下来的方式就是把网络优化型的实例打散了以后，只要流量瞬时不会超过物理交换机峰值，基本上就没有问题了。

这个例子最后有一点狗血，其实这是一个分析思路，从应用层逐渐的去分析，架构部就要协调各个层次，最后才把这个事情定位到好，我今天的分享就到这里。

（编辑：常州站长网）

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