駁“坑爹專案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地址：github.com/spring-clou…
第二點：Feign和Ribbon並不是Spring Cloud的標準，它們也只是Netflix OSS中的元件。對於負載均衡，大家可以瞭解一下spring-cloud-loadbalancer
，它現在是Spring Cloud Common的一部分，這才是真正的標準。對於Spring Cloud Alibaba在整合Dubbo的時候相容Feign客戶端，已經是非常有使用者意識了。
Github地址：github.com/spring-clou…
所以，作者到底有沒有看過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基礎教程》