2018年爱飞狗第一个版本上线,运营到2019年中关闭。爬虫以及数据一直没有中断,只是不想去做产品维护了而已。2020年底,自己重新将这个产品定位为自己的一个技术实践的产物,作为一个试验田,实验新的想法、新的工具。好在云厂商大量的推出廉价的服务器资源,我购买了2台4核8G内存的云服务器,使得爱飞狗重新起航有了新的基础。
2018年写的小程序用的是微信当年刚出来小程序不久写的,用的是原生的小程序的框架加上有赞的ZanUI(当年的称呼)。那是一套CSS框架,当时也没有小程序组件的机制。多方对比,这在当年也算是一个比较成熟的框架了。
到2020年底,小程序开发也非常的方便了,出现了很多的多端UI框架,包括Taro-UI、腾讯的kbone等。为了跨平台和H5兼容,这些框架基本上都使用和前端开发一样的工具,例如使用typescript、react、mobx等框架,使用npm build等生成小程序相关的代码。从Demo等来看,一切看起来都很美好。
Taro-UI看起来算是成熟度比较高的框架,所以尝试将代码进行迁移。在2020年底,Taro-UI有新出不久的3.0版本,老版本也已经进入了维护状态。但尝试了一番以后发现了以下一些问题:
在折腾了一段时间以后,慢慢的挫折感(莫非是自己太笨。。),还是放弃了Taro-UI。还原使用腾讯原生的小程序框架,重新整理了一下代码,删除了大量无用的代码。CSS框架重新使用了有赞的Vant Weapp UI组件库替换之前的CSS框架。替换过程较为顺利,节约了大量的时间。
总结起来,对于前端来讲,精力有限、业务不复杂的情况下,还是选择用腾讯自己原生的一套方案来得快,兼容性最好。
在k8s还不是那么容易安装的前几年,爱飞狗的后端以及爬虫都是使用rancher来运行容器的。后来有了k3s后,发现在低配置的服务器上(1核2G)的机器上,也能顺畅的使用k8s。k3s在长期的运维中也比较稳定,偶尔会出现集群崩溃的情况,只需要重启一下就好了。
为了学一下新的东西,我将k3s切换成了microk8s。然后安装microk8s就遇到了满满的坑:
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = [ "https://3laho3y3.mirror.aliyuncs.com", "http://f1361db2.m.daocloud.io", "https://mirror.ccs.tencentyun.com", "https://hub-mirror.c.163.com", "https://docker.mirrors.ustc.edu.cn", "https://registry-1.docker.io" ]
除了这几个坑意外,microk8s还算是稳定,对资源占用也和k3s差不多。更好的是microk8s提供了更为标准化的组件和插件,更容易进行后期的维护。在迁移过程中,k3s默认是用的traefik而microk8s用的是nginx,所以需要一些简单的修改。
之前爬虫的服务器一直放在国外,主要是考虑到价格相对比较便宜,2核4G的机器一个月150多元,能够承受。但是这个服务器的性能就比较低下,爬虫会占用所有的CPU资源,导致k8s的集群不是很稳定。
双十一大促的时候,华为云推出了4核8G 3年的服务器,5M的带宽加上200G的硬盘,总价3080,算了下真的是白菜价了。华为云的服务器的速度非常的理想,网络速度也很赞。一般来讲,出口5M是定死的,入带宽一般是100M以上,所以作为爬虫或者APP服务器已经非常的够用。但是华为云的镜像服务有一些同步的问题,每次push到镜像服务器中的镜像,第一次拉回的时候总会出现错误,要等一些时间后才能够拉到正确的镜像。
后来又购买了腾讯的4核8G 3年的服务器,5M带宽,50G硬盘,总价3000,也算是白菜价。但是腾讯云的服务器不是很理想,CPU速度那些没有什么问题,主要的问题在于带宽。腾讯的5M的出带宽,提供的对等的入带宽是10M。这就造成了拉docker image等非常的缓慢,和华为云、阿里云等的如带宽相比,腾讯就太抠了。后来一个解决方案是将私有的镜像直接放到腾讯云的镜像服务器中,还好现阶段没有收费,速度也够快了。最后的痛点是经常性的丢包,华为云和腾讯云的服务器都在广州,然而腾讯云的服务器经常丢包得根本无法登陆上去。不知道腾讯云的网络是怎么搞的,反正用起来很不爽快。
以前为了学习Python,所以数据分析、后端代码都是使用的Python技术栈。其中后端使用的是Flask写的,也没有太大的问题。 最近一次重构就重写了业务逻辑,使用了Spring Boot、Kotlin、Spring Boot Security来做。ETL代码之前是用Java8写的,统一也迁移到了Kotlin。
这是以前设计的架构,主要麻烦的地方在于由于当时的服务器性能所限,没有将ETL的过程放到线上进行,所以必须要将数据同步到本地的PC然后进行离线计算,完成后再同步到线上的数据库。这就造成了需要家里面的电脑长时间运行,在春节等期间维护非常的麻烦。
image.png
当服务器性能和存储不是一个问题以后,架构也随之改变为在线数据同步、在线ETL,就不用在本地PC做任何操作了。
image.png
PS:Tips,这个图片使用draw.io的vscode插件,容易修改也容易存储,很赞)