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
