http://www.infoq.com/cn/articles/architecture-practice-09-enterprise-architecture?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

企業(yè)總體架構是什么？有什么用？具體怎么做？以我曾任職的公司為案例，一起來探討這個問題。

這家公司當時有 200 位研發(fā)人員和 200 多臺服務器，我剛進這家公司時，系統(tǒng)已經玩不下去了，總是出現各種問題，例如日常發(fā)布系統(tǒng)時或訪問量稍微過大時，系統(tǒng)就會出現很多故障，而且找不到故障發(fā)生的根本原因。

我進公司后主要的任務就是對這個系統(tǒng)進行升級改造，花了一個半月的時間寫了份企業(yè)總體架構文檔，文檔共有 124 頁，直接指導了之后的技術改造，下圖是那份文檔的目錄，文末有相關資料下載地址。

企業(yè)商務模型

企業(yè)商務模型的內容主要包括主營業(yè)務、商務模式、商務主體、競品分析、組織架構、商務運作模型和業(yè)務流程等。

主營業(yè)務即公司做什么業(yè)務。

商業(yè)模式即公司怎么賺錢。

商務主體即哪幾個人在一起做這門生意。

競品分析即了解競爭對手的情況。

組織架構即公司部門是怎么劃分的，組織架構圖中標出人數，根據系統(tǒng)與業(yè)務之間對應關系，可以了解系統(tǒng)中哪些模塊使用頻率高，以及業(yè)務與其對應模塊的復雜度。

商務運作模型即公司是如何運作的，售前做計劃，找供應商把東西買進來后，經過服務和結算，再賣給我們的經銷商和采購商，使我們獲得利潤，售后進行大數據分析最后又指導著我們的售前，整個過程形成良性循環(huán)。

可以把一家公司想象成一臺機器，輸進去的是錢，轉一轉后，又能夠生出更多的錢出來。

最后是業(yè)務流程和附檔資料，業(yè)務流程包括預訂流程、訂單處理流程、產品供應流程、財務結算流程、賬戶管理流程。企業(yè)商務模型的建立，指導著整個應用系統(tǒng)模型的建立，它是整個應用系統(tǒng)建設的基礎和前提，畢竟應用系統(tǒng)是為業(yè)務服務的。

架構現狀

架構現狀的內容主要包括：功能架構、應用架構、數據設計和物理架構。

功能架構

功能架構主要包括功能、角色和權限三部分。功能是企業(yè)服務，用戶使用的每一個功能，就是企業(yè)的每一個服務。角色是用戶操作的歸類，功能與角色的對應關系即權限。了解系統(tǒng)架構的現狀，從功能架構開始。

應用架構

應用就是處理器，應用架構的內容包括現有架構圖、Web 應用現狀、作業(yè)小應用（Job）現狀和接口架構。其中，接口是應用層面的關鍵，它是一個程序與另外一個程序交互的部分。

應用架構圖表列出了哪些業(yè)務邏輯沒有被重用，換句話說業(yè)務邏輯被多少個應用調用，就需要被重復開發(fā)多少次，一旦改了一個地方，就要同時改多個地方，導致系統(tǒng)開發(fā)效率非常低下。

各業(yè)務邏輯如預訂邏輯，雖然被多個應用調用，但它們與應用是沒有關系的，業(yè)務邏輯可以獨立的存在，也可以寄宿于多個應用。業(yè)務邏輯是一個業(yè)務操作的抽象，而業(yè)務應用與業(yè)務部門共同完成了業(yè)務操作。

數據設計

100 多個數據庫，一萬多張表，能否使用一張 E-R 圖來表示呢？它是可以的。

數據設計依賴于企業(yè)的數據，而不是數據庫的設計，對企業(yè)數據適當做歸類，會直接導致數據設計，最終畫出 E-R 圖，數據設計完成后，數據庫設計就自然而然出來了。

超越庫、超越表去看這張 E-R 圖，可以看出它包括產品、訂單、結算、用戶和基礎設施這五類數據。低層的 E-R 圖可以變，但是高層的 E-R 圖一般不會變化，因為它是根據你的業(yè)務模型而定，業(yè)務模型穩(wěn)定，高層 E-R 圖也是穩(wěn)定的。

數據庫只要早期設計得好，是可以做到易伸縮、易拆分的。下圖從內往外看，一個框既可以是一個庫，也可以是一個模塊，還可以是一個表。

在業(yè)務發(fā)展的早期它可以是一個庫，里面有 5 個模塊，中期可以分為 5 個庫，后期以更低級別可以分為更多的庫，這與業(yè)務階段及系統(tǒng)復雜度相關。在數據的設計完成后，數據庫的設計也就很容易規(guī)劃和調整。

以上是數據庫、數據表之間的靜態(tài)關系，接下來我們介紹數據的流轉狀態(tài)即狀態(tài)圖。通過數據狀態(tài)圖去了解現有數據流轉變遷，如國內訂單狀態(tài)變遷圖，這種圖的價值不僅在于數據庫層，還在于服務化。

圖中的從等待支付到支付成功，中間有個支付行為，通過這個支付行為把數據狀態(tài)變更為支付成功，否則繼續(xù)等待，直到超時關閉訂單。這個支付行為可以做成一個微服務，然后由不同的應用去調用。

物理架構

物理架構的內容主要包括?IDC 機房、機房之間訪問關系、機房內服務器物理部署圖、機房與業(yè)務分布、網站架構、數據庫架構、集群清單和域名清單。

將這些內容以列表和圖形方式整理出來，就會很容易了解和發(fā)現問題，只有發(fā)現問題才能解決問題，特別是在全局體系架構方面，這也是表和圖的價值所在。

當時這家公司共有 5 個地區(qū)、8 個機房，雖然只有 200 多臺服務器，但分布很散，導致物理結構復雜，通訊也很復雜。技改前故障不斷，其主要的一個原因就是物理架構不合理，運維要占 60%、70% 的責任，當時卻把責任歸咎為應用架構，這是個錯誤的方向。

物理架構的不合理，應用架構是很難合理的，因為物理架構是我們的基礎設施，位于最底層，下層為上層服務，運維要為應用服務，應用要為業(yè)務服務，業(yè)務要為客人服務。

領域模型

領域模型關注概念，關注職責、關注邊界、關注交互，只有先確定職責和邊界，交互才會很清晰。領域模型是針對現有問題域提出一個系統(tǒng)解決方案，然后在圖表上建立完整的模型，如同用 AutoCAD 畫的施工圖紙一樣。

領域模型屬于概要設計階段，對于單個應用架構設計，首先需要了解業(yè)務和功能需求、用例圖、用例活動圖，然后才是領域模型。業(yè)務流程圖是對業(yè)務操作的抽象，領域圖是對業(yè)務邏輯代碼的抽象。

建立領域詞匯是建立領域模型的第一步，它能統(tǒng)一詞匯明確概念，以減少一詞多義、一義多詞的情況。概念一旦確定，再擴展屬性和行為，然后把它當作一個單元與其它事物構建在一起，就會很容易形成模型，領域模型與企業(yè)商務模型中的業(yè)務流程圖有參考對應關系。

領域模型在實現時可大可小，在業(yè)務的早期，在系統(tǒng)比較小的情況下，它有可能是一個類。當系統(tǒng)做大了以后，它可能是個 DLL 庫。再做更大一點的時候，它可能是一個服務，給不同的應用去調用。

每一個方法都有成為服務的潛質，特別是在系統(tǒng)中后期。領域模型是業(yè)務邏輯代碼的施工圖紙，它不僅有利于對現在系統(tǒng)業(yè)務邏輯的了解，同時也指導未來的架構改造。

架構規(guī)劃

當我們了解了業(yè)務、了解了架構的現狀，發(fā)現現有架構的問題，接下來就可以做中遠期架構規(guī)劃，以及架構的調整和具體實施。架構規(guī)劃內容包括：頂層架構規(guī)劃、網站功能規(guī)劃、應用規(guī)劃、SOA 規(guī)劃、分層架構規(guī)劃、數據庫規(guī)劃和物理規(guī)劃等。

頂層架構規(guī)劃

上圖是頂層架構的俯視圖和側視圖。第一張圖是俯視圖，坐在飛機上看，整個頂層架構最外層的是功能，中間的是業(yè)務操作，內層的是數據。

功能對應業(yè)務系統(tǒng)的用戶界面，操作對應業(yè)務系統(tǒng)里的服務，數據對應業(yè)務系統(tǒng)的數據存儲如數據庫。

第二張圖是剖面圖，切一刀來看，上層是應用，中層是服務和框架，下層是基礎設施數據中心。從圖中的服務層可以看出，服務的歸類跟業(yè)務流程的歸類有很大關系。

網站功能規(guī)劃

網站功能規(guī)劃就是功能的重新劃分，對照著架構現狀，未來的功能應該如何調整？如案例中的國內網站功能規(guī)劃，分別畫出了全局功能圖、采購商功能圖、平臺商功能圖和供應商功能圖。

其實在做網站功能規(guī)劃的時候，更多需要考慮現狀，而不是未來調整的部分，如果沒有很大問題，則不做調整，尊重歷史。因為有些東西（如名稱）用戶已經使用很久了，調整往往比較難，合理大于準確。

應用規(guī)劃

系統(tǒng)是什么？系統(tǒng) = 元素 + 關系。應用架構是什么？應用架構 = 應用 + 架構。應用就是系統(tǒng)的最小單元，應用分類和應用編號則構成了應用關系即應用的架構。

如上圖中的案例，應用分類新建了框架 FX 和公共業(yè)務系統(tǒng) CBS，在原有的 200 多個應用中并沒有這兩個產品線，而是分布在了不同的業(yè)務線中，從而導致重復建設。

應用編號是給每個應用分配一個六位的數字 ID，就如同我們的身份證一樣，頭兩位表示產品線，中間兩位表示子系統(tǒng)，最后兩位表示應用，如 100206。應用編號是應用管理、依賴和追蹤的基礎，集中式日志和監(jiān)控框架都有使用到應用編號。

SOA 規(guī)劃

SOA 規(guī)劃就是接口規(guī)劃，它的歸類與商務模型中的業(yè)務流程有參考對應關系。上圖案例有五個服務中心：預訂服務、訂單處理服務、產品供應服務、財務結算服務和公共服務。

每個服務只需要實現一套自己的邏輯，我們的前臺、后臺、接口、作業(yè)小應用等都可以調用，服務的邏輯跟我們的業(yè)務邏輯是一致的，修改代碼的時候只需要改一個地方就可以影響到所有調用到這服務的前端應用。

分層架構

分層架構看似很簡單，但保證整個研發(fā)中心都使用統(tǒng)一的分層架構就不容易了。那么要如何去做，以達到提高編寫代碼效率、保證工程統(tǒng)一性的目的呢？

先簡單介紹下當前兩種比較流行的分層架構體系，一種是領域架構：倉儲層（Repository Layer）、領域層（Domain Layer）、應用服務層（Application Layer）、表現層（Presentation Layer）和基礎公共層（Infrastructure Layer），見下圖。

另一種是相對傳統(tǒng)地分為三層：數據層（Data Layer）、應用邏輯層（Business Layer）和表現層（Presentation Layer），見下圖。

領域架構和三層架構之間有什么區(qū)別？我們是這樣認為的，在早期我們做三層架構的時候，大都以表來做驅動的，在做領域架構的時候，大都以業(yè)務邏輯來驅動的，兩者的區(qū)別確實比較明顯。

但到了現在，如果都以業(yè)務邏輯為中心的話，實際上兩者并沒有本質區(qū)別。當時，我所在公司采用了第二種分層法，我們希望把分層做得極簡，也就是說哪怕剛畢業(yè)進來的員工，在分層時基本上也不會亂。

而相對第一種分層法，第二種分層法簡單很多。每一個應用的代碼量都不應該很大，一旦工程變得過大，我們就會把它適當拆分，而不是全部放在一個單塊應用里。

總之，我認為分層越簡單，整個軟件結構就越清晰，代碼就越容易統(tǒng)一。把工程做得極簡，才有利于復制，有利于業(yè)務的快速構建，有利于規(guī)模化、穩(wěn)定可靠。

數據庫規(guī)劃

數據庫是整個信息系統(tǒng)中生命周期最長、最難修改的部分，所以要加強規(guī)劃。數據庫的設計至少要提前兩步，具體根據高層 E-R 圖和數據設計來新建數據庫，早建要比晚建好。

數據庫調整的代價大、周期長，長時間產生的問題，需要長時間來解決，先在新庫里解決新表，再根據當前業(yè)務和應用的需求，逐步調整舊表。

物理規(guī)劃

物理架構的規(guī)劃內容包括集群規(guī)劃和域名規(guī)劃。首先是集群規(guī)劃。

20 倍規(guī)劃、5 倍設計和 1.5 倍實施：規(guī)劃和設計要大一些，但實施時小一些，這樣不僅便于將來的擴展，也節(jié)省了當前的費用。

兩個邏輯網絡：一個內網和一個外網，兩個負載均衡，兩個防火墻，安全隔離內外網。

四條產品線：國際、國內、新業(yè)務以及公共業(yè)務，單點登錄和企業(yè)支付網關等公共業(yè)務也屬于一條產品線。

六個集群：Web 集群、SOA 集群、中間件集群、數據庫集群、Job 集群和 ITD 集群。

以上橫向集群與縱向產品線形成了一個矩陣結構，也基本確定了網絡基礎架構。對于域名規(guī)劃。對內的域名該改的改，該停用的停用，該合并的合并。對外的域名要盡量少改，要改的話也要有歷史繼承性（如跳轉），要盡量減小對用戶的影響。

其它

除以上架構規(guī)劃外，還有一些其它重要項，如源代碼管理規(guī)劃、文檔管理規(guī)劃、技術選型和團隊分工。為什么還要做這些呢？因為統(tǒng)一了源代碼怎么放、每個部門的文檔怎么放、將來要用什么工具版本，才利于團隊的協(xié)作，基于統(tǒng)一的環(huán)境才能有更高層次地提升。

對于團隊分工，需要逐步對齊組織架構與系統(tǒng)的架構規(guī)劃。對于技術選型，需要注意中間件的引進，要有節(jié)奏性，力量要相對集中，要小規(guī)模試點，找非核心項目，試用成功后再進行大規(guī)模推廣。

架構實施

做完架構規(guī)劃后，就是架構實施落地了。我們的架構實施整體思路是：樹目標、給地圖、立榜樣、抓重點、造文化、建制度、整環(huán)境、組建架構部。

架構部內招幾名老程序員，外招幾個架構師。內部走出去，提高眼界。外部牛人請進來，落地了解歷史和業(yè)務。技術建議是：SOA 服務化、基礎設施平臺化、公共業(yè)務服務化、加強項目概要設計。

當研發(fā)團隊達到 200 多人、有了幾百個應用，且在故障不斷的情況下，不能與以前一樣沒有設計就開始編碼，而是做加強項目概要設計及評審。后面的補與前面的防，兩手都要抓，兩手都要硬。

具體計劃是：Roadmap 分步實施，改造一期、改造二期、改造三期，近細遠粗、實事求是、逐步細化、逐步完善。不斷立技術改造項目，不斷將技改與業(yè)務研發(fā)項目相結合，技改即是工單、工單即是技改。避免對業(yè)務過多地影響，并不斷有業(yè)務價值輸出，這是架構改造得以持續(xù)實施的關鍵！

以上簡單地介紹了總體架構的編寫方法，我們的編寫思路是先了解業(yè)務，建立企業(yè)商務模型，主要包括靜態(tài)的商務主體、組織架構和動態(tài)的商務運作模型和業(yè)務流程。

接著了解架構現狀，建立現有信息系統(tǒng)模型，主要包括功能架構、應用架構、數據設計和物理架構。一個是商務，一個是電子，兩者即是整個公司的電子商務系統(tǒng)。

然后在企業(yè)商務模型和現有系統(tǒng)模型之上建立領域模型，領域模型它相對穩(wěn)定，直接指導著接下來的架構規(guī)劃，最后一定要落地即架構實施。

附檔是去掉敏感信息后的真實案例，它的價值如下：

• Big Picture，全局藍圖，起到方向性和指導性。
• 將隱性知識顯性化，方便傳達、廣而告之。
• 對于新員工的價值，快速入門。
• 對于老員工的價值，了解全局，過程梳理，然后專注于自己的部分。

關于企業(yè)總體架構，你可以參考標準 TOGAF(開放組體系結構框架)。其實，我們是在完成那份文檔后才知道 TOGAF，它們之間有很多相似之處和不同之處。

TOGAF 的內容主要包括業(yè)務架構、應用架構、數據架構和技術架構，而我們當時只是以解決公司系統(tǒng)架構問題為導向、以時間為主線，內容有企業(yè)商務模型、架構現狀、領域模型、架構規(guī)劃和架構實施。

方法論很重要，但看到事物本身的特點，深入問題以及找到解決辦法更為重要。歡迎點贊和拍磚！

案例參考：

https://github.com/das2017/TopArchDemo

本系列文章涉及內容清單如下（并不按這順序發(fā)布），其中有感興趣的，歡迎關注：

• 開篇：中小型研發(fā)團隊架構實踐三要點
• 緩存 Redis：Redis快速入門及應用
• 消息隊列 RabbitMQ：如何用好消息隊列RabbitMQ？
• 集中式日志 ELK：中小型研發(fā)團隊架構實踐之集中式日志ELK
• 任務調度 Job：中小型研發(fā)團隊架構實踐之任務調度Job
• 應用監(jiān)控 Metrics：應用監(jiān)控怎么做？
• 微服務框架 MSA：這是你心心念念的.NET棧的微服務架構實踐
• 搜索利器 Solr
• 分布式協(xié)調器 ZooKeeper
• 小工具：Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
• 發(fā)布工具 Jenkins
• 總體架構設計：電商如何做企業(yè)總體架構？
• 單個項目架構設計
• 統(tǒng)一應用分層：如何規(guī)范公司所有應用分層？
• 調試工具 WinDbg
• 單點登錄
• 企業(yè)支付網關
• 結篇

作者介紹

張輝清，10 多年的 IT 老兵，先后擔任攜程架構師、古大集團首席架構、中青易游 CTO 等職務，主導過兩家公司的技術架構升級改造工作。現關注架構與工程效率，技術與業(yè)務的匹配與融合，技術價值與創(chuàng)新

轉載于:https://www.cnblogs.com/davidwang456/articles/8183228.html

總結

以上是生活随笔為你收集整理的中小型研发团队架构实践：电商如何做企业总体架构？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。