前言
- SpringCloud的诞生以及市面上常见SpringCloud生态
- Spring Cloud 生态中包含的技术详解
- 微服务及微服务架构
3.1 微服务
3.2 微服务架构 - 微服务的优点及其缺点
4.1 微服务优点
4.2 微服务缺点 - 微服务涉及的技术栈
- 为什么选择SpringCloud作为微服务架构
前言
- 本章主要讲解:Spring Cloud 生态涉及的技术栈
1. SpringCloud的诞生以及市面上常见SpringCloud生态
1. 对于模块化拆分后出现的4个核心问题-->
问题1:服务非常多,客户端如何访问?
问题2:服务非常多,服务之间如何通信(基于Http或Rpc)?
问题3:服务非常多,服务如何治理(注册中心)?
问题4:服务非常多,某一个服务挂了怎么办?
-->从而衍生出了一套解决方案:Springcloud。
2. SpringCloud的诞生就是为了做分布式,通过分布式来解决上面出现
的4个问题。
3. SpringCloud不是一个技术,它是一个生态,就是很多东西集合在一
起的。同时SpringCloud是基于SpringBoot。
--------------------------------------------------
4. 市面上常见的SpringCloud 生态,来解决上面4个问题的解决方案,有如下几种↓
⑴ Spring Cloud NetFlix
- 一站式解决方案(上面问题都能够解决)。
⑵ Apache Dubbbo Zookeeper
- 半自动(上面4个问题只能解决其中几个)。
⑶ Spring Cloud Alibaba
- 全新的一站式解决方案。
2. Spring Cloud 生态中包含的技术详解
1. 再啰嗦一下:由于SpringCloud就是很多东西集合在一起的,里面包
含的东西(技术)就是为了解决上面这4个问题。
-------------------------------------------------
2. 对微服务的四个问题的简单梳理
⑴ 访问用到:Api网关 -->路由问题
⑵ 通信用到:Http或RPC -->通信问题
⑶ 服务注册和发现用到:就是利用了高可用机制 -->高可用问题
⑷ 服务挂机用到:熔断机制 -->某个服务出问题,防止服务血崩
(比如A调用服务B,服务B调用服务C…如果C因为某些原因挂掉了,或者
网络原因掉不到C,这时候B这个方法也挂掉了,A这边也跟着挂….这就
是雪崩效应)
3. 总归一句话就是因为"网络不可靠"-->才会出现上面这四个问题。
- 所以正是因为分布式网络是不可靠的,才会造成"丢包,丢帧,数据
被拦截,数据丢失.."由此衍生出以上四个问题。
3. 微服务及微服务架构
3.1 微服务
1. 微服务详解
⑴ 微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个
的服务,彻底地去耦合每一个微服务提供单个业务功能的服务。
一个服务只做一件事情, 从技术角度看就是一种小而独立的处理过程,
类似进程的概念。
**每一个服务均能够自行单独启动或销毁,拥有自己独立的数据库**。
(每一个服务能够自行启动项目,是一个独立的功能模块)
⑵ 微服务:将单一服务划分成多个小服务==》简称"模块化"。
⑶ 划分出来的每一个小服务都有一个独立的端口,相当于每一个服务都
是一个进程,而不是一个线程。
⑷ "微服务"强调的是服务的大小,他关注的是某一个点,是具体解决某一
个问题/提供落地对应服务的一个服务应用, 狭义的看,可以看做是IDEA
中的一个个微服务工程,或者Moudel (即:一个模块,一个端口,就对应
了一个微服务)。
⑸ IDEA 工具里面使用Maven开发的一个个独立的小Moudle,它具体是使
用springboot开发的一个小模块,一个模块就做着一件事情
---------------------------------------------------
2. 微服务理解总结
⑴ 微服务要给用户提供真正的服务,他就需要将很多服务组合起来,
组合起来才变成一个真正的服务,就类似一条最简单的生产线。
⑵ 就像通过淘宝买商品(其中包含:订单模块-->交易模块-->支付
模块--->物流模块-->评论模块)
⑶ 单一的一个"订单模块"它根本不能称为一个真正的服务,单单一
个"交易"它也根本不叫一个真正的服务,你将其中一个模块拆分出来,
它根本没有任何作用,只是说可以简单运行起来而已,你只有将所有一
个个服务完整的拼接在一块,它才可以给用户提供一个完整的服务(缺
一不可)。
⑷ 每一个服务都是分开的,在开发或部署阶段都是独立的(交易模块
分开,支付模块分开...)。
3.2 微服务架构
1. 微服务架构是一种新的"架构形式",它提倡将单一应用程序划分
成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价
值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通
信机制互相协作,每个服务都围绕着具体的业务进行构建,并且能够
被独立的部署到生产环境中。
2. 在微服务架构的构建过程中,应尽量避免统一的, 集中式的服
务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适
的语言,工具对其进行构建。
4. 微服务的优点及其缺点
4.1 微服务优点
1. 微服务的优点↓:
⑴ 每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定
的业务功能或业务需求。
⑵ 开发简单,开发效率提高,一个服务可能就是专一的只干一件事。
⑶ 微服务能够被小团队单独开发,这个小团队是2-5人的开发人员
组成。
⑷ 微服务是松耦合的。是有功能意义的服务。无论是在开发阶段或
部署阶段都是独立的。
⑸ 微服务能使用不同的语言开发。
⑹ 易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,
通过持续集成工具,如jenkins,Hudson,bamboo
⑺ 微服务易于被一个开发人员理解,修改和维护,这样小团队能够
更关注自己的工作成果。无需通过合作才能体现价值。
⑻ 微服务允许你利用融合最新技术。
⑼ 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面混合。
⑽ 每个微服务都有自己的存储能力,可以有自己的数据库,也可以
有统一数据库。
4.2 微服务缺点
1. 微服务缺点↓:
⑴ 开发人员要处理分布式系统的复杂性。
⑵ 多服务运维难度,随着服务的增加,运维的压力也在增大。
⑶ 系统部署依赖。
⑷ 服务间通信成本。
⑸ 数据一致性
⑹ 系统集成测试。
⑺ 性能监控...
5. 微服务涉及的技术栈
- 微服务涉及的技术栈,如图所示-“图-ms2”。
⑴ 在微服务技术栈中只列举了微服务其中一部分的内容,微服务的官网Spring Cloud中还包含了非常多的技术,具体可自行去了解。
图-ms2
6. 为什么选择SpringCloud作为微服务架构
整体解决方案和框架成熟度和社区热度高,可维护性好。
----->其他对于Springcloud更详细的资料可以去官网自行了解。