springCloud：
1springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。
2springCloud是基于springboot的，spring的使用部署太方便了。
dubbo：
1dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。
要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外
现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。
dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。
微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是d缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。
真正需要微服务的不会像现在看到的那么多。
慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。
如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。
剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。
它们都淘汰也是早晚的事[捂脸]毕竟是java闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]
事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。
以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：
第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。
第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。
第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。
第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。
因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。
个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。
分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。
这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。
springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。
在国外springcloud使用的多，在国内dubbo使用的多。
springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。
Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代
dubbo
对内rpc，对外>问题：直连dubbo应用时，提示错误：RpcException: Invalid token! Failed to invoke method
原因：这是因为provide 配置了token验证，调试时可以暂时去掉这个配置。 关于dubbo token 配置的说明如下：
dubbo:service tokentokenstring/boolean可选false服务治理令牌验证，为空表示不开启，如果为true，表示随机生成动态令牌，否则使用静态令牌，令牌的作用是防止消费者绕过注册中心直接访问，保证注册中心的授权功能有效，如果使用点对点调用，需关闭令牌功能
解决：关闭token验证后就可以正常调用了。报错日志如下：
问题原因是多个服务在该服务器内运行，两个服务的qos-server配置端口号一致，启动时提示被占用，修改其一端口号并重启。
qos是dubbo的在线运维命令，dubbo258新版本重构了telnet模块，提供了新的telnet命令支持，新版本的telnet端口与dubbo协议的端口是不同的端口，默认为22222。
qos端口冲突并影响服务消费者消费服务，但是每次程序启动总是抛出端口冲突异常Dubbo 从低版本升级到 265 版本后，启动失败，报错如下：
<b><font color='red'>上终极方案：使用 262 以下版本或者 270 以上版本的 dubbo ；</font></b>
具体解决方式需要根据项目的情况解决，提供一些其他方案：
删除 webxml 中如下的配置：
Spring Boot 工程没有特别好的解决方案，提供两个解决思路：
这个方案也没有绕过添加 webxml 的命运，做法如下：
观察报错日志，报错位置很明显是 Spring 框架初始化时的报错，重点是： there is already a root application 。
这个错误抛出位置位于： Spring-web 包的 ContextLoader 类的 initWebApplicationContext 方法。
原因很明显， ContextLoader 被调用了至少两遍，第二遍报错导致项目初始化失败，其主要的“罪魁祸首”是 dubbo 包下面的 web-fragmentxml 。
Servlet 30 是随着 Java EE 6 规范发布的，主要新增特性：
支持 Servlet 30 规范的容器，在启动后会扫描工程的 jar 包，找到符合规范的 添加了相关注解的类 和 web-fragmentxml 然后跟 webxml 的配置合并作为整个项目的初始化配置。
上述问题的发生原因很明显了:
这个是 Servlet 30 提供的一个属性，等同一个开关，设置为 true 则表示 webxml 已经提供了全部的配置信息，不需要容器再去各个 jar 包找配置了，换句话就是：关闭 可插特性 ；
这个属性是 SpringServletContainerInitializer 注释里面提供的解决思路。这个属性可以理解为指定 web-fragmentxml 的加载顺序，和 ordering 标签的区别是， absolute-ordering 仅仅针对我们指定的 web-fragmentxml 做排序。
轻易升级一个基础框架不是一个好的做法，<b>升级基础框架还是应该关注下当前版本和目标升级版本，框架作者做了些什么事情，出现过什么BUG。</b>
当前的 Spring Boot 的解决方案并不让人满意，毕竟 Spring Boot 的无Xml的感觉还是很爽的，为了这个升级引入了 webxml 会有一点点不爽。在dubbo服务器上，执行telnet可进入dubbo命令控制行：
点击回车，进入dubbo控制台
ls
显示服务列表。
ls -l
显示服务详细信息列表。
ls XxxService
显示服务的方法列表。
ls -l XxxService
显示服务的方法详细信息列表。
ps
显示服务端口列表。
ps -l
显示服务地址列表。
ps 20880
显示端口上的连接信息。
ps -l 20880
显示端口上的连接详细信息。
trace XxxService
跟踪1次服务任意方法的调用情况。
trace XxxService 10
跟踪10次服务任意方法的调用情况。
trace XxxService xxxMethod
跟踪1次服务方法的调用情况
trace XxxService xxxMethod 10
跟踪10次服务方法的调用情况。1 服务器启动，运行服务提供者。
2 服务提供者在启动时，向注册中心(zookeeper)注册自己提供的服务。
3 服务消费者在启动时，向注册中心订阅自己所需的服务。
4 注册中心返回服务提供者地址列表给消费者，(若有变更，注册中心将基于长连接推送变更数据给消费者)
5服务的消费者,从地址列表中,基于负载均衡,选一台提供者的服务器进行调用,若是失败,在从 地址列表中,选择另一台调用
6期间Dubbo的监控中心,会记录定时消费者和提供者,的调用次数和时间
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）