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

1、.wd.wd.wd.研發(fā)團隊的總體架構(gòu)設(shè)計方案InfoQ微信號 infoqchina功能介紹 有內(nèi)容的技術(shù)社區(qū)媒體寫在前面 企業(yè)總體架構(gòu)是什么，有什么用，具體怎么做呢以我曾任職的公司為案例，一起來探討這個問題。這家公司當時有 200 位研發(fā)人員和 200 多臺服務(wù)器，我剛進這家公司時，他們的系統(tǒng)就已經(jīng)玩不下去了，總是出現(xiàn)各種問題，例如日常發(fā)布系統(tǒng)時或訪問量稍微過大時，系統(tǒng)就會出現(xiàn)很多故障，而且找不到故障發(fā)生的 基本原因。我進這家公司后的主要任務(wù)就是對這個系統(tǒng)進展升級改造，花了一個半月的時間寫了那份企業(yè)總體架構(gòu)文檔，文檔共有 124 頁，直接指導(dǎo)了之后的技術(shù)改造，以以下圖是那份文檔的目錄。一、企

2、業(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)圖中標出人數(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)?？梢园岩患夜鞠胂蟪梢慌_機器，輸

3、進去的是錢，轉(zhuǎn)一轉(zhuǎn)后，又能夠生出更多的錢出來。最后是業(yè)務(wù)流程和更多業(yè)務(wù)資料下載，業(yè)務(wù)流程包括預(yù)訂流程、訂單處理流程、產(chǎn)品供應(yīng)流程、財務(wù)結(jié)算流程、賬戶管理流程。企業(yè)商務(wù)模型的建設(shè)，指導(dǎo)著整個應(yīng)用系統(tǒng)模型的建設(shè)，畢竟系統(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) 功能架構(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)狀

4、和接口架構(gòu)。其中，接口是應(yīng)用層面的關(guān)鍵，它是一個程序與另外一個程序交互的局部。應(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ǎo)致數(shù)據(jù)設(shè)

5、計，最終畫出 E-R 圖，數(shù)據(jù)設(shè)計完成后，數(shù)據(jù)庫設(shè)計就自然而然出來了。超越庫、超越表去看這張 E-R 圖，可以看出它包括產(chǎn)品、訂單、結(jié)算、用戶、根基設(shè)施這五類數(shù)據(jù)。低層的 E-R 圖可以變，但是高層的 E-R 圖一般不會變化，因為它是根據(jù)你的業(yè)務(wù)模型而定，業(yè)務(wù)模型穩(wěn)定，高層 E-R 圖也是穩(wěn)定的。數(shù)據(jù)庫只要早期設(shè)計得好，是可以做到易伸縮、易拆分的。以以下圖從內(nèi)往外看，一個框既可以是一個庫，也可以是一個模塊，還可以是一個表。在業(yè)務(wù)開展的早期它可以是一個庫，里面有 5 個模塊，中期可以分為 5 個庫，后期以更低級別可以分為更多的庫，這與業(yè)務(wù)階段及系統(tǒng)復(fù)雜度相關(guān)。在數(shù)據(jù)的設(shè)計完成后，數(shù)據(jù)庫的設(shè)計也就

6、很容易規(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)用。物理架構(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)問題才能

7、解決問題，特別是在全局體系架構(gòu)方面，這也是表和圖的價值所在。當時這家公司共有 5 個地區(qū)、8 個機房，雖然只有 200 多臺服務(wù)器，但分布很散，導(dǎo)致物理構(gòu)造復(fù)雜，通訊也很復(fù)雜。技改前故障不斷，其主要的一個原因就是物理架構(gòu)不合理，運維要占 60%、70% 的責(zé)任，當時卻把責(zé)任歸咎為應(yīng)用架構(gòu)，這是個錯誤的方向。物理架構(gòu)的不合理，應(yīng)用架構(gòu)是很難合理的，因為物理架構(gòu)是我們的根基設(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)解決

8、方案，然后在圖表上建設(shè)完整的模型，如同用 AutoCAD 畫的施工圖紙一樣。領(lǐng)域模型屬于概要設(shè)計階段，對于單個應(yīng)用架構(gòu)設(shè)計，首先需要了解業(yè)務(wù)和功能需求、用例圖、用例活動圖，然后才是領(lǐng)域模型。業(yè)務(wù)流程圖是對業(yè)務(wù)操作的抽象，領(lǐng)域圖是對業(yè)務(wù)邏輯代碼的抽象。建設(shè)領(lǐng)域詞匯是建設(shè)領(lǐng)域模型的第一步，它能統(tǒng)一詞匯明確概念，以減少一詞多義、一義多詞的情況。概念一旦確定，再擴展屬性和行為，然后把它當作一個單元與其它事物構(gòu)建在一起，就會很容易形成模型，領(lǐng)域模型與企業(yè)商務(wù)模型中的業(yè)務(wù)流程圖有參考對應(yīng)關(guān)系。領(lǐng)域模型在實現(xiàn)時可大可小，在業(yè)務(wù)的早期，在系統(tǒng)比較小的情況下，它有可能是一個類。當系統(tǒng)做大了以后，它可能是個 DL

9、L 庫。再做更大一點的時候，它可能是一個服務(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ī)劃 當我們了解了業(yè)務(wù)、了解了架構(gòu)的現(xiàn)狀，發(fā)現(xiàn)現(xiàn)有架構(gòu)的問題，接下來就可以做中遠期架構(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ī)劃 上圖是頂層架構(gòu)的俯視圖和側(cè)視圖。第一張圖是俯視圖，坐在飛機上看，整個頂層架構(gòu)最外層的是功能，中間的是業(yè)務(wù)操作，內(nèi)層的是數(shù)據(jù)。功能對應(yīng)業(yè)務(wù)系

10、統(tǒng)的用戶界面，操作對應(yīng)業(yè)務(wù)系統(tǒng)里的服務(wù)，數(shù)據(jù)對應(yīng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲如數(shù)據(jù)庫。第二張圖是剖面圖，切一刀來看，上層是應(yīng)用，中層是服務(wù)和框架，下層是根基設(shè)施數(shù)據(jù)中心。從圖中的服務(wù)層可以看出，服務(wù)的歸類跟業(yè)務(wù)流程的歸類有很大關(guān)系。網(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)整往往比較難，合理大于準確。應(yīng)用規(guī)劃 系統(tǒng)是什么，系

11、統(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)用，如 100206。應(yīng)用編號是應(yīng)用管理、依賴和追蹤的根基，集中式日志和監(jiān)控框架都有使用到應(yīng)用編號。SOA 規(guī)劃 SOA 規(guī)劃就是接口規(guī)劃，它的歸類與商務(wù)模型中的業(yè)務(wù)流程有參考對應(yīng)關(guān)系。上圖案例

12、有五個服務(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)呢，以到達提高編寫代碼效率、保證工程統(tǒng)一性的目的先簡單介紹下當前兩種比較流行的分層架構(gòu)體系，一種是領(lǐng)域架構(gòu)：倉儲層 Repository Layer、領(lǐng)域?qū)?Domain Layer、應(yīng)用服務(wù)層 Applica

13、tion Layer、表現(xiàn)層 Presentation Layer 和根基公共層 Infrastructure Layer，請見第一張圖；另一種是相對傳統(tǒng)地分為三層：數(shù)據(jù)層 Data Layer、應(yīng)用邏輯層 Business Layer 和表現(xiàn)層 Presentation Layer，請見第二張圖。領(lǐng)域架構(gòu)和三層架構(gòu)之間有什么區(qū)別我們是這樣認為的，在早期我們做三層架構(gòu)的時候，大都以表來做驅(qū)動的，在做領(lǐng)域架構(gòu)的時候，大都以業(yè)務(wù)邏輯來驅(qū)動的，兩者的區(qū)別確實比較明顯，但到了現(xiàn)在，如果都以業(yè)務(wù)邏輯為中心的話，實際上兩者并沒有本質(zhì)區(qū)別。當時，我所在公司采用了第二種分層法，我們希望把分層做得極簡，也就是說

14、哪怕剛畢業(yè)進來的員工，在分層時 基本上也不會亂。而相對第一種分層法，第二種分層法簡單很多。每一個應(yīng)用的代碼量都不應(yīng)該很大，一旦工程變得過大，我們就會把它適當拆分，而不是全部放在一個單塊應(yīng)用里。總之，我認為分層越簡單，整個軟件構(gòu)造就越清晰，代碼就越容易統(tǒng)一。把工程做得極簡，才有利于復(fù)制，有利于業(yè)務(wù)的快速構(gòu)建，有利于規(guī)模化、穩(wěn)定可靠。數(shù)據(jù)庫規(guī)劃 數(shù)據(jù)庫是整個信息系統(tǒng)中生命周期最長、最難修改的局部，所以要加強規(guī)劃。 數(shù)據(jù)庫的設(shè)計至少要提前兩步，具體根據(jù)高層 E-R 圖和數(shù)據(jù)設(shè)計來新建數(shù)據(jù)庫，早建要比晚建好。數(shù)據(jù)庫調(diào)整的代價大、周期長，長時間產(chǎn)生的問題，需要長時間來解決，先在新庫里解決新表，再根據(jù)當前

15、業(yè)務(wù)和應(yīng)用的需求，逐步調(diào)整舊表。物理規(guī)劃 物理架構(gòu)的規(guī)劃內(nèi)容包括集群規(guī)劃和域名規(guī)劃。首先是集群規(guī)劃。20 倍規(guī)劃、5 倍設(shè)計和 1.5 倍實施：規(guī)劃和設(shè)計要大一些，但實施時小一些，這樣不僅便于將來的擴展，也節(jié)省了當前的費用；兩個邏輯網(wǎng)絡(luò)：一個內(nèi)網(wǎng)和一個外網(wǎng)，兩個負載均衡，兩個防火墻，安全隔離內(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)品線形成了一個矩陣構(gòu)造，也 基本確定了網(wǎng)絡(luò)根基架構(gòu)。對于域名規(guī)劃。對內(nèi)的域名該改的改，該停用的

16、停用，該合并的合并。對外的域名要盡量少改，要改的話也要有歷史繼承性如跳轉(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)實施 做完架構(gòu)規(guī)劃后，就是架構(gòu)實施落地了。我們的架構(gòu)實施整體思路是：樹目標、給地圖、立典范

17、、抓重點、造文化、建制度、整環(huán)境、組建架構(gòu)部。架構(gòu)部內(nèi)招幾名老程序員，外招幾個架構(gòu)師。內(nèi)部走出去，提高眼界。外部牛人請進來，落地了解歷史和業(yè)務(wù)。具體建議是：SOA 服務(wù)化、根基設(shè)施平臺化、公共業(yè)務(wù)服務(wù)化、加強工程概要設(shè)計。當研發(fā)團隊到達 200 多人、有了幾百個應(yīng)用，且在故障不斷的情況下，不能與以前一樣沒有設(shè)計就開場編碼，而是做加強工程概要設(shè)計及評審。后面的補與前面的防，兩手都要抓，兩手都要硬。具體方案是：Roadmap 分步實施，改造一期、改造二期、改造三期，近細遠粗、實事求是、逐步細化逐步完善。不斷立技術(shù)改造工程，不斷將技改與業(yè)務(wù)研發(fā)工程相結(jié)合，技改即是工單、工單即是技改。防止對業(yè)務(wù)過多地影響，并不斷有業(yè)務(wù)價值輸出，這是架構(gòu)改造得以持續(xù)實施的關(guān)鍵！以上簡單地介紹了總體架構(gòu)的編寫方法，我們的編寫思路是先了解業(yè)務(wù)，建設(shè)企業(yè)商務(wù)模型，主要包括靜態(tài)的商務(wù)主體、組織架構(gòu)和動態(tài)的業(yè)務(wù)流程。再了解架構(gòu)的現(xiàn)狀，建設(shè)現(xiàn)有信息系統(tǒng)模