マイクロサービスの利点
- 独立した展開。自分自身で、他のサービスの展開の影響をコントロールしていない、他のサービス、低カップリングには依存しないでください。
- 開発とメンテナンスのしやすさ：特定の事業に焦点を当て、ビジネスは明確な、少ないコードであるので、モジュールは開発が容易になり、簡単に維持することが容易で、理解すること。
- ブートブロック：以下の機能、より少ないコードなので、保守サービスのためにダウンする必要があり、速い開始は、長い時間のために中断されることはありません。
- 部分的な修正は簡単：ちょうどアジャイル開発のための適切なサービスを展開する必要があります。
- テクノロジースタック無制限ます。java、Node.jsの、など
- オンデマンドでスケール：限定されているサービスは、需要がメモリ、CPUを増やすなどがあります。
- 特定の責任。特別な操作を担当する専門チームは、チーム部門を助長しています。
- コードは再利用します。書き込みは繰り返す必要はありません。基本的な実装は、インターフェースを介して提供されます。
- チームワークを促進する：良いAPIの定義は、並行して開発することができた後、各チームは、ライン上のAPIを提供する必要があります。
2.マイクロ短所サービス
-
分散型固有の複雑さ：フォールトトレランス（サービスのダウンタイム）、ネットワーク遅延、等分散トランザクションなどの関係を、呼び出しは、複雑もたらすでしょう。
-
分散トランザクションの挑戦：各サービスは、独自のデータベースを持って、少し異なるサービスは彼らのビジネスのためのデータベースを選択することができるということです。MySQLで受注し、MongoDBのことで他のコメント。現在、最善の解決策は、次のとおりです。結果整合柔軟な取引。
（リジッドサービス：ACIDは強い整合性の原則に従ってください。
柔軟なトランザクション：BASEフォロー理論、最終的一貫性、異なるトランザクションを剛体、柔軟な取引は、異なるノードに一貫性のないデータを一定の期間を許可するが、最終的な合意が必要で。
BASEは、基本的に利用可能です略語.BASE理論（利用可能な塩基性）、ソフト状態（ソフト状態）、最終的に一貫性のある（最終的な一貫性）CAPの三個のフレーズ、APの拡張であり、一部は許可に失敗した場合、強い整合性の可用性を犠牲にすることによって得られます使用可能ですが、我々は呼んデータが時間をかけて一貫性のないことをできるように、コア機能が使用可能であることを確認、しかし最終的には一貫性のある状態に到達する。会う総務BASE理論、「柔軟な取引」ではありません）
3.インタフェース高調整コスト：インタフェースの変更は、呼び出し側は、変更する必要があります。
4.テストの難易度リフティング：インタフェースの変更は、すべての発信者がメジャーに持っていました。自動テストが重要となります。管理APIドキュメントも重要です。推奨：YAPI。
5.操作と保守が高い必要：数百のサービスを維持する必要性を。監視が複雑になります。また、複数のクラスタ上の焦点に、元のモノマーとは異なり、通常の動作を適用することができます。
繰り返し作業6.：Javaクラスなどのツールをすることができますが、多言語での作業は、common.jarを共有しない、C ++は、直接Javaのjarファイルのパッケージを使用することはできません。
3.技術の選択
春の雲やコンポーネントを比較ダボ
ダボ：飼育係+ダボ+ springmvc / springboot
通信：RPC
レジストリ：飼育係、ナコス
構成センター：ダイヤモンド（淘宝開発）
スプリングクラウド：スプリング+ Netflixの
通信：HTTP安らか
レジストリ：ユーレカ、領事、ナコス
構成センター：設定
ブレーカ：hystrix
ゲートウェイ：zuul、ゲートウェイは、
追跡システムを分散型：スルース+ zipkin
