牛年 dotnet云原生技术趋势

首先祝大家:新年快乐,牛年大吉,牛年发发发!

2020年的春节,新冠疫情使得全球业务停滞不前,那时候,没有人知道会发生什么,因此会议被取消,合同被搁置,项目被推迟,一切似乎都停止了。但是我们却见证了IT社区所焕发的活力。尽管其他行业还不能恢复正常,各行各业通过IT技术来进行经济和社会活动,2020年让我们把数字化转型向前推进了一大步,很多传统的企业通过这次数字化的洗礼,云的技术被更多人所接受,在IT行业中,基于云原生技术的开发仍在继续,该领域也出现了一些有趣的技术趋势,我们一起来看下未来几年内dotnet 技术在云原生领域的发展。

在过去几年里,一直在被吹捧的新兴的微服务风格的微服务风格应用程序构建,应用程序将大型应用程序分解为较小、相互连接的组件,从而使团队可以在应用程序的不同部分上独立工作,而不会互相干扰,但是微服务也会带来自身的一系列挑战。更有甚者是有些团队为了微服务,认定spring cloud就是构建微服务的利器,选择将dotnet转向spring cloud搞微服务,结果是微服务也没搞好,落了个天天996,团队成员怨声载道。随着2020年kubernetes 的进一步普及,dotnet 在容器化方面的优势的不断提升,dotnet在kubernetes 这个新时代的安卓系统里面的优势越发明显, 微服务构建也转向了以Sidecar 模式,这种Sidecar 模式正在以更加迅猛的势头将中间件领域的能力下沉至 Kubernetes 这个新一代的应用基础设施当中,除了已经如火如荼的 Istio 对流量治理领域的颠覆,微软已经不甘示弱的开源了 Open Service Mesh 作为回应。而与此同时, OAM 在微软的姊妹项目 Dapr 则直接拉齐了 Kubernetes 与中间件在“服务发现与绑定”侧的距离,老牌项目 Dubbo 亦宣布了下一代云原生中间件的技术蓝图。当然, 所有这一切背后的用户动机是非常清晰的:云原生时代的中间件,既要语言无关,也要平台无关。

在所有问题上,对于任何给定的项目而言,正确的方法都可能介于两个极端之间(要么微服务架构,要么单体架构),微服务的构建在企业软件设计中正在取得平衡,不会再走向极端,而是接受了微服务的真正内涵,既与语言无关,又与平台无关,选择适合自己团队背景的技术构建云原生应用,对于dotnet 技术背景的团队在构建云原生应用,.NET 5为你提供了很好的技术底座。

尽管Kubernetes主要面向系统运维人员,但它也在如何轻松扩展和管理分布式应用程序方面引发了一场革命,对于开发人员而言,它仍然是需要跟进学习的一个新时代的分布式操作系统,我们的企业基于kubernetes 构建自己的服务平台,kubernetes 位于底层, 基于kubernetes开发云原生应用程序的工作,微软有一次走到了前面,作为最懂开发者的微软 偕同阿里云 推出了开放应用模型 OAM ,OAM 正迅速成为Kubernetes 社区中的事实标准, OAM 在微软的姊妹项目Dapr 再一次将我们开发云原生应用的模型呈现在所有社区面前,目前已经发布了1.0-RC3,也许春节后就可以正式发布1.0.特别对于.NET开发者来说,Dapr 里面的编程模型是很熟悉的,Dapr 所带来的有状态的Actor服务,就是来自于.NET开源项目Orleans 的Virtual Actor,还有微软的开源项目Service Fabric 的Virtual Actor。

云原生的微服务在任何现代应用程序框架中都越来越重要,因此选择正确的开发环境和工具至关重要。随着Dapr接近其1.0版本,它为我们提供了一组构建块和支持工具,可帮助我们以易于部署和可重复的方式实现关键的微服务设计模式。对通用语言的支持和与框架无关的方法确保了花几天时间评估Dapr是非常值得,大家学起来吧。推荐大家从这几篇由朱永光 写的文章开始了解:

Dapr微服务应用开发系列0:概述

Dapr微服务应用开发系列1:环境配置

Dapr微服务应用开发系列2:Hello World与SDK初接触

Dapr微服务应用开发系列3:服务调用构件块

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpyydp.html