對標大廠的技術派架構設計
很多同學對技術派項目非常感興趣，目前技術派教程已經更新了三十篇，今天就給大家講講技術派的架構設計，讓你對該項目有一個整體的認識。
通常對于技術人員而言，在開啟一個新的項目之前，做了前期的調研、立項之后，第一件事情并不是開始搭建工程、擼代碼，一個整體的架構方案設計、評審都屬于不可忽視的環節。
接下來我將盡量追溯還原技術派的整體架構，是如何從 0 到 1 進行敲定的。
不 BB，上目錄：
1. 業務模塊拆解
在查看本文之前，請確保已正確了解技術派的主營業務，覆蓋的功能點，如有疑問，可以先體驗一下技術派網站，訪問地址：https://paicoding.com
在業務模塊拆解這一過程中，除了業務屬性維度之外，還有一個非常重要的屬性是參與者角色。
1.1 角色拆解
作為一個社區系統，用戶角色非常容易劃分
- 讀者：普通瀏覽文章的用戶
- 作者：發布文章的用戶
- 管理員：整個系統的超管
權限劃分
那么這三個角色的權柄是怎么劃分的呢？
從上圖可以比較清晰的看出三個角色的劃分
- 讀者的所有功能，作者都擁有；但是作者存在部分讀者用不了的功能（如文章編輯、修改、發布等）
- 管理員權限最大，覆蓋讀者、作者的所有功能點
差異性劃分
接下來就需要抓重點，看一下上面三個角色的主要差異點在哪里
- 讀者：主要是閱讀文章
- 作者：發布文章，作為信息輸出
- 管理員：整個系統的運營管理，如標簽、分類管理，文章審核等；通常不怎么參與文章的閱讀發布
基于以上分析，我們可以將技術派的用戶分為
- 普通用戶：作為社區的注冊用戶，圍繞文章主體展開其覆蓋的業務功能點
- 管理員：作為官方角色，主要負責整個社區的生態運營
1.2 業務拆解
整個社區系統，按找業務邊界先進行一版本初始劃分：
- 用戶
- 文章
- 評論
- 專欄
- 消息通知
然后再針對上面的進行簡單的細化拆分
再上面進行簡單拆分之后，會發現幾個關鍵點
- 專欄：實際上是一些文章的合集，因此專欄的很多功能點可以直接建立在文章的基礎上
- 評論：評論實際上也是依托于文章的點評，因此它于文章的關聯性很強
- 消息通知：
消息通知的觸發點需要進一步確認，但是它本身又屬于一個相對獨立的業務板塊，因此重點關注交互方式
什么樣的需要通知？如何觸發通知？
怎么通知給用戶？
- 點贊、收藏、計數統計獨立于核心業務功能之外的能力：
這種與業務相關，但是又可以抽離于業務之外獨立存在，可以考慮建設通用的服務能力
社區的搜索、推薦，雖然不影響核心業務功能，但是否需要考慮？
社區運營
基于以上，我們進行業務模塊拆分，先確定以下板塊：
1.3 小結
通常，在業務拆解這里，希望達到的目的是讓參與者，能知曉這個項目的整體情況，可以劃分為多少業務域，明確業務模塊的主營范疇，確定彼此的邊界
在這一階段，我們可以先對技術派的整體拆分，得出以下結論：
角色
- 普通用戶：作為社區的注冊用戶，圍繞文章主體展開其覆蓋的業務功能點
- 管理員：作為官方角色，主要負責整個社區的生態運營
業務模塊
- 業務側：
文章
評論
專欄
用戶
運營
- 基礎功能測：
推薦
搜索
統計
消息通知
注意
- 一般來說，在整體設計階段，每個業務模塊，需明確的是主體業務功能，但并不需要拆解到一個一個具體的功能點，具體的功能點，放在詳細設計中來體現
- 業務的拆解不是一蹴而就的，相反實際情況下，這個拆解經常會出現反復、變動的情況（如果有留心公司的組織結構調整的小伙伴，應該對這種情況不難理解）
2. 模塊交互方案
接下來我們就需要將上面拆分的角兒和業務模塊串聯起來，看一下我們的整個系統是怎么玩的
2.1 整體交互設計
對于技術派的核心玩法，在于作者發布文章，讀者閱讀文章；整體交互相對清晰簡單，實際上這一塊是可以省略的；當然我這里也補上這個流程，主要以文章發布，到讀者閱讀文章，并點贊，作者獲取通知這個流程，來串一下這個系統的整體交互流程
上面這個交互過程中，用戶中心、文章、消息中心，可以是獨立部署的服務，也可以是一個進程內的服務；但是從邏輯上，他們彼此是獨立的；針對上面的操作流程，可以提煉下面幾個點
- 用戶首先通過用戶中心登錄系統
具體的登錄方式可以是傳統的用戶名/密碼，也可以是手機號驗證碼，亦或者是第三方OAuth2.0登錄
登錄之后，用戶身份識別，可以是單機的cookie/session, 也可以是分布式會話，jwt等形式
- 文章發布
- 正向邏輯為作者發布文章
- 文章審核對于作者而言，則屬于被動接收，即存在一個依賴關系，是自動審核，還是人工審核？人工審核怎么通知管理員來審核？
- 消息通知
- 讀者給文章點贊之后，如何將點贊通知給作者？
- 這個點贊事件是同步觸發給作者，還是異步？
2.2 登錄交互方案
登錄交互我們最終選擇的方案是基于微信公眾號來實現的，下面這個交互方案適用于個人公眾號（如果是企業公眾號，可以直接使用微信的相關的API）
2.3 消息通知方案
消息通知采用異步驅動，通過Event/Listener方式來實現解耦
3. 整體架構方案
上面的流程走完之后，接下來就是敲定整體的架構方案，通常一個好的架構方案一張圖就完事了，注意越是前期在意的越不是細節
3.1 初版設計方案
下面這張圖來自于技術派開始做之前繪制的，與最終的實現版稍有差異，無需在意細節??
最初版的方案設計非常簡陋，當然思路還是比較清晰的
從上面這個圖，是否能抓住整個技術派的業務模塊？是否能確定業務模塊的定位（哪些偏業務屬性，哪些偏技術屬性）？是否能確定不同角色的側重點？
能滿足上面三個點，和其他人進行溝通時，不會產生歧義即可；當然上面這個圖是缺少交互方案的，通常在業務架構圖中，不太會整這個，有放在細節里進行鋪開，也有放在詳細設計中的
3.2 業務架構圖
接下來看一下技術派最終定稿的整體業務架構圖，如下：
再看一下前后臺的業務拆分
最后再看一下技術派的技術架構圖
4. 小結
這一篇不算是正規的技術架構方案說明書，更多的是將整個方案的落地過程給大家刨析了一遍，算是拋磚引玉，希望可以給大家今后寫架構方案提供一點幫助。
現在總結的方案設計思路如下：
是不是還沒看爽？
