分布式系統中的CAP理論，面試必問，你理解了嘛？
對于剛剛接觸分布式系統的小伙伴們來說，一提起分布式系統，就感覺高大上，深不可測。而且看了很多書和視頻還是一臉懵逼。這篇文章主要使用大白話的方式，帶你理解一下分布式系統
本文通過介紹使用責任鏈設計模式的背景和經歷，來使得讀者加深對于此設計模式的印象，甚至受到一定的啟發來對自己當下所參與、所負責的項目進行“整容”，從而提升系統的“美感”。分享工作中的點點滴滴。
在下所負責的系統中有這么一個模塊，分區模塊，直接看這個詞的話相信很多人都會疑惑甚至是誤解，其實其真正的含義就是“路由”，接下來我簡單描述一下何謂“路由”。
相信大家都有過網上購物的經驗，每當我們下完訂單后，我們都能隨時隨地的查看訂單的物流跟蹤狀態，而上述的“路由”概念就是指：訂單從A地到B地的運輸路由線路，例如訂單order1要從A運輸到目的地F，其可以從A->B->D->F，也可以從A->D->F，至于具體應該走哪條線路，是靠系統中配置的路由以及對應的匹配規則進行篩選出來的。
很長的一段時間里，系統里的路由配置和規則都是靜態的（所謂靜態就是提前配置好并且幾乎是固定不變的），這種做法的弊端很明顯，就是成本無法控制，就如同上述所講的例子，運輸路線明明有機會可以減少甚至是可以直送（A地到F地的貨物明明可以裝滿N車，卻也不得不按照系統中制定的路線進行運輸），但是卻被系統中定死的路由規則所限只能多走一些道路，提高了人力作業和運輸的成本。
基于此有位大牛發現了降本增效的商機：就是讓這塊路由線路和規則動起來，使得系統能夠更靈活的兼容上述情況，達到資源的極限利用，舉個例子：比如有很多訂單都是從A要送達目的地F的，系統中靜態線路配置的只有A->B->D->F，但是經過系統監測計算發現從A到F的貨物量可以裝滿兩車，那此時為這些訂單臨時生成一條新的線路從A直達F，同時在A場地進行收貨、發貨等凡是涉及到路由線路匹配的實操環節時，均兼容上此臨時路由的場景，這樣就能在不改變用戶習慣的情況下將整體成本給降下來，并且運輸到目的地的效率也得到了大大的提高。
這位大牛提出的方案很好，得到了大家的廣泛認可和好評，于是在立項后進入了轟轟烈烈的開發階段，而在下有幸被委以重任來主導完成此項目的開發交付。
值得一提的是，路由線路這塊的改動貫穿了訂單的整個實操流程以及一些邊邊角角的輔助查詢、統計報表等功能，場景涉及眾多，所以壓力還是蠻大的，雖然期間也確實走了不少彎路，但最終的結果是好的，甚至在之后的又來了幾個類似變動路由線路的需求，但是基于此次改造后，我們這邊都能進行輕松應對，這個在文章后續的效果中會體現一下。
說了這么一大堆，有沒有覺得其實都是廢話的感覺，哈哈，確實有點啰嗦，接下來讓我們來夢回路由，再現一下整個稀碎而又有成就感的改造過程。
后續文章中提到的分區是為路由匹配規則的含義
首先來看一張簡易的實操流程示意圖：
在每個場地的實際操作的作業流程中都會涉及到分區匹配規則的情況，同時在一些輔助實操作業的查詢功能或報表功能中也會涉及到路由匹配規則，所以一旦分區匹配規則要做變動，那么就會面臨如下痛點：
?首先，在業務層面上就會幾乎貫穿整個流程，無論是評估、開發、測試等環節都會面臨工作量巨大的問題
?再次，從系統層面上來看，這部分的代碼現狀也非常不友好，主要體現在：
?分區匹配核心業務規則一致，但是代碼寫法不一，并且分布散亂，讓人難以閱讀與維護，同時伴隨場景遺漏的風險
?分區匹配功能目前都是各個實例自行編寫并且耦合在各個使用場景中，不具備擴展性，一旦規則變化，改動成本非常高
基于上述痛點，在下決定下定決心將此模塊進行重構整治一番，一來通過此次挑戰來提高自我、二來也為以后此塊規則再次變更的可能做好鋪墊，那么具體應該怎么做才能解決上述所提到的痛點呢？我是這么做的。
1.業務層面上做好充分的評估：體現在開發的詳細設計上（這里由于在下對于業務規則非常熟，所以算是是本人的優勢拉哈哈），像場景梳理啊、修改方案、甚至在設計中下沉到了具體功能（按鈕點擊啊、錄入框輸入后的回車觸發啊等等這些細節）的修改邏輯方案以及代碼位置，以便讓所有參與開發人員以此為指導手冊進行快速開發，測試人員以此為指導進行用例編寫、產品人員以此為字典加深其自身對于此塊業務的理解等等。聽起來是不是很牛X，哇哈哈，這里有點吹噓拉，本文中不著重介紹這里，主要介紹設計模式哈，咱們緩緩繼續往下看。
2.這里是我們的重頭戲哈，系統層面上主要體現在代碼上，畢竟說的再好，落實不到代碼，看不到效果都是白搭嘛，何況咱又是職位，好了，廢話不多說，繼續看我表演，哈哈
?首先將分區匹配核心模塊進行統一的收口，在系統中只保留一個實例進行服務提供，既能解決代碼分散維護成本高的問題、又能避免場景遺漏的風險。
看到這里或許會有人說，你這個會不會帶來另外一個問題啊：雖然場景不會遺漏了，達到了一處代碼變動，處處場景都會生效，但是會不會改動了某些場景原有的功能特性？能想到這里的同學，確實很細心哈，如果是硬性收口的話的確是會產生這個新問題，所以統一收口這塊一定要支持擴展，預留好鉤子便于支持各個場景的差異化處理。這么說比較抽象，舉個例子：比如通用場景規則是所有單子都按照系統既定配置的分區規則進行運輸，但是現在有一些商家開通了一些快速送到目的地的服務，那對于這些商家的單子就不能用現有的通用規則進行分區匹配運輸了，要按照新的規則進行分區匹配從而達到快速運輸的目的。這就是里邊的差異化。
?復用現有的數據結構，增加分區類型，并調整對應的sql和service服務（這里不是本篇重點就不展開講了），在兼容現有生產邏輯的基礎上支持分區規則的擴展
?結合設計模式的思想調整分區匹配規則的代碼結構：采用責任鏈模式（這里是本篇文章的重點內容）
那么，到底什么是責任鏈模式呢？
大牛給出的定義：使多個對象都有機會處理請求，從而避免了請求的發送者和接受者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有對象處理它為止。
結合著現有系統的實際業務來講講我是如何進行套用的：開篇背景中已經介紹過現有的分區匹配規則為靜態分區匹配（如某某業務點到點、某某業務點到范圍區域等等，具體業務細則就不展開講了，只要知道這里邊的匹配規則一大堆即可），現在要新增一種規則支持動態（也是各種匹配，就不展開講了），這里我把每一種分區規則都定義為一種分區類型，而每一個分區類型都定義為一個分區節點，將這些節點穿成一條鏈，讓每個請求都在這條鏈中找到匹配自己的線路進行運輸。
由于業務細則比較敏感，文章中就不具體透露了，不影響重點設計模式的應用理解
結合定義以及上述分析，那么實際情況到底適不適合使用責任鏈設計模式呢？在下認為只要能夠解決上述痛點并且總體的利大于弊，那么就是適用的。首先使用此模式改造后的優點如下：
?將請求和處理分開了（從與業務實操的耦合中解脫出來，完全不用關心請求是怎么來的，只專注于分區規則的匹配）
?提高了系統的靈活性和擴展性（再有新的規則，只需要增加節點即可）
當然了，此模式也有一定的缺點：當責任鏈比較長的時候，由于每個請求都會遍歷整個鏈條，可能會有性能的問題，同時對于不理解業務的同學調試起來也會感覺比較復雜。
整體看下來，優點是解決了我們當下的痛點，并且利于后續的擴展，而缺點中的性能部分可通過結合模板模式中預留的鉤子函數（如果當下請求不適合于當下分區節點規則則跳過）拉最大限度的降低性能問題的影響，同時基于開發人員了解業務也是應當的。那這樣看來總體還是利大于弊的。
說了這么多我們先來看看改造前后的分區模塊的簡單對比示意圖吧！
雖然圖非常簡陋，但是其對比含義還是很明顯的，改造前：分區匹配和業務處理是耦合在一塊的；改造后：分區匹配是一條鏈并且里邊沒有業務邏輯處理，從耦合中解脫了出來，也支持擴展。看到這里會有人疑惑：上文中不是說只新增了一個動態匹配規則嗎，怎么鏈中有這么多節點，而且還是兩條鏈。這里我稍作解釋下：當下的兩條鏈是經歷過許多需求版本變更的，當下看起來區別已是不大，主要是因為其提供的來源業務指定場景不同抽象出來的兩條鏈，互不干擾各自運行，而里邊多處本文介紹的那些節點也是后來新增的，直至當下還在系統中使用的節點規則（這也就是文章開篇我提的：萬一后邊還有規則變更呢。果然還是機智如我，“預言”應驗了，在效果中我會講出這里支持擴展對于縮短工期的重要性）
相信有不少讀者會發現，上面又是說統一收口、又是說結合模板模式最大程度規避性能影響，那你這個責任鏈一種設計模式是支持不了的吧。
沒錯，你說對了，大聰明，確實只是使用單一的責任鏈設計模式遠遠達不到上文中所說的效果，這里我們也確實將工廠、模板、責任鏈模式進行了結合使用，工廠用來獲取鏈條的bean，模板用來設置通用方法、方法間的調用以及預留給子類實現的開關、前后置處理、差異化等方法，責任鏈用來組合各個節點，這里簡單抽幾個節點將類圖展示出來如下：
這段就比較簡單了，畢竟就是擼碼，上面的類圖幾乎代碼中的實踐應用了，也是代碼中的核心部分，而在實際調用中均是通過工廠來獲取bean鏈條進行具體分區匹配的。
改造過后的成果主要體現在后續的擴展和維護，就如文章開篇提到的一旦分區匹配規則要做變動就會面臨兩個痛點，最直接的體現就是在工期上面，第一次接此塊的變動新增路由規則需求時，整體實際用的工期就研發側來說是45天，就更別說一旦遇到BUG，那測試工期也就沒保障了（對應上圖節點中的動態節點）。
但是后來沒多久就又再次增加匹配規則的新需求（對應上圖節點中的到倉拼車節點），同類的需求，工期縮短近半，優45天降低到了27天，這里還包括此需求中的其他非分區模塊的改造，當然了第一版的改造確實有些完美的地方，經過這次需求由進行了優化。
接下來的這兩個就真正體現到了什么叫做工期消失術，一個是首板分區規則需求，一個是最近B網融合需求中的直發分區規則：
?直發分區工期2天
?首板分區工期就1天
說實話，我在沒回看這些數據的時候也沒想到有這么大的效果，現在回頭一看我也是驚呆了，誰能想到一個設計模式的應用竟能將工期由45天縮短至了1天，這太不可思議了。
當然了其中也還有一些可以改進升級的地方，目前責任鏈節點的裝配都是手動指定的，可改動為自動裝配（我在另個業務場景中的改造中已經實現過了，這里也會進行同步改造），再有一個就是要控制節點的數量，如果數量過大則可能需要考慮兼容方案了。
俗話說滴水穿石非一日之功,冰凍三尺非一日之寒，追求強大的工具、新穎的技術固然可行，但是也不要忘了日常工作中的一點一滴的小改動，短時之間可能看不出什么，一旦量變引起了質變，我相信那結果將是非常可觀亮眼的。
本文鏈接：http://www.tebozhan.com/showinfo-26-87676-0.html系統整容紀：責任鏈設計模式的應用實戰
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號