Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Comparison between Golang microservices frameworks

Comparison between Golang microservices frameworks

GoCon 2016 Springにて

y_matsuwitter

April 23, 2016
Tweet

More Decks by y_matsuwitter

Other Decks in Programming

Transcript

  1. 2 ©Gunosy  Inc. ⾃自⼰己紹介 n Gunosy  Inc. – 開発本部執⾏行行役員 n

    業務 – 開発全般のマネジメント – Go⾔言語布教係 – パフォーマンスチューニング – ISUCONとか好きです n 担当 – 右⼿手でiOS、左⼿手でAndroid – Web – Infrastructure(AWSのみ) n 最近の興味 – HTC  Viveに感動した 松本 勇気 @y_̲matsuwitter
  2. 4 ©Gunosy  Inc. 今⽇日の話 n マイクロサービスフレームワークを知る n kit,  gizmo,  micro

    n Tracerの観点から n 最後に Go⾔言語のマイクロサービスフレームワークの紹介
  3. 5 ©Gunosy  Inc. マイクロサービスフレームワークを知る Microservices FWに触れることで必須な要素を知ることができる n 運⽤用にはモノリシックと⽐比べてより複雑な考 え⽅方が必要 –

    ログ収集 – サービスディスカバリ – ロード・バランシング – プロトコル – メトリクス管理理 – APIクライアント提供 – …etc n 現状のチームではAWSに頼りつつ、こうした 機能をまかなっている状況 単にRPCでつなぐだけがマイクロサービスではない。 API Gateway Auth Content Log
  4. 6 ©Gunosy  Inc. GoでのMicroserviceフレームワーク go-‐‑‒kit/kit gizmo micro n 3854star n

    他⾔言語との協調も睨み つつ、⼤大規模な micorserviceの運⽤用を サポート n Pluggableで多くのプ ロトコルをサポート n Pub/subなどはサポー トしていない n 1345star n NYタイムズが開発元 n Config,  service,   pubsubの3つを提供 n 軽量量、基本的な機能以 外はミドルウェアを通 じて実装する n 多数のrepoに分割 n microservicesに必要 な多くの機能をmicro ⾃自⾝身で開発している n 最もfullstackなFW n Go以外の⾔言語との協調 n Dockerによる動作環境 なども提供している Go⾔言語でのmicroservicesフレームワークはその他にもKiteなど登場 go-‐‑‒kit,  gizmo,  microの3つを⾒見見てみた
  5. 7 ©Gunosy  Inc. Tracerに⾒見見る各フレームワークの考え⽅方 n Tracing packageにて 提供 n 基本機能はZipkinへの

    tracingパラメタ送信 n ⾃自⾝身で定義したService を、zipkin packageに annotation付けてもら う形式 kit n Tracer機能は持たない n Readmeによれば、 middlewareとして⾃自⾝身 で作成・追加するとの こと n 軽量量なライブラリであ ることがわかる gizmo n Micro⾃自⾝身がtrace-‐‑‒srv を持ち各サービスから 投げる n 各サービスはgo-‐‑‒ platform/traceという ⼦子パッケージを利利⽤用 n KafkaなどのBrokerを 間で利利⽤用する n “Full-‐‑‒stack!!!” micro フレームワークごとに⽤用意しているレイヤーが異異なっている Tracer  =  障害発⽣生時にどういった経路路のアクセスがあったか追跡するもの
  6. 8 ©Gunosy  Inc. 最後に GoのMicroservicesフレームワークからエッセンスを汲み取ろう Microservicesは銀の弾丸ではない、モノリシックとの間で悩もう Microservicesにおいて考えること グノシーでのmicroservicesの現状 n 複雑なサービス依存を管理理する⽅方法

    – 多くのGo製フレームワークから 学ぶことができる n 本当にサービスを分割するべきか – 登場するドメインが少ないシステ ムでモノリシックから移⾏行行する必 要はない n 多数のシステムから単⼀一のデータを触 る際の拘束具としてのサービス分割 n Opsworksの運⽤用が確⽴立立しているゆえ の⼤大量量のサービス管理理 n より適切切な解を模索索している