关于微服务架构的思考

最近在项目中遇到了一些问题,一个比较多的问题服务和服务直接调用混乱 a服务调用b b服务调用c c服务调用d 导致后期升级会出现很多问题 如果有个流程图也许会好些 但是没有 因此我陷入了思考, 如果进行重构的话那什么样的架构会是较好的价格 我想 设计模式的六大原则 在此也一样适用

什么是好的架构

明确的分工,服务之间优雅的调用

我给出的一个结果

这里简单画的一个草图

图片描述

先介绍一下

查询:对应查询操作
操作:对应增删改操作

分为四层

ui: 页面及后台调用

网关层: 路由

聚合层:查询聚合 操作聚合

服务层:订单服务 商品服务

遵循的原则

  • 各个服务只专注于自己的功能 由聚合层来协调服务之间的关系维护与调用
  • 上层通过http调用下层 下层通过mq通知上层 同级不能调用

服务要想调用服务 如 a服务想调用b服务 可以 a通过mq传递给聚合层 然后聚合层根据消息调用b ,服务之前的调用交给 聚合层维护

后面还会不断完善这篇文章的

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值