新坑:LifeAuto,我的生活自动化工具

为了更新技术,将这两年的技术提升进行整合。同时,财政系统也给了下一波开发的财政预算。另外,我本身也有一些想要进一步简化我的生活负担。
于是,几个方面这么一凑合,就挖了一个新坑。至于我自己有没有动力做,其实已经不是重点。

访问地址:https://auto.xloypaypa.pub/。(没怎么搞responsive,手机党且用且珍惜)


主要目标

我中文英文都不太好,想象力也不足,脑子也不好使,所以起名字就比较土。目标就是在名字里,通过一系列或大或小的服务,进一步简化自己的生活。

另外,虽然我的需求往往并不是很普遍(比如目前上的第一个天气通知),但是所有的的服务都要全部对外开放(或者出于法律法规的原因,绝大多数)。


宏观战略

极端激进~

技术选型

从整体架构到具体代码实现,都会采用相对激进的设计和实现。当然,这种激进,主要是对比我默认的状态相比。

举个例子:微服务

当然微服务本身对来说并不属于激进。但是,激进的是:所谓的微服务之间完全独立,这个独立会一直往上走到财政层面。
也就是说,对于服务A来说,与其说服务B是另外一个团队,不说说服务B由另一个公司提供。

服务A访问服务B,也不会通过内网访问,而是直接通过公网访问(不论A和B是否在同一个集群当中)。
同时,禁止A和B的功能互相覆盖,也就是说,如果A要用B的东西,不准自己写,必须调B。
显然服务B不会因为服务A需要而做任何改变。

好处:每个服务极端的独立,非常的干净。
坏处:1. 上面的好处是假的;2. 听着就非常的蠢……

整合财政系统自动化项目

虽然,我相信没有人愿意把自己的财务信息公开给一个没啥交集的第三人。但是,整合进来再说。

有限的质量

除了不坑后期维护,sonar能过,主流程没啥大问题之外。其余什么:有效的提示信息、合理的异常返回、用户体验等等都是第二优先级。

举个例子:查询发现找不到资源。

为了不坑后期维护,对应的后端service会抛一个XXXXNotFoundException。并且为了sonar能通过,有单元测试cover这种情况。当然也会保证找到的时候能正常的返回数据。什么覆盖所有service的trace id什么的自然也不会少。

但是我甚至懒得写advisor去处理作为父类的GeneralNotFoundException,以至于找不到的时候最后前端可能能拿到一个500。然后,前端可能就弹个pop,冒一句:“Ops! we got some error.”

当然,毕竟,主要是自己写自己用,所以心情好的话,不会写的那么变态。如果我自己被糟糕的体验坑的太难受,也可能会主动填坑。

允许争议内容

“简化生活负担”这句话当然可以解读为:把生活中的麻烦事交给自动的系统。也可以解释为,将我能抽象出来的东西从我的脑子里彻底拿出来。
但公私之所以有别,就是因为很多私有的东西其实是有争议的。但是这个系统还是会允许这些内容。
例子就不举了。肯定会有权限管理,不该看到的也看不到。


第一步

目前已经实现了第一步:让天气服务可用。主要是按照上面的思路把架子搭了起来。基本也就能看出点雏形了。

后端架构

一句话,全部走公网。服务A访问服务B就像是访问别的公司的API一样。当然访问DB还是老老实实走内网。

也是占着了这类小工具合集的需求没有什么很长的流程,所以直接铺一层就够了。至于如果遇到有长流程的、有复杂状态的怎么办?我不知道。

前端架构

为了所有服务都能在一个统一的网页上访问到,而且能比较顺利的切来切去。同时,又要批判的(我是指,不同的service之间假装是仇人)看待其他的服务。所以自然的,搞了某种类似于“微前端”的骚东西……

简单来说就是拆成了:home ui、weather ui、user ui。
其中除了Home ui会额外提供:1. 选择的语言(通过cookie);2. 一个完全符合剩余窗口大小的iframe;之外。其他的都是自己干自己的活,然后被用iframe引入进来。

毕竟单个服务的复杂度非常有限,作为工具类的网页,本身也不需要太高的性能。

Infra相关

Infra没啥架构,每个服务都是“天子守国门了”就是一个container部署上去就算完事。

不过因为所有的服务都直接在最外层,所以跨集群访问的代价会非常低。所以这些服务可以部署在任何地方。

Keycloak

是的,虽然我知道keycloak非常的坑。但是我还是用了Keycloak。
其实就是图他把Azure AD、Google、Github登录一次性帮我实现了,顺便把各个登录渠道的用户用Keycloak内部的一个ID标注出来,再给个role。其余深度功能一概不用。

至于,email冲突了怎么处理,keycloak多语言怎么做之类的,别问,问就是都按Keycloak默认行为走,我一概不知。

大概操作也放在这里了。

Keycloak 20.0.3 使用体验
最近有一些需求,评估之后想来想去,还是Keycloak比较合适。所以虽然个人很不喜欢,但还是使用了Keycloak。本文主要分两块。第一块是关于Keycloak的评价性的描述,第二块才是一些功能的体验。

CMS

是的,严格来说,我有使用CMS系统!

我是用Ghost作为一个CMS系统。以Weather service为例,这个service的使用说明页面其实是直接跳Ghost。虽然是打开新标签页,但其实Iframe嵌进去其实也不是啥大事。

当然,Ghost更多还是做博客。如果要稍微靠谱一点但又简单的CMS,不是strapi,而是Wordpress……把静态页面放这玩意上面其实又快又好……

WordPress - Wikipedia

第一步总结

总之,一句话,就是忠实的执行了宏观战略。采用了非常开放的、非常灵活的、非常弹性的、非常决绝的,也同时意味着非常激进的技术选型和设计。


下一步

S3静态文件(已搞定)

虽然我一直都有自己的S3服务器……但是限于我猪脑过载,之前的语言文件是直接跟着各个service的ui一起部署的。

但我觉得未来,翻译文本可以直接扔S3。

Temp File Service(已搞定)

文件上传迟早都要有的……所以这个service一定是要有的……

然而,这个服务因为会消耗大量的流量,所以使用会受到非常多的限制。比如我国内的伪CDN节点是按流量收费的,所以这个服务限制一些地区使用是很自然的。

Ffmpeg Service(已搞定)

显然,在本地机器处理大量的视频我认为是不明智的。视频处理这种吃计算资源的东西,当然是放在远端服务器搞。

自然这个service也会有地区限制。同时这个service会需要大量的计算资源,所以不会公开,会有权限限制。

Image2Text Service

和ffmpeg完全类似。搞个图像文字识别API。

Emergency Internet Rescue Service

我一直在努力想办法提供这个服务。主要当有人突然网络出现某些问题的时候,我能快速、简便的提供一个临时的线路。

目前没啥好思路。可能会试图集成DigitalOcean,AWS等云平台。
当用户翻车时,找用户要access key,帮他自动的创建一台预装好某些特定软件的Server,让他先恢复网络访问再说。
前提是,用户不用访问网站就能记得access key,并且愿意暂时信任本服务。(事后更换access key是必须的)

这个我只能说到这个程度,只能这么隐晦。


此坑大,慢慢填……

蜀ICP备19018968号