关于Dubbo

Posted 2021-04-05 yzfree星球

前序：

这段时间一直在西安往返出差，每次坐飞机都坐的我屁股蛋子生疼，看了看纵横商旅app上的飞行时间，大约在天上待了42个小时。而且我早年看过坐飞机的那一部《死神来了》电影，这导致每次飞机跌波的时候我心里是有一丝丝余悸的，心悬着，毕竟脚不着地的感觉。话不多说，好人一生平安吧。

中序：

是这样的，公司有个项目是采购的西安一家软件公司的sass产品，我司私有化部署并且在全国范围内下属幼儿园已经运行了三年。由于需求不满足现有业务的发展，打算在其基础上进行定制化需求开发。于是乎我便和其他两位素未谋面的同事前往西安与乙方联合开发。

前期由于需求尚在讨论阶段，而且来回掰扯，迟迟定不下来。把领导急坏了，怎么你们还没开始开发啊，要抓紧了。可是做项目就是这样，需求不定，搬砖人也不敢盲目开工，对于搬砖人来说，需求终归要先说断，后不乱。这样也不存在大量返工的情况，至少搬砖的心情是愉悦的，心里有底。一句话的需求坑最多，因为它可能是个黑洞，进去了再出来也是一身黑了吧。所以等到需求封板，已经是一两个礼拜之后了吧。

照这架势，我也觉得项目至少得延期，乙方同事说怕是要做到明年三月份也做不完。可是船到桥头自然直，项目分成两个阶段，招生阶段功能1月15号已经上线，也已经在各大幼儿园使用起来了，家长可以通过小程序扫描招生二维码进行意向报名并缴费，在园在班阶段相关功能1月7号也将上线，目前已经在测试阶段。

后序：

关于Dubbo:

dubbo早在2017年底就重启维护了，并且Dubbo 在国内拥有着巨大的用户群，其实Dubbo 并不是要提供一整套微服务解决方案，而是定位在 RPC 、服务扩展与治理方面：

本身分布式架构可以承受更大规模的并发流量，所以大家希望在使用 Dubbo 的同时享受SpringCloud的生态，出现各种各样的整合方案，但是因为服务中心的不同，各种整合方案并不是那么自然。直到SpringCloud Alibaba 这个项目出现，由官方提供了Nacos服务注册中心后，才将这个问题完美的解决。并且提供了Dubbo和SpringCloud整合的方案，姑且称之为Dubbo SpringCloud。

SpringCloud为什么需要RPC？

在SpringCloud构建的微服务系统中，大多数的开发者使用都是官方提供的Feign组件来进行内部服务通信，这种声明式的HTTP客户端使用起来非常的简洁、方便、优雅，但是有一点，在使用Feign消费服务的时候，相比较Dubbo这种RPC框架而言，性能堪忧。

虽然说在微服务架构中，会将按业务划分的微服务独立去部署，并且运行在各自的进程中。微服务之间的通信更加倾向于使用HTTP这种简答的通信机制，大多数情况都会使用REST API。这种通信方式非常的简洁高效，并且和开发平台、语言无关，但是通常情况下，HTTP并不会开启KeepAlive功能，即当前连接为短连接，短连接的缺点是每次请求都需要建立TCP连接，这使得其效率变的相当低下。

对外部提供REST API服务是一件非常好的事情，但是如果内部调用也是使用HTTP调用方式，就会显得显得性能低下，Spring Cloud默认使用的Feign组件进行内部服务调用就是使用的HTTP协议进行调用，这时，我们如果内部服务使用RPC调用，对外使用REST API，将会是一个非常不错的选择，恰巧，Dubbo和SpringCloud的组合给了我们这种实现方式。

Dubbo要解决的需求（摘抄自dubbo官方文档）：

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

以上是 Dubbo 最基本的几个需求。

dubbo架构简图：

到这里就大概了解了dubbo的确是个好东西，这是dubbo的第一篇->初探，后续应该会继续写吧...