Independently Deployable and Fully Contained †
序文 †
- マイクロサービスアーキテクチャはスケールされた開発を容易にすることができる。
- この技術によって、巨大でない開発者チームが多くの機能と一枚岩の独立したレイヤーの責務を負うことができる。
- しかしながら、開発チームは他の要求を満たさないといけなくなる。サービスは独立してデプロイ可能でなければならないからだ。
- 開発チームは 個々のサービスの全コントロールの全ての責任を負う。
- 他の恩恵としては、このデザインパターンは障害の隔離を行うことができる。
- メモリリークによる他のサービスへの影響を防ぐことができる。
Crosscutting Concerns †
- クロスカッティングの問題は特定のレイヤーに関連しないソフトウェアデザインのキーエリアの問題だ。
- ドメイン駆動開発ではこれは起こらない。
- しかし、開発者がプロジェクト全体でドメインでない再利用を行いたい場合は、依存性注入やオリエントテッドプログラミング(AOP)を使うことができる。
Security †
- マイクロサービスアプリケーションのセキュリティは3つの異なるレベルがある。
- アプリケーションレベル・ユーザレベル・ネットワークレベルの3つになる。
- アプリケーションレベル
- ユーザがどのロールに属しているか、またはシステムのエントリーポイントにアクセスできるかを認可する。
- ユーザレベル
- ユーザのクレデンシャルやトークンのサービスにマップするもの。
- または特定のサービスに関連したロールに紐づけるものだ。
- 基本的は2つの異なるアプローチがある。クレデンシャルやトークンにダウンストリームを含めるか、必要な時にそれを付与するか
- 両方のメソッドはメリットとデメリットがある。
- 最後がネットワークレベル。
- ネットワークレベルのセキュリティのエンタープライズが重要なレイヤーがある。
- 開発者は不正なアクセスを許可しないように実装しなければならない。
Logging †
- ロギングはエンタープライズの環境において、基本的なニーズだ。
- ユニークなサービスリクエストIDかHTTPセッションやSSLセッションIDが助けとなる。
- syslogを使うか、中央集権的なソリューション(Elastic Search / Logstash / Kibana)を使うことができる。
Health Checks †
- ヘルスチェックはDevOps?において重要。
- かなり最初の段階から全ての部分でコントロールかつモニターされる必要がある。
- しかしながら、この要求を満たす異なるアプローチも存在する。
- シンプルなアプローチはAPIマネージメントソリューションを選ぶこと。
Integration Testing †
- 統合テストはJava EEアプリケーションにて重要だが複雑。
- 通常テストはモジュールのコールまたは開発者のテストによって行われる。
- 最初に正しいインフラが必要になる。様々なチームのための統合システムと完全なテストを含みます。
- マイクロサービスではエンタープライズ領域で成功するには、PaaSが必要になる。
- それは容易にインスタンスを出現させることができるし、コスト的にも効率的。
- この目的を果たすために、統合テストフレームワークが存在します。
- もっとも完全なものはArquillianとともにCube拡張。
- 上記はPaaSとともにローカルインスタンスやコンテナーの上で統合テストを実行できる。
担当者のつぶやき †
みんなの突っ込み †
