課程簡介
分布式體系架構設計工作坊通過架構設計實戰(zhàn)貫穿整個培訓
目標收益
通過一個完整案例演練貫穿整個架構設計過程，內容涉及：
需求與架構目標的識別 RAIDs架構驅動方法 技術選型與決策 CQRS模式 系統一致性 領域驅動的戰(zhàn)略設計 六邊形架構 微服務架構的服務分解 架構演進
Clean Architecture思想 技術雷達
培訓對象
課程大綱
| 需求 | 搭建一個技術部落，將與IT、互聯網、數字領域相關的人、部落（業(yè)務、社區(qū)、 興趣組等）和內容聯系起來，提供一個分享與交流的途徑。在最基本的層面上， 它是一個本地的博客、微博、微信文章、開源代碼、活動、講座、工作以及更多 內容的聚合器。 |
| 業(yè)務需求 |
普通用戶可以通過微信、微博等社交賬號登錄 VIP企業(yè)用戶需提供注冊信息，并交納規(guī)定的服務費用 若用戶設置了相關賬戶信息，則個人信息上可以顯示微博動態(tài)、Github提 交記錄等 注冊用戶可以創(chuàng)建新的技術部落 注冊用戶可以申請成為技術部落會員 技術部落會員可以在技術部落中分享內容 技術部落會員可以關注/收藏自己感興趣的內容 技術部落會員可以組織線上講座，進行網絡直播。網絡直播分為公益直播 與收費直播 網絡直播視頻存儲在系統服務器上，提供回看功能 注冊用戶可以發(fā)布活動事件 注冊用戶可以發(fā)布求職信息 VIP企業(yè)用戶可以發(fā)布招聘信息 注冊用戶可以關注自己感興趣的活動，關注后，系統會及時通知活動情況 注冊用戶可以對技術部落中的文章、活動、直播視頻、工作以及用戶進行 全文本搜索 為部落與用戶制定積分政策，并根據最近七天的分數滾動計算出最活躍排 行榜 對整個系統中關注度高、相關度的文章進行智能推薦 為VIP企業(yè)用戶提供人才推薦功能 除收費服務外，其余功能皆提供廣告點擊服務 |
| 質量屬性需求 |
系統分為移動APP與Web應用 滿足10萬PV的并發(fā)請求 用戶閱讀分享內容的響應時間不超過2s 閱讀的內容經過系統的格式化 文章推薦服務的準確度達到60%的準確度 人才推薦服務的準確度達到80%的準確度 網絡直播的并發(fā)訪問量能夠支持10萬級別，并保證直播的播放質量 全文本搜索的響應時間不超過5s |
| 第一次演練：架構目標與范圍 |
分析需求，明確整個系統的用戶角色，定義系統的宏觀邊界，并找出與之相關的 第三方系統。 知識點： 架構與分布式架構的概念 System Context |
| 第二次演練：RAIDs分析 |
RAIDs分析即識別整個系統的風險（Risk）、假設（Assumption）、問題 （Issue）與依賴（Dependency）。分析出來這些內容將成為架構設計的驅動 力，作為技術選型與決策的輸入。 在進行RAIDs分析之后，團隊應就識別出來的風險（問題）優(yōu)先級達成一致意 見，并給出相對具體的架構原則；而假設與依賴則可以視為架構設計的約束。 知識點： RAIDs分析 |
| 第三次演練：技術選型 |
結合著系統需求與RAIDs分析出來的結果，我們需要針對分布式架構的同步消息 調用、異步消息調用等諸多方面進行技術選型。 在進行技術選型時，應根據具體的需求場景、質量屬性、團隊人員能力等諸多方 面進行考量，并利用Technical Matric的方法進行評估，幫助決策。 實戰(zhàn)： 針對RPC框架進行技術Spike 針對數據庫進行技術Spike |
| 第四次演練：關鍵因素分析 |
分離的原則 REST架構風格 CQRS架構模式 系統的高性能 分布式系統的一致性 |
| 第五次演練：領域驅動與微服務 |
領域邏輯的分離應遵循“高內聚松耦合”原則，這一分離原則尤其針對于微服務設 計。在進行服務設計時，引入領域驅動設計（Domain Driven Design）的知 識，通過識別Bounded Context進行微服務設計。 知識點： Bounded Context Context Map 六邊形架構 微服務設計原則 |
| 第六次演練：架構演進 |
技術部落的需求發(fā)生了變化，要求增加如下功能： 通過網絡爬蟲挖掘技術網站文章，根據部落主題進行文章推薦； 為注冊會員提供博客系統，用戶只需要在本地編寫Markdown文件，并進 行同步，即可自動更新博客； 提供對主要招聘網站包括LinkedIn、100Offer等網站的集成，實時更新 招聘信息； 如何在現有架構下應對需求變化，并對架構進行演進式設計。 |
| 工作坊總結 |
Clean Architecture思想 Clean Architecture提出的模型是一個可測試的模型，無需依賴于任何基礎 設施就可以對它進行測試，只需通過邊界對象發(fā)送和接收對應的數據結構即可。 它們都遵循穩(wěn)定依賴原則 ，不對變化或易于變化的事物形成依賴。 |
| 技術雷達 | 針對整個分布式系統架構設計，從原則、模式、框架、工具四個角度設計技術雷 達。 |
|
需求 搭建一個技術部落，將與IT、互聯網、數字領域相關的人、部落（業(yè)務、社區(qū)、 興趣組等）和內容聯系起來，提供一個分享與交流的途徑。在最基本的層面上， 它是一個本地的博客、微博、微信文章、開源代碼、活動、講座、工作以及更多 內容的聚合器。 |
|
業(yè)務需求 普通用戶可以通過微信、微博等社交賬號登錄 VIP企業(yè)用戶需提供注冊信息，并交納規(guī)定的服務費用 若用戶設置了相關賬戶信息，則個人信息上可以顯示微博動態(tài)、Github提 交記錄等 注冊用戶可以創(chuàng)建新的技術部落 注冊用戶可以申請成為技術部落會員 技術部落會員可以在技術部落中分享內容 技術部落會員可以關注/收藏自己感興趣的內容 技術部落會員可以組織線上講座，進行網絡直播。網絡直播分為公益直播 與收費直播 網絡直播視頻存儲在系統服務器上，提供回看功能 注冊用戶可以發(fā)布活動事件 注冊用戶可以發(fā)布求職信息 VIP企業(yè)用戶可以發(fā)布招聘信息 注冊用戶可以關注自己感興趣的活動，關注后，系統會及時通知活動情況 注冊用戶可以對技術部落中的文章、活動、直播視頻、工作以及用戶進行 全文本搜索 為部落與用戶制定積分政策，并根據最近七天的分數滾動計算出最活躍排 行榜 對整個系統中關注度高、相關度的文章進行智能推薦 為VIP企業(yè)用戶提供人才推薦功能 除收費服務外，其余功能皆提供廣告點擊服務 |
|
質量屬性需求 系統分為移動APP與Web應用 滿足10萬PV的并發(fā)請求 用戶閱讀分享內容的響應時間不超過2s 閱讀的內容經過系統的格式化 文章推薦服務的準確度達到60%的準確度 人才推薦服務的準確度達到80%的準確度 網絡直播的并發(fā)訪問量能夠支持10萬級別，并保證直播的播放質量 全文本搜索的響應時間不超過5s |
|
第一次演練：架構目標與范圍 分析需求，明確整個系統的用戶角色，定義系統的宏觀邊界，并找出與之相關的 第三方系統。 知識點： 架構與分布式架構的概念 System Context |
|
第二次演練：RAIDs分析 RAIDs分析即識別整個系統的風險（Risk）、假設（Assumption）、問題 （Issue）與依賴（Dependency）。分析出來這些內容將成為架構設計的驅動 力，作為技術選型與決策的輸入。 在進行RAIDs分析之后，團隊應就識別出來的風險（問題）優(yōu)先級達成一致意 見，并給出相對具體的架構原則；而假設與依賴則可以視為架構設計的約束。 知識點： RAIDs分析 |
|
第三次演練：技術選型 結合著系統需求與RAIDs分析出來的結果，我們需要針對分布式架構的同步消息 調用、異步消息調用等諸多方面進行技術選型。 在進行技術選型時，應根據具體的需求場景、質量屬性、團隊人員能力等諸多方 面進行考量，并利用Technical Matric的方法進行評估，幫助決策。 實戰(zhàn)： 針對RPC框架進行技術Spike 針對數據庫進行技術Spike |
|
第四次演練：關鍵因素分析 分離的原則 REST架構風格 CQRS架構模式 系統的高性能 分布式系統的一致性 |
|
第五次演練：領域驅動與微服務 領域邏輯的分離應遵循“高內聚松耦合”原則，這一分離原則尤其針對于微服務設 計。在進行服務設計時，引入領域驅動設計（Domain Driven Design）的知 識，通過識別Bounded Context進行微服務設計。 知識點： Bounded Context Context Map 六邊形架構 微服務設計原則 |
|
第六次演練：架構演進 技術部落的需求發(fā)生了變化，要求增加如下功能： 通過網絡爬蟲挖掘技術網站文章，根據部落主題進行文章推薦； 為注冊會員提供博客系統，用戶只需要在本地編寫Markdown文件，并進 行同步，即可自動更新博客； 提供對主要招聘網站包括LinkedIn、100Offer等網站的集成，實時更新 招聘信息； 如何在現有架構下應對需求變化，并對架構進行演進式設計。 |
|
工作坊總結 Clean Architecture思想 Clean Architecture提出的模型是一個可測試的模型，無需依賴于任何基礎 設施就可以對它進行測試，只需通過邊界對象發(fā)送和接收對應的數據結構即可。 它們都遵循穩(wěn)定依賴原則 ，不對變化或易于變化的事物形成依賴。 |
|
技術雷達 針對整個分布式系統架構設計，從原則、模式、框架、工具四個角度設計技術雷 達。 |
近期公開課推薦
