如何打造一个Dubbo网关--选型
Dubbo和SpringCloud有什么优缺点？应该如何选型？这里简单对比下：
SpringCloud必须在SpringBoot上运行，提供了一套完整的工具链，包括微服务开发中的方方面面Dubbo与Spring容器集成，只包括服务治理和rpcSpringCloud虽然说开箱即用，但是仍然会引入一些必须理解的组件和额外代码SpringCloud的服务端本质上就是一个运行起来的Spring容器，对外提供rest（http+json）服务Dubbo的服务端是一个单独的NettyServer，默认使用dubbo协议和单一tcpDubbo提供了一套自己的SPI机制可以方便的对常用功能进行扩展
当然两者也不是对立的可以同时使用，毕竟最常见的还是将Dubbo和SpringBoot部署在一起，这其实和SpringCloud部署在一起没有本质区别
我们想要什么
- 足够使用的项目足够稳定可靠并且易于理解，最好有大量的应用实例
- 开发使用要足够简单，尽可能的减少开发人员需要写的代码，不增加普通开发人员的心智负担
- 实体抽象问题，调用方和提供方最好依赖同一套实体，并且只由其中一方维护
- 前后端联调问题，最好有一套易于编写、管理和查看的接口文档
- 最后是性能，性能当然很重要，但rpc的序列化和传输耗时相比业务的阻塞代码不值一提
SpringCloud和Dubbo都是非常优秀且稳定的项目，但Dubbo是阿里的项目并且很长时间处于放弃维护状态
额外提一下，很多时候并不是不想在项目中使用异步或者rxjava之类的，但是在无法保证人员质量的情况下，同步代码是最好的选择
SpringCloud的优缺点
Eureka是一个AP系统，在微服务场景下显然高可用更加合适，同时是应用级注册
SpringCloud的提供方仍然是通过编写RestController提供http接口来提供服务的，只是调用方需要加上一些注解来提供更完整的rpc功能
Ribbon提供了客户端lb，需要从注册中心中读取可用服务列表，可以和RestTemplate配合手动调用，也可以和Feign配合进行声明式调用。但是无论如何都需要指明提供方的uri，大部分情况下是硬编码；另外如果提供方没有提供jar包共享实体就需要在调用方里再写一遍，而这并不是强制要求的
也就是说对于SpringCloud调用方和提供方是一个很松散的结构没有接口约束，只要uri正确并且提供方存在即可，这点有利也有弊：会出现很多粗心和意外错误、会增加沟通成本、很多问题要到调用时才发现、可以方便的跨语言
Ribbon提供了一定的可扩展性，可以实现一些高级操作，比如实现服务软分组
Swagger可以很方便的提供文档，但同样需要进行编码，而且编写方式非常不符合我的胃口。同时这些文档是分散的
为什么使用Dubbo及缺失
Dubbo的服务发现通常是Zookeeper，这是一个CP系统，而且是接口级注册，一旦应用接口数量巨大会给Zookeeper带来很大压力
Dubbo目前没有找到任何简单输出文档的方案，如果要用只能自己实现
那为什么要用Dubbo呢？不是因为kryo比json快多少，也不是因为单一长连接有多少好处，主要是不能接受SpringCloud需要进行uri硬编码，调用依赖uri而不是jar在各种实践上都不那么优雅和可靠
Dubbo的提供方是需要抽象出一个client层的，里边包含提供的接口和相关实体；这些类需要被打包成一个单独的jar并进入mvn仓库供调用方使用；调用方只需要在使用接口时加上注解即可，提供方也只需要实现接口即可；这个过程中只需要一个jar而不用定义uri，这显然符合我们的简单和抽象要求
那么Dubbo提供的接口如何给前端调用呢？前后端联调时文档怎么办呢？
接下来的几篇文章将会详细讲诉如何基于SpringCloudGateway搭建一个Dubbo网关和业务平台来解决上述的问题
如何打造一个Dubbo网关–泛化调用
如何打造一个Dubbo网关–软分组
如何打造一个Dubbo网关–用户注入
如何打造一个Dubbo网关–文档插件
如何打造一个Dubbo网关–文档生成
如何打造一个Dubbo网关–平台
如何打造一个Dubbo网关–数据源
如何打造一个Dubbo网关–组合调用
如何打造一个Dubbo网关–异常处理
如何打造一个Dubbo网关–模拟网关