如何一步步設(shè)計前端架構(gòu)？

時間：2023-09-11 14:18:01 | 來源：網(wǎng)站運(yùn)營

時間：2023-09-11 14:18:01 來源：網(wǎng)站運(yùn)營

如何一步步設(shè)計前端架構(gòu)？：前端有架構(gòu)嗎？前端有架構(gòu)模式嗎？

架構(gòu)是什么？

軟件架構(gòu)，是一種為了解決復(fù)雜問題的通用模式。軟件架構(gòu)，是關(guān)于軟件系統(tǒng)的一系列有層次的技術(shù)決策的集合。換句話來說，當(dāng)我們討論架構(gòu)的時候，不能只討論某某架構(gòu)，而是要包含其實施，以及后期的維護(hù)。

因為：

• 一個無法上線的應(yīng)用架構(gòu)，算不上是好的軟件架構(gòu)
• 一個沒有人能完成開發(fā)的軟件架構(gòu)，算不上是可行的軟件架構(gòu)
• 一個在現(xiàn)有的技術(shù)上不可行的架構(gòu)，算不上是合理的軟件架構(gòu)

諸如微服務(wù)，對于復(fù)雜的后端系統(tǒng)來說，是一種不錯的『低耦合，高內(nèi)聚』的實施。但是，它并不適合于大部分的小公司——復(fù)雜的架構(gòu)不適合于簡單的應(yīng)用。而小公司也缺乏足夠的人才，來實施一個復(fù)雜的系統(tǒng)，與此同時還需要有人能維護(hù)這個系統(tǒng)。

所以，當(dāng)我們談及軟件架構(gòu)的時候，說的是：有這么一些人，他/她們能按時、高質(zhì)量（或者說有質(zhì)量）完成這一個系統(tǒng)的設(shè)計——即有能力的個人。

PS：對于前端架構(gòu)來說，這些人大概率會來自于看了本書的人，笑~

前端架構(gòu)拆解：四層次設(shè)計

從筆者的角度來看，架構(gòu)設(shè)計本身是分層級的，面向不同級別的人時，所展示的內(nèi)容也是不一樣的。如面對的是同一級別、更高一級別的架構(gòu)師、技術(shù)人員，說的便是形而上學(xué)的東西，如微前端、前后端分離，并通過各種概念，如構(gòu)建系統(tǒng)拆份，以抽象的方式介紹如何去設(shè)計。這些概念，對于接觸過的程序員來說，也是相當(dāng)好理解的。而當(dāng)我們面對的是，經(jīng)驗略微豐富的程序員的時候，說的可就不是：去實現(xiàn)微前端這樣的東西。而是需要落實到怎樣去做這樣的一件事。

在不同的時期，不同的階段，我們考慮的架構(gòu)相關(guān)的因素是不同的。按照這個思想，筆者將架構(gòu)的設(shè)計分為了四個層級：

系統(tǒng)級，即應(yīng)用在整個系統(tǒng)內(nèi)的關(guān)系，如與后臺服務(wù)如何通訊，與第三方系統(tǒng)如何集成。 應(yīng)用級，即應(yīng)用外部的整體架構(gòu)，如多個應(yīng)用之間如何共享組件、如何通信等。 模塊級，即應(yīng)用內(nèi)部的模塊架構(gòu)，如代碼的模塊化、數(shù)據(jù)和狀態(tài)的管理等。 代碼級，即從基礎(chǔ)設(shè)施來保障架構(gòu)實施。

對應(yīng)的層級與實施模式，如下圖所示：

!前端四個層級

系統(tǒng)內(nèi)架構(gòu)

在設(shè)計前端架構(gòu)的時候，首先考慮的是應(yīng)用在整個系統(tǒng)中的位置——它與系統(tǒng)中的其它子系統(tǒng)是怎樣的。這種關(guān)系包含了架構(gòu)上的關(guān)系、業(yè)務(wù)上的關(guān)系，以及它們之間的協(xié)作機(jī)制。對于前端應(yīng)用來說，這一部分的子系統(tǒng)包含了：

• 其它前端應(yīng)用。側(cè)重于關(guān)注如何與這些應(yīng)用交互，諸如交互、通訊等。
• 對接的后臺服務(wù)。關(guān)注于如何與后臺服務(wù)進(jìn)行通信，諸如權(quán)限、授權(quán)、API 管理等。

若是系統(tǒng)間的數(shù)據(jù)通信，如與后臺服務(wù)之間的交互，那么只需要規(guī)定好數(shù)據(jù)通信、數(shù)據(jù)傳遞的機(jī)制即可。這一類的通訊機(jī)制，不僅僅包含了前后端分離架構(gòu)的 API 設(shè)計，還包含了各類的數(shù)據(jù)傳遞，諸如 OAuth 跳轉(zhuǎn)的 Token 驗證。除此，對于傳統(tǒng)的多頁面應(yīng)用來說，也需要關(guān)注于其中的數(shù)據(jù)傳遞，如 Cookie 作為用戶憑據(jù)等等。

為此，對于前端開發(fā)人員來說，關(guān)于與后端間的關(guān)系，我們所要考慮的主要因素是前后端分離架構(gòu)的設(shè)計。

• 前后端分離架構(gòu)。（詳見《前端架構(gòu)：從入門到微前端》）
• 微前端架構(gòu)。（詳見《前端架構(gòu)：從入門到微前端》）

而后，我們還需要考慮到前端的客戶端展現(xiàn)形式。在大前端的背景之下，它可能是以 PC Web 應(yīng)用、移動 Web 應(yīng)用、混合移動應(yīng)用（結(jié)合 Cordova 構(gòu)架）、混合桌面應(yīng)用（結(jié)合 Electron 框架）、原生移動應(yīng)用（結(jié)合 React Native）等，具體選擇何一種技術(shù)，取決于我們在之前調(diào)查的利益相關(guān)者的需求。

當(dāng)我們做完上述的三個核心的架構(gòu)決策之后，就需要考慮一下應(yīng)用的部署架構(gòu)。不同的客戶端形式，或者需要服務(wù)端渲染，會在某種程度上影響到前端應(yīng)用的部署，但是總的影響并不是太大。往往只需要通過反向代理的配置，就可以完成部署的配置。若是與后臺服務(wù)不在一個域，則需要考慮支持跨域請求或者是后臺做一層代碼。

在有了這些基本的架構(gòu)設(shè)定，便可以往下繼續(xù)設(shè)計下一層級的應(yīng)用架構(gòu)。

應(yīng)用級架構(gòu)

應(yīng)用級架構(gòu)，指的是單個應(yīng)用與外部應(yīng)用的關(guān)系，如微服務(wù)架構(gòu)下的多個應(yīng)用的協(xié)作。它可以是一個團(tuán)隊下的多個前端應(yīng)用，又或者是一個組織內(nèi)的前端應(yīng)用。其在組織中所處的位置，也進(jìn)一步?jīng)Q定了我們所需要設(shè)計的架構(gòu)方案。

若是從相關(guān)的定義上來看，它與系統(tǒng)級應(yīng)用存在一定的交集。但是，筆者將其視之為系統(tǒng)級架構(gòu)的進(jìn)一步細(xì)化。如在系統(tǒng)內(nèi)架構(gòu)的層級里，我們定義了微前端架構(gòu)，而具體的實施細(xì)則會放在各個應(yīng)用中實現(xiàn)的。而諸如應(yīng)用間的數(shù)據(jù)如何交換，而不同的應(yīng)用又有各自不同的實現(xiàn)，則會在這個層級里定義了相應(yīng)的接口。

與此同時，當(dāng)我們維護(hù)了多個前端應(yīng)用，必然會去考慮在這些應(yīng)用之間，復(fù)用代碼、共享組件庫、統(tǒng)一設(shè)計等，以減少相應(yīng)的工作量。為此，在這個層級里，我們會考慮下面的一些架構(gòu)相關(guān)的設(shè)計內(nèi)容：

• 腳手架。（詳見《前端架構(gòu)：從入門到微前端》）
• 模式庫。（詳見《前端架構(gòu)：從入門到微前端》）
• 設(shè)計系統(tǒng)。（詳見《前端架構(gòu)：從入門到微前端》）

與此同時，在這個層級里，我們決定選擇什么前端框架，進(jìn)行相關(guān)的技術(shù)選型。

模塊級架構(gòu)

模塊級架構(gòu)，便是深入單個應(yīng)用內(nèi)部，更細(xì)致的設(shè)計應(yīng)用內(nèi)部的架構(gòu)。它所涉及的部分，便是在日常開發(fā)中，我們經(jīng)常接觸到的主要部分。我們所做的便是制定一些規(guī)范，又或者是更細(xì)致的架構(gòu)設(shè)計。這部分的內(nèi)容，會在我們開始業(yè)務(wù)編碼之前進(jìn)行設(shè)計，在敏捷軟件開發(fā)中，它稱之為 迭代 0/Sprint 0/Iteration 0。相關(guān)的內(nèi)容有：

• 模塊化。（詳見《前端架構(gòu)：從入門到微前端》）
• 組件化。（詳見《前端架構(gòu)：從入門到微前端》）

除此，對于不同的框架，還涉及到一些框架特定的模式與架構(gòu)設(shè)計，它們會在一定程度上影響單個應(yīng)用的架構(gòu)。對于不同的框架來說，所需要涉及的范圍都有所不發(fā)。如在 Angular 框架中，不需要操心相關(guān)的模式，只需要掌握框架定義的規(guī)范即可，如使用 Service 來保存應(yīng)用的狀態(tài)，使用 Pipe 來處理數(shù)據(jù)等。而在 React 框架中，則需要設(shè)計狀態(tài)和數(shù)據(jù)流的管理方式，為此便需要諸如 Flux 或者 Redux 這樣的狀態(tài)管理方案。

代碼級：規(guī)范與原則

當(dāng)我們真正編碼的時候，考慮的架構(gòu)因素便是更低層級的內(nèi)容。這部分的架構(gòu)設(shè)計，便稱為代碼級的架構(gòu)設(shè)計，它關(guān)注于實踐過程中的相關(guān)規(guī)范和原則。這部分的內(nèi)容相當(dāng)?shù)亩啵⑶曳爆?。它包含了以下的?nèi)容，但是又不限于下述的部分：

• 開發(fā)流程。（詳見《前端架構(gòu)：從入門到微前端》）
• 代碼質(zhì)量及改善。（詳見《前端架構(gòu)：從入門到微前端》）
• 規(guī)范而非默契。（詳見《前端架構(gòu)：從入門到微前端》）

除此，在日常的開發(fā)中，還需要注重代碼的可維護(hù)——簡單的代碼更容易讀性和維護(hù)。筆者維護(hù)一個 Scala 項目的過程中，便是深有體會——越是寫得越抽象的代碼，越難以維護(hù)。諸如函數(shù)式編程是一個好的東西，但是好的東西也容易被爛用，導(dǎo)致人們不喜歡這個東西。

小結(jié)

買， 買，買

——節(jié)選自《前端架構(gòu)：從入門到微前端》