| 工業用モデルなのですぐに生産できます。「速い」ことが最優先であり、アーキテクチャ設計にあまりエネルギーを費やす必要はありません。Web サイトが拡張期に入った場合にのみ、Web サイトが急増したときにトラフィックを運ぶためにアーキテクチャにより多くのエネルギーを投資する必要があります。Ele.me は設立して 8 年が経ち、現在では 1 日あたりの注文件数が 900 万件を超え、Web サイトの構成も比較的充実しています。 |
1. ウェブサイトのインフラストラクチャ
初期の段階では、SOA の拡張を容易にするフレームワークを使用していました。SOA フレームワークを使用して、次の 2 つのことを解決します。
1. 分業と連携
Web サイトの初期段階では、プログラマーは 1 ～ 5 人しかいないかもしれませんが、その時点では、全員が同じ作業に追われている可能性があります。彼らは皆、お互いの仕事を理解しており、「叫び」によって問題を解決することもよくあります。
しかし、人数が増えると、この方法は明らかに現実的ではなくなります。1 人がコードを更新してから、他のすべての人のコードを再びオンラインに公開することは不可能ですよね。したがって、分業と連携の問題を考えなければなりません。
2. 急速な拡大
以前は、注文量は 1,000 個から 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. 出版システム
リリースは最大の不安定要因です。多くの企業は、リリース時間枠に次のような厳しい制限を設けています。
- 投稿できるのは週に 2 日だけです。
- 週末の投稿は絶対に禁止されています。
- ビジネスの繁忙期には投稿は絶対に許可されません。
- 等……
公開に関する最大の問題は、公開後に簡単に実行できるロールバック操作がないことであることがわかりました。ロールバック操作は誰が実行しますか? リリース担当者が実行できますか? それとも専任の人が実行する必要がありますか? 出版社の場合、オンラインで 24 時間稼働しているわけではありません。問題が発生して担当者が見つからない場合はどうすればよいですか? ロールバックを実行する専任の担当者がいて、単純で統一されたロールバック操作がない場合、この担当者は発行者のコードに精通している必要がありますが、これは基本的には実現不可能です。
したがって、公開システムが必要です。公開システムは、統合されたロールバック操作を定義します。すべてのサービスは、公開システムによって定義されたロールバック操作に従う必要があります。
Ele.me の公開システムに接続することは、全員にとって必須の要件です。すべてのシステムが公開システムに接続されている必要があります。出版システムのフレームワークは非常に重要であり、これは実際に会社にとって非常に重要であり、最優先で検討する必要があります。
4. サービス体制
次は Ele.me のサービス フレームワークで、大きな Repo を小さな Repo に分割し、大きなサービスを小さなサービスに分割して、サービスを可能な限り独立させることができます。これには、一連の分散サービスが必要です。 。
分散サービス フレームワークには、サービス登録、検出、ロード バランシング、ルーティング、フロー制御、サーキット ブレーカー、デグレードなどの機能が含まれますが、ここでは個別に説明しません。前述したように、Ele.me は Python や Java を含む多言語エコシステムであり、サービス指向フレームワークも多言語です。これは、DAL レイヤーなどの一部のミドルウェアのその後の選択に影響します。
5. DAL データアクセス層
業務量がどんどん大きくなると、データベースがボトルネックになってしまいます。
初期段階では、ハードウェアをアップグレードすることでデータベースのパフォーマンスを向上させることができます。例えば：
- より多くの CPU を搭載したマシンにアップグレードします。
- ハードドライブをSSDまたはより高度なものに交換します。
しかし、ハードウェアの改善には最終的には容量の限界があります。また、コードを書く際に取引先が直接データベースを操作するケースも多く、サービスが稼働したとたんにデータベースがパンクしてしまうケースも少なくありませんでした。データベースが破壊された後は、データベースを復元しない限り、ビジネスを回復する機会はありません。
データベース内のデータが正常であれば、企業は実際にそれを補うことができます。したがって、DAL サービス レイヤーを構築するときに最初に行うことは、現在のフローを制限することであり、他のことは脇に置くことができます。次に、接続を再利用するために、Python フレームワークはマルチプロセス、シングルスレッド、コルーチン モデルを使用します。
実際、複数のプロセスが接続を共有することはできません。例: 10 個の Python プロセスがマシンにデプロイされ、各プロセスには 10 個のデータベース接続があります。マシンを 10 台に拡張すると、データベース接続の数は 1,000 になります。データベースの場合、接続は非常に高価なため、DAL レイヤーは接続を再利用する必要があります。
この接続の再利用は、サービス自体の接続の再利用ではなく、DAL 層での接続の再利用に関するものです。つまり、サービスには DAL 層への接続が 1000 あります。接続の再利用後は、データベースへの接続は 12 個しか維持されない可能性があります。 . . データベース リクエストがトランザクションであることが判明すると、DAL はこの接続の対応関係を維持するのに役立ちます。トランザクションが終了すると、データベース接続は他のユーザーが使用できるように共有プールに戻されます。
次にスモークとフュージョンを行います。データベースを融合することもできます。データベースが煙を発する場合、データベースがクラッシュしないようにするために、一部のデータベース リクエストを強制終了します。
6. サービスガバナンス
サービス フレームワークの後には、サービス ガバナンスの問題が含まれます。サービス ガバナンスは実際には大きな概念です。1つ目はポイントの埋め方ですが、たくさんの監視ポイントを埋める必要があります。
たとえば、リクエストがある場合、そのリクエストが成功したか失敗したか、リクエストの応答時間はどれくらいかなど、すべての監視インジケータを監視システムに設定します。多くの監視インジケーターを備えた大きな監視画面を備えています。この画面を専門のチームが 72 時間監視しており、曲線に変動があれば誰かが解決してくれるでしょう。もう1つは警報システムで、監視画面に表示されるものは常に限られており、非常に重要な指標のみを表示できます。このとき、警報システムが必要です。
ローマは一日にして成らず、インフラは進化のプロセスです。私たちのリソースと時間は常に限られており、アーキテクトおよび CTO として、そのような限られたリソースでより重要なものを生み出すにはどうすればよいでしょうか?
私たちは多くのシステムを構築し、良い仕事をしてきたと感じていますが、実際はそうではありません。問題はますます増え、要求もますます増えているため、石器時代に戻ったように感じます。いつもそう感じています。システムに何かが欠けているように、やりたいことや機能がたくさんあります。
たとえば、フロー制御システムの場合、ユーザーは同時実行数を設定する必要がありますが、ユーザーはこの同時実行数をまったく設定する必要がないのでしょうか? サービス自体の状態に基づいて同時実行数を自動的に制御することは可能ですか?
次にアップグレード方法ですが、SDKのアップグレードは非常に面倒なものです。例えば、当社のサービスフレームワーク 2.0 は昨年 12 月にリリースされましたが、まだ 1.0 を使用している人もいます。SDK のロスレス アップグレードを実現することは可能ですか? アップグレードの時間とリズムは自分で制御できます。
また、現在の監視は同一サービス上の集計のみをサポートしており、クラスターやマシンに分割されていないため、将来の指標はクラスターとマシンに分割できるのでしょうか? 最も単純な例を挙げると、サービス上に 10 台のマシンがある場合、1 台のマシンにのみ問題が発生する可能性がありますが、そのすべてのインジケータは他の 9 台のマシンに均等に分散されます。サービス全体の遅延が増加しているだけですが、1 台のマシンだけがサービス クラスター全体の速度を低下させている可能性があります。しかし、私たちはまだそれ以上の次元で監視することはできません。
インテリジェントなアラームもあります。このアラームは、高速、完全、正確である必要があります。現在では、より迅速かつ包括的に実行できるようになりました。どうすればより正確に実行できるでしょうか? 毎日のピーク時間帯には、毎分 1,000 件を超えるアラームが送信されます。1,000 個のアラームはすべて役に立ちますか? 何度も警察に電話をした後は、全く警察を呼ばないのと同じことになります。みんな疲れて見るのをやめた。このアラームをより正確に区別するにはどうすればよいですか? もっとインテリジェントなリンク分析はありますか? 将来的には、監視に監視指標を入れるのではなく、リンク分析を入れて、問題がどのノードに対応しているのかを明確に把握できるようにする必要があります。
これらの質問には、物事が十分である限り、事前に計画を立てて計画を立てることができなければならないという、私たちの仕事の原則が含まれています。