## 寫在前面 > 隨著網際網路的發展，網際網路企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化。總體來說，系統的架構大致經歷了：單體應用架構—>垂直應用架構—>分散式架構—>SOA架構—>微服務架構的演變。當然，很多網際網路企業的系統架構已經向Service Mesh(服務化網格)演變。今天，我們就一起來聊聊關於系統架構的演變這個話題。 ## 單體應用架構 在企業發展的初期，一般公司的網站流量都比較小，只需要一個應用，將所有的功能程式碼打包成一個服務，部署到伺服器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。 比如，大家都很熟悉的電商系統，裡面涉及的業務主要有：使用者管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模組，初期我們會將所有模組寫到一個Web專案中，然後統一部署到一個Web伺服器中。  **這種架構特點有其優點：** * 架構簡單，專案開發和維護成本低。 * 所有專案模組部署到一起，對於小型專案來說，維護方便。 **但是，其缺點也是比較明顯的：** * 所有模組耦合在一起，雖然對於小型專案來說，維護方便。但是，對於大型專案來說，卻是不易開發和維護的。 * 專案的各模組之前過於耦合，如果一旦有一個模組出現問題，則整個專案將不可用。 * 無法針對某個具體模組來提升效能。 * 無法對專案進行水平擴充套件。 正是由於單體應用架構存在著諸多的缺點，才逐漸演變為垂直應用架構。接下來，我們就來看看垂直應用架構。 ## 垂直應用架構 隨著企業業務的不斷髮展，發現單節點的單體應用不足以支撐業務的發展，於是企業會將單體應用部署多份，分別放在不同的伺服器上。但是，此時會發現不是所有的模組都會有比較大的訪問量。如果想針對專案中的某些模組進行優化和效能提升，此時對於單體應用來說，是做不到的。於是乎，垂直應用架構誕生了。 垂直應用架構，就是將原來一個專案應用進行拆分，將其拆分為互不想幹的幾個應用，以此來提升系統的整體效能。 這裡，我們同樣以電商系統為例，在垂直應用架構下，我們可以將整個電商專案拆分為：電商交易系統、後臺管理系統、CMS管理系統等。  我們將單體應用架構拆分為垂直應用架構之後，一旦訪問量變大，我們只需要針對訪問量大的業務增加伺服器節點即可，無需針對整個專案增加伺服器節點了。 **這種架構的優點：** * 系統進行了拆分，可根據不同系統的訪問情況，有針對性的進行優化。 * 能夠實現應用的水平擴充套件。 * 各系統能夠分擔整體訪問的流量，解決了併發問題。 * 一個系統發生了故障，不應用其他系統的執行情況，提高了整體的容錯率。 **這種架構的缺點：** * 拆分後的各系統之間相對比較獨立，無法進行互相呼叫。 * 各系統難免存在重疊的業務，會存在重複開發的業務，後期維護比較困難。 ## 分散式架構 我們將系統演變為垂直應用架構之後，當垂直應用越來越多，重複編寫的業務程式碼就會越來越多。此時，我們需要將重複的程式碼抽象出來，形成統一的服務供其他系統或者業務模組來進行呼叫。此時，系統就會演變為分散式架構。 在分散式架構中，我們會將系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層呼叫，表現層則負責處理與頁面的互動操作。  **這種架構的優點：** * 將重複的業務程式碼抽象出來，形成公共的訪問服務，提高了程式碼的複用性。 * 可以有針對性的對系統和服務進行效能優化，以提升整體的訪問效能。 **這種架構的缺點：** 系統之間的耦合度變高，呼叫關係變得複雜，難以維護。 ## SOA架構 在分散式架構下，當部署的服務越來越多，重複的程式碼就會越來越多，對於容量的評估，小服務資源的浪費等問題比較嚴重。此時，我們就需要增加一個統一的排程中心來對叢集進行實時管理。此時，系統就會演變為SOA（面向服務）的架構。  **這種架構的優點：** 使用註冊中心解決了各個服務之間的服務依賴和呼叫關係的自動註冊與發現。 **這種架構的缺點：** * 各服務之間存在依賴關係，如果某個服務出現故障可能會造成服務的雪崩（關於穿透、擊穿和雪崩的問題，小夥伴們可以參見我之前寫的《[【高併發】面試官：講講什麼是快取穿透？擊穿？雪崩？如何解決？](https://mp.weixin.qq.com/s?__biz=Mzg3MzE1NTIzNA==&mid=2247487291&idx=1&sn=8411af97516c65a04ce7079ad47586d0&chksm=cee510f6f99299e0059e9e9a2e38cfe22e4f894863f24b52c7d0335ed9104f0e1fb24e6d16d7&token=1975056470&lang=zh_CN#rd)》一文）。 * 服務之間的依賴與呼叫關係複雜，測試部署的困難比較大。 ## 微服務架構 隨著業務的發展，我們在SOA架構的基礎上進一步擴充套件，將其徹底拆分為微服務架構。在微服務架構下，我們將一個大的專案拆分為一個個小的可以獨立部署的微服務，每個微服務都有自己的資料庫。  **這種架構的優點：** * 服務徹底拆分，各服務獨立打包、獨立部署和獨立升級。 * 每個微服務負責的業務比較清晰，利於後期擴充套件和維護。 * 微服務之間可以採用REST和RPC協議進行通訊。 **這種架構的缺點：** * 開發的成本比較高。 * 涉及到各服務的容錯性問題。 * 涉及到資料的一致性問題。 * 涉及到分散式事務問題（小夥伴們可以參見我後續會持續更新的【[分散式事務](https://mp.weixin.qq.com/mp/appmsgalbum?action=getalbum&__biz=Mzg3MzE1NTIzNA==&scene=1&album_id=1393709600402374656&count=3#wechat_redirect)】專題）。 **好了，今天我們就到這兒吧，我是冰河，我們下期見！！** ## 重磅福利 微信搜一搜【冰河技術】微信公眾號，關注這個有深度的程式設計師，每天閱讀超硬核技術乾貨，公眾號內回覆【PDF】有我準備的一線大廠面試資料和我原創的超硬核PDF技術文件，以及我為大家精心準備的多套簡歷模板（不斷更新中），希望大家都能找到心儀的工作，學習是一條時而鬱鬱寡歡，時而開懷大笑的路，加油。如果你通過努力成功進入到了心儀的公司，一定不要懈怠放鬆，職場成長和新技術學習一樣，不進則退。如果有幸我們江湖再見！ 另外，我開源的各個PDF，後續我都會持續更新和維護，感謝大家長期以來對冰河的支援！！