為什么要用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
