Say Hello To Dubbo 3.0
现在感觉Spring Cloud的整个体系太重了,尝试看看Spring Boot + Dubbo 3.0
官方示例: Spring Boot 开发服务
内置对容器化部署的支持: Docker部署Dubbo跨主机IP访问解决方案
Dubbo超时设置的优先顺序,调用方的接口方法 > 调用方全局设置 > 提供方全局设置 > 提供方接口方法
dubbo-admin: 待探索
现在感觉Spring Cloud的整个体系太重了,尝试看看Spring Boot + Dubbo 3.0
官方示例: Spring Boot 开发服务
内置对容器化部署的支持: Docker部署Dubbo跨主机IP访问解决方案
Dubbo超时设置的优先顺序,调用方的接口方法 > 调用方全局设置 > 提供方全局设置 > 提供方接口方法
dubbo-admin: 待探索
官方文档JobRunr Doc
在Spring Boot上的安装非常简单,有Spring Boot Starter
Spring boot 2的Maven依赖包:
1 | <dependency> |
JobRunr从6.0开始支持Spring Boot 3:
1 | <dependency> |
配置application.yml,主要是开启/关闭 JobRunr 的Server和Dashboard,Server用来执行job,Dashboard则是在一个独立的端口提供网页看板:
1 | org: |
1 | @Autowired |
1 |
|
Dashboard是一个网页看板,在这里可以查看任务的执行情况,也可以手动触发任务、删除任务。
个人觉得选用JobRunr,一方面是与Spring Boot集成比较方便,这样在开发和运维上比较节省人力和服务器资源,当然这可能是个双刃剑,对那些不差钱也不差人的场景来说,这是“缺点”;另一方面是Dashboard的可视化,会增加我们的掌控感。
JobRunr建议在写Job的执行代码时,把异常抛出来,这样JobRunr就会把这个Job的状态设置为Failed,然后在Dashboard上可以看到这个Job的执行情况,如下图所示:
如果某个Job每次执行都抛异常,就会进入Scheduled状态,以更低的频率执行。
有些任务,比如每天甚至每周才执行一次,如果想手工触发,可以在Dashboard上的RecurringJobs下,勾选Job,然后点击“Trigger”按钮触发,如下图所示:
任务的删除,主要是这种场景:代码做了修改之后,使用@Recurring和@Job注解申明的任务,名称变了或者不需要了,也就是代码里其实已经没有这个名称的Job了。这时候可以在Dashboard上的RecurringJobs下,勾选Job,然后点击“Delete”按钮删除。
PaaS - Platform as a Service,平台即服务
Baas - Backend as a Service,后端即服务
Serverless - 无服务
都是试图简化后端的复杂性和运维压力
Firebase是谷歌的一项服务,主要针对App开发,提供了通用的一些服务端功能,基本上一个App前端可以不依赖后端就可以开发一款应用。
Supabase是对标Firebase的开源实现。
Supabase目前来看,只适合负载比较小的应用,也就是一个Docker部署可以支撑的情况。这可能只是笔者的误解,看官方的文档时可以部署在Kubernates上,k8s是可以缩放的。但是k8s本身很复杂很重,基本上对个人开发者或者中小企业来说,只能是用云提供商的服务,这就没什么成本优势了。再说Supabase是基于PostgreSQL来提供一些核心能力,就笔者自己的经验来说,数据库用云服务商提供的最省事也最便宜,不然你需要购买CPU、内存和存储,也需要专业的人员来运维,后患很大。
参考:
Supabase
APISIX和KONG都是基于OpenResty开发的API网关,从目前看到的资料来看,APISIX的性能要好一些。
OpenResty在nginx上增加动态脚本能力(Lua),主要是解决了nginx修改配置后必须reload的问题。这个耗时以秒计,而OpenResty是动态脚本,耗时就是一次admin api 请求,几毫秒。看官方的文档,一直在强调“同步非阻塞”,既可以充分利用nginx的非阻塞I/O模型,又能享受同步编程的简便性,也就是代码看上去就是同步执行代码,很好理解和开发,但其实执行是非阻塞的效率很高。同步非阻塞的开发体验应该是优于node.js的,只是javascript更流行。事实上nginx也被OpenResty启发,尝试在nginx上增加javascript来实现OpenResty类似的能力,但也没火起来。
参考:OpenResty的现状、趋势、使用及学习方法
参考:从openresty谈到rust
我按APISIX官方的文档用docker-compose的方式进行了简单尝试,发现APISIX还是非常重的,如果在API管理上没有很强的需求,没有必要使用APISIX。个人的体会,需要借助OpenResty的动态配置能力来实现业务的场景,才需要使用OpenResty或者更强(更复杂)的APISIX和KONG。
TODO: OpenResty值得研究一下
用随机函数的值来排序,以达到随机查询的目的;最好限制一个取数范围,不然对行数比较多的表来说,随机取数查询可能耗时会比较长。
select * fro some_table order by random() limit 100; |
冒号在JPA中是特殊符号,所以需要加转义字符
select * from some_table where details::varchar like 'ABC%'; |
Java中添加转义字符:
String strSql = "select * from some_table where details\\:\\:varchar like 'ABC%'"; |
1 | # 查询 |
PostgreSQL支持全文检索,但是中文的全文检索需要安装zhparser插件。阿里云上购买的PostgreSQL,某些版本不支持,升级到14最新的小版本,或者15才支持。
表的大小如果超过了物理内存就应该分区了,分区有两种方式:
新建表可以在建表的时候指定分区字段
1 | CREATE TABLE measurement ( |
对现有表使用继承和创建触发器的方式
1 | CREATE TABLE measurement ( |
决定要搭一个自己的博客,是受了《程序员的思维训练:开发认知潜能的九堂课》的启发,External support is part of your mind(大脑之外的思维工具,也会成为你思维头脑的一部分)。