SpringCloud01–入个门
一、架构演变
1.1系统架构演变
随若互联网的发展,网站应用的规模也在不断的扩大,逬而导致系统架构也在不断的进行变化.从互联 网早期到现在,系统架构大体经历了下面几个过程:单体应用架构–>垂直应用架构–>分布式架构–>SOA架构–>微服务架构,当然还有悄然兴起的Service Mesh(服务网格化).接下来我们就来了解一下 每种系统架构是什么样子的,以及各有什么优缺点.
1.1.1应用架构
互联网早期,一般的网站应用流最较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本.
比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块,我们会把它们做成web项目,然后部署到一台tomcat服务器上.
优点:
-
项目架构简单,小型项目的话,开发成本低
-
项目部署在一节点上,维护方便
缺点:
-
全部功能集成在f工程中,对于大型项目来讲不易开发和维护
-
项目模块之间紧密耦合,单点容错率低
-
无法十对不同模块进行针对对性优化和水平发展
1.1.2垂直应用架构
随着访问最的逐渐増大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块都会 有比较大的访问量.
还是以上面的电商为例子,用户访问量的增加可能影响的只是用户和订单模块,但是对消息模块的影响就比较小.那么此时我们希望只多増加几个订单模块,而不増加消息模块.此时单体应用就做不到了,垂直应用就应运而生了.
所调的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率.比如我们可以将上面电商的单体就拆分成:
•电商系统(用户管理、商品管理、订单管理)
•后台系统(用户管理、订单管理、客户管理)
• CMS系统(广告管理、营销管理)
这样拆分完毕之后,一旦用户访问量变大,只需要増加电商系统的节点就可以了,而无需増加后台 和CMS的节点.
1.1.3分布式架构
当垂直应用越来越多,重复的业务代码就会越来越多.这时候,我们就思考可不可以将重复的代码抽取出来,做成统一的的业务层作为独立的服务,然后由前端控制层调用不同的业务层服务呢?这就产生了新的分布式系统架构.它将把工程拆分成表现层和服务层两个部分,服务层中包含业务逻辑。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现.
优点:抽取公共的功能为服务层,提高代码复用性
缺点:系统间耦合度变高,调用关系错综复杂,难以维护
1.1.4 SO A架构
在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需増加一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service OrientedArchitecture, 面向服务的架构)是关键.
优点:
- 使用注册中心解决了服务间调用关系的自动调节
缺点:
-
服务间会有依赖关系,一旦某个环节出错会影响较大(服务雪崩)
-
服务关心复杂,运维、测试部署困难
1.1.5微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步,它更加强调服务的"彻底拆分"。
优点:
-
服务原子化拆分,独立打包、部署和升级,保证每个微服务清晰的任务划分,利于扩展
-
微服务之间采用Restful等轻量级http协议相互调用
缺点:
- 分布式统开发的技术成本高(容措、分布式事务等)
二、什么是微服务
- 微服务是一种架构风格
- 一个应用拆分为一组小型服务
- 每个服务运行在自己的进程内,也就是可独立部署和升级
- 服务之间使用轻量级HTTP交互
- 服务围绕业务功能拆分
- 可以由全自动部署机制独立部署
- 去中心化,服务自治。服务可以使用不同的语言、不同的存储技术
- 服务调用
- 服务降级
- 服务注册与发现
- 服务熔断
- 负载均衡
- 服务消息队列
- 服务网关
- 配置中心管理
- 自动化构建部署
- 服务监控
- 全链路追踪
- 服务定时任务
- 调度操作
这些玩意儿分别对应一种技术~
三、Spring Cloud
一、是什么
分布式微服务架构的站式解决方案,是多种微服务架构落地技术的集合体,俗称微服务全家桶
这里附上Spring Cloud中文网地址:https://www.springcloud.cc/
可以看看里面有多少技术
二、互联网大厂的微服务架构
1.京东
2.阿里
四、SpringCloud技术栈
五、技术选型
jdk1.8+
maven 3.5.x+
mysql 5.7+
这里需要注意!!
微服务架构不是spingcloud!
SpringCloud只是微服务架构的一种一站式解决方案,只是工具,并不能代表微服务架构!
视频:尚硅谷周阳老师
特别感谢:CSDN博主「巨輪」,原文链接
巨轮哥省了我大量时间,特别感谢~