背景：公司接到私有化项目部署，由于没有各个微服务的真实能力，往往项目经理拉会开发评估需要的资源，但是没有测试数据支撑，导致评估的资源往往到线上真实使用量高太多，客户经常抱怨给的服务器资源使用的并不多，所以组织这次压测，目的是得到各个微服务的能力及全链路合理的资源配比（以实时在线通话2000为例）。
什么阶段的公司搞全链路压测
微服务的架构。
需要架构组，得有Mtrace的这种微服务RPC消息跟踪体系架构，能改中间件。
各部门能配合全链路压测调试及部署，运维的机器资源部署。
简单性能测试要通过，即单点的性能测试要没问题。
有更高的技术追求。
什么时间搞全链路压测
压力小的白天就行，要错过高峰期，这也是得益于数据隔离，服务器隔离。
压力大的一般凌晨进行，要错过高峰期。
谁来搞
肯定不是测试，也不是一般的性能测试工程师和测试开发工程师，基本上是一个研发团队在搞。
据说美团的压测平台前身也是测试开发工程师搞的，推广的也不错，在美团趟出了一条压测的路，但是存在了不少有待改进的地方。后来种种原因，平台移交给了开发团队，现在看起来，平台的压测性能、可用性等各方面有了很大的提升。不是说测试开发的同学做不了，而是效率和速度确实还是有差距的。开发同学的效率和速度就是特别大的优势，能加班，可以快速的让产品成型并且快速迭代。
1.梳理某项目所有微服务，服务架构，实现方式，调用关系，线上环境的请求配比（后续做测试数据、编写测试脚本等需要）；
2.梳理服务间调用用到的协议，为后续压测工具选型最准备，本次压测设计到freeswitch、unimrcp、http、grpc协议，由于市面上没有哪款压测工具支撑上述各种协议，最终决定用locust压测，最大好处，能支持二次开发，可以自我实现各种需求
准备环境1.根据需求量和原有的数据大概评估一下服务器，分析哪些服务耗内存，哪些耗cpu....
2.部署相关服务，监控（grafana + prometheus），部署需要的各种exporter (服务器、服务、中间件、locust等)，由于locust本身压测数据不是持久化，prometheus提供了exporter来收集locust压测数据后展示到grafana-参看以往的博文
3.6台服务器、近50个微服务
压测策略1.先压出单个服务的能力（不限制QOS,被压服务和压测脚本单独部署）
2.根据单个服务的能力和各个微服务的QPS的比率关系，合理配比副本数
3.全链路压测，对资源使用进行微调
压测过程1.由于压测涉及到大量的音频传输，先测试压测服务器的io读写速度
2.从最底层服务开始压测服务能力，不限制QOS，加大压力看QPS、响应时间、内存、cpu、磁盘io、网络io、各连接数...的使用情况,找到压力拐点为止。
3.压测次底层服务，优先增大依赖的服务能力（通过副本数或资源增大等），有些微服务只做了代理，能力太强，考虑用mock服务代替后面依赖的微服务（mock服务能力要考虑后面服务的真实能力，随机sleep一段时间）
4.重复2-3步骤，压出online核心服务的处理能力。
5.根据单服务的能力，分析2000在线通话对各个服务的资源使用情况，需要考虑全链路的压测场景，单位时间内几轮对话对请求影响比较大
遇到问题1.测试发现，当压力上去time_wait的数量会持续增大，同时释放的速度又小于新创建连接的速度，就是导致time_wait状态持续过多，这样会导致部分连接无法创建，现象表现为电话打不通，通过修改tcp_max_tw_buckets=50000，tcp_fin_timeout=10s两个系统参数解决上述问题
2.有几个重要服务要占用大量rtp端口，当部署到同一台服务器上，会导致资源抢占厉害，分配的端口也可能给sipp和一些系统服务产生冲突导致无法注册，所以通过调整部署方式和可用端口段解决上面问题
3.压力上去后，某些中间件连接数不够，服务异常后因为无法连接而重启失败
4.某些微服务也是采用了容器里的默认参数，调整后能力大幅提升
5.ELK占用大量资源。。。。
6.。。。
压测结论1.部署方式很重要
2.要善于结合系统参数进行调优（参考How Can I View and Modify Kernel Parameters of a Linux ECS?_Elastic Cloud Server_FAQs_Network Configurations_Others_HUAWEI CLOUD）
3待补充。。。
