云原生
 
云原生简介

 
Ref. doc
 云原生讲解
 云原生参考文章1
 CNCF官方定义
 云原生landscape
 
云原生简介
 
CNCF，即Cloud Native Computing Foundation - 云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软、思科等巨头。
 
云原生计算基金会（CNCF）致力于培育和维护一个开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
 
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、敏捷基础设施和声明式API。
 
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
 
Cloud Native 翻译为云原生，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。
 
云原生涉及的技术领域众多，有6个方面值得大家重点关注：
 
1. 容器（Containers）
 
容器是一种轻量级的虚拟化技术，通过容器可以简化应用的部署、管理和交付。目前各大IT厂商已经投入了大量的资源进行容器产品和服务的研发，可以预见，未来容器将会是一种主流的应用交互手段，非常有前景。
 
2. 微服务（Microservices）
 
微服务倡导运用化整为零，实现各个功能的独立开发与部署、提升应用架构的灵活性，从而提升对业务的响应速度。在提倡敏捷的今天，微服务已经成为应用架构的一种默认的选择。
 
3. 无服务器架构（Serverless）
 
无服务器架构并不是说，未来不再需要服务器，而是不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上，例如一些函数的代码片段，平台自动根据负载按需部署和启动，以及自动伸缩代码逻辑来满足业务处理的需求。
 
4. DevOps
 
DevOps这个框什么都可以往里装，提供了指导思想、流程和工具，为应用的迭代更新保驾护航，运维行业的未来之路。
 
5. Service Mesh(服务网格)
 
Service Mesh是近年兴起的一个话题，在容器微服务的基础上，通过Service Mesh可以让用户更精细、更智能的去管理服务之间的通讯。ServiceMesh社区的旗舰项目Istio，当前的热度正在迅速的飙升。
 参考信息1
 参考信息2
 
6. 云（Cloud）
 
云是云原生的基础，没有云也就没有云原生。没有对云正确地理解，也不可能对云原生有正确的打开方式。对于非技术人员来说，至少要理解云的多种不同的服务模型，比方IaaS、PaaS、SaaS以及各种服务模型的应用场景和价值。参考：云服务
 
优点
 Cloud Native是更好的工具、自我修复系统、和自动化系统的集合，可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本。
 
云原生技术可以让系统松耦合，支持弹性伸缩、可管理的、清晰的。通过整合健壮且有效的自动化，工程师可以用很少的劳动来完成频繁的、预期中的高危代码修改。
 
云原生技术可以提升应用开发的交付效率，缩短应用上线所需要的时间，开发和业务团队人员可以有更多的时间和精力进行业务创新，有效地提升团队的创新能力，从而提升企业在市场的竞争能力。
 

Dapr 是什么？
 
Dapr是一个开源、可移植、事件驱动的云原生分布式应用运行时，它使开发人员能够轻松地构建运行在云平台和边缘的弹性而微服务化的无状态和有状态的应用程序，从而降低基于微服务架构构建现代云原生应用的准入门槛。
 
Dapr 的名字来源于分布式应用运行时（ Distributed Application Runtime）的缩写。
 
为什么我们选择Dapr？
 
在阿里巴巴，Java 使用非常广泛，不仅仅业务应用大量使用 Java，大量中间件和基础能力的服务器端也是使用 Java 开发。在过去十几年间，我们围绕 Java 建立了非常完备的生态体系，经历过各种严酷的考验。
 
而随着业务形态的日渐丰富，多语言 的需求在不断的增加，如 nodejs / golang / c / c++ / rust 等。特别是在微服务流行之后，根据实际情况而选择使用不同的编程语言开发微服务成为趋势。但效仿 Java ，为每一种编程语言都打造一套功能完备的生态体系在成本上是不现实的。因此，需要一个成本可控的方案来解决多语言问题，让微服务开发能真正的实现“语言自由”。
 
随着云的采用，业务应用的形态也开始朝云原生方向发展，越来越多的业务应用（尤其是前台业务）开始拥抱 FaaS 和 Serverless 作为应用托管和资源调度的解决方案。而在 FaaS 和 Serverless 场景下，需要更轻量化的解决方案以满足快速启动和伸缩的需求 —— 传统类库模式下由于需要集成大量的SDK，业务应用变得非常的臃肿。而在 Function 形态下更加的不协调，以nodejs为例：几百行的 nodejs Function 代码依然需要依赖多达几十兆的node module。同时 FaaS 和 Serverless 也对多语言的支持提供了更高的要求。因此，在 FaaS 和 Serverless 这种新型形态下有必要提供有别于传统类库方式的、更轻量化的、支持多语言的解决方案。
 
显然，Servicemesh 倡导的 Sidecar 模式是解决上述问题的绝佳方案。在过去几年间，随着 Servicemesh 的发展和采用， Sidecar 模式已经得到充分验证：Sidecar 模式非常符合云原生的理念，特别是在多语言支持和应用轻量化方面具备天然优势。
 
我们非常认可 Bilgin Ibryam 在 “Multi-Runtime Microservices Architecture” 一文中提出的 Multiple Runtime / Mecha Runtime 的理念，尤其是他对分布式应用需求的分析，很符合我们的实际情况。
 

 而 Dapr 是第一个实践 Multiple Runtime 理念的开源项目，我们从这个项目发布开始就密切关注它，因为 Dapr 可以很好的解决我们面临的问题：Sidecar 模式天然提供了对多语言的支持，各种客户端SDK被 Dapr Runtime 替代之后应用也得以轻量化。
 
此外，从长期战略的角度考虑，我们在2020年提出了”三位一体”的理念，即将”自研技术”、”开源项目”、”商业产品”形成统一的技术体系，最大化技术的价值。而当前的实际情况是三者有完全不同的产品和技术方案，导致当我们需要将某个产品在阿里内部、公有云、客户私有云等不同的平台上进行迁移时，或者是跨多个平台部署时，就会遇到非常大的挑战。Dapr 面向能力编程的理念，强调可移植性和可扩展性的标准API，平台中立、无供应商锁定的设计，深深的吸引了我们。
 
 
 
“在阿里云，我们相信 Dapr 将引领微服务的发展。通过采用Dapr，我们的客户现在可以以更快的速度来构建可移植和健壮的分布式系统。” —— 阿里云资深技术专家 李响
 在2020年年中，我们开始基于 Dapr 项目进行了内部小规模的试点，在实际的落地过程中探索和验证 Dapr 的理念。我们也积极参与到 Dapr 开源项目的建设中，提交了大量的改进建议和代码。
 
 
下面我们将以 Dapr 在阿里的实际落地场景来具体说明 Dapr 是如何帮助我们解决上述问题的。
 
Dapr在阿里的实践
 
概况
 
目前 Dapr 在阿里巴巴内部还处于实验阶段。
 
我们的首要工作是为内部的中间件开发 Dapr 组件，使业务应用程序可以与这些中间件和实现它们的 Java 语言/ Java Client SDK 解耦。然后通过小规模的业务应用落地，在各种场景下的对 Dapr 进行验证，在验证完成之后计划继续部署较大规模的业务应用。
 
截止到2021年3月，Dapr 在阿里内部落地的场景主要集中在2个方面：多语言支持和云间迁移。
 
多语言支持
 
Faas / Serverless 场景
 
背景：在阿里的电商系统中，存在大量活动和导购需求。
 
这些需求的特点是”短平快”：需要快速开发、快速迭代、生命周期相对比较短。因此这类需求非常适合通过采用 FaaS 的方式来落地。
 
Faas 对多语言支持有强烈的诉求，肯定不会局限于 Java。而阿里内部大部分应用都是Java 体系，对多语言的支持比较弱，尤其是新兴语言（如Dart）或者小众语言（如Rust）。
 
而从需求上说，采用 FaaS 的应用也同样需要和内部运行的服务以及各种中间件/基础设施进行通讯，因此 FaaS 平台迫切的需要解决多语言支持问题。
 
通过 Dapr ，我们很好的解决了 FaaS 的多语言问题，从而使得客户通过 FaaS 实现了开发效率的大幅提升。
 
多语言应用的接入
 
背景：阿里收购有大量的公司
 
这些收购的公司有大量的应用，而这些应用中很多不是Java体系，在接入阿里的技术体系时，对多语言支持有明确的需求。
 
另外，由于业务创新的需要，有些应用对 nodejs 和 golang 有强烈诉求，还有一些应用则需要使用到 Dart 和 C++。
 
但目前这些语言的生态系统并没有像 Java 那么完善，尤其部分中间件和基础设施已经发展的非常成熟，进入维护状态，不太可能在现在重新开发所有语言的客户端：成本上代价很高，时间上也来不及。
 
通过 Dapr ，我们可以为这些应用的提供多语言解决方案。
 
复杂的Java遗留系统
 
背景：基于 Java ClassLoader 机制而设计的复杂系统
 
为了解决类冲突问题，隔绝不同的业务模块，阿里针对 Java 系统设计了基于 ClassLoader 机制的复杂系统，这些系统的设计往往非常复杂，应用也非常臃肿。
 
此外，部分业务团队为了能和现有的中间件进行互通，自行维护了一套多语言的中间件SDK，而这些SDK本来应该由中间件团队维护并保持同步更新。这也带来了稳定性方面的隐患和风险。
 
我们期望将这些遗留的系统迁移到 Dapr 中，统一实现中间件SDK的维护和更新。比较特殊的是这里存在一个需求：最好能让业务开发团队尽量不做代码层面的调整，以减少迁移时对业务应用的冲击。
 
所以针对 Java 遗留系统，在迁往 Dapr 时，我们额外设计了一个Java适配层：将原来的 Java 调用适配到 Dapr 的客户端API上。
 
以上三种多语言的落地实践场景，如下图所示：
 
 
云间迁移
 
 
 
背景：业务应用对外输出时有跨平台需求
 阿里的部分业务，如钉钉文档，原本是提供给阿里内部和外部用户直接使用的，此时钉钉文档只需要部署在阿里内部的业务集群里，直接访问阿里内部的生态体系。
 
 
但是随着 SaaS 业务的发展，以及部分信息安全敏感的用户对于数据安全的强烈诉求， 需要将钉钉文档部署到用户VPC下或者公有云下。
 
为此，我们需要将钉钉文档的系统从阿里内部迁移到公有云上进行部署，而钉钉文档使用的底层技术需要从阿里内部的技术体系迁移到使用开源技术或阿里云的商业化产品上。
 
借助 Dapr 的标准API和可扩展的组建模型，我们采取的策略是让用户不需要修改任何代码，直接通过 Dapr Runtime 屏蔽底层使用的中间件：部署在不同平台时，通过激活 Dapr 中的不同的 Component 来提供一致的能力。
 
以消息通讯威力，当应用需要访问消息系统时：
 
在阿里内部：通过 Rocketmq.yaml 激活 Rocketmq 组件
在公有云上：通过 Kafka.yaml 激活 kafka 组件
 
通过 Dapr 的可移植性，上层的钉钉文档应用现在可以和底层的基础设施（如消息系统）解耦，从而实现在不同的云平台之间平滑迁移：
 
 最终帮助我们的业务团队实现了他们的业务目标：使 Dingtalk 在任何地方部署成为可能。
 
阿里的Dapr未来规划
 
未来我们将继续通过应用试点的方式对 Dapr 进行验证，包括：
 
适用场景
性能
稳定性
可移植性
 
同时我们将继续开发 Dapr 的组件，以集成更多的中间件和基础设施，包括内部产品和阿里云上支持的商业产品。其中对阿里云商业产品的集成代码，我们将在验证通过之后贡献给 Dapr 项目，从而为 Dapr 提供阿里云支持。这些项目预计将包括：
 
Apache Dubbo的RPC支持
Apache RocketMQ的消息传递支持
Nacos的动态配置支持
阿里云RDS的MySQL支持
阿里云缓存服务的Redis支持
 
作为 Multiple Runtime 架构的先驱者和 Dapr 项目的早期采用者，我们将继续和 Dapr 社区合作，在落地的过程中努力完善 Dapr 的功能、性能、稳定性等关键指标，和社区一起联手打造云原生时代的 Distributed APplication Runtime！

简介： 日前，在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上，阿里云高级技术专家黄玉奇发表了题为《云原生新边界：阿里云边缘计算云原生落地实践》的主题演讲。
 
作者 | 黄玉奇
 来源 | 阿里巴巴云原生公众号
 
日前，在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上，阿里云高级技术专家黄玉奇发表了题为《云原生新边界：阿里云边缘计算云原生落地实践》的主题演讲。
 
 
大家好，我是阿里云云原生团队的黄玉奇，非常感谢能有这个机会来跟大家分享。今天分享的题目是《云原生新边界∶ 阿里云边缘计算云原生落地实践》，从题目也能看到，分享内容应该是包括几个部分：云原生、边缘计算、二者结合架构设计、阿里云在商业和开源的实践以及案例。
 
今天大家所熟知的云原生（Cloud Native）理念，本质是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。所以，云原生这个术语自诞生，到壮大，再到今天的极大普及，都处于一个不断的自我演进与革新的过程当中。云原生已经作为一系列的工具、架构、方法论而深入人心，并为广泛使用；那么云原生到底是如何定义的呢？早期，云原生含义包括∶ 容器、微服务、Devops、CI/CD；2018 年以后 CNCF 又加入了服务网格和声明式 Api。
 
而回过头，我们再粗线条的看看云原生的发展历史，早期因为 Docker 的出现，大量的业务开始容器化、Docker 化。容器化通过统一交付件、隔离性从而带来了 Devops 的快速发展；Kubernetes 的出现让资源编排调度与底层基础设施解耦，应用和资源的管控也开始得心应手，容器编排实现资源编排、高效调度；随后，lstio 为代表的服务网格技术解耦了服务实现与服务治理能力。今天云原生几乎"包罗万象"般的无处不在，越来越多的企业、行业开始拥抱云原生。
 
 
而阿里巴巴作为云原生技术的践行者之一，云原生早已成为阿里的核心技术战略之—，这源自于过去十多年阿里在云原生领域的积累、沉淀和实践。大致可以分为三个阶段：
 
第一阶段通过应用架构的互联网化沉淀了核心中间件、容器、飞天云操作系统等基础云原生能力；
第二阶段是核心系统的全面云原生以及云原生技术的全面商业化；
第三是云原生技术的全面落地和升级阶段，尤其是以 Serverless 为核心代表的下一代云原生技术正在引领整个技术架构升级。
阿里云容器服务 ACK 作为阿里云原生能力相关的商业化平台，正在为广大客户提供丰富的云原生产品及能力，这些都是拥抱云原生最好的佐证，我们坚信云原生是未来。
 
云原生技术已经无处不在， 阿里云作为云原生服务的提供者，我们认为云原生技术会继续高速发展，并被应用于"新的应用负载"、"新的计算形态"和"新的物理边界"；从阿里云云原生产品家族大图中我们可以看到∶ 容器正被用于越来越多类型应用和云服务中；并且通过越来越多的计算形态承载，如 Serverless、函数计算等等；而丰富的形态也开始从传统的中心云走向边缘计算，走向终端。这就到了今天分享的主题：边缘计算中的云原生，下面我们看看什么是边缘计算。
 
首先，我们从直观感受上看看什么是边缘计算。随着 5G、loT、音视频、直播、CDN 等行业和业务的发展，我们看到一个行业趋势，就是越来越多的算力和业务开始下沉到距离数据源或者终端用户重近的地方，从而来获得很好的响应时间和降低成本;这明显区别传统的中心式的云计算模式。并越来越被广泛应用于汽车、农业、能源、交通等各行各业。
 
 
再从 IT 架构上看边缘计算，可以看到它具有明显的按照业务时延和计算形态来确定的分层结构，这里分别引用 Gartner 和 IDC 对边缘计算顶层架构的解释∶ Gartner 将边缘计算分为"Near Edge"、"Far Edge"、"Cloud"三部分，分别对应常见的设备终端，云下 IDC/CDN 节点，以及公共云/私有云；而 IDC 则将边缘计算定义为更直观的"Heavy Edge"、"Light Edge"来分别表示数据中心维度，和低功耗计算的端侧。从图中我们可以看到分层结构中，层层相依。互相协作。
 
这种定义也是现在业界对边缘计算和云计算关系所达成的一个共识。说完背景、架构，我们再看看边缘计算的趋势;我们尝试从业务、架构和规模三个维度去分析边缘计算的三大趋势：
 
第一，Al、loT 与边缘计算的融合，会有种类越来越多、规模越来越大、复杂度越来越高的业务运行在边缘计算场景中，从图上我们也能看到一些非常震撼人心的数字。
 
第二，边缘计算作为云计算的延伸，将被广泛应用于混合云场景，这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力，同样图上也有部分引用数字。
 
第三，基础设施的发展将会引爆边缘计算的增长，随着 5G、loT、音视频行业的发展，边缘计算的爆发是理所当然，去年疫情期间在线直播、在线教育行业的爆发式增长也是一个例子。
 
随着架构的共识形成，在落地过程中我们发现，边缘计算的规模、复杂度正逐日攀升，而短缺的运维手段和运维能力也终于开始不堪重负，那么如何去解决这个问题呢? 
 
云和边缘天然就是不可分割的有机整体，"云边端一体"的运维协同是目前比较能形成共识的一种方案。而作为云原生领域的从业人员，我们试着从云原生的角度来思考和解决这个问题;试想，如果"云边端一体"有云原生的加持，将会更好的加速云边融合进程。
 
 
在这个顶层架构设计下，我们抽象出了云边端协同的云原生架构：在中心（云），我们保留了原汁原味的云原生管控和产品化能力，通过云边管控通道将之下沉到边缘，使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载，通过服务流量和服务治理更好的和端进行交互;从而完成业务、运维、生态的一体化;而通过边缘云原生，我们可以获得和云上一致的运维体验，更好的隔离性，安全性以从及效率。产品落地就顺师理成章了许多。
 
接下来我们介绍阿里云在商业化和开源上的边缘计算云原生实践。
 
 
阿里云 ACK@Edge 主打“云端标准管控，边缘适度自治”的服务理念；“云边端”三层结构分层明显，能力协同。第一层是中心的云原生管控能力，提供标准的云原生北向接口供上层业务集成，诸如城市大脑、工业大脑、CDN PaaS，loT PaaS 等；第二层是云边运维管控通道，有多规格、软硬多链路方案来承载云边下沉管控流量和业务流量；再往下就是关键的边缘侧，我们在原生的 K8s 能力基础上叠加了类似：边缘自治、单元化管理，流量拓扑，边缘算力状态精细化检测等能力；边云协同，从而构成了一个完整的云边管控闭环；目前，这套架构已经广泛用于 CDN、loT 等领域。
 
那么边缘容器到底需要哪些核心能力和业务目标呢，图中所示包括∶ 四个能力，五个目标；四个能力是边缘算力管理、边缘业务容器化管理、边缘业务高可用支持和最终要实现的边缘云原生生态；从而实现边缘算力可接入、可运维，业务可管理、编排，服务高可用，业务有生态。下面对这些核心能力的设计做简单阐述。
 
阿里云边缘容器产品 ACK@Edge 通过内置 SD-WAN 能力实现云上云下网络互联，业务流量互通，大大提升云边协同效率和稳定性、安全性;而通过云端资源对接，实现了云上云下的资源弹性互通，提升了边缘场景下的业务弹性能力。
 
 
第二个核心能力是边缘自治能力，在云边一体架构中，运维协同是一项重要的能力，但是通常受限于云和边缘之前的网络条件，边缘需要适当的自治能力来保证业务的连续性和持续稳定运行，换句话讲就是边缘资源和边缘业务能够在脱离云端管控的条件下继续完成业务的全生命周期管理，包括创建、启停、迁移、扩缩容等。
 
 
第三个异构资源的支持比较好理解，边缘计算区别于传统中心云计算的一个标志性特征就是计算资源、存储资源种类多样、异构明显。ACK@Edge 目前支持 arm x86 cpu 架构，支持 linux、windows 操作系统，支持将 linux 应用和 windows 应用混合部署，来很好地解决边缘场景资源异构问题。
 
通过配合阿里云容器镜像服务，提供在边缘场景下的多地域交付能力，能够支持多种云原生制品的多地域交付，包括容器镜像，应用编排资源包等。
 
 
这里还要和大家同步一个信息，就是上述所有核心的边缘容器能力我们都开源在边缘容器平台项目 OpenYurt 中，OpenYurt 是 CNCF 的边缘容器官方项目，是一个延伸原生 Kubernetes 到边缘计算的智能开放平台项目。
 
作为 ACK@Edge 的核心框架，已经服务了超百万容器实例规模，并被广泛应用于主流的边缘计算场景中；在介绍完商业和开源实践后，还有几个案例和大家分享：
 
 
第一个，是盒马鲜生基于边缘云原生实现的“人货场”数字化融合转型，通过云原生体系将多种类型的边缘异构算力统一接入、统一调度，包括∶ENS（阿里公共云边缘节点服务）、线下自建边缘网关节点， GPU 节点等。获取了强大的资源弹性和业务混编带来的灵活性;并通过 ACK@Edge 提供的边缘云原生 Al 解决方案，构建云、边、端一体化协同的天眼 Al 系统，充分发挥了边缘计算就近访问，实时处理的优势，轻松实现全方位的降本提效，门店计算资源成本节省 50%，新店开服效率提升 70%。
 
 
第二个是我们在一家视频网站客户的案例，使用 ACK@Edge 来管理跨 region、跨类型、跨地域的边缘算力，用于部署视频加速服务，通过对异构资源的支持，客户在边缘计算场景获得了强大的资源弹性能力；有一个数字分享给大家，通过边缘容器的弹性和异构资源管理能力，能够节省 50% 左右的成本。
 
 
第三个案例是 ACK@Edge 在 loT 智慧楼宇项目中的落地，其中 loT 网关设备作为边缘节点托管在 ACK@Edge 的云端管控，网关设备上的业务和楼宇的智能设备交互;网关和端设备的运维都统一收编到中心云，效率大大提升。
 
原文链接
 
本文为阿里云原创内容，未经允许不得转载。

目录
 
 
 
 
文章目录
 
 

  
目录
  
云原生应用的特征
  
云原生应用的架构
  
如何构建云原生应用
 
 
 
 
云原生应用的特征
 
 

 
 
普遍可访问（Universal Availability）：服务可在任何地方从多前端访问。
 
 
 
高可用性（High Availability）：基本服务随时在线。升级扩容服务无中断。单点失败影响范围小。失败触发自动恢复。负载均衡，自动限流降级熔断，异常流量自动调度，故障隔离，宕机自动迁移等。
 
 
 
高扩展性（Scalability）：服务可以随业务需要随时迅捷线性伸缩。
 
 
 
自动弹性伸缩（Elasticity）：服务可以随业务需要按定义自动伸缩。根据业务负载自动伸缩，做到秒级扩缩容能力，灵