[翻訳]squbs公式サイトの7リクエスト/応答パイプ

概要
デルは、異なるサービス・エンド/クライアントにまたがる共通のインフラストラクチャ機能をよく使用します.このようなインフラストラクチャには、ログ、指標収集、要求追跡、認証/認可、追跡、クッキー管理、A/Bテストなどが含まれるが、これらに限定されない.
squbsが注目の分離を促進するにつれて、このような論理はクライアント実装ではなくインフラストラクチャに属する.squbsパイプラインでは、お客様自身がこれらの点を心配することなく、インフラストラクチャ提供コンポーネントをクライアントにインストールできます.
通常、squbsパイプはBidi Flowであり、次のような橋渡しをしています.

Akka HTTP層とsqubsサービス

Akka HTTPからsqubsサービスに送信すべての要求メッセージは、パイプ

を通過する.

逆もまた、squbsサービスから送信されたすべての応答メッセージは、パイプ

を通過する.

squbsクライアントとAkka HTTPホスト接続プールフロー:

squbsクライアントからAkka HTTP接続プールへ送信すべての要求メッセージは、パイプ

を通過する.

逆もまた、Akka HTTP接続プールからsqubsクライアントへのすべての応答メッセージは、パイプ

を通過する.

パイプ申明
次の構成で指定したデフォルトの前/後ストリームは、単一のサービス/クライアント構成でdefaultPipelineがoffに設定されていない限り、サーバ/クライアントパイプラインに自動的に接続されます.

squbs.pipeline.server.default {
    pre-flow = defaultServerPreFlow
    post-flow = defaultServerPostFlow
}

squbs.pipeline.client.default {
    pre-flow = defaultClientPreFlow
    post-flow = defaultClientPostFlow
}

サービス側パイプの申明
squbs-metaでconf、サービス側にパイプを指定できます.

squbs-services = [
  {
    class-name = org.squbs.sample.MyActor
    web-context = mypath
    pipeline = dummyflow
  }
]

squbsサービス側のカスタムパイプがない場合は、省略します.上記の構成を使用すると、パイプラインは次のようになります.

RequestContext ~>|         |~> |         |~> |         |~> |         | 
                 | default |   |  dummy  |   | default |   |  squbs  |
                 | PreFlow |   |  flow   |   | PostFlow|   | service | 
RequestContext 

RequestContextは、基本的にはHttpRequestおよびHttpResponseの周りのパッケージであり、コンテキスト情報の携帯も可能である.
クライアントパイプの説明
アプリケーションでconf、クライアントにパイプを指定できます.

sample {
  type = squbs.httpclient
  pipeline = dummyFlow
}

squbsクライアント用のカスタムパイプがない場合は、省略します.上記の構成を使用すると、パイプラインは次のようになります.

                 +---------+   +---------+   +---------+   +----------+
RequestContext ~>|         |~> |         |~> |         |~> |   Host   | 
                 | default |   |  dummy  |   | default |   |Connection|
                 | PreFlow |   |  flow   |   | PostFlow|   |   Pool   | 
RequestContext 

Bidi Flow構成
bidi flowは、次のように指定できます.

dummyflow {
  type = squbs.pipelineflow
  factory = org.squbs.sample.DummyBidiFlow
}

type:構成をsqubsとして識別する.pipelineflow. factory:このファクトリクラスはBidiFlow fromを作成します.
DummyBidiFlowの例を次に示します.

class DummyBidiFlow extends PipelineFlowFactory {

  override def create(context: Context)(implicit system: ActorSystem): PipelineFlow = {
     BidiFlow.fromGraph(GraphDSL.create() { implicit b =>
      val inbound = b.add(Flow[RequestContext].map { rc => rc.addRequestHeader(RawHeader("DummyRequest", "ReqValue")) })
      val outbound = b.add(Flow[RequestContext].map{ rc => rc.addResponseHeader(RawHeader("DummyResponse", "ResValue"))})
      BidiShape.fromFlows(inbound, outbound)
    })
  }
}

ちゅうだんりゅう
場合によっては、パイプ内の1つのフェーズでストリームを中止し、例えば認証/認可を行う場合にHttpResponseを返す必要がある場合があります.この場合、パイプラインの残りの部分はスキップされ、squbsサービスに到達しないように要求されるべきである.残りのストリームをスキップするには、次の手順に従います.

ストリームには、b.add(authorization abortable)のようなabortableを有するコンストラクタを追加する必要がある.

RequestContextでHttpResponse付きabortWithを呼び出し、中止する必要がある場合.

次のDummyAbortableBidiFlowの例では、authorizationはabortable付きbidi flowであり、ユーザーが許可していない場合にストリームを中止します.

class DummyAbortableBidiFlow extends PipelineFlowFactory {

  override def create(context: Context)(implicit system: ActorSystem): PipelineFlow = {

    BidiFlow.fromGraph(GraphDSL.create() { implicit b =>
      import GraphDSL.Implicits._
      val inboundA = b.add(Flow[RequestContext].map { rc => rc.addRequestHeader(RawHeader("keyInA", "valInA")) })
      val inboundC = b.add(Flow[RequestContext].map { rc => rc.addRequestHeader(RawHeader("keyInC", "valInC")) })
      val outboundA = b.add(Flow[RequestContext].map { rc => rc.addResponseHeaders(RawHeader("keyOutA", "valOutA"))})
      val outboundC = b.add(Flow[RequestContext].map { rc => rc.addResponseHeaders(RawHeader("keyOutC", "valOutC"))})

      val inboundOutboundB = b.add(authorization abortable)

      inboundA ~>  inboundOutboundB.in1
                   inboundOutboundB.out1 ~> inboundC
                   inboundOutboundB.in2  

    val authorization = b.add(Flow[RequestContext] map { rc =>
        if(!isAuthorized) rc.abortWith(HttpResponse(StatusCodes.Unauthorized, entity = "Not Authorized!"))
        else rc
    })

    val noneFlow = b.add(Flow[RequestContext]) // Do nothing

    BidiShape.fromFlows(authorization, noneFlow)
  })
}

ストリームにabortableが追加されるとbidi flowが接続されます.このbidi flowは、HttpResponseが存在するかどうかを確認し、下流リクエストを迂回または送信します.上記DummyAbortableBidiFlowは次のように見えます.

                                                |  +-----------+    +-----------+   |   +-----------+
                  +-----------+   +---------+   |  |           | ~> |  filter   o~~~0 ~>|           |
                  |           |   |         |   |  |           |    |not aborted|   |   | inboundC  | ~> RequestContext
RequestContext ~> | inboundA  |~> |         |~> 0~~o broadcast |    +-----------+   |   |           |
                  |           |   |         |   |  |           |                    |   +-----------+
                  +-----------+   |         |   |  |           | ~> +-----------+   |
                                  | inbound |   |  +-----------+    |  filter   |   |
                                  | outbound|   |                   |  aborted  |   |
                  +-----------+   |   B     |   |  +-----------+