欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

ServiceComb和目前火热的SpringCloud、Dubbo相比较

架构&设计模式 water 563℃ 0评论

首先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了我们考虑用在正式环境里。

转载请注明:学时网 » ServiceComb和目前火热的SpringCloud、Dubbo相比较

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!