軟件架構(gòu)入門-分層架構(gòu)、事件驅(qū)動、微服務(wù)架構(gòu)和云原生架構(gòu)

軟件架構(gòu)（software architecture）就是軟件的基本結(jié)構(gòu)。

合適的架構(gòu)是軟件成功的最重要因素之一。大型軟件公司通常有專門的架構(gòu)師職位（architect），只有資深程序員才可以擔(dān)任。

O'Reilly 出版過一本免費(fèi)的小冊子《Software Architecture Patterns》（PDF）， 介紹了五種最常見的軟件架構(gòu)，是非常好的入門讀物。

軟件架構(gòu)就是軟件的基本結(jié)構(gòu)。架構(gòu)的本質(zhì)是管理復(fù)雜性。如果你覺得架構(gòu)不重要，可能是你做的事情不夠復(fù)雜，或者是你沒有管理好復(fù)雜性。架構(gòu)模式雖多，經(jīng)過抽象沉淀之后，也就那么幾種：

1. 分層架構(gòu)（比較傳統(tǒng)的單體架構(gòu)）

2. 事件驅(qū)動架構(gòu) （一般適用于應(yīng)用局部場景，用來實現(xiàn)異步解耦）

3. 微核架構(gòu)（又稱插件架構(gòu)，開發(fā)難度較高，一般用來做工具軟件開發(fā)，如Eclipse，不太適合分布式業(yè)務(wù)場景）

4. 微服務(wù)架構(gòu)（當(dāng)前比較流行的服務(wù)化架構(gòu)，解決單體架構(gòu)面臨的問題，適合敏捷開發(fā)，快速迭代）

5. 云架構(gòu)（現(xiàn)在的說法是云原生架構(gòu)-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架構(gòu)）

在原文的基礎(chǔ)上，小編按照自己的想法，進(jìn)行了小幅調(diào)整。

layered architecture）是最常見的軟件架構(gòu)，也是事實上的標(biāo)準(zhǔn)架構(gòu)。如果你不知道要用什么架構(gòu)，那就用它。

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

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

• 表現(xiàn)層（presentation）：用戶界面，負(fù)責(zé)視覺和用戶互動
• 業(yè)務(wù)層（business）：實現(xiàn)業(yè)務(wù)邏輯
• 持久層（persistence）：提供數(shù)據(jù)，SQL 語句就放在這一層
• 數(shù)據(jù)庫（database） ：保存數(shù)據(jù)

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

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

優(yōu)點(diǎn)

• 結(jié)構(gòu)簡單，容易理解和開發(fā)
• 不同技能的程序員可以分工，負(fù)責(zé)不同的層，天然適合大多數(shù)軟件公司的組織架構(gòu)
• 每一層都可以獨(dú)立測試，其他層的接口通過模擬解決

缺點(diǎn)

• 一旦環(huán)境變化，需要代碼調(diào)整或增加功能時，通常比較麻煩和費(fèi)時
• 部署比較麻煩，即使只修改一個小地方，往往需要整個軟件重新部署，不容易做持續(xù)發(fā)布（因為是單體架構(gòu)）
• 軟件升級時，可能需要整個服務(wù)暫停
• 擴(kuò)展性差。用戶請求大量增加時，必須依次擴(kuò)展每一層，由于每一層內(nèi)部是耦合的，擴(kuò)展會很困難（單體架構(gòu)，需求調(diào)整會貫穿每一層）

事件驅(qū)動架構(gòu)（event-driven architecture）核心組件：

• 事件隊列（event queue）：接收事件的入口
• 分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元
• 事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道
• 事件處理器（event processor）：實現(xiàn)業(yè)務(wù)邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作

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

優(yōu)點(diǎn)

• 分布式的異步架構(gòu)，事件處理器之間高度解耦，軟件的擴(kuò)展性好
• 適用性廣，各種類型的項目都可以用
• 性能較好，因為事件的異步本質(zhì)，軟件不易產(chǎn)生堵塞
• 事件處理器可以獨(dú)立地加載和卸載，容易部署

缺點(diǎn)

• 涉及異步編程（要考慮遠(yuǎn)程通信、失去響應(yīng)等情況），開發(fā)相對復(fù)雜
• 難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾
• 分布式和異步特性導(dǎo)致這個架構(gòu)較難測試

事件驅(qū)動架構(gòu)在通信產(chǎn)品中應(yīng)用得也非常廣泛，典型的如狀態(tài)機(jī)處理。事件驅(qū)動架構(gòu)不適于做頂層架構(gòu)，但適合做局部實現(xiàn)，幾乎遍布在通信軟件的各個角落。

優(yōu)點(diǎn)

• 良好的功能延伸性（extensibility），需要什么功能，開發(fā)一個插件即可
• 功能之間是隔離的，插件可以獨(dú)立的加載和卸載，使得它比較容易部署，
• 可定制性高，適應(yīng)不同的開發(fā)需要
• 可以漸進(jìn)式地開發(fā)，逐步增加功能

缺點(diǎn)

• 擴(kuò)展性（scalability）差，內(nèi)核通常是一個獨(dú)立單元，不容易做成分布式
• 開發(fā)難度相對較高，因為涉及到插件與內(nèi)核的通信，以及內(nèi)部的插件登記機(jī)制

微核架構(gòu)的設(shè)計和開發(fā)難度較高，這就注定它在企業(yè)產(chǎn)品中用得不多，雖然它的優(yōu)點(diǎn)還不少。

RESTful API 模式：服務(wù)通過 API 提供，云服務(wù)就屬于這一類

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

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

現(xiàn)在開源的微服務(wù)框架比較多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

優(yōu)點(diǎn)

• 擴(kuò)展性好，各個服務(wù)之間低耦合
• 容易部署，軟件從單一可部署單元，被拆成了多個服務(wù)，每個服務(wù)都是可部署單元
• 容易開發(fā)，每個組件都可以進(jìn)行持續(xù)集成式的開發(fā)，可以做到實時部署，不間斷地升級
• 易于測試，可以單獨(dú)測試每一個服務(wù)

缺點(diǎn)

• 由于強(qiáng)調(diào)互相獨(dú)立和低耦合，服務(wù)可能會拆分得很細(xì)。這導(dǎo)致系統(tǒng)依賴大量的微服務(wù)，變得很凌亂和笨重，性能也會不佳。
• 一旦服務(wù)之間需要通信（即一個服務(wù)要用到另一個服務(wù)），整個架構(gòu)就會變得復(fù)雜。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個服務(wù)中去，用冗余換取架構(gòu)的簡單性。
• 分布式的本質(zhì)使得這種架構(gòu)很難實現(xiàn)原子性操作，交易回滾會比較困難。

處理單元：實現(xiàn)業(yè)務(wù)邏輯（類似于微服務(wù)架構(gòu)中的微服務(wù)）

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

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

• 消息中間件（Messaging Grid）：管理用戶請求和session，當(dāng)一個請求進(jìn)來以后，決定分配給哪一個處理單元；
• 數(shù)據(jù)中間件（Data Grid）：將數(shù)據(jù)復(fù)制到每一個處理單元，即數(shù)據(jù)同步。保證某個處理單元都得到同樣的數(shù)據(jù)；
• 處理中間件（Processing Grid）：可選，如果一個請求涉及不同類型的處理單元，該中間件負(fù)責(zé)協(xié)調(diào)處理單元；
• 部署中間件（Deployment Manager）：負(fù)責(zé)處理單元的啟動和關(guān)閉，監(jiān)控負(fù)載和響應(yīng)時間，當(dāng)負(fù)載增加，就新啟動處理單元，負(fù)載減少，就關(guān)閉處理單元。

隨著Docker、Kubernetes等容器化技術(shù)的快速發(fā)展，上述關(guān)于云架構(gòu)描述有點(diǎn)陳舊了。當(dāng)前最新的云原生架構(gòu)，以Docker+Kubernetes為核心，尤其是容器編排Kubernetes 已經(jīng)成為事實上的行業(yè)標(biāo)準(zhǔn)。

云原生架構(gòu)圖的主要特征：

• 微服務(wù)應(yīng)用運(yùn)行支撐環(huán)境；
• 以容器化應(yīng)用的鏡像作為交付標(biāo)準(zhǔn)；
• 通過資源調(diào)度服務(wù)快速申請、釋放資源；
• 通過彈性伸縮快速擴(kuò)展應(yīng)用；
• 狀態(tài)監(jiān)控；

主要目標(biāo)：

1. 讓開發(fā)人員聚焦業(yè)務(wù)邏輯的實現(xiàn)，其他交給容器云平臺來完成；

2. 支持業(yè)務(wù)系統(tǒng)的快速迭代，支撐業(yè)務(wù)的快速變化和發(fā)展；

3. 構(gòu)建以共享服務(wù)體系為核心的業(yè)務(wù)中臺；

下面是小編針對某新零售企業(yè)設(shè)計的云原生架構(gòu)圖，以云和微服務(wù)架構(gòu)為基礎(chǔ)構(gòu)建云原生應(yīng)用，這里云可以是公有云、私有云、混合云等等。

以上是從不同的視角，對架構(gòu)進(jìn)行了分類。實際應(yīng)用中，各種架構(gòu)并不是孤立的，可以根據(jù)業(yè)務(wù)環(huán)境和業(yè)務(wù)訴求，對各種架構(gòu)進(jìn)行綜合和嫁接。每種架構(gòu)都有其優(yōu)點(diǎn)和缺點(diǎn)。優(yōu)點(diǎn)不必多說，缺點(diǎn)則幾乎都是通過工具工程（比如自動化發(fā)布工具、自動化測試等等）能力的方法來規(guī)避，工具工程對軟件架構(gòu)非常重要。

名稱欄目：軟件架構(gòu)入門-分層架構(gòu)、事件驅(qū)動、微服務(wù)架構(gòu)和云原生架構(gòu)
分享網(wǎng)址：http://muchs.cn/news/103819.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)站設(shè)計公司、靜態(tài)網(wǎng)站、微信小程序、Google、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)