- 1路由跳转传参（params）_edit(row) { this.$router.push('/studentupdate?id='
- 2Linux下Pytorch版deeplabv3+环境配置训练自己的数据集_在linux环境下搭建deeplabv3+
- 3自然语言处理（NLP）初识_hunlp
- 43分钟彻底搞懂什么是 token_token 人工智能
- 5UNet - 预测数据predict(多个图像的分割)_unet图象分割代码
- 6机器学习--支持向量机(通俗版本+demo)
- 7php中配置文件操作config.php文件的读取修改等操作_请在 config_global.php 内修改本地文件读取模式为 1 或 4 后再试
- 8论文阅读---VITC----Early Convolutions Help Transformers See Better
- 9transformer的原理_transformer原理
- 10使用InsightFace识别人脸_pip install insightface retinaface 人脸检测 模型
一个关于微服务架构和monolithic架构的讨论_monolithic js
赞
踩
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的原创文章，请关注公众号"汪子熙":
