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

我们之所以监控缓存，是因为我们发现有时候应用层Key使用的不对，或者是配置的不对，会导致缓存层失效，请求就会直接打到数据库，导致请求相对比较的慢。对于缓存的监控，我们在缓存的客户端的jar，会和配置中心进行联动，监控某些我们认为相对比较重要的Key，当Key出现缓存丢失，写频繁，或者写丢失等类似这种事件的时候，它就会上报到我们的监控系统。这个时候，就会发现导致缓存失效的程序Bug。

第二步：如果应用层没有问题，则检查异常流量

如果我们确认应用层的确没有问题，就需要开始往下层去进行怀疑了。

首先第一个比较怀疑的是，是不是出现异常流量。比如说有外部的异常流量，可以问问网管和安全部是否网站被DDoS，另外入口网关是否接受到了大量的请求，例如有临时的促销或者临时的事件。

如果入口没有问题，则查看集群的监控，要对照着两个指标看，一个是服务端的请求数目的一个统计，看是否有集中的热点，比如说一个集群有多个副本，其中某个副本收到的请求量特别的大，而其他副本收到的请求数相对比较低。二是在云主机里面的网卡虚拟网卡，也是能够看到相应的监控的，看是不是网络流量就集中到某几台机器上。这两个会有一个对照，如果两方面指标能够对照起来，集中热点比较容易定位，也即请求数上去了，同时云网络的网卡流量也上去了。当出现了热点的时候，就需要通过服务治理中心或者配置中心，将请求打散。

如果两个指标不匹配，这时候就有问题了，也即服务端请求的数目其实并没有多，但是云网络发现出现了问题，这时候就就可能是底层基础设施的问题，我们这个例子遇到这个点就是相对比较诡异，还需要接着解析。

如果不是异常流量，就需要从前往后再来梳理这个事，比如说从核心交换机到VPC的网关区域这些是不是出了问题，这时候就要联系机房的网管部门去定位，然后是VPC网关到云的负载均衡，然后是从负载均衡到应用的API网关，然后API网关到应用的Controller层，然后是中间的dubbo调用，然后缓存层到数据库层。接下来要按照整个链路依次的去排查。

这里画了一张经比较经典的机房的一个图，其实任何一家公司机房的样子要比这个图可能要复杂得多，这就需要架构部门对机房的架构相对比较清楚。

我们会分机房，分可用区，还会分二级可用区，他们会走不同的汇聚交换机，在监控系统里面也要标明某个服务器群和另一个服务集群之间的访问到底是哪个物理机集群到哪个物理机集群之间的访问，这时候你心里可能需要清楚他们是否在同一个机架里面，或者是在同一个二级可用区，还是在同一个一级可用区，是跨机房了，或者是甚至到异地了，这时候你要心里有个数，因为他们之间的时延都是不一样的。

第二个就是对于VPC网络的架构是要比较清楚。我们是通过OpenStack Neutron的vxlan去做的这个事情的。横向流量是通过vxlan，基于OVS去做的，纵向的流量，出去的时候会有网关，我们不是用的物理网关，而是虚拟网关，在数据中心里面有一个虚拟网关的网关层，网关层有的时候是挂在汇聚交换机下面的，有的机房要求吞吐量比较大，网关层可以直接挂在核心交换机下面的，很可能网络瓶颈点会发生在这些网关上。

我们的VPC网络是有一定的改进的，因为我们要求一个VPC里面能承载的虚拟机的数量要比开源的OpenStack要多得多，能达到5万台的规模。

限制网络规模的一是广播问题，我们可以事先把整个网络拓扑下发到一个拓扑库上去，每一个节点上的Agent会订阅拓扑库的更新事件，从而更新本地的OVS策略。每个Agent都会看到整个网络的拓朴结构，则ARP的时候，本地就可以拦截来进行返回。

另外的一个改进就是虚拟网络，默认的虚拟网关只能做主备，横向扩展能力没有这么好，不能够承载大的并发量，这其实需要有一排的虚拟网关，全部挂载到汇聚或者核心交换机上。接下来的问题是纵向的流量怎么从这一排网关里面去选择，这里使用了一致性哈希的算法。

（编辑：衡阳站长网）

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