架构必会的性能指标及分析策略

　　不管是java还是.net基础设施必不可少。

MQ：

　　如果发现MQ是瓶颈。不管用的是rabbitmq还是kafka，其他的也好。作为生产者要确认超时时间、重试机制、异步线程池。消费方要做两件事：发现和解决。发现的主要是通过积压阈值最快发现问题。解决的方法主要有：短期方案：增大线程数，增加服务器。长期需要优化逻辑。积压阈值的设置主要取决于对积压的容忍程度，比如我们的服务对延时很敏感，那么设置积压阈值为50或者100。这样有问题可以快速发现。

缓存：

 　　缓存的话，不管是tair还是redis或者memcached。我们对缓存的写入成功和数据存在性都不能强依赖。所以基本要做到缓存读取不成功就需要再次查DB。而且不管出什么问题，对程序来说，就是抛异常了。所以一定要异常捕获。数据要用异步线程池异步写入。监控要做好。我们有个服务要做一层缓存。我们组的兄弟比较担心，问我了解不了解冷热启动的概念。这个其实需要去咨询维护服务的人怎么定义这个概念。一般来讲：冷启动数据是从磁盘加载的，热启动是从内存加载的。

超时和重试：

　　为了防止别的服务出问题，一定优化好超时时间和重试机制。超时时间的定义一般设置为一个请求处理99.9%的耗时时间的5到10倍。这是因为考虑到跨机房等网络耗时的问题。虽然运维的同事会告诉说跨机房之间的时延也就是1ms或者2ms的事情，但是实际值要大于这个值，所以一般设置超时时间是100ms起步。很多请求设置了这个值还是超时了，没关系，就是截获一个异常然后重试。如果服务不重要，比如展示的时候，去取一个展示的key的字典值，也可以不重试。一般的RPC组件默认重试是3次。

　　一般超时的异常有以下特征：

　　Unknown Source：远程问题的特征之一

　　timeout是超时的特征

服务隔离：

　　服务隔离是为了减少损失的影响范围，避免雪崩效应。比如我们有一些外部的依赖：我们依赖微信支付的稳定性、支付宝支付的稳定性、银联支付的稳定性。那么我需要按照这几种通道做物理隔离，可以部署相同的代码但是部署在不同的机器群。

组件版本及时升级：

　　比如httpclient4.3的版本有个bug并发量大的时候会阻塞。之前在乐视的时候，部门有个小组的服务就发生过这样的线上问题。

及时下线不再使用的代码：

　　可能在一个团队中很多程序bug都是因为存在太多的兼容逻辑和临时代码，写这些逻辑的人如果没有加上很好的注释，在用完的时候也没有及时清理。后来维护的人看到这段毫无道理的代码不敢动。程序里大量的IF和ELSE，很容易踩坑。招聘的时候卡的很严，很多面试者不服气，我也能写出来代码。但是会写代码和会写代码是不一样的。我们需求很急，但是宁愿不做也不要一个写出一堆问题代码，处处是坑，难以维护代码的程序员。

数据库：

　　一个数据表的数据过多，对更新和查询性能都有影响。对于不再使用的数据要及时备份清走。一般数据库的容量剩余不到60%, 就要考虑分库分表了。一般一台物理机写入能力也不能高于QPS1500。所以对于主从延时不是很敏感的业务场景，一定要做好读写分离。虽然做了读写分离，如果读和写的代码在一个事务里，其实都是走的主库。杜绝慢查询。

梳理好依赖：

　　开发一个系统，最忌讳的是没有灵魂。来什么需求都接。把系统搞得很乱。梳理好系统的边界和定位。我们应该依赖什么服务，是强依赖还是可以降级的弱依赖。调用系统的调用方需要什么东西，我们是应该给提供，还是让他们自己去解决。

总结：

　　上面提到的哪一步没有做好，都可能引发蝴蝶效应。比如：一个MQ的消费能力差，积压了，生产者同步写入，写入等待。另外一个服务调用了这个接口，还把这个调用包裹到事务里，导致这个事务长时间不提交。这样的请求来几个，线程池满了，整个服务就挂了。如果别人调用这个服务，超时时间设置的过长，别的服务也跟着线程池满，挂掉了。如果没做好物理隔离，所有服务都挂了。

　　作者简介：

静儿，20岁时毕业于东北大学计算机系。在毕业后的第一家公司由于出众的语言天赋，在1年的时间里从零开始学日语并以超高分通过了国际日语一级考试，担当两年日语翻译的工作。后就职于人人网，转型做互联网开发。中国科学院心理学研究生。有近百个技术发明专利，创业公司合伙人。有日本东京，美国硅谷技术支持经验。目前任美团点评技术专家，善于新人培养（欢迎关注静儿的个人技术公众号：编程一生）

技术交流可关注我的github:https://github.com/xiexiaojing

关注静儿公众号，不定期漫画技术推送~