Goの学習ネット/コンテキスト

Goを使用する主なニッチがネットワークサービスであることは周知の事実です。あらゆる種類のサーバー、バックエンド、マイクロサービス、分散データベース、ファイルストレージです。 このクラスのプログラムは、ネットワーククエリを非常に積極的に使用します。必要な機能はすべて標準ライブラリにありますが、ネットワークアーキテクチャの開発の1つの側面は、多くのクエリコンテキストのダークスポットのままです。 この記事では、この側面を詳しく見て、このツールがいかに強力で重要であるかを示したいと思います。

コンテキストとは何ですか？

主な質問から始めましょう-これはどのような概念、「コンテキスト」ですか？ このコンテキストは、トートロジーに申し訳ありませんが、コンテキストはAPI関数の境界間で送信されるオブジェクトに関する情報です。 通常、オブジェクトはネットワークリクエストを意味し、APIの境界は異なるミドルウェア、異なるパッケージ、抽象化の層を意味しますが、「コンテキスト」の概念はネットワークリクエストだけに固有のものではありません。 ただし、この記事では主にそれらについて説明します。



典型的な例は、JWTトークンからユーザー情報を抽出し、この情報をハンドラーに渡して、アクセスの確認、ログへの書き込みなどを行うことです。



このコンテキストの概念は、少なくともネットワーククエリでは、多くの言語とフレームワークで利用可能です-C＃ではHttpContext 、Java Netty では-ChannelHandlerContext 、Python Twisted では-twisted.python.contextなど。

コンテキストを移動

Go標準ライブラリには優れたHTTPスタックがあり、 「10K接続の問題」を恐れることなくマルチスレッドサーバーをすばやく作成し、 Handlerインターフェイスを使用してさまざまなリクエスト処理スクリプトを簡単に実装できます。 ただし、標準ライブラリにはhttpハンドラーのコンテキストはありません。



しかし、Goは、メインの標準ライブラリに加えて、Goの著者から、メインのGoコードの外部で開発され、標準ライブラリのように下位互換性のハード約束を持たないパッケージの別個のグループを持っています。 これらはすべてgolang / x /にあるパッケージです。 その中でも、長い間、コンテキストの本質を実装するネット/コンテキストパッケージがあり、これについては本日お話しします。 執筆時点では、 GoDocによると 、このパッケージは1560パッケージですでに使用されています。



一部には、標準ライブラリにコンテキストがないため、Webフレームワークの動物園全体が出現し、それぞれが独自の方法でリクエストコンテキストを送信する問題を解決しました。

Zooフレームワーク

「zoo」という言葉を使うと、特に問題はないので、少し誇張します。 標準のnet / httpは基盤としては良いですが、何らかのWebサービスの記述を開始するとすぐに、より高度な機能（グループ化、高度なロギング、承認処理、アクセス制御などの複雑なルーティング）を実装する必要が生じます、そしてこれは当然一種のフレームワークに変わります-多くの人はきっと同じ機能を必要とし、同じアプローチが彼らの好みになります。 しかし、全体として、通常、最も人気のあるフレームワークがいくつかあり、それらは時々変更され、ゼロメモリの割り当てと速度で競合します 。 今、人気のヤシは、 ジンゴニックのようなものです 。



各フレームワークは、独自の方法でコンテキストを渡す問題に取り組みました。 GorillaToolkitは、各要求の値のグローバルマップを保持し、mutexで要求を保護します。 Gojiとその他のユーザーは、リクエストごとに個別のマップを保持しています。 gocraft / webは、リフレクションを通じてコン​​テキストを処理します。 前述のGin- Contextは、一般的にすべてのハンドラーが機能するキー構造です。 エコーでは、コンテキストの概念は一般に、リクエスト処理のすべての機能にかかっています。



これらのアプローチにはそれぞれ長所と短所がありますが、すべてにマイナスの1つがあります-フレームワークへのバインドです。 上で述べたように、コンテキストはかなり抽象的な概念であり、http-requestに限定されません。 これを例で見てみましょう。

例

簡単なWebサービスから始めましょう。

package main import ( "net/http" ) func handler(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hello World")) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":1234", nil) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 $ curl http://localhost:1234 Hello World
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ここでは、PINコードによるプリミティブな承認が必要でした。http.HandlerFuncを使用して簡単なミドルウェアを作成します。

 func needPin(h http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { if r.FormValue("pin") != "9999" { http.Error(w, "wrong pin", http.StatusForbidden) return } h(w, r) } } ... http.HandleFunc("/", needPin(handler)) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 $ curl http://localhost:1234 wrong pin $ curl http://localhost:1234?pin=9999 Hello World
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すばらしいですが、ハードコードではなく、SQLデータベースからピンを読み取る必要があります。 OK、今のところ、* sql.DBグローバル変数を追加します。

 func needPin(h http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { var pin string if err := db.QueryRow("SELECT pin FROM pins").Scan(&pin); err != nil { http.Error(w, "database error", http.StatusInternalServerError) return } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、私たちの要件と欲望のリストが大きくなり始めます。

• 間違ったPINコードで各リクエストをsyslogに記録することは可能ですか？
• ただし、IPアドレスを確認して記録することはできますか？
• しかし、異なるIPに対してシャーディングを実行し、異なるデータベースで実行できますか？
• できますか...？

「もちろんできます」新しいタスクごとにミドルウェアを考えて記述し、それらをチェーンで組み立て始めます。 Aliceなど、このための個別のパッケージもあります。 しかし、authMiddlewareからlogMiddlewareに認証エラーを渡す方法は？ また、一時的なパスワードのためにVaultで実行する必要がある場合、最初にセッションからトークンを抽出しますか？ しかし、グローバル変数を取り除き、データベース接続オブジェクトをハンドラーに渡す方法は？



ここで、コンテキストの概念が役立ちます。 各ミドルウェア関数は、その値をコンテキスト変数に設定し、リクエストとコンテキストをさらに渡します。 許可ステータス、ユーザー名、アクセス許可、初期リクエストのヘッダーから取得した情報、データベース接続へのポインター、さらに追跡するための一意のIDなど、このコンテキストに自由に入力できます。



通常、context.Contextはパラメーターとして関数に渡されます（ミドルウェアと要求で機能する関数の両方）。 原則として、コンテキストを構造体フィールドとして保存できますが、コンテキストはリクエストに結び付けられる必要があるため、これは慎重に行う必要があります。リクエストごとに作成され、リクエストの処理後に削除されます。



しかし、 ネット/コンテキストは値を保存するだけでなく、タイムアウトを管理してリクエストをキャンセルするための統一されたアプローチでもあります。 もっと詳しく見てみましょう。

内側からのネット/コンテキスト

ネット/コンテキストAPIは少し珍しいので、最初は驚くかもしれません。



ここでは、Goで複雑なリクエスト処理パイプラインが通常どのように作成されるかを理解することも重要です。これは通常、1つのリクエストを受け入れるゴルーチンで、このリクエストまたはリクエストのストリームを処理する1つ以上のゴルーチンを生成し、結果をトップに返します。 これは、関数の単純な同期呼び出しとして、場合によっては個別のパッケージに間隔を空けるか、チャネルを送信する新しいゴルーチンとチャネルのカスケード全体として実行できます。 主なものは、各ミドルウェア、各パッケージの責任の明確な境界があり、それぞれが要求について何かを知りたい、そしてそれについて何かをしたいということです。



したがって、ネット/コンテキストの最初の主要な原則は、 コンテキストがネストされ 、ツリー構造を持っているということです。 実際、net / contextパッケージの主な機能はそれを行います。 既存のコンテキストから新しいコンテキストのバリエーションを作成し、新しい「サブコンテキスト」を生成します。

 func Background() Context func TODO() Context func WithCancel(parent Context) (ctx Context, cancel CancelFunc) func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc) func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) func WithValue(parent Context, key interface{}, val interface{}) Context
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の重要な点は、context.Contextがインターフェースであり、net / contextパッケージが提供するバリエーションはわずかであるが、複雑なコンテキストを自由に作成できることです。

 type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key interface{}) interface{} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

既存のコンテキストの主なタイプを見てみましょう。

• context.Background（）は空のコンテキストであり、値もタイムアウトもキャンセルもありません。 通常、Background（）は、最初に着信要求を受信する関数で使用され、後続のすべての派生要求の基礎となります。
  
  camilstoreの例を次に示します。
  
  

   client := oauth2.NewClient(context.Background(), google.ComputeTokenSource(""))
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• context.TODO（）も特別なコンテキストであり、空ですが、使用するコンテキストが明確でない場合、またはコンテキストを受け入れるように関数がまだリファクタリングされていない場合に使用されます。 静的コードアナライザーがこのケースを簡単に見つけられるように、TODO名が特に選択されました。 ただし、現時点では、コンテキストを分析するリンターはまだオープンソースではありませんが、Google上にあり、今後もオープンになる予定です。
• context.WithCancel（親コンテキスト）（ctxコンテキスト、CancelFuncのキャンセル） -新しいDoneチャネルとこのチャネルのクローズを開始するCancelFunc関数を含む親コンテキストのコピーを返します。
  
  仕組みを見てみましょう。
  
  

   func handler(w http.ResponseWriter, r *http.Request) { //      ctx, cancel = context.WithCancel(context.Background()) defer cancel() //         Done,    go func() { time.Sleep(1 * time.Second) ctx.Done <- struct{}{} }() //     res, err:= startLongQuery(ctx, w) if err != nil { http.Error(w, "cancelled", http.StatusInternalError) return } // ...encode res to json w.Write(encodedResult) } func startLongQuery(ctx context.Context, w http.ResponseWriter) (*Result, error) { resCh, transport := runLongQueryToJavaService(someArgs) select { case <-ctx.Done(): //       transport.CancelRequest(req) <-resCh return nil, ctx.Err() case result := <-resCh: //   ,   Done,   return Result{result}, nil } }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  この例は意図的に簡略化されており、タイムアウトにコンテキストを使用する方法は以下で説明しますが、考え方は明確である必要があります。
  
  強制キャンセルは、たとえば、異なるサービスレプリカへの同時リクエストの場合に便利です。最速のレプリカの応答後、残りのリクエストはリソースが無駄にならないように安全にキャンセルできます。
• context.WithTimeout（親Context、タイムアウトtime.Duration）（Context、CancelFunc）およびcontext.WithDeadline（親Context、deadline time.Time）（Context、CancelFunc） -WithCancel（）に似ていますが、タイムアウトまたは達成後に終了します締め切り。 実際、WithTimeoutは、パラメーターtime.Now（）。Add（timeout）を持つWithDeadlineです。
  
  
  
  WithCancelの仕組みを理解していれば、これら2つの機能に問題はないはずです。 上記の例は数行簡略化されており、次のようなことができます。
  
  
  
  

    timeout, err := time.ParseDuration(req.FormValue("timeout")) if err == nil { ctx, cancel = context.WithTimeout(context.Background(), timeout) }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  長いリクエストを待つ時間を示します。
• context.WithValue（親コンテキスト、キーインターフェイス{}、valインターフェイス{}）コンテキスト -上記のコンテキストに関連するデータまたはリソースを保存するタスクに使用されます

context.WithValueについてもう少し

上記のフレームワークとは異なり、ネット/コンテキストは、ツリーベースのネストされたアーキテクチャのため、マップまたは同様のデータ構造を使用しません。 1つのコンテキストには、1つの値と親コンテキストが含まれます。 新しい意味-これはすでに新しいコンテキストです。 キーと意味自体の両方は、どのタイプでもかまいません。



これを使用するための標準的なメカニズムは次のとおりです。キーは、コンテキストで動作できる他のパッケージ/ APIとの衝突を避けるために、エクスポート不可能なタイプでなければなりません。 例：

 package userIP // ,       type key int //   IP .         - ,    . const userIPKey key = 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

値自体のコンテキストは次のようになります（https://github.com/golang/net/blob/master/context/context.go#L433）：

 type valueCtx struct { Context key, val interface{} } //   Value   func (c *valueCtx) Value(key interface{}) interface{} { if c.key == key { return c.val } return c.Context.Value(key) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、任意のコンテキストの入れ子を使用して、Value（）は、目的の型の目的の値が見つかるまでコンテキストツリーを上に移動します。 まあ、または、nilを返すのは、Value（）がすべてのコンテキストに対して定義されているためです（覚えているように、Contextはインターフェイスであり、したがって、Backgroundコンテキストに対しても定義されています）。



コンテキスト値で機能するサンプルパッケージの完全なコードは、次のようになります。





何をどのようにコンテキストに入れるかは、特定のタスクに依存します。 単純なユーザーID、内部に多くの情報を含む複雑な構造、またはデータベースを操作するためのsql.DBのようなオブジェクトのいずれかです。

パン

コンテキストをユニバーサルインターフェイスとして実装すると、他のフレームワークのコンテキストを使用するコードがnet / contextを使用するコードとフレンドになります。



gorilla / contextを使用したコンテキストの例： blog.golang.org/context/gorilla/gorilla.go



そして、これが別のフレームワークであるtombでリクエストをキャンセルする例の例です： blog.golang.org/context/tomb/tomb.go



または、Dapperスタイルでリクエストの寿命を追跡するためにコンテキストを使用する例として、 net / traceパッケージ。 親コンテキストはcontext.WithValue（ctx、trace）を生成し、リクエストの処理中に生成されるすべての後続の呼び出しとコンテキストにはトレースIDが含まれ、既にネット/トレースコードにはWebページのトレースに関する情報を提供する必要なハンドラーが含まれていますパス/ debug / requestsおよび/ debug / events 。



明らかに、最大の利点は、外部リソースと通信するか、新しいゴルーチンを生成するすべてのコードがネット/コンテキストを使用する場合です。 たとえば、GoのGoogleコードベースは既に約1,000万行のコードを持っていますが、どこでもcontext.Contextを使用しています。 Protobuf3の新しいgPC RPCフレームワークは、Goのコードを生成するときに、どこでもcontext.Contextを渡します。

今後の計画

ネット/コンテキストの将来の計画について活発な議論があり、Go 1.7の標準ライブラリにコンテキストが表示される可能性があります。 おそらく小さな変更があり、おそらくないかもしれませんが、いずれにせよ、興味と欲求があるので、あなたは指を脈打つべきです。



標準ライブラリはそれ自体で下位互換性があり、コードベースを断片化しないようにhttpとctxhttpに分割するようなことはありません（ ctxhttpパッケージは現在実験として存在しています）。 Contextフィールドがhttp.Requestに追加されるか、他のオプションが表示される可能性があります。



net / contextからのnetという単語は消える可能性があります。

参照資料

より詳細に理解し、例を参照したい場合は、次のリンクを強くお勧めします。



Good Goブログコンテキスト記事-blog.golang.org/context

GothamGo 2014コンテキストに関するトーク-vimeo.com/115309491

http.Handlerとnet / contextに関する別の記事はjoeshaw.org/net-context-and-http-handlerです

トピックネット/コンテキストに関する優れたレポートの詳細なスライド-go-talks.appspot.com/github.com/guregu/slides/kami/kami.slide#1

Goの高度なパイプラインとキャンセルに関する記事-blog.golang.org/pipelines

さまざまなフレームワークでのコンテキスト実装の概要-www.nicolasmerouze.com/share-values-between-middlewares-context-golang

ソースコードネット/コンテキスト-github.com/golang/net/tree/master/context