SpringCloud核心原理

什么是微服务？微服务和传统项目的区别？

      微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务：

    --优点

• 单一职责，每个服务只针对一个业务功能

• 微服务是松耦合的，每个服务都独立开发部署

• 每个微服务能使用不同的语言开发。

    --缺点

• 拆分服务之后，运维成本过高，部署复杂，测试工作更加困难

• 微服务应用是分布式系统，由此带来了固有问题，比方说“网络延迟、容错性、消息序列化、异步、版本号化、应用层中的负载变化等等”

单体服务：

    --优点

• 开发简单，集中式管理

• 基本不会重复开发

• 功能都在本地，没有分布式的管理和调用消耗

    --缺点

• 效率低：开发都在同一个项目改代码，相互等待，冲突不断

• 维护难：代码功功能耦合在一起

• 不灵活：构建时间长，任何小修改都要重构整个项目，耗时

• 稳定性差：一个微小的问题，都可能导致整个应用挂掉

总结

    单体系统在初期可以非常方便的进行开发和使用，但是随着业务的扩展，系统将会变得越来越臃肿难以维护等问题。此时微服务诞生了，我们将系统中的不同功能模块拆分成多个不同的服务，这些服务能够独立部署和扩展。

延伸

    --什么是分布式服务？

        分布式服务顾名思义是分散的部署在不同机器上的，一个服务可能负责几个功能，是一个面向 SOA(面向服务) 架构的，服务之间调用通过 rpc(远程过程调用) 来交互或者 webservice 来交互的。系统是部署在超过一台服务器或者虚拟机上，并且各服务间通过各种通讯协议来交互信息，就可以算作是分布式部署。

    --微服务和分布式的关系

        生产环境下的微服务肯定是分布式部署的，而分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同的应用复制到不同的服务器上，但是逻辑功能上它还是单体应用。

        微服务相对于分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都可以由独立的小团队来负责，因此它的敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过微服务化后带来的挑战也是显而易见的，例如服务粒度小数量大导致后期运维困难。

---

SpringCloud 核心组件

     SpringCloud 是一个基于 SpringBoot 实现的微服务架构开发工具，我们使用 SpringCloud 来构建微服务，以下将讲解 SpringCloud 的几个核心组件：

 

      ◦ Eureka：Eureka 是微服务架构中的注册中心，专门负责服务的注册与发现

    总结：

• Eureka Client：负责将这个服务的信息注册到Eureka Server中

• Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

◦ Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，避免手写一大堆代码去与其他服务建立网络连接。

 

普通方式发起请求：

 

Feign 为我们提供了优雅的解决方案：

 

Feign 的一个关键机制就是动态代理。首先你对某个接口使用@FeignClient 注解，Feign 就会针对这个接口去创建一个动态代理。接着你调用那个接口，本质是调用了 Feign 创建的动态代理，这是核心。Feign 的动态代理会根据你在接口上的@GetMapping 等注解，来动态构造请求的服务地址，然后通过这个地址去发起请求，解析响应。

 

◦ Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台(在分布式部署中，我们将一个服务部署在多台机器上)

 

◦ Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。

        服务雪崩：

            在微服务架构中（A 服务、B 服务），当某个 B 服务不幸挂掉了，此时 A 服务来调用 B 服务，每次来请求都会卡住几秒，最后抛出超时异常。倘若 A 服务的最多只有 100 个线程可以处理请求，如果系统处于高并发的场景下，此时大量请求涌入，A服务的 100 个线程都卡在请求 B 服务的过程中，导致 A 服务没有 1 个线程可以处理请求，这就是服务雪崩。

        解决方案：

            Hystrix：它是一个隔离、熔断和降级的一个框架。

◦ Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

---

---

全过程示意图(总结)：

---

Config

        在分布式系统中，每一个功能模块都能拆分成一个独立的服务，一次请求的完成，可能会调用很多个服务协调来完成，为了方便服务配置文件统一管理，更易于部署、维护，所以就需要分布式配置中心组件。

    Config 的本质是，拉取远程 Git 库上的配置文件，复制在本地存储，然后读取本地配置文件内容，扔给微服务去加载。

配置：

spring.cloud.config.server.git.basedir=/Users/etfox/Downloads/git/client-config

本地存储：