不管是java还是.net基础设施必不可少。
MQ：
如果发现MQ是瓶颈。不管用的是rabbitmq还是kafka，其他的也好。作为生产者要确认超时时间、重试机制、异步线程池。消费方要做两件事：发现和解决。发现的主要是通过积压阈值最快发现问题。解决的方法主要有：短期方案：增大线程数，增加服务器。长期需要优化逻辑。积压阈值的设置主要取决于对积压的容忍程度，比如我们的服务对延时很敏感，那么设置积压阈值为50或者100。这样有问题可以快速发现。
缓存：
缓存的话，不管是tair还是redis或者memcached。我们对缓存的写入成功和数据存在性都不能强依赖。所以基本要做到缓存读取不成功就需要再次查DB。而且不管出什么问题，对程序来说，就是抛异常了。所以一定要异常捕获。数据要用异步线程池异步写入。监控要做好。我们有个服务要做一层缓存。我们组的兄弟比较担心，问我了解不了解冷热启动的概念。这个其实需要去咨询维护服务的人怎么定义这个概念。一般来讲：冷启动数据是从磁盘加载的，热启动是从内存加载的。
超时和重试：
为了防止别的服务出问题，一定优化好超时时间和重试机制。超时时间的定义一般设置为一个请求处理99.9%的耗时时间的5到10倍。这是因为考虑到跨机房等网络耗时的问题。虽然运维的同事会告诉说跨机房之间的时延也就是1ms或者2ms的事情，但是实际值要大于这个值，所以一般设置超时时间是100ms起步。很多请求设置了这个值还是超时了，没关系，就是截获一个异常然后重试。如果服务不重要，比如展示的时候，去取一个展示的key的字典值，也可以不重试。一般的RPC组件默认重试是3次。
一般超时的异常有以下特征：
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy67.xxxx(Unknown Source)
at
Caused by: org.apache.thrift.TException: tthrift remote(IP:端口) invoke(xxxx) timeout, traceId:-2093033244087395764, timeout:100
Unknown Source：远程问题的特征之一
timeout是超时的特征
服务隔离：
服务隔离是为了减少损失的影响范围，避免雪崩效应。比如我们有一些外部的依赖：我们依赖微信支付的稳定性、支付宝支付的稳定性、银联支付的稳定性。那么我需要按照这几种通道做物理隔离，可以部署相同的代码但是部署在不同的机器群。
组件版本及时升级：
比如httpclient4.3的版本有个bug并发量大的时候会阻塞。之前在乐视的时候，部门有个小组的服务就发生过这样的线上问题。
及时下线不再使用的代码：
可能在一个团队中很多程序bug都是因为存在太多的兼容逻辑和临时代码，写这些逻辑的人如果没有加上很好的注释，在用完的时候也没有及时清理。后来维护的人看到这段毫无道理的代码不敢动。程序里大量的IF和ELSE，很容易踩坑。招聘的时候卡的很严，很多面试者不服气，我也能写出来代码。但是会写代码和会写代码是不一样的。我们需求很急，但是宁愿不做也不要一个写出一堆问题代码，处处是坑，难以维护代码的程序员。
数据库：
一个数据表的数据过多，对更新和查询性能都有影响。对于不再使用的数据要及时备份清走。一般数据库的容量剩余不到60%, 就要考虑分库分表了。一般一台物理机写入能力也不能高于QPS1500。所以对于主从延时不是很敏感的业务场景，一定要做好读写分离。虽然做了读写分离，如果读和写的代码在一个事务里，其实都是走的主库。杜绝慢查询。
梳理好依赖：
开发一个系统，最忌讳的是没有灵魂。来什么需求都接。把系统搞得很乱。梳理好系统的边界和定位。我们应该依赖什么服务，是强依赖还是可以降级的弱依赖。调用系统的调用方需要什么东西，我们是应该给提供，还是让他们自己去解决。
总结：
上面提到的哪一步没有做好，都可能引发蝴蝶效应。比如：一个MQ的消费能力差，积压了，生产者同步写入，写入等待。另外一个服务调用了这个接口，还把这个调用包裹到事务里，导致这个事务长时间不提交。这样的请求来几个，线程池满了，整个服务就挂了。如果别人调用这个服务，超时时间设置的过长，别的服务也跟着线程池满，挂掉了。如果没做好物理隔离，所有服务都挂了。
