香蕉云编原创发布日期：2019-7-21
阿里的dubbo是较早流行的微服务框架，那么目前流行的spring cloud对于dubbo有什么优势呢？或者说dubbo对spring cloud又有什么特点呢？小编在这篇文章讨论这两个问题。
1、在通信的性能方面，dubbo要优于spring cloud，spring cloud的微服务走的通信协议是http协议，而dubbo是长连接nio通信方式。究竟长连接nio跟http协议有什么区别呢？http是短连接协议，返回数据后立即断开，也就是每请求一次，都必须重新建立连接，建立握手等过程；而dubbo的长连接nio的通信模式，确保网关和服务，服务和服务之间的通信通道是一直处于连接状态，无需重复建立连接，因此数据传输的速度是快很多的。不过对于现在计算机的处理速度来说，这种连接的建立速度人们很难感受得到。
2、spring cloud比dubbo的可用组件要多，dubbo的作用仅是服务治理，而spring cloud却有微服务的一整套解决方案，比如服务跟踪、断路由、分布式配置、消息总线等等。比如某个功能希望所有微服务都接受到同一个消息，比如同时更新一个配置文件，就可以使用消息总线实现。而dubbo要实现这些，则需要开发者自己去编写这些功能，比如断路由这些功能，开发者需要写很多的try catch去实现。
3、spring cloud的微服务的编写通过restful url实现，数据传输采用json实现，因此从开发的方便性和跨平台性方面有天然的优势。可以跨系统、甚至跨开发语言调用微服务，而dubbo属于强类型的接口类型，消费端的接口文件和pojo等文件必须跟服务端的接口文件和pojo版本一致。
4、在服务网关方面，dubbo需要开发者自己去实现web服务网关，比如通过前置spring boot的web应用网关实现，而spring cloud则可以选择zuul网关，或前置web应用网关实现。不过，笔者在这里不建议大家使用zuul，因为笔者觉得假如使用了zuul，因为zuul仅仅做路由转发，那么系统的session管理或token管理就需要交给下游的微服务去做管理。这样跟服务应该无状态化的理念是有冲突的。
服务应该无状态化是什么意思呢？比如两个不同的子系统A和B，这两个子系统的角色、权限和session的实现都是不一致的，但假如这两个系统都需要调用微服务A，假如使用zuul，那么session的管理就需要微服务A去实现，那么微服务A就需要去判断两种session体系。假如以后还要兼容子系统C，那么微服务A以后还需要修改，达不到解耦的效果，造成原子服务的耦合度非常高。因此，笔者不建议直接使用zuul当web服务网关，笔者建议前置一个（或nginx加多个网关ha负载均衡）自编写的web服务网关，web服务网关去负责session的读取和写入等管理，去负责应用的访问权限管理，而不将session和权限等判断逻辑交由下游的微服务做管理。这样服务的调用就灵活很多了，能兼容大部分的异构系统，也无需关心对方异构系统的session机制
