博客主页:踏风彡的博客
博主介绍:一枚在学习的大学生,希望在这里和各位一起学习。
所属专栏:SpringCloud
文章创作不易,期待各位朋友的互动,有什么学习问题都可在评论区留言或者私信我,我会尽我所能帮助大家。
在开头,风哥为了提起大家的学习兴趣,先在文章开头对单体架构和分布式架构做一下对比,小伙伴们,一起来跟风哥看一下吧。
然而在开头,我先抛出来几个疑问,能来看这篇文章的小伙伴,相信已经做了一个或多个类似学生管理系统的小型项目,这种项目有一个大体上的特点就是模块单一,架构简单,部署起来十分方便,但是呢,这也往往存在一个问题,什么问题呢?大家想一下,Java的一个宗旨是什么?高内聚,低耦合。而这样的单一架构的系统,耦合程度还是比较高的。
为什么这么说呢?大家思考一下,先看下面这种情况:
假设做一个这样简单的商务管理系统,倒是能做,服务小众嘛,讲究开发效率,一些问题在这体现的不是那么多,但是如果我们把眼光上升到京东、淘宝这些大型的电商项目来看,如果每个全部功能都写到一个模块里,这里给大家打个比方,一根钢管的承重力是200kg,我们买的东西全部放到一根钢管上,但凡它超过这个限度,我们现成的系统是不是就bom~,直接原地爆炸。那我们怎么样才能极大限度地去避免这种事情的发生呢?这就需要微服务了,那么接下来,风哥就带大家认识一下微服务,Let‘s go.
微服务实际上还是一个分布式架构的解决方案,在文章开头,风哥仅举了一个小例子,相信有的小伙伴对单体架构和分布式架构还不清晰,所以,我在这部分将对两者地架构进行分析:
单体架构特征:将所有服务集中到一个模块里进行开发。
可以看出单体架构地特点:
分布式架构特征:根据业务功能对模块进行拆分,极大限度保证一个功能一个模块,一个模块为一个服务
可以看出分布式架构特点:
既然微服务这么好用,降低了服务间的耦合度,那我们就不需要思考了嘛?不,微服务架构这么复杂,若是再没有一点规矩,那不是乱了套了嘛。正所谓家有家法、行有行规,微服务也有人家的一套准则,至于准则是什么,这章我们不来细说,我把微服务的服务拆分准则和远程调用的方法放在本专栏的下一篇文章中,这篇文章,风哥仅仅带大家了解下微服务,目的是为了提起大家的学习兴趣,如果这个章节太过繁琐,知识点过多,怕是会劝退很多小伙伴啊。
首先,看了上边,相信小伙伴们对微服务有了一个整体上的了解,但是却有着不清晰的概念,接下来,风哥给大家梳理一下。
微服务的架构特征:
正是由于微服务这样的标准,才使程序间进一步啊降低了耦合度,实现了服务的独立性和灵活性,从而更好地做到了高内聚、低耦合。
所以( ̄▽ ̄)*,我们可以认为微服务是经过了一个良好设计的分布式架构方案。
但是,众所周知,每个方案的基石就是技术栈,而在中国乃至全世界,Java领域最引人注目的就是Spring公司提供的SpringCloud架构技术。
SpringCloud是目前国内使用最广泛的微服务框架。官网地址:https://spring.io/projects/spring-cloud。
同时SpringCloud集成了很多微服务功能组件,并且它基于SpringBoot对这些组件实现了自动装配,从而能让各位在使用中有着良好的开箱即用的体验。
其中常见的组件包括以下几个:
另外呢,风哥提前给大家说一下哈,因为SpringCloud是基于SpringBoot实现自动装配,说明SpringCloud是依赖于SpringBoot的,因此,SpringCloud和SpringBoot就有着相应的版本依赖关系。
具体依赖关系可到Spring官网SpringCloud部分来查看。
为了节约小伙伴时间,风哥已经在下面罗列了写这篇博客时的版本依赖关系,大家按需选择版本即可。
部署难度比较大、而且上线后运维、监控的成本较高