前回の記事「.Netマイクロサービスの技術的選択」では、マイクロサービス実装のためのミドルウェアの選択とコラボレーションについて、技術的選択の観点から説明しました。これはマイクロサービスの基礎と始まりであり、.NETでマイクロサービスを使い始めたいと常に思っていた同僚に良い方向性を示したいと思います。この記事では、マイクロサービスプロジェクト全体のデモを再編成し、困っている友人を助けることを期待しています：https://github.com/SkyChenSky/Sikiro
ええと、会社でマイクロサービスを実装したとき、頭の中でそれを考えただけではありませんでした。入社当初は3人か4人しかいませんでしたが、商品企画ではパーミッション、カスタマーサービスIM、コンテンツ管理の3つのモジュールで構成された非常にシンプルなシステムしかありませんでした。プロジェクトは、シンプルなモノリシックアーキテクチャを使用して3週間未満で完了しました。製品の開発中に、プロジェクト全体の計画とプラットフォームシステムの分割を整理し、最後に非常に明確な技術実装の方向性を示しました。同時に、会社の人件費予算が承認され、チームの拡大が始まりました。
この状況では、ビジネスやチームがマイクロサービスアーキテクチャを使用する操作性を持っていても、DevOpsのアイデアを採用してマイクロサービスの実装をサポートすれば、マイクロサービスのスムーズな実装を実装できます。問題は大きくありません。マイクロサービス技術の予備力があり、運用と保守のサポートもしっかりしていて、コンセンサスに達しました。そこで、マイクロサービスミドルウェア、アーキテクチャレイヤー、サービス分割について収集された長いデータを探し始め、マイクロサービスの実装を開始しました。
PS：マイクロサービスの実装について議論したとき、上記の妥当な理由に加えて、実際には少し利己主義があります。つまり、企業は現在、マイクロサービスの実装の経験を必要とする多くの才能を採用していますが、プロジェクトやピアの80％にはこれがありません。実装が必要であり、経験、これは鶏の卵と鶏の卵の問題です。私たちの利己主義は誰もがそれを実装するためにリスクを取ることを奨励することではありませんが、条件が許せば、現在のチームの組織構造、技術的予備力、およびビジネス構造を分析することによってすべての人があなたの小さな要件を満たすことを願っています。マイクロサービスは特効薬ではありませんが、成長する必要もあります。
建築的思考
抽象化はアーキテクチャ的思考の中核であり、全体的な状況を観察して詳細をシールドすることができます。このシステムによって分割されるモジュールはどれですか。モジュールはどのように連携しますか？抽象化は、2種類の思考の分割とコラボレーションを導き出すことができます。
分割の目的は、責任を定義して分割することです。責任は、交通事故の責任ではなく、責任です。モジュールの使用シナリオを定義する場合、何に依存する必要がありますか？何に頼ればいいですか？スプリットは、実際にされた分割統治、シンプルで小さな問題に大規模、複雑な問題を分割するためのアイデアを、物事を簡単に作る自然に解決する1つのブレークで。
コラボレーションの目的は、分割されたモジュールを統合することです。分割されたモジュールを統合できない場合、分割によって元の意味が失われます。
一致する
テクノロジーは建築に貢献し、アーキテクチャはビジネスに貢献し、ビジネスはビジネスに貢献します。したがって、明確なビジネスブループリントはアーキテクチャの方向性を適切に計画でき、適切なテクノロジを選択することでアーキテクチャをサポートできます。この時点で、マイクロサービスの実装を開始しましたが、実装ではさらに中核的なポイントについても検討します。粒度とは何ですか？依存関係を定義する方法は？ピアによるマイクロサービスの実装の失敗例についてはだいたい誰もが耳にするでしょう：分割の細かさは細かすぎて、システムが非常に複雑になります。分割の細かさは粗すぎて、マイクロサービスの効果は実現されません。では、業界には一連の科学的ガイダンス方法論がありますか？DDDの戦略的設計と階層化アーキテクチャがあると思います。
エリックとエヴァンスは2004年に「ドメイン駆動設計」という本を出版しました。それ以来、雷雨に見舞われ、ソフトウェアゴッドファーザーマーティンは、マイクロサービスの包括的な説明に費やし、クライマックスになりました。 、DDDがついに春を獲得しました。DDDがマイクロサービスに適しているのはなぜですか？DDDは、事業を分割することにより、境界、複雑なビジネス単純な設計コンセプト、ある簡素化します。上記のDDD戦略設計を強調するのはなぜですか？DDDは、戦略的設計と戦術的設計に分けられます。
戦略的デザイン
主にビジネスの観点から、ビジネスドメインモデルを確立し、ドメイン境界を分割し、一般的な言語の境界コンテキストを確立します。境界コンテキストは、マイクロサービス設計の参照境界として使用できます。
戦術的なデザイン
主に技術的な観点から、ドメインモデルの技術的な実装、完全なソフトウェアの開発と着陸に焦点を当てています。これには、私たちがよく議論する集計ルート、エンティティ、値オブジェクト、ドメインサービスなどのコードロジックの設計と実装が含まれます。
上記の2つのポイントの説明からわかるように、戦略的設計はビジネスの視点からのものであり、アーキテクチャはビジネスに役立ちます。どちらもビジネスからのものである必要があります。DDD戦略的設計とマイクロサービスは同じ設計思想を持っています：分割、征服、単純化、単純化次に、戦略的設計のアイデアをマイクロサービスアーキテクチャ設計の指針となるイデオロギーとして使用できます。現時点では、このシナリオは一致しています。
階層化アーキテクチャ
Nレイヤーアーキテクチャ（N> = 2）と呼ぶこともできます。実際、本質は責任を分割し、懸念事項を分離して、レイヤー間の違いが十分に明確になり、境界が十分に明確になるようにすることです。
垂直分割
まず、レイヤードアーキテクチャの考え方に従って、縦方向に分割します。主に、UIレイヤー、集約APIサービスレイヤー、基本的なビジネスAPIサービスレイヤー、インフラストラクチャレイヤー、データベースレイヤーの 5つのレイヤーに分かれています。
リンクを上から下に呼び出します。ユーザー-> UI-> APIゲートウェイ->集約APIサービス-> Consul + Consulテンプレート+ Nginx->ビジネスAPIサービス->データベース
UI层
集約APIサービスレイヤーに 依存して、操作はインターフェイス11に対応し、主に表示および利用可能な作業（データ表示、インタラクティブアニメーションなど）を担当します。
インバウンドAPIゲートウェイ
主に、集約APIサービスレイヤーの内部ネットワークと外部ネットワークの分離、および内部トラフィックが外部の大量のトラフィックによって圧倒されないようにするためのインバウンドルールの制御を担当します。
集約APIサービスレイヤー
これは、UIレイヤーに依存し、基本的なビジネスAPIサービスレイヤーに依存します。主に、基本的なビジネスAPIサービスレイヤーのインターフェイスの論理的な組み合わせを担当します。データベースに直接接続されておらず、APIゲートウェイを介してUIレイヤーに公開できます。
登録サービスセンター
基本ビジネスAPIサービスレイヤーのサービスIPリストを 記録し、イントラネットで使用し、集約APIサービスレイヤーと基本ビジネスAPIサービスレイヤーを接続します。
基本的なビジネスAPIサービスレイヤー
依存性ポリマー層のAPIサービスに依存して、データベース層は、読み込み、書き込みプロセスは、基準層サービスの間には相互依存して、ネットワークを使用して、特定のデータベースを行います。
データベース層
非リレーショナルデータベースとリレーショナルデータベースを含みます。
インフラサービス層
場合、すべての層は、依存し得るUI層に依存することであるAPIゲートウェイが登録を通じてネットワークサービス発見に依存している場合、それはデータベースに直接接続することができ、露光。
アウトバウンドAPIゲートウェイ
主に、インフラストラクチャサービスレイヤーの内部ネットワークと外部ネットワークの分離、サードパーティのオープンAPIリクエストの転送、アウトバウンドルールの制御、および制御されていないサードパーティサービスによる内部サービスのドラッグの防止を担当します。
水平分割
次に、ドメインをDDDで分割することにより、サービスの水平方向の次元を分割できます。たとえば、次のとおりです。
当社のプラットフォームには、カスタマーセンター、エンタープライズ管理システム、内部管理システムという異なるビジネス分野の3つのシステムがあります。
次に、集約APIサービス層には、顧客システムAPIサービス、エンタープライズ管理システムAPIサービス、および内部管理システムAPIサービスがあります。
カスタマーセンターには、顧客情報管理、支払い、注文管理などのビジネスモジュールがあります。
エンタープライズ管理システムには、注文管理、権限管理、支払い、倉庫保管などのビジネスモジュールがあります。
内部管理システムには、権限管理、レポート、アカウント管理などのビジネスモジュールがあります。
すべてのシステムには、カスタム注文番号、メッセージプッシュ、その他のサービスが含まれます。
上記から、コアドメインには、倉庫、注文ビジネス、および顧客情報が含まれます。一般的なドメインには、権利管理、アカウント認証、支払いモジュール、メッセージプッシュなどがあります。サポートフィールドには、カスタム注文番号が含まれます。
したがって、基本的なビジネスAPIレイヤーは、ストレージAPIサービス、注文APIサービス、顧客APIサービス、許可APIサービス、認証APIサービス、支払いAPIサービスに分類できます。
インフラストラクチャAPIレイヤーは、ID発行番号APIサービス、メッセージプッシュAPIサービスに分類できます。
ビジネスの拡大に伴ってチームの数が増える場合は、さらに細分化することができます。たとえば、倉庫保管を速達と配送に分割します。支払いはWeChat支払い、Alipayなどに分割されます。
プロジェクト例
前回の「.Netマイクロサービスの技術的選択」では、当社が使用するフレームワークを整理してgithubに公開しましたが、今回はいくつかのビジネスプロジェクトを例に取り上げてアップロードしました。
https://github.com/SkyChenSky/Sikiro
まず、いくつかの点を説明したいと思います。
1.これは標準ではなく、当社の状況に応じて選択した結果であり、各社の事業は複雑かつシンプルであり、誰もが状況に応じて自分のプロジェクトを完成させます。
2.会社独自のビジネスプライバシーを保護するために、ロジックの一部を削除しました。そのため、不完全なロジックがすべての人に表示されるのは正常です。
3.考えを高くし、詳細を掘り下げず、違いを残しながら共通点を探ってください。
4.コードは元の名前に基づいて変更され、参照パスが変更されます。質問がある場合は、コメントやgithubまでお気軽にご連絡ください。
https://www.cnblogs.com/skychen1218/p/12653155.htmlから転送