轉(zhuǎn)自：http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

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

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

O'Reilly 出版過一本免費(fèi)的小冊(cè)子《Software Architecture Patterns》（PDF）， 介紹了五種最常見的軟件架構(gòu)，是非常好的入門讀物。我讀后受益匪淺，下面就是我的筆記柏肪。

一、分層架構(gòu)

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

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

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

表現(xiàn)層（presentation）：用戶界面炬转，負(fù)責(zé)視覺和用戶互動(dòng)

業(yè)務(wù)層（business）：實(shí)現(xiàn)業(yè)務(wù)邏輯

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

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

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

用戶的請(qǐng)求將依次通過這四層的處理菲驴，不能跳過其中任何一層荐吵。

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

結(jié)構(gòu)簡(jiǎn)單，容易理解和開發(fā)

不同技能的程序員可以分工赊瞬，負(fù)責(zé)不同的層先煎，天然適合大多數(shù)軟件公司的組織架構(gòu)

每一層都可以獨(dú)立測(cè)試，其他層的接口通過模擬解決

缺點(diǎn)

一旦環(huán)境變化巧涧，需要代碼調(diào)整或增加功能時(shí)薯蝎，通常比較麻煩和費(fèi)時(shí)

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

軟件升級(jí)時(shí)，可能需要整個(gè)服務(wù)暫停

擴(kuò)展性差闷供。用戶請(qǐng)求大量增加時(shí)，必須依次擴(kuò)展每一層统诺，由于每一層內(nèi)部是耦合的歪脏，擴(kuò)展會(huì)很困難

二、事件驅(qū)動(dòng)架構(gòu)

事件（event）是狀態(tài)發(fā)生變化時(shí)粮呢，軟件發(fā)出的通知婿失。

事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）就是通過事件進(jìn)行通信的軟件架構(gòu)。它分成四個(gè)部分啄寡。

事件隊(duì)列（event queue）：接收事件的入口

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

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

事件處理器（event processor）：實(shí)現(xiàn)業(yè)務(wù)邏輯豪硅，處理完成后會(huì)發(fā)出事件，觸發(fā)下一步操作

對(duì)于簡(jiǎn)單的項(xiàng)目挺物，事件隊(duì)列懒浮、分發(fā)器和事件通道，可以合為一體，整個(gè)軟件就分成事件代理和事件處理器兩部分砚著。

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

分布式的異步架構(gòu)次伶，事件處理器之間高度解耦，軟件的擴(kuò)展性好

適用性廣稽穆，各種類型的項(xiàng)目都可以用

性能較好冠王，因?yàn)槭录漠惒奖举|(zhì)，軟件不易產(chǎn)生堵塞

事件處理器可以獨(dú)立地加載和卸載舌镶，容易部署

缺點(diǎn)

涉及異步編程（要考慮遠(yuǎn)程通信柱彻、失去響應(yīng)等情況），開發(fā)相對(duì)復(fù)雜

難以支持原子性操作餐胀，因?yàn)槭录ㄟ^會(huì)涉及多個(gè)處理器哟楷，很難回滾

分布式和異步特性導(dǎo)致這個(gè)架構(gòu)較難測(cè)試

三、微核架構(gòu)

微核架構(gòu)（microkernel architecture）又稱為"插件架構(gòu)"（plug-in architecture）骂澄，指的是軟件的內(nèi)核相對(duì)較小吓蘑，主要功能和業(yè)務(wù)邏輯都通過插件實(shí)現(xiàn)。

內(nèi)核（core）通常只包含系統(tǒng)運(yùn)行的最小功能坟冲。插件則是互相獨(dú)立的磨镶，插件之間的通信，應(yīng)該減少到最低健提，避免出現(xiàn)互相依賴的問題琳猫。

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

良好的功能延伸性（extensibility），需要什么功能私痹，開發(fā)一個(gè)插件即可

功能之間是隔離的脐嫂，插件可以獨(dú)立的加載和卸載，使得它比較容易部署紊遵，

可定制性高账千，適應(yīng)不同的開發(fā)需要

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

缺點(diǎn)

擴(kuò)展性（scalability）差暗膜，內(nèi)核通常是一個(gè)獨(dú)立單元匀奏，不容易做成分布式

開發(fā)難度相對(duì)較高，因?yàn)樯婕暗讲寮c內(nèi)核的通信学搜，以及內(nèi)部的插件登記機(jī)制

四娃善、微服務(wù)架構(gòu)

微服務(wù)架構(gòu)（microservices architecture）是服務(wù)導(dǎo)向架構(gòu)（service-oriented architecture，縮寫 SOA）的升級(jí)瑞佩。

每一個(gè)服務(wù)就是一個(gè)獨(dú)立的部署單元（separately deployed unit）聚磺。這些單元都是分布式的，互相解耦炬丸，通過遠(yuǎn)程通信協(xié)議（比如REST瘫寝、SOAP）聯(lián)系。

微服務(wù)架構(gòu)分成三種實(shí)現(xiàn)模式。

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

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

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

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

擴(kuò)展性好，各個(gè)服務(wù)之間低耦合

容易部署外厂，軟件從單一可部署單元冕象，被拆成了多個(gè)服務(wù)，每個(gè)服務(wù)都是可部署單元

容易開發(fā)汁蝶，每個(gè)組件都可以進(jìn)行持續(xù)集成式的開發(fā)渐扮，可以做到實(shí)時(shí)部署，不間斷地升級(jí)

易于測(cè)試掖棉，可以單獨(dú)測(cè)試每一個(gè)服務(wù)

缺點(diǎn)

由于強(qiáng)調(diào)互相獨(dú)立和低耦合墓律，服務(wù)可能會(huì)拆分得很細(xì)。這導(dǎo)致系統(tǒng)依賴大量的微服務(wù)幔亥，變得很凌亂和笨重耻讽，性能也會(huì)不佳。

一旦服務(wù)之間需要通信（即一個(gè)服務(wù)要用到另一個(gè)服務(wù)）帕棉，整個(gè)架構(gòu)就會(huì)變得復(fù)雜针肥。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個(gè)服務(wù)中去香伴，用冗余換取架構(gòu)的簡(jiǎn)單性慰枕。

分布式的本質(zhì)使得這種架構(gòu)很難實(shí)現(xiàn)原子性操作，交易回滾會(huì)比較困難即纲。

五捺僻、云架構(gòu)

云結(jié)構(gòu)（cloud architecture）主要解決擴(kuò)展性和并發(fā)的問題，是最容易擴(kuò)展的架構(gòu)崇裁。

它的高擴(kuò)展性，主要原因是沒使用中央數(shù)據(jù)庫束昵，而是把數(shù)據(jù)都復(fù)制到內(nèi)存中拔稳，變成可復(fù)制的內(nèi)存數(shù)據(jù)單元。然后锹雏，業(yè)務(wù)處理能力封裝成一個(gè)個(gè)處理單元（prcessing unit）巴比。訪問量增加，就新建處理單元；訪問量減少轻绞，就關(guān)閉處理單元采记。由于沒有中央數(shù)據(jù)庫，所以擴(kuò)展性的最大瓶頸消失了政勃。由于每個(gè)處理單元的數(shù)據(jù)都在內(nèi)存里唧龄，最好要進(jìn)行數(shù)據(jù)持久化。

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

處理單元：實(shí)現(xiàn)業(yè)務(wù)邏輯

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

虛擬中間件又包含四個(gè)組件薛窥。

消息中間件（Messaging Grid）：管理用戶請(qǐng)求和session胖烛，當(dāng)一個(gè)請(qǐng)求進(jìn)來以后，決定分配給哪一個(gè)處理單元诅迷。

數(shù)據(jù)中間件（Data Grid）：將數(shù)據(jù)復(fù)制到每一個(gè)處理單元佩番，即數(shù)據(jù)同步。保證某個(gè)處理單元都得到同樣的數(shù)據(jù)竟贯。

處理中間件（Processing Grid）：可選答捕，如果一個(gè)請(qǐng)求涉及不同類型的處理單元，該中間件負(fù)責(zé)協(xié)調(diào)處理單元

部署中間件（Deployment Manager）：負(fù)責(zé)處理單元的啟動(dòng)和關(guān)閉屑那，監(jiān)控負(fù)載和響應(yīng)時(shí)間拱镐，當(dāng)負(fù)載增加，就新啟動(dòng)處理單元持际，負(fù)載減少沃琅，就關(guān)閉處理單元。

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

高負(fù)載蜘欲，高擴(kuò)展性

動(dòng)態(tài)部署

缺點(diǎn)

實(shí)現(xiàn)復(fù)雜益眉，成本較高

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

較難測(cè)試

（完）