マイクロサービス入門.2


始める前に


我々のトピックについて話を始める前に、これがどのように働くかを理解するために1分かかりましょう.
すべての記事は3つの部分に分けられます.
  • 何を解決しようとしているのか?私は、特定の話題が解決しようとしているどんな種類の問題について少しの文脈をあなたに与えます;
  • 解決策:トピックの名前-私はトピックについて話をしますどのようにこれらの問題を解決しますand
  • コードを見せてください-私はそのトピックの簡単な実装を通過し、いくつかのドキュメントをポイントし、あなたが深く潜ることを選択する必要があります.
  • 目次

  • What are we trying to solve?
  • The solution: API Gateways
  • Show Me the Code
  • Bibliography
  • 前回は話し合いましたが、今はパターンのいくつかを適用する時です.今日、我々はAPIゲートウェイについて学びます!

    何を解決しようとしているか。

    Imagine this: you developed an online store that uses microservices. Now, you have a service that returns basic information about your products, another for product availability, another for reviews of products, and so on...
    Your front-end wants to access all this information, but it must know ALL of the services addresses. For just a few services, it shouldn't be too hard, but imagine a scenario that your back-end has dozens or maybe hundreds of services. This would be a nightmare!

    There's also a few more reasons as to why gateways are important:

    • The number of instances and their locations might change dynamically. The clients won't know the new address every time a new instance is started;
    • Instances partitioning might change (Z-Axis scaling) and it should be invisible to your clients;
    • Services might use a diverse set of protocols, and some of them might not be 'web friendly'.

    So, our problem is: How clients of a microservices architecture can access individual services in a simple way? By using API Gateways!

    解決策:APIゲートウェイ

    Gateways act as a Single Point of Entry to you application. All requests will go through the API Gateway and will be routed accordingly.


    図1.ゲートウェイパターン
    すべてのクライアントのニーズに合う単一のAPIを持つ代わりに、あなたのゲートウェイはクライアントのそれぞれのタイプに異なるAPIを公開することができます.いっそのこと、複数のAPIゲートウェイ、クライアントの各タイプのいずれかを持つことができます!それはフロントエンドのバックエンドと呼ばれるパターンのバリエーションです.

    図2.APIゲートウェイ変動:フロントエンドのためのバックエンド
    次の記事で見るように、ゲートウェイは、サービスレジストリを実装したら、すべてのインスタンスとそのアドレスに動的にアクセスできます.

    利益


    APIゲートウェイの利点を挙げましょう.
  • クライアントは、アプリケーションがサービス間で分割される方法を知る必要はありません
  • クライアントは、サービスのインスタンスの場所(ホスト+ポート)を知る必要はありません
  • クライアントの各タイプに最適なAPIを提供します
  • APIゲートウェイへの単一の要求は、複数のサービスからデータを得ることができます
  • ゲートウェイに複数のサービスを呼び出す論理を動かすことによって、クライアントを単純化してください;and
  • 使用されるかもしれないどんな内部のプロトコルにも、ウェブプロトコルを翻訳します.
  • 欠点


    また、いくつかの欠点があります.
  • ゲートウェイが開発されて、配備されて、維持されなければならないもう一つのアプリケーションになるので、複雑さを増やします;and
  • 現在、すべての要求がゲートウェイを通して新しいホップを作らなければならないように、応答時間を増やしてください.
  • コードを見せてください

    Now that we know what an API Gateway is, what it does, its benefits and drawbacks, let's implement a simple Gateway and see how it works.

    Start by creating two projects: one for the API Gateway and another for you Web API. Your Web API can be anything, right? If you need an idea just for this tutorial, you can head over to my Github repository . また、この全体の記事シリーズの作業例にアクセスする必要があります.
    さて、あなたがWeb APIを作成したので、APIゲートウェイで動作する時間です.を追加して起動するOcelot ゲートウェイプロジェクトへのパッケージ
    dotnet add package Ocelot
    
    インストールが完了したら、OcOOTというプロジェクトのルートに新しいJSONファイルを作成します.ジェンソン.次に次の行を追加します.
    {
      "Routes": [
        "DownstreamPathTemplate": "/api/v1/{everything}",
        "DownstreamScheme": "https",
        "DownstreamHostAndPorts": [
          {
            "Host": "localhost",
            "Port": "YOUR-LOCAL-PORT"
          }
        ],
        "UpstreamPathTemplate": "/api/gateway/{everything}",
        "UpstreamHttpMethod": [ "GET", "POST", "PUT", "PATCH", "DELETE" ]
      ],
      "GlobalConfiguration": {}
    }
    
    各行の意味を話し合いましょう.あなたのゲートウェイは、前に述べたように、それを介して来るすべての要求のためのルータとして機能します.それを念頭に置いて、“ルート”プロパティは、我々のアプリケーションのすべてのルーティングを定義する場所です.
    プロパティ“DownStreamPathTemplate”、“ダウンストリームスキーム”と“ダウンストリームのポート”は、サービスルートの形式、使用されるプロトコルとベースアドレスを定義します.OcOOTはまた、いくつかのプレースホルダを使用します.
    “UpStreamPathTemplate”と“UpStreamHttpMethod”のプロパティは、外部世界に利用可能なアドレスの形式を定義し、ルートがどのHTTPメソッドを受け入れるかを定義します.
    それで、このJSONファイルで、毎回誰かが要求をしようとしますhttps://localhost:gateway_port/api/gateway/some-resource 「オセロットはリクエストを送る」https://localhost:web_api_port/api/v1/some-resource 「かしら.
    しかし、我々はまだしていません.JSONファイルを読むためにゲートウェイプロジェクトを設定し、ルートリクエストに使用する必要があります.それで、あなたの「プログラム. cs」ファイルを開いて、「CreateHostBuilder」メソッドを編集してください
    // Program.cs
    public static IWebHostBuilder CreateHostBuilder(
      string[] args) => WebHost.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration(
          (host, config) =>
          {
            config.AddJsonFile("ocelot.json");
          }
        )
        .UseStartup<Startup>();
    
    "config . addjsonfile ( "Ocelot . JSON ")"はゲートウェイにOCELET JSON設定をロードします.我々はほとんど完了です!我々は、サービスにオセロットを追加する必要があります.これを行うには、「起動ファイルcs」ファイルを編集します.
    // Startup.cs
    public void ConfigureServices(IServiceCollection services)
    {
      // ...
      services.AddOcelot();
      // ...
    }
    
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
      // ...
      app.UseOcelot().Wait();
      // ...
    }
    
    さて、完了です!あなたのWeb APIとAPIゲートウェイを起動し、結果を確認することができます!
    次のトピックであなたを待ちます.

    参考文献

  • Microservices Patterns: With examples in Java - Chris Richardson
  • API gateway pattern - https://microservices.io/patterns/apigateway.html
    Oracleドキュメントhttps://ocelot.readthedocs.io/en/latest/index.html