新坑：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默认行为走，我一概不知。
大概操作也放在这里了。
CMS
是的，严格来说，我有使用CMS系统！
我是用Ghost作为一个CMS系统。以Weather service为例，这个service的使用说明页面其实是直接跳Ghost。虽然是打开新标签页，但其实Iframe嵌进去其实也不是啥大事。
当然，Ghost更多还是做博客。如果要稍微靠谱一点但又简单的CMS，不是strapi，而是Wordpress……把静态页面放这玩意上面其实又快又好……
第一步总结
总之，一句话，就是忠实的执行了宏观战略。采用了非常开放的、非常灵活的、非常弹性的、非常决绝的，也同时意味着非常激进的技术选型和设计。
下一步
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是必须的）
这个我只能说到这个程度，只能这么隐晦。
此坑大，慢慢填……