单体架构：将业务全部功能集中到一个项目中，打成一个war包存储,部署在一台服务器中，只有一个数据库

优点 ：架构简单，部署成本低。适合小型项目

问题：高并发性能问题，开发时代码耦合问题，部署升级时停服的问题

垂直架构：拆分模块，每个模块使用自己的数据库，如果有模块需要其他模块数据时需要自己查对方模块数据库

问题：大量代码冗余，系统难以维护，性能问题，部署问题

分布式架构：根据业务功能对系统做拆分，每个业务功能作为独立项目开发，称为一个服务

服务之间相互调用，分布式多节点部署

优点：降低耦合，有利于服务升级和拓展  适合大型互联网项目

缺点：服务调用关系错综复杂

在进行服务拆分的时候要考虑很多问题：服务拆分的粒度如何界定，服务之后如何调用，服务的调用关系如何管理，需要指定一套有效的标准来约束分布架构

微服务

架构特点：1.单一职责，每一个服务对应唯一的业务能力，做到单一职责

2.自治，团队独立，技术独立，数据独立，独立部署和交付

3.面向服务，服务提供统一的接口，与语言技术无关

4.隔离性强，服务调用做好隔离，容错，降级避免出现级联问题（级联故障是由于正反馈循环并且随着时间的增加所产生的故障。典型表现：最初由单个节点或子系统故障触发的连锁反应）

微服务的上述特点给分布式架构制定啦一个标准，进一步降低服务之间的耦合，提供服务的独立性和灵活性。微服务是一种经过良好架构设计的分布式架构方案

微服务技术的对比

SpringCloud微服务框架

官网地址：Spring Cloud

开发springcloud组件的组织：spring社区，alibaba，netflix

springCloud集成了各种微服务功能组件，基于SpringBoot实现组件的自动装配

常见的组件：服务注册发现（Eureka,nacos,consul），服务远程调用(OpenFeign,Dubbo)，服务链路监控(Zipkin,Sleuth)，统一配置管理(SpringCloudConfig,nacos)，统一网关路由(SpringCloudGateway,zuul)，流控降级保护(Hystix,Sentinel)

SpringCloud底层是依赖于SpringBoot的，并且有版本兼容关系

 服务拆分原则：1.不同微服务不用重复开发相同业务

2.微服务数据独立，有自己的数据库

3.微服务可以将自己的业务暴露为接口，供其他微服务使用

远程调用

微服务的调用方式：基于RestTemplate发起的http请求实现远程调用，http请求做远程调用只要知道ip，端口，接口路径，请求参数即可。

步骤：1.注册RestTemplate的实例到Spring容器

2.修改消费者order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User

3.将查询到的User填到Order对象

1.

#在order-service服务中的OrderApplication启动类中，注册RestTemplate实例
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {public static void main(String[] args) {SpringApplication.run(OrderApplication.class, args);}@Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}

2.

#修改order-service服务中的OrderService类中的queryOrderById方法
@Service
public class OrderService {@Autowiredprivate OrderMapper orderMapper;@Autowiredprivate RestTemplate restTemplate;public Order queryOrderById(Long orderId) {// 1.查询订单Order order = orderMapper.findById(orderId);//2查询用户String url="http://userservice/user/"+order.getUserId();User user = restTemplate.getForObject(url, User.class);// 3封装user信息order.setUser(user);// 4.返回return order;}
}

在服务调用关系中，会有两个不同的角色，这两个角色是相对的

服务提供者Provider：一次业务中，被其他微服务调用的服务，提供接口给其他服务

服务消费者consumer：一次业务中，调用其他微服务的服务，调用其他微服务提供的接口

注册中心

解决问题：服务注册与发现（服务治理问题）

Eureka注册中心

EurekaServer:服务端，注册中心

EurekaClient:客户端

服务注册：提供者启动之后将自己的信息注册到eureka-server(Eureka服务端）

eureka-server保存服务名称到服务实例地址列表的映射关系

服务拉取：消费者根据服务名称拉取实例地址列表（注册表）并缓存到本地

消费者根据负载均衡算法选中一个实例地址，发起远程调用

健康检查：提供者每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态。称为心跳

当超过一段时间（90秒）没有发送心跳，eureka-server认为微服务实例故障，将该实例从列表中剔除，拉取服务时，该故障实例排除

搭建eureka-server

1.引入依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

2.编写启动类

@SpringBootApplication
@EnableEurekaServer    //开启eureka的注册中心功能
public class EurekaApplication {public static void main(String[] args) {SpringApplication.run(EurekaApplication.class, args);}
}

3.编写配置文件application.yml

server:port: 10086
spring:application:name: eureka-server
eureka:client:service-url: defaultZone: http://127.0.0.1:10086/eureka

启动成功

服务注册

引入依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

 配置文件

spring:application:name: orderservice
eureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

可以将user-service多次启动，模拟多实例部署，注意修改端口设置 -Dserver.port=自定义的端口号

如果没有service选项【IDEA】idea打开新项目，左下角的工作栏中没有显示Services解决办法 - Angel挤一挤 - 博客园

 在order-service完成服务拉取，修改OrderService的代码，修改访问路径

 在order-service项目的启动类OrderApplication中RestTemplate添加负载均衡诸界

    @Bean@LoadBalanced    //负载均衡注解public RestTemplate restTemplate(){return  new RestTemplate();}

负载均衡

SpringCloud底层利用Ribbon的组件，实现负载均衡。服务调用者动态调用服务提供者的多个节点

Ribbon内部就是集成了LoadBalancerClient负载均衡，通过@LoadBalance注解开启负载均衡器。

基本流程：RibbonLoadBalanceClient从请求url中获取服务名称，DynamicServerListLoadBalancer根据服务名称到eureka拉取服务列表eureka返回服务列表，IRule利用内置的负载均衡规则从列表中选择一个服务，返回给RibbonLoadBalanceClient

Ribbon的负载均衡规则时一个叫IRule的接口来定义的，每一个接口就是一种规则

内置的负载均衡规则：

RoundRobinRule 简单的轮询服务列表来选择服务器，Ribbon默认的负载均衡规则

ZoneAvoidanceRule 以区域可用的服务器为基础进行服务器的选择

默认的实现就是ZoneAvoidanceRule，是一种轮询方案（一般使用默认的负载均衡规则，不修改）

Ribbon采用默认的懒加载，第一次访问才会去创建 LoadBalanceClient，请求时间会很长。

Nacos注册中心

Nacos是阿里巴巴的产品，现在是SpringCloudAlibaba中的一个组件(SpringCloudAlibaba实现啦对SpringCloud组件进行扩展）

与Eureka的差异：依赖不同，服务地址不同

Nacos服务搭建，下载安装包，解压，在bin目录下运行startup.cmd -mstandalone

引入依赖，在父工程里面，引入

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>2.2.6.RELEASE</version><type>pom</type><scope>import</scope>
</dependency>

 在服务消费者和提供者的pom文件引入nacos的依赖，注释掉eureka的依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

配置nacos地址，在user-service和order-service的application.yml中添加nacos地址，不要忘了注释掉eureka的地址

spring:cloud:nacos:server-addr: localhost:8848

在启动类添加注解@EnableDicoveryClient

 

Nacos服务分级存储模型

一个服务有多个实例，实例分布在不同的机房中，Nacos将同一机房的实例划分为一个集群

服务-集群-实例

服务调用尽可能选择本地集群的服务，跨集群调用延迟较高。（本地集群不可访问时，在访问其他集群）

给user-service配置集群，修改user-service的application.yml文件

spring:cloud:nacos:server-addr: localhost:8848discovery:cluster-name: HZ # 集群名称

复制一个user-service启动配置，添加属性

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

默认的zoneAvoidanceRule不能实现同集群有效实现负载均衡，Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

修改负载均衡规则修改order-service的application.yml文件，修改负载均衡规则：

userservice:ribbon:NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

根据权重负载均衡：在实际部署中提高权重配置来控制访问频率，权重高访问频率高

在Nacos控制台设置实例的权重值0~1之间

环境隔离namespace

Nacos中服务存储和数据存储的最外层都是一个namespace的东西，用做最外层隔离，修改order-service的application.yml文件：

spring:cloud:nacos:server-addr: localhost:8848discovery:cluster-name: HZnamespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

Nacos的服务实例分为两种类型：

临时实例：如果实例宕机超过一段时间，会从服务列表中剔除，默认的类型

非临时实例：如果实例宕机，不会从服务列表中剔除，也叫永久实例

Nacos和Eureka的区别：

相同点：都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测

区别：1.Nacos支持服务端主动检测提供者状态：临时实例采用心跳检测，非临时实例nacos主动询问

2.临时实例心跳不正常被剔除，非临时实例则不会剔除

3.Nacos支持服务礼包变更的消息推送模式，服务列表更新更及时

4.Nacos集群默认采用AP方式，集群中存在非实例时采用CP模式；Eureka采用AP模式

CAP定理：布鲁尔定理

指出对于一个分布式计算机来说，不可能同时满足三点，最多同时满足两点：

一致性(Consistency)系统中所有数据备份，在同一时刻同样的值

可用性(Availability)保证每次请求不管成功失败都有响应

分区容错性（Partition tolerance）系统中任意信息的丢失或失败不会影响系统的继续运作

配置中心

配置统一管理和配置隔离问题

nacos=SpringCloud eureka注册中心+SpringCloud config配置中心

 

 

项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。(热加载：不重启一个项目，使得部分代码更新，通过java类加载器实现）

保证项目中有bootstrap.yml

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动

在bootstrap.yml中提那就配置中心相关内容：环境相关spring.profiles.active

配置中心地址，配置文件后缀

配置加载顺序：先加载共享配置文件，再加载环境相关配置文件，在加载application.yml

 在idea中的使用

导入依赖

<!--nacos配置管理依赖-->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

添加bootstrap.yaml

spring:application:name: userservice # 服务名称profiles:active: dev #开发环境，这里是dev cloud:nacos:server-addr: localhost:8848 # Nacos地址config:file-extension: yaml # 文件后缀名

配置热更新

最终目的，是修改nacos中的配置后，微服务无需重启就可以让配置生效（配置热更新）

使用两种方式：

一：@Value注入的变量所在类上添加注解@RefreshScope：

二： 在controller中使用@ConfigurationProperties注解代替@Value注解。