dubbo有用吗？分布式治理是伪命题？

dubbo用于解决微服务之间调用，微服务是按业务领域拆分的，一个微服务只有少数接口需要开放给其它微服务调用，但是大量的接口是给前端调用的，这些接口是通过nginx转发的，lrc歌词多个微服务间的负载均衡也是通过nginx实现的，如此一来，就形成了大部分请求走nginx，这部分请求中有少量业务会调用dubbo服务，那么dubbo只治理这很少的一部分服务调用意义何在呢？走nginx的大量浏览器和App客户端的请求并没有反映到dubbo中也无从治理，这部分请求怎么办呢？
于是我把dubbo的调用删除了，自己用hessian协议实现rpc，加了一个处理hessian的servlet用http协议来调用，这样，所有的调用都走nginx了，微服务组件间的RPC调用同样基于nginx的负载均衡实现分布式调用，这样，分布式微服务的rpc调用就实现了，只是没有监控、限流、降级、溶断等分布式服务治理，看到nginx可以配合lua（比如kong）实现服务治理，大家认为这种方案如何？

你可以了解下spring cloud,当然轮子既然造了,那就继续用

你的系统没有复杂到一定的程度，仅限于浅层的一级微服务(外部请求通过nginx直接调用)。
对于这一层微服务，你需要做的是网关治理，而不是微服务治理。
所以，请把侧重点放到网关的解决方案，不要硬来套微服务的概念。

复杂到什么程序才需要呢？再复杂也由1、前端对微服务接口的请求加上2、微服务之间的调用或级联调用组成吧，前端的调用直接路由到特定服务是最好的吧，这样的话，dubbo还是管理的微服务之间的直接或级联调用是吧？这样dubbo面板上的调用数据和控制仍然是不全的，我在想是否我使用dubbo的方式不对呢？我们的代码不是基于spring的，所以是用的dubbo的api方式，只把每个微服务组件中需要被调用的接口注册了。

框架的使用，仁者见仁，智者见智
你的微服务只有少数接口需要开放给其它微服务调用，但是大量的接口是给前端调用的，那说明你的微服务集成度还是很高，自己就完成了业务逻辑，不需要其他微服务协同完成

分为两个过程的话：
1 请求通过网关路由到一级微服务。
2 一级微服务发起的其他微服务之间的级联调用。
dubbo是2里RPC调用的一种实现方式。
按你的描述大量的接口是给前端调用的
应该是1的问题，还没有到2，所以和dubbo关系不大。
最好把1和2分开治理
所以你的问题应该是网关治理，或者说是子系统管理。
2还没有多到要治理的程度。

系统场景不同，确实使用的架构风格不一样，你说的这种前后端比较单纯的APP类确实不需要，而且微服务之间的RPC调用也不能太长，太长会导致时延太久，稳定性太差。Nginx作为网关，容易形成系统单点故障问题，他一旦坏了你的系统立马就全瘫掉了，这也不合适。
当前是首先按照大颗粒去划分系统，这种系统交互通常走APIGW（其实也就是Nginx），小颗粒的服务内部交互都是RPC调用不走网关，通过客户端的流控降级负载均衡来进行治理，而不是通过网关来走。

另外客户端的负载均衡，但服务不会超过100实例，太多了还是要弄成一个独立的云服务去搞。

哦，现在微服务治理快成政治正确了，不搞上显得架构不完整很low，哈哈。
我们开始用dubbo的方法就是处理2的一级微服务之间的调用，但是加了dubbo和zookeeper增加了部署复杂度，而且微服务间的调用比较少感觉治理体现的不全面，所以换成hessian协议结合nginx使用，现在是有微服务和rpc调用但没有治理，引入治理有两个方案，1、nginx+lua这个还需要研究（但似乎可以管理所有的前后端调用）2、是否应把所有接口注册到dubbo，前端直接访问dubbo代替nginx? 基于spring的是否会把所有controller都注册到dubbo呢，前端调用是否会被dubbo管理呢？

但是hessian的方案我们自己的微服务之间可以，与第三方的服务互调用就有问题了，也许这才是微服务架构的意义所在吧

有点明白了，原来我纠结dubbo治理的不全面（因此我让rpc调用也走网关），原来就应该把前端调用和服务间调用分开，dubbo或springcloud提供了公共的注册服务，使自己的微服务和第三方的都可以调用（代替了传统的ESB是吧？），治理也仅是治理这部分调用！这些微服务框架太完善了简直，假如服务间调用出现性能瓶颈，首先更多更频繁的前端调用就会出问题，限流啊降级啊熔断有机会用吗？确实是业务复杂度没有这么高感觉不到治理的好处啊

一级微服务之间不要有互相调用就能减少80%的问题。

WEB层，WEB逻辑层(Service)不要拆，放到一个单体里，这个是一级微服务，通过网关或直接暴露给外面。
领域层是二级微服务，往下是文件，缓存，DB，队列等。
一级往下调用没问题，二级三级等之间调用也没问题。
一级之间存在互相调用的话说明你业务拆分有问题。这是问题的根源。

你们的治理应该是针对服务发现的治理，熔断，降级这些主要从业务上考虑，
业务并发量没大到一定程度的话，直接上反而增加业务的风险。
先把服务发现，网关鉴权，网关分流，网关限流这些弄好吧。

一个微服务应用web层和领域层应该在一起吧，例如用户中心，包括web层领域层都在一起一个微服务，其它微服务都会用到，springcloud服务间调用主要是REST方式调用的controller（对不对？统一调controller也是一致的思路），dubbo则可以用dubbo协议调service，其实也都是一级之间调用吧？

WEB
↓
BIZ（web逻辑层也叫service层，负责CoreService的编排）
↓
CoreService（领域层）

原则上RPC调用都发生在BIZ和CoreService之间的通信。
CoreService可以对外暴露接口，或者本身是一个stub

web和BIZ一定一个单体不要拆。
这个单体我叫一级微服务。
这个单体只能调用自己的CoreService或者通过stub调用其它的CoreService。
所以一级微服务之间是不存在互相调用的。

至于CoreService（领域层）和一级微服务绑定到一个单体的话，没问题。
如果这个绑定到一起的单体对外发布接口也没问题，但和WEB层接口混在一起的话，治理就是个问题了。