1111

							<div class="article-copyright">
版权声明：本文为博主汪子熙原创文章，未经博主允许不得转载。					https://blog.csdn.net/i042416/article/details/88798612				</div>
<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/ck_htmledit_views-f57960eb32.css">
<div id="content_views" class="markdown_views prism-atom-one-dark">
<!-- flowchart 箭头图标 勿删 -->
<svg xmlns="http://www.w3.org/2000/svg"><path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block"></path></svg>
<p>As you mentioned Orchestra just acts as a router, and I prefer to call it as “API gateway”, or the one in “Facade design pattern”. Every time when we introduce a new micro service, the service has to first register itself in Orchestra. Then Orchestra becomes the bottleneck of the whole solution – every micro service has the tight dependency on it. If the orchestra crashes, the whole scenario will not work.<br>

I would assume a typical micro service can provide access to external consumer in a standalone way, which is not true in current design – it is not possible for other consumer to directly call QR code service or Account creation service, which does not look like a real microservice style to me.

So can we fine tune the current design a little bit, as I also mentioned during our meeting? That is:

we still keep the WebSocket servers – the Diablo App / Web shop only knows their corresponding web socket servers and that’s all. No microservice is visible to Diablo App or Web shop.

We develop standalone microservice which is consumed by WebSocket server via HTTP.

In this case we still keep the flexibility and extensibility for future.

要获取更多Jerry的原创文章，请关注公众号"汪子熙":

        </div>
<link href="https://csdnimg.cn/release/phoenix/mdeditor/markdown_views-258a4616f7.css" rel="stylesheet">