常見的架構風格
分層風格
這是最常見的架構風格，它將系統按照水平切分的方式分成多個層。一個系統由多層組成，每層由多個模塊組成。每一層為上層提供服務，並使用下層提供的功能。最為人所知的分層架構應用是OSI七層模型和TCP/IP五層模型，在開發后端服務的時候得到了廣泛的應用。如在采用Spring MVC開發的后端應用中，Controller層在接收后端請求時，將通過Service層向DAO（Data Access Object，數據訪問對象）層請求數據，而不是直接向DAO層請求數據。
MVC架構
這種風格應用得相當廣泛，它強調職責分離，將軟件系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。由視圖和控制器一起完成用戶界面的功能，並設計一套變更機制，來保證用戶界面與模型的一致性。它是一種常見的架構風格，在涉及圖形用戶界面時，往往都有它的身影，如前端應用、移動端應用等。
發布-訂閱風格
這種風格又可以稱為基於事件的架構風格，它是一種一對多的關系，一個對象狀態發生改變時，所有訂閱它的對象都會得到通知。這種架構風格帶來的最大好處是，代碼上的解耦。發布者不關心事件的訂閱者，只需要在適當的時候發布相應的事件即可；而訂閱者則依賴於事件，而非事件的發布者。在前端的日常開發中，為了解耦不同的UI組件的依賴，會經常采用這種模式。
管理和過濾器
這是一種適合於處理數據流的架構模式，它將每個步驟都封裝在一個過濾器組件中，數據通過相鄰過濾器之間的管道傳輸。最典型的管道-過濾器架構是UNIX shell的設計。在類Unix系統中，使用“|”作為管理符號，當我們需要編寫復雜的Shell腳本來處理內容時，便會使用這個符號。諸如ls-l|grep.jpg，便會先執行ls-l命令，再將結果交由grep程序，查找以．jpg結尾的文件名。
它也適用於相關的數據處理場景，如我們在采用Hadoop、Spark等編寫數據處理相關的代碼時，便會采用這種模式來編寫。如前端框架的Angular，也直接內置了管理（Pipe）系統。
架構設計方法
RUP 4 +1 視圖法
邏輯視圖（Logical View）
在設計期的模塊、接口划分、職責及協作方式等。
流程視圖（Process View）
在運行期運行的數據同步，如在微前端中的數據流、控制流等。
開發視圖（Development View）
在開發期的框架、庫、技術選型及其對應的編譯。
物理視圖（Physical View）
又稱為部署視圖。在部署期與持續交付相關的技術決策
場景（scenarios）
又稱為例視圖，它使用一組用例或場景來說明架構
架構設計原則
不多也不少
不做多余的設計，也不缺少關鍵部分
演進式
不斷地演進以使架構適應當前的環境
持續性
長期的架構改進比什么都重要
前端架構設計：層次設計
架構設計本身是分層級的，面向不同級別的人時所展示的內容也是不一樣的，不同階段構成架構的因素是不同的，基於這個思路，架構設計可以分為四個層級。
相應的層級解釋如下：
◎ 系統級，即應用在整個系統內的關系，如與后台服務如何通信，與第三方系統如何集成。
◎ 應用級，即應用外部的整體架構，如多個應用之間如何共享組件、如何通信等。
◎ 模塊級，即應用內部的模塊架構，如代碼的模塊化、數據和狀態的管理等。
◎ 代碼級，即從基礎設施來保障架構實施。
在設計的時候，既要用自上而下的方式來設計架構，又要用自下而上的方式來完善架構。從演進式設計的角度來看，我們需要在前期設計的時候，對所有系統級架構及部分應用級架構進行技術決策，而其余部分的架構則可以在實施的過程中考慮。
微前端的技術拆分方式
從技術實踐上，微前端架構可以采用以下幾種方式進行：
（1）路由分發式。
通過HTTP服務器的反向代理功能，將請求路由到對應的應用上。
在這個架構中，我們只需要關注應用間的數據傳遞方式。通常，我們只需要將當前的用戶狀態，從A應用傳遞到B應用即可。
（2）前端微服務化。
在不同的框架之上設計通信和加載機制，以在一個頁面內加載對應的應用。
前端微服務化，是微服務架構在前端的實施，每個前端應用都是完全獨立（技術棧、開發、部署、構建獨立）、自主運行的，最后通過模塊化的方式組合出完整的前端應用。
采用這種方式意味着，一個頁面上同時存在兩個及以上的前端應用在運行。而路由分發式方案則是，一個頁面只有唯一一個應用。
同時，我們還需要保證應用間的第三方依賴不沖突。如應用A中使用了z插件，而應用B中也使用了z插件，如果一個頁面多次引入z插件會發生沖突，那么我們應該嘗試去解決這樣的問題
（3）微應用。
通過軟件工程的方式，在部署構建環境中，把多個獨立的應用組合成一個單體應用。
微應用化是指，在開發時應用都是以單一、微小應用的形式存在的，而在運行時，則通過構建系統合並這些應用，並組合成一個新的應用。
微應用化與前端微服務化類似，在開發時都是獨立應用的，在構建時又可以按照需求單獨加載。如果以微前端的單獨開發、單獨部署、運行時聚合的基本思想來看，微應用化就是微前端的一種實踐，只是使用微應用化意味着我們只能使用唯一的一種前端框架。
（4）微件化。
開發一個新的構建系統，將部分業務功能構建成一個獨立的chunk代碼，使用時只需要遠程加載即可。
（5）前端容器化。
將iframe作為容器來容納其他前端應用。
（6）應用組件化。
借助於WebComponents技術，來構建跨框架的前端應用。
實施的方式雖然多，但都是依據場景而采用的。在有些場景下，可能沒有合適的方式；在有些場景下，則可以同時使用多種方案。
微前端的業務划分方式
與微服務類似，要划分不同的前端邊界不是一件容易的事。就當前而言，以下幾種方式是常見的划分微前端的方式：
◎ 按照業務拆分。
◎ 按照權限拆分。
◎ 按照變更的頻率拆分。
◎ 按照組織結構拆分。
◎ 跟隨后端微服務划分。
因為每個項目都有自己特殊的背景，所以切分微前端的方式就不一樣。即使項目的類型相似，也存在一些細微的差異。
待續。。。
《前端架構：從入門到微前端》