マイクロサービスアーキテクチャを読んだ。

マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャ
posted with amazlet at 16.07.21
Sam Newman
オライリージャパン
売り上げランキング: 5,636
Amazon.co.jpで詳細を見る

所感としては、カバー範囲が意外と広範囲だったのと、日本で流行っているものとUSで流行っているものの違いのおかげか、知らないプロダクトや技法などについて書いてあって勉強になった。 パラパラと読んでしまったので、もう１度読んで深掘りしたいかもしれない。

以下、ハイライトしてた文章を引用。すでに自分が知ってたり、考えたことがあったものについてはハイライトしてない。

  • いろいろな意味で、マイクロサービスに分解したい既存のコードベースがある方が、最初からマイクロサービスに取り組むよりはるかに簡単です。
  • 組織に存在する境界づけられたコンテキストについて考える際、共有するデータの観点ではなく、そのコンテキストが残りのドメインに提供する機能について考えるべきです。
  • １つのマイクロサービス内ではDRYを破らないけれども、すべてのサービスにわたるDRYの違反には寛大に対処します。
  • 私が気に入っており、適切に機能しているのを見たことがあるモデルは、図4-10に示すようにこのようなバックエンドの仕様を特定のユーザインタフェースやアプリケーションに制限する方法です。このパターンは BFF: Backends for Frontends と呼ばれることもあります。
    • 補足: APIゲートウェイについて語っていて、デバイスの種別ごとに（モバイル、ウェブなど)ゲートウェイを作るのが良いと言っている
    • そもそもとしてゲートウェイが必要なのは、複数のAPIリクエストを１つに束ねるなどしたいため
  • BFFには、特定のユーザエクスペリエンスの提供に特化した振る舞いだけを追加すべきです。
    • バックエンドが使うさまざまな機能のビジネスロジックは、サービス自体の中にとどまるべきです。
  • ファサードサービスを使って基盤となる大きく恐ろしいCRM(Salesforceのような)を隠す
    • 基盤となるCRMを移行できるようにしておく
  • 合成監視
    • 補足: ピタゴラスイッチ的なシステムの end-to-end な監視。テストジョブをエンキューして期待通りに最後まで処理が行くか
  • フィーチャーチームとは、小規模なチームが一連の機能開発を推進し、たとえコンポーネント（さらにはサービス）境界を超えても、必要なすべての機能を実装するという考え方です。
    • 複数の異なるチームにまたがる変更を調整するという課題を避けられます
    • しかし、サービス管理者の役割はずっと複雑です。
  • たとえ制御できたとしても、ほとんど制御できないキャッシュが１つあります。それはユーザのブラウザのキャッシュです。
    • 補足: Expires: Never を食わせてしまい、URLを変えるしかなかった事案が紹介されていた
  • サーキットブレーカー: 下流リソースへの特定の数のリクエストが失敗すると、サーキットブレーカーが落ちます。サーキットブレーカーが落ちている間は、すべてのリクエストがすぐに失敗します。特定の時間の経過後、クライアントはリクエスト送信して下流サービスが復旧しているかを確認し、十分に健全なレスポンスを得たら、サーキットブレーカーをリセットします。
  • swaggerでサービスの文書化
  • Consumer Driven Contract
  • Suro
  • Riemann - Distributed Monitoring System