微服务与SpringBoot、SpringCloud

微服务架构—>新架构
模块化，功能化!
用户，支付，签到，娱乐，… 人多余多: 一台服务器解决不了，增加服务器!
假设A服务器占用98%资源，B服务器只占用了10% 。–负载均衡
将原来的整体项目，分成模块化，用户就是一个单独的项目， 签到也是一个单独的项目 ,项目和项目之前需要通信，如何通信?
用户非常多，而签到十分少!给用户多一点服务器，给签到少一点服务器!

微服务架构问题:
分布式架构会遇到的四个核心问题?

1. 这么多服务，客户端该如何去访问?
2. 这么多服务，服务之间如何进行通信?
3. 这么多服务，如何治理呢?
4. 服务挂了，怎么办?

解决方案:
SpringCloud,是一套生态，就是来解决以上分布式架构的4个问题
想使用SpringCloud,必须要掌握SpringBoot,因为SpringCoud是基于SpringBoot;

1. Spring Cloud NetFlix，出来了一套解决方案! - -站式解决方案。我们都可以直接去这拿?
   Api网关,zuu1组件
   Feign --> HttpClient —> HTTP的通信方式，同步并阻塞
   服务注册与发现，Eureka
   熔断机制，Hystrix
   2018年年底，NetFlix宣布无限期停止维护。生态不再维护，就会脱节。

2. Apache Dubbo zookeeper, 第二套解决系统
   API :没有! 要么找第三方组件， 要么自己实现
   Dubbo是一个高性能的基于Java实现的RPC通信框架! 2.6.x
   服务注册与发现，zookeeper: 动物园管理者(Hadoop ，Hive)
   没有:借助了Hystrix

不完善，Dubbo当前Dubbo 3.0 将提供具备当代特性(如响应性编程)的相关支持，同时汲取阿里内部HSF的设计长处来实现两者的融合，当前预览版的很多地方还在探讨中。

3. SpringCloud Alibaba一站式解决方案!

目前，又提出了一种方案:
服务网格:下一代微服务标准，Server Mesh
代表解决方案: istio (未来可能需要掌握! )

万变不离其宗，一通百通!

1. API网关，服务路由
2. HTTP，RPC框架，异步调用
3. 服务注册与发现，高可用
4. 熔断机制，服务降级

为什么要解决这个问题?本质: 网络是不可靠的!

SpringCloud和SpringBoot关系
●SpringBoot专注于快速方便的开发单个个体微服务。 - Jar
●SpringCloud是关注全 局的微服务协调整理治理框架，它将SpringBoot开发的一 个个单体微服务整合并管理起来，为各个微服务之间提供:配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
●SpringBoot可以离开SpringClooud独立使用，开发项目，但是SpringCloud离不开SpringBoot, 属于依赖关系
●SpringBoot专注于快速、方便的开发单个个体微服务, SpringCloud关注全局的服务治理框架