大話分佈式服務——初識分佈式服務

初識分佈式服務

目錄

初識分佈式服務

簡介

正文

創業期

發展期

成熟期

後記


簡介

         大家好,我們開始第一章 初識分佈式服務

正文

         本文以初識爲題,旨在初步介紹分佈式服務的相關信息,給讀者一個初步的印象。那麼怎麼來解讀分佈式服務呢?分佈式服務是計算機系統服務中的一種概念,那什麼算是分佈式服務呢,這個要從軟件系模式起源來介紹了。 一個成熟的分佈式系統總是經歷過了很多人的辛苦付出,經過了N次的迭代發佈之後才產生的。 本文以一個小夥伴創業最後成就自我的例子來介紹下系統發展歷程,給大家體會一下什麼分佈式的由來

創業期

         我們可以想象一下,假如當前有三個好朋友商量着要不我們創業吧 ,做一個電子身份證怎麼樣。就這樣三人一拍即合開始做,就這麼一個單純的數據管理功能,那我們的系統初期肯定就搭建一個web系統包括用戶的正常的登錄,信息新增和變更,然後對應的有一個數據庫的實例來進行數據的管理基本上就可以夠用了

 

發展期

         隨着企業發展,開始跟其他的業務來合作,那比如說公司跟某店合作,開始管理用戶的收貨地址和聯繫信息。隨着業務增加,發現數據查詢量越來越大性能也越來越差,怎麼辦呢,加緩存吧,noSql的redis開始搞進來。

         隨着發展使用人數的不斷增多,那我們的數據越來越多,然後開始有用戶反饋系統越用越卡了,怎麼辦呢,系統響應越來越差了,那這麼繼續下去,用戶肯定是會越來越少呀。那就開始找問題唄,發現現在數據庫的數據總量記錄太多了都好幾百萬條了,然後發現有很多是歷史已經刪除的數據了實際是用不到的,那好辦呀 開始數據結轉唄

         到現在爲止,系統還一直處於最原始的垂直架構上,直上直下一大坨,但是後來跟某寶合作了,最先出現的問題就是對外支持的收貨地址信息性能出現問題,怎麼辦? 單機跟不上了,那就多機,前面加個負載。然後就麼繼續搞,這就開始引入了集羣了

         然後系統業務繼續發展,主要對外的就是查個收貨地址,官網註冊修改信息,其實跟這個查詢沒啥關係 ,這不是啥問題,就是資源浪費,因爲每個部署的應用都包括了公司所有的業務服務,實際上是沒有必要的,那就拆開唄。從這就開始系統拆分了,這個階段應該就可以理解爲進入了分佈式服務的初級階段了,這會業務簡單不做贅述,就先按業務,把官網註冊維護數據和對外收貨地址查詢拆分成兩個應用,然後官網部署一臺機器,查詢部署個10臺

         拆完了之後,後來緩存扛不住了,怎麼搞? 單機不行,分流唄,引入緩存集羣分片來解決查詢單機瓶頸問題。

後來發現查詢信息部分流量進入數據庫,影響數據庫的性能,然後導致有些時候,新增用戶失敗和更新信息不可用。怎麼辦?讀寫數據庫共享有問題,怎麼辦拆,引入讀寫分離。

         一段時間之後,用戶量繼續增長,寫庫性能下降,怎麼辦? 分庫分表,給分2個庫,一個庫分個20個表,基本上夠用一陣子了。

成熟期

         現在我們再去看那個企業,發現公司已經不滿足於給別的企業提供,地址管理服務這麼簡單了,開始自己搞電商了,那電商互聯網產業在業界就就簡直是秒殺、大流量、高併發的代名詞了,

         然後開始公司有自己的進銷存系統,開始有商品、訂單、交易、營銷等等一大堆的東西,然後這個系統也面臨着它的繼續進化,

         首先隨着系統業務的增加,開始有了更多的系統分佈,那這些系統已什麼維度進行拆分就是一個很大的學問了,如按業務縱向拆分內部閉環、也有的主張橫向業務拆分。這裏我們應該是開始瞭解微服務了。微到什麼程度,這個是一門藝術,個人感覺這個沒有放之四海而皆準的方案,還是需要結合實際的業務來做,這部分讓我概括來說,真的是如三國說的“天下大勢分久必合合久必分” 發展到這個階段,服務治理也就顯得尤爲重要了,RPC框架,依賴圖譜,調用全鏈路追蹤,彈性伸縮這些也就是成了要具備的能力了

         再換個角度去介紹,有了商品,那就肯定有商品定價、競價分析等一系列的能力,數據搜索引擎、千人千面推薦之類的,以及賣貨庫存扣減超賣,退貨恢復庫存等等,然後應該也會隨之遇到的分佈式事務呀、最終一致性呀,這些也就很容易的被引起注意了,沒辦法啊 ,不注意就該被坑了。

         說完庫存類的問題,我們再聊聊交易方面的問題,每年的618 雙十一,時不時的可以看到爆出某某平臺的零點不能支付了等等的問題。這種的問題究其根本原因那就是交易的全鏈路太長了,然後在高峯流量情況下部分節點出現了問題,導致的系統不可用,那爲什麼又能快速的恢復呢,我們就這個問題來簡單聊聊,我們作爲一個消費者從平臺選購商品,要經過商品展示的N多查詢服務,然後加入購物車之後要經過購物車管理服務,然後我們要選擇最適合自己的優惠服務,然後再提交訂單之前我們還要選擇我們的收穫地址,最終提交下單支付,支付的時候我們要選擇支付工具,要提交支付要經過密碼驗證,甚至有可能還要經過風險驗證,我們感受到的就有這麼多環節。然而在業務系統內部服務中,它們會經歷N多的節點之後才能完成我們的一筆訂單交易。這其中任何一環都可能造成我們的系統失敗,那麼當發現失敗之後怎麼能夠快速恢復呢,這個地方我們就不得不提到熔斷降級類的手段了。

         我們再換個場景聊另一個話題 ,假如說公司要搞活動,10塊錢秒殺一臺電腦,此活動的關注度已經達到了幾千萬了,但是秒殺獎品就20個,怎麼搞? 這個場景要提的是預熱/功能前置、限流、名單等這類的維度,雖然說這類並非分佈式獨有。

 

 

後記

         上面以一個創建企業發展成爲一個成熟的電商企業爲例簡單介紹了下,隨着企業的發展,業務的不斷壯大,配套的系統也經歷了它的出生、成長、穩重三個階段。本文以白話敘事爲主,並沒有像很多架構博文,提供了N多的架構演進圖譜之類的信息。相對可能有點枯燥,

原來是想做成漫畫類的,奈何水平有限,作品不堪入目,就只能以文會友了。感謝觀看到結尾的您,今天的介紹就先到這,感謝各位朋友。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章