.NET Core开发云原生应用

为什么要云原生（Cloud Native）

Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

 

了解了为什么要云原生以后，接下来，我们看看到底什么是云原生？

 

云原生的定义(1.0)

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

 

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

 

容器

有效的将单个操作系统的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求，这种技术就是容器技术。

 

Docker 是目前被最官方使用的。提到它就离不开Kubernetes(管理容器集群)。他们两个对于初学者来说就好像两座大山，但其实如果你明白他们解决的问题和场景，或许你会觉得原来他们已经“很简单”了。作为运维已经基本算是必备技能了，而对于开发来说，繁重的开发压力或许也是让大家没有更多精力从全方位了解一个新的领域的重要原因吧。如果在开发时可以屏蔽一些偏运维的技能，或许将是个不错的选择。

 

服务网格

处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。

 

两大王者Istio和Linkerd，他们是云原生解决方案和微服务架构中必不可少的组成部分（只需要其中之一即可）。他们提供了如服务发现、负载均衡、故障恢复、指标和监控等功能，甚至连A/B 测试、金丝雀发布、限流、访问控制和端到端身份验证都被涵盖进去了。虽然他们很强大，但近两年异军突起的Dapr或许会给大家带来新的可能性。

 

微服务

把一个服务拆成N个小的服务就是微服务，NO！！！

 

我有一个单体，只要我把业务分成不同的类库，到时候给他们套个Web API的壳跑起来，就是微服务，NO！！！

 

微服务通常需要按领域科学拆分，目的是为了每个切分的领域可以自主开发，独立部署。

正因为独立部署成服务，由类库间调用就要转向服务调用，所以需要标准的通信协议。

引入了标准的通信协议，所以不同的语言只要遵循协议，也就没有语言占山为王一说了（要硬说没有也不是，毕竟单一语言的经验积累比并行多个语言还是要容易的，可不同的语言也有他们自身的优势）。

最后组合在一起形成了一个新的应用（所以微前端的概念也可以插进来了）。

 

这不还是拆就完事儿了？NO！！！

 

微服务将会带来新的挑战：

• 如何解决通信相关的问题，比如性能，瞬态故障，网络阻塞，安全性等

• 如何让服务可以弹性伸缩，比如程序崩溃，流量瞬间增大，部署等

• 如何解决分布式的挑战，比如大量数据，分布式事务，跨服务查询等

• 如何存储密钥或敏感信息？

 

.NET不会替你解决这些挑战，但它会帮你。比如.NET 6和.NET 7的更新，正在为支持云原生而做的努力。这些应该被开发者们看到，并大胆的去尝试，去体验。

 

不可变基础设施

基础设施在部署了之后决不会被修改。一脸懵逼 ≡(▔﹏▔)≡

说一下优点，它可以保证基础设施具有更高的一致性和可靠性，更简单，可预测的部署过程。那来反推一下，如果基础设施部署后人为变更了，那自动化过程就可能会受到阻碍，比如雪花服务器。

 

声明式API

描述目标状态，而不是指令

 

声明式API相当于是我只需要告诉服务 会议室空调是26度，至于是要打开空调还是调整温度这个由服务来自行完成。在我们设计的绝大多数服务都会直接提供 打开空调API，设置温度API，所以声明式API和命令式API其实是有本质的区别的。

 

Java比.NET更有优势？

Java的确起步的早，但今日的.NET已经不是以前的.NET了。.NET最近几个大版本的更新中，针对云原生技术的挑战已经开始发力解决了。甚至在一些方面实现了反超，这让使用.NET构建云原生应用成为更优解变得可能。