一个关于微服务架构和monolithic架构的讨论

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的原创文章，请关注公众号"汪子熙":

• « 上一篇：Requests后用Beautifulsoup找不到指定元素(原来是页面元素被注释)
• » 下一篇：Nexus架构Maven私服