關於spring cloud的一點點小懷疑？

02-12

公司業務發展，想朝著微服務的方向演進，查資料得知國內的dubbo和國外的spring cloud，dubbo已經廢棄，spring cloud蠻不錯，想請教下有哪些公司線上運行spring cloud超過一年的，分享下經驗。

更新一下吧，上次寫的比較隨意，重點強調的有問題。

spring cloud +docker 當然沒有問題，只是當我們搭建集群實現高可用的時候，覺得k8s對於我們的情況更適用（我們多半的應用都是非Jvm程序），但是可能最後還是會二者皆用。

我的意思並不是說k8s 與spring cloud衝突。我們使用這兩個技術的初衷都是為了實現應用的微服務化。然而對於微服務而言，有六個基本必須實現的1.進程通訊2.服務註冊與發現3.負債均衡4.配置中心5.熔斷器6.網關路由

其實兩者都用是一個不錯的解決方案。k8s和spring cloud 的出發點不同，一個是基於容器管理的概念，一個是基於程序的註冊與發現（我個人認為Netflix 的核心在於註冊中心）。二者都可以達到我們的目的。就拿實現一個高可用的註冊中心Eureka 來說，單純從Netflix的設計思想來說，eureka 是一個AP 系統，要保證數據的同步，可以採用註冊中心（Eureka server ）相互註冊的方案，實現一個集群，但是集群每加入一個節點，要更新所有的client的配置。常規的思想，我們可以通過負載均衡的輪詢演算法實現，然而這個思路正是k8s 的出發點。可能Spring Cloud +K8s二者皆用是一個最好的方案，但是二者擇其一一樣可以達到目的。

……………………………………

研究SpringCloud有陣子了，搭建了一個springcloud微服務平台，昨天和公司的大牛們做了一下相關的技術分享，有了一些新的心得與體會，可能會推翻先前的所有工作吧。好處網上很多，我就不說了。實際過程中必然會遇到一些問題，Chris Richardson 微服務系列算是一個比較完善的理論前期支撐，裡面也有談到微服務會遇到的問題，我認為最大的問題還是運維部署問題吧！

總所周知，Spring cloud 的核心是Netflix微服務框架，非常成熟，但是在netflix oss開發初期，那個時候還沒有docker，我們現在所有的服務都是通過虛擬容器承載的。

Netflix OSS的許多內容都是在一個已經過去的年代寫出來的，那時所有東西都只能運行在AWS雲上而沒有其它選擇。關於那個年代的許多寶貴遺產和前提假設都已經被封裝到了Netflix的庫裡面，對於現在你運行的環境（比如Linux容器）已經不適用了。在Linux容器、Docker、容器管理系統等等出現之後，我們越來越看到把我們的微服務運行在Linux容器（公有雲、私有雲，或者都要，等等）里的巨大價值。另外，因為這些容器都是直接把這些服務打包起來、對外不透明的，所以我們傾向於不要過多關心在容器裡面運行的到底是什麼技術（是Java？還是Node.js？或者Go？）。Netflix

OSS主要是為Java開發者服務的，它是許多的庫、框架和配置的集合，你需要把它們包含在你的Java程序或服務代碼裡面。

就服務發現而言，netflix是使用eureka，用Netflix OSS（SpringCloud Netflix也是一樣的道理）時通常你要建立一台服務發現伺服器，讓所有可以被各種客戶端發現的服務註冊在這裡。比如你用Netflix Ribbon來與各種其它服務交互，就需要能找出來它們都運行在哪裡。各種服務可能下線，可能按它們自己的運行需要退出，也有可能我們要向集群中加入更多服務來做橫向擴展。這種集中式的服務發現註冊機制通常可以幫助我們跟蹤集群中有哪些服務是可用的。

問題之一是，做為一個開發人員你需要做這些事情：

決定我到底是想要一個AP系統（Consul、Eureka等）還是CP系統（ZooKeeper、etcd等等）。

想明白在上了規模時如何運行、管理和監控這些系統（這可不是一個小小的演示系統）。

而且，你要找到對應你使用的編程語言的客戶端庫，才能與服務發現機制通信。回到我們剛才討論的問題，微服務可能是用許多不同種語言實現的，所以可能一個成熟的Java客戶端庫好找，但相應的Go或Node.js庫就沒有了，那你只好自己寫一個。可對每一種語言和每一個程序員，他們都可能對怎麼實現這樣的客戶端庫有自己的想法，這樣你就會忙於維護各種不同的客戶端庫，做的事情功能都是一樣的可是實現邏輯卻各自不同。也有可能每種語言都會使用它自己的服務發現伺服器而且也有它自己現成的客戶端庫呢？所以你就要為每一種語言都管理和維護不同的服務發現伺服器嗎？（Netflix oss Prana和SpringCloud Netflix sidecar 可以支持跨語言，但還是存在一些局限性）

當然，以上提出的問題是很小的一個點，更大的還是先前說的運維部署問題，當拆分出了成百上千個服務，會出現很多瑣碎的問題，如Eureka高可用集群對clientService的配置問題。

令人欣喜的是，Kubernetes 貌似可以解決現在所遇到的問題，可能可以取代netflix的整套技術（只是可能，我也是今天開始調研的，有了新的進展再來談談Kubernetes 吧）

糾正一下，dubbo沒有廢棄，重新維護了~

我來說一些大家沒有說過的：關於Spring Cloud和Dubbo的選擇，並不是一定要排它的。

我們用Spring Cloud還是要多學習它在微服務架構中更為宏觀的設計考慮，比如spring boot actuator，配置管理，API網關這些設計。

如果我們已經有了dubbo，難道我們一定要推翻重來嗎？顯然並不是這樣的，最淺層次的，對於spring boot actuator的監控、spring cloud config的配置中心，spring cloud stream的非同步交互等都是可以直接整合一起玩的，因為這些都跟dubbo沒有衝突的。那麼更深層次一些，我們會考慮是否有必要擴展dubbo的註冊中心，採用consul？讓dubbo通過http協議來調用，讓spring cloud zuul可以直接對接這些介面？很顯然，這些都是可以做到的，但是對於之前說的淺層次的一些整合來說，對於您的團隊要求就更高了。

那麼不用dubbo，直接spring cloud好不好呢？這完全取決於團隊對spring cloud的掌握，目前來說，中文資料也已經非常多了，在做好技術架構之後，只要方案合理，我相信任何團隊都是可以跑起來的，但是用的溜不溜就看團隊水平了。因為一些高級的設計還是要自己去擴展的，比如網關的鑒權、灰度發布等等。另外，由於spring cloud的更新很快，我們需要維護幾個人去熟悉源碼，升級使我們經常要做的事，一方面是排bug，另一方面是增加功能。但是spring cloud也會犯錯，我就碰到過好幾次引升級應發的問題，都是更新版本觸發的新bug。

綜上所述，在選擇的時候，請務必根據自身團隊的實際情況來選擇，不論用什麼框架，姿勢很重要~

spring cloud 線上實踐三個月

使用了 eureka 、config server、zuul 作為服務網關，十幾個系統服務，系統服務通過 feign 進行同步調用，系統之間通過 rabbitmq 的消息進行非同步通知。

部署全面使用 docker，自己寫腳本自動化打包和部署。

系統輸出日誌到 ECS，再通過 ELK 收集並展示日誌。

實踐下來感覺很好用。

上面的一個長回答感覺有些問題額，

首先，spring cloud 的應用完全可以用docker 啊；其次，與服務註冊中心通信可以通過api 啊，並不需要費力的找庫；然後 Kubernetes 是容器方案啊，和 netflix oss 不衝突吧。。。。

我覺得你可以打消這個疑問了，因為我們就是在使用Spring Cloud並且已經超過一年。

先來說說Spring Cloud的優勢：

微服務的框架那麼多比如：dubbo、Kubernetes，為什麼就要使用Spring Cloud的呢？

產出於Spring大家族，Spring在企業級開發框架中無人能敵，來頭很大，可以保證後續的更新、完善。比如dubbo現在就差不多死了
有spring Boot 這個獨立幹將可以省很多事，大大小小的活Spring Boot都搞的挺不錯。
作為一個微服務治理的大傢伙，考慮的很全面，幾乎服務治理的方方面面都考慮到了，方便開發開箱即用。
Spring Cloud 活躍度很高，教程很豐富，遇到問題很容易找到解決方案
輕輕鬆鬆幾行代碼就完成了熔斷、均衡負責、服務中心的各種平台功能

Spring Cloud提供了微服務的一整套解決方案：服務發現註冊、配置中心、消息匯流排、負載均衡、斷路器、數據監控等

Spring Cloud對於中小型互聯網公司來說是一種福音，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發自己的分散式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減少開發成本。同時，隨著近幾年微服務架構和Docker容器概念的火爆，也會讓Spring Cloud在未來越來越「雲」化的軟體開發風格中立有一席之地，尤其是在目前五花八門的分散式解決方案中提供了標準化的、全站式的技術方案，意義可能會堪比當前Servlet規範的誕生，有效推進服務端軟體系統技術水平的進步。

也可以參考我在知乎的這個回答:spring cloud在國內中小型公司能用起來嗎？

我很熟啊，有問題問我啊，致力於springcloud融入阿里雲或者k8s的各種解決方案。。。。網路存儲cicd容器化等問題，儘管問。。。。包括springcloud源碼原理我也能說

protobuf 加 grpc 加自己寫的簡單服務註冊中心和配置中心。

可以很方便的跨不同編程語言。。

分享一下我的看法：

spring-cloud：在application層面上實現的微服務。

k8s:在CAAS層面上實現的微服務。

PCF：在PAAS層面上實現的微服務。

這些解決方案他們的目的都是一致的：實現微服務化的治理，但是他們是基於不同的切入點來實現的。

就好比我們日常coding中Concurrency的實現，不同的語言體系有不同的實現切入點：

JAVA是多線程同步

Nodejs是單線程非同步

實現的方式五花八門，但他們的目的都是一致，提升CPU，IO的利用率。

spring cloud出來沒多久，還不知道成熟不，感覺還是用成熟的框架靠譜點，坑也少點。可選的像dubbo和motan，服務治理方面都挺不錯的。性能更好的像thrift和gRpc之類的，不過就是服務治理弱。