課程簡介
課程可以掌握基本的架構思維和架構原則,以及常用的架構模式,能夠根據特定的場景和問題進行合理的架構設計,在防止過度設計的同時,還能保持架構的可持續(xù)演進;學員在掌握真正高可用架構的思維和實戰(zhàn)方法的同時,更能清晰的知道一個架構從高可用到不可用的路徑上都發(fā)生了什么,以及如何防范,如何在實踐中進行架構的防腐;為學員展示當前一線大廠好的設計和不好的設計的真實案例,并能夠從案例中去映射高可用和不可用的場景,并總結出實戰(zhàn)經驗和教訓的規(guī)范指導。
目標收益
1、掌握基本的架構思維和架構設計原則,同時洞悉高可用架構的本質,并可以掌握設計高可用架構的能力,以及掌握最優(yōu)代碼落地的能力;
2、能夠根據特定的場景和問題進行合理的架構設計,掌握如何拉近問題和架構方案的距離的能力,以及在防止過度設計的同時,還能保持架構可以持續(xù)演進;
3、能清晰的知道一個架構從高可用到不可用的路徑上都發(fā)生了什么,以及如何防范,如何防腐,最后還可以洞悉當前一線大廠的真實案例。
4、能理解組織和人的因素對架構及線上環(huán)境的影響,以及如何在現有的組織架構下有效的讓價格設計發(fā)貨最大的作用;
培訓對象
3-5年工作經驗以上高級開發(fā)人員和架構師;
課程大綱
一、高可用設計:架構設計后如何一步步落地 1.1、架構的智慧 |
架構的價值 架構的終極目標是什么 架構的質量受哪些因素影響 如何縮短問題和解決方案的距離 如何做到整潔架構的向內設計 架構設計時不要忘記業(yè)務-不要讓架構綁架業(yè)務 架構老化與重構 到底哪些工作是架構師的職責 研發(fā)團隊在企業(yè)組織中的價值是什么 |
1.2、宏觀:如何實踐微服務 |
服務拆分的四大時機 服務拆分的六大規(guī)范 服務拆分的四大阻礙 不能忽視的越權訪問 如何利用測試金字塔模型 如何利用消費者驅動契約測試 如何利用數據庫優(yōu)化金字塔模型 如何做服務治理 |
1.3、微觀:代碼落地保障 |
設計模式和設計原則如何選 如何應用SOLID原則 如何應用KISS原則 不能只做結構化編程 什么情下你沒有在執(zhí)行OO思想 依賴倒置不止于面向抽象 代碼分層的邏輯 如何做接口設計 如何做緩存設計 如何寫出一份優(yōu)雅的設計文檔 如何讓別人舒服的閱讀自己的代碼 如何讓自己舒服的閱讀別人的代碼 |
二、架構腐化:高可用架構又如何一步步變的不可用了 2.1、高可用的本質 |
主從結構的邏輯 擴展立方體要指導我們做什么 如何做到變更速度和變更原因的分離 如何劃分服務之間的邊界 同步和異步如何選 一次RPC調用時間都去哪兒了 案例:一個可擴展的架構演變 |
2.2、架構的熵增 |
是什么讓架構變的無序 如何執(zhí)行演進式架構 如何落地六邊形架構 如何做無狀態(tài)的架構 你必須要知道的腦裂問題 空間與時間維度的解耦 如何最大化利用MQ集群性能 混沌工程實踐 |
2.3、線上常見問題解析 |
線上故障畫像 故障TOP場景 系統(tǒng)常用容錯方法 不可用案例: 一味的向上擴展 未分清變更速度和變更原因 軟件工程師的自我欺騙 進行向外依賴的設計 API業(yè)務組合放到了網關內部 狀態(tài)阻礙了擴展 理想化的一步到位拆分 忽略了越權訪問 未遵循測試金字塔模型 敏捷型組織錯位 忽略了故障神經線 人造肉雞:客戶端重試 局部故障:快速失敗失效 局部故障:未做線程池隔離 未遵循數據庫優(yōu)化金字塔模型 熱點KEY觸發(fā)單點限流 分布式流控失效 未把故障和問題區(qū)分開 未區(qū)分部署和上線 認為異步是萬能的 |
一、高可用設計:架構設計后如何一步步落地 1.1、架構的智慧 架構的價值 架構的終極目標是什么 架構的質量受哪些因素影響 如何縮短問題和解決方案的距離 如何做到整潔架構的向內設計 架構設計時不要忘記業(yè)務-不要讓架構綁架業(yè)務 架構老化與重構 到底哪些工作是架構師的職責 研發(fā)團隊在企業(yè)組織中的價值是什么 |
1.2、宏觀:如何實踐微服務 服務拆分的四大時機 服務拆分的六大規(guī)范 服務拆分的四大阻礙 不能忽視的越權訪問 如何利用測試金字塔模型 如何利用消費者驅動契約測試 如何利用數據庫優(yōu)化金字塔模型 如何做服務治理 |
1.3、微觀:代碼落地保障 設計模式和設計原則如何選 如何應用SOLID原則 如何應用KISS原則 不能只做結構化編程 什么情下你沒有在執(zhí)行OO思想 依賴倒置不止于面向抽象 代碼分層的邏輯 如何做接口設計 如何做緩存設計 如何寫出一份優(yōu)雅的設計文檔 如何讓別人舒服的閱讀自己的代碼 如何讓自己舒服的閱讀別人的代碼 |
二、架構腐化:高可用架構又如何一步步變的不可用了 2.1、高可用的本質 主從結構的邏輯 擴展立方體要指導我們做什么 如何做到變更速度和變更原因的分離 如何劃分服務之間的邊界 同步和異步如何選 一次RPC調用時間都去哪兒了 案例:一個可擴展的架構演變 |
2.2、架構的熵增 是什么讓架構變的無序 如何執(zhí)行演進式架構 如何落地六邊形架構 如何做無狀態(tài)的架構 你必須要知道的腦裂問題 空間與時間維度的解耦 如何最大化利用MQ集群性能 混沌工程實踐 |
2.3、線上常見問題解析 線上故障畫像 故障TOP場景 系統(tǒng)常用容錯方法 不可用案例: 一味的向上擴展 未分清變更速度和變更原因 軟件工程師的自我欺騙 進行向外依賴的設計 API業(yè)務組合放到了網關內部 狀態(tài)阻礙了擴展 理想化的一步到位拆分 忽略了越權訪問 未遵循測試金字塔模型 敏捷型組織錯位 忽略了故障神經線 人造肉雞:客戶端重試 局部故障:快速失敗失效 局部故障:未做線程池隔離 未遵循數據庫優(yōu)化金字塔模型 熱點KEY觸發(fā)單點限流 分布式流控失效 未把故障和問題區(qū)分開 未區(qū)分部署和上線 認為異步是萬能的 |