マイクロサービスの進化とそれらを分割する方法

マイクロサービスの進化

1. マイクロサービスの進化プロセス

バージョン1.0

数年前、シャオミンとシャオピオは一緒にオンラインスーパーマーケットを始めました。Xiaoming はプログラム開発を担当し、Xiaobiao はその他の事項を担当します。当時はまだインターネットが発達しておらず、ネットスーパーもまだブルーオーシャンでした。機能が実装されていれば、自由にお金を稼ぐことができます。そのため、ニーズは非常にシンプルです。必要なのは、ユーザーが製品を閲覧して購入できるパブリックネットワーク上の Web サイトだけです。また、製品、ユーザー、注文データを管理できる管理バックエンドも必要です。

機能リストを整理してみましょう。

Webサイト
- ユーザー登録・ログイン機能
- 製品ショーケース
- 注文する
経営背景
- ユーザー管理
- 製品管理
- 注文管理

要件が簡単だったので、Xiao Ming が左手と右手をスローモーションで動かすと、Web サイトが完成しました。セキュリティ上の理由から、管理背景はウェブサイトと統合されていませんが、シャオミンの右手と左手がスローモーションで再生され、管理ウェブサイトも用意されています。全体的なアーキテクチャ図は次のとおりです。

ここに画像の説明を挿入します

Xiao Ming が手を振り、クラウドサービスを見つけてデプロイすると、Web サイトがオンラインになりました。オンラインで発売後、大好評を博し、あらゆるファットハウスから愛されました。シャオ・ミンシャオは喜んで横になってお金を集め始めました。

バージョン2.0

好景気は長くは続かず、数日のうちにさまざまなネットスーパーが誕生し、小明小彪に大きな影響を与えた。

競争の圧力を受けて、Xiaoming Xiaobiao はいくつかのマーケティング手法を実行することにしました。

プロモーション活動を実施します。たとえば、サイト全体での元旦の割引、春節に 2 つ買うと 1 つ無料、バレンタインデーのドッグフードクーポンなどです。
チャネルを拡大し、モバイルマーケティングを追加します。ウェブサイトに加えて、モバイルAPP、WeChatミニプログラムなども開発する必要があります。
精密なマーケティング。履歴データを使用してユーザーを分析し、パーソナライズされたサービスを提供します。
……

これらの活動にはプログラム開発のサポートが必要です。シャオミンはクラスメートのシャオホンをチームに勧誘した。Xiaohongはデータ分析とモバイル端末関連の開発を担当しています。Xiao Mingは、プロモーション活動に関連する機能の開発を担当しています。

開発タスクが比較的緊急だったため、Xiao Ming Xiaohong 氏はシステム全体のアーキテクチャを計画せず、頭を撫でるだけで、プロモーション管理とデータ分析を管理の背景に置くことにし、WeChat とモバイル APP は別々に構築されました。数日間の徹夜作業を経て、新機能やアプリケーションはほぼ完成した。この時点でのアーキテクチャ図は次のようになります。

ここに画像の説明を挿入します

この段階では不合理な点がたくさんあります。

Web サイトとモバイルアプリケーションには、同じビジネスロジックを持つ重複コードが多数あります。
データはデータベースを通じて共有されることもあれば、インターフェイス呼び出しを通じて送信されることもあります。インターフェイスの呼び出し関係が厄介です。
他のアプリケーションにインターフェイスを提供するために、単一のアプリケーションは徐々に大きく変化し、最初からそのアプリケーションに属さないロジックも多数含まれます。アプリケーションの境界があいまいになり、関数の帰属がわかりにくくなります。
管理バックエンドは当初、低レベルのセキュリティで設計されました。データ分析やプロモーション管理に関連する機能を追加した後、パフォーマンスのボトルネックが発生し、他のアプリケーションに影響を及ぼしました。
データベースのテーブル構造は複数のアプリケーションに依存しているため、再構築したり最適化したりすることはできません。
すべてのアプリケーションはデータベース上で動作するため、データベース内でパフォーマンスのボトルネックが発生します。特にデータ分析の実行中は、データベースのパフォーマンスが急激に低下します。
開発、テスト、展開、メンテナンスはますます困難になってきています。たとえ小さな機能を変更するだけでも、アプリケーション全体をまとめてリリースする必要があります。テストされていないコードが誤って記者会見に持ち込まれたり、関数を変更した後に別の予期しないエラーが発生したりすることがあります。リリース時に発生する可能性のある問題やオンライン業務停止の影響を軽減するため、すべてのアプリケーションは午前 3 時または 4 時にリリースする必要があります。リリース後、アプリケーションが正常に動作していることを確認するには、2日目のユーザーのピーク時間帯に注目する必要があります...
チーム内で責任転嫁の現象が起きている。一部のパブリック機能をどのアプリケーションに基づいて構築するかについて長い議論が行われることはよくありますが、最終的には独自の機能を実行するか、メンテナンスせずにどこかに置くだけになります。

課題は多いものの、ビジネスの変化に合わせて迅速にシステムを構築できた成果は否定できません。しかし、緊急で重い仕事をすると、人々は部分的かつ短期的な思考に陥り、妥協した決定を下してしまう可能性があります。この種の構造では、誰もが自分の小さな土地だけに集中し、全体的かつ長期的な設計が欠けています。このままでは制度構築はますます困難になり、打倒と再構築が繰り返されるサイクルに陥る可能性すらある。

バージョン3.0

幸いなことに、シャオミンとシャオホンは追求と理想を持った良い十代の若者です。問題を認識した後、シャオミンとシャオホンは些細なビジネスニーズからエネルギーを解放し、全体の構造を整理し始め、問題を変革する準備をしました。

変革を起こすには、まず十分なエネルギーとリソースが必要です。あなたの要求当事者 (ビジネスマン、プロジェクトマネージャー、上司など) が要求の進捗を追求することに非常に強く、追加のエネルギーとリソースを割り当てることができない場合、あなたは何もできないかもしれません...

プログラミングの世界では、最も重要なことは抽象化する能力です。マイクロサービス変換のプロセスは、実際には抽象的なプロセスです。Xiao Ming と Xiao Hon は、オンラインスーパーマーケットのビジネスロジックを整理し、共通のビジネス機能を抽象化し、いくつかのパブリックサービスを作成しました。

ユーザーサービス
物品・サービス
プロモーションサービス
オーダーサービス
データ分析サービス

各アプリケーションバックグラウンドは、これらのサービスから必要なデータを取得するだけでよいため、大量の冗長コードが削除され、薄い制御層とフロントエンドのみが残ります。このステージの構造は次のとおりです。

ここに画像の説明を挿入します

この段階では、サービスは分離されているだけで、データベースはまだ共有されているため、chimney システムのいくつかの欠点がまだ存在します。

データベースはパフォーマンスのボトルネックとなり、単一障害点の危険にさらされます。
データ管理は混乱しがちです。最初は優れたモジュール設計があったとしても、時間が経つと、あるサービスが別のサービスのデータをデータベースから直接取得するという現象が必ず発生します。
データベースのテーブル構造は複数のサービスに依存している場合があり、システム全体に影響を与えるため、調整が困難です。

共有データベースモデルを常に維持すると、アーキテクチャ全体がますます硬直化し、マイクロサービスアーキテクチャの意味が失われます。したがって、Xiao Ming と Xiao Honyi はデータベースを分割しました。すべての永続層は互いに分離されており、各サービス自体を担当します。さらに、システムのリアルタイムパフォーマンスを向上させるために、メッセージキューメカニズムが追加されています。アーキテクチャは次のとおりです。

ここに画像の説明を挿入します

完全に分離すると、各サービスは異種テクノロジーを使用できるようになります。たとえば、データ分析サービスはデータウェアハウスを永続層として使用して、統計計算を効率的に実行できます。商品サービスやプロモーションサービスはより頻繁にアクセスされるため、キャッシュメカニズムが追加されます。

パブリックロジックを抽象化するもう 1 つの方法は、これらのパブリックロジックをパブリックフレームワークライブラリに作成することです。この方法により、サービス呼び出しのパフォーマンスの損失を軽減できます。ただし、この方法の管理コストは非常に高く、アプリケーションのすべてのバージョンの一貫性を確保することは困難です。

データベースの分割には、データベース間のカスケードの必要性、サービスを介したデータクエリの粒度など、いくつかの問題や課題もあります。しかし、これらの問題は合理的な設計によって解決できます。全体として、データベースの分割には短所よりも長所の方が多くあります。

マイクロサービスアーキテクチャには、技術以外の利点もあります。システム全体の分業と責任がより明確になり、各人が他の人により良いサービスを提供する責任を負います。モノリシックアプリケーションの時代では、パブリックビジネス機能には明確な所有権がないことがよくあります。最終的には、全員が自分のことを行い、それを再度実装するか、ランダムな人 (通常は、より優れた能力または熱意を持つ人) が担当するアプリケーションを実装するかのどちらかになります。後者の場合、この人は自分のアプリケーションに対する責任に加えて、これらの公開機能を他の人に提供する責任も負います。そして、この機能はもともと誰にも責任がありません。単に彼の方が有能だからです/あなたがもっと熱心であれば、理由もなく責任を負うことになります（この状況は、有能な人ほど苦労する、とも称賛されます）。その結果、公的機能を提供しようとする人が誰もいなくなりました。時間が経つにつれて、チーム内の人々は徐々に独立し、全体的なアーキテクチャ設計を気にしなくなります。

バージョン4.0

ここに画像の説明を挿入します

2. マイクロサービスの分割

分割の原理

マイクロサービスを分割するときは、特定の原則に従って分割する必要があります。

ビジネスロジックに基づく
- システム内の業務は責任範囲に応じて識別され、同じ責任を持つ業務は別のサービスに分割されます。
安定性をベースに
- システム内のビジネスモジュールを安定性に基づいて並べ替えます。安定していて頻繁に変更されないサービスを 1 つの部分に分割し、不安定で頻繁に変更されるサービスを独立したサービスに分割します。たとえば、ログサービスと監視サービスは比較的安定したサービスであり、グループ化できます。
信頼性に基づいて
- 同様に、システム内のビジネスモジュールを信頼性に基づいて並べ替えます。信頼性要件の高いコアモジュールはグループ化され、信頼性要件の低い非コアモジュールはグループ化されます。
  
  この分割を賢く行うことで、1 人の老人のせいで鍋のお粥が台無しになってしまう単一のエンティティの欠点を十分に回避できます。同時に、高可用性ソリューションを構築する際のマシンや帯域幅のコストも節約できます。未来。
高いパフォーマンスをベースに
- 上記と同様に、パフォーマンス要件に従ってシステム内のビジネスモジュールに優先順位を付けます。高いパフォーマンス要件を持つモジュールをサービスに分離し、低いパフォーマンス要件を持つモジュールをまとめます。たとえば、全文検索、製品のクエリと分類、フラッシュ販売は、高性能のコアモジュールです。

アピールの分割原則に基づいて、Mulowowo プロジェクトのマイクロサービスを分割できます。

トラベルライティングサービス
- 目的地管理
- 旅行のガイドライン
- 旅行記
- …
コメントサービス
- 旅行特集のレビュー
- 旅行記のレビュー
- 観光スポットのレビュー
- 旅行会社の口コミ
- …
ユーザーサービス
- ユーザーパーソナルセンター
- ユーザーポイント関連
- ブラックリスト/ホワイトリスト
- ファンはフォローします
- …
メッセージングサービス
- SMS通知
- 電子メール通知
- サイトメッセージ
- …
検索サービス
- 戦略検索
- 旅行記まあまあ
- ユーザー検索
- アトラクション検索
- …

人材派遣

業務ごとに分けると、粒度の大きさに応じて以下の2種類に分けられます。

1 つ目のタイプは、商品、トランザクション、ユーザーの 3 つのサービスに分かれています。
2つ目は、商品、注文、支払い、物流、買い手、売り手の6つのサービスに分かれています。

3 VS 6、どうする？

チームに 9 人しかいない場合は 3 つに分割するのが合理的で、18 人いる場合は 6 つのサービスに分割するのが合理的です。ここでは、分割を支援するチームメンバーを紹介します。

分割に関して議論が生じた場合、通常は分割条件を追加します。これは必要十分条件ではありませんが、少なくとも答えは真実に近づきます。

ビジネス上の紛争に加えて、独立したサービスに何人の人員が必要かなど、他の部門でも議論の的になるでしょう。

なぜ3人で1つのサービスを担当するということになるのでしょうか（もちろんメンバーはバックエンド担当者が中心です）。

一人しかいないと仮定すると、休暇を申請したり、病気になったりしても機能しません。一人が一点の問題に遭遇するのですから、無理があります。

人が 2 人いると仮定して、最終的にバックアップを確保しますが、1 人を削除した後も、残りの 1 人に対するプレッシャーは依然として非常に高く、これは不合理です。

3人いたとして、1人を除いても2人になります。そして、数字の 3 は、半分の努力で 2 倍の結果を得ることができる、安定した魔法の数字です。特に技術的な議論に関しては、3人だと比較的包括的ですが、2人だとそれぞれの意見があり、偏見や盲点もあるかもしれません。

では、この 3 は安定した数なのでしょうか?

マシンを始動させながらエンジンを交換する書き換え作業を行うと仮定すると、初期段階では3人全員が負担になる可能性があります。ただし、サービスの後半段階では、1 つで十分な場合があります。