我的技术回顾因ABP框架触发DevOps云原生之路-2020年

我居然把这个系列坚持下来了,感觉真的是超级棒!感谢小伙伴的支持!以及督促。

2020年,我开始往非.NET技术方向发展,也就是DevOps和容器化解决方案发展。当然最后落地了之后,发现这就是各大厂商所开始推广的云原生解决方案。

ABPVnext源代码引发的思考

20年因为疫情的缘故,大家都没有办法出门,所以得空好好看看ABPVnext的源码,把握技术的发展趋势。在看ABP框架的微服务整套解决方案的时候,我发现了一个非常好玩的点,土牛为了严格遵循ABP模块化的规范,将所有的业务模块以及通用模块化拆分的特别细致。这样就带来了一个问题。

以业务模块为例它有差不多17个模块,而每个模块下按照类库划分,又会产生8-9个类库。

账户体系下的类库划分有9个类库,而这些还不包含Angular的前端。

我们做一个简单的计算就可以知道光业务模块的后端代码他就有136个类库,这个还仅仅是业务模块,还没有包含它的所有abpvnext的源代码,而且还没有前端的解决方案。

  • 这些类库还要发布到nuget.org作为公共的工具包,给广大开发者进行使用。
  • 前端的angular方案它也被拆成了一个个独立的npm包。
  • 如果是手动管理和发布这些nuget和npm包,那就是异常灾难。
  • 电脑的配置以及内存也要足够强。

abpframework采用了github的开源仓库以及周边强大的CI工具可以白嫖这些厂商的服务。但是它还有一个商业版本的代码是不开源的,而这些商业版本的CI也是需要服务的。所以土牛的团队里面肯定是有一套完整的DevOps解决方案的,而在容器化的解决方案上一定是Docker,大可能会直接采用k8s进行管理。

当然以上虽然是猜测,后面也确实基本上证实了,abp团队是这样的方案。那么我就在想我没有土牛团队的资金以及人手,我怎么打造一套方案呢。

再次拿52abp官网练手

我手里最现成的可以练手,而且还是足够真实,属于自主可控的就是52abp的官网了。那么不用它作为练手就太可惜了。

首先把他改造成完整的Docker部署,这个不难,但是又产生了一个问题,那就是镜像版本的控制。

Docker是要容器仓库的,自己中途搭建了habor的仓库,可惜因为没钱没服务器难产。

  • 作为微软MVP迁移到了微软Azure所提供的仓库,但是尴尬的就是因为是global的仓库,导致网速跟不上。
  • 白嫖的阿里云个人仓库真香,当然我的视频在线播放用的是阿里云VOD,也算是他的小客户了。

然后把配合Nginx加上docker swarm把52abp做成了双节点,后来发现是没有必要的,毕竟一个日均流量2k的网站要什么集群。然后切换为了Docker-compose 来管理。

我非常建议大家都学习下Docker进行部署和管理的解决方案,有兴趣的可以前往yoyomooc进行学习,你会发现你在运维这方面会给你省太多事情了。然后就要折腾CI CD工具了。

聊聊DevOps的折腾经验

DevOps这个话题非常的大,里面要包含的内容太多了。我们简单说下几个关键点:

在20年的时候我其实发布过一篇文章《小微技术团队的DevOps体系折腾之路》链接地址:https://mp.weixin.qq.com/s/MOiRNY8a6m0YROj5NzTwMQ

DevOps要实现的几大要素:

  • 代码管理
  • 需求管理
  • 持续集成(CI)
  • 持续部署(CD)

如果您是考虑公有云的解决方案,那么就很简单了,阿里云、腾讯云、华为云、微软Azure 里面有一堆现有的解决方案,你只需要把代码托管过去,然后配置下就可以了。

毕竟I'm Rich 这个技能永不过时

而作为一名程序员尤其是想打造一套可控的解决方案的时候,就需要把代码管理、需求管理、持续集成、持续部署这些都变成自己的技能,这样才能让自己的项目和技术栈更加稳定。

代码托管工具

市场上的代码托管工具有很多:Gogs、Gitea 、Gitee、GitHub、Gitlab、Azure DevOps,这些用于管理代码,足够了。你如果还是开源项目的话,可以使用github的所有免费服务。

但是如果是私有化方案,以上都行,但是你会涉及到一个问题那就是CI CD的工具选择。

CI CD工具的选择

大部分开发者会选择使用Jenkins作为自己的第一个CI 工具,毕竟Jenkins是最常用的CI CD工具,而且老牌、资料和文档也足够多。我在17年的时候也选择了它作为CI CD工具,当时觉得没什么问题,毕竟虽然部署有点小麻烦,毕竟部署好了的服务,谁会没事去改它的环境呢。

在2019年我和陈计节在 DNT精英论坛上,作为讲师分享的时候,我们探讨Jenkins作为CI的时候,讨论过它在容器化解决方案的问题。

Jenkins虽然来市场上最早,但是因为无法做到快速的云原生部署,所以迟早会没落。我也在接触了Jenkins之后,发现他在Docker下的解决方案,确实不美好。虽然后面 Blue Ocean提供的pipeline的出现和发展让这一情况有了很大改观,但是我个人依然不推荐。

Drone 也一直是作为和Jenkins进行碰瓷的选手所存在的,后面推出了商业版本,我在研究了之后,发现确实是一个很好的选择。

在最开始的Git代码管理的时候,我看过Gogs、Gitea、gitlab等很多平台,最开始想选择Gitea的,但是在19年经历过了免费的才是的最贵的经验之后。这次选择让我不得不慎重。

在翻阅gitlab的时候,发现他的CE版本,以及它的runner CI工具,集成度非常的高。而且最大的优势在于它的很多扩展都是内置的,对于的社区也是很庞大的。而且gitlab的名气让我至少不用担心,他不会更新这种问题吧。

在确定了采用gitlab+gitlab runner 这个技术方案后。我就开始了狂奔之旅。

单独用gitlab + gitlab runner 都不难,配合docker也不难。难的是你要把所有的场景和流程都适配进去,这个时候就开始变难了。

不过好歹都解决了,不得不说 gitlab runner 可以在Docker下快速进行部署和发布的时候一切问题都迎刃而解了。

聊聊云原生的容器化

关于云原生的介绍网上有很多,我就不再阐释了。在说云原生容器化的时候,我们都会说它是最佳的载体,因为容器具备快速伸缩扩展以及销毁。

我在练习Devops流程的时候,每天要销毁和创建十几次vm虚拟机。容器的创建和销毁就更多了,这个时候就发现容器化的魅力太强了。而如果没有云基础设施的话,我要手动去维护和管理这些虚拟机,实在是太烦了。

尤其是在利用cloud-init配合vm机器创建的时候,一键给你部署好Docker环境,甚至你做的好点,配合脚本可以快速搭建和部署属于你自己的一套环境。而这些时间可以从2-3天的环境搭建到部署安装依赖环境,缩短到1-2个小时。

哦。到了这里,你可能问我为什么没有使用kubernetes。那是因为就52abp的情况来说,没有必要上Kubernetes,而且上了K8S,我的运维成本又会上去了。所以选择适合自己的场景永远是最好的。

尾声

21年的回顾就不用写了,因为之前已经写过差点翻车的总结吧。同时21年我的纯技术没什么提升,毕竟从目前的技术上来说能玩的都基本上玩了一遍,剩下的就是具体场景具体处理了。同时因为工作的原因接触的都是全新的工业软件这条路了。今年是22年或许到年底的时候,我会有一些新的收获和变化吧。