Spring Cloud Alibaba到底坑不坑？

以前我發過一篇《說說我爲何看好Spring Cloud Alibaba》，而後這兩天有網友給我轉了這篇文章《坑爹項目spring-cloud-alibaba，咱們也來一個》，問個人見解是怎麼樣的，聊天時候簡單說了一下。今天在家休息，抽空整理一下內容，逐點說一下個人見解，主要仍是以爲這篇文章博眼球的成分高一些，由於這篇文章的解讀與以前其餘某些自媒體發佈的《Eureka 2.0 開源工做宣告中止，繼續使用風險自負》一文有殊途同歸之「妙」，若是讀者沒有真正的理解Spring Cloud與Spring Cloud Alibaba，就頗有可能會對它們有什麼誤解，而後產生這樣的想法：

• 感受頗有道理，這東西真垃圾
• 標題很燃，必須轉發

下面具體來講說該文章中，那些我認爲不太正確的解讀：

第一點：遠程調用RPC

看看這篇文章的解讀：

SpringCloud默認的是Feign和Ribbon，主要是提供了遠程調用請求和解析，以及負載均衡的功能。客觀點來講，若是不用這兩個組件，就會愈來愈四不像，乾脆也別叫SpringCloud了，因此替換不得。
RPC會大量使用動態代理的功能，將你的字符串或者配置（由於網絡傳輸方便）搞成動態的接口。

你也能夠寫一個RPC進行集成，有不少教程教你手擼一個。

爸爸版的集成了個dubbo，dubbo就是個RPC。因此你一用這玩意，其餘的一些關鍵組件也得跟着全套的換，組件就不叫組件了!

做者認爲Spring Cloud的負載均衡和遠程調用必須使用Feign和Ribbon，這是Spring Cloud的默認實現。若是換成Dubbo，就是四不像了。

說說個人想法：

第一點：Dubbo在融入Spring Cloud的時候，真的就是四不像嗎？若是真正看過Spring Cloud Alibaba以及理解Spring Cloud Common中的抽象的話，這個問題根本就不用去討論。Spring Cloud Alibaba Dubbo在實現的時候是兼容Feign的編程模型的。有興趣的讀者能夠看看小馬哥在該項目中的案例：

Github地址：https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-examples/spring-cloud-alibaba-dubbo-examples

第二點：Feign和Ribbon並非Spring Cloud的標準，它們也只是Netflix OSS中的組件。對於負載均衡，你們能夠了解一下spring-cloud-loadbalancer，它如今是Spring Cloud Common的一部分，這纔是真正的標準。對於Spring Cloud Alibaba在整合Dubbo的時候兼容Feign客戶端，已是很是有用戶意識了。

Github地址：https://github.com/spring-cloud-incubator/spring-cloud-loadbalancer

因此，做者到底有沒有看過Spring Cloud Alibaba Dubbo的方案？

第二點：註冊中心

看看這篇文章的解讀：

服務註冊中心是微服務的另一個必備組件，用來協調服務提供者和調用者的相互發現，SpringCloud默認的註冊中心是Eureka。

爸爸版的用的是Nacos。Nacos的更新目前來看仍是比較活躍的，但真沒有必要集成在一個Cloud中。Nacos最好的方式仍是獨立發佈，而後維護一個starter。開發者能夠按照本身公司的環境進行有選擇性的集成或替換。集成一個組件的成本是比較低的，遠遠低於刪掉一堆自覺得是的功能。

SpringCloud還能夠選擇Zookeeper，或者Consul，甚至Etcd等，進行註冊中心的搭建。目前，Eureka宣佈再也不維護後，Consul應該是首要選擇。

Consul自帶Dashboard和ACL，可以看到大多數你所關心的信息。爲了可以集成在咱們公司的體系中，你可能會開發一些後臺管理功能，進行更多的控制。這部分開發簡單，只須要作個界面，直接經過API讀取Consul的數據就能夠了。

說說個人想法：

第一點：註冊中心的選擇。對於Eureka再也不更新以後，到底選擇使用哪一個並無徹底的最優解，存在即合理，選擇適合本身團隊（技術棧、使用成本）的，纔是最須要考慮的點。

第二點：做者建議「Nacos最好的方式仍是獨立發佈，而後維護一個starter」。這確實是一個很好的建議，可是這點我就奇怪了，做者到底有沒有看過Nacos？Nacos目前就是獨立發佈的，Spring Cloud Alibaba對Nacos的支持，只是Nacos在客戶端應用中，針對Spring Cloud用戶的一種應用方式而已。

因此，做者到底有沒有看過Spring Cloud Alibaba Nacos的方案？

第三點：熔斷、限流

看看這篇文章的解讀：

這部分已經被炒做成微服務體系的必備組件，但捫心自問，這個功能對於中小型的應用可能就是一個擺設。但咱們仍是要搞的，由於這是個賣點。

SpringCloud默認的組件是Hystrix，提供了多線程和信號量來控制的不一樣方式。惋惜的是Hystrix也宣佈再也不維護了，官方推薦的替換版本是resilience4j。

熔斷限流功能實際上是很是簡單的，同事花了一週時間就擼了個足夠用的組件。這部分的主要設計在於可以簡單的應用，最好是可以經過後臺配置實時生效。

爸爸版的是Sentinel，雖然也帶了個後臺，可是並無和註冊中心進行集成，搞了個不三不四。

我要用Sentinel，我本身集成就行了，用你個大頭鬼。

說說個人想法：

第一點：我以爲做者能碰到一個能擼出熔斷、限流框架和配置管理的同事，仍是很是幸運的。可是並非全部的團隊都有人能夠作這些，因此我以爲有這樣的開源項目無論放在何時，都是對行業有益的。你不用沒啥問題，可是並不表明對別人沒用，並不表明這個項目不夠優秀。

第二點：對於做者所說的，沒有與註冊中心集成，搞得不三不四。這裏的不三不四，一直沒能Get到做者的點。。。不知道是否是有點「爲賦新詞強說愁」的感受？我的在對比Hystrix和Sentinel的時候，仍是以爲有很是多要比Hystrix作得更好的地方的。

固然真正應用到本身的架構體系中，一般都是須要作一些適配、自定義等工做的。可是，對於開源產品的擴展，歷來都不是用來抨擊開源項目的核心緣由。

第四點：集成本身的服務

這點是我通篇以爲最好笑的，先來看看做者對於AWS和Azure對Spring Cloud整合的讚美：

話說這aws，搞了個本身的SpringCloud，集成了本身的衆多的服務，相輔相成，賣的很好。因而Azure等，也搞了一套，只不過只能跑在本身的雲上。若是你用了，哪一天若是想換主機環境了，就會知道這些爸爸們是多麼的愛你。

可是到了Alibaba作這些，就成了：

重要的組件不集成，反而集成了一堆相似於OSS、ANS、SMS、MQ等非必須的功能，這就是偷奸耍滑了。

一樣是集成本身的商業服務來作好對客戶的支持，我以爲是任何一個廠商加強自身產品實力必需要作的。到底好很差，用戶說了算。

就拿我的而言，咱們也是阿里雲的客戶，對於OSS、RocketMQ這些必不可少的產品，若是提供Spring Cloud的Starter，讓我更好的使用它們。從用戶角度來講，省去了不少本身封裝的工做，有什麼很差呢？

總結

如今技術圈有個怪現象，自從一些技術自媒體人開始分享本身如何經過分享技術來賺錢開始，催生出了愈來愈多的技術自媒體。

而後就出現了這樣的奇葩現象：

• 沒有作過面試官的人在分享如何應對面試
• 沒有作過架構師的人在分享如何成爲架構師
• 沒有賺到錢的人在分享如何賺錢
• 不是中產的人在分享如何成爲中產
• ...

不能否認，作技術自媒體是能夠賺錢。可是單純爲了賺錢的技術自媒體，生搬硬套那些大V們分享的賺錢方法，爲了追求流量，會使用誇大表述、扭曲事實、傳播侵權內容、編故事博取同情等手段來得到關注和轉發。這使得不少技術內容的分享就變得不那麼純粹了，甚至會對讀者形成對技術內容的誤解。

我沒有能力去控制那些自媒體發佈這些不實的內容，可是在我瞭解的範圍內，仍是盡力輸出一些個人理解。但願能夠給這些誤讀內容不一樣的聲音，可以引發讀者的注意，從而但願你們能夠多一些本身的思考。

固然，個人觀點也不必定都是對的，因此無論讀者看到什麼內容，必定要保持本身的思考。當你發現網上有內容發生衝突的時候，惟一能夠解決的方式不是選擇一方去相信，仍是要本身去深刻研究，去驗證哪個觀點纔是正確的。

最後，聲明一點：我不是Spring Cloud Alibaba的成員，也不是阿里系公司的員工。對於Spring Cloud Alibaba的支持，只是我做爲一名奮鬥在一線的程序員的簡單思考。

若是您以爲我說的不對，很是歡迎能夠留言討論。

歡迎關注我長期連載的《Spring Cloud基礎教程》