隨着互聯網的發展,互聯網企業的業務也在不斷的飛速發展,進而致使系統的架構也在不斷的發生着變化。整體來講,系統的架構大體經歷了:單體應用架構—>垂直應用架構—>分佈式架構—>SOA架構—>微服務架構的演變。固然,不少互聯網企業的系統架構已經向Service Mesh(服務化網格)演變。今天,咱們就一塊兒來聊聊關於系統架構的演變這個話題。程序員
在企業發展的初期,通常公司的網站流量都比較小,只須要一個應用,將全部的功能代碼打包成一個服務,部署到服務器上就能支撐公司的業務。這樣也可以減小開發、部署和維護的成本。面試
好比,你們都很熟悉的電商系統,裏面涉及的業務主要有:用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊,初期咱們會將全部模塊寫到一個Web項目中,而後統一部署到一個Web服務器中。數據庫
這種架構特色有其優勢:緩存
可是,其缺點也是比較明顯的:性能優化
正是因爲單體應用架構存在着諸多的缺點,才逐漸演變爲垂直應用架構。接下來,咱們就來看看垂直應用架構。服務器
隨着企業業務的不斷髮展,發現單節點的單體應用不足以支撐業務的發展,因而企業會將單體應用部署多份,分別放在不一樣的服務器上。可是,此時會發現不是全部的模塊都會有比較大的訪問量。若是想針對項目中的某些模塊進行優化和性能提高,此時對於單體應用來講,是作不到的。因而乎,垂直應用架構誕生了。微信
垂直應用架構,就是將原來一個項目應用進行拆分,將其拆分爲互不想幹的幾個應用,以此來提高系統的總體性能。架構
這裏,咱們一樣以電商系統爲例,在垂直應用架構下,咱們能夠將整個電商項目拆分爲:電商交易系統、後臺管理系統、CMS管理系統等。併發
咱們將單體應用架構拆分爲垂直應用架構以後,一旦訪問量變大,咱們只須要針對訪問量大的業務增長服務器節點便可,無需針對整個項目增長服務器節點了。app
這種架構的優勢:
這種架構的缺點:
咱們將系統演變爲垂直應用架構以後,當垂直應用愈來愈多,重複編寫的業務代碼就會愈來愈多。此時,咱們須要將重複的代碼抽象出來,造成統一的服務供其餘系統或者業務模塊來進行調用。此時,系統就會演變爲分佈式架構。
在分佈式架構中,咱們會將系統總體拆分爲服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用,表現層則負責處理與頁面的交互操做。
這種架構的優勢:
這種架構的缺點:
系統之間的耦合度變高,調用關係變得複雜,難以維護。
在分佈式架構下,當部署的服務愈來愈多,重複的代碼就會愈來愈多,對於容量的評估,小服務資源的浪費等問題比較嚴重。此時,咱們就須要增長一個統一的調度中心來對集羣進行實時管理。此時,系統就會演變爲SOA(面向服務)的架構。
這種架構的優勢:
使用註冊中心解決了各個服務之間的服務依賴和調用關係的自動註冊與發現。
這種架構的缺點:
隨着業務的發展,咱們在SOA架構的基礎上進一步擴展,將其完全拆分爲微服務架構。在微服務架構下,咱們將一個大的項目拆分爲一個個小的能夠獨立部署的微服務,每一個微服務都有本身的數據庫。
這種架構的優勢:
這種架構的缺點:
好了,今天咱們就到這兒吧,我是冰河,咱們下期見!!
微信搜一搜【冰河技術】微信公衆號,關注這個有深度的程序員,天天閱讀超硬核技術乾貨,公衆號內回覆【PDF】有我準備的一線大廠面試資料和我原創的超硬核PDF技術文檔,以及我爲你們精心準備的多套簡歷模板(不斷更新中),但願你們都能找到心儀的工做,學習是一條時而鬱鬱寡歡,時而開懷大笑的路,加油。若是你經過努力成功進入到了心儀的公司,必定不要懈怠放鬆,職場成長和新技術學習同樣,不進則退。若是有幸咱們江湖再見!
另外,我開源的各個PDF,後續我都會持續更新和維護,感謝你們長期以來對冰河的支持!!