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

版权声明:本文为博主汪子熙原创文章,未经博主允许不得转载。 https://blog.csdn.net/i042416/article/details/88798612

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.

clipboard1

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.

clipboard2

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

没有更多推荐了,返回首页