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è)總體架構(gòu)是什么？有什么用？具體怎么做？以我曾任職的公司為案例，一起來探討這個問題。

這家公司當(dāng)時有 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ù)改造，下圖是那份文檔的目錄，文末有相關(guān)資料下載地址。

企業(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)圖中標(biāo)出人數(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)。

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

最后是業(yè)務(wù)流程和附檔資料，業(yè)務(wù)流程包括預(yù)訂流程、訂單處理流程、產(chǎn)品供應(yīng)流程、財務(wù)結(jié)算流程、賬戶管理流程。企業(yè)商務(wù)模型的建立，指導(dǎo)著整個應(yīng)用系統(tǒng)模型的建立，它是整個應(yīng)用系統(tǒng)建設(shè)的基礎(chǔ)和前提，畢竟應(yīng)用系統(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)狀和接口架構(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āng)做歸類，會直接導(dǎo)致數(shù)據(jù)設(shè)計，最終畫出 E-R 圖，數(shù)據(jù)設(shè)計完成后，數(shù)據(jù)庫設(shè)計就自然而然出來了。

超越庫、超越表去看這張 E-R 圖，可以看出它包括產(chǎn)品、訂單、結(jié)算、用戶和基礎(chǔ)設(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ù)發(fā)展的早期它可以是一個庫，里面有 5 個模塊，中期可以分為 5 個庫，后期以更低級別可以分為更多的庫，這與業(yè)務(wù)階段及系統(tǒng)復(fù)雜度相關(guān)。在數(shù)據(jù)的設(shè)計完成后，數(shù)據(jù)庫的設(shè)計也就很容易規(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)問題才能解決問題，特別是在全局體系架構(gòu)方面，這也是表和圖的價值所在。

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

物理架構(gòu)的不合理，應(yīng)用架構(gòu)是很難合理的，因為物理架構(gòu)是我們的基礎(chǔ)設(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)解決方案，然后在圖表上建立完整的模型，如同用 AutoCAD 畫的施工圖紙一樣。

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

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

領(lǐng)域模型在實現(xiàn)時可大可小，在業(yè)務(wù)的早期，在系統(tǒng)比較小的情況下，它有可能是一個類。當(dāng)系統(tǒng)做大了以后，它可能是個 DLL 庫。再做更大一點的時候，它可能是一個服務(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ī)劃

當(dāng)我們了解了業(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ù)系統(tǒng)的用戶界面，操作對應(yīng)業(yè)務(wù)系統(tǒng)里的服務(wù)，數(shù)據(jù)對應(yīng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲如數(shù)據(jù)庫。

第二張圖是剖面圖，切一刀來看，上層是應(yīng)用，中層是服務(wù)和框架，下層是基礎(chǔ)設(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)整往往比較難，合理大于準(zhǔn)確。

應(yīng)用規(guī)劃

系統(tǒng)是什么？系統(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 和公共業(yè)務(wù)系統(tǒng) CBS，在原有的 200 多個應(yīng)用中并沒有這兩個產(chǎn)品線，而是分布在了不同的業(yè)務(wù)線中，從而導(dǎo)致重復(fù)建設(shè)。

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

SOA 規(guī)劃

SOA 規(guī)劃就是接口規(guī)劃，它的歸類與商務(wù)模型中的業(yè)務(wù)流程有參考對應(yīng)關(guān)系。上圖案例有五個服務(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)就不容易了。那么要如何去做，以達到提高編寫代碼效率、保證工程統(tǒng)一性的目的呢？

先簡單介紹下當(dāng)前兩種比較流行的分層架構(gòu)體系，一種是領(lǐng)域架構(gòu)：倉儲層（Repository Layer）、領(lǐng)域?qū)?#xff08;Domain Layer）、應(yīng)用服務(wù)層（Application Layer）、表現(xiàn)層（Presentation Layer）和基礎(chǔ)公共層（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ū)別。當(dāng)時，我所在公司采用了第二種分層法，我們希望把分層做得極簡，也就是說哪怕剛畢業(yè)進來的員工，在分層時基本上也不會亂。

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

總之，我認為分層越簡單，整個軟件結(jié)構(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ù)當(dāng)前業(yè)務(wù)和應(yīng)用的需求，逐步調(diào)整舊表。

物理規(guī)劃

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

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

兩個邏輯網(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)品線形成了一個矩陣結(jié)構(gòu)，也基本確定了網(wǎng)絡(luò)基礎(chǔ)架構(gòu)。對于域名規(guī)劃。對內(nèi)的域名該改的改，該停用的停用，該合并的合并。對外的域名要盡量少改，要改的話也要有歷史繼承性（如跳轉(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)實施整體思路是：樹目標(biāo)、給地圖、立榜樣、抓重點、造文化、建制度、整環(huán)境、組建架構(gòu)部。

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

當(dāng)研發(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ù)，建立企業(yè)商務(wù)模型，主要包括靜態(tài)的商務(wù)主體、組織架構(gòu)和動態(tài)的商務(wù)運作模型和業(yè)務(wù)流程。

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

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

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

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

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

TOGAF 的內(nèi)容主要包括業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和技術(shù)架構(gòu)，而我們當(dāng)時只是以解決公司系統(tǒng)架構(gòu)問題為導(dǎo)向、以時間為主線，內(nèi)容有企業(yè)商務(wù)模型、架構(gòu)現(xiàn)狀、領(lǐng)域模型、架構(gòu)規(guī)劃和架構(gòu)實施。

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

案例參考：

https://github.com/das2017/TopArchDemo

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

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

作者介紹

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

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8183228.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。