1 微服务架构
1-1 支付项目实例
技术架构演变
单体架构：所有功能集成在一个项目中部署到服务器上，所有功能使用同一个数据库
- 优点与缺点：从开发与维护与满足需求三个角度思考
分布式架构（按业务拆分成子系统）：
- 缺点：数据冗余，由于业务拆分，无法做到细粒度的需求调整
SOA架构（面向服务架构）：将重复公用的功能抽象为组件（服务）
- 缺点：抽取服务的界限不明确，服务的接口协议不利于维护
微服务架构(移动场景下，支持多客户端)：延续SOA架构，将服务的粒度变的更加小。
- 缺点：开发困难，不利于维护
典型的支付项目架构
2 Nacos的概述
2-1 Nacos在微服务中发挥的作用
Nacos的界面可以看到，主要有三大类功能！！！！：
Nacos主要提供以下四大功能：
1. 服务发现与服务健康检查(重点)
Nacos使服务更容易注册，并通过DNS或HTTP接口发现其他服务，Nacos还提供服务的实时健康检查，以防
止向不健康的主机或服务实例发送请求。
2. 动态配置管理（重点）
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新
部署应用程序，这使配置的更改更加高效和灵活。
3. 动态DNS服务
Nacos提供基于DNS协议的服务发现能力，旨在支持异构语言(不仅仅Java)的服务发现，支持将注册在Nacos上的服务以
域名的方式暴露端点，让三方应用方便的查阅及发现。
4. 服务和元数据管理（重点）
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周
期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。
2-2 微服务的服务发现
微服务架构：
- 系统拆分成若干小的服务。每个小服务单独一个进程
- 服务与服务之间通过RESTful,RPC等轻量协议传输
微服务的服务发现：
服务之间需要远程调用的时候，比如服务A（服务消费方）要调用服务B（服务提供方），首先需要进行服务发现。
微服务的简单实例：
整个父工程包含2个子工程分别是服务调用工程以及服务提供工程，先启动服务提供工程，然后启动服务调用工程。
服务提供方：暴露IP与端口号
- 提供服务调用，通过定义RestController实现0
服务发现的流程：
访问服务调用方A------->服务调用方A访问服务提供方B------>A获得B提供的结果------>A返回结果给服务访问方
实例存在的问题：
服务实例的网络位置或许是动态分配（配置文件无法解决问题）
- 负载均衡问题
- 临时访问压力增加新的服务节点
服务发现的真实定义（为什么需要服务发现）
服务发现：服务消费方通过服务发现中心智能发现服务提供方，从而进行远程调用的过程。
服务发现流程：
- 在每个服务启动时会向服务发现中心上报自己的网络位置。这样，在服务发现中心内部会形成一个服务注册
表，服务注册表是服务发现的核心部分，是包含所有服务实例的网络地址的数据库 。 - 服务发现客户端会定期从服务发现中心同步服务注册表（新增或删除） ，并缓存在客户端（可以在客户端实现服务调用的负载均衡）。
- 当需要对某服务进行请求时，服务实例通过该注册表，定位目标服务网络地址。若目标服务存在多个网络地
址，则使用负载均衡算法从多个服务实例中选择出一个，然后发出请求
总结：
用动态的服务发现机制用于实现微服务间的相互感知。 各服务实例会上报自己的网络地址，这样服务中心就形成了一个完整的服务注册表，各服务实例会通过服务发现中心来获取访问目标服务的网络地址，从而实现服务发现的机制。
2-3 问题：分布式系统中的CAP是指的什么？
浅析分布式中的 CAP、BASE、2PC、3PC、Paxos、Raft、ZAB
- 从上图可以看到作为服务发现中心，实际应用中必须保障 分区容错性P,然后在一致性与可用性进行选择。
CAP理论： 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和 分区容错性（Partition tolerance）这三项中的两项。
一致性（Consistency）: all nodes see the same data at the same time,所有节点在更新操作完成后保持数据到一致性
可用性（Availability）:可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。
分区容错性（Partition tolerance）：“the system continues to operate despite arbitrary message loss or failure of part of the system”，系统能够在容忍出现一定范围的故障时正常工作。
3 Restful接口服务发现流程（服务发现）
3-1 服务发现的核心目标
通过Spring Cloud Alibaba实现解决（SpringCloud是微服务框架的一套标准，集成了很多优秀的其他框架）：
1、服务发现客户端从服务发现中心获取服务列表（服务注册保证）
2、服务消费方通过服务注册中心结合负载均衡机制获取服务地址（服务发现）
流程：
服务消费方通过应用客户端建立连接 => 连接服务注册中心获取服务列表 => 消费方通过负载均衡机制获取服务IP地址
服务提供方通过应用客户端建立连接（需要配置服务名称以及服务中心的IP地址） => 服务中心注册自己的服务
知识点
Restful介绍 REST API concepts and examples
REST：Representational State Transfer
Restful:定义的接口规范
1.每一个URI代表一种资源(Representational)；
2.客户端和服务器之间，传递这种资源的某种表现层(State)；
3.客户端通过四个HTTP动词（get、post、put、delete），对服务器端资源进行操作，实现”表现层状态转化(Transfer)。
Restful需要满足的六个规范：客户端-服务器结构，无状态，统一接口，层次化的系统，按需执行脚本（可选）
3-2 Nacos的Restful服务管理
服务管理包含有：服务发现/注册配置
管理中心
上图中可以看到注册服务的详细信息，包括服务名称以及服务的IP以及端口
对应配置项目
spring:
application:
name: nacos-restful-provider # 服务名称
cloud:
nacos:
discovery:
server-addr: 49.52.10.41:8848 # 注册中心地址
负载均衡定义：将用户请求（流量）通过一定的策略，分摊在多个服务实例上执行，它是系统处理高并发、缓解网络
压力和进行服务端扩容的重要手段之一
负载均衡分类：服务端负载均衡和客户端负载均衡。
负载均衡的执行部件：负载均衡器
3-3-1 服务端负载均衡的概念
特点：服务端维护服务实例清单
上图是服务端负载均衡，其中负载均衡器作用：
1）维护一个可用的服务实例清单
2）当客户端请求来临时，负载均衡服务器按照某种配置好的规则（负载均衡算法)从可用服务实例清单中选取其一去处理客户端的请求
常见的服务端负载均衡：
1）Nginx进行七层（应用层即http请求）负载均衡，客户端发送请求至Nginx，Nginx通过负载均衡算法，在多个服务器之间选择一个进行访问。即在服务器端再进行负载均衡算法分配
2）LVS进行四层（网络层即IP地址）负载均衡
3-3-2 客户端负载均衡的概念
特点：客户端维护服务实例的清单（Nacos就是采用的客户端负载均衡机制）
@RestController
@RequestMapping("/")
public class RestfulConsumerController {
/*调用服务的名称*/
String serviceId = "nacos-restful-provider";
@Autowired
LoadBalancerClient loadBalancerClient;
@GetMapping(value = "/service1")
public String service(){
RestTemplate restTemplate = new RestTemplate();
ServiceInstance serviceInstance = loadBalancerClient.choose(serviceId); // Nacos的客户端负载均衡机制
// URI包含有URL(URL可以理解为 http://IP:端口).
URI url = serviceInstance.getUri();
System.out.println(url);
//调用服务
String providerResult = restTemplate.getForObject( url+
"/service",String.class);
return "consumer invoke | " + providerResult;
}
}
问题：客户端负载均衡与服务端负载均衡的区别？
- 区别在于维护服务实例表的主体
客户端负载均衡：客户端维护服务注册表，根据负载均衡算法从注册表选取服务实例请求服务
服务端负载均衡：服务端维护服务注册表，服务端根据负载均衡算法将客户端的请求转发到对应服务实例。
3-3-3 Nacos的客户端负载均衡组件Ribbon
roundRobin： 轮询调度
ribbon [ˈrɪbən] ( 带，缎带，带状物)
robin [ ˈrɒbɪn] 知更鸟，人名
Ribbon核心组件IRule是负载均衡策略接口，常见的策略如下：
| 策略名称 | 含义 | 备注 |
|---|---|---|
| RoundRobinRule(默认） | 按一定的顺序轮换获取实例的地址（轮询策略） | |
| RandomRule | 随机获取策略 | |
| AvailabilityFilteringRule | 过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略 | |
| WeightedResponseTimeRule | 根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越大,被选中的机率越高 | 刚启动时,如果统计信息不足,则使用RoundRobinRule策略,等统计信息足够时,会切换WeightedResponseTimeRule |
| RetryRule | 按照RoundRobinRule的策略获取服务,如果获取服务失败,则在指定时间内会进行重试 | |
| BestAvailableRule | 过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务 | |
| ZoneAvoidanceRule | 默认规则,复合判断server所在区域的性能和server的可用性选择服务器 |
4 dubbo协议服务发现（服务发现）
4-1 RPC概念辨析
定义：RPC可以看作不同进程通过网络进行通信的一种技术，也可以理解为当前主机调用非本地的函数
RPC: A remote procedure call is an interprocess communication technique that is used for client-server based applications. It is also known as a subroutine call or a function call.
RPC的流程：
A client has a request message that the RPC translates and sends to the server. This request may be a procedure or a function call to a remote server. When the server receives the request, it sends the required response back to the client. The client is blocked while the server is processing the call and only resumed execution after the server is finished（同步调用，调用者会阻塞）.
RPC优点：
1)Remote procedure calls support process oriented and thread oriented models.(以进程/线程为中心)
2)The internal message passing mechanism of RPC is hidden from the user.(具体的消息传递对使用者是透明的)
3)The effort to re-write and re-develop the code is minimum in remote procedure calls.(使用方便)
4)Remote procedure calls can be used in distributed environment as well as the local environment. Many of the protocol layers are omitted by RPC to improve performance.(适用于分布式环境)
RPC与http的区别？
http是一种具体的应用层的协议，而RPC(remote procedure call)是一种宏观上的技术
RPC与dubbo关系？
RPC技术可以采用多种方式实现，Dubbo是采用Java的实现RPC技术的一种框架，该框架自定义了应用层协议叫做Dubbo协议，此外该框架在传输层依旧使用TCP。
Rest与RPC的不同？
1）API设计理念
RPC以调用过程为中心，而Rest是以资源为中心
--RPC is process-oriented and only sends GET and POST requests. GET is used to query information, otherwise POST is used. The request parameter is a verb, which directly describes the action itself.
---RESTful is resource-oriented and uses POST, DELETE, PUT, and GET requests to correspond to add, delete, modify, and check operations respectively. The request parameter is a noun, and this noun is what the "add, delete, modify, and check" wants to operate.（HTTP协议的附带属性）
2）实现机制
1）Restful通常是基于http协议
2）RPC作为进程远程交流的方式，可以使用https实现，当然也可以以应用层协议减少协议的开销，比如dubbo就是自定义应用层协议dubbo协议并结合TCP实现远程调用
3）应用场景
应用时主要考虑耦合性以及性能的balance.
| 名称 | 优点 | 缺点 |
|---|---|---|
| Restful | 耦合性低，兼容性好，提高开发效率，不用关心接口实现细节，相对更规范，更标准，更通用，跨语言支持 | 性能不够好 |
| RPC(Dubbo) | 相比Rest,调用简单，清晰，透明，可自定义协议(比如Dubbo协议)提供效率，自带负载均衡 | 耦合性高 |
总结：
RPC 适用于内网服务调用，对外提供服务请走 REST（耦合性考虑）
IO 密集的服务调用用 RPC，低频服务用 REST（性能考虑）
服务调用过于密集与复杂，RPC 就比较适用（性能考虑）
在微服务架构中：
| 调用方式 | ||
|---|---|---|
| 微服务应用服务器 | 微服务应用服务器 | RPC(比如dubbo提供RPC实现) |
| 微服务应用服务器 | 应用服务器 | RPC(应用服务器调用微服务) |
| 应用服务器 | 应用服务器 | Restful |
| 用户客户端 | 应用服务器 | http请求路径 |
4-2 Duddo的典型架构（重要）
上图的架构同时提供RESTful和Dubbo接口服务：
1）应用层对前端（网关）以及其他应用提供RESTful接口，RESTful是互联网通用的轻量级交互协议，方便前端接入系统（通用性好）。
2）微服务层向应用层提供Dubbo接口，Dubbo接口基于RPC通信协议速度更快 。
交互互流程：
1、网关负责客户端请求的统一入口，路由转发，前端通过网关请求后端服务。
2、网关收到前端请求，转发请求给应用。
3、应用接收前端请求，调用微服务进行业务逻辑处理
4、微服务为应用提供业务逻辑处理的支撑，为应用提供Dubbo协议接口
4-3 Dubbo的使用
需求：简单实现3个应用，其中2个是微服务应用，对外暴露基于dubbo协议的RPC接口。另外一个是应用层应用，该应用接受用户的http请求然后去调用对应的
微服务。实现时要求：应用层应用能够通过RPC远程调用两个微服务应用，微服务应用1能够通过RPC调用调用微服务应用2。
最终实现：
上图中可以看到dubbo-service1和dubbo-service2这两个微服务，一个nacos-restful-consumer
5 Nacos的服务发现管理
5-1 命名空间隔离
命名空间作用：用于进行租户粒度的隔离，Namespace 的常用场景之一是不同环境的隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离，不同开发者的微服务的隔离。
可以在配置文件中设置创建非public的namespace的id。
- 上图中就是名称为dev的namesapce的id.
5-2 服务-集群-实例（IP）的三层模型
下图可以看到Nacos的管理控制台也是按照 服务名，分组，集群数目，实例数，健康实例数来显示具体某个服务的信息的。
一种特定的微服务可能部署在多个集群上，即有多台服务器提供对应的微服务。
概念：微服务 <==== 集群 <====== 服务器实例
概念辨析：
1）服务：对外提供的软件功能，通过网络访问预定义的接口
2）服务名：服务提供的标识，通过该标识可以唯一确定要访问的服务。
3）实例提供一个或多个服务的具有可访问网络地址（IP:Port）的进程，启动一个服务，就产生了一个服务实例。
4）元信息：Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。
5）集群：服务实例的集合，服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群，相同集群下的实例才能相互感知。通过数据模型可知：应用通过Namespace、Service、Cluster(DEFAULT)的配置，描述了该服务向哪个环境（如开发环境）的哪个集群注册实例。
6 Nacos的配置管理中使用（配置管理）
作用：可以在nacos存放配置文件，应用程序可以通过nacos获取信息。
7 Nacos的实际使用注意点
Ubuntu中nacos的启动(采用集群方式启动需要cluster.conf文件配置)：
bash startup.sh -m standalone