你千万别把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吗？这条是规范，不要触碰。