微服务高并发服务治理

加设备

最粗暴土豪的办法，比如直接招标1000台云主机，各大平台还是的屁颠屁颠的设立专门人员来配合，各个模块做镜像，谁扛不住，就加谁，让云供应商驻场，监控也让他们提供，加镜像，做网络配置什么的，都丢给他们

钱能解决的问题都不是问题，问题是大部分公司没这么多钱可以烧，哈哈

灾备

也是个烧钱的玩意儿
同配置的设备再来一套，一旦服务宕机，负载均衡切到新的灾备的nginx
问题是
服务复杂的时候，各部门各外部公司，对接的东西五花八门，拓扑结构向蜘蛛网一样。
数据库数据能同步过来，缓存数据咋办？
请求，回调，各个配置，这么多年积累的各种服务，各种语言，各种人已经走了，谁也不敢动
可能还得再灾备环境专门打包，其他依赖的服务什么的，ip地址啥的都得梳理清楚

所以灾备不好搞，可能要整体做一次全面重构

缓存

页面缓存，减少数据库访问次数，或者直接nginx页面缓存，减轻压力
cdn，一些图片放cdn，减少访问资源的时间

限流

限流的目的是能保证服务正常运行，还有人能够通过，可以是业务上的限流，比如主播的代理商调接口给主播打赏，得限流一秒钟一次，要不然数据库的锁总会出问题的

• nginx限流，ip限流
• tomcat限流
• 令牌 Semaphore
• 计数器
  我的想法是aop搞一套计数器，所有Controller里面对外的接口，默认加上这个过滤
  （所有对外请求，也得加，）
  方法名做key，数字累加累减，进入接口+1，结束的时候-1
  并打印开始时间，结束时间，耗时，并发，总并发
  这样有好处，所有的请求都有日志，其他系统对接有争议的时候，这是一个依据

有人觉得这样干对性能影响很大，其实真的很小
对那些动不动就单机过万的并发的，我的层次很低，我只考虑单tomcat 三五百并发的（某提供流量余额查询服务的提供商，号称2台tomcat能达到1万2的并发，我其实偷偷给他压200的量，错误就超过5%了，那个服务莫名卡死的兄弟对不起是我压了500 ）

降级

• 放通
  举个例子，视频网站会看用户会员级别判断广告和可用分辨率，如果突发事件，用户大增，鉴权组件会扛不住，这时候，就可以投降，给一个通用的结果，直接放通，不做逻辑处理

• 拒绝
  比如直接返回失败，并提升“请稍后再试”
  比如支付的时候，数据库一般会加锁，不足以支持单用户高并发的扣款，就应该加上隔离，直接降级，稍后再试

串行

秒杀什么的时候，可以先告诉他请求成功，但是并不等于抢购成功，把并发的事情串行执行，变成排队执行
这样能缓解服务器压力，不会超库存（提供库存的小姐姐内心os：超过一点点，其实问题也不大）
这时候队列，先进先出，什么的就有了用武之地，

我做过监听多个mq的高频数据的需求，
可能后执行的事件比先执行的事件先到的尴尬情况，所以一般先缓存一段时间，缓存里面碰撞排队，然后再落库，虽然不能彻底解决顺序的问题，概率降低很多，数据库压力也小很多，200条一次执行，和每次一条执行200的区别很大的

简单的监控

如何晓得自己的并发量呢
一个是负载均衡，或者nginx那边能统计
但是公司大一点的，这些东西轮不到咱们查看，都有专业的运维负载
咱们微服务想看的话，一个spring cloud 的健康监控可以看
但是我的想法是，根据日志量，logstash，或者filebeat 转logstash，进es，然后Kibana展示

logstash非常耗资源，如果服务本身很耗资源，还是不要装同一台设备上
es放固态做的阵列里面，几百G的日志完全没问题，

Kibana 过滤一下，可以看到各个接口（我前面对所有Controller做了aop的日志打印）的并发量

如果是阿里云，可以直接配置日志汇聚，elk都不需要自己搭了