做soho一定要做网站吗,浙江建设厅 继续教育 网站首页,中国建设论坛网站大全,手机版网站开发公司我的技术回顾#xff1a;2015年#xff1a;我的技术回顾那些与ABP框架有关的故事-2015年2016年#xff1a;从ABP框架国内社区发展回顾.NET技术变迁-2016年2017年#xff1a;我的技术回顾那些与ABP框架有关的故事-2017年2018年#xff1a;我的技术回顾那些与ABP框架有关的故… 我的技术回顾2015年我的技术回顾那些与ABP框架有关的故事-2015年2016年从ABP框架国内社区发展回顾.NET技术变迁-2016年2017年我的技术回顾那些与ABP框架有关的故事-2017年2018年我的技术回顾那些与ABP框架有关的故事-2018年2019年我的技术回顾2019不止技术的一年我居然把这个系列坚持下来了感觉真的是超级棒感谢小伙伴的支持以及督促。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/MOiRNY8a6m0YROj5NzTwMQDevOps要实现的几大要素代码管理需求管理持续集成(CI)持续部署(CD)如果您是考虑公有云的解决方案那么就很简单了阿里云、腾讯云、华为云、微软Azure 里面有一堆现有的解决方案你只需要把代码托管过去然后配置下就可以了。毕竟Im 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的名气让我至少不用担心他不会更新这种问题吧。在确定了采用gitlabgitlab 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年或许到年底的时候我会有一些新的收获和变化吧。招个人我的团队还缺.NET 开发 中高级工程师薪资14-20K不等。有兴趣的可以联系下我投个简历。多种方式联系我们 交流社区QQ群:461610507 课程网站 yoyomooc.com《深入浅出ASP.NET Core》书籍配套源代码与视频下载京东/当当均有在售
