1.究竟什么是微服务？
所谓微服务架构，从宏观上来讲，无非就是细化了服务拆分过程中的粒度，粒度越细，业务耦合越小，容错性越好，后期扩展越容易。
2.RPC调用
一次RPC请求就是服务调用方以网络的形式进行远程调用服务提供方提供的方法，服务提供方根据服务调用方提供的参数执行指定的服务方法，执行完成后将执行结果响应给服务调用方。
一次RPC调用主要需要经历的三个步骤：
1）底层网络通信协议的处理
2）解决寻址问题
3）请求/响应过程中参数的序列化和反序列化
3.警惕Dubbo因超时和重试引起的系统雪崩
Dubbo的Consumer会在本地根据负载均衡算法从地址列表中选择某一个服务节点进行RPC调用，如果调用失败则自动Failover到其他服务节点上，默认重试次数为两次，服务调用超时就认为调用失败，需要进行重试。
如果一些复杂业务本身就需要耗费较长的时间来执行，但超时时间却被不合理的设置为小于服务执行的实际时间，那么在大流量场景下，系统的负载压力将会被逐步放大，最终产生蝴蝶效应。
假设有1000个并发请求同时对服务A进行RPC调用，但都因超时导致服务调用失败，由于Dubbo默认的Failover机制，共将产生3000次并发请求对服务A进行调用，这是系统正常压力的3倍，若处于峰值流向时情况可能还会更糟糕，大量的并发重试请求很可能直接将Dubbo的容量撑爆，导致资源连接被耗尽，从而引发系统出现雪崩。
另外并不是任何类型的服务都适合Failover重试，比如写服务，调用失败后不应该进行重试，否则将导致数据被重复写入。读服务开启。
4.应对大流量高并发的常规手段
1）扩容，使用集群技术
2）动静分离，静态资源放在CDN
3）缓存技术，从缓存读
4）服务降级，牺牲部分非核心业务
5）限流（漏桶、令牌桶）
5.使用MQ实现系统之间的解耦
当业务垂直化并独立部署后，尽管不同的业务子系统之间可以通过RPC请求来实现服务调用，但是在某些情况下，这些依赖又并不一定都是必须的， 因此完全可以使用MQ消息传递来替代RPC调用。
消息中间件的作用：实现异步调用和系统解耦。
消息模型：
1）P2P，点对点：此为一对一的消息推送、消费模式，如果有多个消费者都在监听消息队列上的消息，那么JMS会根据先到先得的原则确定唯一的消费者，由指定的消费者对目标消息进行消费，如果当前没有任何的消费者在监听消息队列，那么未被消费的消息将会被暂时积压在消息队列中，直到最终被消费为止。这是一个典型的PULL模式，由消费者主动从消息队列中获取消息。
2）pub/sub，发布订阅模型：这是一种广播形式的消费模型，对于订阅了目标TOPIC的所有消费者，JMS都会将指定的消息PUSH给他们进行消费。
6.集中资源配置
集中配置有什么好处？
1）配置信息统一进行管理
2）动态获取和动态更新配置信息
3）降低运维人员的维护成本
4）降低配置出错率
7.使用本地缓存的优缺点
ehcache的本质是同一个进程内的缓存技术，会共享JVM有限的内存资源，如果缓存数据所占的内存比例较大，有可能出现内存溢出的风险。所以本地缓存技术将逐渐被分布式缓存技术替代。
8.Mysql InnerDB锁机制
数据库中针对同一行数据的更新操作是串行执行的，所以在某一个线程未释放锁之前，其余的线程将会全部阻塞在队列中等待拿锁，并发越高等待的线程就越多，这会严重影响到数据库的TPS
