WebFlux下的全局异常处理
Spring 5支持的WebFlux对于全局异常的捕捉与以前的WebMVC框架有了不同,不能靠@ControllerAdvice或@RestControllerAdvice打天下了。目前国内的资料比较少,而且语焉不详,下面我将处理方式分享出来,文末有我的项目代码供参考。
核心要点是要继承AbstractErrorWebExceptionHandler这个WebFlux下的全局异常处理类,然后重写getRoutingFunction。
需要注意的是AbstractErrorWebExceptionHandler中的构造方法中未对messageWriters进行初始化,源码如下:
private List<HttpMessageWriter<?>> messageWriters = Collections.emptyList();
messageWriters是用于最终生成response body的,所以我们必须在实现类中对它进行初始化:
public GlobalErrorWebExceptionHandler(ErrorAttributes errorA ...
WebFlux下访问H2控制台
在基于WebFlux和Netty的应用框架中,惯常通过http://ip:port/h2-console访问的H2控制台无法打开。这个时候,可以通过显式的去启动H2 Server来解决此问题。参考代码如下:
@Component@Profile("test") // <-- up to youpublic class H2 { private org.h2.tools.Server webServer; private org.h2.tools.Server server; @EventListener(org.springframework.context.event.ContextRefreshedEvent.class) public void start() throws java.sql.SQLException { this.webServer = org.h2.tools.Server.createWebServer("-webPort", "8082&q ...
Push code to 2 repos
GitHub和CodingNet上已经创建好空仓库tools,拟将本机的项目代码同时提交到两个仓库
git initgit add .git commit "init"git remote add github https://github.com/frontc/tools.gitgit remote set-url --add github https://e.coding.net/lefer/tools.gitgit push -f --set-upstream github master
基于layer jars构建docker镜像
经过一番折腾之后,还是觉得老老实实的写Dockerfile更香,Spring Boot 2.3.1对layer jars的支持与2.3.0有所变化,网上的资料大部分都是过时了的,正确步骤如下:
pom里开启layer jars支持
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <layers> <enabled>true</enabled> </layers> </configuration> ...
使用spring-boot-maven-plugin构建docker镜像
Spring Boot 2.3发布后带来了新特性之一就是对构建镜像的便捷支持,声称不用写dockerfile就能方便的构建docker image,最近刚好在写一个项目于是折腾了一下,只能说还不太适合国内用户,最终还是老老实实的写了dockerfile需要挂上代理才能勉强可用,下文记录折腾的过程。
更新 2020年6月19日尝试了诸如gcr.io的国内镜像、docker tag更改image的名字为原版gcr.io/等其他几种办法之后,发现只有挂全局代理才可以走通。
Windows下可以使用Proxifier设置全局代理,Proxifier的使用比较简单,网上说的比较多,如这一篇。
全局代理设置好,一切都OK了,如果走代理下载镜像比较慢,可以先把镜像从国内镜像源里拉到本地。然后再改Tag的名字,这样能跳过下载镜像的环节。
docker pull registry.cn-hangzhou.aliyuncs.com/lefer/paketo-buildpacks:0.3# docker tag imageid tag:versiondocker tag 87c89aeacd48 ...
ToMu设计文档
项目介绍ToMu 是 Together Music 的缩写。ToMu是基于网络开放的音乐资源基础上,让一对听众一起听歌的平台。ToMu的初衷是找回在随身听时代,两个人共用一副耳机一边散步一边听歌的感觉。
GitHub:**ToMu**
项目特性
无需登录,记住你的频率即可
一个频率只能两人在线
用户流程主流程
用户访问网站
用户创建一个频道
用户可以将频道链接或者频道号分享给其他人,其他人使用该频道号即可进入频道
用户在频道内可以添加歌曲
用户在频道内可以播放已经添加的歌曲
同一频道内的两个用户同时听到播放的歌曲
主要用例
界面草图
频道页
核心流程
接口定义访问ToMu API Doc
开发计划v0.1
实现单人创建频道,添加歌曲,播放歌曲
v0.2
实现另外用户进入频道,同步频道状态,同步播放歌曲
v0.3
… …
读《架构整洁之道》
总体评价这本书是我看过的架构领域的书中最好的一本,“神书”,作者比较系统的阐述了自己对架构的理解、对好的架构的理解、以及对如何做出好的架构设计的理解。作者本人在软件领域从业几十年,从他的口中听到的一些架构原则更透彻,能让你看到当时的来龙去脉。
阅读感悟
依赖倒置(DIP)本质上是一种解耦,解耦的目的是实现组件化的独立部署和独立开发能力。PS:顺便说一句,最早提出DIP原则的就是这本书的作者罗伯特老爷子。
所有的竞争问题、死锁问题、并发更新问题都是由可变变量导致的。如果变量永远不会被更改,那就不可能产生竞争或并发更新问题。如果锁状态是不可变的,那就永远不会产生死锁问题。所以架构师要做好可变性的隔离,区分出可变组件和不可变组件,尽可能的将处理逻辑归于不可变组件。
软件构建中层结构的主要目标是:第一、使软件可容忍被改动;第二、使软件更容易被理解;第三、构建可在多个系统中复用的组件。
SRP是康威定律的一个推论,即软件应与组织息息相关,每一个软件模块应该只对某一类行为者负责。单一职责原则放到组件层面就是共同闭包,即我们应该将会同时修改,会以同样目的而被修改的类整合成一个组件。
O ...
读《中台战略-中台建设与数字商业》
总体评价烂书一本,整本书就是云徙科技的广告吧。书的内容组织混乱,欠缺开创性的见解,东拼西凑,不值得一读。
阅读感悟
别人打广告要花钱,它打广告还能挣钱,靠的是什么?靠的是热的概念+敢想+敢写
书籍信息中文书名:中台战略:中台建设与数字商业作者:陈新宇 罗家鹰 邓通 江威
静态网页内嵌播放网易云歌单
为了自己听歌方便,我一直在自己的网站上用aplayer挂着自己喜爱的音乐,但因为涉及音乐资源版权,心里始终有点不踏实,所以想着能不能直接把网易云歌单集成进来。网易云提供了iframe的方式内嵌歌单,但是太丑了,还是得自己写一个。在搜索网易云的API的时候,发现竟然有人已经写好了:MetingJS,用得也是aplayer,给了他一个大大的Star之后,记录下用法。
引入js
<!-- require APlayer --><link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/aplayer/dist/APlayer.min.css"><script src="https://cdn.jsdelivr.net/npm/aplayer/dist/APlayer.min.js"></script><!-- require MetingJS --><script src="https://cdn ...
读《修改软件的艺术》
总体评价整本书有点标题党,是想蹭《修改代码的艺术》的热度吧。整本书实质上是作者在敏捷和TDD实践过程中的一些心得。不少观点也很有启发意义,还是值得一读的。
阅读感悟
许多bug都是只在集成阶段才会出现,所以越早集成就越能发现风险。(敏捷的理由)
软件与建筑的区别是盖房子不会想着将来会怎么再加装一层,而软件必须要面向扩展去构建。
过期的注释比没有注释更加糟糕,这会使得代码成为谎言。
注释应该去描述代码的缘由而非解释代码的行为,代码的行为应该是自解释的。
繁复的流程会让各个环节对立,各个环节的对立会引来不信任,不信任会导致更多的流程。复杂的流程并不能帮助软件项目成功。
软件开发过程本质上是一个创造过程,流程无法支配创造力。
掌握一门编程语言并不能使你成为软件开发者,正如掌握一门自然语言并不能使你成为作家。
80%的软件开销花费在软件初始版本发布之后:软件初始版本(20%),发布后的错误修正(17%),各种优化(60%)以及其他。PS:这个数据作者没有注明来源,但符合我的经验。
“精益”理论认为,所有已经开展但尚未完成以至无法为客户创造价值的开发任务就是软件行业的浪费— ...