企業總體架構是什麼,有什麼用,具體怎麼做呢?以我曾任職的公司為案例,一起來探討這個問題。這家公司當時有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畫的施工圖紙一樣。領域模型屬於概要設計階段,對於單個應用架構設計,首先需要瞭解業務和功能需求、用例圖、用例活動圖,然後才是領域模型。業務流程圖是對業務操作的抽象,領域圖是對業務邏輯代碼的抽象。
四、架構規劃
當我們瞭解了業務、瞭解了架構的現狀,發現現有架構的問題,接下來就可以做中遠期架構規劃,以及架構的調整和具體實施。架構規劃內容包括:頂層架構規劃、網站功能規劃、應用規劃、SOA規劃、分層架構規劃、資料庫規劃和物理規劃等。4.1、頂層架構規劃


4.2、網站功能規劃
網站功能規劃就是功能的重新劃分,對照著架構現狀,未來的功能應該如何調整?如案例中的國內網站功能規劃,分別畫出了全局功能圖、採購商功能圖、平臺商功能圖和供應商功能圖。其實在做網站功能規劃的時候,更多需要考慮現狀,而不是未來調整的部分,如果沒有很大問題,則不做調整,尊重歷史。因為有些東西(如名稱)用戶已經使用很久了,調整往往比較難,合理大於準確。4.3、應用規劃

4.4、SOA規劃

4.5、分層架構
分層架構看似很簡單,但保證整個研發中心都使用統一的分層架構就不容易了。那麼如何保證整個研發中心都使用統一的分層架構呢,以達到提高編寫代碼效率、保證工程統一性的目的?先簡單介紹下當前兩種比較流行的分層架構體系,一種是領域架構:倉儲層Repository Layer、領域層Domain Layer、應用服務層Application Layer、表現層Presentation Layer和基礎公共層Infrastructure Layer,請見第一張圖;另一種是相對傳統地分為三層:數據層Data Layer、應用邏輯層Business Layer和表現層Presentation Layer,請見第二張圖。

4.6、資料庫規劃

4.7、物理規劃
物理架構的規劃內容包括集群規劃和功能變數名稱規劃。首先是集群規劃。20 倍規劃、5 倍設計和 1.5 倍實施:規劃和設計要大一些,但實施時小一些,這樣不僅便於將來的擴展,也節省了當前的費用;兩個邏輯網路:一個內網和一個外網,兩個負載均衡,兩個防火牆,安全隔離內外網;四條產品線:國際、國內、新業務以及公共業務,單點登錄和企業支付網關等公共業務也屬於一條產品線;六個集群:Web 集群、SOA 集群、中間件集群、資料庫集群、Job 集群和 ITD 集群。以上橫向集群與縱向產品線形成了一個矩陣結構,也基本確定了網路基礎架構。對於功能變數名稱規劃。對內的功能變數名稱該改的改,該停用的停用,該合併的合併。對外的功能變數名稱要儘量少改,要改的話也要有歷史繼承性(如跳轉),要儘量減小對用戶的影響。
4.8、其它
除以上架構規劃外,還有一些其它重要項,如源代碼管理規劃、文檔管理規劃、技術選型和團隊分工。為什麼還要做這些呢?因為統一了源代碼怎麼放、每個部門的文檔怎麼放、將來要用什麼工具版本,才利於團隊的協作,基於統一的環境才能有更高層次地提升。對於團隊分工,需要逐步對齊組織架構與系統的架構規劃。對於技術選型,需要註意中間件的引進,要有節奏性,力量要相對集中,要小規模試點,找非核心項目,試用成功後再進行大規模推廣。五、架構實施
做完架構規劃後,就是架構實施落地了。我們的架構實施整體思路是:樹目標、給地圖、立榜樣、抓重點、造文化、建制度、整環境、組建架構部。架構部內招幾名老程式員,外招幾個架構師。內部走出去,提高眼界。外部牛人請進來,落地瞭解歷史和業務。技術建議是:SOA服務化、基礎設施平臺化、公共業務服務化、加強項目概要設計。當研發團隊達到200多人、有了幾百個應用,且在故障不斷的情況下,不能與以前一樣沒有設計就開始編碼,而是做加強項目概要設計及評審。後面的補與前面的防,兩手都要抓,兩手都要硬。具體計劃是:Roadmap分步實施,改造一期、改造二期、改造三期,近細遠粗、實事求是、逐步細化、逐步完善。不斷立技術改造項目,不斷將技改與業務研發項目相結合,技改即是工單、工單即是技改。避免對業務過多地影響,並不斷有業務價值輸出,這是架構改造得以持續實施的關鍵!
- Big Picture,全局藍圖,起到方向性和指導性。
- 將隱性知識顯性化,方便傳達、廣而告之。
- 對於新員工的價值,快速入門。
- 對於老員工的價值,瞭解全局,過程梳理,然後專註於自己的部分。