前言

由於歷史原因，集中式架構多用於傳統銀行、電信等行業。主機資源集中在大型主機或小型機上。集中式架構下，包括作業系統，中介軟體，資料庫等“基礎軟體” 均為閉源商用系統。集中式架構的典型案例是 IOE（IBM， Oracle，EMC）提供的計算裝置、資料庫技術和儲存裝置共同組成的系統。

近年來，分散式架構在 Google、 Amazon、Facebook、阿里巴巴、騰訊等網際網路公司廣泛應用基礎上、也越來越多被金融行業關注和應用。分散式架構一般採用價效比更高的 PC 伺服器、分散式資料庫和大量 PC 記憶體快閃記憶體，程式同時執行在眾多 PC 伺服器上。

考慮的點

下面就來看看從現有架構升級為分散式要考慮哪些方面的內容。

【資料庫】

一個典型的網際網路應用，前端伺服器可以利用負載均衡服務，組成一個叢集，但是隻有一個mysql主庫，這時候，mysql服務就是系統中依賴的關鍵服務。

關鍵服務的效能和波動將成為整個系統的效能瓶頸和主要問題源。

為了減輕只有一個mysql主庫的依賴，我們引入了一主多從的架構，讓更多從庫也來提供查詢服務，減輕主庫的查詢依賴。

這樣升級改造後，系統的效能和穩定性還是有明顯的提升，但是mysql查詢的複雜度和數量增加後，mysql的效能瓶頸依然會很突出。

【快取層】

於是，繼續升級，引入redis或者memcache，將大量的結果快取起來，把應用盡量從mysql隔離，減少對資料庫的依賴。

這時候，我們會欣喜的發現，應用的效能比之前完全依賴mysql的時候要強好多，穩定性也響應的提高很多。

隨著我們的系統越來越複雜，訪問量越來越大，快取層的壓力也會越來越大。

一方面是記憶體不足的問題，另一方面資料更新更復雜，還有就是訪問壓力以及內網頻寬的瓶頸也增加了。

這時候又要開始對快取層繼續升級改造了，於是分散式快取叢集也就出現了。

通過一致性hash演算法或者簡單的雜湊方法，都可以很容易的增加redis/memcache服務來構建更大規模的叢集。

這樣一來，隨著伺服器增加，單機的記憶體瓶頸減輕了，訪問壓力以及頻寬壓力也降低了，但是資料更新的問題依然存在。

資料更新的問題，就是資料不一致的問題，本質上就是因為一個資料的多次寫入，中間出現異常的話，就導致出現不一致了。

關於資料一致性問題，我們後面再來詳細分析和講解。加群895244712瞭解更多架構升級知識。

隨著快取層叢集的構建，整個系統架構就變成了多前端伺服器，多快取伺服器，一個主庫，多個從庫。

主庫主要承載資料寫入的負載，在大部分的網際網路應用中，寫入的數量相對還是少很多的，所以大部分時候，這樣的架構也就可以安枕無憂啦。

【更大規模】

我們的追求不僅是眼前的苟且，還有更強大的系統和更多的使用者。

當我們的應用，使用者數、訪問量過千萬之後，以前的架構還是會遇到越來越多的挑戰。

這裡面，可能資料庫還是會第一個出現瓶頸，畢竟一個主庫，再強大也是沒法做到一秒鐘數萬次的更新，哪怕只是小小的點選數的增加。

這時候，就要開始考慮對資料庫做分拆了，把一個資料庫分拆為好幾個資料庫（分表分庫）。

而分拆的方式，大家應該能想到的，比如：水平分拆和垂直分拆。

【水平分拆】

典型的水平分拆就是對資料做歸檔，按照日期（每年歸檔），把舊的資料遷移到歸檔庫裡面，訪問量少，也不會有寫入的壓力。

水平分拆對整個系統的改造和變化相對來說是影響比較小的，畢竟資料結構沒有變化，只是資料來源增加了。

而這種分拆帶來的明顯效果就是，資料規模減少，資料庫的讀寫效能都會有明顯的提升，當然對整個應用的效能和穩定性都會有很大提高。加群895244712瞭解更多架構升級知識。

【垂直分拆】

如果只是對資料庫做垂直分拆，只是把一部分資料表遷移到其他獨立資料庫中，比如：把使用者相關的資訊表遷移到使用者庫，把商品相關的產品表遷移到商品庫，那這個分拆也不算難。

但是，往往伴隨著系統規模的變大，應用的複雜度也會不斷提高。

所以，這個時候垂直分拆，很可能會同時進行應用的分拆。

比如：把使用者的登入註冊、資訊維護單獨部署和維護，把商品資訊的管理和維護單獨部署。

這時候，應用也就同時進行了垂直分拆，即：把大的應用進行元件化、服務化。

【微服務】

到這個階段，大家應該就開始感覺大一個系統的複雜了吧。

一開始說好的做一個網際網路應用，而現在卻出來了很多個應用和服務，他們之間又有很多關聯，組成一個大型的系統。

這時候，系統中的關鍵服務依賴已經不僅僅是快取層、資料庫服務，而變成了一個個拆分之後的應用、微服務了。

這時候，系統的效能和穩定性就完全依賴各個微服務的效能和穩定性了。

如果，再把每個微服務按照上面的架構升級路線演練一遍，貌似又不那麼困難。

但是，全部組合在一起，新的難點已經是對這些服務的監控、運維、故障排除等治理工作。

想要了解更加深入、細節的分散式架構系統嗎？這些分散式架構都是如何實現的？集中式架構升級為分散式架構會遇到哪些坑？歡迎加群895244712，這裡有詳細完整的大型分散式架構系統架構經驗，等你來取。

未來的架構是什麼樣？

那麼，系統繼續升級的話，我想，可能就是自動化運維的工作會更多了吧。

• 一兩個資料庫當機不用怕，主從自動切換，資料庫叢集秒級自動恢復。
• 幾個快取伺服器網路不穩定也沒關係，有備份的快取可以先用著。
• 微服務的一些伺服器不穩定，服務自動降級，並且在微服務穩定後自動恢復以及同步資料。
• 甚至一個機房斷網、斷電了，其他機房依然正常的提供全面的服務，不影響使用者使用。

總結

分散式架構在經濟性、安全自主、靈活性、可伸縮性等方面有明顯優勢，隨著系統需要處理的交易量與資料量越來越大，分散式架構在這方面的優勢也會越來越明顯。集中式系統在可維護性、一致性方面有優勢，而分散式系統需要達到同等或更高的可維護性與高一致性，需要通過先進的分散式中介軟體與大規模運維平臺來支援。

• 關鍵服務依賴總是最重要的環節，也是最容易出問題的地方。
• 系統架構升級，正是對這些關鍵依賴的瓶頸進行鍼對性優化升級和改造。
• 應用從小變大，再分拆變小，從一個應用到很多個微服務，這些都是技術不斷變革的過程。
• 規模化帶來了帶來了的總體容量和總體效能的提高，同時也帶來了關於服務治理的新挑戰。

那麼，是不是開發系統都要用這麼複雜的架構呢？

其實不是，上面的架構升級過程，其實是對線上問題不斷髮現和解決的過程，也是一個不得已的過程。如果一個系統的使用者量、業務量不大，一開始就複用一套龐大的系統架構，那真的就費時費力，累死自己，完全沒必要。所以，合適就好。