一、【SpringCloud】微服务与分布式架构

一、微服务与分布式架构

1.1分布式架构

将一个大的系统，划分为多个业务模块，业务模块分别部署在不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。

上图中的ServiceA，B，C，D分别是业务组件，通过API Geteway进行业务访问。（分布式需要做好事务管理）

1.2微服务架构

微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。 微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。分布式和微服务的架构很是相似，只是部署的方式不一样。 分布式也是属于微服务的，微服务的意思也就是将功能模块拆分成多个独立的服务单元通过接口来实现数据的交互，每个功能元素（服务单元）都是一个可替换的、可独立升级的软件代码。

1.3分布式架构的四个核心问题 与解决方案

微服务架构问题，分布式架构会遇到的四个问题？ 这么多的服务，客户端该如何去访问？（API网关，服务路由） 这么多的服务，服务之间如何通信？（HTTP，RPC框架，异步调用，通信问题） 这么多的服务，如何治理?（服务注册与发现，注册中心） 如果服务挂了，怎么办？（熔断机制） 为什么要解决这些问题呢？这些问题是怎么样产生的？ 本质：网络不可靠

解决方案：

第一种解决方案：SpringCloud NetFlix（已停止维护），是一套生态，就是用来解决以上分布式架构的四个问题。一站式解决方案 访问：Api网关 zuul组件 通信：Feign --> HttpClient —> HTTP的通信方式，同步并阻塞 服务治理：服务注册与发现，Eureka 服务意外停止：熔断机制，Hystrix 第二种解决方案：Dubbo+zookeeper（半自动，需要整合别人） 访问：API : 没有! 要么找第三方组件， 要么自己实现 通信：Dubbo是一个高性能的基于Java实现的RPC通信框架! （使用起来就是一个jar包） 服务治理：服务注册与发现，zookeeper: 动物园管理者(Hadoop , Hive)，服务注册中心 服务意外停止：熔断机制，没有，借助了Hystrix 第三种解决方案：SpringCloud Alibaba：目前最新的一站式解决方案！可解决上述4个核心问题，更简单，（关于SpringCloud Alibaba 的一些介绍可参考：） API网关：Zuul 和 Gateway组件 通信：Dubbo 服务注册和发现：Nacos。 熔断机制：Sentinel

1.4 Spring Cloud 五大组件

服务网关——Netflix Zuul 服务注册与发现——Netflix Eureka 负载均衡： 客户端负载均衡——Netflix Ribbon 服务端负载均衡：——Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口) 断路器——Netflix Hystrix 分布式配置——Spring Cloud Config

1.5面试常见问题

什么是微服务？ 微服务之间是如何独立通讯的？ SpringCloud 和 Dubbo有那些区别？ SpringBoot 和 SpringCloud，请谈谈你对他们的理解 什么是服务熔断？什么是服务降级？ 微服务的优缺点分别是什么？说下你在项目开发中遇到的坑 你所知道的微服务技术栈有哪些？列举一二 Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两者的区别