この記事では、教師の旗プルPingzhongのシェアを支払うことをDangdangから来ています。
インターネットアプリケーションや大規模なエンタープライズアプリケーションでは、ほとんどが同じくらい7 * 24時間運用可能な限り行うことが、完全に中断のない操作があると言うことができるであることが要求されている「非常に難しいです。」
このため、一般的な可用性のメトリックの適用の程度は3 9-5 9を持っています。
そして、データアプリケーションの量を増加させるための機能は、高可用性と簡単に維持します。高可用性を実現するためには、高可用性、ボリュームの成長の決済を確保し、その探求と実践の多くを行うために、単一障害点からアプリケーション自体を引っ張っ支払います。
外部システムは、ネットワークの問題など、突然の故障を、頼る考慮に入れなければ、大規模なパーティ決済と金融地区等、利用できない、99.999％までのプルサービス容量を支払いました。
この記事では、アプリケーション自体のユーザビリティを改善する方法に焦点を当てています。
アプリケーションのユーザビリティを向上させるためには、最初に行うべきことは避けアプリケーションの障害しようとしているが、完全に故障していないことは不可能です。インターネットは場所で「バタフライ効果」を持っている可能性があり、誰も一見小さな、発生確率はゼロで事故が発生する可能性があり、かつ非常に拡大されます。
私たちのRabbitMQ自体は非常に安定性と信頼性であることをすべて知っているが、有料の引き初めはRabbitMQの中で単一のポイントを使用することであった、と動作不良はその心理的に、我々はこの事は間違って行くことはほとんどありませんだと思うではありませんでした。
一日まで、物理ホストハードウェアが原因で荒廃から切断され、このノードは、RabbitMQのこのサービスを提供することはできませんでした、瞬間的なサービスシステムをもたらすことはできません。
障害が最も重要なことは、問題を発見し解決することであり、ひどいではありません。プル給与独自のシステム要件は、このように、障害によってもたらされるマイナスの影響を軽減、迅速診断とトラブルシューティング、故障秒で発見されました。
まず、私たちが遭遇した問題のいくつかの簡単なレビュー：
歴史から学びます
-
経験ネグレクトタイムアウト時間を設定することの重要性が不足しているため、新しいアクセス三者チャネルを扱うの新しい同僚の開発。他のトランザクションがチャネルに影響を与えながら、完全にブロックに位置して三者間のトランザクションキューで、その結果、このような小さなディテールです。
-
システムは、モジュールの環境と展開が非常に大規模かつ複雑であるように、展開を配布し、サポートのグレースケールが解放されます。特定の環境が複数存在するため、新しいモジュールを追加し、それぞれが2ノード環境で、リード線の接続は、このように他のモジュールの機能に影響を与える、十分に新しいデータベースモジュールではありません。
-
それはとても他のトランザクションのスレッドが処理できないこと、また、すべてのワーカースレッドが現在設定されている排出が生じタイムアウトの問題、三者のタイムアウト、です。
-
三者認証、支払いおよび他のインターフェイス、なぜならそれによってネットワークオペレータのDDoS攻撃A三者限界側をトリガー取引量に私達の急激な増加、のインターフェースのいずれかを提供します。IPは通常、輸出取引からネットワークオペレータのために誤解されるように部屋が固定されている輸出し、最終的に同時にAパーティの認証と支払いのインターフェイスにつながることはできません、IPトラフィック攻撃です。
-
データベースの問題以外にも、また、当社の取引量は急激な増加によって引き起こされているため。同僚配列に上限を確立するシーケンス小さな取引量、システム生成された値とフィールド32が一致したとき、999,999,999の配列であるが、インベントリー・データ・フィールドの長さは32ではありませんLビット。しかし、取引量の増加に伴って、シーケンスのビット数は、無意識のうち32が得られることは十分に貯蔵しないで、上昇します。
インターネットシステムのため、この非常に一般的な問題のように、そして隠されたので、どのようにそれを回避することは非常に重要ですしています。
私たちは、私たちは、次の三つの方法を変更しました。
可能な限り、障害を避けるために、
フォールトトレラントシステム設計
このようなことのためにお金を払うユーザーを再ルーティングとして、ユーザーが自分の特定のお金が支払われたチャンネルから、ユーザーが唯一の成功を気にしている気にしないでください。プル有料チャンネル30の複数の接続、それはAチャンネルをお支払いすることが可能であることは失敗し、動的に再ルートパスBまたはCにこの時間必要が、ユーザーが再ルーティングシステムによるフォールトトレランスを実現するために支払う、支払いに失敗したように回避することができます。
そこOOM同じTomcatなどのフォールトトレランス、のために行います。全システムメモリの枯渇は、アプリケーション自体の起動は、ときに、システムOOM一部のメモリが発生さておき設定されている場合、あなたがOOMを避けるために、生きてこの例外をキャッチすることができ、発生します。
ラピッドフェール「フェイルファスト原則」の特定の側面
失敗速い原則があった場合に、メインフローの任意の段階の問題がマイナスの影響だけで治療するまでかなり待つよりも、全体のプロセスに合理的に迅速な終わりでなければならないことです。
いくつかの例を与えるために：
-
プルは、あなたがキャッシュにいくつかの情報とキュー構成情報をロードする必要がある場合キューの読み込みに失敗したか、正しく構成されていない場合、最善のアプローチは失敗したデータをロードすることであるため、要求プロセスの故障を引き起こす可能性が払って起動すると、JVM出口、使用できない以降の開始を避けます。
-
当社のリアルタイムのトランザクション処理クラス最長の応答時間は、システムが、リリース前のスレッドを待つ商人を知らせる処理されている、後続の処理の結果は仕方やビジネスの通知イニシアチブ問い合わせの行にあるだろうしない場合は40代にわたり、40代です結果;
-
私たちは、リアルタイムのアラーム埋没し、テスト重量およびその他の機能の一つを使用するのRedisデータベースキャッシュを行うために使用されます。接続がより50ミリ秒未満のRedis場合、この操作は、この操作の最悪の場合には、放棄をのRedisするシステムで許可された範囲内に制御有料50msの、に影響をもたらすことです。
デザインは自己保護システムの能力を持っています
システムは、一般に、データベース、3つのインターフェースとして、第三者に依存しています。システム開発、ダウンタイムにつながるとき、サードパーティの連鎖反応の問題を回避するために、疑いを保つために、第三者のために必要。
（1）メッセージキューを分割
私たちは、共通のショートカット、個人のオンラインバンキング、オンラインバンキング、返金、キャンセル、バルク支払い、源泉徴収バッチ、単一支払い、単一源泉徴収の支払いの声があり、加盟店への支払インターフェースの様々な提供します残高照会、近いようにID認証、銀行カード認証、承認カード。支払チャネルの手紙マイクロペイメント、ApplePay、30以上のAlipayの決済チャネル、および商人のアクセス数百人が対応します。そのさまざまなビジネスを確保するための方法を3次元では、三者、事業者、および支払いタイプ互いに独立して、行ってきた私たちは、メッセージキューを分割しています。この図は、図スプリットキュービジネスメッセージの一部です：
（2）リソースの使用を制限します
設計リソース可用性の高いシステムの使用に関する制限事項が最も重要なポイントである、簡単に、比較的限られた資源、あまり使用しポイントを見落としている、それは当然、アプリケーションのダウンタイムにつながります。この目的のために、我々は次のことを行うために宿題を持っています：
-
接続の制限数
データベース接続の数を考慮するのではなく、無限の最大化するために必要なの分散規模を持ちます。データベースへの接続数が制限され、特に増加した規模がもたらす、世界的にすべてのモジュールを考慮する必要があります。
-
メモリの使用に関する制限事項
メモリ使用量が大きすぎると、それは主に以下の二つの側面から、頻繁にGCとOOM、メモリ使用量が発生します。
-
特大のセット。
-
もはや、参照、例えば、ThreadLocalのオブジェクトに置かれているではないオブジェクトを解放しませリサイクルする場合、スレッドが終了するまで待機します。
-
制限スレッドの作成
無制限のスレッドの作成、および最終的にはコード内のスレッドを作成するには手に負えない、特に隠された方法につながります。
当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换。Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换。
除此之外，Java应用在创建线程时会操作JVM堆外的物理内存，太多的线程也会使用过多的物理内存。对于线程的创建，最好通过线程池来实现，避免线程过多产生上下文切换。
-
限制并发
做过支付系统的应该清楚，部分三方支付公司是对商户的并发有要求的。三方给开放几个并发是根据实际交易量来评估的，所以如果不控制并发，所有的交易都发给三方，那么三方只会回复“请降低提交频率”。
所以在系统设计阶段和代码review阶段都需要特别注意，将并发限制在三方允许的范围内。
及时发现故障
故障就像鬼子进村，来的猝不及防。当预防的防线被冲破，如何及时拉起第二道防线，发现故障保证可用性，这时候报警监控系统的开始发挥作用了。一辆没有仪表盘的汽车，是无法知道车速和油量，转向灯是否亮，就算“老司机”水平再高也是相当危险的。同样，系统也是需要监控的，最好是出现危险的时候提前报警，这样可以在故障真正引发风险前解决。
实时报警系统
如果没有实时报警，系统运行状态的不确定性会造成无法量化的灾难。我们的监控系统指标如下：
实时性：实现秒级监控；
全面性：覆盖所有系统业务，确保无死角覆盖；
实用性：预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策；
多样性：预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题
报警主要分为单机报警和集群报警，而付钱拉属于集群部署。实时预警主要依靠各个业务系统实时埋点数据统计分析实现，因此难度主要在数据埋点和分析系统上。
埋点数据
要做到实时分析，又不影响交易系统的响应时间，我们在系统各个模块中通过redis实时做数据埋点，然后将埋点数据汇总到分析系统，分析系统根据规则进行分析报警。
分析系统
分析系统最难做的是业务报警点，例如哪些报警只要一出来就必须出警，哪些报警一出来只需要关注。下面我们对分析系统做一个详细介绍：
1、系统运行架构
2、系统运行流程
3、系统业务监控点
我们的业务监控点都是在日常运行过程中一点一滴总结出来的，分为出警类和关注类两大块。
出警类：
网络异常预警；
单笔订单超时未完成预警；
实时交易成功率预警；
异常状态预警；
未回盘预警；
失败通知预警；
异常失败预警；
响应码频发预警；
核对不一致预警；
特殊状态预警；
关注类：
交易量异常预警；
交易额超过500W预警；
短信回填超时预警；
非法IP预警；
4、非业务监控点
非业务监控点主要是指从运维角度的监控，包括网络，主机，存储，日志等。具体如下：
-
服务可用性监控：
使用JVM采集YoungGC/Full GC次数及时间、堆内存、耗时Top 10线程堆栈等信息，包括缓存buffer的长度。
-
流量监控：
通过Agent监控代理部署在各个服务器上，实时采集流量情况。
-
外部系统监控：
通过间隙性探测来观察三方或者网络是否稳定。
-
中间件监控：
针对MQ消费队列，通过RabbitMQ脚本探测，实时分析队列深度；
针对数据库部分，通过安装插件xdb，实时监控数据库性能。
-
实时日志监控：
通过rsyslog完成分布式日志的归集，然后通过系统分析处理，完成日志实时监控和分析。最后，通过开发可视化页面展示给使用者。
-
系统资源监控：
通过Zabbix监控主机的CPU负载、内存使用率、各网卡的上下行流量、各磁盘读写速率、各磁盘读写次数(IOPS)、各磁盘空间使用率等。
以上就是我们实时监控系统所做的，主要分为业务点监控和运维监控两方面，虽然系统是分布式部署，但是每个预警点都是秒级响应。除此之外，业务系统的报警点也有一个难点，那就是有些报警是少量报出来不一定有问题，大量报警就会有问题，也就是所谓的量变引起质变。
举一个例子，拿网络异常来说，发生一笔可能是网络抖动，但是多笔发生就需要重视网络是否真的有问题，针对网络异常，我们的报警样例如下：
单通道网络异常预警：1分钟内A通道网络异常连续发生了12笔，触发了预警阀值；
多通道网络异常预警1: 10分钟内，连续每分钟内网络异常发生了3笔，涉及3个通道，触发了预警阀值；
多通道网络异常预警2： 10分钟内，总共发生网络异常25笔，涉及3个通道，触发了预警阀值。
日志记录和分析系统
对于一个大型系统而言，每天记录大量的日志和分析日志是有一定的难度的。付钱拉每天平均有200W笔订单量，一笔交易经过十几个模块流转，假设一笔订单记录30条日志，可想而知每天会有多么巨大的日志量。
我们日志的分析有两个作用，一个是实时日志异常预警，另外一个是提供订单轨迹给运营人员使用。
实时日志预警
实时日志预警是针对所有实时交易日志，实时抓取带有Exception或者Error的关键字然后报警。这样的好处是，如果代码中有任何运行异常，都会第一时间发现。我们针对实时日志预警的处理方式是，首先采用rsyslog完成日志归集，然后通过分析系统实时抓取，再做实时预警。
订单轨迹
对于交易系统，非常有必要实时了解一笔订单的状态流转。我们最初的做法是通过数据库来记录订单轨迹，但是运行一段时间后，发现订单量剧增导致数据库表过大不利于维护。
我们现在的做法是，每个模块通过打印日志轨迹，日志轨迹打印的格式按照数据库表结构的方式打印，打印好所有日志后，rsyslog来完成日志归集，分析系统会实时抓取打印的规范日志，进行解析然后按天存放到数据库中，并展示给运营人员可视化界面。
日志打印规范如下：
简要日志可视化轨迹如下：
日志记录和分析系统除了以上两点，也提供了交易和响应报文的下载和查看。
7*24小时监控室
以上的报警项目给操作人员提供推拉两种方式，一种是短信和邮件推送，一种是报表展示。除此之外，由于支付系统相比互联网其他系统本身的重要性，我们采用7*24小时的监控室保证系统的安全稳定。
及时处理故障
在故障发生之后，特别是生产环境，第一时间要做的不是寻找故障发生的原因，而是以最快速度处理故障，保障系统的可用性。我们常见的故障和处理措施如下：
自动修复
针对自动修复部分，我们常见的故障都是三方不稳定造成的，针对这种情况，就是上面说的系统会自动进行重路由。
服务降级
服务降级指在出现故障的情况下又无法快速修复的情况下，把某些功能关闭，以保证核心功能的使用。我们针对商户促销的时候，如果某个商户交易量过大，会实时的调整这个商户的流量，使此商户服务降级，从而不会影响到其他商户，类似这样的场景还有很多，具体的服务降级功能会在后续系列介绍。
