前序：
这段时间一直在西安往返出差，每次坐飞机都坐的我屁股蛋子生疼，看了看纵横商旅app上的飞行时间，大约在天上待了42个小时。而且我早年看过坐飞机的那一部《死神来了》电影，这导致每次飞机跌波的时候我心里是有一丝丝余悸的，心悬着，毕竟脚不着地的感觉。话不多说，好人一生平安吧。
中序：
是这样的，公司有个项目是采购的西安一家软件公司的sass产品，我司私有化部署并且在全国范围内下属幼儿园已经运行了三年。由于需求不满足现有业务的发展，打算在其基础上进行定制化需求开发。于是乎我便和其他两位素未谋面的同事前往西安与乙方联合开发。
前期由于需求尚在讨论阶段，而且来回掰扯，迟迟定不下来。把领导急坏了，怎么你们还没开始开发啊，要抓紧了。可是做项目就是这样，需求不定，搬砖人也不敢盲目开工，对于搬砖人来说，需求终归要先说断，后不乱。这样也不存在大量返工的情况，至少搬砖的心情是愉悦的，心里有底。一句话的需求坑最多，因为它可能是个黑洞，进去了再出来也是一身黑了吧。所以等到需求封板，已经是一两个礼拜之后了吧。
照这架势，我也觉得项目至少得延期，乙方同事说怕是要做到明年三月份也做不完。可是船到桥头自然直，项目分成两个阶段，招生阶段功能1月15号已经上线，也已经在各大幼儿园使用起来了，家长可以通过小程序扫描招生二维码进行意向报名并缴费，在园在班阶段相关功能1月7号也将上线，目前已经在测试阶段。
后序：
刚参与这个项目时，拿到git地址，拉取代码看了看提交记录，有好些年头了。分布式服务框架用的不是springcloud而是dubbo+zk，在以前的公司倒是没有用到dubbo的经验，只是自己私下了解搭建过，浅尝辄止。说到这里，我们就会想springcloud和dubbo哪个更好呢？有的人认为dubbo过时了，甚至早已死去，认为springcloud全家桶毕竟是一站式解决方案，社区活跃，并且开发效率高。难道dubbo真的就不香吗，肯定不是这样的。
关于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官方文档）：
在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡
当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
以上是 dubbo 最基本的几个需求。
dubbo架构简图：
喜欢java的同学可以关注我的公众号: yzfree星球
