【图解】我使用过的 Dubbo 和 Spring Cloud _架构

自从2015年毕业开始从事 Java 开发工作，已经过去3年多了，在各种不知名的小公司待过，经历过生产力从低到高，技术从落后到先进的过程，Dubbo 和Cloud 就是我曾经所经历过的两次技术变革。微服务这个概念已经出现好多年了，但是最近几年微服务异常火爆，很多以前使用 Dubbo 的公司也在纷纷尝试转型。Dubbo 好还是Cloud 好，有啥差异，有啥优缺点是人们常常讨论的话题，很多知名大V也纷纷写一些科普文章，我也拜读过很多，读完感受良多，也激起了我写这篇文章的动力。这篇文章更多的不是解释概念，而是讲述我曾经使用到的两种技术的方式，希望大家可以从文章中获得启发。
原生状态
如果以前关注过 Dubbo，对 Dubbo 印象最深的一个定位就是 ”服务治理“的概念。为什么要服务治理？服务治理到底治理了什么方面？这是我们遇到的最直观的问题。
下面就展示下我们曾经没有使用 Dubbo 的业务模型：

文章插图
大体的业务如下：
1、我们有项目A，和项目B，项目A由项目管理部负责使用，项目B由物流部负责使用；
2、每当项目管理部在项目A中完成一个项目，那么就必须发请求给项目B，通知项目B进行物流发货；
3、项目B物流完成之后给项目A发送一个请求，完成物流操作，告知项目A进入结算。
根据图看的话，无非就是两个项目互相调用，在没用采用 Dubbo 之前，我们的项目结构就像图中那样混乱，很多问题都是不可避免的。下面我就把所有遇到的问题一一进行列举，以项目A为例，：
1、开发者由于自身综合素质不高，没有良好编码习惯和架构能力，对的调用和服务暴露散落在各个层面如图所示；
2、项目A中所有的请求的ip，写在配置文件，如果项目B修改了部署ip或者端口，项目A需要手动修改配置文件然后重启；
3、项目B如果修改了方法的参数和返回值，项目A无法得知；
4、项目A调用项目B使用的方式由于开发者的能力和经验不同，采用的实现方式千奇百怪，有的使用，有的使用的，有的使用原生的使用 Java 提供的原生操作。同样，项目B中提供服务的方式也千奇百怪，有的是MVC 提供的 http 接口，有的使用的是，整个项目混乱不堪；

文章插图
5、每个人写的请求参数五花八门，比如超时时间设置，比如的设置等，没有统一的规范；
6、当时接口是暴露在内网的，所以接口没有做安全性校验，但是这也是一大遗留问题。
Dubbo
当原生的架构出现了这些问题之后，我们需要对架构进行更新升级，综合以前遇到的问题，我们提出了一些关于框架的需求：
1、调用其他服务的时候，不用手动的维护ip和端口；
2、暴露给其他服务的接口，接口形式要一致；调用其他服务的接口，方式要统一，参数统一设置，支持个别方法单独设置参数；
3、采用RPC的形式，本地项目依赖远程项目提供的sdk，调用sdk中的方法就可以实现远程方法的调用。
在这样的趋势下，就很正常的选择了 Dubbo 作为项目的框架，当时的想法也特别单纯，和 Dubbo 当时的定位一样，主要就是”服务治理“，让混乱不堪的项目结构清晰起来。当时还没有想到什么分布式事务、服务熔断、服务鉴权这些概念。我们使用 Dubbo 的时候，Dubbo 依然是停止更新状态，还没有捐献给。才采用 Dubbo 架构之后，我们对项目进行了整体的重构，同时引入了 SSO 的单点登录，最后的架构大致如下：