AIGC革命已来,如何在企业场景落地?如何选择模型、怎样应用RAG、需要哪些组织流程配套? 了解详情
写点什么

畅谈云原生(上):云原生应用应该是什么样子?

  • 2019-02-27
  • 本文字数:3724 字

    阅读完需:约 12 分钟

畅谈云原生(上):云原生应用应该是什么样子?

今天和大家一起聊一聊云原生这个话题,内容来自蚂蚁金服中间件服务与容器团队。


由于内容比较多,我们分为上下两个半场。

前言


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



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

如何理解云原生?

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


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



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



先看 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)的基本工作原理:


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

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


本次畅谈云原生分享的上半场内容就到这里结果了,欢迎继续观看下半场内容。


如开头所说,这次分享是希望起到一个抛砖引玉的作用,期待后面会有更多同学出来就云原生这个话题进行更多的分享和讨论。也希望能有同学介绍更多云原生的实现模式,更多云原生的发展思路,拭目以待。


2019-02-27 13:5722459
用户头像

发布了 38 篇内容, 共 20.1 次阅读, 收获喜欢 182 次。

关注

评论 9 条评论

发布
用户头像
感谢作者分享,有两个问题需要思考下:1.应用要实现的能力和云提供的能力如何分界?从IAAS->PAAS->SAAS->FAAS,这本身就是能力的丰富和细化,之前需要自己做的可能以后云上就有了如何演进?2.同一种能力不同云有不同实现,甚至同一个云上也有可能有多种实现,如消息中间件(RabbitMQ、Kafka),这种能力谁来定义统一的标准让应用做到透明无感知,甚至跨云平滑迁移?
2020-03-05 18:06
回复
用户头像
云原生后最重要的是获得两个能力弹性和分布式!
2020-02-19 11:06
回复
太简单
2020-08-24 16:50
回复
用户头像
云原生后最重要的是弹性和分布式
2020-02-19 11:05
回复
用户头像
学习了,谢谢分享
2019-12-27 00:35
回复
用户头像
mark
2019-10-10 10:17
回复
用户头像
学习了
2019-03-30 23:26
回复
用户头像
受益匪浅,对cloud native 和 service mesh 的主要区别还是不太清楚,有时间帮忙解释下
2019-02-28 10:47
回复
cloud native是道, service mesh是术. 前面ppt里有, cloudnative, 具体的实现可能就包括: 微服务, 容器, service mesh等. service mesh是为了实现云原生, 所提供的一种服务发现和治理的方式.
2019-02-28 19:23
回复
没有更多了
发现更多内容

iOS端如何实现MobLink的场景还原功能

MobTech袤博科技

ios sdk moblink

如何进行企业数字化转型?数字化转型的3大核心规律

优秀

企业数字化转型

阿里云实时计算 Flink 版 x Hologres: 构建企业级一站式实时数仓

Apache Flink

大数据 flink 流计算 实时计算 实时数仓

实时数仓Workshop · 广州站 9.15 邀您参加!

Apache Flink

大数据 flink 流计算 实时计算 实时数仓

明势资本黄明明:创新与世界,下一代基础软件的中国突围之路

TDengine

数据库 tdengine 时序数据库

再谈回声消除测评丨Dev for Dev 专栏

声网

音频 Dev for Dev 实时互动

头脑风暴:二叉搜索树中的众数

HelloWorld杰少

算法 LeetCode 8月月更

开源一夏 | React对于生命周期的深入研究

恒山其若陋兮

开源 8月月更

隐私公链Findora生态布局,隐私赛道发展急先锋

EOSdreamer111

EMQX + PolarDB-X 一站式 IoT 数据解决方案

阿里云数据库开源

数据库 阿里云 开源 :MySQL 数据库 PolarDB-X

当满世界喧嚣“All in Web3”,但你可以慢慢来

One Block Community

区块链 程序员 开发者 就业 黑客马拉松

我是咖啡师,在软件公司上班|ONES 人物

万事ONES

开源一夏 |为什么线程池不允许使用Executors去创建?

六月的雨在InfoQ

开源 OOM Executors ThreadPoolExecutor 8月月更

如何快速地学习东西(上篇)

宇宙之一粟

学习 成长 8月月更

一文读懂隐私公链Findora生态布局

股市老人

TDengine 的存储引擎升级之路

TDengine

数据库 tdengine 时序数据库

客户案例|雅森帮携手观测云,保障海量在线用户服务体验

观测云

Python 教程之数据分析(1)—— 使用 Bokeh 进行数据可视化

海拥(haiyong.site)

Python Bokeh 8月月更

索信达控股上半年成绩出炉:核心业务收入大幅增长75.3%

索信达控股

StarRocks 与奥威软件完成产品兼容认证,共同打造数据驱动的智慧企业

StarRocks

数据库

新定位人工智能+营销服务 沃丰科技入选国家级专精特新“小巨人”

科技怪咖

SMTP协议详解

工程师日月

8月月更

每日一R「16」实践课之 kv-server(二)

Samson

学习笔记 8月月更 ​Rust

区块链合约安全系列(四):如何认识及预防公链合约中的算术溢出攻击

BSN研习社

区块链 智能合约

页面切换转场动画,英雄救场更有趣!

岛上码农

flutter ios 前端 移动端开发 8月月更

J-Tech Talk | 编写Dockerfile的最佳实践

Jina AI

Docker J-Tech Talk

什么是数据结构

乌龟哥哥

8月月更

夯实中国智能制造软实力沃丰科技ServiceGo让物流机器人龙头企业售后无忧

科技怪咖

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附复盘模板)

TakinTalks稳定性社区

SRE 故障 定责

[JS入门到进阶] 哎,被vite小坑了一波,大家记得配置build.cssTarget为'chrome61'

HullQin

CSS JavaScript html 前端 8月月更

leetcode 205. Isomorphic Strings 同构字符串(简单)

okokabcd

LeetCode 算法与数据结构

畅谈云原生(上):云原生应用应该是什么样子?_架构_敖小剑_InfoQ精选文章