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

今天我的主题是在微服务场景下的一个性能问题的定位优化，那么今天会讲一个我们其实出现的一个真实的一个场景，然后其实还是花了蛮长时间，然后把这个东西才定位到一个具体的问题。

现在云原生微服务架构特别的火，有非常多的优势，比如说这里面写的快速迭代，高并发，可维护，可扩展，灰度发布，高可用，这些词大家都耳熟能详，这些就不用细说了。

但是微服务不是没有成本的，如果说单体应用的复杂度大概是10的话，上了微服务可能是变成100，可能是十倍的复杂度提高，需要投入大量的人去做这个事儿，并且需要一定的支撑系统和工具链，才能将这些复杂性降下来。

我这边总结了一下微服务实施之后，会大概率出现以下的痛点：

第一：服务依赖的管理，就是一个服务到底调用了哪些，被哪些服务调用，如果依赖管理比较混乱，就会比较痛苦，比如说你要发布一个应用，你可能不知道这个应用被谁依赖了，有没有有一个特别关键的应用在依赖于我这个应用，会不会我升级了以后是否会引发关键业务的不稳定，是应该白天发布，还是凌晨发布，这个时候我们就特别需要希望有一个系统能够看到任何一个服务都被哪些服务依赖以及依赖于哪些服务。

第二：调用统计问题，对于调用记录有一个统计和告警，例如有没有接口突然调用失败率增高，有没有接口突然时延增长，都应该及早发现，而不能因为因为一次发布引入一个bug，导致时延变长但无人知晓，等到流量一来，直接就可能压挂了。再就是有没有接口再也没有人调用，这个接口是否可以下线，这在接口升级的时候，常常采取先添加接口，再下线接口的方式，就需要这样一个统计系统。

第三：接口规范问题，各个团队开发出来的各个服务的接口是否符合统一的接口规范，有没有统一的地方去看接暴露出来的接口?如果说有的接口不遵守规范，那么是不是时候会在同一个地方能看到，然后去尽早的去发现这个问题。

第四：安全管理，很多企业往往通过白名单通过配置中心配到各个服务里面去的，比如说支付这个服务不是所有服务都能调用的，只有部分服务可以调用他。这些配置原来都是散落在这个服务里面去的，各自为站，有可能一不小心就配置错了或者漏了，应该能访问的访问不了，不该访问的能够访问了，但是没有人察觉。

第五，熔断限流降级这些服务治理能力。虽然有很多开源组件可以做这些事情，但是需要写大量重复代码去做，同样是散落在各个地方。

第六，接口测试问题，我们如何保证在不断的拆合的过程中不会引入新的bug，这其实是比较头疼的一个事情，所以需要一个比较大的一个测试集合，就需要一个测试平台来保证。

第七，灰度发布问题，很多公司做灰度发布，都是通过代码里面写if-else做的，当什么条件满足的时候，走这个逻辑，当时什么条件满足的时候，走那个逻辑，这个时候也是相对比较痛苦的。

第八，压力测试问题，这一般是实施微服务的后期，当需要面对大规模流量的时候，才会引入进来的。一开始线上大促的时候，基本处于这种一脸蒙，靠运气的这种状态，心里压根都没有谱，必须要通过压力测试去做这个事儿。

第九，调用链分析问题，一旦出现慢的时候，相对比较难以发现慢的点，尤其是当服务数目多，调用链长了之后。

第十，测试环境治理。服务数目增多了，大家都用了容器，带来的好处就是部署的特别方便，一个编排就能启动一套系统，但是同时也带来一个痛苦，其实我们从云的时候就有这个痛苦，一旦放给大家的权限让大家可以随时部署，对于资源的使用就控制不住了，大家谁都想启动一个新的环境，自己的测试环境和别人都不在一块。如果说只有几个容器，那么每次都重新部署一个新环境，这没有问题，但是如果服务特别多的时候，例如一百个容器的时候，这时候全量部署比较困难。

为了解决这些问题，需要配备比较复杂的工具集合：容器平台负责声明式部署，持续集成和测试平台负责灰度发布和测试集合的维护，API网关负责入口流量的接入，微服务框架负责微服务之间的相互调用，管理和治理，分布式事物负责拆分后的事务问题，APM性能管理负责调用链分析。我们后面也能看到这些组件在定位问题的过程中都起到了什么样子的作用。

微服务的拆分过程并不是一蹴而就的，我们发现很多公司开始计划实施微服务的时候，往往第一个问题是微服务应该怎么拆，应该拆分到什么粒度?觉得是这是一个最重要的一个维度。后来我们发现其实并不是这个样子的，微服务的拆分只是其中很小的一个方面，需要匹配一套工具链，并且经历十二个过程，逐步完成。

（编辑：辽源站长网）

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