架構(gòu)的規(guī)劃誰
架構(gòu)就是對(duì)系統(tǒng)中的實(shí)體以及實(shí)體之間的關(guān)系所進(jìn)行的抽象描述，是決策。
系統(tǒng)架構(gòu)是結(jié)構(gòu)和規(guī)劃，是對(duì)物/信息的功能與形式元素之間的對(duì)應(yīng)情況所做的分配，是對(duì)元素之間的關(guān)系以及元素同周邊環(huán)境之間的關(guān)系所做的定義。
- 架設(shè)計(jì)構(gòu)是個(gè)復(fù)雜的任務(wù)，也是個(gè)很大的話題，有了架構(gòu)之后，就需要讓干系人理解、遵循相關(guān)決策。
架構(gòu)圖的設(shè)計(jì)
系統(tǒng)架構(gòu)圖是為了抽象地表示軟件系統(tǒng)的整體輪廓和各個(gè)組件之間的相互關(guān)系和約束邊界，以及軟件系統(tǒng)的物理部署和軟件系統(tǒng)的演進(jìn)方向的整體視圖
架構(gòu)類型
單體架構(gòu)、分布式架構(gòu)、SOA架構(gòu)、微服務(wù)架構(gòu)、微內(nèi)核架構(gòu)和事件驅(qū)動(dòng)架構(gòu)、無服務(wù)架構(gòu)。
分布式架構(gòu)
分布式應(yīng)用架構(gòu)中，相互獨(dú)立，代碼獨(dú)立開發(fā)，獨(dú)立部署，通過API接口互相通信。通訊協(xié)議一般使用HTTP/RPC，數(shù)據(jù)格式是JSON(是一種輕量級(jí)的數(shù)據(jù)交換格式)，應(yīng)用集成方式比較簡化。
優(yōu)點(diǎn): 應(yīng)用內(nèi)部高內(nèi)聚，獨(dú)立開發(fā)、測試和部署，應(yīng)用之間松耦合，業(yè)務(wù)邊界清晰，業(yè)務(wù)依賴明確，支持大項(xiàng)目并行開發(fā)。
- 缺點(diǎn): API接口需求變化，應(yīng)用就需要重新部署，通信可靠性和數(shù)據(jù)的封裝性相對(duì)于進(jìn)程內(nèi)調(diào)用比較差。
SOA架構(gòu)
SOA也是分布式應(yīng)用架構(gòu)一種。
SOA架構(gòu)提供配套的服務(wù)治理，包括服務(wù)注冊(cè)、服務(wù)路由、服務(wù)授權(quán)、服務(wù)降級(jí)、服務(wù)監(jiān)控等等。
SOA架構(gòu)既體現(xiàn)業(yè)務(wù)的拆分，又體現(xiàn)業(yè)務(wù)的整合，更多地從業(yè)務(wù)整體上考慮系統(tǒng)拆分。
優(yōu)點(diǎn)：以服務(wù)層為主，聚焦核心業(yè)務(wù)，同時(shí)以提供整個(gè)系統(tǒng)共享，服務(wù)作為獨(dú)立的應(yīng)用，獨(dú)立部署，接口清晰，很容易做自動(dòng)化測試和部署，服務(wù)是無狀態(tài)的，很容易做水平擴(kuò)展；通過容器虛擬化技術(shù)，實(shí)現(xiàn)故障隔離和資源高效利用。
- 缺點(diǎn)：系統(tǒng)依賴復(fù)雜，給開發(fā)/測試/部署帶來不便，分布式數(shù)據(jù)一致性和分布式事務(wù)支持困難，一般通過最終一致性簡化解決。
單體式應(yīng)用
系統(tǒng)只有一個(gè)應(yīng)用、打包成一個(gè)應(yīng)用；部署在一臺(tái)機(jī)器；在一個(gè)DB里存儲(chǔ)數(shù)據(jù)，單體式應(yīng)用采用分層架構(gòu)，一般為表示層、業(yè)務(wù)層、數(shù)據(jù)訪問層、DB層，表示層負(fù)責(zé)用戶體驗(yàn)，業(yè)務(wù)層負(fù)責(zé)業(yè)務(wù)邏輯，數(shù)據(jù)訪問層負(fù)責(zé)DB層的數(shù)據(jù)存取
優(yōu)點(diǎn)：開發(fā)、編譯、調(diào)試一站式、一個(gè)應(yīng)用程序包含所有功能點(diǎn)，容易測試和部署
- 缺點(diǎn)：系統(tǒng)逐漸龐大時(shí)，代碼復(fù)雜度高，難以維護(hù)，應(yīng)用擴(kuò)展水平低，業(yè)務(wù)和模塊職責(zé)區(qū)分不清晰。
微服務(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í)
- 易于測試，可以多帶帶測試每一個(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)的簡單性。
- 分布式的本質(zhì)使得這種架構(gòu)很難實(shí)現(xiàn)原子性操作，交易回滾會(huì)比較困難。
事件驅(qū)動(dòng)架構(gòu)
事件（event）是狀態(tài)發(fā)生變化時(shí)，軟件發(fā)出的通知。
- 事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）就是通過事件進(jìn)行通信的軟件架構(gòu)。
事件驅(qū)動(dòng)架構(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ì)于簡單的項(xiàng)目，事件隊(duì)列、分發(fā)器和事件通道，可以合為一體，整個(gè)軟件就分成事件代理和事件處理器兩部分。
事件驅(qū)動(dòng)架構(gòu)的優(yōu)缺點(diǎn)
優(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)較難測試。
分層架構(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)求將依次通過這四層的處理，不能跳過其中任何一層。
分層架構(gòu)
優(yōu)點(diǎn)
結(jié)構(gòu)簡單，容易理解和開發(fā)。
不同技能的程序員可以分工，負(fù)責(zé)不同的層，天然適合大多數(shù)軟件公司的組織架構(gòu)
- 每一層都可以獨(dú)立測試，其他層的接口通過模擬解決
缺點(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ì)很困難。
微核架構(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ī)制。
云架構(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ù)制、分布式處理、處理單元的部署。
