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