SpringCloud(01)
(1-1) 微服务架构四个核心问题:根本原因!网络不可靠
- 在服务很多的情况下,客户端怎么去访问
- 服务之间怎么去通信(http rpc)
- 服务该怎么治理
- 如何处理服务挂掉的问题
(1-2) 对于以上问题的解决方案:
-
springcloud 它的诞生就是做分布式,也就是为了解决上述问题,它不是一个技术,而是一种生态
-
Spring Cloud NetFlix (一站式解决方案,也就是什么都能干)
客户端要去访问:要通过api网关(zuul组件)
服务间通信: Feign ,不仅能够通信,还可以做简单的负载均衡,基于Http通信方式(同步,阻塞)
服务治理问题:Eureka
熔断机制:Hytrix
-
Apache Dubbo Zookeeper (半自动解决方案,需要整合别人)
api :无,找第三方组件,进行融合,或者自己实现
Dubbo:高性能的基于java的RPC通信框架(异步,非阻塞)
服务治理:Zookeeper
熔断机制:无,借助Hytrix
-
Spring Cloud Alibaba (一站式解决方案) 成本更低,更加简单
-
那么到底如何学习!
我们只需记住四个点:
(1)API
(2)Http RPC
(3)注册和发现
(4)熔断机制
(1-3) 什么是微服务
微服务并没有一个标准的定义,微服务架构它是一种架构模式,或者说是一种风格,它提倡将单一的应用程序划分为一组小的服务,每个服务都独立运行在自己的进程内,服务之间相互协调,采用轻量级的通信机制互相沟通,并能够被独立的部署到生产环境中,为用户提供最终的价值,另外,可以有轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以用不同的数据存储。。。
也就是说,根据业务把一站式应用拆分成一个一个的服务,彻底的解耦!!!
(1-4) 微服务与微服务架构
微服务强调的是服务的大小,关注的是一个点,换句话说,就是IDEA中的一个个微服务工程,Module,来解决某一个问题。
微服务架构是一种架构模式,是来解决一类问题的也就是前面的内容。
(1-5) 微服务的优缺点
缺点
- 要处理分布式系统的复杂性
- 多服务运维难度
- 系统部署依赖
优点
- 每个服务足够内聚,足够小,代码容易理解
- 开发简单,开发效率高
- 微服务在开发阶段或部署阶段都是独立的
- 易于与第三方集成
- 能使用不同的语言开发
- 微服务知识业务逻辑代码,不会和HTML CSS 或者其他界面混合
- 每个微服务有自己的存储能力,可以有自己的数据库,也可以有统一数据库
(1-6) 为什么选择SpringCloud作为微服务架构
整体解决方案和框架成熟度,社区热度,可维护性,易上手(注解)
(2-1) 什么是SpringCloud
通过SpringCloud来协调处理我们的一个个微服务!Springcloud ,基于Springboot提供了一套微服务解决方案,包括服务与注册中心,配置中心,链路监控,服务网关,负载均衡,熔断器等组件,
它巧妙地简化了分布式系统的开发,屏蔽了复杂的配置原理和实现原理。是分布式微服务架构下一站式的解决方案!!!
(2-2) Springboot 和SpringCloud 的关系
- SpringBoot 专注于快速开发单个个体微服务
- SpringCloud 是专注于全局的微服务协调框架,将SpringBoot开发的一个个微服务整合并管理,为各个微服务提供,配置管理,服务发现,路由,分布式会话等集成服务
- SpringBoot可以离开SpringCloud单独使用,开发案项目,但是SpringCloud离不开SpringBoot
(2-3) Dubbo和SpringCloud的对比
最大区别:SpringCloud 抛弃了Dubbo的RPC通信,采用的是基于HTTP的ERST方式,虽然后者牺牲了服务调用的性能,但也避免了原生RPC带来的问题,REST相比于RPC更加灵活,不存在代码级别的强依赖,也就是说,服务提供方与调用方的依赖只依靠一纸契约,在快速演化的微服务环境下,更加合适,
SpringCloud能与Spring Framework ,SpringBoot,Spring Data 等项目完美融合,但是Dubbo构建的微服务就像组装电脑,我们的选择十分灵活,但是造成结果出现问题的原因也特别多,例如一个内存条出现问题,那么整个组装就失败了,但是SpringCloud,做了大量的兼容性测试。
解决的问题不一样!Dubbo的定位是一款RPC框架,SpringCloud是微服务架构下是一站式解决方案
(2-4) SpringCloud的特性
-
分布式,版本化配置
-
服务注册和发现
-
路由
-
service-to-service
-
负载均衡
-
熔断器
-
分布式消息传递