SpringCloud微服务之 SpringCloud

比眉伴天荒 2022-05-26 02:13 189阅读 0赞

## 前言 ##

--------------------

本节我们将了解学习一下一些实现微服务的架构。现在主流的实现微服务的架构有Dubbo 和 SpringCloud，不过最终选择哪一个应需求而定，不过客观上来讲个人更喜欢SpringCloud。下面我们将介绍一下两者。

--------------------

## Dubbo ##

*  定义：Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
 *  主要核心部件  
    
    
     *  Remoting：网络通信框架，实现了 sync-over-async 和 request-response 消息机制
     *  RPC：一个远程过程调用的抽象，支持负载均衡、容灾和集群功能
     *  Registry： 服务目录框架用于服务的注册和服务事件发布和订阅
 *  工作原理  
    
    
     *  Provider  
        暴露服务方称之为“服务提供者”。
     *  Consumer  
        调用远程服务方称之为“服务消费者”。
     *  Registry  
        服务注册与发现的中心目录服务称之为“服务注册中心”。
     *  Monitor  
        统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。
 *  特性  
    
    
     *  连通性
     *  健壮性
     *  伸缩性

这里就不赘述Dubbo也不写Deom了，一来不怎么样用Dubbo,二来个人认为先入为主的爱上了SpringCloud。

--------------------

## SpringCloud ##

*  定义：Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
 *  主要核心部件(参考[这里][Link 1])  
    
    
     *  Spring Cloud Netflix  
        是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。
     *  Spring Cloud Config  
        将配置信息中央化保存, 配置Spring Cloud Bus可以实现动态修改配置文件
     *  Spring Cloud Bus  
        分布式消息队列，是对Kafka, MQ的封装
     *  Spring Cloud Security  
        对Spring Security的封装，并能配合Netflix使用
     *  Spring Cloud Eureka  
        Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中的一部分，它基于Netflix Eureka 做了二次封装，主要负责完成微服务架构中的服务治理功能。
     *  Spring Cloud Hystrix  
        Netflix的创造了一个调用的库Hystrix实现了断路器图案。在微服务架构中，通常有多层服务调用。
 *  工作原理  
    
    
     *  SpringCloud的工作原理基本是围绕着服务的注册和发现开其中又因使用的SpringCloud组件不同，从而微服务的具有的能力个功能也将不一样，所以对于SpringCloud的工作原理参考[这里][Link 1]  
        ![这里写图片描述][70]

--------------------

## Dubbo VS SpringCloud ##

So 在分析了Dubbo 和 SpringCloud之后 两者之间存在着一些差异，因而在微服务架构选择是到底选择Dubbo还是SpringCloud呢？我们不妨做一下比较。

*  **Round 1：背景**  
    
    
     *  Dubbo 是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了
     *  Spring Cloud 从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。
     *  小结：如果拿Dubbo与Netflix套件做对比，前者在国内影响力较大，后者在国外影响力较大，我认为在背景上可以打个平手；但是若要与Spring Cloud做对比，由于Spring Source的加入，在背书上，Spring Cloud略胜一筹。不过，英雄不问出处，在背景这一点上，不能作为选择框架的主要因素，当您一筹莫展的时候，可以作为参考依据。
 *  **Round 2：社区活跃度**  
    
    
     *  Dubbo更新时间间隔长且频率较低
     *  SpringCloud 用户社区非常活跃，更新迭代也非常快。
     *  小结：在社区活跃度上，Spring Cloud毋庸置疑的优于Dubbo，这对于没有大量精力与财力维护这部分开源内容的团队来说，Spring Cloud会是更优的选择。
 *  **Round 3：架构完整度**
    
     *  核心组件VS  
        ![这里写图片描述][70 1]  
        由此可见：Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。
        
        Dubbo对于上表中总结为“无”的组件不代表不能实现，而只是Dubbo框架自身不提供，需要另外整合以实现对应的功能，比如：
        
         *  分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。
         *  服务跟踪：可以使用京东开源的Hydra
         *  批量任务：可以使用当当开源的Elastic-Job
         *  ……
     *  RPC vs REST  
        由于Dubbo是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如Dubbo的服务调用是通过RPC实现的，但是如果仔细拜读过Martin Fowler的microservices一文，其定义的服务间通信是HTTP协议的REST API，下面我们就来比较一下两者的区别。
        
         *  服务提供方与调用方接口依赖方式太强  
            我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
         *  服务对平台敏感，难以简单复用  
            通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。
     *  小结  
        Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些（如果您读过我之前关于Spring Cloud的一些核心组件使用的文章，应该能体会这些让人兴奋而激动的特性，传送门）。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。
 *  **Round 4：文档质量**  
    
    
     *  Dubbo的文档可以说在国内开源框架中算是一流的，非常全，并且讲解的也非常深入，由于版本已经稳定不再更新，所以也不太会出现不一致的情况，另外提供了中文与英文两种版本，对于国内开发者来说，阅读起来更加容易上手，这也是dubbo在国内更火一些的原因吧。
     *  Spring Cloud由于整合了大量组件，文档在体量上自然要比dubbo多很多，文档内容上还算简洁清楚，但是更多的是偏向整合，更深入的使用方法还是需要查看其整合组件的详细文档。另外由于Spring Cloud基于Spring Boot，很多例子相较于传统Spring应用要简单很多（因为自动化配置，很多内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应，比较建议了解和学习Spring Boot之后再使用Spring Cloud，不然可能会出现很多一知半解的情况。
     *  小结：虽然Spring Cloud的文档量大，但是如果使用Dubbo去整合其他第三方组件，实际也是要去阅读大量第三方组件文档的，所以在文档量上，我觉得区别不大。对于文档质量，由于Spring Cloud的迭代很快，难免会出现不一致的情况，所以在质量上我认为Dubbo更好一些。而对于文档语言上，Dubbo自然对国内开发团队来说更有优势。

--------------------

## 总结 ##

*  通过上面再几个环节上的分析，相信大家对Dubbo和Spring Cloud有了一个初步的了解。就我个人对这两个框架的使用经验和理解，打个不恰当的比喻：使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
 *  这条总结是我想了很久之后的感想，这小点本身和本节无关，只是一些延伸而已。我经常在CSDN上看到有关IT大行业内大龄程序员各种倒苦水，说自己在求职或者工作中不被重视被忽略甚至被差别化对待。我总是这样认为，我国IT行业有很大的发展空间，这么说是应为较国外的相比国内本身就比较落后，第二个也是很致命的：年龄大的经验丰富的人收到行业的不友善对待从而无法在研发上有所突破，久而久之形成一种和可怕的现象：国外用什么新的技术，国内需要经过一段时间才能了解到，再把新技术用到线上时，人家可能以及打算放弃它重新研发新的技术点了。我们用的永远都只是人家用过的，俗称二手货。如果某家公司线上使用到的核心技术都来自于国外，万一哪天除了什么BUG或者社区关闭了，该公司要么换要么老老实实将就着用，这就很被动。说到底，于IT行业而言不应该是个青春饭行业，能者居之是一面，更重要的是留住人才。这样子在做Dubbo和SpringCloud的对比时，Dubbo应该呈现出更优秀的方面，而不是显得那么的商业化。[看这里][Link 2]

[Link 1]: https://springcloud.cc/spring-cloud-dalston.html
[70]: /images/20220526/563a414aac004ed7bb9ed512f7e41f0c.png
[70 1]: /images/20220526/42ca02063d9847128e8d294f9f04e414.png
[Link 2]: https://blog.csdn.net/csdnnews/article/details/80073306