〇、课程内容

课程规划

Day1 介绍及应用场景

Day2 组件介绍及 广度

Day3 设计思想、原理和源码 

Day4 与容器化的容器（服务迁移、容器编排）

一、业务架构的演进

1、单体架构时代

 缺陷：修改小功能，需要重新打包部署

需要：按照业务的维度进行拆分，每个应用有对应的数据库 

2、垂直化拆分的时代

更该商品，无需修改用户及订单

优势：将大系统拆分为不同的子系统

劣势：部署的复杂性增加

存在问题：并发量大、用户数大时（不断查询），经验值qps读写；尤其大促场景

3、集群化时代

集群化之前加负载均衡器，应用高可用的部署方案（负载均衡）

存在问题：访问积分信息，需要进行认证请求，各个服务均需要进行登录，很多功能代码冗余

方案：把不同模块（登录、注册、邮件）抽离出来，得到基础服务

4、SOA架构

 业务访问基础服务

5、微服务架构microservices--SOA架构的变体

是一个开发的独立系统，该系统由多个小的服务组成，每个服务都会运行在独立的Java进程中，并且各个服务之间会使用轻量级的通信机制进行通信（调用）

调用方式：HTTP协议

通过自动化运维机制完成部署：CICD（Continious Intergatation Continious Delivery DevOps）

这些服务是去中心化的（某个服务节点挂掉，其他服务也可以提供完整的功能）

可以采用不同的编程语言完成，不局限于Java进行开发

不同服务可以采用不同的数据存储技术（搜索es，缓存redis）

二、具体介绍

1、单体架构与微服务架构的比较

（1）单体架构

优势：所有代码部署在一个war包，方便部署和测试

劣势：开发效率-需要联调、代码维护难、扩展性比较低、可用性低--系统挂了无法为用户提供服务

（2）微服务架构

优势：各个服务的独立性、技术栈灵活、数据库选择灵活、团队高效

劣势：额外的工作【DDD领域驱动设计】、保证数据的一致性

2、微服务需要解决的问题

调用--跨网络方式通信

负载均衡如何解决

服务调用失败，如何处理-容错机制（立即返回、等待、休眠一段时间再访问）

入口层网关

数据一致性如何保证（事务如何保证）

3、解决

阿里开发了一系列组件，用于解决上述问题，如dubbo、seata

Netflix开发了一系列组件，解决上述问题，eureka、ribbon等

微软……

即大公司内部搞了一些中间件

 一家小公司，对Spring服务拆分之后，会形成一个spring工程

A：整合dubbo、seata、nacos、

对一个普通的spring工程而言，

4、介绍

提供了一个标准，包含很多组件

阿里巴巴实现了标准，并将很多组件进行整合

各个厂商使用装饰者模式对标准的接口进行实现

左边是Spring Cloud自己写了接口和实现类

右边是各个厂商写的实现类（实现Spring Cloud的标准）

需要基于Spring生态作为标准

 

 三、使用

1、创建项目及工程

大项目中，构建多个工程

 

 2、更改配置

两个工程的配置文件改为 yml格式，改成不同的端口

3、版本的兼容性

改为统一的版本

 4、Spring Cloud组件进行整合

整合顺序：整合Spring Cloud的版本

 父pom整合插件，子pom无需整合插件和测试包

 

 

 无需写每个组件的版本

5、设置并行运行

四、注册中心

1、服务的ip地址及端口维护（注册中心）

 注册中心：存储服务及服务的URL

不同服务注册到那台机器，实现服务的统一维护

解决

 即服务注册与发现

服务发现：根据注册中心找到对应的URL地址

在注册中心中，可以进行选择，例如netflix可以使用Eureka或阿里巴巴的Nacos（那扣死）

或者也可以选择zookeeper、Etcd等

2、注册启动--启动服务端

可以采用源码启动或二进制包启动

以Nacos为例，可以先启动Nacos的server进行启动

 默认使用8848端口进行监听

 Nacos会通过集群的方式启动，为了避免寻找，可以配置组内启动，表示以单机的方式启动Nacos Server

设置单机启动的参数 

3、Nacos Server上进行服务注册

服务注册的命令：

 服务发现的命令：

在InstanceController中接收参数

4、启动Nacos

5、配置

指定Nacos服务（注册中心）的地址

指定不同服务的地址（采用当前机器作为 默认地址）

 

 6、总结：基于Spring Boot+Nacos，整合了服务注册与注册发现

可以从客户端浏览器查看Nacos的状态

 需要向Nacos发送

7、不同服务的注册

可以注册到不同的Nacos上

 

 8、服务发现

写接口测试

 使用@Resources注解表示从IOC容器中获取注册信息，同@AutoWired

服务发现是一个接口

 不同厂商编写实现类

 那么UserService就能够访问oder-service

9、负载均衡

 有多个url，进行负载均衡操作

可以自定义负载，筛选出想要的内容

 可以自定义负载均衡算法：轮训、权重、随机

 拿到随机的url地址

默认的是使用ribbon

五、服务调用使用restTemplate

1、选型

2、注入

3、调用

 

4、总结

 缺陷：需要手写负载均衡，算法单一

 六、使用Netflix的Ribbon进行负载均衡

1、步骤

引入依赖、写配置、写注解

2、负载均衡方法体验

 

 Ribbon使用LoadBalancerClient接口，Ribbon对其实现，返回的是实现类

 使用Idea的Restful Tool进行测试

 3、使用注解测试

自带负载均衡的restTemplate-服务发现

 @LoadBalance将

 4、Ribbon的使用方式

原生+配合RestTemplate

5、与Nginx的对比

服务端负载均衡

 客户端负载均衡--Ribbon

6、选择不同负载均衡的方式

如果想要更改某个组件的具体配置

方式1：定义一个java类去配置对应的一些Bean

方式2：在yml文件中进行配置

七、服务调用-fen

1、面向对象开发思想

Object#Method

可以使用OpenFeign

使用MVC注解完成客户端的调用

 可以改变使用方式

 符合面向对象的开发方式

 2、步骤

引入依赖、写配置、写注解

创建feign的包，创建一个接口

 注解替换

 使用

 

 3、总结

原理：会根据服务名称获取到URL地址，并与方法进行拼接

 debug会生成动态代理实现类，完成query的实现

 不同的服务使用不同的Feign（在feign包下的不同接口）

 4、使用HttpClient客户端调用方式

@RequestMapping的注解和接口中的注解的区别与联系：之前开发接口时，定义在服务端（服务端声明好等待客户端进行调用）

而现在使用feign：将其定义在客户端，在客户端发挥作用，（客户端调用服务端）

八、更改组件的行为

1、Ribbon

修改负载均衡策略

2、Feign

例如修改feign的日志级别

修改调用方式

3、修改位置yml配置文件--修改组件的行为

打印出了日志

 

作者：哥们要飞​