去年我写过一篇 牛年 dotnet云原生技术趋势[1]，今天再来写一篇虎年云原生落地技术趋势，去年局限在.NET 平台上的云原生落地，我今年在去年探索云原生落地的基础上从多语言云原生技术落地的趋势来谈谈。
在 2020 年的时候，云原生理念就被提到得越来越多，但是真正呈现出爆发形态、真正被所有的云厂商、用户广泛使用的是在 2021 年。国内三大云厂商都在2020年发布了云原生2.0 路线图，而且这些头部厂商的云原生落地到达了一个里程碑式的关键节点，代表性事件就是各大互联网公司基本完成了云原生化，所有业务百分之百上云。云原生的核心技术如容器、微服务、服务网格等的可用性和成熟度都已经可以支撑起头部互联网的体量。每个行业的云原生进度不一样，头部互联网公司跑得比较靠前，基本都做到了全面云原生化。未来几年，其他行业会逐步追随互联网的脚步全面走向云原生化。
随着直播、5G、IoT 等领域的兴起，让业务对于云的形态需求更高，大家希望云能够更贴近数据的产生点，因此相应的边缘云、本地云、混合云的形态越来越多。现在，整个云计算有一个很重要的趋势，就是呈现一云多形态的模式，用户在各个地方都能用到云计算的能力。但这也对云的基础设施提出了比较大的挑战。用户以前就是用一朵云，管理复杂度是可以接受，但多朵云形态后，挑战难度就比较大了。
云原生技术天然能够比较好地解决云变成多形态后的统一界面管理问题，包括混合云带来的复杂度挑战。下面两张图是我在2021年实践云原生的一个路线图总结：
CNCF 里面有非常多的开源项目，里面的项目已经超过一千了。这些开源项目围绕着云计算在展开竞争，CNCF孵化项目成熟度模型分为三个级别，分别对应到鸿沟理论划分的三个目标客群：
- 沙箱级（Sandbox）：对应创新者群体
- 孵化级（Incubating）：对应早期使用者群体
- 毕业级（Graduated）：对应早期多数群体
项目从孵化级向毕业级过渡最为关键，需要跨越鸿沟（The Chasm）。在此跨越过程中，孵化项目需要向有影响力的公司和组织证明自己提供的能力能够改进生产流程、提升效率、降低成本，并且足够稳定可靠以保证在生产环境使用。截至2022年2月3日，从CNCF成功毕业的项目有16个，进入孵化级别的是27个项目，具体参看CNCF的毕业和孵化项目[2]。
在2022年云原生在各行各业开始进入全面落地阶段，CNCF在推进云原生发展过程中已经形成了几大比较关键的标准：
最早出现的是容器，解决了应用打包标准化和应用发布标准化的问题。在此之前，虚拟机等方式的标准化程度是不够的，Docker 终结了这一问题。随着 Docker 的不断演进和推广，在应用编排、资源调度等又出现了新的问题，当时的 Docker Swarm、Mesos 和 Kubernetes 互相竞争，最后 Kubernetes 胜出，并带来了新的资源编排方面的事实标准。现在 Kubernetes 已经成为一个事实标准。而应用层之前也是百家争鸣的情况，每个企业都在做自己的云原生应用，现在有越来越多的开源标准出现，如OAM(Open Application Model) 和SMI(Service Mesh Interface)等，大家都在尝试定义应用层的标准, OAM 和 SMI 尚未形成事实标准，他们有成为事实标准的潜力，2022年就是非常关键的一年，在云原生项目落地的过程中以OAM 标准的代表项目Dapr 目前在多运行时框架领域是一个非常耀眼的项目，落地的案例也非常多了。云原生的多语言是必然趋势。国内后端开发最火的语言是Java，已经有很多公司（腾讯、字节）在用 Go 作为主要开发语言，PHP 的使用也非常广泛。每种语言的特点不太一样，很多企业会根据业务需要选择一种合适的语言。这时可能会出现多种语言，业务部门觉得用 Java/C#比较好，偏前端的想要 PHP 或者 Node.js，多语言在企业内部越来越普遍。开发人员想用什么语言就用什么语言，但是运维人员就会面临很大的挑战，如多语言环境下的服务治理怎么能统一做等。Java 之前在阿里基本处于统治地位，但现在阿里内部也多语言了。阿里收购了非常多的企业，如饿了么、飞猪、高德等，但不可能让所有并购进来的公司都改变编程语言，这是很难的。由于公司并购，阿里内的编程语言已经变得多元化了。企业足够大的话，就一定是多语言的。如果是初创公司或者体量还不够大，语言统一确实能带来便捷。所以阿里和微软主导了开源项目Dapr，详细内容可以参看 Dapr 在阿里云原生的实践[3], 高德 Serverless 平台建设及实践[4]。
云原生实践在支持多语言这个技术方案上还有Service Mesh，Service Mesh出现的时间上比Dapr 更长久， 目前也处于混战阶段，Istio 并不在CNCF 社区里，微软联合众多厂商在CNCF里提出了SMI(Service Mesh Interface), 主要的Service Mesh框架都实现了SMI，微软主导的Open Service Mesh 遵循SMI 规范，最近也发布了1.0 版本，我昨天体验后写了一篇体验文章 体验 正式发布 的OSM v1.0.0 版本[5]，Open Service Mesh 相对于Istio 来说，确实很轻量。SMI 处理了所有你期望的标准服务 Mesh 功能，包括使用 mTLS 确保服务之间的通信安全，管理访问控制策略，服务监控等，Dapr 和 OSM 是非常好的一个实践多运行时架构的组合。
国内有很多企业已经在虚拟机、物理机环境使用Spring Cloud，这些企业转向云原生时，如果还是简单把spring cloud 部署到kubernetes 环境，spring cloud的很多基础架构能力是和kubernetes相重叠的，想充分享受kubernetes 带来的自动化方面的能力，最好的选择是卸下Spring Cloud，通过Dapr提供的分布式能力让解决方案在各种环境中自由适配，而且Spring Boot 版本可自主升级，不再与Spring Cloud 存在兼容性问题。
我看到有些企业是为了技术而去做云原生，这样最后不一定有好的结果，更多时候还是先从业务价值角度出发考虑要做什么事情，再选择相应的技术。一方面，企业有业务驱动，便会有足够多的资源投入。另一方面，企业在做技术选型和落地的时候会有足够多的实践。从领域来讲，我给大家的建议就是先把基础打好，之后再完善一些生产必备的技能。容器技术是所有的基石，在这之后是一些比较关键的像可观测性、CICD、微服务等企业内部落地真正需要的一些关键技术。
- [1]牛年dotnet云原生技术趋势：https://www.cnblogs.com/shanyou/p/14398499.html
- [2]CNCF的毕业和孵化项目:https://www.cncf.io/projects/
- [3]Dapr 在阿里云原生的实践:https://developer.aliyun.com/article/785943
- [4]高德 Serverless 平台建设及实践:https://xie.infoq.cn/article/686a83fccba14504517ec6fe5
- [5]体验 正式发布 的OSM v1.0.0 版本 : https://www.cnblogs.com/shanyou/p/15861828.html
