1. 程式人生 > 其它 >分散式系統架構設計-讀後

分散式系統架構設計-讀後

美團在對物流探索的過程中,積累了分散式高併發系統的建設經驗,其中主要有兩點:

1.即時物流業務對故障和高延遲的容忍度極低,在業務複雜度提升的同時,要求系統具有分散式、可擴充套件、可容災的能力。即時物流系統階段性的逐步實施分散式系統架構升級,最終解決了系統宕機的風險。

2.圍繞成本、效率、體驗核心三要素,即時物流體系大量結合了AI技術,從定價、ETA、排程、運力規劃、運力干預、補貼、核算、語音互動、LBS挖掘、業務運維、指標監控等方面,業務突破結合架構升級,打到促規模、保體驗、降成本的效果。

 

分散式架構是相對於集中式架構的一種架構體系,分散式架構適用CAP理論(Consistency一致性,Availability可用性,Partition Tolerance分割槽容忍性)

在分散式架構中,一個伺服器部署在多個對等節點中,節點間通過網路通訊,多節點共同組成叢集來提供高可用、一致性服務。

 

在早期美團按照業務領域劃分成多個垂直服務架構,隨著業務的不斷髮展,從可用性角度進行了分層服務架構,再後來業務發展越發複雜後,從運維、質量等多個角度考量後,逐步演進到微服務架構。

這裡體現了兩個原則:不宜過早進入微服務架構的設計中;好的架構是演進的而不是提前設計的

 

對微服務的一點理解:

在早期系統開發中,以購物網站為例,大致需要完成兩項任務,一個是網站首頁,一個是後臺管理,

但隨著系統不斷增加,功能會變得更加複雜,例如購物網站要進行某某促銷活動,這時系統的邊界會隨著一次次擴充而不斷變模糊,並且資料庫的呼叫也會變得十分混亂,十分不合理,

引入微服務,實際上是一種抽象,通過將系統服務拆分成更小的功能模組,甚至將資料庫拆分,各服務相互隔離,提升了系統的可用性、實時性。

但同時微服務也會帶來許多問題,例如不容易精確定位問題發生的位置,測試、開發工作複雜,因此小產品不宜盲目追求微服務,即使是美團也是隨著需求不斷增加而逐步演進到微服務。