研發(fā)團隊的總體架構設計方案

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