目次
1. モノリシック アーキテクチャ VS マイクロサービス アーキテクチャ
1. モノリシック アーキテクチャ VS マイクロサービス アーキテクチャ
1. モノリシックアーキテクチャ
(1). モノリシックアーキテクチャの利点
- シンプルなアーキテクチャ
- 開発、テスト、展開が簡単
(2).モノリシックアーキテクチャのデメリット
- コードの冗長性と不均一な品質により、運用とメンテナンスが非常に複雑になります
- デプロイメントは低速、完全なデプロイメント、低頻度であり、コードの量が多い場合にはより顕著になります。
- 拡張機能が限られている
- 技術革新を妨げ、コードのリファクタリングのリスクが非常に高い
2.マイクロサービスアーキテクチャ
(1) マイクロサービスの特徴
- 各マイクロサービスは独自のプロセスで実行できます。つまり、各マイクロサービスには独自の Tomcat があります。
- 各マイクロサービスは独立して実行でき、連携してシステム全体を構築できます。
- 各サービスは独立したビジネス向けに開発されており、マイクロサービスは注文管理やユーザー管理などの特定の機能のみに焦点を当てています。
- さまざまな言語やデータストレージ技術を利用可能（プロジェクトの状況やチーム力に合わせて）
- マイクロサービスは、REST API を介した呼び出しなどの軽量の通信メカニズムを通じて相互に通信します。軽量の通信メカニズム、通信プロトコルは軽量でクロスプラットフォームである必要がある
- 完全に自動化された展開メカニズム。ビルド、デプロイメント、テストなどを自動化します。
(2) マイクロサービスアーキテクチャ図
(3) マイクロサービスのメリット
- 単一のサービスは開発/保守が容易ですが、単一のサービスではビジネスが限定されます。
- 単一のマイクロサービスがすぐに開始される
- ローカルでの変更は簡単に導入できます
- 無制限のテクノロジースタック
- オンデマンドで拡張可能
(4) マイクロサービスのデメリット
- 運用および保守の要件は高く、複数の jar を運用および保守する必要があるため、完全に自動化された運用および保守の展開メカニズムが必要です。
- 配布に固有の複雑さ
- 重複した作業、同じ開発言語で合計の共通モジュールを抽出できますが、異なる言語で実装することは不可能であり、やはり繰り返す必要があります
(5) マイクロサービスの適用シナリオ
- 大規模/複雑なプロジェクト。アプリケーションがモノリシック アーキテクチャで処理できる場合は、それを過剰に処理する必要はありません。
- 迅速な反復が必要である
- アクセス圧力が高いため、マイクロサービスは分散化されています。
(6) マイクロサービスが適用できないシナリオ
- 事業は安定しており、需要はほとんど変化しない
- 反復サイクルが長く、迅速な反復は必要ありません。
2. マイクロサービスの分割
1. マイクロサービスの分割 -- 方法論
(1 )ドメイン駆動設計 (ドメイン駆動設計)
お勧めの本は次の 2 冊です。
「DDDの元祖」
「ドメイン駆動設計の実装」
(2) オブジェクト指向 (名前別 /動詞 別)
名詞または動詞で分割する
2 マイクロサービスの分割 - 一般的に使用されます
(1) 責任に応じた区分
マイクロサービスの責任の境界を計画し、注文サービスなど、責任の範囲内のビジネスのみに焦点を当てます。
(2) 汎用性で分ける
ユーザーセンターやメッセージセンターなど、汎用的な機能をマイクロサービス化する アリババの大小のプラットフォームは実は汎用性をベースにしているが、中間のプラットフォームは複数のマイクロサービスの集合体である。
3 マイクロサービスの分割 -- 適度な粒度
- ビジネスを十分に満足させる
- 幸福感: チームによるマイクロサービスのメンテナンスは、単一のエンティティほど冗長で複雑に感じられなくなり、デプロイメントが効率的になります。
- 増分反復。各マイクロサービスは比較的独立しており、各リリースは限られた数のマイクロサービスのみです。
- 継続的な進化、テクノロジーの最適化、リスク制御可能
- マイクロサービスの分割は動的であり、時間の経過とともに増加または減少する可能性があります。
3. 実際のプロジェクトプロセス
1. ビジネスの分析 (フローチャート、ユース ケース図、アーキテクチャ図など) 主なタスクは、ビジネス モデリングとアーキテクチャの決定です。
2.業務プロセスの決定（見直し）
3. APIの設計（どのAPIが必要か）/データモデル（テーブル構造の設計 | クラス図 | ER図など）
4.APIの書き込み