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版本,老版本也已经进入了维护状态。但尝试了一番以后发现了以下一些问题:

  • build较为缓慢,微信小程序无法根据build后的生成的小程序源代码重新刷新界面,只能自己手动刷新,显得很笨拙。其实这种问题在其他以npm build为构建工具的地方也存在。
  • 对react相关工具的template支持不好,配置上比较麻烦。比如用了react+redux以后想换成mobx就比较麻烦。
  • 对于非Taro-UI之外的原生微信插件支持的不是很好,比如需要用到的Echarts,在Taro-UI上调试一直无法正常工作,只能在真机上实验。但是Echarts原生组件工作良好。
  • npm install的第三方库不总是能够用,原生程序里面用的好好的东西,到这里就会遇到一些奇怪的问题,而且不是太好解决。
  • 文档和相应的版本不对应,有些解决方案针对的是老的版本,在新的版本上不工作

在折腾了一段时间以后,慢慢的挫折感(莫非是自己太笨。。),还是放弃了Taro-UI。还原使用腾讯原生的小程序框架,重新整理了一下代码,删除了大量无用的代码。CSS框架重新使用了有赞的Vant Weapp UI组件库替换之前的CSS框架。替换过程较为顺利,节约了大量的时间。

总结起来,对于前端来讲,精力有限、业务不复杂的情况下,还是选择用腾讯自己原生的一套方案来得快,兼容性最好。

k8s服务器迁移

在k8s还不是那么容易安装的前几年,爱飞狗的后端以及爬虫都是使用rancher来运行容器的。后来有了k3s后,发现在低配置的服务器上(1核2G)的机器上,也能顺畅的使用k8s。k3s在长期的运维中也比较稳定,偶尔会出现集群崩溃的情况,只需要重启一下就好了。

为了学一下新的东西,我将k3s切换成了microk8s。然后安装microk8s就遇到了满满的坑:

  • 国内服务器上安装的话,由于它会安装google上面的镜像,但是国内服务器永远拉不下来。解决方案有。
    • 手动的将镜像从其他地方下载并且推送到私有repo,但这种方案比较麻烦。
    • 使用代理服务器。这里需要一个能够访问国外的代理服务器,然后将代理服务器配置到container-env文件中的http_proxy中即可。当k8s启动后,就可以将代理取消了
    • 新版本的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" ]
  • 由于爬虫占用磁盘空间很快,所以需要不停的将文件移走,一旦这个过程没有做好,k8s服务器检测到磁盘空间低以后会开始清理image来尝试释放空间。这时候之前通过代理下载好的image就会被清除,当重新创建pod的时候,这时候会由于找不到sandbox的image并且无法下载到镜像(除非开了代理)而导致整个集群的pod停掉。
  • 开了代理以后,no_proxy似乎一直没有生效,国内的镜像也走了代理,很慢。

除了这几个坑意外,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然后进行离线计算,完成后再同步到线上的数据库。这就造成了需要家里面的电脑长时间运行,在春节等期间维护非常的麻烦。

当服务器性能和存储不是一个问题以后,架构也随之改变为在线数据同步、在线ETL,就不用在本地PC做任何操作了。

PS:Tips,这个图片使用draw.io的vscode插件,容易修改也容易存储,很赞)