（二）架构基础知识
軟件設(shè)計原則與分層
軟件設(shè)計原則
單一職責(zé)原則
永遠不應(yīng)該有多余一個原因來改變某個類
理解：對于一個類而言，應(yīng)該僅有一個引起它變化的原因
應(yīng)用：如果一個類擁有了兩種職責(zé)，那就可以將這個類分成兩個類
開放封閉原則
軟件實體擴展應(yīng)該是開放的，但對于修改應(yīng)該是封閉的
理解：對擴展開放，對修改封閉，可以去擴展類，但不要去修改類
應(yīng)用：當(dāng)需求有改動，盡量用繼承或組合的方式來擴展類的功能，而不是直接修改類的代碼
里氏替換原則
理解：父類一定能夠被子類替換
最少知識原則
只與你最直接的對象交流
理解：低耦合，高內(nèi)聚
應(yīng)用：做系統(tǒng)設(shè)計時，盡量減少依賴關(guān)系
接口隔離原則
一個類與另一個類之間的依賴性，應(yīng)該依賴于盡可能小的接口
理解：不要對外暴露沒有實際意義的接口。用戶不應(yīng)該依賴它不需要的接口
應(yīng)用：當(dāng)需要對外暴露接口時，如果是非必要對外提供，盡量刪除
依賴倒置原則
高層模塊不應(yīng)該依賴低層模塊，它們應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象
理解：應(yīng)該面向接口編程，不應(yīng)該面向?qū)崿F(xiàn)類編程
并不是說，所有的類都要有一個對應(yīng)的接口，而是說，如果有接口，那就盡量使用接口來編程吧
總結(jié)
將以上六大原則的英文首字母拼在一起就是SOLID（穩(wěn)定的），所以也稱之為SOLID原則
只有滿足了這六大原則，才能設(shè)計出穩(wěn)定的軟件架構(gòu)！
補充設(shè)計原則
- 組合/聚合復(fù)用原則
當(dāng)要擴展類的功能時，優(yōu)先考慮使用組合，而不是繼承
該原則在23中典型設(shè)計模式中頻繁使用
如：代理模式、裝飾模式、適配器模式等 - 無環(huán)依賴原則
當(dāng)A模塊依賴于B模塊，B模塊依賴于C模塊，C模塊依賴于A模塊，此時將出現(xiàn)循環(huán)依賴
在設(shè)計中避免該問題，可通過引入“中介者模式”解決 - 共同封裝原則
應(yīng)該將易變的類放在同一個包里，將變化隔離出來
該原則是“開放-封閉原則”的誕生 - 共同重用原則
如果重用了包中的一個類，那么也就相當(dāng)于重用了包中的所有類，我們要盡可能減少包的大小 - 好萊塢原則
Don"t call me, I"ll call you
“控制反轉(zhuǎn)”（或稱為“依賴注入”）
不需要主動創(chuàng)建對象，而是由容器幫我們來創(chuàng)建并管理這些對象 - 不重復(fù)原則
不要讓重復(fù)的代碼到處都是，要讓它們足夠的重用，所以要盡可能地封裝 - 保持它簡單與傻瓜
保持系統(tǒng)界面簡潔，功能實用，操作方便 - 高內(nèi)聚與低耦合
模塊內(nèi)部需要做到內(nèi)聚度高，模塊之間需要做到耦合度低 - 關(guān)注點分離
將一個復(fù)雜的問題分離為多個簡單的問題，然后逐個解決
難點：如何進行分離 - 你不需要它
不要一開始就把系統(tǒng)設(shè)計得非常復(fù)雜，不要陷入“過度設(shè)計”的深淵
讓系統(tǒng)足夠簡單，而不失擴展性
軟件設(shè)計分層
架構(gòu)種類分為：系統(tǒng)級架構(gòu)、應(yīng)用級架構(gòu)、代碼級架構(gòu)、模塊級架構(gòu)
系統(tǒng)級架構(gòu)
應(yīng)用在整個系統(tǒng)內(nèi)，如后臺服務(wù)如何通信，與第三方系統(tǒng)如何集成
設(shè)計前端首要條件：了解前端系統(tǒng)與其他系統(tǒng)之間的關(guān)系
關(guān)系包括：業(yè)務(wù)關(guān)系和協(xié)作機制
設(shè)計后端：只需要規(guī)定與后臺數(shù)據(jù)傳遞的機制
包括：api設(shè)計規(guī)則，訪問授權(quán)的一個開放標(biāo)準(zhǔn)（OAuth）跳轉(zhuǎn)token的驗證，數(shù)據(jù)傳遞cookie等。
前端和后端的關(guān)系考慮的主要因素是：前后端分離的架構(gòu)設(shè)計。
前后端分離架構(gòu)其實是如何實施技術(shù)決策，用戶鑒權(quán)、API接口管理和設(shè)計、API文檔管理、Mock的使用、BFF（服務(wù)于前端的后端，nodejs），是否需要服務(wù)端渲染等
微前端
在一個系統(tǒng)內(nèi)微前端是應(yīng)用間的架構(gòu)方案
在多個應(yīng)用之間，微前端則是一種系統(tǒng)間等架構(gòu)方案
微前端是將多個前端應(yīng)用以某種形式結(jié)合在一起進行應(yīng)用
旨在解決單體應(yīng)用在一個相對長的時間跨度下，由于參與的人員、團隊的增多、變遷，從一個普通應(yīng)用演變成一個巨石應(yīng)用（Frontend Monolith）后，隨之而來的應(yīng)用不可維護的問題。
單實例：即同一時刻，只有一個子應(yīng)用被展示，子應(yīng)用具備一個完整的應(yīng)用生命周期
多實例：通常基于url的變化來做子應(yīng)用的切換。
多實例子：同一時刻可展示多個子應(yīng)用。
通常使用Web Components方案來做子應(yīng)用封裝，子應(yīng)用更像是一個業(yè)務(wù)組件而不是應(yīng)用
應(yīng)用級架構(gòu)
應(yīng)用級架構(gòu)可以看作是系統(tǒng)級架構(gòu)的細化
單個應(yīng)用與其他外部應(yīng)用的關(guān)系，微服務(wù)架構(gòu)下多個應(yīng)用的協(xié)作，數(shù)據(jù)交換等
腳手架、模式庫、設(shè)計系統(tǒng)
模塊級架構(gòu)
這部分內(nèi)容是我們開始業(yè)務(wù)編碼之前進行設(shè)計，我們稱為迭代。
代碼級架構(gòu)
規(guī)范與原則
實操
開發(fā)流程
代碼質(zhì)量以及改善
規(guī)范而非默契
注：
在開發(fā)中，要注意可維護性
簡單的代碼可維護性高，越是寫的抽象的代碼越難維護
如何保證架構(gòu)的質(zhì)量
系統(tǒng)的穩(wěn)定性
定義：當(dāng)一個實際的系統(tǒng)處于一個平衡的狀態(tài)時，如果受到外來作用的影響時，系統(tǒng)經(jīng)過一個過濾過程仍然能夠回到原來的平衡狀態(tài)，我們就稱這個系統(tǒng)就是穩(wěn)定的，否則稱系統(tǒng)不穩(wěn)定
架構(gòu)設(shè)計的基石
可以更好的實現(xiàn)自我修復(fù)
系統(tǒng)的健壯性
定義：計算機軟件在輸入錯誤、磁盤故障、網(wǎng)絡(luò)過載或有意攻擊情況下，能否不死機、不崩潰，就是該軟件健壯性的具體表現(xiàn)。
解釋：一個系統(tǒng)容錯能力強，運行不易被干擾，安全性好
系統(tǒng)的健壯性的度量標(biāo)準(zhǔn)
一個軟件可以從錯誤的輸入推斷出正確合理的輸入
一個軟件可以正確的運行在不同環(huán)境下
一個軟件能夠檢測自己內(nèi)部的設(shè)計或者編碼錯誤，并得到正確的結(jié)果
系統(tǒng)的健壯性和穩(wěn)定性
健壯性和穩(wěn)定性是特定的軟件自身的要求
健壯性和穩(wěn)定性是軟件處理的一部分
軟件架構(gòu)的健壯性和穩(wěn)定性是該軟件規(guī)劃時所確定的目標(biāo)
若軟件的實現(xiàn)未達原定目標(biāo)，則該軟件的健壯性和穩(wěn)定性不夠或不好
架構(gòu)質(zhì)量的衡量
擴展性
可管理
維護性
高可用（故障修復(fù)、容災(zāi)、降級、熔斷）
日常開發(fā)過程中的架構(gòu)質(zhì)量
理解難度
崩潰率和錯誤率的指標(biāo)
接入依賴的成本
開發(fā)效率
錯誤上報和信息收集等功能
架構(gòu)前期準(zhǔn)備
架構(gòu)師分類
系統(tǒng)架構(gòu)師，應(yīng)用架構(gòu)師、業(yè)務(wù)架構(gòu)師
系統(tǒng)架構(gòu)師
從系統(tǒng)的維度，負責(zé)整體系統(tǒng)的架構(gòu)設(shè)計
主要是基礎(chǔ)服務(wù)和各系統(tǒng)間協(xié)調(diào)，著眼全局
比如關(guān)注負載，可靠性，伸縮，擴展，整體項目切分，緩存應(yīng)用等方面的基礎(chǔ)架構(gòu)設(shè)計
應(yīng)用架構(gòu)師
從應(yīng)用程序的維度，負責(zé)某個應(yīng)用的技術(shù)架構(gòu)，主要偏業(yè)務(wù)系統(tǒng)
關(guān)注理解業(yè)務(wù)，梳理模型，設(shè)計模式，接口，數(shù)據(jù)交互等方面
業(yè)務(wù)架構(gòu)師
從業(yè)務(wù)流程的維度，關(guān)注某一個行業(yè)、業(yè)務(wù)的領(lǐng)域分析，獲取領(lǐng)域模型，最終獲得系統(tǒng)的模型
也可以叫業(yè)務(wù)領(lǐng)域?qū)＜摇⑿袠I(yè)專家、產(chǎn)品咨詢師、資深顧問
技術(shù)前期準(zhǔn)備
技術(shù)選型：社區(qū)氛圍、發(fā)展規(guī)律、未來發(fā)展趨勢、與當(dāng)前團隊的契合度、執(zhí)行成本、維護和遷移成本、執(zhí)行效率等內(nèi)容的調(diào)研和報告
充分調(diào)研每一項技術(shù)可能帶來的利與弊
最大程度上預(yù)測架構(gòu)設(shè)計中的缺陷，以防止問題的發(fā)生
技術(shù)優(yōu)化
在架構(gòu)發(fā)展過程中，可能會存在一些有悖于當(dāng)前架構(gòu)設(shè)計的實現(xiàn)，造成了架構(gòu)發(fā)展阻塞，所以需要進行架構(gòu)優(yōu)化，使架構(gòu)設(shè)計的適應(yīng)性更高
架構(gòu)不是一蹴而就的，在業(yè)務(wù)發(fā)展過程中，架構(gòu)也在不斷演進
對架構(gòu)設(shè)計進行實時調(diào)優(yōu)，使架構(gòu)優(yōu)化成為常態(tài)化
通過不斷的調(diào)整架構(gòu)實現(xiàn)，改進初始架構(gòu)中設(shè)計的不足，補足短板
技術(shù)填補與崩潰預(yù)防
技術(shù)填補-問題1
開發(fā)過程中因為時間緊迫導(dǎo)致的實現(xiàn)不合理
舉例：查找10000以內(nèi)的質(zhì)數(shù)
循環(huán)的方式。帥選法
技術(shù)填補-問題2
暫時沒有想到更好的實現(xiàn)方式而妥協(xié)的版本
剛開始使用if…else實現(xiàn)
演變?yōu)槭褂秘?zé)任鏈模式
技術(shù)填補-問題3
架構(gòu)設(shè)計前期沒有考慮到的細節(jié)
交互細節(jié)->props傳遞參數(shù)（交互冗余，流程較長）
使用全局狀態(tài)管理實現(xiàn)參數(shù)傳遞
技術(shù)填補-問題4
不合理的交互設(shè)計，導(dǎo)致技術(shù)實現(xiàn)復(fù)雜
技術(shù)填補-問題5
舊功能文檔缺失，無正確擴展，修改和兼容舊功能，導(dǎo)致上線后問題劇增
技術(shù)填補-后果1
修復(fù)變重構(gòu)
小的技術(shù)債務(wù)不做償還，最后會演變成一場大規(guī)模的重構(gòu)工作，導(dǎo)致產(chǎn)出不高
技術(shù)填補-后果2
影響開發(fā)速度
技術(shù)債務(wù)的存在導(dǎo)致整體開發(fā)需要兼容的點過多，影響開發(fā)效率，極大影響上線速度，導(dǎo)致整體項目迭代緩慢，失去核心競爭力
技術(shù)填補-后果3
容易陷入維護舊功能-開發(fā)新功能-兼容舊功能-維護舊功能-開發(fā)新功能。。。這樣的惡性循環(huán)
技術(shù)填補-解決方案1
優(yōu)秀的架構(gòu)設(shè)計是基礎(chǔ)
必須能夠有效處理當(dāng)前需求可預(yù)見的情況，對于未知的、可能出現(xiàn)的特殊情況，很小的改動就能解決問題
根據(jù)當(dāng)前的業(yè)務(wù)，進行合理的項目拆分，盡量的代碼解耦和
必須有日志模塊，操作日志，錯誤日志，業(yè)務(wù)日志等等
技術(shù)填補-解決方案2
良好的技術(shù)培訓(xùn)和傳幫帶能力
讓每一位開發(fā)者可以從更深一層次理解自己所需要實現(xiàn)的功能
從最開始的代碼規(guī)范、到熟悉業(yè)務(wù)、最好再到編寫文檔
技術(shù)填補-解決方案3
充分的技術(shù)方案可避免一部分技術(shù)債務(wù)的產(chǎn)生
技術(shù)方案是充分理解需求之后所能產(chǎn)出的對需求理想的實現(xiàn)方式，必要性不言而喻
技術(shù)填補-解決方案4
不同工程師之前可以相互review
CodeReview是非常重要的，同時也是對自身的一個提高
技術(shù)填補-解決方案5
提升對修復(fù)技術(shù)債務(wù)重要性的認知
工程師如果能預(yù)見一個債務(wù)可能導(dǎo)致的問題，自然愿意花時間去處理
技術(shù)填補-解決方案6
善于發(fā)現(xiàn)和定期處理一些技術(shù)債務(wù)
勇于發(fā)現(xiàn)系統(tǒng)中的技術(shù)債務(wù)，讓自己為系統(tǒng)負責(zé)
總結(jié)
等產(chǎn)品上線后，開發(fā)就沒有那么緊啦，這個時間大家可以找個時間處理技術(shù)債務(wù)，一邊建立感情，一邊品味下原來的代碼，這種感覺極其酸爽
預(yù)防架構(gòu)崩潰
架構(gòu)崩潰是嚴(yán)重的架構(gòu)設(shè)計事故，也是我們需要預(yù)防的關(guān)鍵所在
1.系統(tǒng)崩潰的產(chǎn)生
2.日志記錄：如操作日志，錯誤日志，業(yè)務(wù)日志等
崩潰預(yù)防
用戶行為抓去》爭取在最新時間獲取到用戶操作鏈條
解決存量問題〉技術(shù)債務(wù)
遏制新增》減少新增問題的概率
對臟數(shù)據(jù)進行兜底和檢驗
單元測試
崩潰報警
自動化測試
更廣的灰度觸達
性能優(yōu)化體系
系統(tǒng)重構(gòu)
架構(gòu)不是永恒不變的。架構(gòu)也是具有生命周期的，也會經(jīng)歷初生、發(fā)展、巔峰、衰弱、消亡的過程
重構(gòu)是對軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本
實現(xiàn)方式：使用一系列重構(gòu)手法，在不改變軟件可觀察行為的前提下，調(diào)整其結(jié)構(gòu)
重構(gòu)理念：運用大量微小且保持軟件行為的步驟，一步步達到大規(guī)模的修改
早期系統(tǒng)優(yōu)勢
開發(fā)速度快
代碼復(fù)雜度低
代碼規(guī)范都保持完好
嚴(yán)格注重開發(fā)規(guī)范，不會允許危及架構(gòu)設(shè)計的代碼產(chǎn)生
以上因素導(dǎo)致添加功能難度低，成本低
晚期系統(tǒng)
具備所有早期系統(tǒng)的劣勢
代碼復(fù)雜度高
代碼規(guī)范不完善
很多需求或功能出現(xiàn)逾越架構(gòu)設(shè)計的情況
添加新功能兼顧較多，涉及較多模塊，牽一發(fā)而動全身
當(dāng)發(fā)現(xiàn)一個現(xiàn)有架構(gòu)體系已經(jīng)不能滿足當(dāng)前迭代速度的時候就需要進行重構(gòu)工作
重構(gòu)流程
微重構(gòu)
對與壞味道的代碼通過一些重構(gòu)手段進行微重構(gòu)
確定問題點，確定重構(gòu)功能和范圍》舊架構(gòu)設(shè)計和邏輯梳理〉穩(wěn)定性保證》性能保證〉需求過程中的沖突問題
微前端實現(xiàn)方式對比
Iframe
優(yōu)勢：
技術(shù)成熟、支持頁面嵌入、天然支持運行沙箱隔離、獨立運行
劣勢：
頁面之間可以是不同的域名
需要對應(yīng)的設(shè)計一套應(yīng)用通訊機制，如何監(jiān)聽，傳參格式等內(nèi)容
web component
優(yōu)勢：
支持自定義元素
支持shadow dom ，可通過關(guān)聯(lián)進行控制
支持模版template和插槽slot，引入自定義組件內(nèi)容
劣勢
接入微前端需要重寫當(dāng)前項目
生態(tài)系統(tǒng)不完善，技術(shù)過新容易出現(xiàn)兼容性問題
整體架構(gòu)設(shè)計復(fù)雜，組件與組件之間拆分過細時，容易造成通訊和控制繁瑣
自研框架
優(yōu)勢
高度定制化。滿足需要做兼容的一切場景
獨立的通信機制和沙箱運行環(huán)境，可解決應(yīng)用直接相互影響的問題
支持不同技術(shù)棧子應(yīng)用，可無縫實現(xiàn)頁面無刷新渲染
劣勢
技術(shù)實現(xiàn)難度較高
需要設(shè)計一套定制的通信機制
首次加載會出現(xiàn)資源過大的情況
最終實現(xiàn)-自研框架
路由分發(fā)式
主應(yīng)用控制路由匹配和子應(yīng)用加載，共享依賴加載
子應(yīng)用做功能，并接入主應(yīng)用實現(xiàn)主子控制和聯(lián)動
確定技術(shù)棧
應(yīng)用：主應(yīng)用、子應(yīng)用、后端服務(wù)和發(fā)布應(yīng)用
主應(yīng)用-選定vue3技術(shù)棧：vue2，vue3，react，angular，jquery，原生javascript
vue2子應(yīng)用：實現(xiàn)新能源頁面
vue3子應(yīng)用：首頁、選車
react15子應(yīng)用：資訊、視頻、視頻詳情
react16子應(yīng)用：新車、排行、登錄
服務(wù)端接口：koa實現(xiàn)
發(fā)布應(yīng)用：express
1.主應(yīng)用
注冊子應(yīng)用
加載、渲染子應(yīng)用
路由匹配（activeWhen、rules - 由框架判斷）
獲取數(shù)據(jù)（公共依賴、通過數(shù)據(jù)做鑒權(quán)處理）
通信（父子通信，子父通信）
2.子應(yīng)用的功能
渲染
監(jiān)聽通信（主應(yīng)用傳遞過來的數(shù)據(jù)）
3.微前端框架
子應(yīng)用的注冊
有開始內(nèi)容（應(yīng)用加載完成，）
路由更新判斷
匹配對應(yīng)的子應(yīng)用
加載子應(yīng)用的內(nèi)容
完成所有依賴項的執(zhí)行
將子應(yīng)用渲染在固定容器內(nèi)
公共事件的管理
異常的捕獲和報錯
全局的狀態(tài)管理的內(nèi)容
沙箱的隔離
通信機制
4.服務(wù)端的功能
提供數(shù)據(jù)服務(wù)
5.發(fā)布平臺
主子引用的打包和發(fā)布
總結(jié)
- 上一篇： 联想拯救者 R9000X 2023 笔记
- 下一篇： 对话周枫：发布教育领域垂直大模型“子曰”