[[348586]]

 作者個人研發(fā)的在高并發(fā)場景下，提供的簡單、穩(wěn)定、可擴展的延遲消息隊列框架，具有精準的定時任務(wù)和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業(yè)提供了精準定時調(diào)度方案，經(jīng)受住了生產(chǎn)環(huán)境的考驗。為使更多童鞋受益，現(xiàn)給出開源框架地址：https://github.com/sunshinelyz/mykit-delay

寫在前面

隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)也在不斷的飛速發(fā)展，進而導(dǎo)致系統(tǒng)的架構(gòu)也在不斷的發(fā)生著變化。總體來說，系統(tǒng)的架構(gòu)大致經(jīng)歷了：單體應(yīng)用架構(gòu)—>垂直應(yīng)用架構(gòu)—>分布式架構(gòu)—>SOA架構(gòu)—>微服務(wù)架構(gòu)的演變。當然，很多互聯(lián)網(wǎng)企業(yè)的系統(tǒng)架構(gòu)已經(jīng)向Service Mesh(服務(wù)化網(wǎng)格)演變。今天，我們就一起來聊聊關(guān)于系統(tǒng)架構(gòu)的演變這個話題。

單體應(yīng)用架構(gòu)

在企業(yè)發(fā)展的初期，一般公司的網(wǎng)站流量都比較小，只需要一個應(yīng)用，將所有的功能代碼打包成一個服務(wù)，部署到服務(wù)器上就能支撐公司的業(yè)務(wù)。這樣也能夠減少開發(fā)、部署和維護的成本。

比如，大家都很熟悉的電商系統(tǒng)，里面涉及的業(yè)務(wù)主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期我們會將所有模塊寫到一個Web項目中，然后統(tǒng)一部署到一個Web服務(wù)器中。

這種架構(gòu)特點有其優(yōu)點：

• 架構(gòu)簡單，項目開發(fā)和維護成本低。
• 所有項目模塊部署到一起，對于小型項目來說，維護方便。

但是，其缺點也是比較明顯的：

• 所有模塊耦合在一起，雖然對于小型項目來說，維護方便。但是，對于大型項目來說，卻是不易開發(fā)和維護的。
• 項目的各模塊之前過于耦合，如果一旦有一個模塊出現(xiàn)問題，則整個項目將不可用。
• 無法針對某個具體模塊來提升性能。
• 無法對項目進行水平擴展。

正是由于單體應(yīng)用架構(gòu)存在著諸多的缺點，才逐漸演變?yōu)榇怪睉?yīng)用架構(gòu)。接下來，我們就來看看垂直應(yīng)用架構(gòu)。

垂直應(yīng)用架構(gòu)

隨著企業(yè)業(yè)務(wù)的不斷發(fā)展，發(fā)現(xiàn)單節(jié)點的單體應(yīng)用不足以支撐業(yè)務(wù)的發(fā)展，于是企業(yè)會將單體應(yīng)用部署多份，分別放在不同的服務(wù)器上。但是，此時會發(fā)現(xiàn)不是所有的模塊都會有比較大的訪問量。如果想針對項目中的某些模塊進行優(yōu)化和性能提升，此時對于單體應(yīng)用來說，是做不到的。于是乎，垂直應(yīng)用架構(gòu)誕生了。

垂直應(yīng)用架構(gòu)，就是將原來一個項目應(yīng)用進行拆分，將其拆分為互不想干的幾個應(yīng)用，以此來提升系統(tǒng)的整體性能。

這里，我們同樣以電商系統(tǒng)為例，在垂直應(yīng)用架構(gòu)下，我們可以將整個電商項目拆分為：電商交易系統(tǒng)、后臺管理系統(tǒng)、CMS管理系統(tǒng)等。

我們將單體應(yīng)用架構(gòu)拆分為垂直應(yīng)用架構(gòu)之后，一旦訪問量變大，我們只需要針對訪問量大的業(yè)務(wù)增加服務(wù)器節(jié)點即可，無需針對整個項目增加服務(wù)器節(jié)點了。

這種架構(gòu)的優(yōu)點：

• 系統(tǒng)進行了拆分，可根據(jù)不同系統(tǒng)的訪問情況，有針對性的進行優(yōu)化。
• 能夠?qū)崿F(xiàn)應(yīng)用的水平擴展。
• 各系統(tǒng)能夠分擔(dān)整體訪問的流量，解決了并發(fā)問題。
• 一個系統(tǒng)發(fā)生了故障，不應(yīng)用其他系統(tǒng)的運行情況，提高了整體的容錯率。

這種架構(gòu)的缺點：

• 拆分后的各系統(tǒng)之間相對比較獨立，無法進行互相調(diào)用。
• 各系統(tǒng)難免存在重疊的業(yè)務(wù)，會存在重復(fù)開發(fā)的業(yè)務(wù)，后期維護比較困難。

分布式架構(gòu)

我們將系統(tǒng)演變?yōu)榇怪睉?yīng)用架構(gòu)之后，當垂直應(yīng)用越來越多，重復(fù)編寫的業(yè)務(wù)代碼就會越來越多。此時，我們需要將重復(fù)的代碼抽象出來，形成統(tǒng)一的服務(wù)供其他系統(tǒng)或者業(yè)務(wù)模塊來進行調(diào)用。此時，系統(tǒng)就會演變?yōu)榉植际郊軜?gòu)。

在分布式架構(gòu)中，我們會將系統(tǒng)整體拆分為服務(wù)層和表現(xiàn)層。服務(wù)層封裝了具體的業(yè)務(wù)邏輯供表現(xiàn)層調(diào)用，表現(xiàn)層則負責(zé)處理與頁面的交互操作。

這種架構(gòu)的優(yōu)點：

• 將重復(fù)的業(yè)務(wù)代碼抽象出來，形成公共的訪問服務(wù)，提高了代碼的復(fù)用性。
• 可以有針對性的對系統(tǒng)和服務(wù)進行性能優(yōu)化，以提升整體的訪問性能。

這種架構(gòu)的缺點：

系統(tǒng)之間的耦合度變高，調(diào)用關(guān)系變得復(fù)雜，難以維護。

SOA架構(gòu)

在分布式架構(gòu)下，當部署的服務(wù)越來越多，重復(fù)的代碼就會越來越多，對于容量的評估，小服務(wù)資源的浪費等問題比較嚴重。此時，我們就需要增加一個統(tǒng)一的調(diào)度中心來對集群進行實時管理。此時，系統(tǒng)就會演變?yōu)镾OA(面向服務(wù))的架構(gòu)。

這種架構(gòu)的優(yōu)點：

使用注冊中心解決了各個服務(wù)之間的服務(wù)依賴和調(diào)用關(guān)系的自動注冊與發(fā)現(xiàn)。

這種架構(gòu)的缺點：

各服務(wù)之間存在依賴關(guān)系，如果某個服務(wù)出現(xiàn)故障可能會造成服務(wù)的雪崩（關(guān)于穿透、擊穿和雪崩的問題，小伙伴們可以參見我之前寫的《【高并發(fā)】面試官：講講什么是緩存穿透？擊穿？雪崩？如何解決？》一文）。

服務(wù)之間的依賴與調(diào)用關(guān)系復(fù)雜，測試部署的困難比較大。

微服務(wù)架構(gòu)

隨著業(yè)務(wù)的發(fā)展，我們在SOA架構(gòu)的基礎(chǔ)上進一步擴展，將其徹底拆分為微服務(wù)架構(gòu)。在微服務(wù)架構(gòu)下，我們將一個大的項目拆分為一個個小的可以獨立部署的微服務(wù)，每個微服務(wù)都有自己的數(shù)據(jù)庫。

這種架構(gòu)的優(yōu)點：

• 服務(wù)徹底拆分，各服務(wù)獨立打包、獨立部署和獨立升級。
• 每個微服務(wù)負責(zé)的業(yè)務(wù)比較清晰，利于后期擴展和維護。
• 微服務(wù)之間可以采用REST和RPC協(xié)議進行通信。

這種架構(gòu)的缺點：

• 開發(fā)的成本比較高。
• 涉及到各服務(wù)的容錯性問題。
• 涉及到數(shù)據(jù)的一致性問題。
• 涉及到分布式事務(wù)問題

本文轉(zhuǎn)載自微信公眾號「冰河技術(shù)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系冰河技術(shù)公眾號。