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

一般来说，性能问题往往通过线上性能压测发现的。一般大促之前，提前一段时间，就要开始进行压测。压的时候就会涉及到从前往后，从底到上的所有的系统和部门，都要派代表去参加，哪一块出现了问题，哪一个环节出现了性能瓶颈，哪一块就要改。

线上压力测试需要有一个性能测试的平台，做多种形式的压力测试。例如容量测试，通过梯度的加压，看到什么时候实在不行。摸高测试，测试在最大的限度之上还能承受多大的量，有一定的余量会保险一些，心里相对比较有底。再就是稳定性测试，测试峰值的稳定性，看这个峰值能够撑一分钟，两分钟还是30分钟。还有秒杀场景测试，限流降级演练测试等。

有的时候压测会遇到让人崩溃的事情，例如可能前几天压测的时候，看着吞吐量在向好的方向发展，突然有一天一下子就降下来了，这个时候离大促时间越来越近，心态就会比较崩溃，需要大家一块去看到底是什么问题。

对于测试环境的管理，也是非常关键的。线上压测的时候，为了让数据和正式的线上数据实现隔离，常用的方法是对于消息队列，缓存，数据库，都是使用影子的方式。就需要流量染色的技术，带一个tag进去，说明这个请求是测试数据，还是真实数据。

流量染色的功能，除了压测里面使用，还可以用于测试环境治理。在大规模微服务场景下，不可能每个部门部署一套完整的环境，因为耗费的资源量实在是太大了。

这时候就需要合理规划测试环境。测试环境是应该和持续集成的流程紧密协作的。我们使用分支开发的方式，每个功能的开发在分支上，上线的时候，合并到主分支上来，主分支对应线上环境。

对于测试环境的规划，也是采取类似的思路。我们会有一个基准测试环境，对应master分支，里面部署全量的应用。每一个分支，比如说你修改了五个工程，测试的时候，不需要部署全量的应用，只需要把这五个工程去创建一个Delta测试环境就可以了。当客户端进行测试的时候，带上一个此分支的tag，从API网关开始，微服务框架嵌入的jar会将这个tag一直带下去。当这五个服务之内相互调用的时候，微服务框架就会选择这五个服务的实例进行调研，如果需要调用五个服务之外的其他服务的时候，微服务框架会到master环境里面，选择服务实例进行调用。

（编辑：西安站长网）

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