4.1.3 ThriftとProtocol Buffers

「データ指向アプリケーションデザイン」輪講資料

Transcript

1. データ指向 アプリケーションデザイン 4.1.3 ThriftとProtocol Buffers
2. Apache Thrift https://thrift.apache.org/ 「スケーラブルな言語間サービス開発」のためにFacebookにて開発された 遠隔手続き呼び出し (RPC) フレームワーク .thriftファイルにRPCを定義し、それをもとにやり取りする 対応言語: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages. 今回はサーバをNodejs,クライアントをRustにしてping pongしてみる
3. .thrift ファイルを書き、コードを生成 コード生成（Rust） コード生成（Nodejs）
4. Thriftのネットワークスタック - Protocol 例: Binary,Compact, JSON - Transport 例: Buffered, Framed
5. 実装 protocolとtransportを揃える
6. Protocol: Binary, Transport: Buffered
7. Protocol: Binary, Transport: Framed
8. Protocol: Compact, Transport: Framed
9. 82 21 02 04 70 69 6e 67 18 04 70 69 6e 67 00 4文字 Compact Protocolでエンコードされたものを読む 第一引数”ping”“\0” 終端を表す 4文字 rpc名”ping” 0 0 0 1 1 0 0 0 フィールドタグ1 種類8（文字列）
10. スキーマの進化と互換性 スキーマで重要なものは - rpcの名前 - フィールドタグ番号とその型 だとわかった 前方互換性及び後方互換性を保ったままスキーマを変更したい 前方互換性 ：古い製品がより新しい製品の機能やデータ形式を扱うことができること 後方互換性 ：新しい製品が古い製品の機能やデータ形式を扱うことができること
11. フィールドタグとスキーマの進化 必須ではない（もしくは初期値が設定できる）フィールドを追加すればよい そのフィールドには新しいフィールドタグ番号を割り当てる - 古いシステムが新しいスキーマを読む場合（前方互換性） 知らないフィールドタグ番号はスキップされるので問題ない - 新しいシステムが古いスキーマを読む場合（後方互換性） 新しいフィールドは必須ではないので問題ない
12. データ型とスキーマの進化 Thriftのドキュメントを調べた限り 型を変更してもキャストされるとは書いていないので、 スキーマの型を変更するのはやめたほうがよさそう 新しいフィールドタグ番号を割り当てた、別のフィールドを用意したほうが良い
13. Appendix 以降、Protocol Buffers ( https://developers.google.com/protocol-buffers/ )の説明 gRPC ( https://grpc.io/ ) はProtocol Buffersを使うRPCフレームワーク gRPCは比較的有名なフレームワークだが、今回は紹介せず、 Protocol Buffers のみ紹介する
14. Protocol Buffers https://developers.google.com/protocol-buffers 構造化されたデータを シリアライズ・デシリアライズするライブラリ .protoファイルに構造化されたデータを記述する Goの場合 を実行してコードを生成する
15. Protocol Buffersを使ったシリアライズ 実行結果 “Taro” “taro@taro.com” 1 4 13 0 0 0 0 1 0 1 0 フィールドタグ1 種類2（文字列）