SpringCloud alibaba微服务实战三十七 - Oauth2.0 自定义登录接口
大家好,我是飘渺。
有不少人私下问我,为什么SpringCloud alibaba实战系列不更新了,主要是因为大部分核心功能都已经讲完了,剩下的基本是属于业务功能开发了,需要根据实际业务扩展。
今天更新文章的原因是粉丝提了个问题:如何实现Oauth2认证服务器自定义登录接口以及返回自定义格式? 这里我给大家分享一个简单且实用的方法,既可以灵活定制登录参数也可以自行组装返回结果。
大家好,我是飘渺。
有不少人私下问我,为什么SpringCloud alibaba实战系列不更新了,主要是因为大部分核心功能都已经讲完了,剩下的基本是属于业务功能开发了,需要根据实际业务扩展。
今天更新文章的原因是粉丝提了个问题:如何实现Oauth2认证服务器自定义登录接口以及返回自定义格式? 这里我给大家分享一个简单且实用的方法,既可以灵活定制登录参数也可以自行组装返回结果。
大家好,我是飘渺。今天我们来聊一聊 ZGC。
ZGC(Z Garbage Collector) 是一款性能比 G1 更加优秀的垃圾收集器。ZGC 第一次出现是在 JDK 11 中以实验性的特性引入,这也是 JDK 11 中最大的亮点。在 JDK 15 中 ZGC 不再是实验功能,可以正式投入生产使用了,使用 –XX:+UseZGC 可以启用 ZGC。
ZGC 有 3 个重要特性:
JDK 16 发布后,GC 暂停时间已经缩小到 1 ms 以内,并且时间复杂度是 o(1),这也就是说 GC 停顿时间是一个固定值了,并不会受堆内存大小影响。
大家好,我是飘渺。
在SpringBoot 如何进行限流,老鸟们都这么玩的!一文中我们详细介绍了为什么需要对接口进行限流,也介绍了常见的限流算法,最后还基于Guava工具类实现了接口限流。但是这种方式有个问题,无法实现分布式限流。那今天我们来利用Redis + Lua 来实现分布式限流。
Lua 脚本和 MySQL 数据库的存储过程比较相似,他们执行一组命令,所有命令的执行要么全部成功或者失败,以此达到原子性。也可以把 Lua 脚本理解为,一段具有业务逻辑的代码块。
想必大家天天看技术文章应该都看累了吧,今天咱们不谈技术,聊个有意思的话题,即如何为自己构造出一个 职业成长方面动力十足的良性循环系统。
什么意思呢?
我相信各位做技术的 “秃头老码农” 肯定都有过或实践过这样一个想法:即通过在上班之余努力学习各种知识、开发技能和思维能力,一段时间后提高我们的工作能力,进而做出更好的工作成绩。这些工作成绩会为我们带来更多的金钱,如升职加薪、当上CTO、迎娶白富美等。
这些钱会对我们构成正面激励,让我们有更大的学习动力去继续学习更多的知识和能力,然后继续这一良性循环。这里我们用一张系统动力图来描述这个循环过程。
容器编排工具作为当今最重要的Web开发技术之一,众多强者都在尝试争夺这一行业的主导地位。
Podman是RedHat的一款产品,旨在使用类似于Kubernetes的方法来构建、管理和运行容器,作为一款主流容器的可靠替代产品,它吸引了开发人员的关注。自RHEL 8起,Red Hat用CRI-O/Podman取代了Docker Daemon。为什么Red Hat想要摆脱Docker Daemon?这是因为使用Docker Daemon运行Docker有以下这些问题:
很多技术人员在职业上对自己要求高,工作勤奋,承担越来越大的责任,最终得到信任,被提拔到管理岗位。但是往往缺乏专业的管理知识,在工作中不能从整体范围优化工作流程,仍然是“个人贡献者”的工作方式,遇到问题自己上,经常耽误了本职工作。
于是翻了很多书,看了很多文章,学习了很多“为人处世的艺术”和“企业发展的战略”,最终把自己干成了研发部主管,技术却逐渐荒废。管理工作是什么呢,技术和管理是截然不同的两条发展方向吗?
不是的。技术和管理都要做到量化分析,全局优化,存在很多相似的方法。 这里用一个系统性能优化的场景举个例子,大家可以体会一下:
公司里有一个程序,运行在10台服务器的集群上。现在业务量增加了,请求处理不完。老板把你找来,要你优化这个程序。接到这个头疼的任务,你把开发测试运维各个部门的人都找来开会想办法,有人说数据库该升级了,有人说代码写的太烂要优化,有人说机器太少再加5台,还有人说我们要改架构上云,上了云以后就再也没有这种问题了。你该听谁的呢?
与其花时间在 Git 协同工作流上,还不如把时间花在调整软件架构和自动化软件生产和运维流程上来,这才是真正简化协同工作流程的根本
来源:https://time.geekbang.org/column/article/2440
与传统的代码版本管理工具相比,Git 有很多的优势,因而越来越成为程序员喜欢的版本管理工具。我觉得,Git 这个代码版本管理工具最大的优势有以下几个。
对于一些用户请求,在某些情况下是可能重复发送的,如果是查询类操作并无大碍,但其中有些是涉及写入操作的,一旦重复了,可能会导致很严重的后果,例如交易的接口如果重复请求可能会重复下单。
重复的场景有可能是:
本文讨论的是如何在服务端优雅地统一处理这种情况,如何禁止用户重复点击等客户端操作不在本文的讨论范畴。