SpringCloud

单体架构

????将业务的所有功能集中在一个项目中开发，打成一个包部署。它的优点是架构简单、部署成本低。
????缺点是团队协作成本高（项目打包时间非常长，改bug重新编译就是一种折磨）、系统分布效率低、系统可用性差（Tomcat的资源是有限的，当一个接口的访问量短时间内过高，是会影响所有接口的访问效率的，甚至会导致整个项目宕机）
????所以单体项目适合功能较少，访问量较小的项目。

微服务

????微服务架构，是服务化思想指导下的一套最佳实践架构方案。服务化，就是把单体架构中的功能模块拆分成多个独立的项目。当然了，拆分也是有一定的要求的，拆分粒度一定要小（按照业务来看，拆出去的项目要符合一个完整的功能，单一职责）、团队自治（每个拆分的项目都要有团队来维护）、服务自治（分开打包、分开部署）

SpringCloud

????SpringCloud作为微服务全家桶的技术栈，其包含了很多组件来解决服务拆分中带来的问题

服务治理

????如果不同服务之间存在数据的交换，那么就需要由一个服务调用另一个服务的接口，成为服务治理。服务治理的三个角色分别是

1. 提供者，提供服务接口，供其他服务调用
2. 调用者，调用其服务提供的接口
3. 注册中心，记录并监控微服务各实例状态，推送服务变更状态

注册中心原理

????所以注册中心的作用就是为消费者提供提供者的地址，消费者可以从注册中心订阅和拉取服务信息

那么消费者如何得知服务的变更状态？ 服务提供者通过心跳机制向注册中心报告自己的健康状态，当心跳异常时，注册中心就会将异常的服务剔除，并通知订阅了该服务的消费者。

????如果提供者有多个实例时，消费者可以通过负载均衡算法，从多个实例中选择一个

Nacos注册中心

服务注册

????Nacos是目前国内占比最多的注册中心组件，在docker配置好nacos，并且导入数据库后就可以使用，然后在pom引入nacos依赖和配置。

<!-- Nacos 服务注册发现 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

spring:
  application:
    name:service1 #服务名称
  cloud:
    nacos:
      server-addr:127.0.0.1:8848 #nacos地址

启动服务，就可以在nacos的服务管理-服务列表看到服务的实例

服务发现

????消费者需要连接Nacos以拉取和订阅服务，因此服务发现的前两步和服务的注册是一样的，后面在加上服务调用即可：

1. 引入Nacos discovery依赖
2. 配置nacos地址
3. 服务发现

????使用DiscoveryClient对象的getInstances()方法获取实例列表（传参为服务名），然后实现负载均衡（使用Random实现，Random传参为列表size），随机从实例列表中取出一个实例，里面包含了实例的全部信息（主机名、端口号、原信息等等），然后使用RestTemplate向提供者发起网络请求，获得HTTP响应。这里就不需要再写死服务提供者的端口信息，一切由Nacos注册中心提供，我们只需要写入服务名即可。

OpenFeign

????如果不使用其他组件，微服务之间的调用是相当的麻烦，调用者的代码要先获取提供者服务实例列表；然后手写负载均，挑选一个实例；接着利用RestTemplate发起http请求，调用另外一个服务；最后还要进行解析结果，代码实现是很麻烦的。

OpenFeign如何解决这个问题

????OpenFeign是声明式的HTTP请求客户端，可以让我们写http请求时变得更加简单、优雅。

未完待续