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.
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的原創(chuàng)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的一个关于微服务架构和monolithic架构的讨论的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。