【經典揭祕】集中式架構怎麼升級爲分佈式架構？

前言

因爲歷史緣由，集中式架構多用於傳統銀行、電信等行業。主機資源集中在大型主機或小型機上。集中式架構下，包括操做系統，中間件，數據庫等「基礎軟件」 均爲閉源商用系統。集中式架構的典型案例是 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，這裏有詳細完整的大型分佈式架構系統架構經驗，等你來取。

將來的架構是什麼樣？

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

• 一兩個數據庫宕機不用怕，主從自動切換，數據庫集羣秒級自動恢復。
• 幾個緩存服務器網絡不穩定也不要緊，有備份的緩存能夠先用着。
• 微服務的一些服務器不穩定，服務自動降級，而且在微服務穩定後自動恢復以及同步數據。
• 甚至一個機房斷網、斷電了，其餘機房依然正常的提供全面的服務，不影響用戶使用。

總結

分佈式架構在經濟性、安全自主、靈活性、可伸縮性等方面有明顯優點，隨着系統須要處理的交易量與數據量愈來愈大，分佈式架構在這方面的優點也會愈來愈明顯。集中式系統在可維護性、一致性方面有優點，而分佈式系統須要達到同等或更高的可維護性與高一致性，須要經過先進的分佈式中間件與大規模運維平臺來支持。

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

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

其實不是，上面的架構升級過程，實際上是對線上問題不斷髮現和解決的過程，也是一個不得已的過程。若是一個系統的用戶量、業務量不大，一開始就複用一套龐大的系統架構，那真的就費時費力，累死本身，徹底不必。因此，合適就好。