＃＃＃導入＃＃＃
| 業界モデル、すぐに作成してください。 「速い」ことが最優先であり、アーキテクチャ設計にあまりエネルギーを費やす必要はありません。 Web サイトが拡張期に入ったときのみ、Web サイトが爆発的に増加したときにトラフィックを運ぶためにアーキテクチャにより多くのエネルギーを投資する必要があります。 Ele.meは設立8年目で、1日の注文件数が900万件を超え、ウェブサイトの構成も比較的充実しています。
|
1. Web サイトのインフラストラクチャ
初期の頃、私たちは SOA の拡張を容易にするフレームワークを使用していました。私たちは SOA フレームワークを使用して次の 2 つのことを解決します。
1. 分業とコラボレーション
Web サイトの初期段階では、プログラマーは 1 ～ 5 人しかいなかったかもしれません。当時は、全員が同じ作業に追われていた可能性があります。彼らは皆、お互いの仕事を理解しており、「叫び」によって問題を解決することもよくあります。
しかし、人数が増えると、この方法は明らかに実行不可能になります。1 人がコードを更新してから、他のすべての人のコードを再びオンラインに公開することは不可能ですよね?したがって、分業と連携の問題を考えなければなりません。
2. 急速な拡大
以前は、注文量は 1k から 10,000 個だったと思われますが、現在は 10 倍に増加していますが、総量はそれほど多くなく、Web サイトへの負担はそれほど大きくありません。実際に注文量が10万から100万、100万から200万になったとしても、その数は10倍にしかならないかもしれませんが、これはWebサイト全体のアーキテクチャにとって大きな課題となります。
私たちの背景としては、2014 年に 100 万人を超え、現在は 900 万人となり、技術チームも当初は 30 人強だったのが、現在では 900 人を超えるチームに成長しました。現時点では、分業とコラボレーションが大きな課題となっています。サービスの分割と統合、チームの分割と統合には、それをサポートするフレームワークシステムが必要であり、これもSOAフレームワークの役割です。
現在の状況を見ると、中央がアーキテクチャ システム全体で、右側がサービス化に関連する基本的なコンポーネントやサービスを含む基盤です。
まず言語について話しましょう。私たちの元の Web サイトは PHP に基づいていましたが、その後徐々に変化していきました。
創設者は全員、自分のビジネスを始めようとしている大学生なので、もちろん Python が最初の選択肢として適しています。今のところ、Python も良い選択ですが、なぜ Java と Go に拡張する必要があるのでしょうか?
Python を書ける人はたくさんいますが、本当に上手に書ける人は多くありません。ビジネスが成長するにつれて、より多くの開発者が必要になります。 Java の成熟した生態環境と新興の Go エコシステムを考慮して、私たちは最終的に Python、Java、Go が複数の言語で共存するエコシステムを選択しました。
WebAPI は主に、HTTPS のアンインストール、電流制限、セキュリティ検証など、ビジネス ロジックとは関係のないいくつかの一般的な操作を実行します。
Service Orchestrator は、内部ネットワークと外部ネットワークのプロトコル変換と、コンフィグレーションによるサービスの集約とカスタマイズを実現するサービス オーケストレーション層です。
アーキテクチャ図の右側には、タスクを定期的に実行するためのジョブ システムなど、サービス指向フレームワークを囲むいくつかの補助システムがあります。 1,000 近くのサービスがありますが、これらのシステムをどのように監視すればよいでしょうか?したがって、監視システムが必要です。最初に参加者が 30 名を超えていたときは、ログを検索するためにマシンに向かうのが得意でしたが、900 名を超えると、全員がログを検索するためにマシンに行くことはできなくなります。集中ログシステム。他のシステムについては、ここではいちいち説明しません。
ローマは一日にして成らず、インフラは進化のプロセスです。私たちのエネルギーには限りがあるので、まず何をすべきでしょうか?
2. サービス分割
Web サイトが大きくなると、元の構造では開発のペースが追いつかなくなります。最初にしなければならないことは次のとおりです:
大きなリポジトリを小さなリポジトリに分割し、大きなサービスを小さなサービスに分割し、集中化された基本サービスを異なる物理マシンに分割します。
サービス分割だけでも 1 年以上かかり、比較的長いプロセスです。
このプロセスでは、まず API を適切に定義する必要があります。 API がオンラインになると、いくつかの変更を加えるコストが非常に高くなるためです。多くの人が API に依存しており、多くの場合、誰が API に依存しているのかがわかりません。これは大きな問題です。
次に、いくつかの基本的なサービスを抽象化します。多くのオリジナル サービスは、実際にはオリジナルのビジネス コードに結合されています。たとえば、決済ビジネスを考えてみます。ビジネスが非常に単純な場合、密結合コードは問題になりません。しかし、ますます拡大するビジネスで決済サービスが必要になると、各ビジネス (たとえば、決済機能) に 1 つずつ実行する必要がありますか? ?したがって、支払いサービス、SMS サービス、プッシュ サービスなどの基本サービスを抽出する必要があります。
解体サービスは単純であまり価値がないように見えますが、これはまさに最初からやらなければならないことです。実際、この期間中は、以前のアーキテクチャはすべて延期できます。アーキテクチャを調整しなければ人が死ぬことはありませんが、サービスを解体しなければ、実際に人が死ぬからです。
サービスの分割は長いプロセスであるはずですが、実際には非常に骨の折れるプロセスであり、サポート システムの多くのシステム エンジニアリングが必要です。
3. 出版システム
出版は最大の不安定要因です。多くの企業では、リリース時間枠に厳しい制限を設けています。例:
- 公開できるのは 1 週間に 2 日だけです;
- 週末の投稿は絶対に禁止です;
- 繁忙期の出版は絶対に許可されません;
＃＃＃等……＃＃＃
-
公開に関する最大の問題は、公開後に簡単に実行できるロールバック操作がないことであることがわかりました。ロールバック操作は誰が実行しますか? リリース担当者が実行できますか? それとも専任の人が実行する必要がありますか?出版社の場合、オンラインで 24 時間稼働しているわけではありません。問題が発生して担当者が見つからない場合はどうすればよいですか?ロールバックを実行する専任の担当者がいて、単純で統一されたロールバック操作がない場合、この担当者は発行者のコードに精通している必要がありますが、これは基本的には実現不可能です。
したがって、公開システムが必要です。公開システムは、統合されたロールバック操作を定義します。すべてのサービスは、公開システムによって定義されたロールバック操作に従う必要があります。
Ele.me の公開システムに接続することは全員にとって必須の要件です。すべてのシステムが公開システムに接続されている必要があります。出版システムのフレームワークは非常に重要であり、これは実際に会社にとって非常に重要であり、最優先で検討する必要があります。
4. サービスフレームワーク
次のステップは Ele.me のサービス フレームワークで、大きなリポジトリを小さなリポジトリに分割し、大きなサービスを小さなサービスに分割して、サービスを可能な限り独立させます。これには、サポートする一連の分散サービス フレームワークが必要です。
分散サービス フレームワークには、サービス登録、検出、ロード バランシング、ルーティング、フロー制御、サーキット ブレーカー、ダウングレード、その他の機能が含まれますが、ここでは個別に説明しません。前述したように、Ele.me は Python や Java を含む多言語エコシステムであり、サービス指向フレームワークも多言語です。これは、DAL レイヤーなどの一部のミドルウェアのその後の選択に影響します。
5. DAL データ アクセス層
業務量がどんどん大きくなると、データベースがボトルネックになります。
初期段階では、ハードウェアをアップグレードすることでデータベースのパフォーマンスを向上させることができます。例えば：＃＃＃
より多くの CPU を搭載したマシンにアップグレードします;
ハードドライブをSSDまたはより高度なものに変更します。 -
- しかし、ハードウェアの改善には最終的には容量の限界があります。また、コードを書く際に取引先が直接データベースを操作するケースも多く、サービスが稼働したとたんにデータベースがパンクしてしまうケースも少なくありませんでした。データベースが破壊された後は、データベースを復元しない限り、ビジネスを回復する機会はありません。
データベース内のデータが正常であれば、実際にビジネスを補償することができます。したがって、DAL サービス レイヤーを構築するときに最初に行うことは、現在のフローを制限することであり、他のことは脇に置くことができます。次に、接続を再利用するために、Python フレームワークはマルチプロセス、シングルスレッド、コルーチン モデルを使用します。
実際には、複数のプロセス間で接続を共有することはできません。例: 10 個の Python プロセスがマシンにデプロイされ、各プロセスには 10 個のデータベース接続があります。マシンを 10 台に拡張すると、データベース接続の数は 1,000 になります。データベースの場合、接続は非常に高価なため、DAL レイヤーは接続を再利用する必要があります。
この接続の再利用は、サービス自体の接続の再利用ではなく、DAL 層での接続の再利用に関するものです。つまり、サービスには DAL 層への接続が 1000 個あります。接続の再利用後、データベースは 10 個しか維持できません。いくつかの接続。データベース リクエストがトランザクションであることが判明すると、DAL はこの接続の対応関係を維持するのに役立ちます。トランザクションが終了すると、データベース接続は他のユーザーが使用できるように共有プールに戻されます。
その後、燻製と溶融を行います。データベースを融合することもできます。データベースが煙を発する場合、データベースがクラッシュしないようにするために、一部のデータベース リクエストを強制終了します。
6. サービスガバナンス
サービス フレームワークの後は、サービス ガバナンスの問題が関係します。サービス ガバナンスは実際には大きな概念です。 1つ目はポイントの埋め方ですが、たくさんの監視ポイントを埋める必要があります。
たとえば、リクエストがある場合、そのリクエストが成功したか失敗したか、リクエストの応答時間はどれくらいか、すべての監視インジケータを監視システムに置きます。多くの監視インジケーターを備えた大きな監視画面を備えています。この画面を専門のチームが 72 時間監視しており、曲線に変動があれば誰かが解決してくれるでしょう。もう1つは警報システムで、監視画面に表示されるものは常に限られており、非常に重要な指標のみを表示できます。このとき、警報システムが必要です。
ローマは一日にして成らず、インフラは進化のプロセスです。私たちのリソースと時間は常に限られており、アーキテクトおよび CTO として、限られたリソースでより重要なものを生み出すにはどうすればよいでしょうか?
私たちは多くのシステムを構築し、非常に良い仕事をしてきたと感じていますが、実際はそうではありません。問題はますます増え、問題はますます増えているため、再び石器時代に戻ったように感じます。いつもシステムに何か問題があるように感じますが、まだまだ足りない部分もあり、追加したい機能もたくさんあります。
たとえば、フロー制御システムの場合、ユーザーは同時実行数を構成する必要がありますが、この同時実行数はユーザーが構成する必要はまったくないのでしょうか?サービス自体の状態に基づいて同時実行数を自動的に制御することは可能ですか?
続いてアップグレード方法ですが、SDKのアップグレードは非常に骨の折れる作業です。例えば、当社のサービスフレームワーク 2.0 は昨年 12 月にリリースされましたが、まだ 1.0 を使用している人もいます。 SDK のロスレス アップグレードを実現することは可能ですか? アップグレードの時間とリズムは自分で制御できます。
また、現在の監視は同じサービス上の集計のみをサポートしており、クラスターまたはマシンに分割されていません。将来の指標はクラスターとマシンに分割されるのでしょうか?最も単純な例を挙げると、サービス上に 10 台のマシンがある場合、1 台のマシンにのみ問題が発生する可能性がありますが、そのすべてのインジケータは他の 9 台のマシンに均等に分散されます。サービス全体の遅延が増加しているだけですが、1 台のマシンだけがサービス クラスター全体の速度を低下させている可能性があります。しかし、私たちはまだそれ以上の次元で監視することはできません。
インテリジェント アラームもあります。このアラームは、高速、完全、正確である必要があります。現在は、より迅速かつ包括的に実行できるようになりました。どうすればより正確に実行できますか?毎日のピーク時には、毎分 1,000 件を超えるアラームが送信されます。 1,000 個のアラームはすべて役に立ちますか?何度も警察に電話をした後は、全く警察を呼ばないのと同じことになります。みんな疲れて見るのをやめた。このアラームをより正確に区別するにはどうすればよいですか?もっとインテリジェントなリンク分析はありますか?将来的には、監視に監視指標を入れるのではなく、リンク分析を入れて、問題がどのノードに対応しているのかを明確に把握できるようにする必要があります。
これらの質問には、私たちの仕事の原則が関係しています。つまり、物が十分である限り、雨の日に備え、事前に確実な計画を立てることができなければなりません。
