web開發(fā)常用的互聯(lián)網(wǎng)架構模式有哪些

本篇內(nèi)容介紹了“web開發(fā)常用的互聯(lián)網(wǎng)架構模式有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

 一、分層架構

分層架構(layered architecture)是最常見的軟件架構，也是事實上的標準架構。如果你不知道要用什么架構，那就用它。

這種架構將軟件分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節(jié)。層與層之間通過接口通信。

雖然沒有明確約定，軟件一定要分成多少層，但是四層的結構最常見。

• 表現(xiàn)層(presentation)：用戶界面，負責視覺和用戶互動

• 業(yè)務層(business)：實現(xiàn)業(yè)務邏輯

• 持久層(persistence)：提供數(shù)據(jù)，SQL 語句就放在這一層

• 數(shù)據(jù)庫(database) ：保存數(shù)據(jù)

有的軟件在邏輯層和持久層之間，加了一個服務層(service)，提供不同業(yè)務邏輯需要的一些通用接口。

用戶的請求將依次通過這四層的處理，不能跳過其中任何一層。

優(yōu)點

• 結構簡單，容易理解和開發(fā)

• 不同技能的程序員可以分工，負責不同的層，天然適合大多數(shù)軟件公司的組織架構

• 每一層都可以獨立測試，其他層的接口通過模擬解決

缺點

• 一旦環(huán)境變化，需要代碼調(diào)整或增加功能時，通常比較麻煩和費時

• 部署比較麻煩，即使只修改一個小地方，往往需要整個軟件重新部署，不容易做持續(xù)發(fā)布

• 軟件升級時，可能需要整個服務暫停

• 擴展性差。用戶請求大量增加時，必須依次擴展每一層，由于每一層內(nèi)部是耦合的，擴展會很困難

二、事件驅動架構

事件(event)是狀態(tài)發(fā)生變化時，軟件發(fā)出的通知。

事件驅動架構(event-driven architecture)就是通過事件進行通信的軟件架構。它分成四個部分。

• 事件隊列(event queue)：接收事件的入口

• 分發(fā)器(event mediator)：將不同的事件分發(fā)到不同的業(yè)務邏輯單元

• 事件通道(event channel)：分發(fā)器與處理器之間的聯(lián)系渠道

• 事件處理器(event processor)：實現(xiàn)業(yè)務邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作

對于簡單的項目，事件隊列、分發(fā)器和事件通道，可以合為一體，整個軟件就分成事件代理和事件處理器兩部分。

優(yōu)點

• 分布式的異步架構，事件處理器之間高度解耦，軟件的擴展性好

• 適用性廣，各種類型的項目都可以用

• 性能較好，因為事件的異步本質，軟件不易產(chǎn)生堵塞

• 事件處理器可以獨立地加載和卸載，容易部署

缺點

• 涉及異步編程(要考慮遠程通信、失去響應等情況)，開發(fā)相對復雜

• 難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾

• 分布式和異步特性導致這個架構較難測試

三、微核架構

微核架構(microkernel architecture)又稱為"插件架構"(plug-in  architecture)，指的是軟件的內(nèi)核相對較小，主要功能和業(yè)務邏輯都通過插件實現(xiàn)。

內(nèi)核(core)通常只包含系統(tǒng)運行的最小功能。插件則是互相獨立的，插件之間的通信，應該減少到最低，避免出現(xiàn)互相依賴的問題。

優(yōu)點

• 良好的功能延伸性(extensibility)，需要什么功能，開發(fā)一個插件即可

• 功能之間是隔離的，插件可以獨立的加載和卸載，使得它比較容易部署，

• 可定制性高，適應不同的開發(fā)需要

• 可以漸進式地開發(fā)，逐步增加功能

缺點

• 擴展性(scalability)差，內(nèi)核通常是一個獨立單元，不容易做成分布式

• 開發(fā)難度相對較高，因為涉及到插件與內(nèi)核的通信，以及內(nèi)部的插件登記機制

四、微服務架構

微服務架構(microservices architecture)是服務導向架構(service-oriented architecture，縮寫  SOA)的升級。

每一個服務就是一個獨立的部署單元(separately deployed  unit)。這些單元都是分布式的，互相解耦，通過遠程通信協(xié)議(比如REST、SOAP)聯(lián)系。

微服務架構分成三種實現(xiàn)模式。

• RESTful API 模式：服務通過 API 提供，云服務就屬于這一類

• RESTful 應用模式：服務通過傳統(tǒng)的網(wǎng)絡協(xié)議或者應用協(xié)議提供，背后通常是一個多功能的應用程序，常見于企業(yè)內(nèi)部

• 集中消息模式：采用消息代理(message  broker)，可以實現(xiàn)消息隊列、負載均衡、統(tǒng)一日志和異常處理，缺點是會出現(xiàn)單點失敗，消息代理可能要做成集群

優(yōu)點

• 擴展性好，各個服務之間低耦合

• 容易部署，軟件從單一可部署單元，被拆成了多個服務，每個服務都是可部署單元

• 容易開發(fā)，每個組件都可以進行持續(xù)集成式的開發(fā)，可以做到實時部署，不間斷地升級

• 易于測試，可以單獨測試每一個服務

缺點

• 由于強調(diào)互相獨立和低耦合，服務可能會拆分得很細。這導致系統(tǒng)依賴大量的微服務，變得很凌亂和笨重，性能也會不佳。

• 一旦服務之間需要通信(即一個服務要用到另一個服務)，整個架構就會變得復雜。典型的例子就是一些通用的 Utility  類，一種解決方案是把它們拷貝到每一個服務中去，用冗余換取架構的簡單性。

• 分布式的本質使得這種架構很難實現(xiàn)原子性操作，交易回滾會比較困難。

五、云架構

云結構(cloud architecture)主要解決擴展性和并發(fā)的問題，是最容易擴展的架構。

它的高擴展性，主要原因是沒使用中央數(shù)據(jù)庫，而是把數(shù)據(jù)都復制到內(nèi)存中，變成可復制的內(nèi)存數(shù)據(jù)單元。然后，業(yè)務處理能力封裝成一個個處理單元(prcessing  unit)。訪問量增加，就新建處理單元;訪問量減少，就關閉處理單元。由于沒有中央數(shù)據(jù)庫，所以擴展性的最大瓶頸消失了。由于每個處理單元的數(shù)據(jù)都在內(nèi)存里，最好要進行數(shù)據(jù)持久化。

這個模式主要分成兩部分：處理單元(processing unit)和虛擬中間件(virtualized middleware)。

• 處理單元：實現(xiàn)業(yè)務邏輯

• 虛擬中間件：負責通信、保持sessions、數(shù)據(jù)復制、分布式處理、處理單元的部署。

虛擬中間件又包含四個組件。

• 消息中間件(Messaging Grid)：管理用戶請求和session，當一個請求進來以后，決定分配給哪一個處理單元。

• 數(shù)據(jù)中間件(Data Grid)：將數(shù)據(jù)復制到每一個處理單元，即數(shù)據(jù)同步。保證某個處理單元都得到同樣的數(shù)據(jù)。

• 處理中間件(Processing Grid)：可選，如果一個請求涉及不同類型的處理單元，該中間件負責協(xié)調(diào)處理單元

• 部署中間件(Deployment  Manager)：負責處理單元的啟動和關閉，監(jiān)控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單元。

優(yōu)點

• 高負載，高擴展性

• 動態(tài)部署

缺點

• 實現(xiàn)復雜，成本較高

• 主要適合網(wǎng)站類應用，不合適大量數(shù)據(jù)吞吐的大型數(shù)據(jù)庫應用

• 較難測試

“web開發(fā)常用的互聯(lián)網(wǎng)架構模式有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！