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

接下来，我们来解析一个微服务场景下的问题定位过程。

为什么说在微服务场景下，我们发现定位问题的时候，我们会觉得它特别的复杂，往往需要架构师牵头协调各个部门一块去定位某个问题。

首先第一个复杂度就是，从顶层到底层这个层次是实在是太多了，我们能想到就是任何一个比如说我们发现请求比较慢的时候，我们首先会想到整个层次中，最上面的应用是不是出了问题，应用这一层本身就比较复杂，图中密密麻麻的线是double服务之间的一个调用关系，它的复杂度已经十分高了，然后中间一旦出现了慢请求，这时候其实很难定位到一哪一个点，哪个服务集群调用哪个服务集群。

应用层下面这就是容器层，容器下面其实是openstack的云网络，我们采取方式是kubernetes和openstack整合的一个方式。因为kubernetes对于容器的发布，运行十分友好，对于网络尤其是多机房高可用横向扩展的vpc网络特性相对弱一些，那么正好云在VPC这方面相对比较强一些，例如浮动ip，跨机房高科用，专线等。容器层或者云网络层，都可能产生问题，例如容器网卡吞吐量受限制，或者ovs吞吐量受限制，都会造成性能问题。

再往下是物理网络，因为牵扯到多机房了，那么可能每机房还有多高可用区，那么整个机房的拓扑结构逻辑也会很复杂。

这时候就可以想象说当一个服务的多个副本构成一个业务集群，当从一个业务集群到另一个业务集群时延高，每个层次都其实都有可能出现问题是吧?然后我们就需要层层的去排查这个事情。

另外一个相对比较头疼的一个事，是从前端到后端的层级也是挺多的。问题往往是在压测的时候会发现，那么压测的时候，我们是在我们公有云上去压真实线上的业务，所以其实是走公有网络的。

我们可以想象，从前端到后端经历的环节实在是太多了，你比较难判断他会慢在什么地方。

一开始进入机房，有边界路由器，然后有核心汇聚交换机，这是网管部去管的。

接下来就进入了虚拟的云网络网关，由云计算部门维护。

云网关进来后，会有一层负载均衡，这个负载均衡是可以适配多机房的负载均衡，可以做跨机房浮动IP漂移。

再往里面会有个API网关作为接入层，然后再往后就是服务层了。服务层分业务服务层和基础服务层，之间会引入注册发现机制，比如说用dubbo管理他们之间的相互调用。由于微服务规模比较大，就像刚才图中展示的一样，复杂度很高。

业务之间调用完毕之后，最终肯定是要落库的，这时候会涉及到缓存的访问，缓存后面是数据库。

有时候还涉及到调用云外的系统，因而需要经过云网络的网关。比如说外部的一些支付系统，安全检测系统，包括大数据等，都是云外的。这两次网关其实是不一样的，前面网关是DNAT网关，后面网关是SNAT网关。

（编辑：西安站长网）

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