[轉]Spring Cloud在國內中小型公司能用起來嗎？

原文地址：http://www.cnblogs.com/ityouknow/p/7508306.html

原文地址：https://www.zhihu.com/question/61403505

今天吃完飯休息的時候瞎逛知乎，忽然看到這個一個問題Spring Cloud在國內中小型公司能用起來嗎？，吸引了個人注意。仔細的看了題主的問題，發現這是一個好問題，題主通過了一番思考，而且用圖形全面的將本身的疑問表達了出來，做爲一個研究並使用Spring Boot和Spring Cloud近兩年的程序員，看的我手癢癢不答不快呀。

好問題

好問題必須配認真的回答，仔細的看了題主的問題，發現這個問題很是具備表明性，多是廣大網友想使用Spring Cloud卻又對Spring Cloud不太瞭解的共同想法，題主對Spring Cloud使用的方方面面都進行過了思考，包括市場，學習、先後端、測試、配置、部署、開發以及運維，下面就是題主本來的問題：

想在公司推廣Spring Cloud，但我對這項技術還缺少了解,畫了一張腦圖，總結了種種問題。

微服務是這樣一個結構嗎?

前端或二方 - > ng集羣 -> zuul集羣 -> eureka-server集羣 -> service provider集羣

（二方指其餘業務部門）

想要明白這個問題，首先須要知道什麼是Spring Boot，什麼是Spring Cloud，以及二者之間有什麼關係？

什麼是Spring Boot

Spring Boot簡化了基於Spring的應用開發，經過少許的代碼就能建立一個獨立的、產品級別的Spring應用。 Spring Boot爲Spring平臺及第三方庫提供開箱即用的設置，這樣你就能夠有條不紊地開始。多數Spring Boot應用只須要不多的Spring配置。

Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員再也不須要定義樣板化的配置。用個人話來理解，就是Spring Boot其實不是什麼新的框架，它默認配置了不少框架的使用方式，就像maven整合了全部的jar包，Spring Boot整合了全部的框架（不知道這樣比喻是否合適）。

Spring Boot的核心思想就是約定大於配置，一切自動完成。採用Spring Boot能夠大大的簡化你的開發模式，全部你想集成的經常使用框架，它都有對應的組件支持。若是你對Spring Boot徹底不瞭解，能夠參考個人這篇文章：Springboot(一)：入門篇

什麼是Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。Spring並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

微服務是能夠獨立部署、水平擴展、獨立訪問（或者有獨立的數據庫）的服務單元，Spring Cloud就是這些微服務的大管家，採用了微服務這種架構以後，項目的數量會很是多，Spring Cloud作爲大管家就須要提供各類方案來維護整個生態。

Spring Cloud就是一套分佈式服務治理的框架，既然它是一套服務治理的框架，那麼它自己不會提供具體功能性的操做，更專一於服務之間的通信、熔斷、監控等。所以就須要不少的組件來支持一套功能，若是你對Spring Cloud組件不是特別瞭解的話，能夠參考個人這篇文章：springcloud(一)：大話Spring Cloud

Spring Boot和Spring Cloud的關係

Spring Boot 是 Spring 的一套快速配置腳手架，能夠基於Spring Boot 快速開發單個微服務，Spring Cloud是一個基於Spring Boot實現的雲應用開發工具；Spring Boot專一於快速、方便集成的單個微服務個體，Spring Cloud關注全局的服務治理框架；Spring Boot使用了默認大於配置的理念，不少集成方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基於Spring Boot來實現，能夠不基於Spring Boot嗎？不能夠。

Spring Boot能夠離開Spring Cloud獨立使用開發項目，可是Spring Cloud離不開Spring Boot，屬於依賴的關係。

Spring -> Spring Boot > Spring Cloud 這樣的關係。

回答

如下爲我在知乎的回答。

首先樓主問的這些問題都挺好的，算是通過了本身的一番思考，我剛好經歷了你所說的中小公司，且都使用Spring Cloud而且已經投產上線。第一家公司技術開發人員15人左右，項目實例 30多，第二家公司開發人員100人左右，項目實例達160多。

實話說Spring Boot、Spring Cloud仍在高速發展，技術生態不斷的完善和擴張，難免也會有一些小的bug，但對於中小公司的使用來將，徹底能夠忽略，基本均可以找到解決方案，接下來回到你的問題。

一、市場

據我所知有不少知名互聯網公司都已經使用了Spring Cloud，好比阿里、美團但都是小規模，沒有像我經歷的這倆家公司，業務線所有擁抱Spring Cloud；另外Spring Cloud並非一套高深的技術，普通的Java程序員通過一到倆個月徹底就能夠上手，但前期須要一個比較精通人的來帶隊。

二、學習

有不少種方式，如今Spring Cloud愈來愈火的狀況下，各類資源也愈來愈豐富，查看官方文檔和示例，如今不少優秀的博客在寫spirng cloud的相關教程，我這裏收集了一些Spring Boot和Spring Cloud的相關資源能夠參考，找到博客也就找到人和組織了。

• Spring Boot學習資料彙總：
• Spring Cloud學習資料彙總 ：

三、先後職責劃分

其實這個問題是每一個系統架構都應該考慮的問題，Spring Cloud只是後端服務治理的一套框架，惟一和前端有關係的是thymeleaf，Spring推薦使用它作模板引擎。通常狀況下，前端app或者網頁經過zuul來調用後端的服務，若是包含靜態資源也可使用nginx作一下代理轉發。

四、測試

Spring-boot-starter-test支持項目中各層方法的測試，也支持controller層的各類屬性。因此通常測試的步奏是這樣，首先開發人員覆蓋本身的全部方法，而後測試微服務內全部對外接口保證微服務內的正確性，再進行微服務之間集成測試，最後交付測試。

五、配置

session共享有不少種方式，好比使用tomcat sesion共享機制，但我比較推薦使用redis緩存來作session共享。徹底能夠分批引入，我在上一家公司就是分批過渡上線，新舊項目經過zuul進行交互，分批引入的時候，最好是新業務線先使用Spring Cloud，老業務作過渡，當徹底掌握以後在所有替換。若是隻是請求轉發，zuul的性能不必定比nginx低，可是若是涉及到靜態資源，仍是建議在前端使用nginx作一下代理。另外Spring Cloud有配置中心，能夠很是靈活的作全部配置的事情。

六、部署

多環境不一樣配置，Spring Boot最擅長作這個事情了，使用不一樣的配置文件來配置不一樣環境的參數，在服務啓動的時候指明某個配置文件便可，例如：java -jar app.jar --spring.profiles.active=dev就是啓動測試環境的配置文件；Spring Cloud 沒有提供發佈平臺，由於jenkins已經足夠完善了，推薦使用jenkins來部署Spring Boot項目，會省很是多的事情；灰度暫時不支持，可能須要本身來作，若是有多個實例，能夠一個一個來更新；支持混合部署，一臺機子部署多個是常見的事情。

七、開發

你說的包含html接口就是前端頁面吧，Spring Boot能夠支持，但其實也是Spring Mvc在作這個事情，Spring Cloud只作服務治理，其它具體的功能都是集成了各類框架來解決而已；excel報表能夠，其實除過swing項目外，其它Java項目均可以想象；Spring Cloud和老項目能夠混合使用，經過zuul來支持。是否支持callback，能夠經過MQ來實現，仍是強調Spring Cloud只是服務治理。

八、運維

Turbine、zipkin能夠用來作熔斷和性能監控；動態上下線某個節點能夠經過jenkins來實現；provider下線後，會有其它相同的實例來提供服務，Eureka會間隔一段時間來檢測服務的可用性；不一樣節點配置不一樣的流量權值目前還不支持。註冊中心必須作高可用集羣，註冊中心掛掉以後，服務實例會所有中止。

總結，中小企業是否能用的起來Spring Cloud，徹底取決於本身公司的環境，若是是一個技術活躍型的團隊就大膽的去嘗試吧，目前Spring Cloud是全部微服務治理中最優秀的方案，也是一個趨勢，將來一兩年可能就會像Spring同樣流行，早接觸早學習豈不更好。

但願能解答了你的疑問。

Spring Cloud 架構

咱們從總體來看一下Spring Cloud主要的組件，以及它的訪問流程

• 一、外部或者內部的非Spring Cloud項目都統一經過API網關（Zuul）來訪問內部服務.
• 二、網關接收到請求後，從註冊中心（Eureka）獲取可用服務
• 三、由Ribbon進行均衡負載後，分發到後端的具體實例
• 四、微服務之間經過Feign進行通訊處理業務
• 五、Hystrix負責處理服務超時熔斷
• 六、Turbine監控服務間的調用和熔斷相關指標

圖中沒有畫出配置中心，配置中心管理各微服務不一樣環境下的配置文件。

以上就是一個完整的Spring Cloud生態圖。

最後送一個完整示例的Spirng Cloud開源項目等你去spring-cloud-examples

 

----------------------------------------------分割線-----------------------------------------------------

----------------------------------------------分割線-----------------------------------------------------

----------------------------------------------分割線-----------------------------------------------------

 

做者：Harry Huang
連接：https://www.zhihu.com/question/61403505/answer/188118355
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

踩過一段時間Spring Cloud的坑，來強答一下。

結論：確定能用起來，可是要根據實際狀況判斷用的程度。

---

我基本嘗試架構了全套的Spring Cloud服務，包括和Spring Cloud深度關聯的Cloud Foundry。可是最終決策並無採起全套部署Spring Cloud方案。

其中幾點緣由說明一下：

1. 微服務

與Spring Cloud相關聯的，很核心的一個概念就是微服務。

微服務不適合解決企業類應用的架構問題，而是針對互聯網服務特別有效的解決方案。

互聯網業務的特性是模式簡單，服務量巨大。部分業務能夠深度解耦，在這種狀況下，微服務是一種行而有效的解決方案。

而企業業務深度耦合，不少業務都是事務性處理，任何單路微服務掛掉均可能致使整個事務的丟棄迴轉。在這種狀況下，事務性業務須要考慮如何在微服務架構上，將每一個微服務的業務都丟棄。

我在微服務概念普及以前，已經嘗試過幾回將服務微服務化（移動互聯網應用和遊戲服務以及企業業務），針對互聯網應用確實頗有效，可是針對遊戲和流程性很強的企業業務，並不成功（由於粒度沒法控制，最終結果是在微服務的粒度上，構建不少複合業務，數據分離存儲後，又有不少冗餘數據要重複存儲，避免過多的業務互相訪問）。

所以，我認爲採用微服務架構必需要根據實際問題具體考慮。有個核心點是Context is king。在Java裏面Context實例化採用的也不少，所以這點考慮相對容易。若是你的服務粒度之間能夠拋棄Context，實現徹底的無狀態訪問，那麼能夠考慮採用微服務結構。

2. Spring Cloud自己技術的有效性

最近Docker推出了內置的Docker Swarm Mode，能夠將若干機器聯合起來進行快速擴展訪問，而且自帶快捷的流量自動分發，在這點上，Zuul的做用就不明顯了，被縮減到主要是服務監控的做用。若是是將Zuul聯合Docker Swarm Mode以及前面再加一層Nginx或F5作SSL和流量分發，意義就更不明顯了。

Spring Cloud提出了一套技術解決方案（主要是基於Netflix的解決方案），可是這套技術並不必定是惟一的最佳解決方案。當新的服務提出時，Spring Cloud裏面的部分解決方案，可能就是過期的了。

另外，Spring Cloud的入門門檻，我認爲仍是很是高的，由於英文文檔寫的十分複雜，並且結構組織並很差。我從找到Tutorial開始一點一點常識部署，到最終對整個架構有一點比較完整的認識，前先後後大概花了半年的時間，而且其中大多數時候都是搞明白工做模式後，發現並不適合本身的業務模式使用，從而丟棄（傳說中的踩坑）。

迴歸本源，Spring Boot自己是神同樣的解決方案。但Spring Cloud還沒達到Spring Boot這個級別。舉個例子，Spring Cloud OAuth我認爲就是很不成熟的解決方案。我照着Spring Cloud OAuth本身寫了一套基於JPA的OAuth流程，發現本來的實現，很是受侷限（若是要使用自帶的數據庫那套代碼）；並且OAuth自己，雖然很適合作針對客戶的業務，但並不適合作企業內部的系統認證處理（這個是我我的的偏見，由於個人全部服務都是提供的REST API，並不指望在服務中嵌入任何H5代碼，可是這樣必然不符合OAuth第三方認證的模式）。

3. Spring Cloud與Cloud Foundry的聯繫

Cloud Foundry是一套很複雜的雲系統，運行在VMware或其餘雲虛擬服務上。而Spring Cloud官方提供的一些服務，包括Sagan項目案例，AB部署（官方叫藍綠部署）等，都是基於Cloud Foundry的。

我特地購買了128G內存，安裝VMware虛擬機後嘗試部署了這套方案。由於若是這套方案可行，那麼給客戶部署CF的私有云對我而言也是能夠接受的方案。

可是最終我並無成功的部署Cloud Foundry的服務，由於，它是在對硬件要求過高了（不加內存跑不起來，即便是測試部署，它也模式你是部署在公網環境，必需要有一套公網認證的Wildcard域名-幾萬一年。同時，Spring部署上去還必須對Java的運行包進行修改，以支持SSL訪問）。

評估下來，可能必需要組建一套真正的私有云機房，纔可以正常的部署Cloud Foundry服務。（涉及到的多是百萬級別的VMware購買費用，或者是組織團隊作一套OpenStack的解決方案）。而無論從哪一個方面考慮，若是針對中小企業私有云的話，我我的評估不出它帶來的超額的價值。

另一點，真的要部署到開放服務的話，我我的感受對比自建機房，選擇阿里雲等雲服務對絕大多數企業是更好的選擇（我是阿里雲腦殘粉）。

若是拋棄Cloud Foundry，我我的認爲Docker是很是好的替代方案。固然，不少功能須要本身來完成了，包括部署、AB部署等。

4. 目前個人方案

我目前徹底拋棄了Spring Cloud，只使用了Spring Boot。這樣最終服務是直接打成惟一的一個包。

部署的時候，採用Docker Swarm Mode，直接用Service模式，這樣能夠手動控制節點數量。

即便是小型私有云服務，在VMware機器上，虛擬出若干臺虛擬機，而後每臺虛擬機跑一個服務就足夠了。

這裏面要考慮的主要是存儲和數據庫服務。數據庫免費的能夠考慮Percona數據庫（也有一些坑，由於我本身製做的DockerFile，讓存儲文件掛載到NAS上）。不過業務量不大，單臺MySql也能夠。收費的，上Oracle這個就不說了。

另一個問題就是文件存儲和訪問的問題，在多臺機器下，NAS存儲幾乎是必選方案（若是你願意，虛擬一臺機器安裝NAS操做系統也能夠）。

其餘裏面你提到的一些問題：

1. Spring Cloud人才是否好招聘？

公司本身內部培養一我的便可，這個技術不須要太多人掌握。維護人員知道如何維護就能夠了。

2. Spring Cloud資料

網上主要是教程和官方文檔，更多的，目前主要靠本身踩坑。

3. Spring Cloud先後端劃分

這個跟自己的業務模式相關，我一直是先後端分離的，這樣便於移動端訪問。網頁端直接部署阿里雲OSS上，而後經過Api訪問服務器，極大下降了服務器的帶寬成本。

4. Spring Cloud微服務碎片化

微服務的粒度是本身控制的，並且這個控制很是難（這也是我採起微服務失敗以及再也不在企業項目中採起微服務架構的核心緣由）。記住一點，Context is king。

固然，若是人力充足，微服務也是能夠選擇的，靠人力完成服務解構，這樣極大便於以後的維護。

項目是能夠無限次重構的，只要有需求，在合適時機招聘人員來完成便可。

5. Session共享

個人模式是訪問Token來控制，有一個惟一的微服務來存儲和控制Token，其餘服務獲取訪問以後進行驗證和獲取用戶ID等信息。本身作的緣由是由於沒有采起Spring Cloud的服務，並且這項服務設計實現起來很是簡單，本身作自由度也很高。

這樣也能夠強行將全部服務RESTful化，便於服務的橫向擴展。

6. 多環境不一樣配置

Spring Boot只須要你有Java便可，別的都自帶。最好是跑在Docker裏面了，我本身維護了一套Docker的Image。

Spring Cloud發佈平臺，這個自帶的和Cloud Foundry深度相關，建議仍是看Docker，固然部署靠本身寫代碼了。若是基於Gradle或者Maven，自帶Docker插件，能夠和項目深度綁定。

7. Docker搞不定？

強行指派搞定，這個真沒那麼難

8. 混合部署

Docker自然支持

9. HTML代碼和UI接口

這個是Spring Boot的功能，Spring Cloud無論這塊

10. 和老系統整合

這個與Spring無關，若是你以前系統是REST的HTTP服務，那天然簡單得多。若是是特殊接口，那就要本身實現了。

11. 異步Callback

上MQ系統吧，和Spring Cloud也不要緊，和你本身實現相關。

運維

與Spring Cloud自然無關，和你選擇的部署模式相關。

Zuul和Nginx等技術對流量控制稍好一點，Docker Swarm Mode不少地方都仍是空白。