微服务之RPC(远程过程调用)的四种方式

微服务思想

微服务思想-注册中心zookeeper

微服务: 架构设计采用分布式思想,当服务器发生故障时,可以实现自动化的故障迁移.无需人为干预.

注册中心实现原理:

ZK工作原理说明
Zookeeper集群中leader负责监控集群状态同步数据,follower主要负责客户端链接获取服务列表信息.同时参与投票.
1.当服务器启动时,会将服务器的状态(服务名称/IP/端口) 一起写入注册中心
2.注册中心接收到服务器信息时,会动态的维护服务列表数据.
3/4.当客户端(消费者)启动时,首先会链接注册中心,获取所有的服务列表数据.并且将服务列表数据保存到本地.
5.当消费者执行业务调用时,如果有多个服务的生产者时,采用负载均衡的思想挑选其中的一个服务进行访问(RPC).
6.当服务器发生宕机时,由于注册中心有心跳检测机制,所有会动态的维护服务列表数据.会全网广播通知所有的客户端(消费者)更新服务列表数据. 在更新服务列表时,数据的同步会陷入阻塞的状态.

关于微服务思想负载均衡说明

1 集中式负载均衡
说明: 所有的请求都必须由某个服务器进行统一的管理.
案例: Nginx是集中式的负载均衡,但是nginx主要的作用是做反向代理
2 客户端负载均衡
说明: 请求发送之前,每个客户端都非常清楚的知道,自己应该访问哪台服务器.
在服务器内部.由客户端直接访问后端服务器,将负载的压力进行了分担.
关于集群相关概念

几台服务器可以搭建集群zookeeper

公式: 存活节点 > N/2
算数计算:
1个节点 1-1 > 1/2 假的 不能搭建集群
2个节点 2-1 > 2/2 假的 不能搭建集群
3个节点 3-1 > 3/2 真的 可以搭建集群
结论:集群最小单位3台.

集群一般都是奇数台为什么?

3个节点 3-1 > 3/2 真的 可以搭建集群 允许宕机1台
4个节点 4-1 > 4/2 真的 可以搭建集群 允许宕机1台
说明: 由于搭建偶数台和搭建奇数台的容灾效果相同的,所以一般都是奇数个.

集群中的脑裂现象?

说明: 由于集群工作过程中主机意外宕机. 之后集群开始进行选举.如果出现多次连续平票状态时,则可能出现脑裂现象.
脑裂发生的概率是: 1/8=12.5%
如何有效降低脑裂现象发生: 增加节点的数量

关于zk集群选举的规范
说明: zk集群选举规则是myid最大值优先的算法,如果选举结束,则剩余的节点当新主机的从机.
考题1: 如果依次启动1-7台zk节点
问1: 谁当主机? 4
问2: 谁永远不能当选主机? 1,2,3

SOA思想(面向服务的架构)

面向服务的架构（SOA）是一个组件模型(编程方法)，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
![在这里插入图片描述](https://img-blog.csdnimg.cn/2020121718070420.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzUyMDcxNTQ0,size_16,color_FFFFFF,t_70

RPC(远程过程调用)

RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。
本地过程调用: 如果需要完成业务逻辑,则直接去调用本地的方法即可.
远程过程调用: 我想完成一个业务的调用,但是该功能我没有办法直接调用,需要通过第三方帮助我完成业务规则.
具体用法: RPC不关注具体的实现规则,用户也不需要了解具体的协议.谁调用谁实现.

2.RPC调用的方式有三种

1.跨域访问(jsonp和cors)
2. HttpClient
3.

2.1跨域访问(jsonp和cors)

什么是跨域？

说明: 浏览器(解析页面地址)在解析(页面发起ajax)Ajax请求时,由于违法了同源策略,则把该访问称之为跨域访问.

同源策略

说明: 浏览器规定 用户访问的域名与该域名中展现的页面中的ajax请求,必须满足如下的条件时,才能访问成功.
条件:要求全部相同1).协议规则 http/https/tcp-ip 2).域名地址 www.jt.com/manage.jt.com 3).端口号: 80/8081/8091…

1).满足同源策略的规定,称之为同域访问.
页面url地址: http://manage.jt.com:80/test.html
Ajax网址: http://manage.jt.com:80/test.json
该组合可以实现业务的调用.
协议://域名:80端口
2).不满足同源策略规定,称之为跨域访问.
页面url地址: http://www.jt.com/test.html
Ajax网址: http://manage.jt.com/test.json
结果: 请求不能正常的获取返回值结果.

2.1.1 JSONP方式

JSONP(JSON with Padding)是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。由于同源策略，一般来说位于 server1.example.com 的网页无法与不是 server1.example.com的服务器沟通
JSONP原理说明
步骤:
1).利用javaScript中的src属性实现远程数据的获取 获取的数据是一个JS对象 由浏览器负责解析JS.


JSONP优化
1).函数名称应该动态传递过去的.
2).能否利用常规的ajax实现JSONP调用.
3).能否动态生成一个回调函数.
前端url:http://www.jt.com要访问后端的url:http://sso.jt.com
检索所有的代码 搜索需要的内容 在eclipse下按ctrl+h**

应用场景

1.业务说明
说明:当用户输入内容之后,当鼠标离焦时,应该发起Ajax请求去后端服务器JT-SSO校验数据是否存在. 如果数据存在应该提示用户,如果数据不存在则告知用户该数据可以使用.

测试js的图如下

2.页面JS分析
3.编辑全局异常处理机制

4.编辑JT-SSO UserController
5.编辑JT-SSO UserService

2.1.2 CORS方式

CORS介绍
跨域资源共享（英语：Cross-origin resource sharing，缩写：CORS），用于让网页的受限资源能够被其他域名的页面访问的一种机制。(实现跨域),CORS通过在响应头中标识允许跨域的网址.之后同源策略基于安全性的规范予以放行的一种跨域访问方式.
说明:需要在服务器中添加允许访问的标识即可.
通过该机制，页面能够自由地使用不同源（英语：cross-origin）的图片、样式、脚本、iframes以及视频。[2]一些跨域的请求（特别是Ajax）常常会被同源策略（英语：Same-origin policy）所禁止的。跨源资源共享定义了一种方式，为的是浏览器和服务器之间能互相确认是否足够安全以至于能使用跨源请求（英语：cross-origin requests）。[3]比起纯粹的同源请求，这将更为自由和功能性的（functionality ），但比纯粹的跨源请求更为安全。
跨域资源共享是一份浏览器技术的规范，提供了 Web 服务从不同网域传来沙盒脚本的方法，以避开浏览器的同源策略
1.编辑CORS配置类

2.2 HttpClient

HttpClient介绍
HTTP 协议可能是现在 Internet 上使用得最多、最重要的协议了，越来越多的 Java 应用程序需要直接通过 HTTP 协议来访问网络资源。虽然在 JDK 的 java net包中已经提供了访问 HTTP 协议的基本功能，但是对于大部分应用程序来说，JDK 库本身提供的功能还不够丰富和灵活。HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本和建议。HttpClient 已经应用在很多的项目中，比如 Apache Jakarta 上很著名的另外两个开源项目 Cactus 和 HTMLUnit 都使用了 HttpClient。
远程访问调用流程

HttpClient案例说明

2.4.1 业务场景
要求:
1)通过http://www.jt.com/user/findUserList,并且要求JSON结构返回用户数据…
2)JT-WEB服务器网址应该向JT-SSO获取用户信息.
URL: http://sso.jt.com/userfindUserList. 获取全部的用户信息.
使用HttpClient方式实现.
1.添加jar包

2.编辑JT-SSO UserController

3 编辑JT-SSO UserService

4 编辑JT-WEB UserController

5.编辑JT-WEB HttpClientUserServiceImpl
* 1.实例化HttpClient客户端对象
* 2.定义url地址
* 3.定义请求类型
* 4.发起httpClient请求
* 5.获取响应结果 分析状态码信息 200 404 500 504 502
* 6.获取结果,进行后续操作

3.Dubbo框架(基于zookeeper集群的搭建)

Dubbo框架介绍

Apache Dubbo 供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

Dubbo入门案例

1. 导入jar包

    
        com.alibaba.boot
        dubbo-spring-boot-starter
        0.2.0
    

2.定义中介接口
2. 编辑服务生产者(编辑接口实现)
说明:注意service注解导入的是dubbo的注解

4.编辑YML配置文件
#关于Dubbo配置
dubbo:
scan:
basePackages: com.jt #指定dubbo的包路径
application: #应用名称
name: provider-user #一个接口对应一个服务名称 如果是多个实现类则应用名称一致
registry:
address: zookeeper://192.168.126.129:2181?backup=192.168.126.129:2182,192.168.126.129:2183
protocol: #指定协议
name: dubbo #使用dubbo协议(tcp-ip) web-controller直接调用sso-Service
port: 20880 #每一个服务都有自己特定的端口 不能重复.

5.编辑服务消费者( 编辑UserController

3. 编辑消费者的YML配置文件

4.SpringCloud(可以集成所有的注册中心)

Sprin Cloud是框架集,集成了许多框架,多个工具,用来解决微服务系统中遇到的各种问题
不像Spring MVC 和mybatis只解决一个单一的问题,而是对于服务系统中遇到的所有问题,提供了一整套的解决方法(微服务全家桶)
做到开箱即用具体工作配置参考手册来做,掌握每个工具的功能和作用,每个工具部署的位置
注册中心:作用,注册和发现
所有服务启动,都要把自己的地址注册到注册中心:注册的是服务id和主机的地址

eureka注册中心(zookeeper注册中心)

consul,nacos,etcd等注册中心

4.1 eureka工作机制

1 注册

服务提供者启动时,会一次次反复尝试向eureka注册,直到连接成功

2.拉取

消费者每30秒拉取一次注册表,来刷新注册表

心跳

服务提供者每30秒向eureka发送一次心跳数据,eureka服务器如果连续3收不到一个服务的心跳,则删除这个服务的注册信息

自我保护模式

如果因为网络不稳定,15分钟内,85%的服务器出现心跳异常,会自动进入自我保护模式
所有的服务注册信息都不删除,等网络恢复后可以自动退出保护模式,恢复正常
开发调试之期间,可以禁用保护模式,避免影响测试

4.2 搭建服务器

1.新建项目添加eureka server依赖
2.yml,
(1),禁用自我保护模式
(2),主机名,集群中用来区分不同的服务器
(3)针对单台服务器:不向自己注册,不从自己拉取注册表
3.启动类添加注解@EnableEurekaServer:触发eureka 服务器的自动配
4.修改host文件将一个127.0.0.1 eureka1,127.0.0.2 eureka2配置
一个中心 eureka (微服务治理，服务注册和发现)
俩个基本点 rubbon (负载均衡、请求重试 )hystrix（断路器，服务降级、熔断)
三个工具 feign zuul
四个监控

feign
ribbon + hystrix 集成，并提供声明式客户端
hystrix dashboard 和 turbine
hystrix 数据监控

zuul

zuul API 网关，为微服务应用提供统一的对外访问接口。
zuul 还提供过滤器，对所有微服务提供统一的请求校验。
nginx—>zuul—>后台
1.API 网关，提供微服务的统一调用入口，并提供统一的权限验证,可以看做是一个代理对象,用户的权限通过过滤器进行判断，后端只需要写业务代码无需考虑权限.
1.添加zuul依赖,eureka client依赖
2.yml配置路由转发规则,默认的配置,根据注册表的注册信息可以进行自动配置,一般都要手动配置,防止注册信息不全
3.在主启动类上加注解@EnableZuulProxy @EnableDiscoveryClient

提供统一的权限验证

网管添加权限判断代码,后台服务不需要再判断权限,只关注业务就可以了
zuul提供一个过滤器,可以继承过滤器,在子类中添加权限判断
token的传递:cookie传递,协议请求头传递

添加过滤器

1.继承zuulFilter,
2.添加@component注解,自动找到过滤器实例,来完成自动配置
自定义过滤器:
前置过滤器:负责向后台转发
路由过滤器:
后置过滤器:
<-@Component//加此注解完成自动配置
public class AccessFilter extends ZuulFilter {
//过滤器类型 pro post rooting error
//直接返回写"pre" ,FilterConstants.PRE_TYPE常量值都可以
@Override
public String filterType() {
return FilterConstants.PRE_TYPE;
}
//过滤器插入的位置前置过滤器第6个
//在第5个过滤器中在上下文对象添加了serviceId
//在后边过滤器中才能访问serviceId
@Override
public int filterOrder() {
return 6;
}
//对用户的请求进行判断,判断是否要执行过滤代码,即执行后边的run方法
@Override
public boolean shouldFilter() {
/*只对item-service调用进行过滤
* 如果调用user-service或者order-service不执行过滤代码
* */
//1.获得调用的服务Id,当前请求的上下文对象
RequestContext c=RequestContext.getCurrentContext();
String serviceId=(String) c.get(FilterConstants.SERVICE_ID_KEY);
//2.判断是否是item-service,equalsIgnoreCase忽略大小写进行比较
return “item-service”.equalsIgnoreCase(serviceId);
}
//过滤代码
@Override
public Object run() throws ZuulException {
///判断url中是否有token,
// 1.获取token参数,要用request对象获取参数,
RequestContext ctx=RequestContext.getCurrentContext();
HttpServletRequest request=ctx.getRequest();
// 2.接受token
String token=request.getParameter(“token”);
// 3.如果没有token,阻止访问,并直接向客户端返回响应/
if(StringUtils.isBlank(token)){
//阻止继续访问
ctx.setSendZuulResponse(false);
String json=JsonResult.err().code(JsonResult.NOT_LOGIN).msg(“not login”).toString();
ctx.addZuulRequestHeader(“Content-Type”, “application/json;charser=UTF-8” );
ctx.setResponseBody(json);
}
return null;//返回值没有任何作用
}
}
->
zuul不推荐启动重试
rubbon
hystrix:不需要任何配置,添加降级代码,实现zuul提供的FallbackProvider接口,只加一个@component注解,自动配置类,会自动发现降级类的实例,完成自动的配置
feign不推荐启用hystrix
暴露监控端点

zuul和feign

调用远程服务
集成ribbon
集成hystrix
zuul网关,作为一个独立的服务,部署在系统的最前边.不推荐使用重试在最前边使用,会造成后台所有服务器访问压力倍增
feign- 业务微服务系统内部,是服务与服务之间进行调用,不是一个独立的服务,不推荐使用hystrix,降级熔断

config
配置中心
bus
消息总线, 配置刷新
sleuth+zipkin
链路跟踪