spring cloud 微服务理解

最近在看spring cloud的相关技术栈，记录下在学习过程中的体会。首先都在说微服务，那么微服务是什么？有什么优势？是我在学习过程中首先要解决的两个问题。首先来我的理解是微服务主要体现在“微”，将一个的大的项目拆分成一个一个的服务来完成原来这个项目所作的所有事情，也就是说专一的服务做专一的事情。比如说一个电商的项目其中可能包括：用户系统，交易系统，支付系统，库存系统，积分系统。。。如果将这些服务塞到一个大的系统里也可以做，但是这样做了之后会造成很多不便的地方，比如说在用户系统完成交易对用户的积分进行添加的时候发生意外，那么不可避免的会影响到其他的业务，并且如果说积分系统需要改动那么整个项目都要重新进行部署，再改动的同时程序员也都需要对其他一些和积分无关的业务有所了解这样肯定会影响到开发效率。而将这些拆分成一个一个的服务之后这种情况就可以得到有效的避免，实现独立运行独立部署，并且程序员只需要了解他所要改动的服务的相关代码。

那微服务和spring cloud有什么关系呢？微服务就相当于是java中的一个接口，而微服务架构就是实现了这个接口的抽象类，spring cloud就是继承了这个抽象类的具体实现。借用我的一位老师“阳哥”说的一句话，“天上飞的理念，总有落地的实现”,而spring cloud就是落地实现中的一种。

那spring cloud的优势在哪里？借用官网对spring cloud的定义，spring cloud是一系列框架的有序集合，为开发人员提供了很多构建微服务架构的一些列便捷的工具诸如：配置管理，服务注册服务发现，断路器，路由等

那spring cloud和目前大型互联网公司使用的dubbo之间的区别又有那些也是面试过程中一道热门的面试题。不可否认dubbo是一个特别特别牛逼的服务治理框架并且现在很多大型互联网公司也是在用dubbo。但是在dubbo停止维护的这五年也使很多程序员对其以后的发展抱有迟疑的态度。以下是dubbo做服务治理的时候的大致架构图，dubbo在进行服务通信的时候与spring cloud的不同指出在于，dubbo使用的rpc协议进行通信，而spring cloud使用的是http协议进行通信，关于通信协议我也是小白一枚，之所以很多大公司选型dubbo的原因可能就在于rpc是远程过程调用效率比起http的rest调用要高，但是不得不说的是远程过程调用使得服务提供方与调用方在代码上产生强依赖提供方需要将一些公共代码达成jar包供消费者使用一旦打包过程出现问题就会导致服务的调用失败。dubbo在做服务注册的时候严重依赖第三方组件，这就使得一旦第三方组建出现问题服务调用基本也就gg了。但是spring cloud在做微服务架构时提供的却是自己的一些组件，这就使得很多问题可以避免。总的来说spring cloud是中小型公司的福音。