关于 FeignClient 参数 fallbackFactory 和 fallback
首先两个参数都可以作为断容器使用,在抛出 exception 时,返回默认的配置数据 其次两个参数不能同时使用 区别:fallbackFactory 可以识别到 cause,也就是说如果需要得到错误原因,可以使用 fallbackFactory,如下 fallbackFactory 的使用FeignClient 123456// remote接口标注fallbackFactory/** * @author 小五 */@FeignClient(contextId = "productFeign", value = ServiceNameConstants.PRODUCT_SERVICE, fallbackFactory = ProductFeignFallbackFactory.class) FeignClient 实现类 12345678910111213@Slf4j@Componentpublic class ProductFeignFallbackImpl implements ProductFeign { @Sette...
OpenFeign 远程调用
Feign 远程调用先来看我们以前利用 RestTemplate 发起远程调用的代码: 存在下面的问题: 代码可读性差,编程体验不统一 参数复杂 URL 难以维护 Feign 是一个声明式的 http 客户端,官方地址:https://github.com/OpenFeign/feign 其作用就是帮助我们优雅的实现 http 请求的发送,解决上面提到的问题。 Feign 替代 RestTemplateFeign 的使用步骤如下: 1)引入依赖我们在 order-service 服务的 pom 文件中引入 feign 的依赖: 1234<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId></dependency> 2)添加注解在 order-service 的启动类添加注解开启 Feign 的功能: 3)编写...
关于 Spring Cloud
单体, 微服务, 分布式 1.1 单体架构单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。 单体架构的优缺点如下: 优点: 架构简单 部署成本低 缺点: 耦合度高(维护困难、升级困难) 1.2 分布式架构分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务。 分布式架构的优缺点: 优点: 降低服务耦合 有利于服务升级和拓展 缺点: 服务调用关系错综复杂 分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考: 服务拆分的粒度如何界定? 服务之间如何调用? 服务的调用关系如何管理? 人们需要制定一套行之有效的标准来约束分布式架构。 1.3 微服务微服务的架构特征: 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责 自治:团队独立、技术独立、数据独立,独立部署和交付 面向服务:服务提供统一标准的接口,与语言和技术无关 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题 微服务的上述特性其实是在给分布式架构制定一个标准,进一步降低服务之间的耦合度,提供服务的...
学习 Nacos - 注册中心与配置中心
Nacos 是 Spring Cloud Alibaba 的组件,而 Spring Cloud Alibaba 也遵循 Spring Cloud 中定义的服务注册、服务发现规范。因此使用 Nacos 和使用 Eureka 对于微服务来说,并没有太大区别。 主要差异在于: 依赖不同 服务地址不同 注册中心依赖配置pom 依赖: 1234567<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> 1234<dependency> <groupId>...
SQL Server 常用操作记录
常用函数记录DateAdd在日期中添加或减去指定的时间间隔: 1DATEADD(day/month.., number, date) getdate()获取系统当前时间。 STUFF 结合 FOR XML PATH 拼接字符串如果不是 varchar 类型,先转换:CAST(xx AS VARCHAR)。 12345678SELECT id, [text] = '[' + STUFF((SELECT ',{"bizDate":"' + CAST(business_date AS VARCHAR) + '","pkgCode":"' + [package_code] + '","guestType":"' + [guest_type] + '","count":' + CAST(COUNT AS VARCHAR) +...
aliyun OSS 分布式存储
结合之前学习一个开源项目的时候,重新写一下关于 OSS 的文章(修改 API 使用及开通流程部分) 使用 OSS 作为文件存储 关于 OSS 作为文件存储的一个叙述 文件上传在系统中用的很频繁,所以我们需要将上传的文件进行存储,传统的将文件上传到本机已不适用分布式系统。自己搭建文件服务器有复杂性和维护成本。所以我们可以采用市面上成熟的文件存储服务,如阿里云的 OSS 对象存储服务。 每个 OSS 的用户都会用到上传服务。Web 端常见的上传方法是用户在浏览器或 APP 端上传文件到应用服务器,应用服务器再把文件上传到 OSS。具体流程如下图所示。 和数据直传到 OSS 相比,以上方法有三个缺点: 上传慢:用户数据需先上传到应用服务器,之后再上传到 OSS。网络传输时间比直传到 OSS 多一倍。如果用户数据不通过应用服务器中转,而是直传到 OSS,速度将大有提升。而且 OSS 采用 BGP 带宽,能保证各地各运营商之间的传输速度。 扩展性差:如果后续用户多了,应用服务器会成为瓶颈。 费用高:需要准备多台应用服务器。由于 OSS 上传流量是免费的,如果数据直传到 OSS...
记录支付宝支付开发过程
支付宝相关概念网站支付 DEMO 传送门:手机网站支付 DEMO | 网页&移动应用 RSA、加密加签、密钥 对称加密对称加密:发送方和接收方用的是同一把密钥,存在问题:当某一方将密钥泄漏之后,发送的消息可以被截取获悉并且随意进行通信。 非对称加密非对称加密:发送方和接收方使用的不是同一把密钥,发送方使用密钥 A 对明文进行加密,接收方使用密钥 B 对密文进行解密,然后接收方将回复的明文用密钥 C 进行加密,发送方使用密钥 D 进行解密。采用非对称加密的好处是:即使有密钥被泄漏也不能自由的通信。 公钥与私钥 公钥和私钥是一个相对概念 密钥的公私性是相对于生成者而言的。发送方通过密钥 A 对明文进行加密,密钥 A 是只有发送方自己知道的,接收方想要解密密文,就需要拿到发送方公布出来的密钥 B。 一对密钥生成后,保存在生产者手里的就是私钥(自己持有,不公开) 生成者发布出去让大家用的就是公钥 此时: 密钥 A 和密钥 C 就是私钥,私钥用于加密,确保发送的消息不会被他人篡改 密钥 B 和密钥 D 就是公钥,公钥用于解密,可以暴露出去。 加密和数字签名 签...
Spring REST Docs 结合单元测试的使用
简介通过将手写文档与 Spring MVC Test 生成的自动生成的片段结合起来,记录 RESTful 服务。 详细说就是,通过编写单元测试利用 asciidoctor 生成 adoc 文档,然后将这些 adoc 片段输出 HTML。 代码示例pom.xml1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162<spring-restdocs.version>2.0.4.RELEASE</spring-restdocs.version><!-- restdoc --><dependency> <groupId>org.springframework.restdocs</groupId> <artifactId>spring-restdocs-mockmvc</artifactId> <scope>t...
SpringDoc 整合
前言SpringDoc 是一个用来自动生成 API 文档的库。它是基于 SpringBoot 项目的,遵循 OpenAPI3(一个组织规定的规范)规范。它是通过检查我们运行中的程序,推断出基于 Spring 配置、类结构和各种注解的 API 语义,从而自动生成 JSON、YAML 和 HTML 格式的接口文档。 而我们不得不提的就是 Swagger。Swagger 是一个公司的开源项目,将自己的 API 设计贡献给了 OpenAPI 并由其标准化。在 SpringDoc 之前我们还可以使用 Springfox,和 SpringDoc 一样是一个用于生成 API 文档的库,2020 年起不再更新。 官方文档链接:https://springdoc.org/#Introduction 使用插件使用【用于生成 openapi.json】:https://springdoc.org/#plugins 官方 demo 文档:https://github.com/springdoc/springdoc-openapi-demos 访问主页:http://localhost:8080/swag...
单元测试介绍及使用
前言开发人员写的常常是"单元测试",但其实可以细分成单元测试和集成测试两个。 划分的原因拿常见的 Spring IoC 举例。Spring 不同 Bean 之间相互依赖,例如某 API 业务逻辑中会依赖不同模块的 Service,Service 方法中又可能依赖不同的 Dao 层方法,甚至还会通过 RPC、HTTP 调用外部服务方法。这给我们写测试用例带来了难度,本来只想测试某个方法的功能,却要考虑一连串的依赖关系。 单元测试 单元测试:是指对软件中的最小可测试单元进行检查和验证。 通常任何软件都会划分为不同的模块和组件。单独测试一个组件时,我们叫做单元测试。单元测试用于验证相关的一小段代码是否正常工作。单元测试不是用于发现应用程序范围内的 bug,或者回归测试的 bug,而是分别检测每个代码片段。 单元测试不验证应用程序代码是否和外部依赖正常工作。它聚焦与单个组件并且 Mock 所有和它交互的依赖。例如,方法中调用发短信的服务,以及和数据库的交互,我们只需要 Mock 假执行即可,毕竟测试的焦点在当前方法上。 单元测试的特点: 不依赖任何模块。 基于代码...
