Zenn
Open8

#マイクロサービスパターンimpress

gkzgkz

Amazon.co.jp: マイクロサービスパターン[実践的システムデザインのためのコード解説] (impress top gear): Chris Richardson, 樽澤広亨, 長尾高弘: 本

Chapter 1　モノリシック地獄からの脱出
Chapter 2　サービスへの分割
Chapter 3　マイクロサービスアーキテクチャで使われるプロセス間通信
Chapter 4　サーガによるトランザクションの管理
Chapter 5　マイクロサービスアーキテクチャにおけるビジネスロジックの設計
Chapter 6　イベントソーシングを使ったビジネスロジックの開発
Chapter 7　マイクロサービスアーキテクチャでのクエリーの実装
Chapter 8　外部APIパターン
Chapter 9　マイクロサービスのテスト（前編）
Chapter 10　マイクロサービスのテスト（後編）
Chapter 11　本番環境に耐えられるサービスの開発
Chapter 12　マイクロサービスのデプロイ
Chapter 13　マイクロサービスのリファクタリング

cf. https://github.com/gkzz/ReadingParty/blob/main/contents/Fundamentals-of-Software-Architecture/20201227/hackmd.md

gkzgkz

Chapter 1　モノリシック地獄からの脱出

本書で扱うモノリシックなシステムのアーキテクチャ

  • 図 1.1 の解説文より

    • FTGO アプリケーションはヘキサゴナルアーキテクチャになっている。中心にビジネスロジックがあり、モバイルアプリケーションなどの UI や、支払い、メッセージング、メールなどの外部のクラウドサービスとのインターフェイスを実装するアダプタがそれを囲んでいる

アプリケーションをスケーリングするための 3 つの分割方法

  • 図 1.3の解説文より
- X軸: 複数の同じインスタンスを使ったロードバランシングによるスケーリング
- Z軸: リクエストの属性に基づくルーティングによるスケーリング
- Y軸: アプリケーションをサービスに分割することによるスケーリング 
- マイクロサービスとは、Y 軸スケーリング、アプリケーションをサービスに分割することによるスケーリング

SOA とマイクロサービスの比較

  • 表 1.1

マイクロサービスアーキテクチャのメリデリ

  • メリット抜粋

    • 大規模で複雑なアプリケーションの継続的デリバリー/デプロイを可能にする

    • 個々のサービスが小さく、簡単にメンテナンスできる

  • デメリット抜粋

    • サービスの適切な分割方法を見つけるのが難しい

    • 分散システムは複雑であり、開発/テスト/デプロイが難しくなる

CD/継続的デリバリー

gkzgkz

Chapter 2　サービスへの分割

  • 図 2.2

    • ビジネスロジックと 1 つ以上のアダプタ(外部システムとの通信手段)から構成されるヘキサゴナルアーキテクチャの例。

アーキテクチャの観点からマイクロサービスを再定義

  • マイクロサービスアーキテクチャは、複数のコンポート(実行可能ファイル、または WAR ファイル)で実装ビューを構成します。コンポーネントはサービスであり、コネクタはサービスの連携を可能にする通信プロトコル

サービスとは

  • 何らかの役に立つ機能を実装するスタンドアロンの個別にデプロイできるソフトウェアコンポーネント

  • クライアントがサービスの機能を利用するための手段として API を提供

  • 操作には、コマンド 6 ) とクエリー 7 ) の 2 種類があります。 API は、コマンド、クエリー、イベントから構成されています。

  • 図2.4は図にしたもの

アプリケーションをサービスに分割するうえで障害となるもの

  • ネットワークレイテンシ

  • 同期通信による可用性の低下

  • サービス間でのデータ整合性の維持
    など

gkzgkz

Chapter 3　マイクロサービスアーキテクチャで使われるプロセス間通信

プロセス間通信の技術選定

同期的 v.s. 非同期

  • 同期的
    • HTTP ベースの REST や gRPC といったリクエスト/レスポンスベース
  • 非同期的
    • AMQP や STOMP などのメッセージベース

メッセージの形式

  • JSON 、 XML のような人間が読めるテキストベースの形式
  • Avro や Protocol Bufferのような効率のよいバイナリ形式

技術選定時の考慮事項としてのクライアントとサービスのインタラクションスタイル

  • 同期的かつ 一対一
    • リクエスト/レスポンス
  • 同期的かつ 一対多は該当なし
  • 非同期的かつ 一対一
    • 非同期リクエスト/レスポンス
    • 一方通行の通知
  • 非同期的かつ 一対多
    • パブリッシュ/サブスクライブ
    • パブリッシュ/非同期レスポンス

サービスディスカバリ

  • サービスとそのクライアントが直接サービスレジストリを操作する
  • デプロイインフラストラクチャがサービスディスカバリを処理する

メッセージ

gkzgkz

Chapter 4　サーガによるトランザクションの管理

saga

  • サーガは、メッセージ駆動のローカルトランザクションのシーケンスです。サーガは、 ACD 、すなわち原子性、整合性、持続性を保証しますが、 ACID トランザクションの I 、分離性をサポートしません。

  • サーガの実装は、サーガのステップをコーディネートするコードから作られています。

saga 分散トランザクション - Azure Design Patterns | Microsoft Docs より

  • Image from Gyazo

sagaコーディネートを実装する2つの方法

  • オーケストレーター
    • Image from Gyazo
  • コレオグラフィ
    • Image from Gyazo
gkzgkz

Chapter 5　マイクロサービスアーキテクチャにおけるビジネスロジックの設計
Chapter 6　イベントソーシングを使ったビジネスロジックの開発
Chapter 7　マイクロサービスアーキテクチャでのクエリーの実装

gkzgkz

Chapter 8　外部APIパターン

モノリシック(略)なら、 1 度のリクエストだけでオーダーの詳細情報を取得できる。しかし、マイクロサービスアーキテクチャ移行後は、同じ情報を得るために何度もリクエストを送らなければならない

  • そこで、API GW(アダプター、ルーティングなどのニュアンス)登場
  • 各サービスの責任の分界点を決める難しさというお話
  • 同書は共通部分はAPI GWチーム、各サービスそれぞれのAPIモジュールはチームごとに開発することを提案。

、、とこれは以前読んだ↓だった。。綺麗にサービスを分割できることはないだろう。下記の記事でいう「管理画面」はどういうするのか？

リアクティブプログラミングの必要性

  • 背景には非同期コールバックで書いていくと、コールバック地獄にハマりかねないとのこと

  • An event-driven/reactive approach is best if it must scale to scale to handle high loads.

  • ユーザーにとって直接的に価値があるのは「即応性」 であり、それを常に保つために「耐障害性」「弾力性」が必要であり、それらは「メッセージ駆動」を基盤とすることで実現される

ブローカーレスアーキテクチャ

サービス同士が直接メッセージをやりとり

  • 可用性が下がるとかサービスディスカバリが必要になるといったことは、同期的なリクエスト/レスポ
    ンスを使ったときと同じ欠点です。これらの欠点があるため、エンタープライズアプリケーションの大半
    はメッセージブローカーベースのアーキテクチャを使っています。

ブローカーベースアーキテクチャ

各サービスはブローカーを介してメッセージをやりとり

  • サポートされているプログラミング言語

  • メッセージの順序

  • 配信保証

  • 永続記憶

    • ブローカーがクラッシュしても、メッセージはディスクに書き出されているので生き残るか

  • 持続性

    • コンシューマがメッセージブローカーに再接続したとき、切断中に送られてきたメッセージを受信できるか

  • スケーラビリティ

    • エンドツーエンドのレイテンシ

  • 競合するコンシューマをサポートするか

  • 表 3.2

    • メッセージチャネルの実装方法はメッセージブローカーによって異なる
gkzgkz

Chapter 9　マイクロサービスのテスト（前編）

  • 図 9.9 オーダーサービスのためのデプロイメントパイプラインの例。パイプラインは一連のステージから
    構成されている。コミット前テストは、コードをコミットする前に開発者が実行するテストである。その他のステージは、 Jenkins CI サーバーなどの自動化ツールによって実行される