傳統架構到分佈式架構詳解 前端
軟件架構演進
軟件架構的發展經歷了從單體架構、垂直架構、SOA架構到微服務架構的過程，博客裏寫到了這四種架構的特色以及優缺點分析，我的學習之用，僅供參考！java
1.1.1 單體架構
算法
特色：
一、全部的功能集成在一個項目工程中。
二、全部的功能打一個war包部署到服務器。
三、應用與數據庫分開部署。
四、經過部署應用集羣和數據庫集羣來提升系統的性能。數據庫
優勢：
一、項目架構簡單，前期開發成本低，週期短，小型項目的首選。緩存
缺點：
一、所有功能集成在一個工程中，對於大型項目不易開發、擴展及維護。
二、系統性能擴展只能經過擴展集羣結點，成本高、有瓶頸。
三、技術棧受限。服務器
1.1.2 垂直架構架構
特色
當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。負載均衡
優勢：
一、項目架構簡單，前期開發成本低，週期短，小型項目的首選。
二、經過垂直拆分，原來的單體項目不至於無限擴大。
三、不一樣的項目可採用不一樣的技術。框架
缺點：
一、所有功能集成在一個工程中，對於大型項目不易開發、擴展及維護。
二、系統性能擴展只能經過擴展集羣結點，成本高、有瓶頸。分佈式
1.1.3 SOA架構
面向服務架構，如dubbo
優勢：
把模塊拆分，使用接口通訊，下降模塊之間的耦合度
把項目拆分紅若干個子項目，不一樣的團隊負責不一樣的子項目
增長功能時只須要在增長一個子項目，調用其它系統的接口就能夠
能夠靈活的進行分佈式部署
缺點：
系統之間交互須要使用遠程通訊，接口開發增長工做量
1.1.4 微服務架構
特色：
一、將系統服務層徹底獨立出來，並將服務層抽取爲一個一個的微服務。
二、微服務遵循單一原則。
三、微服務之間採用RESTful等輕量協議傳輸。
優勢：
一、服務拆分粒度更細，有利於資源重複利用，提升開發效率。
二、能夠更加精準的制定每一個服務的優化方案，提升系統可維護性。
三、微服務架構採用去中心化思想，服務之間採用RESTful等輕量協議通訊，相比ESB更輕量。
四、適用於互聯網時代，產品迭代週期更短。
缺點：
一、微服務過多，服務治理成本高，不利於系統維護。
二、分佈式系統開發的技術成本高（容錯、分佈式事務等），對團隊挑戰大。
要解決的技術難點：
一、這麼多服務，怎麼找?
經過zookeeper作服務註冊信息的分佈式管理。當服務上線時，服務提供者將本身的服務信息註冊到ZK，並經過心跳維持長連接，實時更新連接信息。服務調用者經過ZK尋址，根據可定製算法，找到一個服務，還能夠將服務信息緩存在本地以提升性能。當服務下線時，ZK會發通知給服務客戶端。
主流的註冊中心：zookeeper、Eureka、consul、etcd
二、服務之間如何通訊？
由於全部的微服務都是獨立的Java進程跑在獨立的虛擬機上，因此服務間的通訊就是IPC（inter process communication），已經有不少成熟的方案。好比基於HTTP的REST或者Thrift
三、這麼多服務，服務掛了怎麼辦？ 重試機制熔斷機制限流/降級負載均衡