一.微服務之間是如何獨立通訊的？
同步：
1 Rest Http協議
2 RPC TCP協議
異步：
二. 項目中緩存如何使用的？爲什麼要用緩存？緩存使用不當會造成什麼後果？
使用方向：
字典項 、菜單配置、系統參數、登錄token、session
要用緩存原因：
高性能
對於一個請求，耗時幾百毫秒查出一個結果，然後這個操作員就用了一次，這很浪費。
而同一個不經常改變的結果，從緩存取，只需要幾毫秒。
高併發
redis官方測評數據，每秒10W左右的讀寫，而mysql遠遠達不到這個數量。
不當的後果？
暫時未想好。
三. 爲什麼進行分庫分表？（涉及到高併發的時候，原來公司在數據庫層面使用什麼方案）分庫分表用過哪些中間件？這些中間件有什麼有趣點？你原來公司是怎麼進行數據庫水平或者垂直拆分的？
爲什麼進行分庫分表？
分表：
單一表的數據量太大，達到幾百萬的時候，sql執行性能就會變差，這個時候就需要把一個表的數據拆到多個表中。
分庫：
以一般經驗來看，一個數據庫最多支撐2000併發，就需要擴容，這個時候把一個數據庫的數據拆分到多個多個庫中，承受的併發將提高多倍
分庫分表用過哪些中間件？
DDS 華爲自研
沒有開源，這個就不多說了
Sharding-jdbc
噹噹網開源的，屬於client層方案，支持分庫分表，讀寫分離，分佈式ID生成，柔性事務
Mycat
是阿里的Cobar改良而來，屬於proxy層方案
他們有什麼優缺點？
首先，Mycat和Sharding-jdbc這兩種中間件，我並沒有用過
根據網上的回答，整理一下
ShardingJdbc:
優點在於不用部署，運維成本低，不需要代理層的二次轉發請求，性能高，缺點在於耦合，如果遇到升級，各個系統都需要重新升級再發布，各個系統都耦合Sharding-Jdbc的依賴
Mycat
這種proxy層的缺點在於需要部署，自己運維一套中間件，運維成本高，好處是對於各個項目是透明的，如果遇到升級，自己中間件那裏搞就行
我原來公司如何進行水平或者垂直拆分數據庫的
水平拆分和垂直拆分同時用。
首先使用垂直拆分，化爲兩個模塊，一個是基本不變的公共資源庫，裏面存放菜單 字典 系統參數之類的數據
然後把第一次水平拆分稱爲一級分庫，根據新政區劃這個字段，把全國的數據劃分爲幾部分，然後放到不同的庫裏。
但是有的進行一級分庫之後，從省份來看，有的省份的數據依然是大的，這個時候就進行二級分庫，也就是把省裏的數據進行第二次水平拆分。我們制定一個二級分庫字段，進行hash一下均勻分散，這樣可以平均分配每個庫的數據量和請求壓力