云原生2021展望

云原生已经成为了现代企业架构首选，这里总结了云原生在 2021 年的发展趋势。

注意其中提到的一些项目尚未生产环境可用

Kubernetes 地位进一步稳固

根据云原生产业联盟的 2020 年调查数据显示，Kubernetes 在受访人群的采纳率高达 63%，17% 用户选择 Docker Swarm。

KubeCon 及 CloudNativeCon 是 Kubernetes 项目官方推广会议，近年来的参与人数呈现爆发性增长。

conference-attendance.png

并且，参与 Kubernetes 的开发者中，越来越呈现出多样性。

Change-in-percentage-of-contributors-by-country.png

CNCF WG-Serverless: Serviceless workflows

CNCF Serverless WorkGroup 最初的任务是寻找云原生和Serviceless可以产生协同效应地方。

A Serverless Overview Whitepaper及Serverless Landscape是工作组当时的产出。

之后，工作组继续进行了 Serverless Workflow 以及 CloudEvents 相关的工作。

serverless-workflow-spec-parts.png

sw-spec-overview

最终，WG-Serverless 工作组呈现出来的是标准化的 事件驱动 的云原生 Serviceless 框架。

The Serverless Workflow language is composed of:

• Function definitions: Reusable functions that can declare services that need to be invoked, or expressions to be evaluated.
• Event definitions: Reusable declarations of events that need to be consumed to start or continue workflow instances, trigger function/service execution, or be produced during workflow execution.
• Retry definitions: Reusable retry definitions. Can specify retry strategies for service invocations during workflow execution.
• State definitions: Definition of states, the building blocks of workflow control flow logic. States can reference the reusable function, event and retry definitions.

总之，Serverless Workflow 是一项标准，但是 Runtime 需要额外实现。

实现类似能力的云服务有:

• AWS Step Functions
• Google Cloud Workflows
• 阿里云 Serverless工作流

需要注意的是，上述服务均没有实现上述的 Serverless Workflow 标准。

目前 Serverless Workflow 尚处于开发阶段，且没有可用的 Runtime，因此还未处于实际可用阶段。

现有的SDK只包含 Schema 解析的功能，没有完整的运行时。

• Go SDK
• Java SDK

Serverless 相比于微服务架构更为激进，原始应用切换为 Serverless 一般都需要重写，并且 Serverless 不适用于下列场景:

• 成本敏感，Serverless 框架的性能一直是短板，Serverless 很少有高并发应用案例
• 复杂业务逻辑，业务逻辑的复杂性是固有的，而如果 Serverless 让复杂性进一步提升，那么 Serverless 化的意义就有待商榷

目前各个云服务平台都有独特的 胶水 DSL组装 Serverless Function，而 Serverless Workflow 提供了统一的标准，降低了使用者在不同云平台切换的门槛，降低了用户云平台绑定顾虑。

CloudEvents

Events 是一个抽象概念，实际上无处不在，但是这个概念没有标准定义，于是针对 Events 没有形成非常统一的软件规范。

CloudEvents 是 CNCF WG-Serverless 的另一项工作，为 Events 定义了一种规范。

Events are everywhere. However, event producers tend to describe events differently. The lack of a common way of describing events means developers must constantly re-learn how to consume events. This also limits the potential for libraries, tooling and infrastructure to aide the delivery of event data across environments, like SDKs, event routers or tracing systems. The portability and productivity we can achieve from event data is hindered overall. CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.

CloudEvents 规范为跨服务/系统交换数据提供了标准支撑。

消息队列: NATS VS Kafka

NATS

消息队列已经成为云原生应用最重要的中间价之一。

NATS 是 CNCF 主推的消息队列服务，优势是简单、安全、高性能以及和云原生社区高度协同。

NATS 与 Kafka 如何选型呢 ?

• 首先，大数据领域一般选型 Kafka
• NATS 面向在线服务之间的消息传递，混杂 Event/Message
• NATS 提供 最多一次 语义，Kafka 提供 最少一次 语义，因此如果要确保消息一定被消费，NATS 需要慎重选择
• NATS 简单好维护，Kafka 复杂一点，但从实际使用看，Kafka 运维成本也不高
• 性能方便，两者性能相近

此外，如果想要 至少一次 语义，可以考虑 nats-streaming

CSI 进一步成为存储标准

CSI, container-storage-interface 提供了存储与容器对接的标准，用于替换 Flex Volume。

CSI 独立于 Kubernetes Storage SIG，由 Kubernetes、Mesos、Cloud Foundry 负责推广应用。

CSI 提供的能力包括:

• Dynamic provisioning and deprovisioning of a volume, 动态提供数据卷
• Expand Volume, 扩展大小
• Snapshot, 快照备份

目前越来越多的存储支持 CSI。完整的插件列表CSI Drivers

Service Mesh

CNCF 提供了 Service Mesh Interface 作为 Service Mesh 标准。

相应的，已经有多种实现支持这一标准:

• Consul Connect*: service segmentation (consul.io/docs/connect)
• Flagger: progressive delivery operator (flagger.app)
• Gloo Mesh: Multi-cluster service mesh management plane (solo.io/products/gloo-mesh)
• Istio*: connect, secure, control, observe (servicemeshinterface/smi-adapter-istio)
• Linkerd: ultralight service mesh (linkerd.io)
• Traefik Mesh: simpler service mesh (traefik.io/traefik-mesh)
• Meshery: the service mesh management plane (layer5.io/meshery)
• Rio: application deployment engine (rio.io)
• Open Service Mesh: lightweight and extensible cloud native service mesh (openservicemesh.io)
• Argo Rollouts: advanced deployment & progressive delivery controller (argoproj.io)

其中 Open Service Mesh 是 CNCF 官方提供的 Service Mesh, 目前处于开发阶段，尚不可用于生产环境。

• lightweight, Simple to understand and contribute to
• extensible
• Cloud Native, Easy to configure via Service Mesh Interface (SMI)

Service Mesh 在生产实践中的认可度还是很高，但是还是有下面的局限性:

• 网络延迟，对于延迟敏感型应用，多一个 sidecar 意味着多了 10 ms左右的延迟，有时是不可接受的
• 网络复杂性，K8s 本身的网络环境就已经很复杂，加上 ServiceMesh 进一步加重了这种趋势
• 故障可能性增加，Service Mesh 组件的稳定性至关重要，多了一层就多了故障概率

云原生服务器/裸金属服务器

云原生服务器 与 裸金属服务器 概念相近，但更近一步，硬件优化更面向云原生场景。

《云原生发展白皮书》

传统 IaaS 层计算产品形态主要分为裸金属物理机和云服务器两大类。两者在计算性能，管理运维方面各有优势，又都存在不足。云原生服务器则兼顾了物理机的性能优势、完整特性和云服务器的管理便利，进一步解决客户对高性能计算的强需求。 云原生服务器是指基于专用硬件、芯片，利用软硬融合虚拟化等技术将负载或任务转移，提升资源使用效率、用户体验和整体性能的新型服务器。云原生服务器采用软硬一体的硬件卸载和加速技术，通过专用的硬件，将原来在物理机上运行的网络、磁盘、管控等负载，完全下沉到定制的硬件上，物理服务器上的资源可以被最大程度的释放出来，从而提升资源的使用效率，降低成本。同时，通过使用 ASIC或者 FPGA 等专用芯片来处理存储、网络等任务，可以使用较低的成本将性能提升数倍甚至一两个数量级。此外，软硬融合的虚拟化技术能够支持裸金属形态的计算产品，使其同时具备虚拟机的使用体验和物理机的强大性能。

但这个方向是否可以走出规模化道路还未可知，因为硬件定制化带来的能效提升可能不能抵消规划化效应带来的成本降低。

是否云原生服务器可以被市场接纳，要看云厂商是否可以对这一概念产生共识，目前这个概念的主导方是阿里云。

Argo

Argo Workflows in 5 minutes

Argo 定位为 CI/CD 以及 Workflow。

作为 Workflow 的部分与 Airflow 为竞品关系。

在大数据的离线调度中，Argo 长期看可以取代 Airflow

• Argo 更为轻量，而 Airflow 需要连接数据库
• Argo 更符合云原生的思想，配置可呈现程度高
• Argo 更适合执行计算密集型负载
• Airflow 会有死锁问题，当任务执行过久造成堆积时，可能因为任务相互依赖造成死锁

Airflow 相比于 Argo 优势

• 特性丰富，业界已经积累了各种常见任务的实现
• 定时调度及 DAG 实现成熟度高，支持 backfill

Argo 尚缺少一项关键特性: 支持 backfill，这需要Workflow的每次调度有一个时间参数，这样可以重跑旧的时间实例。

目前已经有 Issue，但是为 Open 状态。

Cron Workflows

Cron Workflows Backfill

Issue: Cron workflow time parameters

Helm VS Kustomize

Helm 与 Kustomize 都是应用打包发布的常见工具。

在 Thoughtworks 技术雷达 中，将 Helm 列为陈旧的技术，而将 Kustomize 列为推荐方案。

因此，重新梳理了一下两者的优劣，结论是: Helm 依据是应用发布的最佳方案。

Kustomize 十分简洁，但是相比于 Helm 有以下局限性:

• 首先应用打包工具面对的是复杂的应用，简单的应用直接 kubectl apply 就可以解决问题
• Helm 更适合复杂应用场景，其 sub chart 特性可以让复杂应用层次化组合在一起
• 轻松支持多环境部署，这是一个非常强烈的诉求
• 易于理解，所有配置集中到 values.yaml，也可以支持多种 values.yaml, 而具体部署细节隐藏起来，可以使大型应用更易管理
• 不只是安装，Helm 还可以跟踪应用状态/回滚/卸载

Helm vs Kustomize: How to deploy your applications?

可观测

监控能力是云原生领域的重要基础设施。

监控领域三板斧: Metrics, Logging, Tracing, 而 Logging, Tracing 可以进一步转化为 Metrics。

CNCF 建议:

• Prometheus 作为 Metrics 的解决方案
• Fluentd 作为 Logging 解决方案
• 推荐 Jaeger 作为 Tracing 解决方案，但也可以使用兼容 OpenTracing 的其他解决方案

Prometheus 是目前云原生监控领域的核心组件，而 Fluentd/Jaeger 的地位尚未稳固。

Fluentd 的竞争者有 Loki, Logstash。其中 Loki 因为和 Grafana 组合的高度易用性，近期发展迅速。

Jaeger 的竞争者有 zipkin, 不过转向使用 Jaeger 的趋势在增强。

另外 Grafana 社区的强劲发展，有一统监控可视化的趋势。

参考

CNCF 官网

CNCF Kubernetes Project Journey Report

CNCF Cloud Native Landscape

信通院:云原生发展白皮书

KubeCon CloudEvent

CNCF Serverless Whitepaper

CNCF Serverless KubeCon