我居然把这个系列坚持下来了，感觉真的是超级棒！感谢小伙伴的支持！以及督促。
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年或许到年底的时候，我会有一些新的收获和变化吧。
