爱飞狗技术架构升级

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

image.png

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