中小型研發團隊架構實踐：電商如何作企業整體架構？

企業整體架構是什麼？有什麼用？具體怎麼作？以我曾任職的公司爲案例，一塊兒來探討這個問題。

這家公司當時有 200 位研發人員和 200 多臺服務器，我剛進這家公司時，系統已經玩不下去了，老是出現各類問題，例如平常發佈系統時或訪問量稍微過大時，系統就會出現不少故障，並且找不到故障發生的根本緣由。

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

企業商務模型

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

主營業務即公司作什麼業務。

商業模式即公司怎麼賺錢。

商務主體即哪幾我的在一塊兒作這門生意。

競品分析即瞭解競爭對手的狀況。

組織架構即公司部門是怎麼劃分的，組織架構圖中標出人數，根據系統與業務之間對應關係，能夠了解系統中哪些模塊使用頻率高，以及業務與其對應模塊的複雜度。

商務運做模型即公司是如何運做的，售前作計劃，找供應商把東西買進來後，通過服務和結算，再賣給咱們的經銷商和採購商，使咱們得到利潤，售後進行大數據分析最後又指導着咱們的售前，整個過程造成良性循環。

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

最後是業務流程和附檔資料，業務流程包括預訂流程、訂單處理流程、產品供應流程、財務結算流程、帳戶管理流程。企業商務模型的創建，指導着整個應用系統模型的創建，它是整個應用系統建設的基礎和前提，畢竟應用系統是爲業務服務的。

架構現狀

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

功能架構

功能架構主要包括功能、角色和權限三部分。功能是企業服務，用戶使用的每個功能，就是企業的每個服務。角色是用戶操做的歸類，功能與角色的對應關係即權限。瞭解系統架構的現狀，從功能架構開始。

應用架構

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

應用架構圖表列出了哪些業務邏輯沒有被重用，換句話說業務邏輯被多少個應用調用，就須要被重複開發多少次，一旦改了一個地方，就要同時改多個地方，致使系統開發效率很是低下。

各業務邏輯如預訂邏輯，雖然被多個應用調用，但它們與應用是沒有關係的，業務邏輯能夠獨立的存在，也能夠寄宿於多個應用。業務邏輯是一個業務操做的抽象，而業務應用與業務部門共同完成了業務操做。

數據設計

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

數據設計依賴於企業的數據，而不是數據庫的設計，對企業數據適當作歸類，會直接致使數據設計，最終畫出 E-R 圖，數據設計完成後，數據庫設計就天然而然出來了。

超越庫、超越表去看這張 E-R 圖，能夠看出它包括產品、訂單、結算、用戶和基礎設施這五類數據。低層的 E-R 圖能夠變，可是高層的 E-R 圖通常不會變化，由於它是根據你的業務模型而定，業務模型穩定，高層 E-R 圖也是穩定的。

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

在業務發展的早期它能夠是一個庫，裏面有 5 個模塊，中期能夠分爲 5 個庫，後期以更低級別能夠分爲更多的庫，這與業務階段及系統複雜度相關。在數據的設計完成後，數據庫的設計也就很容易規劃和調整。

以上是數據庫、數據表之間的靜態關係，接下來咱們介紹數據的流轉狀態即狀態圖。經過數據狀態圖去了解現有數據流轉變遷，如國內訂單狀態變遷圖，這種圖的價值不只在於數據庫層，還在於服務化。

圖中的從等待支付到支付成功，中間有個支付行爲，經過這個支付行爲把數據狀態變動爲支付成功，不然繼續等待，直到超時關閉訂單。這個支付行爲能夠作成一個微服務，而後由不一樣的應用去調用。

物理架構

物理架構的內容主要包括 IDC 機房、機房之間訪問關係、機房內服務器物理部署圖、機房與業務分佈、網站架構、數據庫架構、集羣清單和域名清單。

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

當時這家公司共有 5 個地區、8 個機房，雖然只有 200 多臺服務器，但分佈很散，致使物理結構複雜，通信也很複雜。技改前故障不斷，其主要的一個緣由就是物理架構不合理，運維要佔 60%、70% 的責任，當時卻把責任歸咎爲應用架構，這是個錯誤的方向。

物理架構的不合理，應用架構是很難合理的，由於物理架構是咱們的基礎設施，位於最底層，下層爲上層服務，運維要爲應用服務，應用要爲業務服務，業務要爲客人服務。

領域模型

領域模型關注概念，關注職責、關注邊界、關注交互，只有先肯定職責和邊界，交互纔會很清晰。領域模型是針對現有問題域提出一個系統解決方案，而後在圖表上創建完整的模型，如同用 AutoCAD 畫的施工圖紙同樣。

領域模型屬於概要設計階段，對於單個應用架構設計，首先須要瞭解業務和功能需求、用例圖、用例活動圖，而後纔是領域模型。業務流程圖是對業務操做的抽象，領域圖是對業務邏輯代碼的抽象。

創建領域詞彙是創建領域模型的第一步，它能統一詞彙明確概念，以減小一詞多義、一義多詞的狀況。概念一旦肯定，再擴展屬性和行爲，而後把它看成一個單元與其它事物構建在一塊兒，就會很容易造成模型，領域模型與企業商務模型中的業務流程圖有參考對應關係。

領域模型在實現時可大可小，在業務的早期，在系統比較小的狀況下，它有多是一個類。當系統作大了之後，它多是個 DLL 庫。再作更大一點的時候，它多是一個服務，給不一樣的應用去調用。

每個方法都有成爲服務的潛質，特別是在系統中後期。領域模型是業務邏輯代碼的施工圖紙，它不只有利於對如今系統業務邏輯的瞭解，同時也指導將來的架構改造。

架構規劃

當咱們瞭解了業務、瞭解了架構的現狀，發現現有架構的問題，接下來就能夠作中遠期架構規劃，以及架構的調整和具體實施。架構規劃內容包括：頂層架構規劃、網站功能規劃、應用規劃、SOA 規劃、分層架構規劃、數據庫規劃和物理規劃等。

頂層架構規劃

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

功能對應業務系統的用戶界面，操做對應業務系統裏的服務，數據對應業務系統的數據存儲如數據庫。

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

網站功能規劃

網站功能規劃就是功能的從新劃分，對照着架構現狀，將來的功能應該如何調整？如案例中的國內網站功能規劃，分別畫出了全局功能圖、採購商功能圖、平臺商功能圖和供應商功能圖。

其實在作網站功能規劃的時候，更多須要考慮現狀，而不是將來調整的部分，若是沒有很大問題，則不作調整，尊重歷史。由於有些東西（如名稱）用戶已經使用好久了，調整每每比較難，合理大於準確。

應用規劃

系統是什麼？系統 = 元素 + 關係。應用架構是什麼？應用架構 = 應用 + 架構。應用就是系統的最小單元，應用分類和應用編號則構成了應用關係即應用的架構。

如上圖中的案例，應用分類新建了框架 FX 和公共業務系統 CBS，在原有的 200 多個應用中並無這兩個產品線，而是分佈在了不一樣的業務線中，從而致使重複建設。

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

SOA 規劃

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

每一個服務只須要實現一套本身的邏輯，咱們的前臺、後臺、接口、做業小應用等均可以調用，服務的邏輯跟咱們的業務邏輯是一致的，修改代碼的時候只須要改一個地方就能夠影響到全部調用到這服務的前端應用。

分層架構

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

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

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

領域架構和三層架構之間有什麼區別？咱們是這樣認爲的，在早期咱們作三層架構的時候，大都以表來作驅動的，在作領域架構的時候，大都以業務邏輯來驅動的，二者的區別確實比較明顯。

但到了如今，若是都以業務邏輯爲中心的話，實際上二者並無本質區別。當時，我所在公司採用了第二種分層法，咱們但願把分層作得極簡，也就是說哪怕剛畢業進來的員工，在分層時基本上也不會亂。

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

總之，我認爲分層越簡單，整個軟件結構就越清晰，代碼就越容易統一。把工程作得極簡，纔有利於複製，有利於業務的快速構建，有利於規模化、穩定可靠。

數據庫規劃

數據庫是整個信息系統中生命週期最長、最難修改的部分，因此要增強規劃。數據庫的設計至少要提早兩步，具體根據高層 E-R 圖和數據設計來新建數據庫，早建要比晚建好。

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

物理規劃

物理架構的規劃內容包括集羣規劃和域名規劃。首先是集羣規劃。

20 倍規劃、5 倍設計和 1.5 倍實施：規劃和設計要大一些，但實施時小一些，這樣不只便於未來的擴展，也節省了當前的費用。

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

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

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

以上橫向集羣與縱向產品線造成了一個矩陣結構，也基本肯定了網絡基礎架構。對於域名規劃。對內的域名該改的改，該停用的停用，該合併的合併。對外的域名要儘可能少改，要改的話也要有歷史繼承性（如跳轉），要儘可能減少對用戶的影響。

其它

除以上架構規劃外，還有一些其它重要項，如源代碼管理規劃、文檔管理規劃、技術選型和團隊分工。爲何還要作這些呢？由於統一了源代碼怎麼放、每一個部門的文檔怎麼放、未來要用什麼工具版本，才利於團隊的協做，基於統一的環境纔能有更高層次地提高。

對於團隊分工，須要逐步對齊組織架構與系統的架構規劃。對於技術選型，須要注意中間件的引進，要有節奏性，力量要相對集中，要小規模試點，找非核心項目，試用成功後再進行大規模推廣。

架構實施

作完架構規劃後，就是架構實施落地了。咱們的架構實施總體思路是：樹目標、給地圖、立榜樣、抓重點、造文化、建制度、整環境、組建架構部。

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

當研發團隊達到 200 多人、有了幾百個應用，且在故障不斷的狀況下，不能與之前同樣沒有設計就開始編碼，而是作增強項目概要設計及評審。後面的補與前面的防，兩手都要抓，兩手都要硬。

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

以上簡單地介紹了整體架構的編寫方法，咱們的編寫思路是先了解業務，創建企業商務模型，主要包括靜態的商務主體、組織架構和動態的商務運做模型和業務流程。

接着瞭解架構現狀，創建現有信息系統模型，主要包括功能架構、應用架構、數據設計和物理架構。一個是商務，一個是電子，二者便是整個公司的電子商務系統。

而後在企業商務模型和現有系統模型之上創建領域模型，領域模型它相對穩定，直接指導着接下來的架構規劃，最後必定要落地即架構實施。

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

• Big Picture，全局藍圖，起到方向性和指導性。
• 將隱性知識顯性化，方便傳達、廣而告之。
• 對於新員工的價值，快速入門。
• 對於老員工的價值，瞭解全局，過程梳理，而後專一於本身的部分。

關於企業整體架構，你能夠參考標準 TOGAF(開放組體系結構框架)。其實，咱們是在完成那份文檔後才知道 TOGAF，它們之間有不少類似之處和不一樣之處。

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

方法論很重要，但看到事物自己的特色，深刻問題以及找到解決辦法更爲重要。歡迎點贊和拍磚！

案例參考：

https://github.com/das2017/TopArchDemo

轉自：http://www.infoq.com/cn/articles/architecture-practice-09-enterprise-architecture