前の上記モノマーのアプリケーションおよびマイクロサービスアーキテクチャ、春公式サイトの建築図、ゲートウェイはまた、このようなものを示しています。この記事では、我々は次のAPIゲートウェイを理解する必要があり、前置きとして、マイクロおよびサービスステーションアーキテクチャのいくつかの側面を探求します。
サービスの分割した後、私たちのシステムは次のようになる可能性があります：
コールチェーンの追跡サービスは非常に重要ですので、まだ、かなり厄介に見えました。クライアントの場合、これは、クライアント上でハード非常に多くのラインのコールのルートです。そして、このようになる可能性があります当社のシステムの一つ上の中間層の考え方に適用されます。
八角形のオレンジへのすべての呼び出しの複雑さ。
このとき、クライアントのために、オレンジ色の八角形が全体のシステムの場合、クライアントはすべての機能を提供し、すべての要求は、入口れます。
内部サービスの場合は、オレンジ色の八角形は、様々なサービスを呼び出すために、クライアントと同等です。この場合には、システム構成を簡素化することができます。
オレンジ八角形は、APIゲートウェイ、HTTPプロトコルゲートウェイとの相互作用を介してクライアントです。コンテンツやサービスと対話する方法は他にRPCまたはHTTPゲートウェイ。ゲートウェイは、文字通りの意味で理解して、この次のとおりです。
- 行為のチェックポイントのように、内部サービスなどの外部ゲートウェイ：ネットワークを渡します。それはレベルがあるので、その後、何を提供することができますか？
- セキュリティーチェック
- 限定的
- ルートの転送
- 集合
- 実際にはこれらのシーンとの生活は、対応を渡すことができます
- ネットワークプロトコル変換、中間層：ここでAPIゲートウェイに加えて、実際には、物事ゲートウェイを聞いたことがあるかもしれません。彼らは、プロトコル変換機能を果たしている、の図は、特定のRPCプロトコルにHTTPプロトコルを変換することです
垂直方向の負荷分散サービスの下のDirのような非国家レジストリサービス部門の簡単なレビューは、実際に内部もちろん、負荷分散コンポーネントを使用して達成することができ、レジストリによって実現行くことができます。そして、そのためのAPI Gatewayの？
APIゲートウェイとクライアントが対話型であるので、レジストリの方法を使用することはそれほど簡単ではありません。それは自然に下に示すように、負荷分散コンポーネントで実装する必要があります。
追加しました負荷分散と高可用性APIゲートウェイ自体を達成するために、前のレベルで採択されたその他の措置。もちろん、負荷分散層は非常に背を言うために、複雑になることがあります。
API Gatewayの負荷分散が達成されているので、それの内部でサービスをロードバランシング？あなたが達成するために、レジストリを使用する場合は、サービスプロバイダは、以下のように示すことがあります。
A1、A2、A3は、同じサービスを提供し、その後、「クライアント」それを呼び出すべき？すべてはA3を呼び出す場合、その何の助け負荷が目的のバランスをとるません。このとき、負荷分散アルゴリズムは、「クライアント」することができ、このクライアントは、ゲートウェイまたは他の内部サービスをすることができます。非侵襲のビジネスを保護するために、自然に使用するagentソフトクライアントの負荷分散を実現するために、このエージェントモデルを。
実際には、上記のすべての側面は、マイクロサービスシステムで構成されています。図バネの公式ウェブサイトで見てみましょう：
- APIゲートウェイ：APIゲートウェイ
- サービスレジストリ：レジストリサービス
- Microservices：マイクロアプリケーションサービス
- 分散型トレース：コールチェーントラック
- コンフィグサーバ：コンフィグレーションセンター。同様の練習やサービスセンターでは、より多くのすべての後に、プロの人たちは、プロのことを行うために、構成情報を格納型に傾きました
ただ、ミクロのサービスを理解することは非常に困難実際には、これらのコンポーネントを見てください。サービスのビジネスシナリオからマイクロ切っても切れない、私たちは話していないでしょう。
類推に設計されたサービスアプリケーションはとても良い私たちのオブジェクト設計、オブジェクト間の相互作用もうまく処理され、オブジェクト指向プログラミングと呼ばれることも、それはそれを完了することではないでしょうか？
もちろん、再び呼び戻さない階層的な思考の、いくつかのオブジェクトが同じ共通に、変更される可能性があり、一部のオブジェクトは、いわゆる分離が変更と変わらない属しています -
分割して、その後、沈殿物最終的に次のような構造を形成：
どこで：
- 物理リソース：クラウドサービスのリソースを参照する、または物理サーバのリソースなど
- K8Sプラットフォーム：前もの簡潔には、前に基本的なマイクロサービスソフトウェア「ハードウェア」の施設と同等のものを言及しました
- ミドルウェア・サービス：ミドルウェアの例は、MySQL、Redisの、MQシリーズ、技術的なプラットフォームのための
- 基本的なビジネス・サービス：などのプッシュサービス、例えば、いくつかの一般的な操作、
- 特定のビジネスプラットフォーム：フロントデスクは異なる（ウェブ、など）アプリケーションの顔である、特定のビジネス・サービスの開発
- 受付業務：自然はWEB、APPおよびその他のフロントエンドアプリケーションです
この階層的分割では、層オブジェクト内部の明確な分割の層の間に位置する「オブジェクト」も明らかです。次いで、比較的容易に低結合、高い凝集力を達成するだけでなく、ある程度の再利用最大値を達成します。
だから、このアーキテクチャでは、マイクロサービスがある：K8Sプラットフォームから全体 - 特定のビジネスプラットフォーム。マイクロサービス「ハードウェアサポート」に属し、残りの部分はマイクロサービスソフトウェアに属しますが、ソフトウェアはセクションに分割することができるK8S。
- 基本的なソフトウェアサポート
- 財団ビジネスサポート
- 具体的なビジネス・サービス
それはそこにフロントデスクにまとめることができるので、特定のビジネスサービス、フロントサービスのためには、密接に一緒にリンクされています。基本的なソフトウェアのサポートおよびインフラ支援事業を呼び出すことができ中台、それは、上の特定のビジネス・サービスのための最終段階にあり、呼び出すことができます业务中台。
だから、当時？当然のことながら、背景の一部は、様々な管理システムを参照して、プラットフォームの他の部分ができ、またK8S、物理リソース背景には、これは、下地層スケジューリング、メンテナンス、及びニーズを監視するように多様です。
この階層化アーキテクチャでは、中台私たちのビジョンへのへのコンセプト。ビジネスデスクでは、すぐに速く開発することができ、当社のフロントオフィスを作り、上位層のサービスを再利用する機能を提供するだけでなく、維持する機能が容易になります。だから、ステージはマイクロサービス・ソフトウェア・レベルのさらなる進化です。
3回の記事では、我々は少し作業のガイドラインを行うために、マクロで考えられ、再び現在の全体的なアーキテクチャの概念を、それを見ました。
ソフトウェアアーキテクチャやシステムアーキテクチャは哲学の一態様です。
我々は、次を参照します。パートIIは、正式に宇宙の広大さが始まった感謝の分散、分散システムの内部に入る、始めました。
