簡單聊聊分散式
現在哪個後臺開發人員不知道什麼是分散式，那肯定是個剛畢業的新手了，不！畢業生也是會接觸分散式。
我們為什麼會用分散式？分散式到底給我們帶來了什麼好處？
帶著上面的問題，我們來看下分散式的架構演變（沒有畫圖工具，簡單的聊聊哈哈哈哈）
一個專案在初期的時候，為了儘可能快的驗證市場，將專案部署上線，對業務程式碼的最快實現。在這個階段，程式碼開發人員將所有層級（MVC）的業務程式碼都寫在同一個專案工程當中，所有的業務資料都存放在一個資料庫當中。
臥槽，一個月不到就上線了！！！ 然後開開心心的去擼火鍋。突然有一天，老闆打電話來說，小彭啊，今天我們開了一場招商會，使用者反映app登入異常，用起來也很不流暢，使用者體驗賊差啊！
嗎的，次個火鍋還被趕回去加班！！
開始系統第一次升級：對伺服器做負載(Nginx)，加快取(redis)。這個時候資料訪問層我們可以將基礎配置資訊存到redis當中，比如說全域性系統配置常量啊，使用者登入的基本資訊啊，都可以放在redis當中去快取，然後使用者訪問應用層中間再加一個ng進行路由派發，將我們的應用伺服器分別部署在兩臺（分散式session問題採用redis儲存）。然後部署釋出！
ok，系統優化完成，應該不會有啥問題了，繼續去擼串！一個月內，市場部開始大力推廣，使用者越來越多，突然伺服器又爆炸了，再次被老闆叼！
第二次升級：檢視日誌發現百分之60的請求全是select！而且訂單表很龐大，居然到達了單表5000W，所以立馬對資料庫做一個讀寫分離（mycat），對訂單表進行按月分片拆分，拆分之後檢查跟訂單相關的一些select語句，尤其是複雜查詢語句進行測試（因為mycat對很多複雜sql查詢不支援）。
然後資料庫層的優化算是做完了，這次不要再被老闆叼了，提前想一下是不是還有什麼可以優化的地方可以做？臥槽，應用層啊！剛開始為了快速開發，完全沒有考慮業務拓展，現在趕緊做一次優化！
第三次升級：將我們的應用層拆分成為訂單中心、會員中心、註冊中心、報表。。。
為什麼要拆分？？ 比如運營部門，我tm只想查詢一下今日的流水報表，為什麼伺服器響應都這麼慢？再比如註冊，根本就不用關心我的報表，訂單，會員相關。
綜上所想，我們開始拆分，把服務層server拆分成若干個server，採用微服務架構（dubbo/springcloud）提供api介面，api註冊在註冊中心（zookeeper / spring cloud Netflix Eureka），應用訪問層（客戶端）直接去註冊中心上去拿需要用到的api進行一系列的邏輯處理，不再採用spring的依賴注入的方式，而是通過RPC／Restful進行遠端介面呼叫。ok這個時候我們的服務拆分算是完成了，釋出在不同的伺服器上，提供一個註冊中心。客戶端呼叫介面就直接去註冊中心拿。同樣的，我們的服務端也可以做負載。
做完以上，我們就可以笑嘻嘻的去擼串了嗎？不！！！
雖然分散式架構確實給我們的服務減輕了很多壓力，但是也有弊端，什麼弊端？
1: 分散式事物（可採用MQ 事務訊息／TCC補償性）
2：熔斷、限流、降級、容錯（springcloud 自有解決方案，dubbo需要找開源框架解決）
這裡推薦使用springcloud做分散式，至於為什麼？？？
太晚了，不想碼字了，網上一大堆，自己百度吧。。。
下面是dubbo跟spring cloud 的一些對比。。。截圖來的。。。
