研發(fā)團隊的總體架構(gòu)設(shè)計方案

1 研發(fā)團隊的總體架構(gòu)設(shè)計方案 寫在前面 企業(yè)總體架構(gòu)是什么 有什么用 具體怎么做呢 以我曾任職的公司為案例 一起來探討這個問題 這 家公司當(dāng)時有 200 位研發(fā)人員和 200 多臺服務(wù)器 我剛進這家公司時 他們的系統(tǒng)就已經(jīng)玩不下去了 總是出現(xiàn)各種問題 例如日常發(fā)布系統(tǒng)時或訪問量稍微過大時 系統(tǒng)就會出現(xiàn)很多故障 而且找不到故 障發(fā)生的根本原因 2 我進這家公司后的主要任務(wù)就是對這個系統(tǒng)進行升級改造 花了一個半月的時間寫了那份企業(yè)總體架構(gòu) 文檔 文檔共有 124 頁 直接指導(dǎo)了之后的技術(shù)改造 下圖是那份文檔的目錄 一 企業(yè)商務(wù)模型 企業(yè)商務(wù)模型的內(nèi)容主要包括主營業(yè)務(wù) 商務(wù)模式 商務(wù)主體 競品分析 組織架構(gòu) 商務(wù)運作模型和 業(yè)務(wù)流程等 主營業(yè)務(wù)即公司做什么業(yè)務(wù) 商業(yè)模式即公司怎么賺錢 商務(wù)主體即哪幾個人在一起做這門生意 競品 分析即了解競爭對手的情況 組織架構(gòu)即公司部門是怎么劃分的 組織架構(gòu)圖中標(biāo)出人數(shù) 根據(jù)系統(tǒng)與 業(yè)務(wù)之間對應(yīng)關(guān)系 可以了解系統(tǒng)中哪些模塊使用頻率高 以及業(yè)務(wù)與其對應(yīng)模塊的復(fù)雜度 商務(wù)運作 模型即公司是如何運作的 售前做計劃 找供應(yīng)商把東西買進來后 經(jīng)過服務(wù)和結(jié)算 再賣給我們的經(jīng) 銷商和采購商 使我們獲得利潤 售后進行大數(shù)據(jù)分析最后又指導(dǎo)著我們的售前 整個過程形成良性循 環(huán) 可以把一家公司想象成一臺機器 輸進去的是錢 轉(zhuǎn)一轉(zhuǎn)后 又能夠生出更多的錢出來 3 最后是業(yè)務(wù)流程和更多業(yè)務(wù)資料下載 業(yè)務(wù)流程包括預(yù)訂流程 訂單處理流程 產(chǎn)品供應(yīng)流程 財務(wù)結(jié) 算流程 賬戶管理流程 企業(yè)商務(wù)模型的建立 指導(dǎo)著整個應(yīng)用系統(tǒng)模型的建立 畢竟系統(tǒng)是為業(yè)務(wù)服 務(wù)的 二 架構(gòu)現(xiàn)狀 架構(gòu)現(xiàn)狀的內(nèi)容主要包括 功能架構(gòu) 應(yīng)用架構(gòu) 數(shù)據(jù)設(shè)計和物理架構(gòu) 功能架構(gòu) 4 功能架構(gòu)主要包括功能 角色和權(quán)限三部分 功能是企業(yè)服務(wù) 用戶使用的每一個功能 就是企業(yè)的每 一個服務(wù) 角色是用戶操作的歸類 功能與角色的對應(yīng)關(guān)系即權(quán)限 了解系統(tǒng)架構(gòu)的現(xiàn)狀 從功能架構(gòu) 開始 應(yīng)用架構(gòu) 應(yīng)用就是處理器 應(yīng)用架構(gòu)的內(nèi)容包括現(xiàn)有架構(gòu)圖 Web 應(yīng)用現(xiàn)狀 作業(yè)小應(yīng)用 Job 現(xiàn)狀和接口架 構(gòu) 其中 接口是應(yīng)用層面的關(guān)鍵 它是一個程序與另外一個程序交互的部分 5 應(yīng)用架構(gòu)圖表列出了哪些業(yè)務(wù)邏輯沒有被重用 換句話說業(yè)務(wù)邏輯被多少個應(yīng)用調(diào)用 就需要被重復(fù)開 發(fā)多少次 一旦改了一個地方 就要同時改多個地方 導(dǎo)致系統(tǒng)開發(fā)效率非常低下 各業(yè)務(wù)邏輯如預(yù)訂 邏輯 雖然被多個應(yīng)用調(diào)用 但它們與應(yīng)用是沒有關(guān)系的 業(yè)務(wù)邏輯可以獨立的存在 也可以寄宿于多 個應(yīng)用 業(yè)務(wù)邏輯是一個業(yè)務(wù)操作的抽象 而業(yè)務(wù)應(yīng)用與業(yè)務(wù)部門共同完成了業(yè)務(wù)操作 數(shù)據(jù)設(shè)計 100 多個數(shù)據(jù)庫 一萬多張表 能否使用一張 E R 圖來表示呢 它是可以的 數(shù)據(jù)設(shè)計依賴于企業(yè) 的數(shù)據(jù) 而不是數(shù)據(jù)庫的設(shè)計 對企業(yè)數(shù)據(jù)適當(dāng)做歸類 會直接導(dǎo)致數(shù)據(jù)設(shè)計 最終畫出 E R 圖 數(shù)據(jù) 設(shè)計完成后 數(shù)據(jù)庫設(shè)計就自然而然出來了 超越庫 超越表去看這張 E R 圖 可以看出它包括產(chǎn)品 訂單 結(jié)算 用戶 基礎(chǔ)設(shè)施這五類數(shù)據(jù) 低層的 E R 圖可以變 但是高層的 E R 圖一般不會變化 因為它是根據(jù)你的業(yè)務(wù)模型而定 業(yè)務(wù)模型穩(wěn)定 高層 E R 圖也是穩(wěn)定的 數(shù)據(jù)庫只要早期設(shè)計得好 是可以做到易伸縮 易拆分的 下圖從內(nèi)往外看 一個框既可以是一個庫 也可以是一個模塊 還可以 6 是一個表 在業(yè)務(wù)發(fā)展的早期它可以是一個庫 里面有 5 個模塊 中期可以分為 5 個庫 后期以更低級 別可以分為更多的庫 這與業(yè)務(wù)階段及系統(tǒng)復(fù)雜度相關(guān) 在數(shù)據(jù)的設(shè)計完成后 數(shù)據(jù)庫的設(shè)計也就很容 易規(guī)劃和調(diào)整 以上是數(shù)據(jù)庫 數(shù)據(jù)表之間的靜態(tài)關(guān)系 接下來我們介紹數(shù)據(jù)的流轉(zhuǎn)狀態(tài)即狀態(tài)圖 通過數(shù)據(jù)狀態(tài)圖去 了解現(xiàn)有數(shù)據(jù)流轉(zhuǎn)變遷 如國內(nèi)訂單狀態(tài)變遷圖 這種圖的價值不僅在于數(shù)據(jù)庫層 還在于服務(wù)化 圖 中的從等待支付到支付成功 中間有個支付行為 通過這個支付行為把數(shù)據(jù)狀態(tài)變更為支付成功 否則 繼續(xù)等待 直到超時關(guān)閉訂單 這個支付行為可以做成一個微服務(wù) 然后由不同的應(yīng)用去調(diào)用 7 物理架構(gòu) 物理架構(gòu)的內(nèi)容主要包括 IDC 機房 機房之間訪問關(guān)系 機房內(nèi)服務(wù)器物理部署圖 機房與業(yè)務(wù)分布 網(wǎng)站架構(gòu) 數(shù)據(jù)庫架構(gòu) 集群清單和域名清單 將這些內(nèi)容以列表和圖形方式整理出來 就會很容易了 解和發(fā)現(xiàn)問題 只有發(fā)現(xiàn)問題才能解決問題 特別是在全局體系架構(gòu)方面 這也是表和圖的價值所在 當(dāng)時這家公司共有 5 個地區(qū) 8 個機房 雖然只有 200 多臺服務(wù)器 但分布很散 導(dǎo)致物理結(jié)構(gòu)復(fù)雜 通訊也很復(fù)雜 技改前故障不斷 其主要的一個原因就是物理架構(gòu)不合理 運維要占 60 70 的責(zé) 8 任 當(dāng)時卻把責(zé)任歸咎為應(yīng)用架構(gòu) 這是個錯誤的方向 物理架構(gòu)的不合理 應(yīng)用架構(gòu)是很難合理的 因為物理架構(gòu)是我們的基礎(chǔ)設(shè)施 位于最底層 下層為上層服務(wù) 運維要為應(yīng)用服務(wù) 應(yīng)用要為業(yè)務(wù)服 務(wù) 業(yè)務(wù)要為客人服務(wù) 三 領(lǐng)域模型 領(lǐng)域模型關(guān)注概念 關(guān)注職責(zé) 關(guān)注邊界 關(guān)注交互 只有先確定職責(zé)和邊界 交互才會很清晰 領(lǐng)域 模型是針對現(xiàn)有問題域提出一個系統(tǒng)解決方案 然后在圖表上建立完整的模型 如同用 AutoCAD 畫的 施工圖紙一樣 領(lǐng)域模型屬于概要設(shè)計階段 對于單個應(yīng)用架構(gòu)設(shè)計 首先需要了解業(yè)務(wù)和功能需求 用例圖 用例活動圖 然后才是領(lǐng)域模型 業(yè)務(wù)流程圖是對業(yè)務(wù)操作的抽象 領(lǐng)域圖是對業(yè)務(wù)邏輯代碼 的抽象 9 建立領(lǐng)域詞匯是建立領(lǐng)域模型的第一步 它能統(tǒng)一詞匯明確概念 以減少一詞多義 一義多詞的情況 概念一旦確定 再擴展屬性和行為 然后把它當(dāng)作一個單元與其它事物構(gòu)建在一起 就會很容易形成模 型 領(lǐng)域模型與企業(yè)商務(wù)模型中的業(yè)務(wù)流程圖有參考對應(yīng)關(guān)系 領(lǐng)域模型在實現(xiàn)時可大可小 在業(yè)務(wù)的 早期 在系統(tǒng)比較小的情況下 它有可能是一個類 當(dāng)系統(tǒng)做大了以后 它可能是個 DLL 庫 再做更大 一點的時候 它可能是一個服務(wù) 給不同的應(yīng)用去調(diào)用 每一個方法都有成為服務(wù)的潛質(zhì) 特別是在系 統(tǒng)中后期 領(lǐng)域模型是業(yè)務(wù)邏輯代碼的施工圖紙 它不僅有利于對現(xiàn)在系統(tǒng)業(yè)務(wù)邏輯的了解 同時也指 導(dǎo)未來的架構(gòu)改造 四 架構(gòu)規(guī)劃 當(dāng)我們了解了業(yè)務(wù) 了解了架構(gòu)的現(xiàn)狀 發(fā)現(xiàn)現(xiàn)有架構(gòu)的問題 接下來就可以做中遠(yuǎn)期架構(gòu)規(guī)劃 以及 架構(gòu)的調(diào)整和具體實施 架構(gòu)規(guī)劃內(nèi)容包括 頂層架構(gòu)規(guī)劃 網(wǎng)站功能規(guī)劃 應(yīng)用規(guī)劃 SOA 規(guī)劃 分 層架構(gòu)規(guī)劃 數(shù)據(jù)庫規(guī)劃和物理規(guī)劃等 頂層架構(gòu)規(guī)劃 10 上圖是頂層架構(gòu)的俯視圖和側(cè)視圖 第一張圖是俯視圖 坐在飛機上看 整個頂層架構(gòu)最外層的是功能 中間的是業(yè)務(wù)操作 內(nèi)層的是數(shù)據(jù) 功能對應(yīng)業(yè)務(wù)系統(tǒng)的用戶界面 操作對應(yīng)業(yè)務(wù)系統(tǒng)里的服務(wù) 數(shù)據(jù) 對應(yīng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲如數(shù)據(jù)庫 第二張圖是剖面圖 切一刀來看 上層是應(yīng)用 中層是服務(wù)和框架 下層是基礎(chǔ)設(shè)施數(shù)據(jù)中心 從圖中的服務(wù)層可以看出 服務(wù)的歸類跟業(yè)務(wù)流程的歸類有很大關(guān)系 11 網(wǎng)站功能規(guī)劃 網(wǎng)站功能規(guī)劃就是功能的重新劃分 對照著架構(gòu)現(xiàn)狀 未來的功能應(yīng)該如何調(diào)整 如案例中的國內(nèi)網(wǎng)站 功能規(guī)劃 分別畫出了全局功能圖 采購商功能圖 平臺商功能圖和供應(yīng)商功能圖 其實在做網(wǎng)站功能 規(guī)劃的時候 更多需要考慮現(xiàn)狀 而不是未來調(diào)整的部分 如果沒有很大問題 則不做調(diào)整 尊重歷史 因為有些東西 如名稱 用戶已經(jīng)使用很久了 調(diào)整往往比較難 合理大于準(zhǔn)確 應(yīng)用規(guī)劃 系統(tǒng)是什么 系統(tǒng) 元素 關(guān)系 應(yīng)用架構(gòu)是什么 應(yīng)用架構(gòu) 應(yīng)用 架構(gòu) 應(yīng)用就是系統(tǒng)的最小 單元 應(yīng)用分類和應(yīng)用編號則構(gòu)成了應(yīng)用關(guān)系即應(yīng)用的架構(gòu) 如上圖中的案例 應(yīng)用分類新建了框架 Fx 和公共服務(wù) CBS 原有的應(yīng)用架構(gòu)中并沒有這兩個的 而是分布在了不同的業(yè)務(wù)線中 從而導(dǎo)致重復(fù)建 設(shè) 應(yīng)用編號是給每個應(yīng)用分配一個六位的數(shù)字 ID 就如同我們的身份證一樣 頭兩位表示產(chǎn)品線 中 間兩位表示子系統(tǒng) 最后兩位表示應(yīng)用 如 應(yīng)用編號是應(yīng)用管理 依賴和追蹤的基礎(chǔ) 集中式日志和 監(jiān)控框架都有使用到應(yīng)用編號 SOA 規(guī)劃 12 SOA 規(guī)劃就是接口規(guī)劃 它的歸類與商務(wù)模型中的業(yè)務(wù)流程有參考對應(yīng)關(guān)系 上圖案例有五個服務(wù)中心 預(yù)訂服務(wù) 訂單處理服務(wù) 產(chǎn)品供應(yīng)服務(wù) 財務(wù)結(jié)算服務(wù)和公共服務(wù) 每個服務(wù)只需要實現(xiàn)一套自己的 邏輯 我們的前臺 后臺 接口 作業(yè)小應(yīng)用等都可以調(diào)用 服務(wù)的邏輯跟我們的業(yè)務(wù)邏輯是一致的 修改代碼的時候只需要改一個地方就可以影響到所有調(diào)用到這服務(wù)的前端應(yīng)用 分層架構(gòu) 分層架構(gòu)看似很簡單 但保證整個研發(fā)中心都使用統(tǒng)一的分層架構(gòu)就不容易了 那么如何保證整個研發(fā) 中心都使用統(tǒng)一的分層架構(gòu)呢 以達(dá)到提高編寫代碼效率 保證工程統(tǒng)一性的目的 先簡單介紹下當(dāng)前 兩種比較流行的分層架構(gòu)體系 一種是領(lǐng)域架構(gòu) 倉儲層 Repository Layer 領(lǐng)域?qū)?Domain Layer 應(yīng)用服務(wù)層 Application Layer 表現(xiàn)層 Presentation Layer 和基礎(chǔ)公共層 Infrastructure Layer 請 13 見第一張圖 另一種是相對傳統(tǒng)地分為三層 數(shù)據(jù)層 Data Layer 應(yīng)用邏輯層 Business Layer 和表現(xiàn) 層 Presentation Layer 請見第二張圖 14 領(lǐng)域架構(gòu)和三層架構(gòu)之間有什么區(qū)別 我們是這樣認(rèn)為的 在早期我們做三層架構(gòu)的時候 大都以表來 做驅(qū)動的 在做領(lǐng)域架構(gòu)的時候 大都以業(yè)務(wù)邏輯來驅(qū)動的 兩者的區(qū)別確實比較明顯 但到了現(xiàn)在 如果都以業(yè)務(wù)邏輯為中心的話 實際上兩者并沒有本質(zhì)區(qū)別 當(dāng)時 我所在公司采用了第二種分層法 我們希望把分層做得極簡 也就是說哪怕剛畢業(yè)進來的員工 在分層時基本上也不會亂 而相對第一種 分層法 第二種分層法簡單很多 每一個應(yīng)用的代碼量都不應(yīng)該很大 一旦工程變得過大 我們就會把 它適當(dāng)拆分 而不是全部放在一個單塊應(yīng)用里 總之 我認(rèn)為分層越簡單 整個軟件結(jié)構(gòu)就越清晰 代 碼就越容易統(tǒng)一 把工程做得極簡 才有利于復(fù)制 有利于業(yè)務(wù)的快速構(gòu)建 有利于規(guī)?；?穩(wěn)定可靠 數(shù)據(jù)庫規(guī)劃 15 數(shù)據(jù)庫是整個信息系統(tǒng)中生命周期最長 最難修改的部分 所以要加強規(guī)劃 數(shù)據(jù)庫的設(shè)計至少要提前 兩步 具體根據(jù)高層 E R 圖和數(shù)據(jù)設(shè)計來新建數(shù)據(jù)庫 早建要比晚建好 數(shù)據(jù)庫調(diào)整的代價大 周期長 長時間產(chǎn)生的問題 需要長時間來解決 先在新庫里解決新表 再根據(jù)當(dāng)前業(yè)務(wù)和應(yīng)用的需求 逐步調(diào) 整舊表 物理規(guī)劃 16 物理架構(gòu)的規(guī)劃內(nèi)容包括集群規(guī)劃和域名規(guī)劃 首先是集群規(guī)劃 20 倍規(guī)劃 5 倍設(shè)計和 1 5 倍實施 規(guī)劃和設(shè)計要大一些 但實施時小一些 這樣不僅便于將來的擴展 也節(jié)省了當(dāng)前的費用 兩個邏輯網(wǎng) 絡(luò) 一個內(nèi)網(wǎng)和一個外網(wǎng) 兩個負(fù)載均衡 兩個防火墻 安全隔離內(nèi)外網(wǎng) 四條產(chǎn)品線 國際 國內(nèi) 新業(yè)務(wù)以及公共業(yè)務(wù) 單點登錄和企業(yè)支付網(wǎng)關(guān)等公共業(yè)務(wù)也屬于一條產(chǎn)品線 六個集群 Web 集群 SOA 集群 中間件集群 數(shù)據(jù)庫集群 Job 集群和 ITD 集群 以上橫向集群與縱向產(chǎn)品線形成了一個 矩陣結(jié)構(gòu) 也基本確定了網(wǎng)絡(luò)基礎(chǔ)架構(gòu) 對于域名規(guī)劃 對內(nèi)的域名該改的改 該停用的停用 該合并 的合并 對外的域名要盡量少改 要改的話也要有歷史繼承性 如跳轉(zhuǎn) 要盡量減小對用戶的影響 其它 除以上架構(gòu)規(guī)劃外 還有一些其它重要項 如源代碼管理規(guī)劃 文檔管理規(guī)劃 技術(shù)選型和團隊分工 為什么還要做這些呢 因為統(tǒng)一了源代碼怎么放 每個部門的文檔怎么放 將來要用什么工具版本 才 利于團隊的協(xié)作 基于統(tǒng)一的環(huán)境才能有更高層次地提升 對于團隊分工 需要逐步對齊組織架構(gòu)與系 統(tǒng)的架構(gòu)規(guī)劃 對于技術(shù)選型 需要注意中間件的引進 要有節(jié)奏性 力量要相對集中 要小規(guī)模試點 找非核心項目 試用成功后再進行大規(guī)模推廣 架構(gòu)實施 17 做完架構(gòu)規(guī)劃后 就是架構(gòu)實施落地了 我們的架構(gòu)實施整體思路是 樹目標(biāo) 給地圖 立榜樣 抓重 點 造文化 建制度 整環(huán)境 組建架構(gòu)部 架構(gòu)部內(nèi)招幾名老程序員 外招幾個架構(gòu)師 內(nèi)部走出去 提高眼界 外部牛人請進來 落地了解歷史和業(yè)務(wù) 具體建議是 SOA 服務(wù)化 基礎(chǔ)設(shè)施平臺化 公共 業(yè)務(wù)服務(wù)化 加強項目概要設(shè)計 當(dāng)研發(fā)團隊達(dá)到 200 多人 有了幾百個應(yīng)用 且在故障不斷的情況下 不能與以前一樣沒有設(shè)計就開始編碼 而是做加強項目概要設(shè)計及評審 后面的補與前面的防 兩手都 要抓 兩手都要硬 具體計劃是 Roadmap 分步實施 改造一期 改造二期 改造三期 近細(xì)遠(yuǎn)粗 實事求是 逐步細(xì)化逐步完善 不斷立技術(shù)改造項目 不斷將技改與業(yè)務(wù)研發(fā)項目相結(jié)合 技改即是工 單 工單即是技改 避免對業(yè)務(wù)過多地影響 并不斷有業(yè)務(wù)價值輸出 這是架構(gòu)改造得以持續(xù)實施的關(guān) 鍵 以上簡單地介紹了總體架構(gòu)的編寫方法 我們的編寫思路是先了解業(yè)務(wù) 建立企業(yè)商務(wù)模型 主要包括 靜態(tài)的商務(wù)主體 組織架構(gòu)和動態(tài)的業(yè)務(wù)流程 再了解架構(gòu)的現(xiàn)狀 建立現(xiàn)有信息系統(tǒng)模型 主要