微服务设计指导-微服务各层间应该如何调用

你千万别把consumer去冲到前端直接这样调用了哈。

下面说一下微服务和DB、中间件(包括一切中间件)的调用关系,这个是精华,网上的复制、粘贴是没的。

微服务与中间件、DB的调用关系最佳实践(这不是规范是最佳实践)

从Consumer端来看设计

  • Consumer端经常会去调用Redis,是因为consumer端有时需要通过一个状态、一个值来“反转”或者“组织”provider“端;
  • 假设有一个provider端叫getCity,consumer端每个请求都要调一次getCity,这时就会造成微服务泛滥,而这种场景在“业务代码编织时”又不可避免,那么怎么办?我们调过一次provider端的getCity后,反它缓存起来,这样consumer端是不是就减少了对provider端的调用?
  • 字典表、枚举值放在db一个table里,consumer端也要调用。不是不可以,而是这样做你:1. 降低了服务的响应速度 2. 变相增加了泛滥DB的调用,不是不可以而是在consumer端我们提倡可以做到0调用DB,尽量多用redis,mongodb;
  • Consumer端也会去调MQ的,异步多线程去请求provider端;

所以,consumer端的总结就是:尽量少用或者不用db,多用缓存减少对provider端的调用、多用mongodb减少对db的依赖、用mq和多线程控制住对provider端的泛滥。

从Provider端来看设计

这边的设计其实就是平峰削谷的5个层次、3个维度去在provider的单根服务的响应速度上做足功课,力争单根微服务<2秒(万级并发下)

5个层次

第一层,用waf上的三道防火墙挡住各种CC和BOT攻击 - 和provider端无关
第二层,用varnish尽可能的去多挡各种静态,get请求- 和provider端无关
第三层,用redis加速API的访问速度(一般使用redis和不使用redis可以相差千倍性能);
第四层,用异步MQ去保护后台交易、提交、支付、供应链端应用;
第五层,用mongodb或者是redis存储功能去替代传统数据库做流水、历史、小DB应用;

3个维度


第一个维度,单SQL在基于千万级数据库表结果的底上运行时间不得超过500ms;
第二个维度,系统日志、历史数据要可archive,即需要有明确的字段、标识以便于DEVOPS、DB巡检维度,不断去发现不合理设置,尽可能提前对系统进行扩、缩、Archive动作;
第三个维度,少用DB,多用NOSQL;

大家可以把5层漏斗想像成一个空心漏斗,水是无缝不渗透的。这才有了这三个维度形成了包裹着这个漏斗的三层防洪堤。

最后再说一句

后台跑批、跑JOB可以跨库也必须跨库访问DB,都跑JOB了你还调用微服务,这不是自己no zuo no die吗?这条是规范,不要触碰。

 

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

TGITCIC

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值