OSGiとマイクロサービスは同じアーキテクチャスタイルを共有しますが、粒度が異なります。実際、Webがその名前を盗むまで、OSGiサービスのマイクロサービスを呼び出していました。現在、時々nanoservicesと呼んでいます。
（micro | nano）servicesの原則は、明確に定義された[〜＃〜] api [〜＃〜]でgateを介してモジュール間の通信をトンネルすることです。 APIは実装とは無関係であるか、少なくともそうである必要があるため、他のモジュールに影響を与えることなく1つのモジュールを変更できます。最も重要な利点の1つは、大規模なシステムの設計でも、サービス図を見ると理解しやすいことです。ある意味では、サービスベースの設計はシステムの本質を捉え、モジュールの詳細を残します。
Web /マイクロサービスでは、gateは通信エンドポイント（たとえばHost：port）およびプロトコル（たとえばREST）です。 APIは非公式に定義されているか、Swagger/OpenAPIやSOAPのようなもので定義されています。
OSGiは、（ナノ）サービスを、他のモジュール（バンドル）が使用できるようにするオブジェクトとして定義します。 JavaはAPIの定義に使用されます。
ナノサービスはOSGiの最も重要な設計プリミティブであるため、ナノサービスを簡単に操作できるようにするための多くのサポートがあります。興味深いことに、サービスレジストリは動的で反射的であるため、ナノサービスをマイクロサービスに、またはその逆にマッピングするのは非常に簡単です。 OSGi Allianceは、このモデルを分散OSGi、「リモートサービス管理者」用に標準化しました。この仕様により、OSGiナノサービスを取得して、REST、SOAP、またはその他のプロトコルにマッピングできます。
したがって、OSGiを選択すると、マイクロサービスをサポートする決定を延期できるだけでなく、後でシステムにマイクロサービスを追加することもできます。最も基本的な機能と最高レベルの機能の統一されたアーキテクチャスタイルを持つことにより、システムの理解とスケーリングが容易になります。
ここでリンゴとリンゴを比較しているとは思わない。 OSGIはapplicationアーキテクチャであり、microservicesは分散システムですコンセプト。
私の経験では、マイクロサービスには多くの利点があります。
- 個々のマイクロサービスは、展開、テスト、および保守が簡単です。
- マイクロサービスは言語に依存しません。つまり、1つのマイクロサービスをpythonで、もう1つをjavascriptで、3つ目をgoで、さらにもう1つをJavaで書くことができます。
- マイクロサービスのスケーリングは簡単です、個別に。つまり、あるタイプの要求が他のタイプよりも頻繁に行われる場合、システム内の他の要素をスケーリングすることなく、必要なマイクロサービスをスケーリングできます。
- システム内の各マイクロサービスは、独自のデータを所有しています。これにより、明確な境界と懸念事項の分離が保証されます。
ただし、いくつかの欠点もあります。
- 展開する際には、インフラストラクチャに関する懸念がより多くあります。
- マイクロサービス間でメッセージをクリーンで効率的に保つことは困難です。
- 多くの可動部品があるシステムでエンドツーエンドのテストを行うのは困難です。
- メッセージングにはより多くのオーバーヘッドがあります。別のサービスへの直接メソッド呼び出しの代わりに、HTTPまたはその他のネットワーク通信形式を使用する必要があります。
いくつかの違いを説明する良い記事があります here 。