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