所以，在落地高德全链路压测的时候，首先考虑的就是借助Amazon平台。经过充分的调研和部分项目的试用，我们发现Amazon平台并不能满足我们的要求。
Amazon平台诞生于淘宝，作为淘宝，天猫稳定性保障体系中重要的成员。Amazon 追求的是超高的施压能力和极强的平台稳定性。另外，淘宝的双11，双12全链路压测是多团队合作的项目，一次全链路压测可能需要数百人的参与，对于这种超大规模的全链路压测项目，成败的关键在于团队的合作。平台需要搞定的是人无法搞定的事情，对于Amazon来讲，要做的就是把事情做到极致。
高德的全链路压测流量的要求远远不及淘宝的全链路压测，并且通常全链路压测的周期都不会太长（通常在2周左右，这个时间还需要缩减），所以我们比较关注压测成本的问题，例如压测数据的构造成本，压测资源申请的成本，错误排查成本，以及便捷性方面的问题，例如压测过程的可视化，压测报告等。
另外，高德的日常环境的压测需求比较旺盛，除了全链路压测外，我们还需要借助别的平台（如PAP，PAS）来满足日常的压测需求。
从成本收益的角度出发，最终我们选择自研压测平台来满足高德的全链路压测需求，以及日常的压测需求。
高德压测平台的自建思路如何打造一款全新的压测平台？
回答这个问题，先要回答平台的目的是什么。高德压测平台的目的是什么？一定是为了解决业务的问题！结合上文对全链路压测的描述，对高德业务特点的描述，我们建设压测平台就需要回答这几个问题：
如何保证场景的真实性？
线上压测，如何保证压测流量不影响线上用户，如果保证压测数据不污染线上数据？
如何构建超高流量？
如何降低使用成本？
如何降低资源成本？
如何保证场景的真实性
压测要保证真实，需要在压测场景上做到全覆盖，需要从协议支持和用户行为两个方面来满足场景的真实性。
协议支持：
对于高德服务而言，不同的用户场景使用到的通信协议不一样，例如PC端主要是http协议，而移动端则是accs协议。因此全链路压测的场景设计上首先需要满足对全协议的支持。
用户行为：
除协议外，场景构造还需要考虑到真实场景的用户行为，目前的做法是使用线上日志作为原材料，对日志进行过滤，整理，最终形成标准化语料文件，这样可以在一定程度上保证压测数据的真实性。这种低成本的做法，只能借助业务同学的经验去保证。人总会出错，因此未来在场景真实性保障方面不能仅仅依靠人的经验，平台需要通过技术的手段，通过模型，依靠机器去保证。
线上压测，如何保证压测流量不影响线上用户，如何保证压测数据不污染线上数据？
为了保证压测流量不影响线上用户，不对污染线上环境，首先要做的是：链路上的各系统，中间件需要做到对压测流量进行识别，具体而言需要如下步骤：
接入鹰眼
使用集团的中间件（集团的中间件都支持压测流量识别）
业务改造（结合鹰眼对压测标进行透传，对于某些业务可能需要在业务层面对压测流量进行过滤，如对三方系统的调用需要替换成mock方式）
除此之外，还需要有完备的监控手段，在发现服务问题（如系统中发生限流，降级，RT突然增高等等）时，及时的止损。
如何构建超高流量
对线上服务的压测，需要构造出超大规模级别的压力。这需要大量的施压机器共同努力才能达到。要达到验证服务稳定性的目标，全链路压测就需要具备构造超大规模压力的能力。我们目前的策略是自建分布式Jmeter施压集群，依托于Aone的快速部署和便捷的扩容能力来迅速的满足压测流量的需求。
如何降低使用成本
压测引擎：以往高德线下的压测属于工具形式，大家使用Jmeter对被测服务进行压力测试，负责压测的同学都对Jmeter比较熟悉。考虑到平台使用的成本，和工具转平台的便捷性，我们使用Jmeter作为TestPG的压测引擎。
快速压测：高德有非常多的单链路压测需求，而且服务的接口数量比较少，也比较简单。对于此类型的压测需求，平台需要提供开速开始的能力，简化语料->场景->任务的标准化流程。
压测数据管理：全链路压测使用的压测数据（语料文件）的大小达到数十G，文件的存储和分发对系统的设计而言都是不小的挑战。目前采取的做法是使用OSS来存储压测数据，通过一定的策略和算法在施压机器上对语料进行预加载。
如何降低资源成本