本文我會來說說我認(rèn)為架構(gòu)評審中應(yīng)該看的一些點粪般，以及我寫設(shè)計文檔的一些心得昼捍。助你在架構(gòu)評審中過五關(guān)斬六將蜂筹，助你寫出能讓人收藏點贊的設(shè)計文檔幅慌。

技術(shù)架構(gòu)評審一百問

架構(gòu)評審或技術(shù)方案評審的價值在于集眾人的力量大家一起來分析看看方案里是否有坑腰素，方案上線后是否會遇到不可逾越的重大技術(shù)問題聘裁，提前盡可能把一些事情先考慮到提出質(zhì)疑其實對項目的健康發(fā)展有很大的好處。很多公司都有架構(gòu)評審委員會都有架構(gòu)評審的流程弓千，做業(yè)務(wù)的兄弟要么看到這個流程往往心驚膽戰(zhàn)害怕自己做的方案被斃了咋整衡便，要么就是認(rèn)為這是一種過場，隨便糊弄一點文檔發(fā)給委員會看一下就算過去了洋访。我做過架構(gòu)評審委員也做過提交評審方案的業(yè)務(wù)兄弟镣陕，不管哪個角色我都不害怕而是喜歡這一流程，評審這個事情做的好其實可以很享受姻政，大家都是一起學(xué)習(xí)的過程呆抑，不存在誰為難誰。下面說說我覺得架構(gòu)評審（非代碼評審）中看重的需要評審的一些點汁展。

組件選型

• 為什么選A不選B呢鹊碍？
• A不是開源的，出了問題怎么辦食绿？
• B雖然是開源的侈咕，但是是Erlang寫的，公司沒人能看懂怎么辦器紧？
• C我看待解決的Issues還有很多耀销，有沒有去了解過？
• 這個組件在性能方面你是否了解過铲汪？
• 開源的免費版本不支持集群怎么辦熊尉？
• 如果徹底要自己寫這個組件有沒有可能性？

組件特別是存儲組件選型挺重要的桥状，真心建議事先可以有那么幾周的時間搭一個高可用的集群帽揪，使用接近于真實的數(shù)據(jù)對組件進(jìn)行壓測（你看之前我博客上的Mongodb的壓測文章停火的辅斟，說明很多人沒有這個時間和條件對一些組件進(jìn)行壓測）。眼見為實耳聽為虛芦拿，自己通過壓測對比一下自己得出的數(shù)據(jù)和公開的數(shù)據(jù)是否有差異士飒，如果有的話說不定還能發(fā)現(xiàn)自己使用上的一些問題查邢。盡量還是選用使用的人多的開源組件吧，出了問題至少Patch不會來的太慢酵幕。

性能

• 我們需求的TPS扰藕、QPS和RT是多少？
• 整體設(shè)計上會做到的TPS芳撒、QPS和RT是多少邓深？
• 隨著數(shù)據(jù)量的增大系統(tǒng)性能會不會出現(xiàn)明顯問題？
• 系統(tǒng)哪個環(huán)節(jié)會是最大的瓶頸笔刹？
• 是否打算做壓力測試芥备，壓力測試方案是怎么樣的？
• 怎么提高前端用戶的訪問流暢性舌菜？

對于重要的項目萌壳，建議做一下整體壓測，沒有經(jīng)過壓測得出來的估計的結(jié)論往往可能是錯的日月，我們總以為最終會死在最后的存儲上袱瓮，但是很可能早早就死在了程序的低級錯誤上，比如在一些存儲組件的Client使用上爱咬，如果沒把控好最佳實踐（把應(yīng)該作為單例使用Clinet每次都去創(chuàng)建一次尺借，默認(rèn)的線程數(shù)小的可憐應(yīng)該重新配置但是保留了默認(rèn)值），死的非常難看精拟。

可伸縮性

• 每一個環(huán)節(jié)是否都是可以橫向擴(kuò)展的褐望？
• 擴(kuò)容需要怎么做手動還是自動？
• 數(shù)據(jù)庫不能橫向擴(kuò)展怎么辦串前？
• 縱向擴(kuò)展有多少效果瘫里？
• 橫向擴(kuò)展是否是線性的？
• 擴(kuò)展后是否可以提高響應(yīng)速度荡碾？

靈活性

• 是否有了解過產(chǎn)品層面以后會怎么發(fā)展谨读？
• 模塊A是否能拆分出去獨立為其它業(yè)務(wù)服務(wù)？
• 模塊B是否可以替換為另一種第三方數(shù)據(jù)源坛吁？
• 如果流程有變劳殖，需要多大的工作量來適應(yīng)？
• 業(yè)務(wù)是否可以做到可配拨脉？

可擴(kuò)展性

• 為什么A和B都有差不多的邏輯哆姻？
• 是否考慮到了A業(yè)務(wù)的實現(xiàn)以后還有B的可能性？
• 如果現(xiàn)在有兩種策略以后擴(kuò)展到了八種策略怎么做玫膀？
• 以后是否可以把這個業(yè)務(wù)的H5前端適配到PC矛缨？

可靠性

• 是否架構(gòu)中有單點？
• 故障轉(zhuǎn)移是怎么實現(xiàn)的？
• 集群內(nèi)部故障轉(zhuǎn)移需要多久箕昭？
• MQ或存儲出現(xiàn)問題的時候系統(tǒng)會怎么樣灵妨？
• MQ或存儲出現(xiàn)問題又恢復(fù)了系統(tǒng)是否會自己恢復(fù)？
• 是否考慮過異地故障轉(zhuǎn)移的方案落竹？
• 是否考慮過多活的方案泌霍？
• 是否有數(shù)據(jù)丟失的可能性？
• 數(shù)據(jù)丟失后是否可以恢復(fù)述召？
• 系統(tǒng)徹底掛了對其它業(yè)務(wù)的影響是什么朱转？
• 系統(tǒng)徹底掛了是否可以有線下的方式走業(yè)務(wù)？

安全性

• 是否徹底避免SQL注入和XSS积暖？
• 是否做了風(fēng)控策略藤为？
• 是否有防刷保護(hù)機(jī)制？
• 數(shù)據(jù)庫拖庫了會怎么樣呀酸？
• 是否有數(shù)據(jù)泄露的可能性凉蜂？
• 數(shù)據(jù)的權(quán)限怎么控制的？
• 功能的權(quán)限是怎么控制的性誉？
• 是否做了日志審計窿吩？
• 受到了DDOS攻擊怎么辦？
• 數(shù)據(jù)傳輸是否加密驗簽错览？

兼容性

• 老的系統(tǒng)打算怎么辦纫雁？
• 怎么進(jìn)行新老系統(tǒng)替換？
• 新老系統(tǒng)能否來回切換倾哺？
• 別的系統(tǒng)怎么連接你這套新服務(wù)轧邪？
• 上下游依賴是否梳理過，影響范圍多大羞海？
• 上下游改造的難度怎么樣忌愚？
• 上下游改造有排期嗎？
• 上下游改造的計劃和通知時間確定了嗎却邓？
• 使用了新的數(shù)據(jù)源數(shù)據(jù)怎么遷移硕糊？
• 使用了新的技術(shù)老項目開發(fā)能否適應(yīng)？

彈性處理

• 這個數(shù)據(jù)重復(fù)消費會怎么樣腊徙？
• 這個接口重復(fù)調(diào)用會怎么樣简十？
• 是否考慮了服務(wù)降級？哪些業(yè)務(wù)支持降級撬腾？
• 是否考慮了服務(wù)熔斷螟蝙？熔斷后怎么處理？
• 是否考慮了服務(wù)限流民傻？限流后客戶端表現(xiàn)怎么樣胰默？
• 隊列爆倉會怎么樣场斑？
• 是否考慮了隔離性？

事務(wù)性

• 這段業(yè)務(wù)由誰保證事務(wù)性初坠？
• 數(shù)據(jù)庫事務(wù)回滾后會怎么樣和簸？
• 服務(wù)調(diào)用了失敗怎么辦彭雾？
• 隊列補(bǔ)償怎么做的碟刺？
• 服務(wù)調(diào)用補(bǔ)償怎么做的？
• 數(shù)據(jù)補(bǔ)償實現(xiàn)最終一致需要多久薯酝？
• 在數(shù)據(jù)不完整的時候用戶會感知到嗎半沽？

可測試性

• 測試環(huán)境和線上的差異多大？
• 是否支持部署多套隔離的測試環(huán)境吴菠？
• 是否打算做單元測試者填，覆蓋率目標(biāo)是多少？
• 測試黑盒白盒工作量的比例是怎么樣的做葵？
• 是否支持接口層面的自動化測試占哟？
• 是否有可能做UI自動化測試？
• 壓測怎么造數(shù)據(jù)酿矢？
• 是否可以在線上做壓測榨乎？
• 線上壓測怎么隔離測試數(shù)據(jù)？
• 是否有測試白名單功能瘫筐？

可運(yùn)維性

• 每一個組件對服務(wù)器哪方面的壓力會最大蜜暑？
• 重新搭建整套系統(tǒng)最快需要多少時間？
• 系統(tǒng)是否可以完全基于源代碼構(gòu)建策肝？
• 系統(tǒng)是否有初始化或預(yù)熱的環(huán)節(jié)肛捍？
• 系統(tǒng)里哪些環(huán)節(jié)需要人工參與？
• 數(shù)據(jù)是否需要定期歸檔處理之众？
• 會不會有突發(fā)的數(shù)據(jù)量業(yè)務(wù)量增大拙毫？
• 隨著時間的推移如果壓力保持不變的話系統(tǒng)需要怎么來巡檢和維護(hù)？
• 怎么在容器里進(jìn)行部署棺禾？

監(jiān)控

• 業(yè)務(wù)層面哪些指標(biāo)需要監(jiān)控和報警缀蹄？
• 應(yīng)用層面系統(tǒng)內(nèi)部是否有暴露了一些指標(biāo)作監(jiān)控和報警？
• 系統(tǒng)層面使用的中間件和存儲是否有監(jiān)控報警帘睦？
• 是否所有環(huán)節(jié)都接入了全鏈路跟蹤袍患？
• 出現(xiàn)報警的時候應(yīng)該由誰來處理？
• 每一個模塊是否有固定的主要和次要負(fù)責(zé)人竣付？
• 有沒有可能系統(tǒng)出了問題無法通過監(jiān)控指標(biāo)體現(xiàn)诡延？
• 哪些指標(biāo)需要上大屏由監(jiān)控進(jìn)行7*24監(jiān)控？

看了這么多問題可能會覺得這架構(gòu)設(shè)計是沒法做了古胆，其實不同階段的項目有不同的目標(biāo)肆良，我們不會在項目起步的時候做99.99%的可用性支持百萬QPS的架構(gòu)筛璧，高效完成項目的業(yè)務(wù)目標(biāo)也是架構(gòu)考慮的因素之一。而且隨著項目的發(fā)展惹恃，隨著公司中間件和容器的標(biāo)準(zhǔn)化夭谤，很多架構(gòu)的工作被標(biāo)準(zhǔn)化替代，業(yè)務(wù)代碼需要考慮架構(gòu)方面伸縮性運(yùn)維性等等的需求越來越少巫糙，慢慢的這些工作都能由架構(gòu)和運(yùn)維團(tuán)隊來接朗儒。一開始的時候我們可以花一點時間來考慮這些問題，但是不是所有的問題都需要有最終的方案参淹。

技術(shù)設(shè)計文檔五要素

如果你在Google搜索架構(gòu)設(shè)計文檔醉锄、技術(shù)設(shè)計文檔、概要設(shè)計文檔可以搜索到很多模板浙值，很多公司也會以這些模板作為設(shè)計文檔的模板來讓大家填寫恳不。對于大部分所謂的項目只是一個項目中的一個小環(huán)節(jié)是一個具體的業(yè)務(wù)邏輯，因此總是可以看到大家寫的所謂的技術(shù)設(shè)計文檔只能填滿文檔的20%开呐，其余都不知道怎么寫烟勋。當(dāng)你不知道文檔應(yīng)該寫哪些內(nèi)容的時候可以這么來考慮問題，就是你這個項目接下去是要賣給別人來用的筐付，你沒有機(jī)會當(dāng)面和他把這個項目說清楚卵惦，你只能通過文檔來把事情寫清楚，別人就給你一次機(jī)會家妆，如果看不懂你文檔表達(dá)的意思鸵荠，不能理解你的項目，你的項目就賣不出去不值錢伤极，這個時候你一定會從各個角度來剖析你的系統(tǒng)想盡一切辦法來把事情說清楚蛹找，用這個方法逼一下自己的，你的文檔會很優(yōu)秀哨坪。接下去我想說一下如果是我的話我看重技術(shù)設(shè)計的哪些部分以及這些部分的文檔的寫作方式庸疾，這些內(nèi)容構(gòu)成了一個必要的（概要）設(shè)計文檔，算是拋磚引玉当编。

交代背景和需求全貌

在這里届慈，推薦使用腦圖在技術(shù)角度給出一下自己理解的項目需求的分布。PRD中的產(chǎn)品功能腦圖可以和這里技術(shù)角度的腦圖有差異忿偷，在說清楚需求的同時側(cè)重技術(shù)層面金顿，體現(xiàn)在：

• 可以不按照需求的功能點進(jìn)行歸類而是按照實際項目歸類，把需求列在實際的項目下面
• 可以區(qū)分需求是自己干的還是調(diào)用外部的接口鲤桥，可以在圖上以不同的形態(tài)提現(xiàn)
• 可以畫出功能之間的依賴關(guān)系揍拆，以虛線實線進(jìn)一步區(qū)分依賴的程度
• 可以在圖上體現(xiàn)需求的優(yōu)先級以及需求目前的進(jìn)展和負(fù)責(zé)人，這樣基本一個圖就可以看清楚這個項目需要消耗多少資源需要多久可以結(jié)束

看了這個圖基本產(chǎn)品需求就可以理解個大概茶凳，具體的細(xì)節(jié)規(guī)則可以進(jìn)一步參考PRD嫂拴。

系統(tǒng)架構(gòu)圖

在本系列文章的第二到第五篇中播揪，我都配了一個架構(gòu)圖。架構(gòu)圖需要傳遞清楚下面的信息：

• 項目由哪些模塊筒狠、服務(wù)猪狈、緩存、存儲構(gòu)成辩恼，可以以不同的圖案和顏色代表不同類型
• 模塊之間的依賴關(guān)系（當(dāng)然雇庙，也可以從數(shù)據(jù)的流向角度來畫）
• 核心流程的步驟组贺，沿著圖上的1文黎、2、3基本就可以大概了解核心流程的實現(xiàn)
• 可以用大的框把組件進(jìn)行分組來描述組件的部署方式（比如相同機(jī)器上承載的組件在一個框內(nèi)）
• 可以以邊框的虛實來分類項目內(nèi)的組件或三方組件，可以以箭頭的虛實來標(biāo)記主要流程次要流程等等

UML里會有一些具體的分類谁帕，什么類圖、組件圖冯袍、部署圖等等匈挖，我覺得不必拘泥于這些細(xì)節(jié)，通過線線框框的架構(gòu)圖能把模塊和模塊之間的關(guān)系表述請求康愤，然后再配以一定的文字來說明每一個組件即可儡循。我自己常用的是gliffy，只要能說清楚征冷，Word畫也可以择膝。根據(jù)項目的大小，圖上的模塊不一定是需要獨立部署的進(jìn)程检激，模塊也可以是項目內(nèi)部的一個模塊或類肴捉。對于復(fù)雜的項目，要畫一個圖說清楚很難叔收，可以畫一個大的架構(gòu)圖齿穗，然后針對每一個模塊或流程再細(xì)化畫不同層次的圖。

對外API定義

API的詳細(xì)定義可以由Swagger UI饺律、Spring REST Doc窃页、Miredot等等工具生成，這些生成的接口是按照代碼來組織層次關(guān)系的复濒，只能體現(xiàn)接口的參數(shù)定義不能體現(xiàn)接口的形態(tài)等脖卖，是沒有思想的，不適合用來閱讀巧颈，只適合用來參考畦木。因此還是建議做一個腦圖來總體闡述一下接口的：

• 分類，按業(yè)務(wù)功能的分類洛二，按受眾的分類等等
• 形式（圖上不同的顏色）馋劈，同步還是異步（結(jié)果不在響應(yīng)中攻锰，單獨的回調(diào)返回），單條還是批量妓雾，數(shù)據(jù)接口還是頁面調(diào)用等等
• 重要性（圖上文字后的星號）娶吞，比如重點標(biāo)記主流程的接口

圖上可以不顯示出參數(shù)清單，但可以以簡單的文字來描述重要參數(shù)械姻，比如下單接口：->@用戶身份妒蛇，優(yōu)惠券ID，[{商品ID,數(shù)量}]<-訂單號楷拳，下單結(jié)果（0-失敗绣夺，1-成功）。（->代表輸入欢揖，<-代表輸出陶耍，[]代表數(shù)組，@代表隱式參數(shù)她混，代表可空參數(shù)等等）烈钞。

之前強(qiáng)調(diào)過好多次涉及到和外部交互的API是設(shè)計中非常重要的一個環(huán)節(jié)，不僅僅體現(xiàn)了系統(tǒng)對外輸出的能力坤按，也體現(xiàn)了系統(tǒng)設(shè)計在安全性毯欣、復(fù)用性、封裝等方面的平衡臭脓。

交互時序

時序圖的表達(dá)非常重要酗钞，可以表現(xiàn)需求腦圖、架構(gòu)圖和API腦圖無法表現(xiàn)出來的幾個方面来累，清晰展現(xiàn)了某個事情：

• 關(guān)鍵的利益關(guān)系方砚作。這個事情由哪幾個方面構(gòu)成，可以是用戶佃扼、甲方偎巢、乙方這么來分，也可以是用戶兼耀、APP客戶端压昼、服務(wù)端這么來分
• 每一方在做什么，依賴的又是什么瘤运，整個順序是怎么樣的
• 技術(shù)層面這是同步接口窍霞、還是回調(diào)、還是非技術(shù)的線下流程
• 還可以在圖上表現(xiàn)出可選邏輯拯坟，條件判斷邏輯但金，循環(huán)邏輯等等

我覺得能在比較高的層面說一下技術(shù)（對接）流程即可，不一定要詳細(xì)到類和類之間的交互郁季，類和類之間的交互閱讀代碼或直接看全鏈路調(diào)用的圖就可以冷溃。如果項目有多個合作方多個依賴方钱磅，項目流程比較復(fù)雜，那么序列圖是能把這個事情說清楚的最好的方式似枕。

對于這種時序圖盖淡，采用傳統(tǒng)的工具來畫費時費力，推薦下面兩個工具（https://www.websequencediagrams.com/和http://plantuml.com/sequence-diagram）凿歼，可以在幾分鐘內(nèi)生成需要的圖褪迟。

我們輸入類似的文字：

title 合作流程

用戶->XX:投資YY標(biāo)的

XX->YY:同步投資情況，更新可用額度

用戶->YY:在額度內(nèi)消費

YY->XX:同步消費情況答憔，更新可用額度味赃，更新回款計劃

YY->XX:還款

XX->用戶:回款（已消費部分作為手續(xù)費給XX）

opt 線下流程

XX->YY:對于YY用戶的消費出賬單

YY->XX:對賬確認(rèn)賬單

XX->YY:打款開具發(fā)票

End

網(wǎng)站生成類似的時序圖，還可以自由選擇自己喜歡的樣式：

數(shù)據(jù)庫ER

ER圖就是實體聯(lián)系圖虐拓。形式上我們可以在圖上表現(xiàn)幾個點：

• 實體：哪些表

• 實體上的屬性：體現(xiàn)實體之間關(guān)系以及實體業(yè)務(wù)功能的重要字段

• 聯(lián)系：實體和實體之間的關(guān)系心俗，比如一對多，多對一還是多對多之類

在有的時候我們可以省略屬性的類型定義侯嘀，甚至可以直接省略具體的屬性（實體名和M對N的關(guān)系是必須的）另凌，把圖簡化為類似下面的部分：

ER圖的信息量非常大，絕對不是粘貼一下表結(jié)構(gòu)的DDL可以替代的戒幔，原因是：

• ER圖可以以極小的空間展現(xiàn)很多信息，這樣我們可以在圖上對業(yè)務(wù)進(jìn)行分組土童，看到全貌
• ER圖展現(xiàn)的是表和表之間的關(guān)系诗茎，一眼可以看出最重要核心的表是哪些

比如下圖，是否一眼就可以看明白一套P2P金融業(yè)務(wù)整個數(shù)據(jù)結(jié)構(gòu)的架構(gòu)呢：

（隨便畫的圖献汗，不代表任何意義敢订，請不要以這個圖做P2P的表結(jié)構(gòu)設(shè)計）

所有的圖，文字只是一個維度罢吃，我們要學(xué)會利用邊框類型（矩形楚午、圓角矩形），邊框樣式（虛線尿招，實線）矾柜，填充色，文字顏色就谜，關(guān)聯(lián)線條粗細(xì)顏色樣式怪蔑，框內(nèi)ICON來增加我們要表現(xiàn)信息的維度，最多可以增加到6維+丧荐，這種能力是文字很難實現(xiàn)的缆瓣。一圖勝過千言，所以我一直認(rèn)為圖是設(shè)計文檔中非常重要的部分虹统。

其它

之前我說了我們可以以五圖的形式（需求腦圖弓坞、架構(gòu)圖隧甚、API腦圖、序列圖渡冻、數(shù)據(jù)庫ER圖）把系統(tǒng)大概介紹一個底朝天呻逆，說清楚了需求、架構(gòu)菩帝、對外接口咖城、交互流程和數(shù)據(jù)結(jié)構(gòu)設(shè)計這幾個事情，業(yè)務(wù)項目說清楚這些足夠了呼奢。

對于偏向于中間件（不管是基礎(chǔ)中間件還是業(yè)務(wù)中間件宜雀，中臺）的項目（而不是業(yè)務(wù)項目），這里我再補(bǔ)充幾個重要的方面握础，需要在設(shè)計文檔中有體現(xiàn)：

• 可靠性：是否有單點的組件辐董，非單點的組件如何做故障轉(zhuǎn)移

• 高性能：是否有抗突發(fā)性能壓力的能力，大概可以滿足多少的TPS和QPS禀综，怎么去做來實現(xiàn)高性能

• 可擴(kuò)展：隨著壓力上升哪些環(huán)節(jié)可以做擴(kuò)展简烘，怎么做擴(kuò)展

• 安全性：哪些手段防突破，萬一突破了后果怎么樣

• 兼容性：和遺留系統(tǒng)怎么通訊定枷，怎么做遷移

• …………等等方面

這些點我就不一一展開說了孤澎，在第一節(jié)說架構(gòu)評審的時候都有提到過，針對那些問題寫一下自己的設(shè)計是怎么應(yīng)對的吧欠窒。

這些點我認(rèn)為可以構(gòu)成一個合格的設(shè)計文檔覆旭，文檔的形式不重要，重要的是可以把業(yè)務(wù)的技術(shù)實現(xiàn)梳理清楚岖妄，確保我們在開發(fā)之前有一個清晰的思路型将，在開發(fā)上線后，文檔也是一個后人熟悉系統(tǒng)的非常重要的手段荐虐。你可能會提出疑問說這樣的設(shè)計文檔是不是太粗略了一點七兜，完全沒有體現(xiàn)到軟件層面設(shè)計的細(xì)節(jié)，沒錯是這樣福扬，但是我一直說的是互聯(lián)網(wǎng)架構(gòu)心得腕铸，敢問現(xiàn)在互聯(lián)網(wǎng)項目從0開始的大項目1到2個月上線，大的版本迭代2周一次忧换，如果設(shè)計的時間是五分之一的話恬惯，設(shè)計也就是2天到一周這樣子，我們有多少時間和能力來細(xì)化文檔呢亚茬，如果能把我這里說的五要素都做好酪耳，對于互聯(lián)網(wǎng)項目已經(jīng)笑死。

還有一點往往會比較可惜，我們或許可以做到在開發(fā)之前有一個概要設(shè)計文檔的產(chǎn)出碗暗，但是我們很難做到在系統(tǒng)上線后隨著迭代還能繼續(xù)維護(hù)第一版產(chǎn)品上線時那個大而全的文檔颈将。隨著產(chǎn)品的迭代，我們的技術(shù)文檔也像PRD迭代文檔一樣只說這次迭代的技術(shù)改動的話言疗，這種設(shè)計文檔因為沒有全局觀意義不大晴圾。對于這個情況，我覺得對于每一條業(yè)務(wù)線的產(chǎn)品噪奄，我都建議我們至少能維護(hù)大而全的下面這些文檔的全量版本：

• 完整表結(jié)構(gòu)（順帶標(biāo)一下歸檔方案死姚、重要程度）
• 需求全貌
• 對外產(chǎn)品能力輸出全貌
• 整體架構(gòu)圖
• 關(guān)鍵業(yè)務(wù)交互流程（特別是那種很難說清楚的多方結(jié)算關(guān)系）

定期回顧一下這五個文檔，根據(jù)最近的需求改改勤篮，可能也只需要花費幾小時的時間都毒，對于大項目其意義往往是新人的靈魂導(dǎo)師（之前我有畫過一個比較復(fù)雜系統(tǒng)的架構(gòu)圖，這個架構(gòu)圖我看到有人做了桌面）碰缔。

寫在最后

點關(guān)注账劲，不迷路，每天跟新Java相關(guān)技術(shù)及資訊