我的技术回顾因ABP框架触发DevOps云原生之路-2020年
?我的技術回顧：
2015年：我的技術回顧那些與ABP框架有關的故事-2015年
2016年：從ABP框架國內(nèi)社區(qū)發(fā)展回顧.NET技術變遷-2016年
2017年：我的技術回顧那些與ABP框架有關的故事-2017年
2018年：我的技術回顧那些與ABP框架有關的故事-2018年
2019年：我的技術回顧2019不止技術的一年
我居然把這個系列堅持下來了，感覺真的是超級棒！感謝小伙伴的支持！以及督促。
2020年，我開始往非.NET技術方向發(fā)展，也就是DevOps和容器化解決方案發(fā)展。當然最后落地了之后，發(fā)現(xiàn)這就是各大廠商所開始推廣的云原生解決方案。
ABPVnext源代碼引發(fā)的思考
20年因為疫情的緣故，大家都沒有辦法出門，所以得空好好看看ABPVnext的源碼，把握技術的發(fā)展趨勢。在看ABP框架的微服務整套解決方案的時候，我發(fā)現(xiàn)了一個非常好玩的點，土牛為了嚴格遵循ABP模塊化的規(guī)范，將所有的業(yè)務模塊以及通用模塊化拆分的特別細致。這樣就帶來了一個問題。
以業(yè)務模塊為例它有差不多17個模塊，而每個模塊下按照類庫劃分，又會產(chǎn)生8-9個類庫。
賬戶體系下的類庫劃分有9個類庫，而這些還不包含Angular的前端。
我們做一個簡單的計算就可以知道光業(yè)務模塊的后端代碼他就有136個類庫，這個還僅僅是業(yè)務模塊，還沒有包含它的所有abpvnext的源代碼，而且還沒有前端的解決方案。
這些類庫還要發(fā)布到nuget.org作為公共的工具包，給廣大開發(fā)者進行使用。
前端的angular方案它也被拆成了一個個獨立的npm包。
如果是手動管理和發(fā)布這些nuget和npm包，那就是異常災難。
電腦的配置以及內(nèi)存也要足夠強。
abpframework采用了github的開源倉庫以及周邊強大的CI工具可以白嫖這些廠商的服務。但是它還有一個商業(yè)版本的代碼是不開源的，而這些商業(yè)版本的CI也是需要服務的。所以土牛的團隊里面肯定是有一套完整的DevOps解決方案的，而在容器化的解決方案上一定是Docker，大可能會直接采用k8s進行管理。
當然以上雖然是猜測，后面也確實基本上證實了，abp團隊是這樣的方案。那么我就在想我沒有土牛團隊的資金以及人手，我怎么打造一套方案呢。
再次拿52abp官網(wǎng)練手
我手里最現(xiàn)成的可以練手，而且還是足夠真實，屬于自主可控的就是52abp的官網(wǎng)了。那么不用它作為練手就太可惜了。
首先把他改造成完整的Docker部署，這個不難，但是又產(chǎn)生了一個問題，那就是鏡像版本的控制。
Docker是要容器倉庫的，自己中途搭建了habor的倉庫，可惜因為沒錢沒服務器難產(chǎn)。
作為微軟MVP遷移到了微軟Azure所提供的倉庫，但是尷尬的就是因為是global的倉庫，導致網(wǎng)速跟不上。
白嫖的阿里云個人倉庫真香，當然我的視頻在線播放用的是阿里云VOD，也算是他的小客戶了。
然后把配合Nginx加上docker swarm把52abp做成了雙節(jié)點，后來發(fā)現(xiàn)是沒有必要的，畢竟一個日均流量2k的網(wǎng)站要什么集群。然后切換為了Docker-compose 來管理。
我非常建議大家都學習下Docker進行部署和管理的解決方案，有興趣的可以前往yoyomooc進行學習，你會發(fā)現(xiàn)你在運維這方面會給你省太多事情了。然后就要折騰CI CD工具了。
聊聊DevOps的折騰經(jīng)驗
DevOps這個話題非常的大，里面要包含的內(nèi)容太多了。我們簡單說下幾個關鍵點：
在20年的時候我其實發(fā)布過一篇文章《小微技術團隊的DevOps體系折騰之路》鏈接地址：https://mp.weixin.qq.com/s/MOiRNY8a6m0YROj5NzTwMQ
DevOps要實現(xiàn)的幾大要素：
代碼管理
需求管理
持續(xù)集成(CI)
持續(xù)部署(CD)
如果您是考慮公有云的解決方案，那么就很簡單了，阿里云、騰訊云、華為云、微軟Azure 里面有一堆現(xiàn)有的解決方案，你只需要把代碼托管過去，然后配置下就可以了。
畢竟I'm Rich 這個技能永不過時
而作為一名程序員尤其是想打造一套可控的解決方案的時候，就需要把代碼管理、需求管理、持續(xù)集成、持續(xù)部署這些都變成自己的技能，這樣才能讓自己的項目和技術棧更加穩(wěn)定。
代碼托管工具
市場上的代碼托管工具有很多：Gogs、Gitea 、Gitee、GitHub、Gitlab、Azure DevOps，這些用于管理代碼，足夠了。你如果還是開源項目的話，可以使用github的所有免費服務。
但是如果是私有化方案，以上都行，但是你會涉及到一個問題那就是CI CD的工具選擇。
CI CD工具的選擇
大部分開發(fā)者會選擇使用Jenkins作為自己的第一個CI 工具，畢竟Jenkins是最常用的CI CD工具，而且老牌、資料和文檔也足夠多。我在17年的時候也選擇了它作為CI CD工具，當時覺得沒什么問題，畢竟雖然部署有點小麻煩，畢竟部署好了的服務，誰會沒事去改它的環(huán)境呢。
在2019年我和陳計節(jié)在 DNT精英論壇上，作為講師分享的時候，我們探討Jenkins作為CI的時候，討論過它在容器化解決方案的問題。
Jenkins雖然來市場上最早，但是因為無法做到快速的云原生部署，所以遲早會沒落。我也在接觸了Jenkins之后，發(fā)現(xiàn)他在Docker下的解決方案，確實不美好。雖然后面 Blue Ocean提供的pipeline的出現(xiàn)和發(fā)展讓這一情況有了很大改觀，但是我個人依然不推薦。
Drone 也一直是作為和Jenkins進行碰瓷的選手所存在的，后面推出了商業(yè)版本，我在研究了之后，發(fā)現(xiàn)確實是一個很好的選擇。
在最開始的Git代碼管理的時候，我看過Gogs、Gitea、gitlab等很多平臺，最開始想選擇Gitea的，但是在19年經(jīng)歷過了免費的才是的最貴的經(jīng)驗之后。這次選擇讓我不得不慎重。
在翻閱gitlab的時候，發(fā)現(xiàn)他的CE版本，以及它的runner CI工具，集成度非常的高。而且最大的優(yōu)勢在于它的很多擴展都是內(nèi)置的，對于的社區(qū)也是很龐大的。而且gitlab的名氣讓我至少不用擔心，他不會更新這種問題吧。
在確定了采用gitlab+gitlab runner 這個技術方案后。我就開始了狂奔之旅。
單獨用gitlab + gitlab runner 都不難，配合docker也不難。難的是你要把所有的場景和流程都適配進去，這個時候就開始變難了。
不過好歹都解決了，不得不說 gitlab runner 可以在Docker下快速進行部署和發(fā)布的時候一切問題都迎刃而解了。
聊聊云原生的容器化
關于云原生的介紹網(wǎng)上有很多，我就不再闡釋了。在說云原生容器化的時候，我們都會說它是最佳的載體，因為容器具備快速伸縮擴展以及銷毀。
我在練習Devops流程的時候，每天要銷毀和創(chuàng)建十幾次vm虛擬機。容器的創(chuàng)建和銷毀就更多了，這個時候就發(fā)現(xiàn)容器化的魅力太強了。而如果沒有云基礎設施的話，我要手動去維護和管理這些虛擬機，實在是太煩了。
尤其是在利用cloud-init配合vm機器創(chuàng)建的時候，一鍵給你部署好Docker環(huán)境，甚至你做的好點，配合腳本可以快速搭建和部署屬于你自己的一套環(huán)境。而這些時間可以從2-3天的環(huán)境搭建到部署安裝依賴環(huán)境，縮短到1-2個小時。
哦。到了這里，你可能問我為什么沒有使用kubernetes。那是因為就52abp的情況來說，沒有必要上Kubernetes，而且上了K8S，我的運維成本又會上去了。所以選擇適合自己的場景永遠是最好的。
尾聲
21年的回顧就不用寫了，因為之前已經(jīng)寫過差點翻車的總結吧。同時21年我的純技術沒什么提升，畢竟從目前的技術上來說能玩的都基本上玩了一遍，剩下的就是具體場景具體處理了。同時因為工作的原因接觸的都是全新的工業(yè)軟件這條路了。今年是22年或許到年底的時候，我會有一些新的收獲和變化吧。
招個人
我的團隊還缺.NET 開發(fā) 中高級工程師，薪資14-20K不等。有興趣的可以聯(lián)系下我，投個簡歷。
多種方式聯(lián)系我們
?交流社區(qū)
QQ群:461610507
?課程網(wǎng)站?
yoyomooc.com
《深入淺出ASP.NET Core》書籍配套源代碼與視頻下載
京東/當當均有在售
總結
以上是生活随笔為你收集整理的我的技术回顾因ABP框架触发DevOps云原生之路-2020年的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： WPF 基础控件之 DatePicker
- 下一篇： 这是Blazor上传文件的最佳方式吗？