还有就是在你的后方有众多微服务，各个微服务也可能会相互依赖，如果其中一个挂了，那么对你来说可能就是灾难，怎么避免这种情况？
这个也是最近在做的事情，搜了一圈，都是在谈Netflix的Hystrix，这个应该是比较成熟的方案了。
熔断和降级只能保证微服务不会星火燎原，但不能保证前端出现错误，所以前端一起配合，提供一些柔软、体验好的错误提示会更好。
最后
奶爸的工作当然不止这些了，为人父母当然没那么简单了，杂七杂八超乎你的想象。
和产品谈需求，客服事件排查，和同事讨论技术方案，和测试沟通改bug，和领导汇报，什么？app又打不开了？什么？机房有故障？什么？有人在刷接口？永无止境。。。
------------------------------------------------------
说几个自己踩过的坑：
1. 网卡被打满
当第一次遇到网卡被打满的时候，觉得很神奇，有一种介于牛A和牛C之间的感觉。时日至今，网卡被打满真不是什么新鲜事了。
测试在压力测试的时候，qps老是上不去，后来发现是压测机的网卡被打满了。
服务崩了，缓存服务器网卡被打满了，单key存储的东西太大。
总结：网卡被打满是不得不考虑的事情，尤其是你来来回回传输的东西既大调用量又高。解决办法就是单key的值不宜太大，而且不论是什么缓存，随着值大小的增加，性能是急剧下降的，所以能拆就拆，现在都是分布式缓存，key越多，各个服务器就越平均,key的增加对性能的影响微乎其微。
2. tomcat老是被重启
一到高峰期，tomcat就噼里啪啦的自动重启，找不到原因啊，奶爸遇到挑战了。
就像前面说的，孩子生病了，你有的药吃不好，那就请大夫开方子，请别人治好也是康复啊。
后来在tomcat重启的时候做了dump和tcp监控，后来发现tomcat在重启的时候time wait过多，推断出某个服务的调用出现了性能问题，积压太多，累积到一定程度就爆炸了。
后来是增加某服务的rpc调用的连接数搞定了。
还有一点就是synchronized关键词的使用要小心，小心出现性能问题，会堵塞。
3. 监控曲线突然没了
曲线突然没了，掉成0了，顿时吓尿了，赶快排查日志，发现在上报监控的时候报错了，上报的线程的挂了。
改呗，上报错了就错了，不能制造惊魂啊！
-----------------------------------------------------------------
总结：
以上都是本人的一些经验心得，可能对你来说没什么特别，也只能说鄙人才疏学浅，跟不上技术发展的脚步。如果你有更好的，请不吝赐教，大家一起成长！
以上的所有东西，对于小公司小团队，或者从无到有的项目还是很庞大的。监控系统，日志系统，运维，发布，到处都有坑让你踩。我们目前所用的rpc调用方案、缓存、mq都是第三方的，虽然有技术支持，还是踩了很多坑。
坑到处都有，我们要做的就是踩到坑了不摔倒！
祝大家新年快乐！
相关文章
精彩导读
热门资讯
关注我们
