總體介紹
2017年雙11，交易峰值達到了32.5萬筆/秒，這給整個交易系統帶來了非常大的挑戰。一方面，系統需要支撐全集團幾十個事業部的所有交易類需求：要考慮如何能更快響應需求、加快發布周期；如何能為新小業務提供快速支撐、降低准入門檻；是否足夠開放使得業務方能做到自助式擴展；新需求是否已經在其他事業部有可復用資產等問題。
互聯網的特點決定了業務系統是按領域服務建設的分布式架構。而電商業務的特點是業務生命周期長，從招商、選品、供應鏈、倉儲、營銷/導購、下單、履約、物流、售后等，其業務鏈路長、業務邏輯上游對下游又有影響。在這業務主線的鏈路上，又建設了眾多系統進行支撐，比如商品平台、購物車系統、下單系統、履約系統、優惠系統、物流系統、供應鏈系統等，圍繞這些核心系統，還有數不清的輔助系統/服務，比如服務平台、天貓SMC、淘寶CPC等等。
在每一次的業務需求分析過程中，又是需要能從業務生命周期的全鏈路視角進行需求分析、技術方案評估、編碼、聯調以及發布。這整個過程，也是一次復雜的跨團隊協助過程，痛點主要體現在：
1)缺少全鏈路視角的需求管理機制，協同效率低
2)平台准入門檻高，新小業務無法快速試錯
3)業務與平台沒有很好分離，無法支撐業務自助式(Self-Service)發展
4)缺少可復用業務資產。
痛點一： 缺少業務全鏈路視角的需求管理機制，協同效率低
對業務需求的跟蹤與管理缺少全業務鏈路視角，主要體現在：
需求的描述往往就是一句話。詳細的需求描述基本都是靠后期的一些文檔、郵件以及組織需求澄清會的形式進行講解。在講解時，會盡可能拉上能想得到的可能會相關的平台開發同學，場面蔚為壯觀。
需求傳遞低效，需要反復溝通。業務需求在建模與分解過程中，缺少有效傳遞載體和形式，不能准確無縫傳遞到開發，導致反復溝通澄清與需求返工以及重復工作量。
平台能力缺少透出，技術方案評估花費時間長。技術同學在評估需求實現對平台的改動點時，由於平台能力缺少透出，業務與平台代碼沒有分離，導致技術方案評估時，很難一下評估出針對新續期，現有平台有什么能力可以服用？改動對現有哪些業務會有影響？對相關的周邊哪些系統有影響？工作量有多少？ 這些基本都需要事后去反復翻代碼分析評估。
類似需求重復建設。 需求發布上線后，隨着時間的推移，人員的更換。就沒有人知道這個需求當時是如何實現的？遇到類似需求的方案評估，又只能翻代碼，或者重復實現一次。
痛點二：平台准入門檻高，新小業務無法快速試錯
新小業務都有一個成長規律，在早期業務模式驗證階段，需要的玩法比較簡單，希望能頻繁的發布快速試錯。但共享的交易平台、商品平台、營銷平台等雖然能支持各種業務模式與營銷玩法。但對於新小業務而言，這些在早期並不適用，他們希望平台能靈活裁剪，比如：
1)下單流程是否能裁剪成極簡流程，而不是必須走完整流程
2)與其他業務代碼在運行期分離，不希望對其他業務或者被其他業務所影響
3)業務發布節奏可以自行控制，不希望等待每周一次的全網回歸
痛點三：業務與平台沒有很好分離，無法支撐業務自助式(Self-Service)發展
阿里電商業務五花八門，各部門的定位也不一樣，有的定位於是面向“垂直”行業的，比如天貓汽車業務、盒馬生鮮業務、航旅業務等；而有的又是定位於面向對所有行業支撐的平台業務，如聚划算、導購寶等。 所以，業務本身會分成“垂直”和“水平”兩個維度。在一次業務交互過程中，其業務復雜度就在於業務“垂直”維度與“水平”維度產生的疊加，並由疊加而產生的業務規則上的沖突。
針對業務疊加的處理，各系統基本上還是基於SPI擴展機制，這些SPI缺少按照業務維度進行組織與隔離。在業務種類少，不同業務在邏輯疊加度小的情況下還是可以在很大程度上解決業務可定制化、多樣化的問題。但隨着各類業務越來越多時，就會導致各類業務在同一個擴展點上的疊加效應越來越突出。其中最薄弱的點就是 SPI接口中是否需要執行的過濾方法(filter)的編寫。一旦過濾方法寫得不好，就可能會造成不該執行的邏輯被執行了，或者把后續本該執行的邏輯給跳過了。
在共享的各個平台中，提供給業務方可擴展的SPI多達幾百個。一個業務的最終邏輯是否正確，就需要該業務確保這幾百個SPI決策樹中每個節點注冊的位置正確，過濾方法中的過濾條件正確，同時執行邏輯也必須確。不僅如此，本業務注冊的SPI都正確了，還需要其他的業務注冊的SPI也都是正確的，這最終導致了業務與業務之間高度耦合。這種耦合，又進一步導致了各業務方之間、業務方與平台之間的大量聯調、集成與回歸等配合工作，無法做到自助式的業務設計、開發與交付。
痛點四：缺少可復用業務資產
一個企業的IT體系建設是否成熟，業界是有一些指導框架來進行評估的，比如TOGAF框架。在該信息系統建設框架中，有一個很重要的系統成熟度評估項目 —— Enterprise Continumm(企業統一體)。
這里面的關鍵是企業需要建立：
架構統一體(Architecture Continuum)： 該統一體能從特定架構中提取出可復用的組件到倉庫中(Reposity)，為后續的類似業務的重用(Gerneralization for future re-use)。在具體應用中，可以從組件倉庫中選擇可復用的組件並進行與實際應用場景適配(Adaptation for use)。
解決方案統一體(Solutions Continuum)：與架構統一體類似，在面對不同的市場，需要能從可復用的解決方案庫中選擇並快速復制。對於新興市場的交付，也能提取成可復用的解決方案到資產庫中。
經過多年的發展，我們在淘寶、天貓國內市場中，我們 有各種各樣的業務支撐工具與玩法，比如，電子憑證、預售、購物券、紅包等等，在面對國際化市場交付時，是否能做到業務模式的快速復用？
解決這些問題的思路
整個電商體系涉及的應用高達7000+：要考慮需求的評估是否具有全鏈路視角；業務需求的技術評估是否分析全面、技術方案的影響范圍是否評估到位；業務的全鏈路穩定性保障、調用鏈路監控、強弱依賴等問題。此外面對每天幾百個業務需求，500+個獨立的發布變更：要考慮各業務方的需求發布是否會相互產生影響；需求代碼是否對平台有侵入、導致平台腐化；高頻率的需求發布下如何管控質量；能否按業務維度進行業務監控、故障分析等等。
面對這些挑戰，TMF2.0框架需要解決的六大關鍵問題：
業務全鏈路可視：業務分析人員和技術人員能基於同一套業務語言以全鏈路可視化方式進行需求討論、影響分析以及技術方案評估，在業務視圖上看到的規則就是實際在運行系統上運行的規則。在對大規模的業務交付支撐場景下，業務可視化對於效率提升是非常必要的。
需求結構化：基於透出的業務能力、已有的業務規則完成需求結構化分解降低溝通成本。
業務配置化：這是可視化的前提，要在需求明確的情況下在線配置業務、快速發布上線。
業務測試一體化：根據修改的代碼進行自動化用例篩選、自動化測試。
業務監控：以精細化的業務維度進行監控，而不僅僅局限於交易大盤。
故障排查：當業務故障時快速拿到故障快照、還原故障現場以及迅速定位問題原因。
TMF2.0 關鍵設計思想
針對上面提到的問題，TMF2在架構設計上主要的思想是：
業務包與平台分離的插件化架構：平台提供插件包注冊機制，實現業務方插件包在運行期的注冊。業務代碼只允許存在於插件包中，與平台代碼嚴格分離。業務包的代碼配置庫也與平台的代碼庫分離，通過二方包的方式，提供給容器加載。
全鏈路統一的業務身份： 平台需要能有按“業務身份”進行業務與業務之間邏輯隔離的能力，而不是傳統SPI架構不區分業務身份，簡單過濾的方式。如何設計這個業務身份，也成為業務間隔離架構的關鍵。
管理域與運行域分離：業務邏輯不能依靠運行期動態計算，要能在靜態期進行定義並可視化呈現。業務定義中出現的規則疊加沖突，也在靜態器進行沖突決策。在運行期，嚴格按照靜態器定義的業務規則、沖突決策策略執行。
業務包與平台分離的插件化架構
如上所示的業務定制包與平台分離架構可以分為三個層次。最底層是業務規范層，包括一些交易模型、交易領域的划分、業務領域的划分、以及交易啟動環境下的配置項。基於這個理論模型，就可以進行一些定義及規范工作，比如接口定義、流程規范、模型規范等，而且其中的很多內容都可以在不同的領域進行復用。
業務規范層之上是解決方案層。大家都知道阿里巴巴目前正在走國際化的戰略，所以面對不同的市場會構建不同的解決方案，不同的解決方案中也就有自己不同的業務玩法、業務邏輯。所以要將不同的市場解決方案和他們自身的流程、規則結合起來。但是這一過程中會發現，不同的市場解決方案會有很多可以復用的地方，比如營銷模式。所以形成的可復用基礎實現就可以在不同的解決方案中得到復用，所那么在面對不同的市場時就不用考慮可復用基礎實現的內容，只需要關注市場相關的業務就可以了。
再往上一層是業務定制層。即使是在一個市場內，也會有各種細分的定制玩法，這些不同的細分點就會有各自不同的業務邏輯，這就是制定業務定制層的原因。團隊會根據底層的需求點來進行一些業務定制包的組裝，就可以實現不同的業務邏輯和玩法了。
在這樣一個復雜的分離架構中，最重要的是要將不同層次間的職責划分清晰，整個代碼都嚴格地、有意識地進行分離。所以在最后的部署過程中，首先要完成底層業務的復用，然后形成不同市場的解決方案，再在解決方案下對不同的業務實現差異化的點。
全鏈路統一的業務身份
上面所講的是業務和平台的分離，在業務和平台分離之后就要進行業務和業務之間的隔離，即統一的業務身份，類似於身份證號碼，在整個交易鏈路上必須是唯一的。業務身份需要通過人、貨、場三個維度進行抽象，比如市場類型、垂直市場、渠道來源等等，確定了這個唯一的業務身份后就可以將業務流程和業務規則進行關聯。
基於業務識別，團隊也提供了一個基於UIL的業務身份識別方案，總體設計基於標准模型來抽象，自定義語法，統一管理模型。事實上，通過樣品模型、買家模型、賣家模型、類目模型這四個維度，99%的商品都可以有效地進行標識。業務身份確定后，就可以按照業務身份維度，對業務配置、部署進行統一管理，在這其中要注意配置隔離性、熱部署、配置回滾、配置確定性等核心要素。
業務管理域與運行域分離
業務身份確定后就要進行業務定義，這其中就涉及管理域和運行域分離的問題。管理域就是指對業務生命周期、業務身份、業務對象進行定義，包括業務流程、業務管理等。這些操作完成之后就會將配置文件下發到，運行域上的各種平台就會自動解析配置域所下發的配置文件，然后將配置文件解析成業務命令來執行。
在上面所講的業務域中，一個核心的問題就是如何定義業務：核心三要素是業務身份、業務疊加關系、沖突決策，即基於業務協議標准定義業務，執行單元按協議執行業務邏輯。
在業務疊加關系中，業務的復雜度就在於業務規則在不同維度下產生的沖突。業務的復雜度可以分為兩個維度，一個是橫向維度，一個是垂直維度。
垂直維度，也可稱之為“行業”。往往一個特定的“業務對象”(如商品)，在靜態期就能確認其具體歸屬於哪個行業。行業與行業之間的業務規則是不會有疊加的。比如，付款超時時間，各可以設置為1天超時。但“天貓汽車”把超時時間改了，一定不會聯動改其他業務的超時設置。橫向維度，也稱為產品維度，特點有：產品是可以被多個垂直業務所使用的、一個垂直業務是可以使用多個產品的、產品是否生效是需要結合業務會話的。比如，“電子憑證”是否生效，要看用戶是否選擇了“電子憑證”的交付方式。
通過業務復雜度的分析，可以得出一個結論是：一次業務會話完整的規則=1個垂直業務規則集合+ N個水平業務規則集。所以在做業務定義和管理的時候，具體就是在管某一個垂直業務是和哪些橫向業務在疊加。在疊加之后產生的業務沖突又是怎么解決的？要基於這一點進行業務管理。這是比較關鍵的一點。
TMF2.0 關鍵模型介紹
下面詳細闡述一下TMF 2.0的關鍵模型，主要包括業務配置主線和業務運行主線。
在業務配置主線中，由項目的業務PD來看一下當前業務涉及到哪些業務域，以及這些業務域下面有哪些功能和產品可以去使用，哪些業務點是可以去擴展的。這其中就需要能力域模型的支撐，通過這個模型所透出的結構化數據，來研究平台中每個域具備的能力、每個能力具有的可變點，從而有針對性地進行設置。在配置模型里，通過關鍵的視圖模板，進行模板透出，然后保存、下發配置數據到業務運行主線。業務配置主線和業務運行主線是相交互的。
基於TMF 2.0關鍵模型，整個交易平台實現了業務定義可視、可管、可配。業務定義可視化包括系統能力可視化、業務流程可視化、業務規則可視化、產品疊加可視化等；業務可配置，所見即所得的業務規則可配置能力，凡是基於TMF2標准構建的系統均立刻可獲取業務可配置能力，不需做額外的開發；配置版本化，針對業務配置有完善的版本化管理機制，配置推送可實現按版本快速生效或者回退；業務多租戶管理，不同的業務系統之間可以通過租戶完全隔離的。不同的租戶有自己的數據空間，以及配置推送策略。
面向業務維度的運維 & 穩定性保障
當業務與平台分離並且具有業務身份的識別后，我們就可以從業務維度進行可靠性保障，主要有：1)按業務維度進行故障監控 2)按業務維度分集群部署 3)按業務維度做穩定性保障 等。
1) 按業務維度進行故障監控
在過去沒有做到業務身份識別時，每天的交易大盤監控還比較粗放，只能去從整體去監控交易量趨勢。有些業務，特別是一些新小業務，其早期交易量非常小。即使因為故障交易跌零了，從交易大盤上也無法即使監控到，只有等到客戶投訴了才發現有故障發生。
基於TMF2構建的業務系統，因為有“業務身份”的標示，我們就可以將業務身份標示貫穿整個接口調用鏈路以及寫入日志中。並在各類監控大盤中，可以針對業務維度進行分組展現。
2) 按業務維度分集群部署
過去淘寶、天貓所有的交易，都是通過同一套BUY、TP進行下單並履約的。當某個業務有新需求或者故障解決等原因，要進行升級部署時，就不可避免的將所有機器都分批進行升級部署。每一次升級發布，都是一次變更行為，只要有變更就可能會產生新的故障。
基於TMF2構建的業務系統，因為有“業務身份”的識別。我們就可以根據業務身份做前置路由。給不同的業務身份分配不同的集群，並按集群去分別部署業務。從物理的隔離，在滿足一些業務快速迭代發布的訴求下，還能保障業務的穩定性。
3) 按業務維度做穩定性保障
過去在沒有業務身份的識別下，在做性能優化、大促保障時，是沒法按業務維度用不同的QoS策略進行差異化的大促保障。比如，無法按照業務維度進行流量分配進行限流、無法按照業務維度建立性能基線並進行性能劣化監控等。業務平台目前正在做的天秤項目，與過去單純監控物理指標不一樣的地方，就是在於能按照業務進行場景化監控。例如：
可以按業務維度建立各業務在各個調用場景下的性能基線，如RT、QPS等，一旦某次發布和預設基線有重大差異，就能快速找到性能劣化的業務並進行改進
可以按業務維度建立外部服務調用的強弱依賴關系，結合強弱依賴關系可制定全局以及業務維度的各種預案開關。
可以按全局或者業務維度，構建全局調用鏈路監控大盤。
交易平台改造效果
業務需求平均開發周期縮短至12天: 比如汽車4S服務中，在老系統上做了一個月(未完成)，新系統7天完成；五道口業務中，在老系統中評估工作量兩個月，新系統12個工作日完成；餓了么業務中，老系統評估要兩周，基於新系統2天完成。
平台與業務解耦: 目前已完成的業務，其業務定制均只存在於業務包；在平台未改動情況下，業務方的發布更加靈活(有多次單業務發布，不需要其他業務方進行回歸的案例)。
業務資產庫: 積累形成了50+業務資產庫，新業務可快速進行快速復制、調整並發布。
原文：如何實現32.5萬筆/秒的交易峰值？阿里交易系統TMF2.0技術揭秘
復雜業務系統的架構設計思路
做技術方案，核心是下面幾個問題：
做什么？- 產品需求
業務上怎么做？- 業務文檔
技術上怎么做？- 技術方案
代碼怎么實現？- 落地實現
明確了這幾個問題，可以處理大部分日常需求開發，如果是比較復雜的業務系統，就需要拆解的更精細。
比如電商的商品管理、訂單交易等系統的開發和重構，業務相對復雜，開發人天在幾個月以上，直接開發可能會老虎啃天，無從下手。
這時候可以通過一個流程化的模板來指導，如果抽象一個通用的流程，可以參考下面的套路：
業務拆解 > 復雜度來源 > 核心挑戰點
領域驅動設計 > 業務過程分析 > 領域模型抽象 > 模型分解
分層組織 > 工程架構 > 模塊化 > 組件化
考慮功能復用 > 可選路徑 —( 業務身份，能力，擴展點，工作流程，編排)
方案產出 > 整體-模塊-流程-細節 > 方案評審 > 最終方案
其中的功能復用環節，是包括阿里在內的大部分業務中台的解決思路，僅供參考。
一、業務拆解
1.1 復雜度來源
為什么要關注復雜度？
架構設計的目的是為了解決軟件系統的復雜度帶來的問題。
所以在設計架構時，首先就要分析系統的復雜度。
只有正確分析出了系統的復雜性，后續的架構設計方案才不會偏離方向；否則，如果對系統的復雜性判斷錯誤，即使后續的架構設計方案再完美再先進，都是南轅北轍，做的越好，錯的越多、越離譜。
舉個例子，醫院管理應用的醫療管理系統(HIS)，復雜度在於業務邏輯復雜，系統之間調用不清晰，如果你設計一個QPS幾萬的高性能架構，就是沒有解決系統的核心問題。
正確的做法是將主要的復雜度問題列出來，然后根據業務、技術、團隊等綜合情況進行排序，優先解決當前面臨的最主要的復雜度問題。
1.2 核心挑戰點
射人先射馬，擒賊先擒王。
確定了復雜度，也就確定了系統設計的難點，在進行系統設計時，可以把難點列出來，各個擊破。
以電商促銷為例，促銷活動最大的復雜度來自營銷形態的變化，營銷最大的不變就是變，亂花漸欲迷人眼，各類促銷方式千變萬化。
每次促銷活動都有不同的玩法和定義，促銷系統的設計必須對促銷模式有所抽象，任何活動或優惠手段都是基於最基本的促銷模式而建立的。
電商營銷中心建設難點包括：
底層模型抽象：底層模型抽象可以通過DDD的方式，對領域模型和進行抽象。
促銷引擎性能：性能問題如何解決？已經是老生常談，工程領域有很多經典的解決方案，比如緩存，異步，最終一致性。
關聯系統交互：理清和關聯系統的交互
二、領域驅動設計
軟件系統的目的反映在業務上，都是來解決一系列問題，例如考試系統完成考試，電商就是賣貨，同一個領域的系統都具有相同的核心業務，因為他們要解決的問題的本質是類似的，一個領域本質上可以理解為一個問題域 。
只要確定了系統所屬的領域，那么這個系統的核心業務，即要解決的關鍵問題就基本確定了。
任何一個系統都會屬於某個特定的領域，例如論壇系統，核心功能是確定的，比如用戶發帖，回帖等基本功能。廣義的電商系統也是一個領域，做電商業務，必須要支持的商品，訂單，交易，物流等功能。
DDD里有領域專家的概念，領域專家要在這個領域深入研究，只有這樣才會遇到非常多的該領域的問題，積累比較更加豐富的經驗。
通常來說，一個領域有且只有一個核心問題，也就是核心子域。在核心子域、通用子域、支撐子域梳理的同時，會定義出子域中的限界上下文及其關系，用它來闡述子域之間的關系 。
以電商營銷為例，優惠券、抽獎、套餐等，都是圍繞這個促銷這個業務范圍來進行的，在促銷域之外，還有相關的用戶、商品、訂單、風控、商家等。
三、架構分層
3.1 架構分層
下圖是領域驅動設計中經典的分層架構：
下圖為 Eric Evans 在其經典著作《領域驅動設計》中的分層架構：
三層架構：
整潔架構(Clean Architecture)
Robert Martin 的整潔架構將領域模型放在整個系統的核心，這一方面體現了領域模型的重要性，另外一方面也說明了領域模型應該與具體的技術實現無關。領域模型就是業務邏輯的模型，它應該是完全純粹的，無論你選擇什么框架，什么數據庫，或者什么通信技術，按照整潔架構的思想都不應該去污染領域模型。如果以 Java 語言來實現，遵循整潔架構的設計思想，則所有領域模型對象都應該是 POJO(Plain Ordinary Java Object)(具有領域邏輯的 POJO 對象)。
3.2 工程架構
DDD的核心訴求就是將業務架構映射到系統架構上，在響應業務變化調整業務架構時，也隨之變化系統架構。 微服務追求業務層面的復用，設計出來的系統架構和業務一致，不過領域模型並不直接反映數據結構，需要明確這一點。領域驅動設計最后落地到數據存儲上，不需要直接參考領域模型，在最后的技術架構上可以自由選擇合適的技術架構。
3.3 模塊組織
Java項目一般是典型的Maven多模塊項目，可以使用不同的Module，區分各個層次，進一步，通過Package來控制DDD中的限界上下文。
四、功能復用
4.1 編程DRY原則
大家都知道，編寫整潔代碼，有一個非常重要的原則就是DRY，Don't Repeat Yourself，避免產生重復代碼，有經驗的程序員都能夠意識到這一條約束。
如果你使用Idea開發，Idea也會識別並且提示你重復的代碼，建議你進行抽象。
DRY的好處更少的代碼是好的，它節省了時間和精力，易於維護，並且減少了bug的幾率。
除了在軟件開發領域，在業務系統層面，也存在如何避免重復能力建設，考慮業務復用的問題。
4.2 業務層面的DRY
業務系統層面的DRY原則，其實可以總結為一個問題，就是復雜業務系統，如何實現具有共性的業務能力的復用，這個也是很多業務中台關注的問題。
一般的，大部分業務中台(特指業務中台，不包括數據中台等其他形態)對業務復用的方式，
都可以通過定義業務身份 ——> 梳理擴展點 ——> 枚舉業務能力 ——> 根據不同業務身份編排工作流 ——> 實現業務能力復用，這樣的流程來實現。
可以對比編程中的Pipeline模式，或者責任鏈模式，只不過每個鏈條上負責處理輸入和輸出的，是不同的業務功能。
業務中台是另一個話題，這部分是發散思考，具體可以參考阿里巴巴 TMF (Trade Mudule Framework)框架的介紹：
如何實現32.5萬筆/秒的交易峰值？阿里交易系統TMF2.0技術揭秘
五、可擴展性和過度設計如何平衡
好的架構設計一定是擴展簡單的。在設計時，要盡量封裝可能的變化，在業務流程發生一些調整時，能夠比較方便地修改系統程序模塊或組件間的調用關系而實現新的需求，也就是我們常說的可擴展性。
但是可擴展性本身也是系統設計的復雜度來源之一，這就涉及到一個問題，如何平衡可擴展和過度設計。
5.1 區分確定性和變化
好的架構一定是擴展簡單，運行平穩的。
系統架構最開始可以從一個通用的流程開始，case-by-case，然后將「變化少」的部分沉淀下來為架構，將「變化多」的沉淀為擴展或者配置，梳理清楚，將這兩者結合起來，最后完成系統架構設計。
5.2 用容量規划的方式來處理擴展程度
可以使用容量規划的思想，來處理可擴展性設計。
在做技術方案時，容量規划是一個特別重要的環節，要預估未來幾年的增長量，進行數據庫和緩存的容量規划。
我覺得這個方式也可以應用在擴展性設計上，對業務變化進行預期，考慮技術方案能夠支持的業務發展時間。
六、方案評審
好的技術方案很難一蹴而就，大部分時候要經過反復的調整，就是需要關聯的各方參與方案的評審和修改，最終確定最終技術方案。
七、總結
復雜業務系統開發的一些體會：
熟悉業務，抽象產品需求，分析相關測試用例，了解各種用戶角色和其使用的場景
自頂向下進行方案設計，對於比較復雜的業務系統，比較好的方式是先關注頂層模型，避免在一開始就陷入技術和業務細節中去
從整體設計，到模塊局部規划，設計好部署架構、分層和分模塊、API設計、數據庫設計等
可以參考成熟的解決方案，比如將開源軟件，改造，變成適合自己業務需求的架構
驗證和優化架構設計方案，完整的架構設計方案，需要有多次的評審，充分收集各方面的反饋，反復修改后確定
合理進行擴展，考慮架構預期能滿足多長時間的業務增長，比如未來一年的業務變化。
參考資料：
https://blog.csdn.net/bingyuea/article/details/111101459
https://blog.csdn.net/zhouhao88410234/article/details/95242449
https://baijiahao.baidu.com/s?id=1658157066668484115&wfr=spider&for=pc
————————————————
版權聲明：本文為CSDN博主「東海陳光劍」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/universsky2015/article/details/114921993