REVIEW
2018年11日、日活の成長の喜びをもたらし、万人を破るために、だけでなく、ハイテクドイツのビジネスの人々の挑戦をサポートするために、ドイツの高DAU。システムの安定性を確保するために、どのように、どのようにシステムを確保するためには、信頼性の高いサービスをユーザーに提供し続けることができますか？すべての人々が高いドイツの技術が直面している問題が、また、みんなと一緒に問題を解決する必要があります。
高いドイツの事業規模
サポートDAU億ドイツのサービスがどのような高体重のですか？誰もが同じではありません答えることが、ここではインフラの面で簡単になるように皆のために、我々は、オンラインアプリケーションの数千人が十数千台のマシンの中で全国の複数の部屋に配備されています。
このマップは、高い道徳的なリンクアーキテクチャのコアビジネスは、ドイツの高いビジネスは非常に高い複雑性を有する図からわかるようです。もちろん、この写真は、ドイツの高全体のビジネスフォームを表現するためにあれば、実際のシステムは、はるかに複雑な図が示すよりも、あまりにも一方的、ジグソーパズルの一片に等しいです。
そのような大規模な、非常に複雑なシステムでは、システムの安定性を保護するためにどのように、人々が直面して解決し、高いドイツの技術の長期的な問題です。
サポートは、安定性を意味し、
システムの安定性を確保するために、どのように、ほぼすべてのインターネット企業が直面しなければならない問題です。一般的に言えば、5は理論的には、すなわち、システムの安定性を保護するために意味があります。
- キャパシティプランニング：前回のトラフィック操作に基づき、将来の予測トラフィック（通常は大きなプロモーションは、休日を予定）。全体の流れでは、各サブシステム容量の推定サイズに基づいて成立する必要があります。サブシステムの容量、その後は、システムの適切な展開に必要なリソースの量を計算します。計算は単純に以下の式のように表すことができます。
機械=容量/シングル能力+バッファー（冗長性のある量）の推定数
- フロー制御：フローシステムは、設計容量を超え防ぐために必要であるが、限定デザインの流量を超えています。各事業にも機能が制限されているサブサービス、ダウングレードのための過負荷サービスを超えて流れている必要があります。
- ディザスタリカバリ：システム致命的な障害たら、多数のユーザーへの損傷を引き起こす避けるために、災害復旧の部屋にトラフィックを切り替える必要があります。
- 監視：サービス、状態のリアルタイム制御システムのすべての側面を監視するために、タイムリーな警告システムの問題は、その早期発見と早期治療を生じます。
- 運動計画：災害時の顔でのパフォーマンスに連動してシステムをテストするためのシステムは、包括的なプレビューを行うための問題に直面する可能性があり、断線の手段、停電などの災害シミュレーション。
5つの魔法の安定性の保証で、我々は後ろに座ると、それを緩和することができるかどうか？答えは残念です、ここでは厳しい現実の2つの例があり、彼はあまりにも楽観的ではないと、私たちに警告しました。
一年前の春祭りの前夜に、私たちは、高い道徳的なコアは、圧力試験を結ぶ必要があり、圧力試験の設計フローは、春祭りのトラフィック予測よりも高くなっている、システムが一度に好調、指標が要件を満たしています。しかし、春祭りの間、サービスが何らかの理由で警告を発行したが、現時点では水ラインのトラフィックは我々の期待を超えませんでした。
特定の年月日中の別の時間は、サービスが再び警告を発行し、早期警戒と春祭りが同じでないことを理由。
サポートの当社の安定手段は、達成するために、認知システムに基づいていますが、現実の世界では、多くの場合、マインドマップで認識されているモデルや実際のシステムのスナップショットです。多くの場合、真のシステムの状態と観測システムに基づいて、我々はあまり一貫性の観察、測定モデルは、システムにはあまり正確になる傾向があり、私たちは畏敬の念を維持したいです。システムシミュレーションは辛抱強く、システムの真の状態に限りなく近い、永遠の追求です。
セキュリティの安定性の上に働いて、理論的には、唯一の圧力の下でシステムを保証することができますが、真の流れが入るかを決定することはできません、どれだけシステム！
したがって、我々はあなたが先に到着の実際のトラフィックをする必要があり、運動する必要があります！
リンク圧力測定
先に到着の実際のトラフィックを取得する方法？私たちは、完全なリンク電圧の測定値を使用する必要があり、その後、完全なリンク電圧がそれを測定何ですか？
私の理解では、次のとおりです。完全なリンクの圧力測定は二つの部分の実行に分割されます。まず、全体のリンク、一つの圧力測定値は、それぞれ、理解します：
- 完全なリンク2つの層を意味し、1つのトップダウン、システムの要求を介して完全なパスを。第二は、ユーザーが全体の一部を支払うことなどをショッピングカートに参加する、商品、商品の選択を閲覧するにはログインするなどの一連のアクションのコレクションです。高いドイツの事業については、我々は最初の完全なリンクに焦点を当てています。
- 圧力測定：システムの安定性を試験するための質量シミュレーション、徐々にシステム圧力の手段によってユーザーの行動。
グループの同志は「最終兵器」は非常にイメージとして完全な圧力試験にリンクしています。それは「最終兵器」であるので、それは高地ドイツ語のための十分な抑止力を持っている必要があり、目的は以下のとおりです。システムの安定性をテストするために、実際の環境で実際のトラフィックを提供します。
これは3つのキーポイントが含まれています。
- 実際のトラフィック：現実の世界に近い流れの大きさと特性。
- 実環境：直接オンライン環境。
- アドバンス：ピーク時のトラフィックの到着前に。
これらの3点が、本当の意味での運動とみなすことができるか、それは完全なリンク電圧測定呼び出すことができます。
リンク全体の圧力測定が直面している高道徳的な挑戦
高地ドイツ語フルリンク電圧の測定は、分散システムに固有の課題に加えて、多くの側面に挑戦する、高圧デリンクは全体の尺度はまた、事業の特殊性の課題に直面しています。
分散システムの特徴
- 不確実性
私たちは、交通秩序、真の流れがランダムかつ不確実であると信じています。
- ジッター
そこ世界理論スループット要求量の関数であり、それは次式のように表すことができます。
スループット= F（負荷）
他の要因からの干渉がない場合、システムが飽和する前に、要求された量とスループットとの関係が線形であるべきです。この理論モデル内部の現実の世界が表示されますすることはほとんど不可能です。なぜ？ジッタので。そこに振るのはなぜですか？ネットワーク、ディスク、およびその不確実性からです。
- 待ち行列システムの特性
私たちのビジネスが処理されるのを待って、システムへの単純な抽象キューイング・システム、左からランダムに要求することができた後、処理は、キューを残す右から、完成されています。システムが飽和していない場合、ユーザを扱うことができるシステムが飽和状態に近く、良い要求とキューと、待ち行列の長さが大きく、平均応答時間を増加させることができると要求が増加するように表示され、あるいは要求の一部であろうタイムアウト。システムは、理論的1000q / sで扱うことができるため、異なる流量、次の可能な状態（特定のシステムの測定）の場合：
図からわかるように。
- 2倍の増加要求到着率、キューの長さは約60倍に増加します。
- システムが飽和状態に近づくと、依頼者からの少しの変化は、システムに大きな影響となります。0.95から0.99へのリクエスト到着率、キューの長さは40％増加します。
キューシステムの機能は次のとおりです。システムが飽和状態に近づいたときに、輻輳が順番に混雑度を高めた、長いサービス時間につながる混雑します。状況の悪化によって、システムリソース（CPU、MEM）が最終的に排出されます。渋滞やサービス劣化は正の相関を示し、この機能は、最終的にシステム障害を下に着用し、時間の急激な悪化となります。
高いドイツのビジネス特性
ビジネス旅行は、それは多くの要因によって影響を受けることができ、独自の特殊性を持っています。他の要因の中でも特に高いドイツのビジネスに特有の、システムの影響を受ける地域の行動、地形、交通、道路網の密度、季節、天候、政府の活動、。
カーナビゲーションには、例えば、ナビゲーションシステムは、以下の要因によって影響されます。
- 地域：地域の経済発展のさまざまなレベルが矛盾している、人々は異なるものになります車で移動することを選択し、人々の自動車保有率は、経済的に開発された地域で高くなり、自動車での移動頻度の使用が高くなります。
- 地形：山区，城市繁华地区会因gps信号遮挡导致定位不准确，可能被系统认为偏航，从而引发路径重新规划。
- 路况：事故，拥堵，施工，限行，管制 这些路况都对导航服务造成影响。
- 路网密度：导航算法所要求的计算资源和路网的密度有很强的关联，路网越密，路径规划所消耗的cpu资源，内存资源就会越大，同时计算的时间也会越长。
- 距离：路径规划的距离越长，导航算法对计算资源的要求就越高。
- 季节&天气：人们的出行行为和季节也会呈现相关性，如 五一，端午 人们可能集中前往景区旅游。十一，春节 人们可能会集中返乡。这样在导航行为上就会出现导航距离分布不同的情况，不同的导航距离对服务的要求会不一样，越长距离的导航对服务资源的要求越高。
- 政府活动：交通管制，修路，限行等等。
对于高德而言不能单纯的通过放大流量来对系统进行压测，在流量构造阶段我们需要考虑到流量的特征，考虑到所有影响服务行为的因素。
高德全链路压测平台的自建起因
身在阿里，说起全链路压测，首先想到的肯定是大名鼎鼎的Amazon平台，Amazon 诞生于2013年，自2013年起，Amazon一直作为淘宝、天猫稳定性保障体系中神一般的存在。经过多年的发展和演进，Amazon平台已经日臻稳定和成熟，在施压能力，链路治理，数据构造，用户模拟方面已经做到极致。
所以，在落地高德全链路压测的时候，首先考虑的就是借助Amazon平台。经过充分的调研和部分项目的试用，我们发现Amazon平台并不能满足我们的要求。
Amazon平台诞生于淘宝，作为淘宝，天猫稳定性保障体系中重要的成员。Amazon 追求的是超高的施压能力和极强的平台稳定性。另外，淘宝的双11，双12全链路压测是多团队合作的项目，一次全链路压测可能需要数百人的参与，对于这种超大规模的全链路压测项目，成败的关键在于团队的合作。平台需要搞定的是人无法搞定的事情，对于Amazon来讲，要做的就是把事情做到极致。
高德的全链路压测流量的要求远远不及淘宝的全链路压测，并且通常全链路压测的周期都不会太长（通常在2周左右，这个时间还需要缩减），所以我们比较关注压测成本的问题，例如压测数据的构造成本，压测资源申请的成本，错误排查成本，以及便捷性方面的问题，例如压测过程的可视化，压测报告等。
另外，高德的日常环境的压测需求比较旺盛，除了全链路压测外，我们还需要借助别的平台（如PAP，PAS）来满足日常的压测需求。
从成本收益的角度出发，最终我们选择自研压测平台来满足高德的全链路压测需求，以及日常的压测需求。
高德压测平台的自建思路
如何打造一款全新的压测平台？
回答这个问题，先要回答平台的目的是什么。高德压测平台的目的是什么？一定是为了解决业务的问题！结合上文对全链路压测的描述，对高德业务特点的描述，我们建设压测平台就需要回答这几个问题：
- 如何保证场景的真实性？
- 线上压测，如何保证压测流量不影响线上用户，如果保证压测数据不污染线上数据？
- 如何构建超高流量？
- 如何降低使用成本？
- 如何降低资源成本？
如何保证场景的真实性
压测要保证真实，需要在压测场景上做到全覆盖，需要从协议支持和用户行为两个方面来满足场景的真实性。
- 协议支持：
对于高德服务而言，不同的用户场景使用到的通信协议不一样，例如PC端主要是http协议，而移动端则是accs协议。因此全链路压测的场景设计上首先需要满足对全协议的支持。 - 用户行为：
除协议外，场景构造还需要考虑到真实场景的用户行为，目前的做法是使用线上日志作为原材料，对日志进行过滤，整理，最终形成标准化语料文件，这样可以在一定程度上保证压测数据的真实性。这种低成本的做法，只能借助业务同学的经验去保证。人总会出错，因此未来在场景真实性保障方面不能仅仅依靠人的经验，平台需要通过技术的手段，通过模型，依靠机器去保证。
线上压测，如何保证压测流量不影响线上用户，如何保证压测数据不污染线上数据？
为了保证压测流量不影响线上用户，不对污染线上环境，首先要做的是：链路上的各系统，中间件需要做到对压测流量进行识别，具体而言需要如下步骤：
- 接入鹰眼
- 使用集团的中间件（集团的中间件都支持压测流量识别）
- 业务改造（结合鹰眼对压测标进行透传，对于某些业务可能需要在业务层面对压测流量进行过滤，如对三方系统的调用需要替换成mock方式）
除此之外，还需要有完备的监控手段，在发现服务问题（如系统中发生限流，降级，RT突然增高等等）时，及时的止损。
如何构建超高流量
对线上服务的压测，需要构造出超大规模级别的压力。这需要大量的施压机器共同努力才能达到。要达到验证服务稳定性的目标，全链路压测就需要具备构造超大规模压力的能力。我们目前的策略是自建分布式Jmeter施压集群，依托于Aone的快速部署和便捷的扩容能力来迅速的满足压测流量的需求。
如何降低使用成本
- 压测引擎：以往高德线下的压测属于工具形式，大家使用Jmeter对被测服务进行压力测试，负责压测的同学都对Jmeter比较熟悉。考虑到平台使用的成本，和工具转平台的便捷性，我们使用Jmeter作为TestPG的压测引擎。
- 快速压测：高德有非常多的单链路压测需求，而且服务的接口数量比较少，也比较简单。对于此类型的压测需求，平台需要提供开速开始的能力，简化语料->场景->任务的标准化流程。
- 压测数据管理：全链路压测使用的压测数据（语料文件）的大小达到数十G，文件的存储和分发对系统的设计而言都是不小的挑战。目前采取的做法是使用OSS来存储压测数据，通过一定的策略和算法在施压机器上对语料进行预加载。
如何降低资源成本
高德每年会进行两次大型的压测（春节和十一），其他时间如：清明，五一，端午视各业务线的情况而定。在大型压测时，需要大量的压测资源（几百台，4C16G），而平时少量的压测资源（几十台）就足以满足日常的压测需求，因此在压测资源的管理上要保证灵活，需要时快速满足，不需要时释放，避免资源浪费。
目前TesgPG提供两种施压集群扩容的方式：一是使用Aone部署，通过Normandy平台进行快速扩容（pouch）；二是支持用户自主提供压测机，技术方案是使用Docker + StarAgent 方式来实现施压机的自动部署。
压测资源调度：除了支持全链路压测外，还需要支持日常的压测。对于不同的压测，系统在设计上要满足多租户，多任务的需求，在压测资源的管理方面做到按需分配（目前是人工评估）。
高德压测平台的自建目标
- 短期目标：
支撑高德全链路压测。
为高德所有服务提供线下压测的能力。
- 中期目标：
成为高德线上系统稳定性的试金石。 - 长期目标：
产品化，服务于集团的更多业务。
高德压测平台架构与特点
高德压测平台架构
- 高德压测平台业务架构
- 高德压测平台技术架构
高德压测平台特点
- 极速压测：
对于大部分简单压测需求，TestPG提供极速压测的能力，只需要填写被测服务地址，设定压测必须的url，请求类型，请求字段，QPS，压测时长等信息，就可以开始压测。对于初次使用平台的用户，平均15分钟即能上手压测。 - 调试能力：
TestPG平台提供两种调试手段：挡板调试和服务调试。
- 挡板调试：请求不会发往真实的服务，施压机作为调试挡板，对语料格式，url格式，请求参数进行校验。
- 服务调试：平台将压测请求（默认20条请求）发往真实的被测服务，并详细记录请求的上行数据和下行数据，格式化后，通过平台展示给用户。
调试的目的式帮助用户调整压测的参数，为正式的压测做好准备。
- 错误定位辅助：
TestPG平台会详细记录压测过程中出现异常的请求，对请求的上行数据和下行数据进行格式化保存，用户可以在压测过程中通过平台查看异常日志，定位错误原因。 - 详细的压测报告&基线对比：
TestPG平台在压测完成后自动产出压测报告，压测报告详细包括本次压测的整体、各场景、所有接口的QPS，RT，最大、最小RT，百分统计RT，错误请求数量，错误请求率。并且还包含压测时的实时QPS ，RT图表，以及被测服务的基础监控数据。
此外，压测报告还支持基线对别，若设定了基线报告，后续产出的压测报告都会和基线进行对比，在报告中就会体现出服务性能的变化。压测报告的详细信息可以查看下文平台展示中压测报告部分。
高德压测平台展示
压测看板
调试
错误排查
压测报告
高德全链路压测的实践
2018年十一是我参加了高德全链路压测，当时团队的同学一起聚在稳定性保障会议室里，对高德的核心链路进行了为期两周的全链路压测。
高德的全链路压测流程是比较传统的方式，下图是历年全链路压测的大致流程：
高德压测平台的现状
高德压测平台从2018年开始启动，经过大半年的发展，已经成功支持了高德2019年春节全链路压测，2019年五一全链路压测，在施压能力方面达到百万级别。
目前高德压测平台包括语料生产，场景构造，压测资源管理，压测任务调度，压测过程监控，压测调试，压测错误排查，压测报告生成，压测报告评估（对比基线，从QPS，rt，cpu，mem这几个维度进行压测结论的评估）等功能。
平台从2018年底投入使用至今，共执行几千次的压测。通过开放api的方式，平台开放压测能力，现已成功和持续交付平台打通，为持续交付提供可靠的性能指标。
自春节后，平台主要致力于降低压测门槛，提升压测效率。对于大部分简单的压测需求，从原有的语料->场景->任务逐级构造模式简化为一键压测模式，在初次使用平台成本方面，简单的压测工作预计能从平均3小时，减小为平均30分钟。
虽然高德压测平台在近一年的时间里，取得了一些成果，我们也支撑了几次全链路压测。但是我们的全链路压测还不能完全满足上文的三个要求，其中最关键的场景真实性还无法得到保证，"全链路压测" 对于高德来说，还是远方，我们还有很多路要走，还有很多困难要克服。
高德压测平台的未来
在可见未来里，我们期望在以下几个方面去探索和实践：
全链路监控
TestPG目前的监控是基于用户自定义链路的监控，在链路真实性上无法得到保障。未来我们将会与运维团队合作，打造基于EagleEye链路自动梳理的全链路监控。除了基本的系统指标监控功能外，TestPG平台还会在下面的几个方面进行探索：
- 监控大盘，全面的展示系统的状态
- 短板机器，短板服务的识别
- 基于时间序列的性能问题挖掘
- 结合邮件，钉钉等手段，对发现的问题进行及时的报警
简化语料生成流程
目前压测语料的生成采用的是用户自定义脚本的方式。平台定义好语料目录格式，语料文件格式，用户编写语料处理（一般以日志文件为基础）的程序，然后上传到平台。平台会执行用户提供的程序，然后在将程序的输出文件存储在OSS上，以备压测之用。
这种方式降低了平台的实现成本，也给用户提供了足够灵活度，但是增加了语料的处理门槛。未来我们会将这部分工作全部交由平台来处理，用户只需要提供原材料，配置生成规则即可。
丰富压力模型
TestPG平台目前的压力模型是Jmeter原生的，为了最大限度的接近真实场景，在压力模拟上，我们还需要具备如下几种压力模型：
- 步进施压
- 抖动施压
- 脉冲施压
压测置信度评估
压测场景能否代表真实的用户场景？这是一个TestPG目前还无法回答的问题。场景的真实性现在依托于业务同学的经验，业务同学按照自己抽象出来的业务模型对原材料（通常是线上日志）进行处理，生成平台规定格式的预料文件。语料对平台和用户来讲，都是黑盒子，除了被测系统外，没人知道语料的模型是否接近真实世界的用户场景。
因此，我们期望通过一些技术手段来对压测场景的真实性进行一个科学的评估，这便是压测置信度评估。置信度评估的目标是评估压测的场景和我们期望的场景相似度，下面是压测置信度评估需要探索的方向：
- 建设场景特征库（例如五一，十一，春节）
- 基于特征库的压测场景置信度评估
- 基于地理位置的压测场景置信度评估
- 基于链路覆盖度的压测场景置信度评估
- 基于流量模型的压测场景置信度评估
结合上述维度的评估数据，我们可以给出一个具有价值的评估报告，作为一个重要的参考，可以帮助用户评估压测的效度。
链路改造
TestPG平台的中期目标是要支撑高德业务的全链路压测，成为高德系统稳定性的试金石。但现在我们离真正的全链路压测的距离还很远，我们的压测场景只覆盖了读请求，还不具备支持写请求压测的能力，原因是系统还不具备全链路流量识别的能力，还不具备隔离压测流量的能力。未来，全链路压测，全场景覆盖是必经之路。
关注高德技术，找到更多出行技术领域专业内容