系統從初期到支撐億級流量，都經歷了哪些架構上的演變？
作者個人研發的在高并發場景下，提供的簡單、穩定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業提供了精準定時調度方案，經受住了生產環境的考驗。為使更多童鞋受益，現給出開源框架地址：https://github.com/sunshinelyz/mykit-delay
寫在前面
隨著互聯網的發展，互聯網企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化。總體來說，系統的架構大致經歷了：單體應用架構—>垂直應用架構—>分布式架構—>SOA架構—>微服務架構的演變。當然，很多互聯網企業的系統架構已經向Service Mesh(服務化網格)演變。今天，我們就一起來聊聊關于系統架構的演變這個話題。
單體應用架構
在企業發展的初期，一般公司的網站流量都比較小，只需要一個應用，將所有的功能代碼打包成一個服務，部署到服務器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。
比如，大家都很熟悉的電商系統，里面涉及的業務主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期我們會將所有模塊寫到一個Web項目中，然后統一部署到一個Web服務器中。
這種架構特點有其優點：
- 架構簡單，項目開發和維護成本低。
- 所有項目模塊部署到一起，對于小型項目來說，維護方便。
但是，其缺點也是比較明顯的：
- 所有模塊耦合在一起，雖然對于小型項目來說，維護方便。但是，對于大型項目來說，卻是不易開發和維護的。
- 項目的各模塊之前過于耦合，如果一旦有一個模塊出現問題，則整個項目將不可用。
- 無法針對某個具體模塊來提升性能。
- 無法對項目進行水平擴展。
正是由于單體應用架構存在著諸多的缺點，才逐漸演變為垂直應用架構。接下來，我們就來看看垂直應用架構。
垂直應用架構
隨著企業業務的不斷發展，發現單節點的單體應用不足以支撐業務的發展，于是企業會將單體應用部署多份，分別放在不同的服務器上。但是，此時會發現不是所有的模塊都會有比較大的訪問量。如果想針對項目中的某些模塊進行優化和性能提升，此時對于單體應用來說，是做不到的。于是乎，垂直應用架構誕生了。
垂直應用架構，就是將原來一個項目應用進行拆分，將其拆分為互不想干的幾個應用，以此來提升系統的整體性能。
這里，我們同樣以電商系統為例，在垂直應用架構下，我們可以將整個電商項目拆分為：電商交易系統、后臺管理系統、CMS管理系統等。
我們將單體應用架構拆分為垂直應用架構之后，一旦訪問量變大，我們只需要針對訪問量大的業務增加服務器節點即可，無需針對整個項目增加服務器節點了。
這種架構的優點：
- 系統進行了拆分，可根據不同系統的訪問情況，有針對性的進行優化。
- 能夠實現應用的水平擴展。
- 各系統能夠分擔整體訪問的流量，解決了并發問題。
- 一個系統發生了故障，不應用其他系統的運行情況，提高了整體的容錯率。
這種架構的缺點：
- 拆分后的各系統之間相對比較獨立，無法進行互相調用。
- 各系統難免存在重疊的業務，會存在重復開發的業務，后期維護比較困難。
分布式架構
我們將系統演變為垂直應用架構之后，當垂直應用越來越多，重復編寫的業務代碼就會越來越多。此時，我們需要將重復的代碼抽象出來，形成統一的服務供其他系統或者業務模塊來進行調用。此時，系統就會演變為分布式架構。
在分布式架構中，我們會將系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用，表現層則負責處理與頁面的交互操作。
這種架構的優點：
- 將重復的業務代碼抽象出來，形成公共的訪問服務，提高了代碼的復用性。
- 可以有針對性的對系統和服務進行性能優化，以提升整體的訪問性能。
這種架構的缺點：
系統之間的耦合度變高，調用關系變得復雜，難以維護。
SOA架構
在分布式架構下，當部署的服務越來越多，重復的代碼就會越來越多，對于容量的評估，小服務資源的浪費等問題比較嚴重。此時，我們就需要增加一個統一的調度中心來對集群進行實時管理。此時，系統就會演變為SOA(面向服務)的架構。
這種架構的優點：
使用注冊中心解決了各個服務之間的服務依賴和調用關系的自動注冊與發現。
這種架構的缺點：
各服務之間存在依賴關系，如果某個服務出現故障可能會造成服務的雪崩（關于穿透、擊穿和雪崩的問題，小伙伴們可以參見我之前寫的《【高并發】面試官：講講什么是緩存穿透？擊穿？雪崩？如何解決？》一文）。
服務之間的依賴與調用關系復雜，測試部署的困難比較大。
微服務架構
隨著業務的發展，我們在SOA架構的基礎上進一步擴展，將其徹底拆分為微服務架構。在微服務架構下，我們將一個大的項目拆分為一個個小的可以獨立部署的微服務，每個微服務都有自己的數據庫。
這種架構的優點：
- 服務徹底拆分，各服務獨立打包、獨立部署和獨立升級。
- 每個微服務負責的業務比較清晰，利于后期擴展和維護。
- 微服務之間可以采用REST和RPC協議進行通信。
這種架構的缺點：
- 開發的成本比較高。
- 涉及到各服務的容錯性問題。
- 涉及到數據的一致性問題。
- 涉及到分布式事務問題
本文轉載自微信公眾號「冰河技術」，可以通過以下二維碼關注。轉載本文請聯系冰河技術公眾號。
