為什么要用springcloud?
在回答這個問題之前我們要了解什么是微服務架構，以及這些年系統架構的演變程序
什么是微服務架構
“微服務 ”一詞源于Martin Fowler 的名為 Microservices 的博文，簡單地說， 微服務是系統架構上的一種設計風格， 它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的行程中運行，服務之間通過基于HTTP的RESTful API進行通信協作， 被拆分成的每一個小型服務都圍繞著系統中的某一項或一些耦合度較高的業務功能進行構建， 并且每個服務都維護著自身的資料存盤、 業務開發、自動化測驗案例以及獨立部署機制， 由千有了輕量級的通信協作基礎， 所以這些微服務可以使用不同的語言來撰寫，
系統架構的演變程序
架構原始階段：萬能的單機
架構的最原始階段，即一臺服務器搞定一切，傳統官網、論壇等應用，只需要一臺，對應的web服務器、資料庫、靜態檔案資源等，部署到一臺服務器上即可，一般5萬pv到30萬pv訪問量，結合內核引數調優、web應用性能引數調優、資料庫調優，基本上能夠穩定的運行，
架構動靜分離階段：靜態快取 + 檔案存盤
//nginx動靜分離
server {
listen 80;
server_name ds.oldxu.com;
location / {
proxy_pass http://127.0.0.1:8080;
}
location ~* \.(png|gif|jpg|mp4)$ {
root /images;
expires 1d;
}
}
當訪問壓力達到100萬pv到300萬pv的時候，我們看到前端web服務出現性能瓶頸，大量的web請求被堵塞，同時服務器的CPU、磁盤IO、帶寬都有壓力，這時候我們一方面將網站圖片、js、css、html及應用服務相關的檔案存盤在oss中，另外一方面通過CDN將靜態資源分布式快取在各個節點實作“就近訪問”，通過將動態請求、靜態請求的訪問分離（“動靜分離”），有效解決服務器在磁盤IO、帶寬方面的訪問壓力，
架構分布式階段：業務拆分 負載均衡
當訪問量達到1000萬pv到5000萬pv，雖然“動靜分離”有效分離了靜態請求的壓力，但是動態請求的壓力已經讓服務器“吃不消”，最直觀的現象是，前端訪問堵塞、延遲、服務器行程增多、cpu100%，并且出現常見502/503/504的錯誤碼，顯然單臺web服務器已經滿足不了需求，這里需要通過負載均衡技術增加多臺web服務器（對應ECS可以選擇不同可用區，進一步保障高可用），因而告別單機的時代，轉變分布式架構的階段，
雖然這個時候我們可以看到通過分布式檔案系統OSS已經解決了檔案存盤的性能問題，CDN也已經解決靜態資源訪問的性能問題，但是當訪問壓力再次增加，這個時候web服務器和資料庫方面依舊是瓶頸，在此我們通過垂直擴展，進一步切分web服務器和資料庫的壓力，解決性能問題，
在業務層，可以把不同的功能模塊拆分到不同的服務器上面進行單獨部署，比如，用戶模塊、訂單模塊、商品模塊等，拆分到不同服務器上面部署，在資料庫層，當結合資料庫快取，資料庫壓力還是很大的時候，我們通過讀寫分離的方式，進一步切分及降低資料庫的壓力，
結合業務拆分、讀寫分離，在資料庫層，比如我們同樣可以把用戶模塊、訂單模塊、商品模塊等，所涉及的資料庫表：用戶模塊表、訂單模塊表、商品模塊表等，分別存放到不同資料庫中，如用戶模塊庫、訂單模塊庫、商品模塊庫等，然后把不同資料庫分別部署到不同服務器中，
當訪問量達到5000萬pv及以上時，真達到千萬級架構以上訪問量的時候，我們可以看到垂直擴展的架構也已經開始“山窮水盡”，比如，讀寫分離僅解決“讀”的壓力，面對高訪問量，在資料庫“寫”的壓力上面“力不從心”，出現性能瓶頸，另外，分庫雖然將壓力拆分到不同資料庫中，但單表的資料量達到TB級別以上，顯然已經達到傳統關系型資料庫處理的極限，
當前主流架構面臨的問題
- 由于單體系統部署在一個行程內，功能模塊之間耦合性強相互影響，
應用中的這些功能模塊的使用場景、并發量、消耗的資源型別都各有不同，這樣使得我們對各個業務模塊的系統容量很難給出較為準確的評估， - 隨著系統功能越來越復雜， 相應的應用也不斷增加，我們的靜態配置就會變得越來越難以維護，并且面對不斷發展的業務，我們的集群規模、服務的位置 、服務的命名等都有可能發生化，如果還是通過手工維護的方式，那么極易發生錯誤或是命名沖突等問題，同時，對于這類靜態內容的維護也必將消耗大量的人力，
- Nginx等設施的路由實作負載均衡需要運維人員需要手工維護這些路由規則與服務實體串列，當有實體增級訓是IP地址變動等情況發生的時候， 也需要手工地去同步修，果當系統規模不斷增大， 那么這些看似簡單的維護 任務會變得越來越難， 并且出現配置錯誤的概率也會逐漸增加，
- 單體應用中都實作一套校驗邏輯，隨著服務規模的擴大，這些校驗邏輯的冗余變得越來越多，給開發和測驗人員都造成困擾，
springCloud
SpringCloud專案不同于其他 Spring 的優秀專案， 它不再是一個基礎框架類， 而是
一個更高層次的、 架構視角的綜合性大型專案， 其目標旨在構建一套標準化的微服務解決
方案， 讓架構師、 開發者在使用微服務理念構建應用系統的時候， 面對各個環節的問題都
可以找到相應的組件來處理， 參考網友戲稱的一個比喻： Spring Cloud 可以說是 Spring 社
區為微服務架構提供的一個
“ 全家桶 ” 套餐， 由于 “ 套餐 ” 中的組件通過一個社區進行包
裝與整合， 使得 “ 套餐 ” 中各個組件之間的配合變得更加和諧， 這可以有效減少我們在組
件的選型和整合上花費的精力， 所以它可以幫助我們快速構建起基礎的微服務架構系統，
考慮 Spring Cloud 的原因有如下幾點：
- Spring Cloud 來源于 Spring，質量、穩定性、持續性都可以得到保證，
- spirng Cloud 天然支持 Spring Boot，更加便于業務落地，
- Spring Cloud 是 Java 領域最適合做微服務的框架，相比于其它框架，Spring Cloud 對微服務周邊環境的支持力度最大，對于中小企業來講，使用門檻較低，
- Spring Cloud 是微服務架構的最佳落地方案，
- 與分布式系統相關的復雜性 – 包括網路問題，延遲開銷，帶寬問題，安全問題，
- 處理服務發現的能力 – 服務發現允許集群中的行程和服務找到彼此并進行通信，
- 解決冗余問題 – 冗余問題經常發生在分布式系統中，
- 負載平衡 – 改進跨多個計算資源（例如計算機集群，網路鏈接，中央處理單元）的作業負載分布，
- 減少性能問題 – 減少因各種操作開銷導致的性能問題，
SpringCloud
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/174982.html
標籤：Java
上一篇：JVM 學習筆記記錄