牛年 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：服务调用构件块