weixin_43811057的博客

引入新技术栈时，一定要阅读相关文档了解组件的配置化参数信息(默认值往往在遇到高并发场景无法满足)，特别是对于基于springboot构建的应用，往往由于自动化的配置，导致忽略了重要参数的指定。

详细介绍Spring Cloud 系列之 Sleuth 链路追踪（一）Spring Cloud Sleuth 为 Spring Cloud 实现了分布式跟踪解决方案。兼容 Zipkin，HTrace 和其他基于日志的追踪系统，例如 ELK（Elasticsearch 、Logstash、 Kibana）。链路追踪：通过 Sleuth 可以很清楚的看出一个请求都经过了那些服务，可以很方便的理清服务间的调用关系等。性能分析。

我们在provider服务有些参数是从请求头中获取的，但是consumer服务在调用feign接口时，本身接口请求头中并没有provider需要的的参数；此时想手动的将一些参数设置到feign接口！如果我们在@RequestHeader指定了请求头参数名称，那么取的时候也需要使用对应的名称。该方式是在方法执行前，先获取需要的参数，后将取出来的值作为参数传递到待执行的方法中。

由于在consumer中子链路调用feign接口，request不支持继承。在调用feign接口时原有的request已经不会跟随到新的请求中，所以provider中request是空的，获取不到参数值。在开发中，A项目需要在后端调用B项目的feign接口。我们知道feign接口是不支持HttpServletRequest作为参数的，所以feign接口如下。request中的值手动设置到feign请求的http调用上。

我们在平时学习中简单知道调用feign接口或者做服务降级；但是在企业级项目中使用feign时会面临以下几个问题： 1. Feign客户端应该如何提供？ 2. Feign调用的接口要不要进行包装？ 3. Feign如何抓取业务生产端的业务异常？

Dubbo【 Dubbo概念（什么是分布式系统、什么是RPC、核心组件、Zookeeper注册中心 ）】(一)-全面详解（学习总结—从入门到深化）Dubbo【 Dubbo入门案例（服务消费者配置、服务消费者代码编写、IDEA开启Dashboard 、序列化协议安全、地址缓存）】(二)-全面详解（学习总结—从入门到深化）Dubbo【Dubbo高级特性（重试机制、多版本 、负载均衡 、集群容错 、服务降级、服务限流原理 、结果缓存） 】(三)-全面详解（学习总结—从入门到深化）

RPC（Remote Procedure Call Protocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简言 之，RPC使得程序能够像访问本地系统资源一样，去访问远端系统资源。比较关键的一些方面包括：通讯协议、序列化、资源（接口）描述、服务框架、性能、语言支持等。简单的说，RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器 (服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。

Spring Cloud GateWay是Spring Cloud的⼀个全新项⽬，⽬标是取代Netflix Zuul， 它基于Spring5.0+SpringBoot2.0+WebFlux（基于⾼性能的Reactor模式响应式通信 框架Netty，异步⾮阻塞模型）等技术开发，性能⾼于Zuul，官⽅测试，GateWay是 Zuul的1.6倍，旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。

Hystix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。Hystrix也是Netflix公司的一款组件。主页：https://github.com/Netflix/Hystrix/Hystrix 是一种开关装置，类似于熔断保险丝。在消费者端安装一个 Hystrix 熔断器，当Hystrix 监控到某个服务发生故障后熔断器会开启，将此服务访问链路断开。不过 Hystrix 并不会将该服务的消费者阻塞，或向消费者抛出异常，而是向消费者返回一个符合预期的备选响应（FallBack）

引入 spring-cloud-starter-openfeign 后，使用 Ribbon 是客户端负载均衡器 则无需引入额外依赖，因为引入的 spring-cloud-starter-openfeign 依赖中集成了 Ribbon。案例中，我们启动了一个feign-provider-modules，然后通过feign-consumer-8080调用feign接口来访问。进程内LB：将LB集成到消费方，消费方从服务注册中心获知哪些地址可用，然后自己再从可用地址中选择一个合适的服务器。

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如tomcat中的session。例如登录：用户登录后，我们把登录者的信息保存在服务端session中，并且给用户一个cookie值，记录对应的session。然后下次请求，用户携带cookie值来，我们就能识别到对应session，从而找到用户的信息。缺点是什么？服务端保存大量数据，增加服务端压力服务端保存用户状态，无法进行水平扩展客户端请求依赖服务端，多次请求必须访问同一台服务器。

对称加密算法中，数据发送方将明文和密钥一起经过特殊加密算法处理成密文后，将它发送出去。接收方收到密文后，若想解读原文，则需要使用加密用到的相同密钥及相同算法的逆算法对密文进行解密，才能使其恢复成原文。它的最大优势是加/解密速度快，适用于大数据量进行加密，缺点是密钥管理困难，最典型的问题就是如何同步这个密钥，同步过程如果在公网上，不进行加密是可以抓包拿到的，那么这里就遇到了要对密钥加密的问题。常见的对称加密算法有 AES、DES、Blowfish 等等。对称加密的核心是只有一把密钥。

非对称加密算法中，有两个密钥：公钥和私钥。它们是一对，如果用公钥进行加密，只有用对应的私钥才能解密；如果用私钥进行加密，只有用对应的公钥才能解密。非对称加密算法实现机密信息的交换过程为：甲方生成一对密钥并将其中一个作为公钥向其他方公开；得到该公钥的乙方使用该密钥对机密信息进行加密后发送给甲方；甲方再用自己的另一个专用密钥对加密后的信息进行解密。最有名的非对称加密算法当属 RSA 了，本文将对 RSA 算法的加/解密过程进行详细剖析。非对称加密拥有两把密钥。

接下来如果用户希望访问某些资源，前端要向后端发起一个 HTTP 的请求，同时相应的 Cookie 也会跟随请求一起发送给服务器，而服务器取得 Cookie 以后就会去查找是否有 Session ID ，然后通过 Session ID 提取相应的 Session 来确定用户的身份与权限，如果 Session 与 ID 相符，同时用户的信息也能提供相应的权限，服务器就会认为这个用户已经登录了，随后资源信息就会通过 HTTP 响应给前端。当然也可以使用其他加密方式对用户信息进行加密作为无状态token来使用，

在实际开发中需要调用第三方接口数据，或者是调用另外一个服务接口时，我们可以使用spring框架提供的类可用于在应用中调用 rest 服务，它简化了与http服务的通信方式，统一了restful的标准，封装了http链接， 我们只需要传入 url 及返回值类型即可。

1、分布式锁控制分布式系统之间 同步访问共享资源 的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。实现分布式锁的几种方案基于数据库实现:基于数据库的悲观锁 for update（行锁）实现（写入的并发的太大）基于zookeeper实现:基于zookeeper的文件系统及通知机制基于redis的实现（推荐）:基

1、springcloud feign传输List的坑2、SpringCloud通过Feign传递List类型参数3、Feign的传参研究4、SpringCloud使用feign时的复杂参数传递5、Feign消费服务时POST/GET请求方式6、Spring Boot 和 Spring Cloud Feign调用服务及传递参数踩坑记录...

3.OpenFeign3.1.基本使用步骤：​ Feign中已经自动集成了Ribbon负载均衡，因此我们不需要自己定义RestTemplate了引入依赖<!--fegin--><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId>

2.Eureka2.1.Eureka的基本使用搭建eureka服务端提供者去注册服务消费者拉取服务2.1.1.搭建eureka服务基本步骤：导入依赖<!-- Eureka服务端 --><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server&

第一步：选中服务 按快捷键:Ctrl+D第二步：修改服务名称，端口号：-Dserver.port=8082第三步：点击ok 启动即可