マイクロサービスガバナンスとSOA

Question

私は過去10年間、SOAガバナンスプロジェクトに取り組んでいましたが、現在はマイクロサービスアーキテクチャのものに切り替わります。

SOAの良い点は、実際には何らかの努力で構築されたCanonical Data Modelがあったことですが、最終的にすべてのシステムが同じ「言語」を話し終わり、通信はサービスバスを介して集中化されました。 Microserviceアーキテクチャチームで

独立しており、何のサービス・バスがないように、このすべての積分するポイントがどのように機能するか疑問に思います。

1）SOAPのためのSOA（中WSDL）があるようないくつかの契約をenforeする方法はありますか？

2）チーム開発サービスBが自主的で、新しいサービスを展開する場合は、古いバージョンも維持する必要がありますか？ SOAでは、サービスバス上でv1を維持し、v2への変換を行ったという問題が解決されました。サービスBが新しいバージョンを持っていることは、消費者にとっては敬遠されました。

3）チームができるだけ自律的（「アジャイル」）でなければならないことを知っている下の写真のように、マイクロサービスの数がかなり多い場合は、どんな種類のガバナンスが必要でしょうか？

私は最良の答えを探しているわけではありません。ここには魔法の解決策がないので、私はさまざまな意見に興味があります。

ありがとうございました。

Answer 1

我々はまた、同様の変化を受けています。

契約を履行するかどうかについての質問は、サービスバス経由で直接接続している場合とは独立しています。 SOAPとWSDLを使用するためにマイクロサービスを構築することができます。業界全体がこれから離れるように見える。私たちはRESTを使用しています。

マイクロサービスの展開を担当するチームは、顧客のようなすべての外部パーティを処理する必要があります。これは、変更が発生した場合、下位互換性を維持し、他のチームで変更管理プロセスを経て、古いバージョンを廃止する前にそれらをアップグレードする必要があることを意味します。できるだけ変更を破らないようにし、そうでない場合はセマンティックバージョン管理を使用します。自動化されたテストは、これをすべて可能にします。

、私は周りの地面のルールを設定しますガバナンスの観点から

次破壊の変更を検討し、これはバージョン管理システムでどのように処理されるかである（とない）何

このようTLSおよび認証メカニズムなど
• は、クライアントがどのように自分自身を認証する方法/サービスのためのドキュメントが公開され、更新される場所を
• セキュリティ勧告

すべてのサービスをカバーする標準的なデータモデルを用意していないかもしれませんが、ドメインに適した小さな慣習を導入することは賢明かもしれません。私のドメインでは、これは常に3文字のISO標準通貨コードを金額とともに使用することを意味します。我々は通貨を仮定したり、別の表現を使用したりすることはありません。

Answer 2

私は同様の移行に参加しましたが、途中でかなりの間違いがありました。ここで私は、中央統治体として行うだろういくつかのものがある：

1.

は、私は最大の過ちは、単に古いSOAPサービスは、自分のものになるせていると思う

最初の建築の独立を作成します。それは動作しません。 2番目の間違いは、MicroservicesをData CRUDサービス（Product、Customerなど）にすることです。それはどちらもうまくいきません。

これらのことは、多くの同期相互依存性と多くの問題を引き起こします。

相互依存性を最小限に抑えるアーキテクチャに投資します。可能な限り同期通信の必要性を減らす。そして私はMQを使用するわけではありませんが、マイクロサービスの主な機能は他のサービスと連携して動作するはずです。

これは、古いSOAPサービスの行に沿っていない全く新しいタイプの分解を必要とします。だからこそこれは大変な作業ですが、後で多くの（指数関数的な）問題を避けています。 Self-Contained Systemsをチェックしてください。

プロトコルガバナンス

2.あなたがRESTfulなHTTPに移行している場合は特に、私はのためのルールを設定します：（ので、すべてのアプリケーションが均一にクロールすることができます）形式の標準

をリンク

• ベストプラクティスをリンクする（すべてのリソースはにリンクを介して到達可能、URLはハードコードされていないなど）
• D重要なことは、後方互換性のない変更を行った後でバージョンをマークする自動的な方法です。そして標準的な猶予期間が経過した後、これらは削除されます（生き延びる必要がある時）。どちらかなど

カレンダー間隔、またはリリースの数であり、これらのいずれかを行うことのない一つの方法ではありませんので、あなたは、それらを強制する、これらの全てを思い付くする必要があります。

私は、スワッガーのような特定の製品を必要としていなくても、チームでこれらの決定をすることができます。

JSON-RPCを探していてRESTを探していない場合は、上記の点のいくつかがあなたと無関係かもしれません。

3.インフラのようなもの

認証と承認のための統一基準を作成します。繰り返しますが、できるだけ製品に依存しないものとし、同期通信は必要ありません。

例えば、Json Tokensを使用するように定義します。これらのものは、誰とでも通信することなく「オフライン」で使用でき、また、認可に役立つユーザーについてのアサーションも含めることができます。

特定のメッセージの通信暗号化などのセキュリティ制約も定義します。再び、私はちょうど「どのように」「どのように」必要とします。

4.継続的な監督

私はおそらく建築監督のためのチームを作成します。適切なアーキテクチャーを作成することは難しく、時にはプロジェクトが必要とする迅速かつ汚れたソリューションのために落ちることなくそれを変更することはさらに難しく、卑劣な依存関係や隠された問題が生じます。

これらの人々は、ハンズオンドメインエキスパートと建築家も、最終的に全体の景観が機能するために責任する持っている必要があります。

まあ、それは、HTH物事の私の即興リストです。..