如何評價華為新開源的ServiceComb微服務框架？

01-13

ServiceComb和目前火熱的SpringCloud、Dubbo相比較有哪些吸引大家嘗試使用的地方？是否有潛在的使用危機？

好吧，同事告訴我居然我們的ServiceComb出現在知乎上了。作為從一開始就在負責ServiceComb的程序員，我來回答一下這個問題。

首先ServiceComb基於華為內部的CSE(Cloud Service Engine)框架開源而來，這個框架在華為內部已經存在了2年多，支撐了多個大型的商業項目。有相對傳統的企業級項目，也有類似手機應用這樣的互聯網屬性比較強的項目。並且在成為整個華為公司統一的微服務標準框架後，依然有越來越多的產品在逐漸使用它開發自己的微服務。然後在今年剛剛開源出來。雖然已經商用在了多個項目中，但是因為剛剛開源出來，所以我們低調地給它起了0.X這樣一個版本。。。但是Saga確實是屬於探索型的項目，因此給它一個0.X的版本並不冤屈。

對於通信性能，因為華為本身做通信起家，對於眾多的程序員和程序員出身的領導來說，他可以不知道啥叫微服務，他也可以不知道治理是啥意思，他甚至可以不會Java，但是說起通信、性能、網路、RPC，是個人都可以開一堂課。所以這個框架從一開始在內部使用就在性能上面廣受群狼的挑戰。大家都在各種場景下對它做各種性能測試，然後各種挑戰。。所以性能這塊，無論是REST還是highway都在性能這塊做足了功課。具體測試數據，各位可以自己試試。

對於啟動時間需要10s。。這個還請這位同學移步ServiceComb的社區，提個issue，大家一起分析一下為啥。我們這好像沒有那麼慢。

對於Go、C、ServiceMesh的支持，可以劇透一下，go的部分馬上就會開源出來。而C的部分，主要是內部使用，因為暫時沒有看到外部需求所以還沒有計劃開源。而Service Mesh，已經在華為公有雲的微服務引擎裡面上線，雖然不開源，但是全免費使用，可以隨意試用。

回答那位「看了幾眼」的同學，ServiceComb並不依賴zuul做gateway（同樣性能原因，zuul的性能在華為內部根本不會被列為考慮對象），ServiceComb裡面實現了一套Edge Service的開發框架，實現了zuul裡面的很多能力而且性能有很大提升，這部分也應用在了內部某大型系統中。感興趣的可以在社區裡面看一下。當然它同樣不阻礙你用zuul。我們實現了一個ServiceComb的DiscoveryClient。如果你希望用zuul，你可以按你原來的使用方法去用zuul一樣沒有問題。

「不用SpringBoot的原因」，這個問題本身就有問題，因為ServiceComb並不阻礙你用SpringBoot，也不阻礙你用SpringCloud。如果你用這兩個技術，可以把ServiceComb當做封裝好了的幾個starter，可以讓你更方便地構建你的應用，就像樓主同學所說，在ServiceComb裡面對Netflix OSS的一些組件做了很深度的集成和封裝，不像SpringCloud這樣一個大雜燴，在ServiceComb裡面從頭到尾進行了封裝。你可以把它想像成是提供了類似Fegin的標記式開發方式，提供了SpringMVC的開發方式，提供了JAXRS的開發方式，然後對於你來說，這就夠了，因為你用了這些開發方式開發了代碼以後，LB、Hystrix已經被封裝在後面了，你不用自己再去構建Command來用Hystrix。當然，如果你想自己擴展也可以。但是你也真的可以不用SpringBoot而只用ServiceComb。原因么，內部產品太多，各個團隊水平和情況各不相同，有的就是不願意用SpringBoot我們也沒辦法。動不動就說影響了他們幾個億的大買賣我們也很無奈啊。所以其實ServiceComb的第一個內部版本我們是依賴SpringBoot的，但是後面逐漸優化逐漸瘦身，開出來的版本已經不再強依賴SpringBoot了（注意，不依賴不表示不能一起用）。

對於Dubbo，微服務不是說好了「各個微服務用最適合的語言寫不能綁定語言」嗎？不是說好的「每個進程是一個微服務」嗎？所以我們認為它是一個非常優秀的SOA時代的RPC框架，但是就微服務而言，它還有一些問題。

對於那位說避免使用框架的同學，我覺得不同的應用有不同的主要要解決的問題。有很多東西可能你並不需要，那真的可以自己全盤控制沒有問題。但是如果你除了註冊發現外，還想處理多種的本地負載均衡策略，想去處理錯誤隔離、降級、熔斷，還想在各個點輸出Metrics信息供APM用，另外還需要tracing的能力，那我建議還是找一個（類似ServiceComb全部封裝好了的框架）或者根據自己的情況用多個框架，不要全部自己去寫，比較複雜容易出錯，而且維護起來比較麻煩。

那位同學說的「殺出重圍」什麼的，實在是言重了。。我們只是在不斷滿足所有用戶的需求，讓它更易用，更穩定而已。實在沒有想過要去打打殺殺。

評價一下華為的ServiceComb，我感覺我們這個團隊還有這個框架，沒有辦法的傳承了華為公司的氣質。我感覺就像是一個低調的程序員。一直在默默地完成著各方面提過來的各種需求，努力地守護著自己的代碼，不讓它出現一絲壞味道。但是讓這個程序員當著幾千人講話，他可能就會說「我覺得我們的東西做的挺好的」，然後就沒有然後了。

然而代碼就在那裡，不悲不喜，不增不減。不去取悅於人，也不會辜負了誰。

我們用了兩周時間基於ServiceComb搭了一個含有十來個微服務的demo應用，自己的感受如下：

優點：

1、開發快速，幾天時間就能搭起一個應用的架子

2、功能完善，內置的服務治理功能很齊備，各種規則的負載均衡、容錯與熔斷、流量控制、調用鏈追蹤都有了

3、服務契約可以用swagger描述，也可以簡單加個註解在代碼中聲明

4、vertx部署並且使用highway協議，相比SpringCloud而言TPS據說有30%以上的提升（沒有實測）

5、有分散式事務一致性方案Saga

缺點：

1、目前還是0.4版本，有些地方還可以更友好一些，比如介面參數直接禁用了HashMap

2、啟動有點慢，10秒以上是常態

3、Saga還不成熟，寫的是0.0.2版本，還算有自知之明

4、highway協議可以免費用，但是協議本身是私有的

ServiceComb也不是從頭全自己做的框架，裡面和SpringCloud一樣用了很多Netflix OSS的經過了考驗的包，但封裝得不錯，基本做到了開箱即用。目前支持JAVA和GO，C++部分以及Service Mesh據說也在做，等它1.0了我們考慮用在正式環境里。

瀉藥

我們現在已經去框架化了，要做什麼的話，盡量自己做

因為我們發現，用了框架之後，並不會真的簡化工程

相反遇到問題的時候，程序猿經常性會陷入一種茫然狀態

就是不懂問題出在哪裡，看源碼其實是最快的方式，但是因為源碼並不是程序猿自己寫的

所以很多時候就各種不知所措，而且客觀滴說

我個人並不認為很多源碼寫得有多好，相反，辣雞源碼比較多

這也很正常，都是人嘛，怎麼可能不犯錯

所以總有個感覺，還不如我自己做快

當然員工會有這樣那樣的問題，那這個時候一個好的架構就能體現出其作用來

一個好的架構，就是把責任和邊界切割清楚，讓每個人都能發揮自己的長處的同時

又不會有太大的破壞，所以為什麼微服務流行？就是因為微服務的架構切割方式合理

邊界清楚，每個人可以有一定的發揮空間，但又不會造成巨大的反嗜，因為邊界在那邊

所以適合搞微服務，當我們用微服務的架構來規劃好我們的系統之後

剩下的就程序猿自己發揮咯，其實你自己做一個也沒有什麼難度

微服務只是一個架構的思路，你完全可以根據你企業自身需要，自己擼一個

用別人的東西，多不爽啊

所以拒絕框架，從我做起

個人使用體會，和Spring Cloud和Dubbo比較優點是：

比Spring Cloud靈活，輕量，雖然實現上都是使用了Netflix的ribbon hystrix等若干微服務組件。ServiceComb早期的有個版本也是基於Spring Cloud做的，試圖借用Spring Boot的annotation，雖然省了代碼，但是用著不好用，這其實也是用Spring Cloud的一個感覺，不直接，不好用。
比Dubbo出來的晚，技術上比Dubbo更通用，提供的微服務治理手段更多，功能更強，擴展性也好一點。

和兩者比較缺點是：因為出來的晚，所以成熟度差一些。

現在菊廠貌似在這個項目上投入挺多的，原來是個內部項目，現在開源出來了。方向正確，結果應該值得期待。

我始終認為Spring Cloud 社區一味地堅持rest是不明智的。他們搞出一個feign來把客戶端做成一個rpc調用的形式。Dubbo的那套遠程rpc明顯直接好用多了，卻被spring cloud社區看不上。

分散式服務明明可以做得更簡單直接，即使要支持多語言，也不用一定要堅持只能rest。

這方面ServiceComb是領先了Spring Cloud和Dubbo的。Dubbo的問題是和Java綁死了，而Spring Cloud，則因為過度迷信rest導致性能和易用性上做出了很大犧牲。

作為一個同時用過並研究過Spring Cloud和Dubbo，並且是ServiceComb早期主要開發者，我可以說，由於它的後發優勢，ServiceComb做的比前兩者都好。

這個項目我做了大概半年的時間，後來工作調整我搞其他東西去了。過了幾個月，我有一個同學告訴我他們部門要他們切換CSE(ServiceComb的閉源版本)，他一開始覺得部門領導傻逼已經有了spring cloud了用這玩意幹嘛。兩個月以後我問他情況，他告訴我，這個框架的功能和易用性已經比直接使用spring cloud要好。

「微服務」技術正處於方興未艾之際，到底是華為的ServiceComb能夠突出重圍，殺出一條「血路」來，還是阿里的Dubbo、zookeeper能夠獨佔鰲頭，亦或者Spring Boot、Spring Cloud大行其道、獨領風騷，這都很難說。

至於那個分散式服務框架更加優秀，要看後續這些框架誰能夠更好的解決企業中所遇到的問題了！

時間太短, 看了幾眼.

兼容Java和Go,

使用swagger來進行約束.

用zuul來做gateway

呃, 這貨的目的是啥, 給我一個不用springboot用這個的理由. 難道只是兼容go?