精华内容
下载资源
问答
  • 特别指出:这次分享主要是希望起到抛砖引玉的作用,让大家更多的参与到云原生这个话题的讨论,希望后面有更多更好的分享。我们笨鸟先飞,起一个头。 内容主要围绕这几个问题,上半场我们将围绕前三个问题。 ...

    前言

     

    特别指出:这次分享主要是希望起到抛砖引玉的作用,让大家更多的参与到云原生这个话题的讨论,希望后面有更多更好的分享。我们笨鸟先飞,起一个头。

     

     

    内容主要围绕这几个问题,上半场我们将围绕前三个问题。

     

    如何理解云原生?

    第一个话题:如何理解“云原生”?之所以将这个话题放在前面,是因为,这是对云原生概念的最基本的理解,而这会直接影响到后续的所有认知。

     

    每个人对云原生的理解都可能不同,就如莎士比亚所说:一千个人眼中有一千个哈姆雷特。

     

     

    我们来快速回顾一下云原生这个词汇在近年来定义的变化。

     

     

    先看 Pivotal,云原生的提出者,是如何定义云原生的。

     

     

    这是 2015 年,云原生刚刚开始推广时,Matt Stine 给出的定义。

     

     

    两年之后,同样是 Matt Stine。

     

     

    而这是 Pivotal 最新官方网站的描述。可见 Pivotal 对云原生的定义一直在变。

     

     

    再来看看目前云原生背后最大的推手,CNCF,这是 2015 年 CNCF 刚成立时对云原生的定义。

     

     

    2018 年 CNCF 更新了云原生的定义。

     

     

    这是新定义中描述的代表技术,其中容器和微服务两项在不同时期的不同定义中都有出现,而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来,和微服务并列,而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。

     

     

    云原生自身的定义一直在变,这让我们该如何才能准确的理解云原生呢?

     

     

    这里我们尝试,将 Cloud Native 这个词汇拆开来理解,先看看什么是 Cloud。

     

     

    快速回顾一下云计算的历史,来帮助我们对云有个更感性的认识。

     

     

    云计算的出现和虚拟化技术的发展和成熟密切相关,2000 年前后 x86 的虚拟机技术成熟后,云计算逐渐发展起来。

     

     

    基于虚拟机技术,陆续出现了 IaaS/PaaS/FaaS 等形态,以及他们的开源版本。

     

     

    2013 年 docker 出现,容器技术成熟,然后围绕容器编排一场大战,最后在 2017 年底,kubernetes 胜出。2015 年 CNCF 成立,并在近年形成了 cloud native 生态。

     

     

    这是云的形态变化,可以看到:供应商提供的功能越来越多,而客户或者说应用需要自己管理的功能越来越少。

     

     

    当云发生如此之大的变化时,云上的应用要如何适应?

     

     

    在回顾完云计算的历史之后,我们对 Cloud 有更深的认识,接着继续看一下:什么是 Native?

     

     

    这是从字典中摘抄下来的对 Native 词条的解释,注意其中标红的关键字。

     

     

    Native,总是和关键字 Born 联系在一起。

     

     

    那 Cloud 和 native 和在一起,又该如何理解?

     

     

    这里我们抛出一个我们自己的理解:云原生代表着原生为云设计。详细的解释是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。

     

    这个理解有点空泛,但是考虑到云原生的定义和特征在这些年间不停的变化,以及完全可以预料到的在未来的必然变化,我觉得,对云原生的理解似乎也只能回到云原生的出发点,而不是如何具体实现。

     

    云原生应用应该是什么样子?

     

    那在这么一个云原生理解的背景下,我再来介绍一下我对云原生应用的设想,也就是我觉得云原生应用应该是什么样子。

     

     

    在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。

     

    然后应用将这些功能,连同自身的业务实现代码,一起打包。

     

     

    这是传统非云原生应用的一个形象表示:在业务需求的代码实现之后,包裹厚厚的一层非业务需求的实现(当然以类库和框架的形式出现时代码量没这么夸张)。

     

     

    而云的出现,可以在提供各种资源之外,还提供各种能力,从而帮助应用,使得应用可以专注于业务需求的实现。

     

     

    在我们设想中,理想的云原生应用应该是这个样子:业务需求的实现占主体,只有少量的非业务需求相关的功能。

     

     

    非业务需求相关的功能都被移到云,或者说基础设施中去了,以及下沉到基础设施的中间件。

     

     

    以服务间通讯为例:需要实现上面列举的各种功能。

     

     

    SDK 的思路:通过一个胖客户端,在这个客户端中实现各种功能。

     

     

    Service Mesh 的思路,体现在将 SDK 客户端的功能剥离出来,放到 Sidecar 中。

     

     

    通过这种方式,实现应用的轻量化。此时绝大部分的功能都在剥离,应用中只留下一个轻量级的客户端。这个轻量级客户端中还保留有少数功能和信息,比如目标服务的标识(指出要调用的目标),序列化的实现。

     

    这里特别指出,有一个功能是我们努力尝试但是始终没有找到办法的:业务动态配置的客户端。也就是如何获取和应用业务逻辑实现相关的动态配置信息。如果有哪位同学对此有研究,希望可以指教。

     

     

    我们的想法,云原生应用应该超轻量化的方向努力,尽量将业务需求之外的功能剥离出来。当然要实现理想中的状态还是比较难的,但是及时是比较务实的形态,也能比非云原生下要轻量很多。

     

     

    在这里举一个效果比较理想的实际案例,在 service mesh 中实现密文通讯。

     

    由于客户端和服务器端两个 sidecar 的存在,因此我们可以通过 Sidecar 之间的协商与合作分别实现加密和解密,从而实现远程通讯的密文传输,而这个加密和解密的过程对于原有应用是透明的。

     

    云原生下的中间件该如何发展?

     

    云原生涉及到的面非常广,对开发测试运维都会有影响,我们这里将聚焦在中间件,给出我们的一些粗浅的想法,因为我们来自中间件部门。大家也可以将中间件自行替换为自己关心的领域,尝试思考一下这个问题。

     

     

    前面我们讲到云原生应用的理想形态和轻量化方向,这里隐含了一个前提:不管云原生应用的形态如何变化,云原生应用最终对外提供的功能应该是保持一致的。

     

     

    而要实现这一点,应用需要依赖于云提供的能力,来替换因应用轻量化而剥离的原有能力,云提供的能力是应用形态演变的基础和前提。

     

     

    理想状态下,我们期望云能够提供应用需要的所有能力,这样应用就可以以最原生化的形态出现。但是现实是这一点远还没有做到,我们依然需要在云之外额外提供一些功能,比如原有中间件的功能。

     

     

    在云原生之前,中间件的做法通常是以类库和框架的形式出现,近年来也有服务形式。而在云原生时代,我们的想法是让中间件下沉到基础设施,成为云的一部分。

     

     

    在这里解释一下,在前面就提到了“下沉”,什么是下沉?

     

     

    我们的想法是:云原生下的中间件,功能应该继续提供,但是中间件给应用的赋能方式,应该云原生化:

     

    • 在云原生之前,应用需要实现非常多的能力,即使是以通过类库和框架的方式简化,其思路是加强应用能力,方式如左图所示,通过提供更大更厚的衣物来实现御寒御寒能力。

    • 云原生则是另外的思路,主张加强和改善应用运行环境(即云)来帮助应用,如右图所示,通过提供温暖的阳光,来让轻量化成为可能。

     

     

    我们以 Service Mesh 模式为例来详细讲解,首先我们以白盒的视角来看 Service Mesh 的工作原理:

     

    1. 以原生模式开发应用:应用只需具备最基本的能力,如客户端简单发一个请求给服务器端

    2. 部署时动态插入 Sidecar:当我们将开发的云原生应用部署到云上,具体说是部署在 k8s 的 pod 中时,我们会自动在 pod 中再部署一个 Sidecar,用于实现为应用赋能

    3. 在运行时,我们会改变云原生应用的行为:如前面所说客户端简单发一个请求给服务器端,在这里会被改变为将请求劫持到 Sidecar,注意这个改变对应用而言是透明无感知的

    4. 在 Sidecar 中实现各种功能:Sidecar 里面就可以实现原有 SDK 客户端实现的各种功能,如服务发现,负载均衡,路由等等

    5. Sidecar 在实现这些功能时,可以对接更多的基础设施,也可以对接其他的中间件产品,这种情况下,Service Mesh 产品会成为应用和基础设施/中间件之间的桥梁

    6. 可以通过控制平面来控制 Sidecar 的行为,而这些控制可以独立于应用之外

     

     

    我们再以应用的视角,将云和下沉到云中的 Service Mesh 产品视为黑盒,来看 Service Mesh 模式:

     

    1. 以原生模式开发应用

    2. 以标准模式部署应用:底下发生了什么不关心

    3. 客户端简单发一个请求给服务器端:底下是如何实现的同样不关心,应用只知道请求最终顺利发送完成

     

    Service Mesh 产品的存在和具体工作模式,对于运行于其上的云原生应用来说是透明无感知的,但是在运行时这些能力都动态赋能给了应用,从而帮助应用在轻量化的同时依然可以继续提供原有的功能。

     

     

    Mesh 模式不仅仅可以用于服务间通讯,也可以应用于更多的场景:

     

    • Database mesh:用于数据库访问

    • Message mesh:用于消息系统

     

     

    中间件下沉到基础设施的方式,不只是有 Mesh 模式一种,而且也不是每个中间件都需要改造为 Mesh 模式,比如前面我们提到有些中间件是可以通过与 Mesh 集成的方式来间接为应用提供能力,典型如监控,日志,追踪等。

     

    我们也在探索 mesh 模式之外的更多模式,比如 DNS 模式,目前还在探索中。

     

    简单归纳一下我们目前总结的云原生赋能(Cloud Empower)的基本工作原理:

     

    • 首先要将功能实现从应用中剥离出来:这是应用轻量化的前提和基础

    • 然后在运行时为应用 动态赋能:给应用的赋能方式也要云原生化,要求在运行时动态提供能力,而应用无感知

    云和应用该如何衔接?

     

    应用和云之间是需要密切配合的。

     

    • 对于非云原生场景,由于云正提供非常有限的能力,因此应用需要自行实现各种能力,包括通过类库/框架的形式。

    • 务实版本的云原生方案下,云可以提供大部分的能力,因此应用可以大幅减负,和非云原生相比在轻量化方面可以有明显的改观。但是依然存在部分能力云无法提供,因此应用还是需要自行实现部分能力。

    • 比较理想的云原生,是希望云能够提供绝大部分的能力,只是在某些特定环节无法完全剥离和解耦,但是此时应用的轻量化已经达到了非常高的水准。

    • 当然,理论上的最终目标,梦想中的云原生,应该是云提供所有能力,而且所有的环节都可以完全解耦,此时应用的轻量化可以做到极致,完全依赖云提供的能力。

    • 整个演进过程中的哲学就是:将复杂留给云,将简单留给应用。

     

     

    但是,这里需要先强调一下,云原生的演进过程,不仅仅需要云的努力,也需要应用作配合。否则,即便云已经可以提供各种能力,但是如果应用本身没有进行轻量化改造,未能使用云提供的能力,而是继续保持原有的非云原生的形态,那么效果就会大打折扣。

     

     

    回顾上半场的第一个话题“如何理解云原生”:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。这里强调的是,应用需要以原生形态来设计,以充分发挥云的优势。

     

    然后回到我们的话题,假设现在云已经准备妥当,各种能力都可以提供,而应用也按照云原生的理念设计,那当云原生应用部署在云上时,这些应用和云之间应该如何衔接?既可以让应用使用云提供的能力,又不至于侵入应用,破坏应用的云原生特性?简单说,就是要实现应用无感知。

     

     

    首先涉及到的就是赋能方式:即当云(包括下沉到云中的中间件)可以为应用提供各种能力时,这些能力又如何赋予应用呢?

     

    为了满足应用轻量化的需求,不应在编译打包等阶段引入这些能力,以保持应用的云原生特性。因此,我们的目标是:应该在运行时为应用 动态赋能。这样可以让应用在开发设计阶段保持简单和专注业务,在部署运行于云上之时再通过赋予的这些能力来对外提供服务。

     

    这个想法自然是非常理想化的,所以问题就来了:如何实现 动态赋能?

     

     

    流量透明劫持 是我们目前比较认可的动态赋能方式之一,在上半场谈到 Service Mesh 模式的工作原理时,讲到当我们讲应用部署在 Service Mesh 中时,我们会在部署时动态的在应用所在的 pod 中插入 Sidecar 容器,然后在运行时,会以对用户透明的方式来改变应用的行为。典型如将应用发出的服务间远程调用的请求,改为转向本地部署的 Sidecar,从而引入 Service Mesh 能提供的各种能力。

     

    这个在运行时透明的改变远程调用请求的行为,我们称之为 “流量透明劫持”。

     

     

    透明劫持的部署模式如上图所示,右边图片是应用容器与 Sidecar 容器在 k8s/Sigma 中的部署模式,左边图片是单个 pod 的放大。其中绿色方块为应用容器,蓝色方块为 Sidecar 容器,蓝色线条表示服务间通讯。

     

     

    透明劫持的具体工作流程是这样,我们以 iptables 流量劫持方案为例:

     

    • Init 流程(编号为 0 的两条紫色虚线):在 Pod 启动时,通过 Init Container 特权容器,开启流量劫持并设置流量劫持规则(分为 Inbound 规则和 Outbound 规则)。注意这个流程时部署时进行,因为不是真实请求流量所以用的虚线表示。

    • Inbound 流程(左边编号为 1,2,3 的黄色实现):Inbound 请求,被 traffic interception 劫持,根据 Inbound 规则请求被转发到 Sidecar,然后 Sidecar 再转发给应用。这是用于劫持 Inbound 流量,也就是外部访问当前应用的流量,使之在通过 Sidecar 再由 Sidecar 转发给应用。

    • Outbound 流程(右边编号为 4,5,6 的黑色实现):应用发出的 Outbound 请求会被 traffic interception 劫持,根据 Outbound 规则请求被转发给 Sidecar,然后 Sidecar 处理之后将请求发送给目的地。这是用于劫持 Outbound 流量,也就是当前应用访问外部服务的流量,使之先通过 Sidecar,然后由 sidecar 进行转发。

     

    通过上述三个流程,我们就实现了让应用的 Inbound 请求和 Outbound 请求在运行时改变行为方式,在应用无感知的情况下实现了将流量劫持到 Sidecar 中。然后我们在 Sidecar 中就有机会为当前请求赋予各种能力,典型如服务发现/负载均衡/实施各种路由策略/认证/加密等一系列能力,从而实现了对应用的动态赋能。

     

     

    当前流量透明劫持的技术实现方案有多种,其优缺点如图所示。

     

    透明劫持的最大优点是对代码无侵入:

     

    • 业务应用在开始时无需关注各种功能的实现细节和调用方式,也不需要依赖 SDK,这些能力会在运行时动态赋予

    • 对于已有的应用,旧有代码可以无需改动就直接运行在 service mesh 上

    • 从而避免修改代码,和相关的重新打包发布上线等复杂流程

    • 另外透明劫持支持直连(不经过 sidecar)/单跳(只经过一个 Sidecar)/双跳(经过两个 Sidecar),方便开发调试,容易实现和现有系统的兼容

     

    透明劫持近乎完美的实现了我们要求的目标:在运行时为应用 动态赋能,应用无感知。

     

    另外透明劫持还有一个比较隐蔽但是又非常关键的优点:不丢失重要信息。这指的是在透明劫持模式下,请求的原始目标地址和端口信息(original_dest)得以保留,让应用可以工作在特定协议应该绑定的端口上,从而更符合 12 factor 中”Port Binding”的要求,关于这一点的细节,可以见最后的花絮部分。

     

    由于原始目标地址和端口信息(original_dest)得以保留,因此透明劫持容许服务在多个端口上绑定多个不同协议而 Sidecar 只需要一个端口就可以实现流量转发。

     

     

    流量透明劫持的重要使用场景之一就是实现平滑迁移,即从现有的体系向 service mesh 体系逐渐迁移。

     

    图中时典型的服务注册/服务发现机制:应用向注册中心注册,然后客户端在发起请求时通过服务发现获得目标服务的地址列表,再选择其中的某个地址发出请求。

     

     

    当我们将其中的一个应用 (如图中的 Servcie B) 迁移到 Service Mesh 中,此时会和 Service B 一起部署 Sidecar 并设置流量劫持的规则。当 Service B 作为服务器端接收客户端请求时的,原有请求 Service B 的流量就会被劫持到 Sidecar。此时 Service A 和 Service B 都对此无感知。

     

     

    当 Service B 作为客户端对外发起请求时,请求会被流量劫持到 Sidecar,然后 Sidecar 再转发请求。同样,图中的 Service B 和 Service C 对此也是没有感知。

     

     

    当客户端和服务器端的应用都迁移到 service mesh 之后,此时两端都部署有 Sidecar,请求会按照 service mesh 的标准方式在客户端和服务器端都做两次透明劫持进入 Sidecar。依然,两端的服务对此无感知。

     

     

    透明劫持对于现有系统的升级非常有帮助,主要体现在为升级带来的弹性。如图所示:

     

    • 当客户端和服务器端都没有进行升级时,应用是直接连接的

    • 当客户端接入 service mesh 时,客户端会有改造,有 Sidecar 和透明劫持,因此客户端会有一次流量劫持,再往服务器端发送请求时,由于服务器端没有改造,因此服务器端是继续沿用原有方式直接连接。此时流量只经过一次 sidecar,我们称为“单跳”,客户端单跳。

    • 类似的,如果客户端没有改造,而服务器端有改造,则客户端工作方式不变而服务器端会有一次流量劫持,这也是单跳,服务器端单跳。

    • 当客户端和服务器端都改造完成时,在客户端和服务器端会有两次流量劫持,称为双跳。

     

    由于迁移的全过程都做到了对应用透明,因此在迁移过程中可以非常有弹性的安排应用的升级工作,包括个别应用升级失败时的回退。

     

     

    前面我们详细介绍流量透明劫持这种动态赋能的方式,下面我们继续介绍另外一种常见的动态赋能方式,DNS。

     

    在上半场我们介绍 Service Mesh 的思路时,我们提到在让应用轻量化的过程中,最终在应用里面还是会有一个轻量级的客户端,里面保留有少数功能和信息。这其中就有“目标服务标识”这一项,用于标识当前请求要发送的目标服务。

     

    而在此时,有一个很常见的方式就是用域名来做标识符,从而让客户端可以发起一次 DNS 解析请求到 DNS 服务器。而我们可以通过各种方式在 DNS 服务器中预设 DNS 信息,比如最中间的方式就是和服务注册中心拉通,通过某种方式将服务注册信息中的服务域名和 IP 地址信息(典型如 k8s 中使用 ClusterIP)导入到 DNS 服务器中。

     

    通过这样一个方式,就可以实现通过操作 DNS 记录来控制 DNS 解析的结果,从而实现特定目的。而将数据拉到到 DNS 服务器的方式可以有多种,域名和 DNS 记录信息的使用方式也可以有很多,配合流量透明劫持,Sidecar 也是可以获知这个请求的 DNS 解析结果…… 这里就有很多的想象空间了。

     

     

    具体 DNS 赋能的典型例子,在 SOFAMesh 项目中,为了兼容现有的单进程多接口的应用,而且容许客户端代码继续维持原有的用接口名而不是应用名来进行访问,我们就是利用了 DNS。

     

    如图,我们通过打通服务注册环节,在服务注册时获取到当前应用所提供的接口,然后将这些接口和应用的 ClusterIP 添加为 DNS 记录,使得这些接口名称对应的域名都指向 cluster ip。然后在请求过程中,客户端会通过接口名进行 DNS 解析,获取 cluster ip,接着以 cluster ip 为目标地址发出请求,然后被透明流量劫持进 Sidecar,sidecar 从请求的原始目标地址中获取到 cluster ip,就可以得到请求的目标服务,从而可以开始后面的各种流程。

     

    在这一过程中,我们组合使用了服务注册 + DNS 信息同步 + 流量透明劫持 + Sidecar 逻辑处理,比较好的实现了对旧有应用的兼容。

     

     

    在介绍动态赋能方式之后,我们再来继续看应用和云衔接的另外一个话题:在应用被赋予能力之后,应用该如何控制这些能力?

     

    控制的方式通常有两种:命令式和声明式。

     

    对于对于我们云原生的场景而言,有些微妙:这些能力时动态赋予应用的,应用根本无法直接控制这些能力的具体实现,而且从云原生的理念上可说,应用也不应该知道这些来自云的能力的具体实现方式,因此,在动态赋能的场景下,命令式是不合适。

     

    应用能为此做什么?应用肯定知道自己要达到的控制目标,即应用期待的目标状态。比如,应用可以要求说,当我访问某个服务时:

     

    • 要用轮询的负载均衡算法

    • 要 10%的流量去 v2 版本,其他的去 v1 版本

    • 要开启链路加密

    • 要……

     

    虽然这些能力会如何实现应用不清楚也无法直接控制,但是给出这些要求应用还是可以做到的。因此,声明式非常符合动态赋能场景下的控制需求。

     

    使用 声明式 API 的好处在于:

     

    • 简单:应用不需要关心实现细节,这些能力的具体的实现方式/流程/细节都是能力提供方内部完成。而且这些能力隐藏在云下,对应用是透明的,在运行时才动态赋予,应用完全可以简单实用这些能力而无需关注其他。

    • 自描述:声明描述的就是应用期望的目标状态

     

     

    声明式 API 的哲学:把方便留给别人,把麻烦留给自己。

     

     

    关于云和应用如何衔接这个话题,目前我们能给出的方案还不多,远谈不上理想,期望能够在未来会找到有更多更好的做法。对此有兴趣的同学,非常欢迎一起探讨这个话题,如果有好的想法和方式,欢迎随时指教。

     

    如何让产品更符合云原生?

     

    下半场的第二个话题:如何让产品更符合云原生?。

     

    注意这里要说的是产品,而不是应用。如何让应用更符合云原生有足够多的文章和理论了,但是如何提供一个产品,让这个产品为云原生应用提供服务和支持,然后要让这个产品本身更符合云原生,能找到的资料就不多了。

     

     

    我们先总结一下从前面内容中得到的一些规律:其核心在于,不仅提供功能,更强调体验:

     

    • 在讨论云原生应用应该是一个什么样子时提出,云原生应用就应该是原生形态,轻量化:云应该让应用更舒服

    • 在回顾云计算历史,探讨云的形态变化时,我们给出了中间这个图表:云应该让应用少做事

    • 刚刚探讨的声明式 API 的哲学,把方便留给别人,把麻烦留给自己:云应该让应用更方便。

     

    那么,当我们在云上开发产品,试图将产品的能力融合进云,让云上应用可以自如的使用这些能力时,应该遵循什么样的方式?

     

     

    在这里,我们介绍一个云原生的飞轮理论,其创意由我们团队的 典韦 同学,参考了亚马逊的飞轮理论。

     

    亚马逊的飞轮理论相信大家都很熟悉,在这里亚马逊努力打造了两个飞轮,即闭环循环,通过“选品与便利”和“更低价格”实现了更好的“客户体验”。

     

     

    详细介绍一下云原生的飞轮理论。首先,在云计算和云原生出现之前,下面的这个大循环其实就已经存在了。这个循环主要关注的是功能性方面的需求,提供商的产品主要通过提供功能来满足客户需求,当然不是说没有功能性之外的其他需求,只是在早期对非功能性的需求远没有今天这么多。

     

     

    进入互联网时代,尤其是移动互联网时代之后,这个大循环面临新的挑战,一方面在功能性方面要求越来越高:除了简单功能实现之外,还有对性能/安全/稳定性/高可用/可扩展性的诸多要求,而且越来越苛刻。

     

     

    另一个方面,在功能性之外,更多的需求来自对效率的追求:包括开发、测试、部署、维护、变更的效率,以及对成本的要求。

     

     

    对效率的追求,推动了云计算的产生和发展,以及云原生理念和架构的产生,我们熟知的容器技术,微服务架构,以及新生的 Service Mesh 架构都由此诞生,不可变基础设施和声明式 API 的理念也在实践中被总结出来,并为后续的云原生架构提供理论指导。

     

     

    云计算的发展,云原生的推出,为云和云上产品带来了功能性之外的一个重要特征:易用性。体现在有了云的支撑之后,云上应用可以简单开发,开发人员容易上手,由于大部分维护工作由云承担,因此降低了客户的维护工作量(甚至 serverless 提出了无维护的理念)。这些产品使用简单,对客户心智要求低,无需客户具体相关的专业知识。

     

    其核心在于分离关注点:客户和客户应用应该关注与业务实现,而非业务实现的内容应该由云和云上产品提供。

     

     

    而易用性的飞跃,在满足各种功能性的前提下,不仅仅满足了客户需求,也极大的改善了开发体验。在开发、测试、部署、维护、变更等环节的效率提升,也帮助用户控制了成本。

     

     

    这样,围绕易用性,新的闭环循环产生:对效率的追求,催生了云和云原生架构,带来了易用性的提升,改善了开发体验,从而进一步提供了效率。这个环形的过程会持续发生,云原生架构就会沿着这个飞轮循环不断的发展演进。在过去几年间,这个飞轮循环已经在运转,云原生架构中的容器/微服务等架构都是在这个循环中不断完善和普及。

     

     

    这是完整的云原生架构飞轮理论,两个飞轮分别关注功能性和易用性,两者结合来满足客户需求,改善开发体验,最终实现云原生架构的良性循环。

     

     

    为了更好的理解云原生的飞轮理论,我们以云计算中至关重要的虚拟化技术为例,看看这二十年间以虚拟化技术为基础,云和云原生架构是如何一步一步演进和发展的。

     

    首先,在物理机时代,在虚拟化技术出来之前,提供商只能提供服务器托管/服务器租用以及基于 web 服务器的虚拟主机服务,此时云还不存在。

     

     

    在 2000 年前后,出于对资源利用率的追求,在虚拟机技术成熟之后,基于虚拟机技术首先诞生了 VPS,然后陆续出现了大家熟悉的 VMWare/Xen/KVM/VirtalBox 等技术和产品,云计算开始出现。

     

    之后围绕易用性,先是 amazon 推出 s3 和 EC2,IaaS 出现;后面 HeroKu 推出了 PaaS。此时云已经走向成熟,而云原生架构也出现了早期形态,比如 HeroKu 提出的 12 factor 应用,DevOps 的流行。后面陆续出现了其他 Xaas 形态:SaaS/FaaS 等。

     

    此时的开发体验和物理机时代相比已经有质的飞跃。

     

     

    2013 年前后,以 docker 为标志的容器技术开始成熟,催生了容器编排、不可变基础设施等技术和理念。而容器这种轻量化虚拟计划的出现也极大的促进了微服务架构等的演进,2015 年前后,云原生架构被正式提出。而之前基于虚拟机技术的 XaaS 也开始向容器化方向转变。

     

     

    随着 kubernetes 完成了对容器编排市场的统一,云和云原生架构进入 kubernetes 时代,虽然底层虚拟化技术依然是虚拟机和容器,但是上层的 XaaS 形态已经开始陆陆续续开始向 k8s 转型。此时 k8s 奉行的声明式 API 等理念也成为云原生架构的指导思想之一。

     

     

    最近安全容器技术发展迅速,预期未来一旦技术成熟,很可能会带来新一轮的变革,未来的云和 XaaS 会可能会转为基于安全容器,也许还会有新的未知的形态出现,值得期待。

     

    从上述演进过程可以看到,随着虚拟化技术的一步一步演进,飞轮的一次一次循环,云开始诞生,XaaS 形态开始出现,各种技术和理念相继诞生并日益完善,云原生架构出现并开始成熟,新的理念和架构出现/实践/改进,整个云原生架构就这样在一次一次的飞轮循环中走向成熟。

     

     

    以云原生飞轮理论为基础和指导,分享一些我们团队在设计云原生产品的一点点心得:

     

    • 首先,在关注功能/性能之外,应该更多的关注易用性,关注开发者的体验,要将应用和应用开发者当成 bady 来呵护,努力让产品的使用者可以更舒适更简单的使用产品

    • 产品应该依托云原生架构,具体说,就是应该基于云,基于容器,基于 kubernetes。其核心观点在于,要让产品表现的更符合云原生,产品本身就应该是云原生的。

    • 顺势而为,要顺着飞轮的方向,迎合云原生的理念,迎合社区的发展方向。不要逆势而为,不要试图挑战整个社区。

     

     

    Kubernetes 是云原生的关键所在,怎么强调都不为过。这里有一个被越来越多人认可的说法:

     

    Kubernetes 是云原生时代的 Linux

     

    对这句话,我们有两个认识,在这里分享一下:

     

    • 应该以 kubernetes 为底座进行能力建设:简单说就是如果是 kubernetes 已有的能力则直接使用,如果 k8s 的能力不足,则在 kubernetes 上做改进和争强,充分利用 k8s 的能力,而不是选择无视。

    • 把 kubernetes 当 kubernetes 用:即要符合 kubernetes 的理念和设计,遵循 kubernetes 的游戏规则

     

    谈到遵循 kubernetes 的游戏规则,我们深入一下,核心在于遵循 kubernetes 的 CRD + Controller 模型:

     

    • 如果 k8s 底座的能力不够:则应该去补充和加强 k8s 的能力,体现为实现新的 Controller

    • 如果 k8s 的抽象不够:比如说对于某些复杂场景,现有 CRD 不适用或不够用,则应该定义新的抽象,体现为添加新的 CRD

     

    两者结合起来,加固 k8s 底座(Controller)+ 扩展 k8s 抽象(CRD),就可以得到新的云原生基础设施。

     

    另外,重要的事情说三遍:声明式 API,声明式 API,声明式 API!

     

     

    举几个用 CRD 做扩展的例子,典型如 Istio。

     

     

    还有 Google 新推出的 serverless 项目 knative。

     

     

    在通过以 加固 k8s 底座(Controller)+ 扩展 k8s 抽象(CRD)的方式打造新的云原生基础设施后,再在这些云原生基础设施的基础上,生长新的云原生产品。

     

     

    这里给出一个利用 k8s 能力的例子:Knative 的 Autoscaler 的实现。

     

     

    尽量遵循标准,尽量和社区一起玩:一方面可以从社区借力,跟随社区一起成长;另一方面,在产品对外输出时也容易被社区接受。

     

     

    最后再次强调一点:尽量不要逆势而为,尽量顺着云原生飞轮转动的方向。

     

    小结:

     

    关于如何让产品更符合云原生这个话题,我们这次只带来了一些比较基础的想法,由于在云原生这个领域我们也还处于摸索阶段,所以目前的看法和想法可能都还不够成熟。而且,更具体更深入的建议应该结合实际产品讲,但是本次分享中不太适合再进一步深入展开了,希望后面会有机会。

     

    此外,受工作范围限制,我们专注的领域偏中间件和服务间通讯,对于其他产品领域,期望后续有其他同学带来更深入分享。这也是我们本次分享的重要目的:抛砖引玉。

     

    花絮:有哪些有趣的角色转变?

     

    在本次分享的最后是花絮内容,我们轻松一下,来看看在云原生的演进过程中,有哪些有趣的角色转变?

     

     

    这里所说的角色,指的是一个云计算中的口头禅或者说典故,通常在英文资料中经常看到:Pets VS. Cattle。

     

    宠物或者奶牛,为了表述的更形象一些,我喜欢翻译为宠物或者牲口。

     

     

    这里有个问题:在云原生时代,有哪些概念发生了角色转变?大家有兴趣可以试试回答一下。

     

    我这里给出两个回答,一个是 IP 地址,从宠物到牲口;另一个是 端口/port,从牲口到宠物。

     

     

    IP 地址在云原生时代,从宠物到牲口,基本大家都比较认可了。

     

     

    而端口/port,从云原生之前的牲口,转变为云原生之后的宠物,则还存在比较大的争议。这里列出当牲口和当宠物的两个不同的端口使用方式。

     

     

    视端口为宠物的一个重要理论依据,来自 12 Factor 中的 Port Binding 原则。实践中很多产品,包括 Envoy / Istio 等都遵循这一原则。在我们的 SOFAMesh 产品中,我们也同样遵循这一原则。

     

    当然这个花絮的主要目的,还是希望可以借这个话题,让大家有个心理准备:在云原生之后,可能会有些之前理所当然的理念会发生变化。因此,请保持良好的心态 :)

     

    总结

    在最后,再一次强调,这次云原生分享是希望起到一个抛砖引玉的作用,期待后面会有更多同学出来就云原生这个话题进行更多的分享和讨论。

     

    展开全文
  • 阿里云边缘云原生技术专家江岑,分享了阿里云在边缘云原生的探索实践,并从应对技术挑战与系统架构设计等方面阐述产品核心竞争力,以创新技术驱动业务发展。 5月20-22日,第十三届中国系统架构师大会(SACC2021)...

    简介: 5月20-22日,第十三届中国系统架构师大会(SACC2021)在云端进行网络直播,主题为“数字转型、架构重塑”。阿里云边缘云原生技术专家江岑,分享了阿里云在边缘云原生的探索实践,并从应对技术挑战与系统架构设计等方面阐述产品核心竞争力,以创新技术驱动业务发展。

    5月20-22日,第十三届中国系统架构师大会(SACC2021)在云端进行网络直播,主题为“数字转型、架构重塑”。阿里云边缘云原生技术专家江岑,分享了阿里云在边缘云原生的探索实践,并从应对技术挑战与系统架构设计等方面阐述产品核心竞争力,以创新技术驱动业务发展。

    云原生发展与现状
    image.png
    随着云计算技术的成熟,大多数企业选择云计算来快速部署运营业务。5G规模商用,更是促进全球数百亿的终端设备联网。客户对于低时延、大带宽的近端准实时计算需求将大大增加。边缘云计算市场规模的增长,一方面来自于中心业务的下沉边缘,另一方是各类边缘创新业务场景的出现和发展,例如云游戏,智慧城市等。

    江岑认为,企业业务系统上云,无论是上中心云还是边缘云,大都会经历三个阶段:

    自建IDC的迁移,基于稳定性以及灾备等因素考虑,不会对业务架构有大调整,大部分只使用最基础的云服务,如ECS, SLB, VPC等;

    整体业务上云,从全面复用云的能力和提效降本的角度出发,随云而生的架构演进也逐步开始灰度应用。

    当一切就绪,业务开始大规模拥抱云原生。

    而现阶段,很多上云业务已经在大规模推进云原生化。

    云原生概念最早来自CNCF云原生计算基金会,Google孵化的Kubernetes平台。CNCF成立于2015年底,已孵化了大量符合云原生标准的优质项目,核心模块包含数据库、消息中间件、应用编排调度、CICD持续集成、RPC、 服务网格、容器服务、云原生网络等等。

    现在,云原生技术已经不局限于容器/Kubernetes领域,逐渐成为广大云厂商中立的软硬件基础设施的标准架构。边缘计算是在最近3-5年内随着5G、物联网技术应用而逐步兴起的技术,其技术成熟度还远低于中心云计算,目前CNCF上涉及边缘计算的项目还不多。伴随着边缘场景以及配套能力的提升,中心大量业务下沉到边缘,边缘创新场景不断涌现,必然会在边缘侧催生符合边缘特色的云原生技术。

    边缘云原生演进面临的挑战
    image.png

    在谈到云原生技术如何向边缘演进时,江岑提到了3个技术挑战:

    • 从资源侧看,边缘不同于中心大规模集中式的布局,主要以分布式和高地域覆盖率为目标建设。除了中心标准的云服务器,在边缘侧还存在大量的异构资源,包括物联网设备、MEC、合作共建节点等等。云原生技术对部署环境是有明确要求的,因此需要对边缘侧海量的异构资源做灵活的适配。另外,边缘节点的特点是小而多,提升资源复用率是关键,这就要求能够根据资源池化的能力和资源性能做灵活的弹性调度。
    • 从技术能力来看,云边基础设施存在差异,云原生能力直接下沉应用到边缘时,除了需要提供等同于中心的性能指标、安全隔离、容灾自治、架构感知等能力,还需要不断完善云边以及边边高速通道建设等,进而提升建设难度系数。
    • 当资源适配、技术能力已具备时,保持用户体验一致会面临很大的挑战。从用户视角来看,中心业务下沉过程势必是个漫长的过程,对于单一业务中心和边缘可能处于长期并存的状态,云边的能力建设很可能存在不一致,大部分的不一致对于用户应该是无感的,所以如何包装产品,在成本、功能、性能、稳定性等各方面达到云边一致的体验,是极具挑战的。

    阿里云边缘云原生体系建设

    依托遍布全球2800+边缘云节点,阿里云面向用户提供安全、稳定、可靠的边缘计算和内容分发加速服务,构建离用户最近的边缘云基础设施。单个节点是一个小型的IDC,规模在几台到几十台服务器不等。早期边缘云节点建点策略是和CDN分开独立建点,导致资源无法共享,缺少业务。目前建设策略是推动CDN ON ENS资源融合生产,整合边缘算力资源,融合后也给资源的分时复用带来更大的可能性。
    image.png

    CDN作为最成熟的边缘云应用场景,经历了长期的技术架构演进,其基础设施软硬件架构可以复用到边缘云技术中。源站通常为企业自建的服务器,规模及性能相对于中心云是比较有限的。在业务上线早期可以正常运转,但随着业务的增长,面对海量的客户端请求,假如没有CDN,企业只能增加资源投入,否则可能会造成服务端的响应超时甚至服务瘫痪。而CDN通过多级缓存以及全局的DNS调度能力,使用户能就近访问所需的资源(特别是图片、视频等静态资源),避免对源站带宽和服务器造成过度的压力。由于满足不同地域的用户就近接入,可以认为CDN天然具备低时延、全局大带宽的边缘云计算典型特点。支撑CDN的监控、数据智能、配置管理等系统,具备标准的边缘海量数据分发、处理,以及和中心交互的能力,也将逐步演进为边缘云原生的配套标准系统。
    image.png

    根据阿里云边缘云原生的能力模型定义可知:在资源侧,主要是将异构资源(包含传统物理机,云联节点,IoT/MEC设备,ARM阵列服务器等)进行并池云化,在这之上提供边缘云节点操作系统,将计算、存储、网络资源进行虚拟化,并结合容器/K8S标准云原生的能力进行模块化能力构建以及对应边缘标准生态延伸输出社区,比如面向业务需要有全网全集群应用生命周期管理、编排发布的能力,对应到阿里云有定义边缘CRD operator EdgeWorkload提供能力,定义OAM编排扩展能力。面向平台管理员,像多集群管理,租户隔离,元数据管理等也是在边缘海量用户海量数据场景下也需要相应的能力定制。另外边缘存在大量分布式异构资源,如何最大化利用资源,需要依赖于全局的容器调度器结合业务相关的全局流量调度分发策略。弹性伸缩HPA/VPA的场景也是面向边缘分布式的解决方案。

    阿里云拥有遍布全球各地的资源,需要对异构资源纳管模块定义分区域的规划策略,进行规划接入,围绕中心管控+边缘自治+多重缓存的方式进行展开。

    考虑边缘云的架构复杂度、海量节点数量、异构资源差异性等因素,阿里云通过不断完善系统可观测性和强化Devops运维建设能力,来提升系统稳定性。

    同时,阿里云边缘云原生具有异构融合广覆盖、云边体验一致性、标准云原生兼容、算力全域流动性等技术优势。

    典型边缘云业务应用
    image.png

    早期CDN节点架构主要是按照资源进行规划部署,2台LVS+小于4台管控机器,剩下都是缓存机器,属于规划先行的部署模式,资源闲置较多,并且也造成建设成本的浪费。在全面推进CDN ON ENS边缘融合计算可以极大提升资源利用效率。

    智能终端上云,是未来IoT设备大规模接入很重要的场景,涉及到典型的边缘全局容器调度和流量调度的协同。中心管控会事先根据预估的用户规模申请资源,接入集群,并将容器部署在边缘节点上,在用户请求建连时,根据预定义的流量调度策略,从中心管控获取边缘闲置容器,将用户设备和服务端容器进行绑定。当用户断连时,销毁重建新的容器供后续其它业务使用,避免数据泄漏。中心管控会实时的根据并发请求情况等核心指标进行动态的容器扩缩容。

    中心下沉业务,中心具备规模化Region的数量是比较有限的,当客户对延迟非常敏感,首选是在就近边缘节点进行服务的部署和处理客户请求。为保证云边一致体验,业务中控系统需要同时获取中心和边缘的服务数据,再根据用户请求进行流量分发。这样既可以降低对于中心带宽成本和资源的压力,又可以提升用户体验。

    最后, 江岑表示,阿里云边缘云原生技术将不断完善调度、资源、协同等方面能力,面向行业客户以及合作伙伴提供最佳云原生应用体验,共同打造边缘云创新应用。

    原文链接
    本文为阿里云原创内容,未经允许不得转载。

    展开全文
  • 原生的搬运

    2021-01-30 01:14:45
    特别指出:这次分享主要是希望起到抛砖引玉的作用,让大家更多的参与到云原生这个话题的讨论,希望后面有更多更好的分享。我们笨鸟先飞,起一个头。 内容主要围绕这几个问题,上半场我们将围绕前三个问题。 如何...

    内容来自蚂蚁金服中间件服务与容器团队

    前言

    img

    特别指出:这次分享主要是希望起到抛砖引玉的作用,让大家更多的参与到云原生这个话题的讨论,希望后面有更多更好的分享。我们笨鸟先飞,起一个头。

    img

    内容主要围绕这几个问题,上半场我们将围绕前三个问题。

    如何理解云原生?

    第一个话题:如何理解“云原生”?之所以将这个话题放在前面,是因为,这是对云原生概念的最基本的理解,而这会直接影响到后续的所有认知。

    每个人对云原生的理解都可能不同,就如莎士比亚所说:一千个人眼中有一千个哈姆雷特。

    img

    我们来快速回顾一下云原生这个词汇在近年来定义的变化。

    img

    先看 Pivotal,云原生的提出者,是如何定义云原生的。

    img

    这是 2015 年,云原生刚刚开始推广时,Matt Stine 给出的定义。

    img

    两年之后,同样是 Matt Stine。

    img

    而这是 Pivotal 最新官方网站的描述。可见 Pivotal 对云原生的定义一直在变。

    img

    再来看看目前云原生背后最大的推手,CNCF,这是 2015 年 CNCF 刚成立时对云原生的定义。

    img

    2018 年 CNCF 更新了云原生的定义。

    img

    这是新定义中描述的代表技术,其中容器和微服务两项在不同时期的不同定义中都有出现,而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来,和微服务并列,而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。

    img

    云原生自身的定义一直在变,这让我们该如何才能准确的理解云原生呢?

    img

    这里我们尝试,将 Cloud Native 这个词汇拆开来理解,先看看什么是 Cloud。

    img

    快速回顾一下云计算的历史,来帮助我们对云有个更感性的认识。

    img

    云计算的出现和虚拟化技术的发展和成熟密切相关,2000 年前后 x86 的虚拟机技术成熟后,云计算逐渐发展起来。

    img

    基于虚拟机技术,陆续出现了 IaaS/PaaS/FaaS 等形态,以及他们的开源版本。

    img

    2013 年 docker 出现,容器技术成熟,然后围绕容器编排一场大战,最后在 2017 年底,kubernetes 胜出。2015 年 CNCF 成立,并在近年形成了 cloud native 生态。

    img

    这是云的形态变化,可以看到:供应商提供的功能越来越多,而客户或者说应用需要自己管理的功能越来越少。

    img

    当云发生如此之大的变化时,云上的应用要如何适应?

    img

    在回顾完云计算的历史之后,我们对 Cloud 有更深的认识,接着继续看一下:什么是 Native?

    img

    这是从字典中摘抄下来的对 Native 词条的解释,注意其中标红的关键字。

    img

    Native,总是和关键字 Born 联系在一起。

    img

    那 Cloud 和 native 和在一起,又该如何理解?

    img

    这里我们抛出一个我们自己的理解:云原生代表着原生为云设计。详细的解释是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。

    这个理解有点空泛,但是考虑到云原生的定义和特征在这些年间不停的变化,以及完全可以预料到的在未来的必然变化,我觉得,对云原生的理解似乎也只能回到云原生的出发点,而不是如何具体实现。

    云原生应用应该是什么样子?

    img

    那在这么一个云原生理解的背景下,我再来介绍一下我对云原生应用的设想,也就是我觉得云原生应用应该是什么样子。

    img

    在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。

    然后应用将这些功能,连同自身的业务实现代码,一起打包。

    img

    这是传统非云原生应用的一个形象表示:在业务需求的代码实现之后,包裹厚厚的一层非业务需求的实现(当然以类库和框架的形式出现时代码量没这么夸张)。

    img

    而云的出现,可以在提供各种资源之外,还提供各种能力,从而帮助应用,使得应用可以专注于业务需求的实现。

    img

    在我们设想中,理想的云原生应用应该是这个样子:业务需求的实现占主体,只有少量的非业务需求相关的功能。

    img

    非业务需求相关的功能都被移到云,或者说基础设施中去了,以及下沉到基础设施的中间件。

    img

    以服务间通讯为例:需要实现上面列举的各种功能。

    img

    SDK 的思路:通过一个胖客户端,在这个客户端中实现各种功能。

    img

    Service Mesh 的思路,体现在将 SDK 客户端的功能剥离出来,放到 Sidecar 中。

    img

    通过这种方式,实现应用的轻量化。此时绝大部分的功能都在剥离,应用中只留下一个轻量级的客户端。这个轻量级客户端中还保留有少数功能和信息,比如目标服务的标识(指出要调用的目标),序列化的实现。

    这里特别指出,有一个功能是我们努力尝试但是始终没有找到办法的:业务动态配置的客户端。也就是如何获取和应用业务逻辑实现相关的动态配置信息。如果有哪位同学对此有研究,希望可以指教。

    img

    我们的想法,云原生应用应该超轻量化的方向努力,尽量将业务需求之外的功能剥离出来。当然要实现理想中的状态还是比较难的,但是及时是比较务实的形态,也能比非云原生下要轻量很多。

    img

    在这里举一个效果比较理想的实际案例,在 service mesh 中实现密文通讯。

    由于客户端和服务器端两个 sidecar 的存在,因此我们可以通过 Sidecar 之间的协商与合作分别实现加密和解密,从而实现远程通讯的密文传输,而这个加密和解密的过程对于原有应用是透明的。

    云原生下的中间件该如何发展?

    img

    云原生涉及到的面非常广,对开发测试运维都会有影响,我们这里将聚焦在中间件,给出我们的一些粗浅的想法,因为我们来自中间件部门。大家也可以将中间件自行替换为自己关心的领域,尝试思考一下这个问题。

    img

    前面我们讲到云原生应用的理想形态和轻量化方向,这里隐含了一个前提:不管云原生应用的形态如何变化,云原生应用最终对外提供的功能应该是保持一致的。

    img

    而要实现这一点,应用需要依赖于云提供的能力,来替换因应用轻量化而剥离的原有能力,云提供的能力是应用形态演变的基础和前提。

    img

    理想状态下,我们期望云能够提供应用需要的所有能力,这样应用就可以以最原生化的形态出现。但是现实是这一点远还没有做到,我们依然需要在云之外额外提供一些功能,比如原有中间件的功能。

    img

    在云原生之前,中间件的做法通常是以类库和框架的形式出现,近年来也有服务形式。而在云原生时代,我们的想法是让中间件下沉到基础设施,成为云的一部分。

    img

    在这里解释一下,在前面就提到了“下沉”,什么是下沉?

    img

    我们的想法是:云原生下的中间件,功能应该继续提供,但是中间件给应用的赋能方式,应该云原生化:

    • 在云原生之前,应用需要实现非常多的能力,即使是以通过类库和框架的方式简化,其思路是加强应用能力,方式如左图所示,通过提供更大更厚的衣物来实现御寒御寒能力。
    • 云原生则是另外的思路,主张加强和改善应用运行环境(即云)来帮助应用,如右图所示,通过提供温暖的阳光,来让轻量化成为可能。

    img

    我们以 Service Mesh 模式为例来详细讲解,首先我们以白盒的视角来看 Service Mesh 的工作原理:

    1. 以原生模式开发应用:应用只需具备最基本的能力,如客户端简单发一个请求给服务器端
    2. 部署时动态插入 Sidecar:当我们将开发的云原生应用部署到云上,具体说是部署在 k8s 的 pod 中时,我们会自动在 pod 中再部署一个 Sidecar,用于实现为应用赋能
    3. 在运行时,我们会改变云原生应用的行为:如前面所说客户端简单发一个请求给服务器端,在这里会被改变为将请求劫持到 Sidecar,注意这个改变对应用而言是透明无感知的
    4. 在 Sidecar 中实现各种功能:Sidecar 里面就可以实现原有 SDK 客户端实现的各种功能,如服务发现,负载均衡,路由等等
    5. Sidecar 在实现这些功能时,可以对接更多的基础设施,也可以对接其他的中间件产品,这种情况下,Service Mesh 产品会成为应用和基础设施/中间件之间的桥梁
    6. 可以通过控制平面来控制 Sidecar 的行为,而这些控制可以独立于应用之外

    img

    我们再以应用的视角,将云和下沉到云中的 Service Mesh 产品视为黑盒,来看 Service Mesh 模式:

    1. 以原生模式开发应用
    2. 以标准模式部署应用:底下发生了什么不关心
    3. 客户端简单发一个请求给服务器端:底下是如何实现的同样不关心,应用只知道请求最终顺利发送完成

    Service Mesh 产品的存在和具体工作模式,对于运行于其上的云原生应用来说是透明无感知的,但是在运行时这些能力都动态赋能给了应用,从而帮助应用在轻量化的同时依然可以继续提供原有的功能。

    img

    Mesh 模式不仅仅可以用于服务间通讯,也可以应用于更多的场景:

    • Database mesh:用于数据库访问
    • Message mesh:用于消息系统

    img

    中间件下沉到基础设施的方式,不只是有 Mesh 模式一种,而且也不是每个中间件都需要改造为 Mesh 模式,比如前面我们提到有些中间件是可以通过与 Mesh 集成的方式来间接为应用提供能力,典型如监控,日志,追踪等。

    我们也在探索 mesh 模式之外的更多模式,比如 DNS 模式,目前还在探索中。

    简单归纳一下我们目前总结的云原生赋能(Cloud Empower)的基本工作原理:

    • 首先要将功能实现从应用中剥离出来:这是应用轻量化的前提和基础
    • 然后在运行时为应用 动态赋能:给应用的赋能方式也要云原生化,要求在运行时动态提供能力,而应用无感知

    云和应用该如何衔接?

    img

    下半场的第一个话题:云和应用该如何衔接?

    img

    应用和云之间是需要密切配合的。

    • 对于非云原生场景,由于云正提供非常有限的能力,因此应用需要自行实现各种能力,包括通过类库/框架的形式。
    • 务实版本的云原生方案下,云可以提供大部分的能力,因此应用可以大幅减负,和非云原生相比在轻量化方面可以有明显的改观。但是依然存在部分能力云无法提供,因此应用还是需要自行实现部分能力。
    • 比较理想的云原生,是希望云能够提供绝大部分的能力,只是在某些特定环节无法完全剥离和解耦,但是此时应用的轻量化已经达到了非常高的水准。
    • 当然,理论上的最终目标,梦想中的云原生,应该是云提供所有能力,而且所有的环节都可以完全解耦,此时应用的轻量化可以做到极致,完全依赖云提供的能力。
    • 整个演进过程中的哲学就是:将复杂留给云,将简单留给应用。

    img

    但是,这里需要先强调一下,云原生的演进过程,不仅仅需要云的努力,也需要应用作配合。否则,即便云已经可以提供各种能力,但是如果应用本身没有进行轻量化改造,未能使用云提供的能力,而是继续保持原有的非云原生的形态,那么效果就会大打折扣。

    img

    回顾上半场的第一个话题“如何理解云原生”:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。这里强调的是,应用需要以原生形态来设计,以充分发挥云的优势。

    然后回到我们的话题,假设现在云已经准备妥当,各种能力都可以提供,而应用也按照云原生的理念设计,那当云原生应用部署在云上时,这些应用和云之间应该如何衔接?既可以让应用使用云提供的能力,又不至于侵入应用,破坏应用的云原生特性?简单说,就是要实现应用无感知。

    img

    首先涉及到的就是赋能方式:即当云(包括下沉到云中的中间件)可以为应用提供各种能力时,这些能力又如何赋予应用呢?

    为了满足应用轻量化的需求,不应在编译打包等阶段引入这些能力,以保持应用的云原生特性。因此,我们的目标是:应该在运行时为应用 动态赋能。这样可以让应用在开发设计阶段保持简单和专注业务,在部署运行于云上之时再通过赋予的这些能力来对外提供服务。

    这个想法自然是非常理想化的,所以问题就来了:如何实现 动态赋能?

    img

    流量透明劫持 是我们目前比较认可的动态赋能方式之一,在上半场谈到 Service Mesh 模式的工作原理时,讲到当我们讲应用部署在 Service Mesh 中时,我们会在部署时动态的在应用所在的 pod 中插入 Sidecar 容器,然后在运行时,会以对用户透明的方式来改变应用的行为。典型如将应用发出的服务间远程调用的请求,改为转向本地部署的 Sidecar,从而引入 Service Mesh 能提供的各种能力。

    这个在运行时透明的改变远程调用请求的行为,我们称之为 “流量透明劫持”。

    img

    透明劫持的部署模式如上图所示,右边图片是应用容器与 Sidecar 容器在 k8s/Sigma 中的部署模式,左边图片是单个 pod 的放大。其中绿色方块为应用容器,蓝色方块为 Sidecar 容器,蓝色线条表示服务间通讯。

    img

    透明劫持的具体工作流程是这样,我们以 iptables 流量劫持方案为例:

    • Init 流程(编号为 0 的两条紫色虚线):在 Pod 启动时,通过 Init Container 特权容器,开启流量劫持并设置流量劫持规则(分为 Inbound 规则和 Outbound 规则)。注意这个流程时部署时进行,因为不是真实请求流量所以用的虚线表示。
    • Inbound 流程(左边编号为 1,2,3 的黄色实现):Inbound 请求,被 traffic interception 劫持,根据 Inbound 规则请求被转发到 Sidecar,然后 Sidecar 再转发给应用。这是用于劫持 Inbound 流量,也就是外部访问当前应用的流量,使之在通过 Sidecar 再由 Sidecar 转发给应用。
    • Outbound 流程(右边编号为 4,5,6 的黑色实现):应用发出的 Outbound 请求会被 traffic interception 劫持,根据 Outbound 规则请求被转发给 Sidecar,然后 Sidecar 处理之后将请求发送给目的地。这是用于劫持 Outbound 流量,也就是当前应用访问外部服务的流量,使之先通过 Sidecar,然后由 sidecar 进行转发。

    通过上述三个流程,我们就实现了让应用的 Inbound 请求和 Outbound 请求在运行时改变行为方式,在应用无感知的情况下实现了将流量劫持到 Sidecar 中。然后我们在 Sidecar 中就有机会为当前请求赋予各种能力,典型如服务发现/负载均衡/实施各种路由策略/认证/加密等一系列能力,从而实现了对应用的动态赋能。

    img

    当前流量透明劫持的技术实现方案有多种,其优缺点如图所示。

    透明劫持的最大优点是对代码无侵入:

    • 业务应用在开始时无需关注各种功能的实现细节和调用方式,也不需要依赖 SDK,这些能力会在运行时动态赋予
    • 对于已有的应用,旧有代码可以无需改动就直接运行在 service mesh 上
    • 从而避免修改代码,和相关的重新打包发布上线等复杂流程
    • 另外透明劫持支持直连(不经过 sidecar)/单跳(只经过一个 Sidecar)/双跳(经过两个 Sidecar),方便开发调试,容易实现和现有系统的兼容

    透明劫持近乎完美的实现了我们要求的目标:在运行时为应用 动态赋能,应用无感知。

    另外透明劫持还有一个比较隐蔽但是又非常关键的优点:不丢失重要信息。这指的是在透明劫持模式下,请求的原始目标地址和端口信息(original_dest)得以保留,让应用可以工作在特定协议应该绑定的端口上,从而更符合 12 factor 中”Port Binding”的要求,关于这一点的细节,可以见最后的花絮部分。

    由于原始目标地址和端口信息(original_dest)得以保留,因此透明劫持容许服务在多个端口上绑定多个不同协议而 Sidecar 只需要一个端口就可以实现流量转发。

    img

    流量透明劫持的重要使用场景之一就是实现平滑迁移,即从现有的体系向 service mesh 体系逐渐迁移。

    图中时典型的服务注册/服务发现机制:应用向注册中心注册,然后客户端在发起请求时通过服务发现获得目标服务的地址列表,再选择其中的某个地址发出请求。

    img

    当我们将其中的一个应用 (如图中的 Servcie B) 迁移到 Service Mesh 中,此时会和 Service B 一起部署 Sidecar 并设置流量劫持的规则。当 Service B 作为服务器端接收客户端请求时的,原有请求 Service B 的流量就会被劫持到 Sidecar。此时 Service A 和 Service B 都对此无感知。

    img

    当 Service B 作为客户端对外发起请求时,请求会被流量劫持到 Sidecar,然后 Sidecar 再转发请求。同样,图中的 Service B 和 Service C 对此也是没有感知。

    img

    当客户端和服务器端的应用都迁移到 service mesh 之后,此时两端都部署有 Sidecar,请求会按照 service mesh 的标准方式在客户端和服务器端都做两次透明劫持进入 Sidecar。依然,两端的服务对此无感知。

    img

    透明劫持对于现有系统的升级非常有帮助,主要体现在为升级带来的弹性。如图所示:

    • 当客户端和服务器端都没有进行升级时,应用是直接连接的
    • 当客户端接入 service mesh 时,客户端会有改造,有 Sidecar 和透明劫持,因此客户端会有一次流量劫持,再往服务器端发送请求时,由于服务器端没有改造,因此服务器端是继续沿用原有方式直接连接。此时流量只经过一次 sidecar,我们称为“单跳”,客户端单跳。
    • 类似的,如果客户端没有改造,而服务器端有改造,则客户端工作方式不变而服务器端会有一次流量劫持,这也是单跳,服务器端单跳。
    • 当客户端和服务器端都改造完成时,在客户端和服务器端会有两次流量劫持,称为双跳。

    由于迁移的全过程都做到了对应用透明,因此在迁移过程中可以非常有弹性的安排应用的升级工作,包括个别应用升级失败时的回退。

    img

    前面我们详细介绍流量透明劫持这种动态赋能的方式,下面我们继续介绍另外一种常见的动态赋能方式,DNS。

    在上半场我们介绍 Service Mesh 的思路时,我们提到在让应用轻量化的过程中,最终在应用里面还是会有一个轻量级的客户端,里面保留有少数功能和信息。这其中就有“目标服务标识”这一项,用于标识当前请求要发送的目标服务。

    而在此时,有一个很常见的方式就是用域名来做标识符,从而让客户端可以发起一次 DNS 解析请求到 DNS 服务器。而我们可以通过各种方式在 DNS 服务器中预设 DNS 信息,比如最中间的方式就是和服务注册中心拉通,通过某种方式将服务注册信息中的服务域名和 IP 地址信息(典型如 k8s 中使用 ClusterIP)导入到 DNS 服务器中。

    通过这样一个方式,就可以实现通过操作 DNS 记录来控制 DNS 解析的结果,从而实现特定目的。而将数据拉到到 DNS 服务器的方式可以有多种,域名和 DNS 记录信息的使用方式也可以有很多,配合流量透明劫持,Sidecar 也是可以获知这个请求的 DNS 解析结果…… 这里就有很多的想象空间了。

    img

    具体 DNS 赋能的典型例子,在 SOFAMesh 项目中,为了兼容现有的单进程多接口的应用,而且容许客户端代码继续维持原有的用接口名而不是应用名来进行访问,我们就是利用了 DNS。

    如图,我们通过打通服务注册环节,在服务注册时获取到当前应用所提供的接口,然后将这些接口和应用的 ClusterIP 添加为 DNS 记录,使得这些接口名称对应的域名都指向 cluster ip。然后在请求过程中,客户端会通过接口名进行 DNS 解析,获取 cluster ip,接着以 cluster ip 为目标地址发出请求,然后被透明流量劫持进 Sidecar,sidecar 从请求的原始目标地址中获取到 cluster ip,就可以得到请求的目标服务,从而可以开始后面的各种流程。

    在这一过程中,我们组合使用了服务注册 + DNS 信息同步 + 流量透明劫持 + Sidecar 逻辑处理,比较好的实现了对旧有应用的兼容。

    img

    在介绍动态赋能方式之后,我们再来继续看应用和云衔接的另外一个话题:在应用被赋予能力之后,应用该如何控制这些能力?

    控制的方式通常有两种:命令式和声明式。

    对于对于我们云原生的场景而言,有些微妙:这些能力时动态赋予应用的,应用根本无法直接控制这些能力的具体实现,而且从云原生的理念上可说,应用也不应该知道这些来自云的能力的具体实现方式,因此,在动态赋能的场景下,命令式是不合适。

    应用能为此做什么?应用肯定知道自己要达到的控制目标,即应用期待的目标状态。比如,应用可以要求说,当我访问某个服务时:

    • 要用轮询的负载均衡算法
    • 要 10%的流量去 v2 版本,其他的去 v1 版本
    • 要开启链路加密
    • 要……

    虽然这些能力会如何实现应用不清楚也无法直接控制,但是给出这些要求应用还是可以做到的。因此,声明式非常符合动态赋能场景下的控制需求。

    使用 声明式 API 的好处在于:

    • 简单:应用不需要关心实现细节,这些能力的具体的实现方式/流程/细节都是能力提供方内部完成。而且这些能力隐藏在云下,对应用是透明的,在运行时才动态赋予,应用完全可以简单实用这些能力而无需关注其他。
    • 自描述:声明描述的就是应用期望的目标状态

    img

    声明式 API 的哲学:把方便留给别人,把麻烦留给自己。

    img

    关于云和应用如何衔接这个话题,目前我们能给出的方案还不多,远谈不上理想,期望能够在未来会找到有更多更好的做法。对此有兴趣的同学,非常欢迎一起探讨这个话题,如果有好的想法和方式,欢迎随时指教。

    如何让产品更符合云原生?

    img

    下半场的第二个话题:如何让产品更符合云原生?。

    注意这里要说的是产品,而不是应用。如何让应用更符合云原生有足够多的文章和理论了,但是如何提供一个产品,让这个产品为云原生应用提供服务和支持,然后要让这个产品本身更符合云原生,能找到的资料就不多了。

    img

    我们先总结一下从前面内容中得到的一些规律:其核心在于,不仅提供功能,更强调体验:

    • 在讨论云原生应用应该是一个什么样子时提出,云原生应用就应该是原生形态,轻量化:云应该让应用更舒服
    • 在回顾云计算历史,探讨云的形态变化时,我们给出了中间这个图表:云应该让应用少做事
    • 刚刚探讨的声明式 API 的哲学,把方便留给别人,把麻烦留给自己:云应该让应用更方便。

    那么,当我们在云上开发产品,试图将产品的能力融合进云,让云上应用可以自如的使用这些能力时,应该遵循什么样的方式?

    img

    在这里,我们介绍一个云原生的飞轮理论,其创意由我们团队的 典韦 同学,参考了亚马逊的飞轮理论。

    亚马逊的飞轮理论相信大家都很熟悉,在这里亚马逊努力打造了两个飞轮,即闭环循环,通过“选品与便利”和“更低价格”实现了更好的“客户体验”。

    img

    详细介绍一下云原生的飞轮理论。首先,在云计算和云原生出现之前,下面的这个大循环其实就已经存在了。这个循环主要关注的是功能性方面的需求,提供商的产品主要通过提供功能来满足客户需求,当然不是说没有功能性之外的其他需求,只是在早期对非功能性的需求远没有今天这么多。

    img

    进入互联网时代,尤其是移动互联网时代之后,这个大循环面临新的挑战,一方面在功能性方面要求越来越高:除了简单功能实现之外,还有对性能/安全/稳定性/高可用/可扩展性的诸多要求,而且越来越苛刻。

    img

    另一个方面,在功能性之外,更多的需求来自对效率的追求:包括开发、测试、部署、维护、变更的效率,以及对成本的要求。

    img

    对效率的追求,推动了云计算的产生和发展,以及云原生理念和架构的产生,我们熟知的容器技术,微服务架构,以及新生的 Service Mesh 架构都由此诞生,不可变基础设施和声明式 API 的理念也在实践中被总结出来,并为后续的云原生架构提供理论指导。

    img

    云计算的发展,云原生的推出,为云和云上产品带来了功能性之外的一个重要特征:易用性。体现在有了云的支撑之后,云上应用可以简单开发,开发人员容易上手,由于大部分维护工作由云承担,因此降低了客户的维护工作量(甚至 serverless 提出了无维护的理念)。这些产品使用简单,对客户心智要求低,无需客户具体相关的专业知识。

    其核心在于分离关注点:客户和客户应用应该关注与业务实现,而非业务实现的内容应该由云和云上产品提供。

    img

    而易用性的飞跃,在满足各种功能性的前提下,不仅仅满足了客户需求,也极大的改善了开发体验。在开发、测试、部署、维护、变更等环节的效率提升,也帮助用户控制了成本。

    img

    这样,围绕易用性,新的闭环循环产生:对效率的追求,催生了云和云原生架构,带来了易用性的提升,改善了开发体验,从而进一步提供了效率。这个环形的过程会持续发生,云原生架构就会沿着这个飞轮循环不断的发展演进。在过去几年间,这个飞轮循环已经在运转,云原生架构中的容器/微服务等架构都是在这个循环中不断完善和普及。

    img

    这是完整的云原生架构飞轮理论,两个飞轮分别关注功能性和易用性,两者结合来满足客户需求,改善开发体验,最终实现云原生架构的良性循环。

    img

    为了更好的理解云原生的飞轮理论,我们以云计算中至关重要的虚拟化技术为例,看看这二十年间以虚拟化技术为基础,云和云原生架构是如何一步一步演进和发展的。

    首先,在物理机时代,在虚拟化技术出来之前,提供商只能提供服务器托管/服务器租用以及基于 web 服务器的虚拟主机服务,此时云还不存在。

    img

    在 2000 年前后,出于对资源利用率的追求,在虚拟机技术成熟之后,基于虚拟机技术首先诞生了 VPS,然后陆续出现了大家熟悉的 VMWare/Xen/KVM/VirtalBox 等技术和产品,云计算开始出现。

    之后围绕易用性,先是 amazon 推出 s3 和 EC2,IaaS 出现;后面 HeroKu 推出了 PaaS。此时云已经走向成熟,而云原生架构也出现了早期形态,比如 HeroKu 提出的 12 factor 应用,DevOps 的流行。后面陆续出现了其他 Xaas 形态:SaaS/FaaS 等。

    此时的开发体验和物理机时代相比已经有质的飞跃。

    img

    2013 年前后,以 docker 为标志的容器技术开始成熟,催生了容器编排、不可变基础设施等技术和理念。而容器这种轻量化虚拟计划的出现也极大的促进了微服务架构等的演进,2015 年前后,云原生架构被正式提出。而之前基于虚拟机技术的 XaaS 也开始向容器化方向转变。

    img

    随着 kubernetes 完成了对容器编排市场的统一,云和云原生架构进入 kubernetes 时代,虽然底层虚拟化技术依然是虚拟机和容器,但是上层的 XaaS 形态已经开始陆陆续续开始向 k8s 转型。此时 k8s 奉行的声明式 API 等理念也成为云原生架构的指导思想之一。

    img

    最近安全容器技术发展迅速,预期未来一旦技术成熟,很可能会带来新一轮的变革,未来的云和 XaaS 会可能会转为基于安全容器,也许还会有新的未知的形态出现,值得期待。

    从上述演进过程可以看到,随着虚拟化技术的一步一步演进,飞轮的一次一次循环,云开始诞生,XaaS 形态开始出现,各种技术和理念相继诞生并日益完善,云原生架构出现并开始成熟,新的理念和架构出现/实践/改进,整个云原生架构就这样在一次一次的飞轮循环中走向成熟。

    img

    以云原生飞轮理论为基础和指导,分享一些我们团队在设计云原生产品的一点点心得:

    • 首先,在关注功能/性能之外,应该更多的关注易用性,关注开发者的体验,要将应用和应用开发者当成 bady 来呵护,努力让产品的使用者可以更舒适更简单的使用产品
    • 产品应该依托云原生架构,具体说,就是应该基于云,基于容器,基于 kubernetes。其核心观点在于,要让产品表现的更符合云原生,产品本身就应该是云原生的。
    • 顺势而为,要顺着飞轮的方向,迎合云原生的理念,迎合社区的发展方向。不要逆势而为,不要试图挑战整个社区。

    img

    Kubernetes 是云原生的关键所在,怎么强调都不为过。这里有一个被越来越多人认可的说法:

    Kubernetes 是云原生时代的 Linux

    对这句话,我们有两个认识,在这里分享一下:

    • 应该以 kubernetes 为底座进行能力建设:简单说就是如果是 kubernetes 已有的能力则直接使用,如果 k8s 的能力不足,则在 kubernetes 上做改进和争强,充分利用 k8s 的能力,而不是选择无视。
    • 把 kubernetes 当 kubernetes 用:即要符合 kubernetes 的理念和设计,遵循 kubernetes 的游戏规则

    谈到遵循 kubernetes 的游戏规则,我们深入一下,核心在于遵循 kubernetes 的 CRD + Controller 模型:

    • 如果 k8s 底座的能力不够:则应该去补充和加强 k8s 的能力,体现为实现新的 Controller
    • 如果 k8s 的抽象不够:比如说对于某些复杂场景,现有 CRD 不适用或不够用,则应该定义新的抽象,体现为添加新的 CRD

    两者结合起来,加固 k8s 底座(Controller)+ 扩展 k8s 抽象(CRD),就可以得到新的云原生基础设施。

    另外,重要的事情说三遍:声明式 API,声明式 API,声明式 API!

    img

    举几个用 CRD 做扩展的例子,典型如 Istio。

    img

    还有 Google 新推出的 serverless 项目 knative。

    img

    在通过以 加固 k8s 底座(Controller)+ 扩展 k8s 抽象(CRD)的方式打造新的云原生基础设施后,再在这些云原生基础设施的基础上,生长新的云原生产品。

    img

    这里给出一个利用 k8s 能力的例子:Knative 的 Autoscaler 的实现。

    img

    尽量遵循标准,尽量和社区一起玩:一方面可以从社区借力,跟随社区一起成长;另一方面,在产品对外输出时也容易被社区接受。

    img

    最后再次强调一点:尽量不要逆势而为,尽量顺着云原生飞轮转动的方向。

    小结:

    关于如何让产品更符合云原生这个话题,我们这次只带来了一些比较基础的想法,由于在云原生这个领域我们也还处于摸索阶段,所以目前的看法和想法可能都还不够成熟。而且,更具体更深入的建议应该结合实际产品讲,但是本次分享中不太适合再进一步深入展开了,希望后面会有机会。

    此外,受工作范围限制,我们专注的领域偏中间件和服务间通讯,对于其他产品领域,期望后续有其他同学带来更深入分享。这也是我们本次分享的重要目的:抛砖引玉。

    花絮:有哪些有趣的角色转变?

    img

    在本次分享的最后是花絮内容,我们轻松一下,来看看在云原生的演进过程中,有哪些有趣的角色转变?

    img

    这里所说的角色,指的是一个云计算中的口头禅或者说典故,通常在英文资料中经常看到:Pets VS. Cattle。

    宠物或者奶牛,为了表述的更形象一些,我喜欢翻译为宠物或者牲口。

    img

    这里有个问题:在云原生时代,有哪些概念发生了角色转变?大家有兴趣可以试试回答一下。

    我这里给出两个回答,一个是 IP 地址,从宠物到牲口;另一个是 端口/port,从牲口到宠物。

    img

    IP 地址在云原生时代,从宠物到牲口,基本大家都比较认可了。

    img

    而端口/port,从云原生之前的牲口,转变为云原生之后的宠物,则还存在比较大的争议。这里列出当牲口和当宠物的两个不同的端口使用方式。

    img

    视端口为宠物的一个重要理论依据,来自 12 Factor 中的 Port Binding 原则。实践中很多产品,包括 Envoy / Istio 等都遵循这一原则。在我们的 SOFAMesh 产品中,我们也同样遵循这一原则。

    当然这个花絮的主要目的,还是希望可以借这个话题,让大家有个心理准备:在云原生之后,可能会有些之前理所当然的理念会发生变化。因此,请保持良好的心态 😃

    总结

    在最后,再一次强调,这次云原生分享是希望起到一个抛砖引玉的作用,期待后面会有更多同学出来就云原生这个话题进行更多的分享和讨论。我们团队目前在云原生这条全新的道路上努力的探索,但是云原生应该如何进行,这是一个非常大的话题,希望有更多的人一起来参与,一起来讨论,一起来交流。

    带来更深入分享。这也是我们本次分享的重要目的:抛砖引玉。

    展开全文
  • 原生是什么?细数云原生的5大特征00 云原生是什么?01 轻、快、不变的基础设施02 弹性服务编排03 开发运营一体化04 微服务架构05 无服务模型 来源:大数据DT 导读:随着公有云和私有云的广泛部署,云计算基础...

    来源:大数据DT

    导读:随着公有云和私有云的广泛部署,云计算基础设施成为企业部署新业务的首选。可以说,云计算已进入下半场,各大云计算服务商的厮杀日益激烈,新的概念也层出不穷。

    近年来,云原生计算(Cloud Native Computing)越来越多地出现在人们的视野中,可以说云原生是云计算时代的下半场,或许我们可以称之为云计算2.0。云原生的出现是云计算不断与具体业务场景融合,与开发运营一体化碰撞的结果,是一场由业务驱动的对云端基础设施、编排体系的重构。

    00 云原生是什么?

    近年来,云计算模式逐渐被业界认可和接受。在国内,包括政府、金融、通信、能源在内的众多领域的大型机构和企业,以及中小企业,均对其托管业务的基础设施进行了不同程度的云化。

    但它们大多数利用开源或商业的IaaS系统构建云计算平台,只是简单地将传统物理主机、平台或应用转为虚拟化形态。这种方式所带来的好处是整体资源的利用更加合理,且集约式的运营会降低成本,提升整体运营效率和成熟度。但总体而言,这样的上云实践只是“形”上的改变,还远没有达到“神”上的变化。

    在云计算的下半场,应该充分利用云计算弹性、敏捷、资源池和服务化等特性,解决业务在开发、运行整个生命周期中遇到的问题。毕竟,业务中出现的问题才是真正的问题。

    比如,传统应用有升级缓慢、架构臃肿、无法快速迭代等问题,于是云原生的概念应运而生。笔者认为云原生就是云计算的下半场,谁赢得云原生的赛道,谁才真正赢得了云计算。

    谈到云原生,不能不提始终推动云原生发展的CNCF(Cloud Native Computing Foundation,云原生计算基金会)。CNCF是一个孵化、运营云原生生态的中立组织。截止到2020年,CNCF共有371个开源项目、1402个项目和组织,可以说是一个覆盖面相当广的云计算组织。

    CNCF对云原生的见解是:

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

    云原生提倡应用的敏捷、可靠、高弹性、易扩展以及持续更新 。在云原生应用和服务平台的构建过程中,近年兴起的容器技术凭借其高弹性、敏捷的特性以及活跃、强大的社区支持,成为云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端应用的设计、开发和运行,从而重构云上业务模式。

    不同于以虚拟化为基础的传统云计算系统,云原生系统一般有如下特征。

    01 轻、快、不变的基础设施

    在云原生环境中,支撑基础设施通常是容器技术。容器生命周期极短,大部分是以秒或分钟为单位,占用的资源也比虚拟化小得多,所以容器的最大特点就是轻和快。

    而正是因为容器有轻和快的特点,在实践中通常不会在容器中安装或更新应用,而是更新更为持久化的镜像,通过编排系统下载新镜像并启动相应的容器,并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变的基础设施(immutable infrastructure)。从不变的基础设施就能看出,云原生的运营与传统虚拟机运营方式截然不同。
    在这里插入图片描述

    02 弹性服务编排

    云原生的焦点是业务,而非基础设施,而业务的最核心之处是业务管理和控制,如服务暴露、负载均衡、应用更新、应用扩容、灰度发布等。服务编排(orchestration) 提供了分布式的计算、存储和网络资源管理功能,可以按需、弹性地控制服务的位置、容量、版本,监控并保证业务的可访问性。

    服务编排对应用层隐藏了底层基础设施的细节,但又提供了强大的业务支撑能力,以及让业务正常运行的容错、扩容、升级的能力,使开发者可以聚焦业务本身的逻辑。

    03 开发运营一体化

    开发运营一体化(DevOps) 是一组将软件开发和IT运营相结合的实践,目标在于缩短软件开发周期,并提供高质量软件的持续交付。虽然DevOps不等同于敏捷开发,但它是敏捷开发的有益补充,很多DevOps的开发理念(如自动化构建和测试、持续集成和持续交付等)来自敏捷开发。

    与敏捷开发不同的是,DevOps更多的是在消除开发和运营侧的隔阂,聚焦于加速软件部署。

    当前,很多云原生应用的业务逻辑需要及时调整,功能需要快速丰富和完善,云端软件快速迭代,云应用开发后需要快速交付部署,因而开发运营一体化深深地融入云原生应用整个生命周期中。
    在这里插入图片描述

    04 微服务架构

    传统Web应用通常为单体应用系统,如使用WebSphere、WebLogic或.Net Framework等,从前端到中间件再到后端,各个组件一般集中式地部署在服务器上。

    后来随着Web Service标准的推出,应用以标准的服务交付,应用间通过远程服务调用(RPC)进行交互,形成了面向服务的架构(Service-Oriented Architecture,SOA),极大提升了应用组件的标准化程度和系统集成效率。

    在云原生应用设计中,应用体量更小,因而传统单体应用的功能被拆解成大量独立、细粒度的服务。

    微服务架构使得每个服务聚焦在自己的功能上,做到小而精,然后通过应用编排组装,进而实现等价于传统单体应用的复杂功能。其优点是后续业务修改时可复用现有的微服务,而不需要关心其内部实现,可最大限度地减少重构开销

    05 无服务模型

    无服务(Serverless) 是一种基于代码和计算任务执行的云计算抽象模型,与之相对的是基于服务器(虚拟机、容器)的计算模式。

    无服务在公有云和私有云上都有相应的服务,如AWS Lambda、阿里云的函数计算、Kubernetes的Kubeless、Apache OpenWhisk等。无服务聚焦在函数计算,隐藏了底层复杂的实现方式,使开发者能够聚焦于业务本身。
    在这里插入图片描述

    小结

    总体而言,云原生真正以云的模式管理和部署资源,用户看到的将不是一个个IT系统/虚拟主机,而是一个个业务单元,开发者只需要聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现,而容器、编排、服务网格均是实现云原生的支撑技术

    展开全文
  • 什么是云原生

    2021-10-24 22:30:13
    原生(CloudNative)的概念是伴随云计算的滚滚浪潮应运而生,云原生这几年很火,简直火得一塌糊涂,不过云原生(CloudNative)没有确切的定义,云原生一直在发展变化之中,解释权不归某个人或组织所有。 何谓云原生...
  • 在容器、微服务等领域积淀了丰富经验的阿里云原生资深专家李国强,向数十家山东企业分享了云原生定义、云原生上云的多种方式及关键技术等。本文根据作者的现场演讲整理而成。 今天的分享主题是云原生上云概述,想和...
  • 大家言必称云原生,却鲜少有人告诉你到底什么是云原生,若是找资料来看,读完大多会感觉云绕雾罩,一知半解,总之虚得很;甚至会让你一度怀疑自己的智商,不过我对于读不懂的文章,一律归因于写文章的人太蠢,当然这...
  • 本文将带你了解名企FreeWheel核心业务系统研发团队将单体应用改造成云原生微服务应用的演进之路。 01 何为云原生应用 2010年,WSO2的创始人Paul Fremantle提出了云原生(Cloud native)一词。经历了10多年的发展和...
  • 简介:日前,在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上,阿里云高级技术专家黄玉奇发表了题为《云原生新边界:阿里云边缘计算云原生落地实践》的主题演讲。...
  • 原标题:对比app开发的三种形态原生、混合以及H5 目前市场上选择开发app有三种选择形态原生、混合以及H5。•原生应用程序:原生应用程序是某一个移动平台(比如iOS或安卓)所特有的,使用相应平台支持的开发工具...
  • 原生---Serverless

    2021-09-28 20:26:09
    而典型的计算产品,就是云函数这种形态。 云函数,或者称为函数即服务 (Function as a Service),它和后端即服务 (Backend as a Service) 一起,都可以称为 Serverless 产品。通过组合使用这些...
  • 原生这么火,你再不了解就out了

    千次阅读 2021-02-05 10:11:08
    伴随云计算的滚滚浪潮,云原生(Cloud Native)的概念应运而生,云原生很火,火得一塌糊涂,都2021年了,如果你还不懂云原生,那真的out了。云原生是过去几年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会...
  • 原文《云安全的下半场:原生安全》---绿盟科技刘文懋 中国计算机学会会刊2020年第12期文章 云安全将成为纯安全问题 关于云安全的未来,著名咨询机构高德纳 (Gartner)有两个比较有意思的论断 : 论断 1:网络...
  • 前文中,我们分析并讲述了云原生技术体系在传统企业数字化转型过程中的价值和意义,并重点描述和分析了云原生技术体系如何重构传统企业零散分布式的异构基础设施,进而实现底层分布式异构基础设施的大一统和上层丰富...
  • 盘点云原生的5大特征

    2021-11-10 11:22:35
    导读:随着公有云和私有云的广泛部署,云计算基础设施成为企业部署新业务的首选。可以说,云计算已进入下半场,各大云计算服务商的厮杀日益激烈,新的概念也层出不穷。近年来,云原生计算(Cloud ...
  • 原生带来了标准化、松耦合、易观测、易扩展的特性,为交付基建与业务解耦、更灵活的环境管理和无损发布带来新机遇。同时,微服务架构下服务数量爆炸式增长,对应的交付基建工作量暴增,且服务间拓扑复杂,又导致...
  • 主会场+分会场(AIoT云端一体)一共十四场演讲,一天下来,给我印象最深的几个关键词如下:“云原生”,“无行业不AI”,“云端一体”,“低代码”,“人人都是开发者”。 由于我从2009年以来,一直从事物联网领域的...
  • 数据库是计算机基础三大软件其中之一,相比于操作系统这类更容易收到关注的表面软件,数据库就像是被埋藏在深海里看不见的冰山,虽然存在但很少有人为之侧目。数据库又叫做数据管理系统,是处理的数据按照一定的方式...
  • 构建基础设施资源能力,支持虚机和容器(基于虚机或裸机)类型的虚拟化资源,虚机和容器共享硬件资源,按需调整服务规模,上层网元/应用依据部署形态选择对应的虚拟资源。 统一资源管理和编排能力,引入容器基础...
  • 所谓转型,是指事物的结构形态、运转模型和人们观念的根本性转变过程。PS:源于所见所闻所习所思总结而成,所代表的场景比较有限,可能不会适用于多数场景。上周末,我在思考『大型组织如何进行 De...
  • 原生 Stack 补齐了云原生线下能力,提供了四大核心产品形态: 第一个是云原生 Stack for Application:它是企业数字化的一站式技术底座,把 ACK 敏捷版、EDAS 应用平台、应用高可用服务 AHAS、可观测 ARMS 集成在...
  • 简介:云原生是近几年最火爆的技术热词之一,几乎所有的云计算产品都会或多或少跟云原生发生关联,云原生正在重塑整个软件的生命周期。但到底什么是云原生?云原生带来的最大的技术创新和未来机会是什么?以及,围绕...
  • 什么是 云原生应用?

    2021-02-02 09:28:35
    原生定义# 云原生意味着应用程序原生就被设计为在云上以最佳方式运行。 云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥云计算的优势。这些应用的特点是可以实现快速和频繁的构建、...
  • 中国国情不接受e68a84e8a2ad62616964757a686964616f31333363396438原生系统,正如国内的政策谷歌不能接受,所以就淡出中国,原生系统也就不能在中国发展了。拓展:原生系统缺乏个性与美观度,原生的安卓系统虽说...
  • 原生(Cloud Native)无疑是近两年云计算领域最热的词,随着 Kubernetes 和 Docker 等开源技术的普及,也推动了云原生技术的快速落地。云原生技术首先在新兴互联网企业得到了广泛的实践,同时也逐渐进入传统行业,...
  • 原生发展趋势浅谈

    2020-12-22 12:21:15
    第六,Serverless,这是一种PaaS的特殊形态,它定义了一种更为“极端抽象”的应用编写方式。 容器云加速业务交付效率 云原生有两个重要的思路:第一个是敏捷的不可变基础设施,这一点目前是通过容器镜像来实现,其...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 17,158
精华内容 6,863
关键字:

原生形态