dubbo和SpringCloud

一、我的看法

公司在使用dubbo实现了服务分离，最近常常在想，dubbo和springCloud之间到底是啥关系呢？嗯，下面有一些自己的看法：

二者的共同点：

         一、dubbo和springCloud的目标是一致的，拆分垂直架构，拆分臃肿业务，面向服务编程，实现快速敏捷部署。

         二、二者在架构上都支持了服务监控。

二者的区别：

         一、dubbo是SOA的产物，定位于rpc领域的解决方案，是微服务的重要一环；springCloud是微服务的产物，微服务是SOA继续服务化的一个总体。

         二、很显然，上边第一条中描述的dubbo仅仅专注于rpc框架，因此不可能有微服务中的网关（路由的能力，虽然dubbo有一点点，但是说不上是网关），熔断，限流等能力。

 

二、关于dubbo使用的一些心得

        一、所谓事不过三，对于查询类型的接口我们retry我们可以设置三次。

       二、超时时间可以设置长一点，视网络和具体业务而定，一般情况下，我们设置30s ~ 60s

       三、对于非幂等性的操作，通常情况下，最好不要重试，除非，业务逻辑中做了幂等方案。

       四、对于状态机，枚举值类（状态机，响应码，其他参数枚举）和通用工具类放在接口jar中，防止引用方出现魔鬼参数

       五、通常情况下，可以使用dubbo服务实现和外部第三方系统的交互，然后再套一层dubbo服务引用，这样对内部完全屏蔽外部的变化，便于对接多个第三方系统水平扩展，而在使用的时候，只需要通过版本号控制即可。

      六、如果是考虑第五条的使用方案的话，最好还是xml，这样可以保证使用时，随时可切换实例。

     七、如果前后端分离，API接口调用dubbo服务的时候，建议dubbo服务参数尽量简单，仅仅传一下必传参数，而其他的参数通过查询获取到，一方面可以降低前端传值的风险，另一方面当前端发布有问题，而又需要马上解决问题，这个时候，调用invoke就比较方便，因为你不比传太多的值进去。如果你有直接修改生产环境数据库的权限，这一条当我没说

 

 

 

 

                                                                                                                                                                             未完待续，随时更新......