項目復盤

前言

　　最近一年半多一直在做一個CMS項目，做了快兩年了也沒有上線，而且開發還走了不少，其中有不少原因是因為開發中頻繁改動需求導致開發人員失去耐心，但是其中還有一個重要的原因就是架構設計的不好，導致很多服務的邊界很模糊，耦合性強，改一處需求從而導致遷一發動全身的惡果！下面復盤下這個項目中架構設計的坑，從中吸取教訓！

架構圖

　　首先，這個項目采用的SOA的架構，分為多媒體、廣告、任務調度、核心這四個模塊，其中核心這個模塊定義的很模糊，把認證、授權、站群全部放在的核心模塊中，這樣導致核心模塊成了一個臃腫的單體服務。

　　　　

?

多媒體模塊：負責圖片、視頻、文件資源的上傳下載，需要視頻轉碼、圖片處理時則調用task模塊負責，task處理完成后再通過mq回調core通知任務處理成功。

廣告模塊：負責接入大數據便簽，通過大數據推送的人物畫像標簽動態生成廣告，實現千人千頁廣告效果（廣告模塊的理想狀態下的功能，實質上有各種原因沒有實現‘千人千頁’的效果，后面會具體說下原因）

調度模塊：負責處理多媒體的圖片、視頻，站群的發布任務（這個模塊的服務邊界很模糊，導致調度模塊過多耦合業務最終成了一個誰也說不清楚的爛攤子服務……）

核心模塊：這個模塊同樣存在服務邊界模糊的問題，核心模塊里面有包含了用戶模塊、站群站點模塊、OpenApi模塊，最終結果就是一個四不像的單體應用……

通過上面的描述，其實發現一最大的問題就是模塊之間服務邊界很模糊，大家誰也說不清楚這個模塊到底是一個工具模塊（調度模塊）還是一個業務模塊，開發者不清楚那些邏輯要寫在core里面，那些邏輯是要交給task里面，再加上開發者的水平也參差不齊，對業務和架構理解不透徹，架構師也沒有及時的codeview（或者說，架構師自己對模塊之間的服務邊界問題也很模糊），最終的結果就是大家沒有統一的開發原則，自己的代碼想寫在那個模塊就寫到哪個模塊中，時間長了連開發者自己也不清楚一個業務到底有哪個幾個模塊參與了或者自己捋不清楚自己負責的業務線（當然，這里還有一種可能，就是模塊之間的服務邊界很模糊，有些開發者可能為了偷懶強行把一個業務部分邏輯放在其他模塊中，讓別人替自己實現，美其曰，這是按照模塊開發的思想，其實這本質是一種不負責的表現！）。

優化后的架構

　　優化后的架構還是SOA架構，把核心模塊拆分成了用戶模塊、站群站點模塊，調度模塊里面的業務邏輯遷移到業務層中，從此調度模塊不再負責業務處理，只負責任務的調度，所有的業務代碼全部放在業務層中，生命周期也全部在業務層中。

這里強調一下，之前的調度模塊里面有業務代碼，所有有些業務的生命周期是跨模塊的，這樣會導致業務線不完整，或者耦合很大。調整后的調度模塊，只服務調度任務，任務的的具體實現是由發起調度任務的開發者實現，即：誰調度誰實現，這樣的好處有兩點，一是調度模塊由業務模塊轉變成了工具模塊，解耦合，二是業務代碼的生命周期完全在業務層中，不會再出現一個業務線開發者自己都捋不清楚的情況發生，即：誰開發誰掌握代碼的生命周期。具體調度模塊怎么調度任務，這里有很很多的實現方式，rest、rpc都可以實現，完全沒有必要通過MQ來調度任務。

最后吐個槽，一個合格的架構師一定是一直保持在一線碼代碼的高級工程師，如果只會ppt不能技術落地這樣會害死人的……

?