隨著網際網路的發展，網際網路企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化。總體來說，系統的架構大致經歷了：單體應用架構—>垂直應用架構—>分布式架構—>soa架構—>微服務架構的演變。當然，很多網際網路企業的系統架構已經向service mesh(服務化網格)演變。今天，我們就一起來聊聊關於系統架構的演變這個話題。在企業發展的初期，一般公司的**流量都比較小，只需要乙個應用，將所有的功能**打包成乙個服務，部署到伺服器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。
比如，大家都很熟悉的電商系統，裡面涉及的業務主要有：使用者管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模組，初期我們會將所有模組寫到乙個web專案中，然後統一部署到乙個web伺服器中。
這種架構特點有其優點：
但是，其缺點也是比較明顯的：
正是由於單體應用架構存在著諸多的缺點，才逐漸演變為垂直應用架構。接下來，我們就來看看垂直應用架構。
隨著企業業務的不斷發展，發現單節點的單體應用不足以支撐業務的發展，於是企業會將單體應用部署多份，分別放在不同的伺服器上。但是，此時會發現不是所有的模組都會有比較大的訪問量。如果想針對專案中的某些模組進行優化和效能提公升，此時對於單體應用來說，是做不到的。於是乎，垂直應用架構誕生了。
垂直應用架構，就是將原來乙個專案應用進行拆分，將其拆分為互不想幹的幾個應用，以此來提公升系統的整體效能。
這裡，我們同樣以電商系統為例，在垂直應用架構下，我們可以將整個電商專案拆分為：電商交易系統、後台管理系統、cms管理系統等。
我們將單體應用架構拆分為垂直應用架構之後，一旦訪問量變大，我們只需要針對訪問量大的業務增加伺服器節點即可，無需針對整個專案增加伺服器節點了。
這種架構的優點：
這種架構的缺點：
我們將系統演變為垂直應用架構之後，當垂直應用越來越多，重複編寫的業務**就會越來越多。此時，我們需要將重複的**抽象出來，形成統一的服務供其他系統或者業務模組來進行呼叫。此時，系統就會演變為分布式架構。
在分布式架構中，我們會將系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層呼叫，表現層則負責處理與頁面的互動操作。
這種架構的優點：
這種架構的缺點：
系統之間的耦合度變高，呼叫關係變得複雜，難以維護。
在分布式架構下，當部署的服務越來越多，重複的**就會越來越多，對於容量的評估，小服務資源的浪費等問題比較嚴重。此時，我們就需要增加乙個統一的排程中心來對集群進行實時管理。此時，系統就會演變為soa（面向服務）的架構。
這種架構的優點：
使用註冊中心解決了各個服務之間的服務依賴和呼叫關係的自動註冊與發現。
這種架構的缺點：
隨著業務的發展，我們在soa架構的基礎上進一步擴充套件，將其徹底拆分為微服務架構。在微服務架構下，我們將乙個大的專案拆分為乙個個小的可以獨立部署的微服務，每個微服務都有自己的資料庫。
這種架構的優點：
這種架構的缺點：
好了，今天我們就到這兒吧，我是冰河，我們下期見！！
另外，我開源的各個pdf，後續我都會持續更新和維護，感謝大家長期以來對冰河的支援！！
MySQL如何支撐起億級流量
目錄 大部分網際網路業務都是讀多寫少，因此優先考慮db如何支撐更高查詢數，首先就需要區分讀 寫流量，這才方便針對讀流量單獨擴充套件，即主從讀寫分離。若前端流量突增導致從庫負載過高，dba會優先做個從庫擴容上去，這樣對db的讀流量就會落到多個從庫，每個從庫的負載就降了下來，然後開發再盡力將流量擋在db...
申通完美支撐「雙11」 億級包裹背後的雲基礎設施
今年雙11，申通的系統前所未有的流暢與平穩 雙11全站跑在阿里雲上，億級包裹洪峰過境，千萬級訂單毫秒級響應，系統穩如泰山。申通上雲的技術負責人方遙難掩驕傲地說。11月1日凌晨第一波訂單高峰到來，整個系統的響應很快，面對超過日常數倍的接單量，系統的響應時間沒有變化 在接單 自動化分揀 巴槍掃瞄 快件跟...
申通完美支撐「雙11」 億級包裹背後的雲基礎設施
簡介 億級包裹洪峰過境，千萬級訂單毫秒級響應，系統穩如泰山。今年雙11，申通的系統前所未有的流暢與平穩。今年雙11，申通的系統前所未有的流暢與平穩 雙11全站跑在阿里雲上，億級包裹洪峰過境，千萬級訂單毫秒級響應，系統穩如泰山。申通上雲的技術負責人方遙難掩驕傲地說。11月1日凌晨第一波訂單高峰到來，整...