作者 | 王铎（都铎）
来源 | Serverless 公众号

人类对自由的追求从未停止，我们用战斗获得民族自由，我们用代码获得双手自由，同时代码作为服务器的奴隶，也开始蠢蠢欲动，革命已经开始，当代码翻身做主，作为开发者的我们又该如何适应新时代的到来？

一、一切皆代码的革命（Everything As Code）

代码一直是服务器中的囚徒，然而革命已来，看代码和如何一步一步掌控环境，走向服务。

1. 革命：用代码控制编译打包

Pipeline as code：代表技术 Jenkins Pipeline

2. 革命：用代码控制服务器

Machine as code：代表技术 Docker

3. 革命：用代码控制服务器集群

Server cluster as code：代表技术 K8S

4. 革命：用代码控制基础资源

Infrastructure as code：代表技术 Terraform

当一切皆代码，A=B 可得 B=A，代码即服务时代就来了。

二、代码即服务时代的到来

1. 传统时代的代码仓库

传统的代码仓库说明中，”运行环境安装向导”文档是必备的，以 SpringBoot 代码为例，自带安装向导文档。

2. 新时代的代码仓库

参考代码仓库 aws-lamda-spring-boot2，包括 springboot 运行到 aws 的 lamda 需要的全部代码。

3. 主流技术对新时代的拥抱

以 Spring 的发展为例，从 SpringBoot 开始，不断对环境控制进行集成，直到 SpringNative，已经可以直接构建镜像。

三、代码即服务下的云原生架构

1. 容器服务：用代码控制一切

2. 微服务引擎：信任标准平台，将部分控制权交给平台

3. 函数计算：信任标准平台，将大部分控制权交给平台

四、代码即服务下的研发平台战争

在代码即服务的时代，各大厂商都在建立自己的云上研发闭环，谁做好云上的开发平台，谁就能抓住下一带云原生开发者的心。

1. 代码托管之战：得代码者的天下

• 微软宣布收购 GitHub
• 谷歌投资 Gitlab
• AWS 自建私有仓库 CodeCommit
• 阿里云企业级代码托管平台 Codeup

2. 在线开发之战

• 微软整合 VS Code 和 Github，推出 Github Codespace
• 谷歌另辟蹊径，做线下 IDE 插件 Cloud Code，对接 Google Cloud
• AWS 在线云 IDE：Cloud 9
• 阿里云 IDE：DevStudio

3. 在线构建 DevOps 之战

• Azure DevOps
• Google DevOps
• AWS DevOps
• 阿里云云效

4. 研发体系发展

• 在代码即服务时代，Git 作为代码版本管理软件，加上 WebHook，可以轻松地管理整个代码的运行生命周期，GitOps 应运而生。GitHub 吸 收GitOps 思想，推出 GitHub Actions。

• AWS 推出产品 Proton，提供全配置代码的服务和环境模板，将平台建设能力和复用能力开放给平台开发人员，让普通开发人员更专注业务实现。

五、阿里云开发平台

1. 云开发平台，通过整合云原生产品和云效，完成了云原生开发闭环

2. 云开发平台，构建应用级别的云原生应用，预设标准云架构

3. 云开发平台，应用共享

• 云开发平台和天猫精灵，钉钉团队合作，整合小程序的前后端一起化开发部署，解决小程序云和用户云不能打通问题，给小程序加上用户云能力。
• 云开发平台应用可以在团队内共享，团队内的技术交流，再也不仅仅是 clone 代码。
• 云开发平台市场共享，后续可以合作方的技术方案直接在市场上构建，让云服务提供商再也不用现场帮助用户构建和维护云环境。

六、结语

诚挚邀请大家加入云开发平台，一起共建服务百万阿里云开发者阿里云的云上研发平台。

引用：

1. Performance of running Spring Boot as AWS Lambda functions

本文整理自阿里云技术专家–都铎在【阿里云 Serverless Developer Meetup 上海站】上的分享
ppt 获取方式：关注 Serverless 公众号，后台对话框回复“ppt”即可
直播回放观看地址：https://developer.aliyun.com/live/246653

作者 | 许晓斌
来源 | 阿里巴巴云原生公众号

写作动机

我们为何写作？对于许多技术同学来说，写作是一件比写代码困难许多的事情，和电脑相顾无言数小时，发现自己写不出什么像样的东西来，着实不是一种很好的体验。即便对于有些经验的人来说，写四千字质量尚可的文章，我估计也要花 6 小时以上的时间，这还不算平时素材积累的时间消耗。

这么费事费力的事情，为什么要去做呢？我认为此事有着极大的价值，这个价值分两层，我暂且称之为表层价值和深层价值。

表层价值是极其功利的，例如有同学想晋升，而晋升的一项指标是个人影响力，那么写文章就能提升个人影响力；例如有团队 Team Leader 想招聘，那怎么让别人了解你及你的团队呢，写文章也是个不错的方法；再有一些就是冲着上级或者利益相关方写的文章，以类似项目汇报的方式写的文章。表层价值的核心关注点其实并不在文章本身，而在于文章背后的人，作者对读者的期望往往不在于读者认可文章内容，也不期望读者参与对内容的讨论，而仅仅是期望读者快速地认可作者这个人。

只关注表层价值去写文章，非常的本末倒置。就好比写一篇讨论 PM 2.5 的科普文章，如果你一上来就冲着推销自己的空气净化器这个动机去写，其恶臭很快会从字里行间流露出来。

与表层价值相对的，我认为任何一篇文章都应该从深层价值出发。这个所谓深层价值就是文章的内容，文章的观点，文章需要尽可能地客观，要向学术真理的态度逼近。写一篇文章是因为对一个问题有着自己的思考，并且去详细了解了很多人的思考，发现了一些观点的冲突，并且不会为了政治正确去迎合别人的观点；尽我所能把那些我认为有价值的想法，总结下来，用清晰、有趣的方法传播给他人；我能体会到写作的热情，这种热情来自于思维的乐趣，来自于观点的碰撞。这个写作的过程，自己的思维有成长，通过大量的逻辑思考，我的思维得到提升；其次写出来的文章，对读者有着很高的价值，因为有价值的知识得到了传播。

还有一种写作动机就是想要传播有价值的技术，例如 Pivatal 公司的布道师 Josh Long 就写了大量的技术介绍文章，也有很多精彩的演讲。我曾问他为什么能够做的如此出色，以致于多年被评为全球 Java 领域最有影响力的 20 人之一。他的回答是这样的：

I think that people don’t trust technology, they trust people. So, while it is possible that the spring team could just publish good documentation and leave it for the world to find, it’s far more compelling when u feel u can ask questions of someone. And u can see that they’re having fun.I love Spring because it has made millions of lives easier. It makes me happy to think about its application, to see people happy with its possibilities.

一篇文章写出来，是因为作者喜爱一项技术，从内心认可技术的价值，相信技术的潜力；还是因为作者想兜售什么东西。这两者动机的差异，稍微细心的读者很快就能发现。当然，上述动机经常混合在一起，但是如果写作的主要动机都在表层，那么基本上这样的文章也就没什么价值了。

影响力

Josh 是 Java 领域在全世界有影响力的人，他通过演讲，写书，博客，影响着全世界数百万的 Java 程序员，帮助了 Spring 等优秀的技术在全世界的推广。我写了一本关于 Maven 的书，这本书也得以卖书了几万册，再加上盗版 PDF 的数量，那是影响了全国十多万的 Java 程序员了，帮助了 Maven 这一技术在中国的推广。我加入阿里 8 年多，在内部技术社区 ATA 发表了 60 多篇文章，累计的阅读数大概也有五万以上，我相信这些文章也给阿里的技术带来了一些微小的正面改变。从这些角度看，写优质的文章虽然耗费很大的精力，但是由于其非常便于分享传播，因此能够快速地影响许多人，而且这种影响能够持续的存在。

当然时代在改变，以前由于网络技术的限制，文字的传播比较方便，视频的制作及传播成本比较高，因此演讲的实际影响力相比文章和书籍会弱很多。而今天的网络和视频技术已经非常成熟，制作高质量的视频也许更容易传播了。

文章也好，视频也好，影响力应该是被用来做正确的事情。今天控制影响力的很多流量入口，已然形成了一种新的权力，他们能控制什么声音容易被大家听见，什么画面容易被大家看见，什么文字容易被大家阅读，什么态度容易被大家感受。权力的形成进而演变成了权力寻租，然后这个事情就往往和所谓“正确的事情”无关了。

通过影响力做正确的事情，我觉得最好的例子就是张瓅玶（花名：谷朴）的这两篇文章了，第一篇是「API 设计最佳实践的思考」，第二篇是「警惕复杂度困局：关于软件复杂度的思考」。文章的内容都是工程师喜闻乐见的关于软件设计的深度分析和思考，但我觉得在这个例子中，比内容更重要的是这两篇文章中传递了一个非常重要的信息，那就是，“在阿里巴巴，即便是研究员级别，也是有人在仔仔细细认认真真看技术的，那些层级更低的却早已脱离一线的，张口闭口都说技术只是细节的管理者，见鬼去吧。”（当然，这个信息只是我个人观点，不能代表谷朴）

写作方法

我们的基础教育似乎在写作的培养方面很有问题，我印象中市面上常见的那些优秀作文选，往往都是注重形式和套路，往往缺乏逻辑和观点，用一个成语总结就是“无病呻吟”，什么事情都要拔高抒情，以小见大，最终的结果就是假大空成灾。大家整体的基础已经薄弱了，而从事技术工作的同学，往往在读书的时候语文还是个弱项，那么结果就可想而知了。写出来的东西，要逻辑逻辑不严密，要形式形式乱糟糟，基本的分段、标点、用词更是问题颇多。好在写作这个能力不是只在学校才能训练的，工作中也可以训练，而且明显有章可循。

1. 阅读量

郑子颖（花名：南门）在他的文章中强调了“多看”的重要性，他用豆瓣记录了年均 50 本以上的阅读量，这相当于平均每周至少一本书，这是一个比较非常惊人的数字。我回顾了一下自己的豆瓣记录，阅读量大概是他的一半，也就是年均 25 本的样子。阅读的益处自不必说，我这里想强调的一点是，不断阅读优质图书能提升自己的文字鉴赏力，书读多了，拿起一本翻翻目录，其中找几个段落读一下，对于此书的质量，心里大概就有个谱了。自己写作的时候，其实大多数时间也是在参考现有例子的结构和方法，如果你照着大量优秀的案例学习，那么自然也不会差到哪里去。

我在写《Maven 实战》之前，阅读了大量的 O‘Reilly，Pragmatic Bookshelf，和 Manning 的计算机图书，这些公司出版的图书大都有非常高的质量保证，在介绍技术的时候，有清晰的由浅入深的结构，辅以大小适中的案例，以及不枯燥的理论分析。可以说，我就是参考着那些优秀的书籍的写作结构和写作方法，写了自己的书，最终我的书也得到了整体不错的评价。

除了写作方法上的受益，阅读更重要的是从内容受益。再举例来说，我在「如何做好技术 TL」这篇文章中，提到了自己在做 TL 的这些年阅读了好多本讲管理的书籍，包括《赢》、《驱动力》、《门后的秘密》、《非暴力沟通》等等，这些书籍极大程度上帮助我补充了自己的思考脉络。写作即思考，而思考不是凭空出现的，思考需要原料，常见的原料就是我们实际的工作经验，然而一个人的体验毕竟是非常有限的，而阅读他人的体验及思考，以谦卑的态度为自己的思考提供更多原料，显然是明智的做法。

「如何做好技术 TL」收到过一条很有意思的评论，评论是这样的：

个人认为管理相关的书籍都是鸡汤，不必看，如果需要靠着“教你怎么做管理”的书才能做管理，那么说明这个人不适合做管理。

这句话隐含的意思是，有些知识，例如管理的知识，是无法传承的，只能靠自己天性领悟。对于此评论，我只能说无知者无畏了，我们写文章必不可持有这种心态，即便自己的想法有多么独特、多么原创，也一定不能自建藩篱，坐井观天。

2. 素材

我最近一年一直在做云原生相关的工作，期间我一直在思考，到底什么才是云原生架构，目前行业里对这个词有非常多的解释，但是所有这些解释都没法给让我满意，它们都过于偏重技术和云厂商的视角，而缺乏应用架构的视角。对于这个状况，我想基于过去一年，以及未来的相关工作，对云原生架构这个概念写一些东西，对其概念做一些补充阐述，帮助大家更好的使用技术，文章还没写出来，但是动机就这样形成了。

有了这个动机，再结合我自己个人的一些兴趣，过去一年我一直在积累素材，这些素材非常有意思。例如，我直接深入参与了国际化中台和考拉的项目，他们的架构基于云原生的技术，以及许多阿里云的产品，做了非常大的升级；我也详细了解了菜鸟如何在云上构建平台服务他的合作方公司；学习了解钉钉、IoT 这些本身在公有云上售卖服务的部门，自身是如何在云上架构。我通过 IM，电话或者面对面的方式和相关的同学沟通，他们都非常友好地知无不言，然后我整理相关的材料，再从中分析相同的模式。人脑非常喜欢模式识别的刺激，我在做这些事情的过程中也是乐在其中。除了实际的案例，行业资深人员的观点也是我平时收集素材的来源，例如林昊（花名：毕玄）最近写了一篇名为「云原生的进一步具象化」的文章，他们的文章通常不会人云亦云，仔细阅读会发现一些比较原创的观点。

除了上述和目标主题关联度非常大的素材外，我还发现跨学科的阅读也往往会给自己带来意向不到的收获。还是以云原生为例，虽然我在这个领域工作，但是最近一两年我一直在断断续续的阅读一些经济学的书籍，包括曼昆的《经济学原理》等（我估计好多人买了这套书了，但是真正认真读完的非专业人士还是比较少的）。在学习经济学的思维方式时，我就想从经济学的视角去解释云原生这个事情，原本自建的技术基础设施，在云的时代在逐渐演变的基于云的基础设施，这背后的选择对于业务来说，从经济学的角度应该怎样去分析？自建的成本和效用是什么？购买的成本和效用是什么？将复杂的业务技术架构拆分成一层一层之后，或许可以逐层分析，在每一层做一个从经济学角度最优的选择。

3. 思维导图

我最早了解思维导图是因为读了「Pragmatic Thinking and Learning」这本书，书中介绍思维导图的核心用途是把一个主题相关的所有内容，无论重要次要，都在一个图中写出来，那些不断拓展延伸的线，不是为了构成一个清晰的结构，而是为了给大脑显示什么地方思维可以进一步拓展。因此画思维导图的方式应该是尽量开放自由，目标是把主题相关的内容全部展现出来，思维导图的目的不是建立清晰的逻辑结构。因此，当我看到很多画的思维导图实际上是一个目录的时候，我觉得他们基本都用错了。

写文章（做演讲也是类似的），都是一个先开放后收敛的过程，在前期不断积累素材，使用思维导图拓展思维，建立材料的关联，就是开放的阶段。这个阶段中可以适当让逻辑思维退到幕后，把目光打开，不要过多评价（建立结构，分主次其实就是一种评价），用一种类似空杯的心态去倾听和观察现实世界及他人想法。我在做演讲或者做文章之前，总会先找个安静的地方，准备好咖啡，打开 MindNode，或者直接找拿出 A4 白纸和笔，给自己半小时到一小时的时间，把主题相关的思维导图画一画。安静免打扰的环境、没有时间的压力、富有精力的大脑，这些条件放在一起，才能够让自己从手头事务的聚焦中移开，让大脑中平时得不到关注的意识浮现出来，然后落到纸上。

4. 结构

将大量的材料胡乱堆砌在一起作成文章自然是不行的，作品必然要有一个清晰的结果。在建筑中，我们耳熟能详的有古希腊建筑的柱式结构，也有哥特式建筑以尖拱券、肋拱、飞扶壁等要素为核心的结构；在程序中，常见的 MVC、分层、微内核等模式也是清晰的结构。文章的结构能帮助作者把自己的观点清晰地表达，引导读者在清晰的路径中阅读。在有了思维导图之后，我通常会从那些纷繁复杂的材料中提取出一个最合适的结构，然后再基于这个结构组织材料。

写技术文章还是有一些常见的结构的，以下是几种范式：

• 解决问题型结构。这种范式通常围绕解决一个具体问题出发，常见逻辑是：背景介绍 -> 提出问题 -> 讨论解决问题的思路 -> 解决问题 -> 价值总结。这种结构可能是工程师最熟悉的了，因为大家都擅于解决具体问题。
• 知识介绍型结构。这种范式通常用于新技术的介绍，常见逻辑是：行业背景 -> 技术提出 -> 简单 Demo -> Core Conecpts -> 概念深入及 Demo （1-N次）-> 前景分析。大家平时看到的很多技术介绍文章通常使用的是这样的结构，这样的结构的好处是可以由浅入深地介绍新技术和新概念。
• 观点输出型结构。这种范式相较于前面的两种会更有挑战，常见的逻辑是：总体观点 -> 子观点 1 -> 子观点 1 阐述 -> 子观点 2 -> 子观点 2 阐述 … -> 总结。这种结构的文章写好了力度是非常强的，但是写起来非常有挑战，因为观点的阐述需要丰富的素材以及严密的逻辑推导，稍有不慎就有胡扯之嫌。

当然，我们在写作的时候不必拘泥于这些范式，也可以琢磨自己的范式，但不论何种范式，背后总是存在一个有逻辑关系的结构的。有一本书叫「金字塔原理」，我听到很多人推崇（尤其是在绩效季的时候），我看了下介绍和评价，讲的就是如何用高效地方式让对方理解你，我没读过这本书，但应该就是讲行文的结构和逻辑的，有兴趣的同学可以买来看看。

5. 观点

不是所有的文章都有观点的，例如你写文章总结自己如何解决一个性能问题，不一定需要有观点；介绍一项技术，如 Rust，不是非要表达观点。但是能够表达自己观点的文章通常会更有吸引力，例如解决性能问题的时候强调理解排队论的重要性，这就是一个观点，容易让人印象深刻；介绍 Rust 的时候，断言其在性能敏感的场景未来会占据统治地位，也更容易让这门技术吸引人的目光。当然，观点是需要论证的，其坚固性和你论证的投入度成正比，逻辑推导、数据支撑、案例分析都是非常好的论证手段。

我们也看到有一些文章满篇观点，但基本都是引用，一会是乔布斯，一会是张小龙，一会是马云等等；当然，更常见的是引用公司高管的话，谁谁谁在什么时候说过什么等等，然后用这些内容来支持自己的材料。我觉得偶有引用无伤大雅，总是引用就只能说明自己没有观点，或者观点无力，需要强力给自己支撑。

更有勇气，能体现自己素材丰富，思考深度的观点，反而是那些敢于说出皇帝的新衣的文字。技术文章应该是具备科学精神的，科学是基于对过去不断的 say no 发展出来的，技术文章也应该敢于表达 say no 的观点，不用怕得罪人，我们应该明白，正确的技术/架构/方案，应该是经得起质疑的，因为如果技术是错误的，即便当下环境没人敢质疑，时间长了，现实会让错误需要付出的代价呈指数倍上升。因此，相比于通篇正确的废话，敢于对现状 say no 并提出自己反面观点的文章，更值得推崇。

6. 故事

严格来说，给自己的内容添油加醋的整故事，对于逻辑论证没有任何帮助。然而要让自己的文章/演讲有吸引力，故事的元素是必不可少的。人类进化到今天，大脑对逻辑的反应是非常慢的，而且需要经过训练后才能理解逻辑，但是对于故事的反应，三四岁的小孩就有，人类早期流传下来的精神，例如希腊神话和圣经，都充满了精彩的故事。直至今天，无论公司内网，还是微博，大家对吃瓜的热情之高，岂是逻辑论证能点燃的。故事很容易引起人的共情，让人设身处地联想，然后大脑皮层就容易嗨了，神经网络被激活，各种激素开始分泌……

这是人类生理的现实，所以我们写文章的时候要尊重（利用）这个现实。要讲一下程序性能不好导致身边的同事半夜 3:20 分电话惊醒了；出了故障导致超市收银机被砸了，介绍新编程语言的时候要秀一段代码，顺便搞个对比说 Java 不行；介绍 Mesh 的时候就要说你原来升级中间件得这么干这么干，以后不需要了，等等……

我介绍自己「Maven 实战」的时候喜欢讲一个真实的故事：

在我书出版的前些年，因为虚荣心作祟，我特别喜欢去各大售书的网站刷评论，什么亚马逊，豆瓣，京东啊等等，一条条的去看，看到 5 星评价就喜滋滋，看到低1星或者 2 星的就很生气，当然，大部分评价都是很正面的。直到有一天，我在京东刷到一条 1 星的评论，我就一边难过一边打开评论，但读罢我就乐了，那个读者打 1 星的原因是这样的“让你们老板泡奶茶，差评！”原来是因为那阵子刘强东奶茶爆出了恋爱的新闻，伤了这位读者的心了，然后我就躺枪了。

这个故事其实和我在书中介绍的技术没有任何关系，但是我却喜欢讲这个故事，因为他会让听众会心一笑，然后记住我写过一本关于 Maven 的书。

烂文章是怎样的

讲了那么多怎么写好文章的方法，我也想说一下烂文章都长什么样。所谓烂文章，就是指那些对于读者来说，几乎没什么任何正面价值的文章，更有甚之，不仅没有正面价值，还存在负面价值。以下我稍作总结：

• 个人笔记成文章。自己解决了一个技术问题，做了一些记录，然后写成文章发出来了。这类文章充其量只能称之为素材，因为没有总结提炼，而且完全是从一个人的视角出发写的，读者读起来，不仅感觉不到体系，有价值的部分更通常是少的可怜。
• PPT 贴成文章。作者在某个地方作了一次演讲，因为想传播给更多的人，因此就用贴图的方式整理成了文章，好心点的，在图片的中间在补充一些解释文字，就这么成文了。我先假设这个演讲本身的质量是不错的，有逻辑，有观点，有案例，但是即便如此，这样的所谓文章，其阅读体验也是非常差的。在演讲中，PPT 是辅助“讲”的，如果只有 PPT，那真正核心的“讲”的部分就丢失了，因此，更负责任的做法，应该是演讲者用丰富的文字把所讲，用清晰的方式写下来，而不仅仅是那几页干瘪的 PPT。
• 用宣传战功的方式写文章。组织内部此类文章屡见不鲜，标题会带着很多常见的如“总结”，“年度”，“体系”，“反思”，“展望”等词，通常这类文章既没有体系，也罕见反思，其主要的目的是邀功。基本套路就是，写在在一年中做了很多事情，结果非常好，配几个看起来差不多的框框“架构”图，再直白点，就要上合影了。这类文章后面通常会有很多赞，但基本没有讨论，讨论个啥嘛？作者来邀功了，莫非你说他做的不好得罪人？从知识传播，促进思考的角度来看，这类文章价值几乎为零。
• 各类贴图成文章。相比用 PPT 贴图，还有用各种其他图贴成文章的，思维导图直接贴，设计图直接贴，流程图直接贴，监控图直接贴，一顿看下来就是没见几行字。好的图，的确是一图胜千言，但是那也仅仅应该是点睛之笔采用，如果篇所谓文章全是图，就完全看不出重点，也看不到体系。文字是非常有力量的，文字可以把读者拉入到作者的思考体系中，用逻辑和修辞去引导读者的思考。或归纳，或推导，让原本隐蔽的知识展现；或雄辩，或幽默，让作者的观点闪光。写作应该充分发挥文字的力量，不是只有图才有架构，不是只有图才能体现思考，相反，图往往因为其不精确性，成为很多人掩饰其思考不足的工具。
• 正确的废话成文章。官话套话，动辄抽象到极高的高度，从公司战略说起，洋洋洒洒一顿分析，满眼就是最近被抨击得厉害的那类字眼，什么“顶层设计”，“底层逻辑”，“赋能”，“抓手”之类；如果找不到清晰的逻辑，就来个 1.0，2.0，3.0，4.0，5.0，6.0，反正主版本号加 1 就是比前面牛逼了，至于为什么小版本号从来没人用，不知道，反正 N.0 就对了，直接 N 是不行的，直接 N.0.0 也是不行的。读罢这类文章你说不清楚哪里是错的，你唯一明白的就是这文章啥价值都没有，你又浪费了几分钟生命。

来源 | 阿里巴巴云原生公众号

2021 年 4 月 27 日，云原生计算基金会（CNCF）宣布通过全球 TOC 投票接纳 Fluid 成为 CNCF 官方沙箱项目。Fluid 是一个由南京大学、阿里云以及 Alluxio 开源社区联合发起并开源的云原生数据编排和加速系统。

Fluid 项目地址：
https://github.com/fluid-cloudnative/fluid

项目介绍

云原生环境下，计算存储分离架构在提升系统弹性和灵活性的同时，给大数据 / AI 等数据密集型应用带来了计算性能和管理效率方面的挑战。现有云原生编排框架运行此类应用面临数据访问延时高、多数据源联合分析难、应用使用数据过程复杂等痛点。Fluid 正是为解决这些问题而生的。

Fluid 系统架构图

Fluid 运行在 Kubernetes 上，是一个可扩展的分布式数据编排和加速系统，其目标为构建云原生环境下数据密集型应用的高效支撑平台。该项目开源于 2020 年 9 月，短短半年多时间内发展迅速，吸引了众多领域专家和工程师的关注与贡献，并在包括微博、中国电信等多家大型知名IT和互联网企业中使用。

核心功能

Fluid 在云原生应用与数据的协同编排、调度优化、数据缓存等几方面提出一系列技术创新，其核心功能包括：

• 提供存储无感知的数据对象-数据集(Dataset)：通过自定义资源对象 (Custom Resource Definition)实现对不同存储系统的统一抽象定义与管理，支持可观测性和弹性伸缩。
• 利用分布式缓存技术加速数据集读写：通过扩展 CacheRuntime 对象，自定义并管理分布式数据缓存引擎。目前已原生支持缓存引擎 Alluxio 和 JindoFS。
• 基于容器调度的智能数据编排：基于 Kubernetes 容器调度和扩缩容能力，实现数据缓存的智能化编排。
• 数据集与应用协同调度：扩展 Kubernetes 调度器感知数据集缓存信息，就近调度应用，发挥本地读写缓存的性能优势。
• 标准访问接口：使用 Kubernetes 标准存储接口 Persistent Volume Claim  访问数据集，实现无缝兼容云原生应用。
• 面向场景的性能调优：针对深度学习、批量数据处理等任务，提供数据集预热、元数据管理优化、小文件 IO 优化、自动弹性伸缩等手段，普遍提升任务运行效率。

展望未来

Fluid 开源项目致力于通过结合学术界的原创研究和工业界的落地实践能力，加速云原生基础设施拥抱数据密集型应用，与开源社区一同构建 Kubernetes 平台应用使用和管理数据的统一界面。Fluid 开源社区目前有 5 位核心维护者 (Maintainer)，分别来自南京大学，阿里巴巴和 Alluxio，并由来自南京大学 PASALab 的顾荣副研究员担任开源社区主席。此外，来自中国电信、微博、Boss 直聘、第四范式、云知声等企业的工程师都贡献了大量的开发工作。

作为对原生 Kubernetes 生态完全兼容的数据密集型应用运行支撑平台，Fluid 将向更灵活、智能、可扩展的架构方向发展，不断提升开发者和用户使用体验。未来，Fluid 将继续与社区并肩、与生态同行，致力于推进云原生技术在大数据 / AI 系统领域的生态建设与普及，与全球开发者一起拓展云原生的边界。

欢迎大家持续关注 Fluid 开源项目并积极参与该项目的共建。

作者 | 阿相
来源 | 阿里巴巴云原生公众号

最近我发现一些同学的分享越来越趋于“念稿”式。我一边看着分享的同学在上面念稿，另一边看着几十号人在下面看电脑看手机，我心里就特别着急。恨不得我自己上去讲，也恨不得没收了大家的电脑手机。但这种粗暴的方法肯定是不解决问题的，核心问题还是大家不善于分享。

我自认为自己过往的分享都还是中等偏上的，因此总结一下，讲讲如何做场高质量分享，希望能够给未来要做分享的同学提供一些帮助。

为什么要分享

每个人在分享前都应该先问自己这么一个问题，我为什么要分享？我觉得分享就一个最纯粹的原因，就是“我有一些知识，是别人不知道的，但对他人会有所帮助，所以我想分享给大家”。

换言之，分享的本意就是总结并传播知识，分享的核心是利他。

而现实情况呢？

• 做了一些技术产品，想推广给大家，所以要分享。
• 为了体现自己有团队贡献，想要好绩效，所以要分享。
• 就是想 show 一下自己，让别人觉得我厉害，所以要分享。

是不是有些变味呢？其实我也并不否认这些原因，我们如果能分享的好，这些也都是自然而然的结果。这就类比我们加入蚂蚁最核心还是想要快速成长，而好绩效是快速成长的结果。但谁不想要好绩效呢？

但我们不能为了这些结果而忽略了初心。分享的初心是希望大家相互分享知识，互相成长。我觉得也只有真的能对别人有帮助的分享才能称之为“高质量分享”。

所以，如果你在准备分享，请你再质问一下自己，你到底是为什么要分享？只有自己初心摆正了，在做分享的准备的时候，才会真正的去想：怎么才能把这个分享做好，怎么才能让分享生动有趣，怎么才能让分享干货满满，怎么才能更好传达自己的知识。否则，你以为自己分享了就是取得结果了，其实你什么也没得到，还浪费了别人的时间。

什么是好的内容

好，相信看到此处的同学都是愿意利他的同学了。那新的问题又来了，我需要分享什么呢？什么样的内容才能支撑所谓的高质量分享，我理解是如下三种。

1. 高度总结的知识

有些知识也不是多难掌握，而是掌握的过程可能需要花费大量的时间去到处收集信息。过程中可能又会衍生出很多问题，需要自己破案一样的去研究。比如很早时我写的一篇《你的 Tree-Shaking 并没什么用》。为了研究 tree-shaking 为什么真实场景下优化有限，研究了 babel、uglyfy、webpack、rollup，甚至去翻一堆 issue，最终花了我数天才窥见原由。

其他人如果也想了解这里面的原因，也需要花费数天的话，未免太折腾了。因此我把研究的过程总结成了文章并发表，同时在团队内做了一次分享。一方面传播了知识，另一方面如果别人真的想再仔细研究，至少可以节约一些时间。

类似的还有一些新技术推出时，业界文档较少，大家学习成本较高，自己系统性学习以后做一些总结并在团队内做系统性的分享。比如 React16 刚推出时，我师兄芃程在团队内分享了 16 的新特性：

2. 可以借鉴的经验

还有一些偏经验性的内容。可能是非技术性的经验，比如成长经验、人生感悟或个人思考。最典型如晋升总结、管理经验分享等等。比如我们部门曾邀请过的一些分享：

• 兼续的《聊一聊平台技术前端如何成长》
• 依鹭的《业务中台 – 合作伙伴提效》

我觉得他们的分享都非常的好。比如兼续提的“微习惯”，依鹭提的“不要用战术上的勤奋掩盖战略上的懒惰”等等都给我留下了非常深的印象。

也有可能是技术上的经验，比如某类技术产品的建设经验、推导的过程等。比如 2020 年前端 D2 大会上的：

• 辰啸的《前端故障演练的探索与实践》
• 当轩的《跨端的另一种思路》
• 霸剑的《SSR 在双十一会场的落地实战》

核心就是：把自己的长期经验做一些系统总结，以自己的故事或技术专项作为案例支撑，摆事实讲道理，给其他有相似诉求的人一些“长者”经验。

3. 晦涩难懂的技术

还有一些是非常难理解的知识，这种往往是非自己专业领域的知识、或上手成本特别高的技术点、亦或是某些高深的源码解析之类。如果我们的分享能把这些晦涩难懂的技术讲的非常深入浅出，易于理解与吸收，那也是非常优质的分享。比如部门邀请过的邦祝老师的《Challenges for On-device System Design and Innovative Algorithms》（连标题都看不懂了）。还记得当时邦祝老师讲卷积神经网络时，板书做的很好，挺容易让大家理解。

不过这类分享在蚂蚁我见的比较少，也很少看见讲的非常很好的。不过网上有一些，比如：李永乐老师的很多科学、数学相关科普视频。

那是不是我们分享的内容属于高度总结的知识、可以借鉴的经验、晦涩难懂的技术就代表着是一场好分享呢？肯定不是的。内容虽有用，也要观众听。能被观众听进去的内容，才能称之好内容。所以如何把我们的内容给分享好才是最关键的。

我认为，想分享好内容，首先是要组织好内容，然后是要找到好的方式去展示它，最后是有一定的技巧去表达它。

如何去组织内容

1. 结构性

很多人都听过《金字塔原理》，这是一本讲解写作逻辑与思维逻辑的读物。其实我也没看过，但我知道它的最中心思想，就是“总-分-总”。总分总相信大家都知道，一个主观点，N 个子观点，每个子观点可能还有子观点。讲每个观点都是结论先行，然后讲解论证，然后总结说明。用技术人更容易理解些的话，就是整理成一颗树，然后做深度优先遍历。

当然《金字塔原理》里还有非常多有用的知识，还是推荐大家有空去读一读，肯定会有更多的收货。

我们今天先迈出第一步，就是总分总。换言之，内容的组织需要具有结构性。如果通篇内容，没有标题、没有分段、没有中心思想。是文章的话看着累，是演讲的话听着累。而结构化表达以后，有两大好处：

• 对于自己：更系统、更体系的整理了自己准备分享的知识，对自我知识是更好的总结跟整理。
• 对于他人：人类对于有序事物的记性肯定是大于无序事物。结构化表达有利于观众接收信息并回忆信息。

2. 故事性

除了结构性表达，我个人还很喜欢故事性的表达。就是想办法让自己的内容显得更加跌宕起伏或具有延续性。

跌宕起伏指的是不断地抛出问题，再解决问题。比如在我的《保险智能运营体系 2.0 的前端建设之路》。我先讲 1.0 的现状与问题，然后讲自己的策略与解法。做完以后，通过一些数据分析又发现了新的问题，然后又出了一些解法。这样不断的发现问题 -> 解决问题，让内容具有一定跌宕起伏的故事感，能让读者持续保有新鲜感与阅读欲望。

延续性是指不断的由一个内容衍生出新的内容，最终回答最初的问题。比如我的《国家为什么老爱管我们》（一篇介绍金融基础知识的文章），从金融引到货币，从货币讲到银行，再讲到影子银行，再讲到具备影子银行特性的互联网产品，最后回答国家为什么老爱管我们。就像是在一条风景优美的公路兜风，两边的风景从树林渐变到草原再渐变到湖泊，过程衔接顺畅，风景美不胜收。最终证明了这是一条风景优美的公路。延续性的内容可以始终牵引着观众思绪，保持观众注意力。

其实我这边文章就尽量去遵守结构性跟故事性。主题是「如何做一篇高质量分享」，后面细分成几个观点，观点再细分子观点。这些观点又具有一定延续性。先是定义什么是好的内容，有了好内容后讲怎么去组织、去展示、去表达。最后的最后再做一个总结。

如何去展示内容

如果是以文章形式的非现场分享，那能组织好内容，内容又是高质量的，相信文章一定也是高质量的。但本文更多的还是想探讨周会、月会等现场分享时，该如何更好的展示我们要分享的内容。

而对于这个问题，我只有一个核心观点：少字多图。

我现在发现很多人特别喜欢把文章直接拿来做现场分享，但这种情况的分享我没见过有效果特别好的。因为基本都是在念稿子。这就是我观点的最极端反面，几乎全都是字。如果一篇现场分享稿也全都是字。那请问大家是听你说话呢？还是看你文字呢？还是听你念字呢？这还不如把文档发给大家自己看呢。

我一直鼓励大家还是用 PPT 分享，因为 PPT 上不容易放太多字，只能放核心信息。因此用 PPT 会倒逼自己把关键信息摘取出来。由于字少了，信息少了，又会倒逼自己去更生动的传达观点。

我以我的《国家为什么老爱管我们》为例。我写完文章以后，又准备在团队内做个分享。但文章字数有 3 万多字，如果我当稿子念，估计大家梦都做两回了。所以我把文字信息给抽象，配上合适的图，把文章当做演讲稿，再多加一些即兴发挥。比如其中的「什么是资产证券化」一节，该节纯文本字数有 867 字，我转成 PPT 后如下：

用几张图片加摘要文字，展示资产证券化的演化过程。然后画了专门的图来介绍资产证券化本身的运行机制。最后加粗个大字表达核心的观点。

对于有些并没有太多观点的章节，我的PPT更简单。比如其中的「你是否听过影子银行」这一节，主要是讲了两个小故事，并没太多观点。因此我的 PPT 就放了两张图，其他靠嘴巴讲讲即可。因为这种没关键信息的内容，观众没必要一边听我讲一大段故事，一边在 PPT 上看一堆文字。

当然，很多技术的分享，可能要演示一些代码，或者展示一些流程图、架构图，用语雀这样的文档工具可能会更方便编写跟展示。只要控制好排版，不要堆列演讲文字，对关键信息加大加粗，这也是可以的。语雀也提供了演示模式，但希望大家能更好的利用这个演示模式。

总结一下，其实分享形式本身并不重要，重要的是别念稿。分享文档一定是高度抽象后的信息展示，其他过程的阐述尽量靠自己的嘴巴配合图片去传达。记住核心要义：少字多图。

PS：有一种 PPT 分享形式，叫高桥流。每一个 PPT 上就几个大字，其他全靠嘴。罗永浩，还有我们前端熟知的贺师俊都使用过该形式做过分享。我也曾经尝试过：《Node HTTP/2 Server Push 从了解到放弃》。

如何去表达内容

是不是有了高质量的内容、高质量的 PPT，就能讲好这场分享了，也不一定。高质量的分享最后考验的还是演讲者自身的演讲水平。

由于我又自认演讲口才还可以，因此我总结了我个人认为的一些演讲技巧。我觉得如果能把这几点做好，肯定对表达我们的内容有很好的帮助。

1. 吸引人的开场

好的开始是成功的一半，很多事情都是这样，一场分享也是如此。很多场合下，包括我们的月会，数金荟等等，大家最开始的心思并不一定在你的分享上。又不是什么苹果发布会，你的分享真的很重要吗？如果一开始不能吸引大家注意力，后面你讲的是啥别人都不知道了。

因此我的分享，我的开头一定会想办法吸引大家注意力。还是以《国家为什么老爱管我们》为例。首先我设计这个标题已经很吸引人注意了，但我还是觉得不够。因此我的 PPT 内容第一页加了一个问题：我们是金融公司还是科技公司？并借之前公司改名的事件开始介绍我的观点。这样通过介绍最贴近大家的事情，先把大家注意力吸引过来，后面讲起来就很顺畅了。

也有一些文稿可能不一定很吸引人。我也会想办法先说一些题外话吸引注意。比如上文提到的高桥流之作：《Node HTPP2 Server Push》。我一开始会先跟大家介绍一下什么是高桥流，并说出罗永浩、贺师俊等名人的事情，借此吸引大家对这份 PPT 的好奇。

总之，无论什么样的分享，一定要有一个吸引人的开头，甚至可以不是分享内容本身，但一定要吸引人。实在不行，先上去唱个歌跳个舞也行。

2. 与观众有互动

开头吸引住人了，后面丢了他们的注意力也不行。我自己的技巧是尽量维持与观众有互动。有些是我本来就精心设计好的，比如我在分享《国家为什么老爱管我们》的货币起源一节时，我会现场挑一个人，让他扮演一个角色，跟我产生互动，借此来阐述货币与债务的关系。我甚至专门准备了一张 100 元的现钞来类比欠条，来增加现场互动感。

除了一些精心设计的环节，我分享时会尽量注意现场的气氛跟下面同学的注意力。大家都不听的时候，可能是本节内容确实无趣，同学们注意力已经离开。因此我可能会快速略过一些不重要的内容，快速进入下一个环节，并想一些方式再次唤起大家的注意力。

甚至在现场互动之前，在我写文章或写 PPT 时，也往往会想象出一个观众来。我会想如果我是他，看到我此时的文章，或者听到我的分享，他内心会产生怎么样的想法与问题。然后就这个可能的问题，我会撰写对应的部分内容。或以可能的问题在现场时做自问自答。所以我分享时常会说“那么就会有人问”，然后开始自行解答。当然，如果现场确实有人问，效果就更好。

3. 有停顿有节奏

上文也说到，我想一些方式再次唤起大家的注意力。而最简单的唤起大家注意力的方式就是有停顿有节奏。想象一下，在一个会议室，上面有一个人在分享，下面的人都低头开始玩手机。如果分享的人突然停下来不说话，大家会怎么样？很多人都会抬起来看看发生了什么。这时候大家的注意力又被牵引回来了。但是这是一招“狼来了”的技巧，所以不能滥用，必须是发生在，你即将要讲关键信息之前，做一下停顿。

除了停顿之外，演讲还应该抑扬顿挫，也就是有节奏的演讲。我们没办法保证所有的内容都是关键信息，也就没办法保证大家都能持续的维持注意力，因此在关键的信息节点，我们应该加大音量，提醒大家现在到了关键信息了，该收回注意力听我讲话了。这就像写文章时，重点内容加粗加黑一个道理。一篇长文，如果通篇无段落、无加粗，是很难成为好文章的，同理演讲也是。

必要条件：费尽心思

最后的最后，我觉得高质量的分享一定是费尽心思，花费大量时间来准备的。就以这篇文章为例，我花了一整个周六的时间去撰写，中间调整过若干次结构与标题。为了更好证明论据，把很多之前别人的分享翻出来做论证支撑。

确实，现在大家工作都很忙，没时间好好准备。我经常会催我们月会上要分享的同学的 PPT，但基本都很难提早催到，都是最后时间节点之前的临时之作。这样的情况下，怎么能保证质量有多高呢？

所以我觉得还是要回归到我最初提的那个问题，为什么要分享？如果我们的分享是真的想帮助到他人，那肯定会好好要求自己的分享具有一定质量，否则我怎么帮助到他人呢？如果我的文章、我的 PPT 对他人没有帮助，这不是反而浪费了大家的时间。如果我自认为还没准备好，可以选择到下次机会再分享，然后好好准备。

我相信，如果能费尽心思帮助他人，肯定也能成就自己。

当前，全球已经进入数字经济时代，各国都十分重视数字经济建设。我国更是高度重视数字经济发展，在2021全国两会上，多次提及要大力发展数字经济，打造数字经济新优势，建设数字中国。在“中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要”（以下简称“十四五”规划）中，将“加快数字化发展，建设数字中国”单列篇章，提出：迎接数字时代，激活数据要素潜能，推进网络强国建设，加快建设数字经济、数字社会、数字政府，以数字化转型整体驱动生产方式、生活方式和治理方式变革。

 

云计算：数字经济新引擎

在十四五规划“加快推动数字产业化”的小节中，提出将发展云计算、大数据、物联网、工业互联网、区块链、人工智能、虚拟现实和增强现实等数字经济重点产业。在对应的专栏中，云计算位列数字经济重点产业第一位。

而在产业数字化转型方面，十四五规划提出要实施“上云用数赋智”行动，推动数据赋能全产业链协同转型。这里，“上云”的云也就是云计算，“上云”是指企业要完成数字化和网络化，企业通过“上云”才能将经营管理过程中的数据积累下来，这是“用数”和“赋智”的基础和前提条件。

云计算不仅能够推动数字产业化，对产业数字化转型也有重要作用。云计算是我国新型基础设施建设的核心所在，也是建设数字中国的基础设施所在。云计算能够为数字经济的发展提供技术支持，是推动数字经济发展的重要驱动力，是新一代信息技术产业体系创新发展的重要支撑。培育壮大云计算行业，对推动数字化发展，打造数字经济新优势具有重要意义。

云原生赋能数字经济
引领数字化转型升级

云计算发展至今，从最初的物理机到虚拟机，再到容器，而互联网架构也从集中式架构到分布式架构，再到云原生架构。如今，云原生作为云计算的再升级，已经成为了云计算未来的发展方向。作为整个云计算生态中发展最迅速的一条主线脉络，云原生让云计算变得标准、开放、简单高效、触手可及。

云原生是企业实现数字化转型的最短路径。以容器、微服务和DevOps为代表的云原生技术实现了应用的敏捷开发，大幅提升了交付速度，降低了业务的试错成本，能够快速响应用户需求，增强用户体验、加速业务创新。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。如今企业“上云”，首选必然是云原生。企业能够通过云原生实现应用云化，充分发挥云的价值，从而快速激活数字创新能力。

当前，云原生技术飞速发展，作为下一代云计算技术，云原生应用敏捷开发、运维与管理等核心能力正在定义云原生2.0。未来，云原生2.0将会和云计算一起持续进化，逐渐成为数字经济时代的基础设施，成为下一代数字经济体系的基础，从而赋能数字经济，引领数字化转型升级，促进我国数字经济发展。

谐云助力数字经济高速发展

谐云作为云原生领头羊企业，一直以来都以“成为中国数字基础设施建设云原生软件领军企业”为愿景，从2009年从浙江大学SEL实验室起步以来，曾是云计算云原生行业的黄埔军校，为云计算行业输送了大量顶尖技术人才。谐云多年来持续专注云原生，深耕云计算技术，专精于PaaS平台技术研究，是国内为数不多掌握底层核心技术的容器云产品及解决方案提供商。

谐云助力数字经济的独特优势十分明显：拥有众多浙大高层次技术专家和高精尖人才，由此带来了业内领先的技术研发能力；技术实力雄厚，拥有软著36项，申请发明专利26项，已获得发明专利2项，出版了国内第一本深度剖析容器云技术的专著；大规模生产环境落地实践经验沉淀，落地经验丰富，服务了百余家企业，助力多行业的龙头企业进行数字化转型。这些优势能够为数字经济发展提供坚实的人才支持和技术保障。

各行业数字转型方案

谐云作为国内最早布局云原生的企业之一，利用自己的容器云等核心技术，已经服务了百余家企业，其中，交通、通信、金融、能源等行业的头部企业都选择了与谐云合作，进行数字化转型。

不管是交通、通信，还是金融、能源等行业，其亟待解决的问题都主要是以下几点：资源利用率低；资源管理复杂；业务种类繁多需求变化快；运维成本过高；应用访问压力大；监管层要求高等。谐云利用自己的底层核心技术和容器云产品，依托大规模生产环境落地实践经验沉淀，提供个性化的解决方案，帮助交通、能源、工业等传统基础设施进行数字化、网络化、智能化改造升级，对推进数字基础设施建设促进数字经济发展作出了巨大贡献。

1金融行业

在谐云和某银行的合作中，谐云利用自己的核心技术制定了完整的DevOps工具链、管理平台统一调度资源和容器技术支撑应用快速部署K8S等解决方案，助力其数字化建设，有效降低了资源投入成本，显著提升了开发、交付、运维的工作效率，帮助其业务快速敏捷上线。

2通信行业

谐云和某移动在线的合作中，谐云观云台为中移在线提供了强大的底层PaaS平台，支撑其数千台机器和数千规模节点。而标准DevOps工具将发布交付过程自动化。容器PaaS自动化运维能力，实现秒级故障隔离与自动修复。APM全链路监控，直接定位故障根因。容器结合混部调度提高资源利用。为近亿用户提供了更好的服务及更优的体验，从而帮助某移动在线成功进行数字化转型。

3能源行业

在谐云和某国家电网的合作中，谐云制定了以下几种解决方案：统一监控/考核指标全面覆盖，深度定制开发指标采集，定制专有功能，对执行超过指定时间的事务，给出详细信息。从而助力某国家电网准确、快速的定位问题所在的节点，解决实际工作中故障定位难、协调部门多的问题，提高故障处理效率，为辽电赢得更好的客户体验。

4物流行业

在谐云和某物流企业的合作中，谐云利用容器技术作支撑，逐步将功能代码解耦。使用Kubernetes为应用服务做弹性支撑。应用性能监控发现应用中的慢方法、慢SQL。从而助其完善服务化所需技术能力，并建立统一规划和标准规范，明确系统边界，实现服务共享，与开发模式和开发流程结合，提高开发效率和产品质量。

5工业行业

在谐云和某化学集团的合作中，谐云观云台提供了以下解决方案：统一交付方式/规模化一键部署，构建统一容器平台，解决多环境多组件依赖。从而助力其快速响应市场，从研发交付、平台转型、业务创新等维度切入升华其信息系统水平，以服务化方式为工业企业数字化转型升级提供帮助。

响应政策引领，坚持顺势而为。在数字化转型浪潮的驱动下，谐云作为承载数字化使命的企业，未来还将继续探索技术边界，使用自己的云原生核心技术，持续为各行各业的客户提供数字化转型基础设施的产品、技术与服务，助力建设新型数字基础设施，从而推动数字经济建设，为建设数字中国贡献力量。

作者 | 邓学祥（祥翼）
来源 | Serverless 公众号

高德从 FY21 财年开始启动 Serverless 建设，至今一年了，高德 Serverless 业务的峰值超过十万 qps 量级，平台从 0 到 1，qps 从零到十万，成为阿里集团内 Serverless 应用落地规模最大的 BU，这中间的过程是怎么样的？遇到过哪些问题？高德为什么要搞 Serverless/Faas？是如何做 Serverless/Faas 的？技术方案是什么样的？目前进展怎么样？后续又有哪些计划？本文将和大家做一个简单的分享。

1. Why-高德为什么要搞 Serverless

高德为什么要搞 Serverless？背景原因是高德 FY21 财年启动了一个客户端上云项目。客户端上云项目的主要目的是为了提升客户端的开发迭代效率。

以前客户端业务逻辑都在端上，产品需求的变更需要走客户端发版才能发布，而客户端发版需要走各种测试流程、灰度流程，解决客户端崩溃等问题，目前的节奏是一个月一个版本。

客户端上云之后，某些易变的业务逻辑放到云上来。新的产品需求在云端来开发，不用走月度的版本发布，加快了需求的开发迭代效率，离产研同频的理想目标又近了一步（为什么要说“又”，是因为高德之前也做了一些优化往产研同频的方向努力，但是我们希望云端一体化开发可以是其中最有效的一个技术助力）。

1.1 目标：客户端开发模式–端云一体

虽然开发模式从以前的端开发转变为现在的云 + 端开发，开发同学应该还是原来负责相应业务的同学，但是大家知道，服务端开发和客户端开发显然是有差异的，客户端开发是面向单机模式的开发，服务端开发通常是集群模式，需要考虑分布式系统的协调、负载均衡、故障转移降级等各种复杂问题。如果使用传统的服务端模式来开发，这个过渡风险就会比较大。

Faas 很好地解决了这一问题。我们结合高德客户端现有的 xbus 框架（一套客户端上的本地服务注册、调用的框架），扩展了 xbus-cloud 组件，使得云上的开发就像端上开发一样，目标是一套代码、两地运行，一套业务代码既能在客户端上运行，也能在服务端上运行。

高德客户端主要有三个端：IOS、android、车机（类 Linux 操作系统）。主要有两种语言：C++ 和 Node.js。传统地图功能：如地图显示、导航路径显示、导航播报等等，由于需要跨三个端，采用的 C++ 语言来开发。地图导航基础之上的一些地图应用功能，如行前/行后卡片、推荐目的地等，主要用 Node.js 来开发。

FY20 财年淘系前端团队开发了 Node.js Faas runtime。高德客户端上云项目，Node.js 的部分就采用了现有的淘系的 Node.js runtime，来接入集团的 Faas 平台，完成 Node.js 这部分的一些业务上云。2020 年十一期间很好地支撑了高德的十一出行节业务。

C++ Faas 没有现有的解决方案，因此我们决定在集团的基础设施之上做加法，新建 C++ Faas 基础平台，来助力高德客户端上云。

1.1.1 端云一体的最佳实践关键：客户端和 Faas 之间的接口抽象

原本客户端的逻辑移到 Faas 服务端上来，或者新的需求一部分在 Faas 服务端上开发，这里的成败关键点在于：客户端和 Faas 的接口协议定义，也就是 Faas 的 API 定义，好的 API 定义除了对系统的可维护性有好处以外，对后续支撑业务的迭代开发也很重要，好的 API 定义请参考谷朴大神的文档：《API 设计最佳实践的思考》。

理想情况下：客户端做成一个解析 Faas 返回结果数据的一个浏览器。浏览器协议一旦定义好，就不会经常变换，你看 IE、Chrome 就很少更新。当然我们的这个浏览器会复杂一些，我们这个浏览器是地图浏览器。如何检验客户端和 Faas 之间的接口定义好不好，可以看后续的产品需求迭代，如果有些产品需求迭代只需要在 Faas 上完成，不需要客户端的任何修改，那么这个接口抽象就是成功的。

1.2 BFF 层开发提效

提到高德，大家首先想到的应该是其工具属性：高德是一个导航工具（这个说法现在已经不太准确了，因为高德这几年在做工具化往平台化的转型，我们要做万能的高德，高德的交易类业务正在兴起，高德打车、门票、酒店等业务发展很迅猛）。

针对高德导航来说，相比集团其他业务（如电商）来说，有大量的只读场景是高德业务的一大技术特点。这些只读场景里，大量的需求是 BFF（Backend For Frontend）类型的只读场景。为什么这么说？因为导航的最核心功能，例如 routing、traffic、eta 等都是相对稳定的，这部分的主要工作在持续不断地优化算法，使得高德的交通更准，算出的路径更优。这些核心功能在接口和功能上都是相对比较稳定的，而前端需求是多变的，例如增加个路径上的限宽墩提示等。

Faas 特别适合做 BFF 层开发，在 Faas 上调用后端相对稳定的各个 Baas 服务，Faas 服务来做数据和调用逻辑封装、快速开发、发布。在业界，Faas 用的最多的场景也正是 BFF 场景（另外一个叫法是 SFF 场景，service for frontend）。

1.3 Serverless 是云时代的高级语言

FY21，高德是集团内第一个全面上云的 BU，虽然高德已经全面上云了，但是这还不是云时代的终局，目前主要是全面 pouch 化并上云，容器方面做了标准化，在规模化、资源利用率方面可以全面享受云的红利，但是业务开发模式上基本上还和以前一样，仍是一个大型的分布式系统的写法。对于研发模式来说还并没有享受云的红利，可以类比为我们现在是在用汇编语言的方式来写跑在云上的服务。而 Serverless、云原生可以理解为云时代的高级语言，真正做到了 Cloud as a computer，只需要关注于业务开发，不需要考虑大型分布式系统的各种复杂性。

1.4 Go-Faas 补充 Go 语言生态

前面讲到了因为客户端上云项目，我们在阿里云 FC（函数计算）团队之上做加法，开发了 C++ Faas Runtime。不仅如此，我们还开发了 Go-Faas，我们为什么会做 Go-Faas 呢？这里也简单介绍一下背景，高德服务端 Go 部分的 qps 峰值已超百万。高德已补齐了阿里各中间件的 Go 客户端，和集团中间件部门共建。可观测性、自动化测试体系也基本完善，目前 Go 生态已基本完善。补齐了 Go-Faas 之后，我们就既能用 Go 写 Baas 服务，又能用 Go 写 Faas 服务了，在不同的业务场景采用不同的服务实现方式，Go-Faas 主要应用于上文提到的 BFF 场景。

2. How-技术方案介绍：在集团现有基础设施之上做加法

2.1 整体技术架构

上文讲了我们为什么要做这个事情，接下来讲我们具体是怎么做这个事情的，是如何实现的，具体的技术方案是什么样的。

本着在集团现有的基础设施、现有的中间件基础之上做加法的思想，我们和 CSE、阿里云 FC 函数计算团队合作共建，开发了 C++ Faas Runtime 和 Go Faas Runtime。整体和集团拉通的技术架构如下图所示，主要分为研发态、运行态、运维态三个部分。

2.1.1 运行态

先说运行态，业务流量从我们网关进来，调用到 FC API Server，转发到 C++/Go Faas Runtime，runtime 来完成用户函数里的功能。runtime 的架构本文下一章节会具体介绍。

和 runtime container 一起部署的有监控、日志、Dapr 各种 side car，side car 来完成各种日志采集上报功能，dapr side car 来完成调用集团中间件的功能。

另外目前 dapr 还在试点的阶段，调用中间件主要是通过 Broker 和各个中间件 proxy 来完成，中间件调用的有HSF、Tair、metaq、diamond 等中间件 proxy。

最后 Autoscaling 模块来管理函数实例的扩缩容，达到函数自动伸缩的目的。这里的调度就有各种策略了，有根据请求并发量的调度、函数实例的 CPU 使用率的调度。也能提前设置预留实例数，避免缩容到 0 之后的冷启动问题。

底层调用的是集团 ASI 的能力，ASI 可以简单理解为集团的 K8S+ sigma（集团的调度系统），最终的部署是 FC 调用 ASI 来完成函数实例部署，弹性伸缩的，部署的最小单位是上图中的 pod，一个 pod 里包含 runtime container 和 sidecar set container。

2.1.2 研发态

再来看研发态，运行态决定函数是如何运行的，研发态关注函数的开发体验，如何方便地让开发者开发、调试、部署、测试一个函数。

C++ Faas 有个跨平台的难点问题，C++ Faas runtime 里有一些依赖库，这些依赖库没有 Java 依赖库管理那么方便。这样依赖库的安装比较麻烦，Faas 脚手架就是为了解决这个问题，调用脚手架，一键生成 C++ Faas 示例工程，安装好各种依赖包。为了本地能方便地 debug，开发了一个 C++ Faas Runtime Boot 模块，函数 runtime 启动入口在 boot 模块里，boot 模块里集成 runtime 和用户 Faas 函数，可以对 runtime 来做 debug 单步调试。

我们和集团 Aone 团队合作，函数的发布集成到 Aone 环境上了，可以很方便地在 Aone 上来发布 Go 或者 C++ Faas，Aone 上也集成了一键生成 example 代码库的功能。

C++ 和 Go Faas 的编译都依赖相应的编译环境，Aone 提供了自定义编译镜像的功能，我们上传了编译镜像到集团的公共镜像库，函数编译时，在函数的代码库里指定相应的编译镜像，编译镜像里安装了 Faas 的依赖库、SDK等。

2.1.3 运维态

最后来看函数的运维监控，runtime 内部集成了鹰眼、sunfire 采集日志的功能，runtime 里面会写这些日志，通过 sidecar 里的 agent 采集到鹰眼、或者 sunfire 监控平台上去（FC 是通过 SLS 来采集的）之后，就能使用集团现有的监控平台来做 Faas 的监控了，也能接入集团的 GOC 报警平台。

2.2 C++/Go Faas Runtime 架构

上面讲的是和 Aone、FC/CSE、ASI 集成的一个整体架构，Runtime 是这个整体架构的一部分，下面具体讲讲 Runtime 的架构是怎样的，Runtime 是如何设计和实现的。

最上面部分的用户 Faas 代码只需要依赖 Faas SDK 就可以了，用户只需要实现 Faas SDK 里的 Function 接口就能写自己的 Faas 了。然后如果需要调用外部系统，可以通过 SDK 里的 Http Client 来调用，如果要调用外部中间件，通过 SDK 里的 Diamond/Tair/HSF/metaq Client 来调用中间件就可以。SDK 里的这些接口屏蔽了底层实现的复杂性，用户不需要关心这些调用最后是如何实现，不需要关心 runtime 的具体实现。

SDK 层就是上面提到的 Function 定义和各种中间件调用的接口定义。SDK 代码是开发给 Faas 用户的。SDK 做的比较轻薄，主要是接口定义，不包含具体的实现。调用中间件的具体实现在 Runtime 里有两种实现方式。

往下是 Runtime 的一个整体架构。Starter 是 runtime 的启动模块，启动之后，runtime 自身是一个 Server，启动的时候根据 Function Config 模块的配置来启动 runtime，runtime 启动之后开启请求和管理监听模式。

再往下是 Service 层，实现 SDK 里定义的中间件调用的接口，包含 RSocket 和 dapr 两种实现方式，RSocket 是通过 RSocket broker 的模式来调用中间件的，runtime 里集成了 dapr（distributed application runtime），调用中间件也可以通过 dapr 来调用，在前期 dapr 试点阶段，如果通过 dapr 调用中间件失败了，会降级到 rsocket 的方式来调用中间件。

再往下就是 rsocket 的协议层，封装了调用 rsocket 的各种 metadata 协议。dapr 调用是通过 grpc 方式来调用的。

最下面一层就是集成了 rsocket 和 dapr 了。

rsocket 调用还涉及到 broker 选择的问题，upstream 模块来管理 broker cluster、broker 的注册反注册、keepalive 检查等等，LoadBalance 模块来实现 broker 的负载均衡选择以及事件管理、连接管理、重连等等。

最后 runtime 里的 metrics 模块负责鹰眼 trace 的接入，通过 filter 模式来拦截 Faas 链路的耗时，并输出鹰眼日志。打印 sunfire 日志，供 sidecar 去采集。下图是一个实际业务的 sunfire 监控界面：

2.2.1 Dapr

dapr 架构如下图所示，具体可以参考官方文档。

runtime 里以前调用中间件是通过 rsocket 方式来调用的，这里 rsocket broker 会有一个中心化问题，为了解决 outgoing 流量去中心化问题，和集团中间件团队合作引入了 dapr 架构。只是 runtime 层面集成了 dapr，对于用户 Faas 来说无感知，不需要关心具体调用中间件是通过 rsocket 调用的还是通过 dapr 调用的。后面 runtime 调用中间件切换到 dapr 之后，用户 Faas 也是不需要做任何修改的。

3. How-业务如何接入 Serverless

如前文所述，接入统一在 Aone 上接入。提供了 C++ Faas/Go Faas 的接入文档。提供了函数的 example 代码库，代码库有各种场景的示例，包括调用集团各种中间件的代码示例。C++ Faas/Go Faas 的接入对整个集团开发，目前已经有一些高德以外的 BU，在自己的业务中落地了 C++ /Go Faas。Node.js Faas 使用淘宝提供的 runtime 和模板来接入，Java Faas 使用阿里云 FC 提供的 runtime 和模板来接入就可以了。

3.1 接入规范-稳定性三板斧：可监控、可灰度、可回滚

针对落地新技术大家可能担心的稳定性问题，我们的应对法宝是阿里集团的稳定性三板斧：可监控、可灰度、可回滚。建立 Faas 链路保障群，拉通上下游各相关业务方、基础平台一起，按照集团的 1-5-10 要求，共同努力做到 1 分钟之内响应线上报警、快速排查；5 分钟之内处理；10 分钟之内恢复。

为了规范接入过程，避免犯错误引发线上故障，我们制定了 Faas 接入规范和 checkList，来帮助业务方快速使用 Faas。

可监控、可灰度、可回滚是硬性要求，除此之外，业务方如果能做到可降级就更好了。我们的 C++ 客户端上云业务，在开始试点阶段，就做好了可降级的准备，如果调用 Faas 端失败，本次调用将会自动降级到本地调用。基本对客户端功能无损，只是会增加一些响应延迟，另外客户端上该功能的版本，可能会比服务端稍微老一点，但是功能是向前兼容的，基本不影响客户端使用。

4. Now-我们目前的情况

4.1 基础平台建设情况

• Go/C++ Faas Runtime 开发完成，对接 FC-Ginkgo/CSE、Aone 完成，已发布稳定的 1.0 版本。
• 做了大量的稳定性建设、优雅下线、性能优化、C 编译器优化，使用了阿里云基础软件部编译器优化团队提供的编译方式来优化 C++ Faas 的编译，性能提升明显。
• C++/Go Faas 接入鹰眼、sunfire 监控完成，函数具备了可观测性。
• 池化功能完成，具备秒级弹性的能力。池化 runtime 镜像接入 CSE，扩一个新实例的时间由原来的分钟级变为秒级。

4.2 高德的 Serverless 业务落地情况

C++ Faas 和 Go Faas 以及 Node.js Faas 在高德内部已经有大量的应用落地。举几个例子：

上图中的前两个图是 C++ Faas 开发的业务：长途天气、沿途搜。后两个截图是 Go-Faas 开发的业务：导航 tips、足迹地图。

高德是阿里集团内 Serverless 应用落地规模最大 的BU，已落地的 Serverless 应用，日常峰值超过十万 qps 量级。

4.3 主要收益

高德落地了集团内规模最大的 Serverless 应用之后，都有哪些收益呢？

首先第一个最重要的收益是：开发提效。我们基于 Serverless 实现的端云一体组件，助力了客户端上云，解除了需要实时的客户端发版依赖问题，提升了客户端的开发迭代效率。基于 Serverless 开发的 BFF 层，提升了 BFF 类场景的开发迭代效率。

第二个收益是：运维提效。利用 Serverless 的自动弹性扩缩容技术，高德应对各种出行高峰就更从容了。例如每年的十一出行节、五一、清明、春节的出行高峰，不再需要运维或者业务开发同学在节前提前扩容，节后再缩容了。高德业务高峰的特点还不同于电商的秒杀场景。出行高峰的流量不是在 1 秒内突然涨起来的，我们目前利用池化技术实现的秒级弹性的能力，完全能满足高德的这个业务场景需求。

第三个收益是：降低成本。高德的业务特点，白天流量大、夜间流量低，高峰值和低谷值差异较大，时间段区分明显。利用 Serverless 在夜间流量低峰时自动缩容技术，极大地降低了服务器资源的成本。

5. Next-后续计划

• FC 弹内函数计算使用优化，和 FC 团队一起持续优化弹内函数计算的性能、稳定性、使用体验。用集团内丰富的大流量业务场景，来不断打磨好 C++/Go Faas Runtime，并最终输出到公有云，普惠数字化转型浪潮中的更多企业。
• Dapr 落地，解决 outcoming 流量去中心化问题，逐步上线一些 C++/Go Faas，使用 Dapr 的方式调用集团中间件。
• Faas 混沌工程，故障演练，逃生能力建设。Faas 在新财年也会参与我们 BU 的故障演练，逐一解决演练过程中发现的问题。
• 接入边缘计算。端云一体的场景下，Faas + 边缘计算，能提供更低的延时，更好的用户体验。

以上要做的事情任重道远，另外 FY22 财年我们部门还会做云原生的试点和落地。技术同学都知道，从技术选型、技术原型到实际业务落地，这之间还有很长的路要走。

欢迎对 Serverless、云原生、或者 Go 应用开发感兴趣，想一起做点事情的小伙伴来加入我们（不管之前是什么技术栈，英雄不问出处，投简历到 gdtech@alibaba-inc.com，邮件主题为：姓名-技术方向-来自 Serverless），这里有大规模的落地场景和简单开放的技术氛围，欢迎自荐或推荐！

本文整理自阿里巴巴高级技术专家–祥翼在【阿里云 Serverless Developer Meetup 上海站】上的分享
ppt 获取方式：关注 Serverless 公众号，后台对话框回复“ppt”即可
直播回放观看地址：https://developer.aliyun.com/live/246653

来源 | 阿里巴巴云原生公众号

阿里巴巴开源的混沌工程项目 ChaosBlade 通过 CNCF TOC 投票，顺利推进 CNCF Sandbox。CNCF 全称 Cloud Native Computing Foundation (云原生计算基金会) ，旨在为云原生软件构建可持续发展的生态系统，服务于厂商中立的快速增长的开源项目，如 Kubernetes、Prometheus、Envoy 等。

ChaosBlade github 地址：
https://github.com/chaosblade-io/chaosblade

项目介绍

ChaosBlade 是阿里巴巴 2019 年开源的混沌工程项目，包含混沌工程实验工具 chaosblade 和混沌工程平台 chaosblade-box，旨在通过混沌工程帮助企业解决云原生过程中高可用问题。实验工具 chaosblade 支持 3 大系统平台，4 种编程语言应用，共涉及 200 多个实验场景，3000 多个实验参数，可以精细化地控制实验范围。混沌工程平台 chaosblade-box 支持实验工具托管，除已托管 chaosblade 外，还支持 Litmuschaos 实验工具。已登记使用企业 40 多家，其中已在工商银行、中国移动、小米、京东等企业中落地使用。

核心能力

ChaosBlade 具备以下功能特点：

• 丰富的实验场景：包含基础资源（CPU、内存、网络、磁盘、进程、内核、文件等）、多语言应用服务（Java、C++、NodeJS、Golang 等）、Kubernetes 平台（覆盖 Container、Pod、Node 资源场景，包含上述实验场景）。
• 多样化的执行方式：除了使用平台白屏化操作，还可以通过工具自带的 blade 工具或者 kubectl、编码的方式执行。
• 便捷的场景扩展能力：所有的实验场景遵循混沌实验模型实现，并且不同层次场景对应不同的执行器，实现简单，易于扩展。
• 实验工具自动化部署：无需手动部署实验工具，实现实验工具在主机或集群上自动化部署。
• 支持开源实验工具托管：平台可托管业界主流的实验工具，如自身的 chaosblade 和外部的 litmuschaos 等。
• 统一混沌实验用户界面：用户无需关心不同工具的使用方式，在统一用户界面进行混沌实验。
• 多维度实验方式：支持从主机到 Kubernetes 资源，再到应用维度进行实验编排。
• 集成云原生生态：采用 Helm 部署管理，集成 Prometheus 监控，支持云原生实验工具托管等。

架构设计

Chaosblade-box 架构如下：

通过控制台页面可实现 chaosblade、litmuschaos 等已托管工具自动化部署，按照社区建立的混沌实验模型统一实验场景，根据主机、Kubernetes、应用来划分目标资源，通过目标管理器来控制，在实验创建页面，可以实现白屏化的目标资源选择。平台通过调用混沌实验执行来执行不同工具的实验场景，配合接入 prometheus 监控，可以观察实验 metric 指标，后续会提供丰富的实验报告。

Chaosblade-box 的部署也非常简单，具体可以查看：_https://github.com/chaosblade-io/chaosblade-box/releases_。

客户案例

未来规划

ChaosBlade 未来以云原生为基础，提供面向多集群、多环境、多语言的混沌工程平台和混沌工程实验工具。实验工具将继续聚焦在实验场景丰富度和稳定性方面，支持更多的 Kubernetes 资源场景和规范应用服务实验场景标准，提供多语言实验场景标准实现。混沌工程平台聚焦在简化混沌工程部署实施方面，后续会托管更多的混沌实验工具和兼容主流的平台，实现场景推荐，提供业务、系统监控集成，输出实验报告，在易用的基础上完成混沌工程操作闭环。欢迎大家加入社区，共同推动混沌工程领域发展，切实在企业中落地，构建高可用的分布式系统。

本文转载自公众号：HelloJava。

云原生这个概念已经越来越深入人心，但对“云原生到底是什么？”这个问题，仍然是各种各样的解读，最近对云原生具体是什么有了点感触，于是写下来分享和探讨下。

我现在认为云原生其实是让众多的公司，通过基于云的产品迅速获得在构建一个现在这个时代的应用（是不是有点像 AWS 一直讲的 Modern Applications）所必需的各种基础能力（如：极强的规模伸缩性、极高的可用性、极低的创新/运营成本、大数据的分析/运营能力等等），而不需要像以前的很多公司，为了具备这些能力，投入巨大，或者用另外一句话说：云原生就是专业的基础能力普惠化，随手可得。

当今时代的应用和多年前的应用面临的状况差别太大，这个差异和当今业务面临的激烈竞争和玩法有很大的关系，我以前一直觉得像阿里在发展过程中积累的很多能力，外面很少有公司会需要，就像当年百亿、千亿美金的公司是多么难才出现，但现在看来则完全不一样，所以这也奠定了当今时代的应用在技术层面能力的要求也远不一样，简单说几个点：

1. 对可用性的要求远高于以前的应用：现在的应用通常一上线对可用性要求就已经不低了，因为一旦出问题就很容易把用户送给竞对；
2. 对伸缩性的能力要求也远比以前高，主要体现在两个方面：一是团队规模，现在的业务公司很容易迅速发展到百人以上，而百人以上的研发效率如何保持尽量不下降，这对系统的伸缩能力有着很高的要求；二是用户规模，现在众多业务的用户规模可以很快地突破百万、千万规模，这就要求系统必须能根据用户规模快速地伸缩；
3. 创新和运营的成本必须低：业务竞争无比激烈，快是关键，所以怎么在不需要太大投入的情况下快速上线各种业务，是无比重要的；另一个方面就是运营的成本，这个是和现在应用的用户规模、激烈竞争密切相关的；
4. 大数据的玩法：现在的很多业务对获客、推荐、搜索等的大数据化要求还是相当高的。

阿里是一家在自身发展过程中，逐步碰到上述的挑战（当年的竞争环境基本还不会要求一个业务上来就把各种能力具备好），但以前也没有云可用，所以在发展过程中不断积累各种能力，现在通过开源、云商业化对外输出这些能力，使得即使到了现在这样的竞争环境下，各种有业务创新想法的同学们，还是可以像当年一样快速上线业务，而不是要先投入巨多力量、花费巨多时间把需要的基础能力打磨出来。

我自己并没有完全经历阿里的发展过程，接下来主要还是简单说下我自己经历的一些。

1. 在 2007 年，淘宝在基础能力上面临的最大问题是伸缩性，两个现象当时都出现了：用户数量大量增加，加机器已经基本要加到瓶颈了；研发人员大量增长，研发效率下滑非常明显。在这个阶段，淘宝做了一轮非常重要的架构改造，磨练出了例如服务框架、消息中间件、分库分表方案、分布式文件系统、分布式缓存等基础技术产品，结合业务架构的重新设计，很好地解决掉了伸缩性的问题。
2. 在 2009 年，淘宝面临了可用性问题，经常出各种故障，于是开始积累各种监控、快速恢复、tracing、系统设计里如非关键路径异步化等技能。可用性这块的投入一直在持续，到后来为解决 双11 这种特殊情况的可用性、确定性诉求而创造的全链路压测；通过同城双活、异地多活的多机房体系构建的强容灾能力以及快速恢复能力等；以及在线下场景加入后来面临的不一样的可用性方案等。各种场景的高可用方案的积累，也使得业务的可用性越来越有保障。
3. 2011 年左右，阿里开始觉得未来在资源投入上的运营成本可能会很夸张，于是在 2011 年开始通过容器化来提升机器使用效率、持续进行成本优化，后来又持续通过云资源弹性来解决 双11 这类型的短时高峰的成本投入问题，通过在线离线混部解决大数据机器投入越来越大、在线机器集群利用率不高产生浪费的问题，经过多年努力，使得业务在高速增长的情况下，机器资源投入上的运营成本还是相对可控的。

如上文所讲，阿里是依靠巨大的人力投入、场景打磨和多年的持续投入才逐渐形成了完备的能力。而现在的业务，则可以用云原生的方式构建，使自身一上来就具备这些能力，至少能够让自己在如今激烈且要求更高的业务竞争环境中，不会在这些基础能力上拖后腿，以此可以花更多的精力、时间、资源在真正的业务创新上。这样具象化的云原生对整个社会的创新还是相当有价值的。

来源 | 阿里巴巴云原生公众号

近日，Gartner 发布了《2021 年 Gartner APM 魔力象限》，阿里云成为国内唯一入选的云厂商，产品能力和战略愿景获得 Gartner 分析师高度认可。

Gartner 是全球最具权威的 IT 研究与顾问咨询公司，其每年的 Gartner  APM 魔力象限报告对于企业选择 APM 工具提供了可靠的参考标准。本次评测应用实时监控服务（ARMS）作为阿里云 APM 的核心产品，联合云监控以及日志服务共同参与。Gartner 评价阿里云 APM：

• 中国影响力最强：阿里云是中国最大的云服务提供商，阿里云用户可以使用云上监控工具来满足其可观测性需求。
• 开源集成：阿里云非常重视将开源标准和产品（例如 Prometheus）集成到其平台中。
• 成本优势：与在阿里云上使用第三方 APM 产品相比，阿里云 APM 产品具有更高的成本效益。

图片来源：2021 Gartner APM 魔力象限

当下，企业正逐步加快数字化转型的步伐，导致 IT 系统更新频繁，应用复杂度急剧升高。微服务、容器化等之前仅有技术型公司关注的前沿技术也逐渐在传统企业中兴起，而云服务早已经成为企业大规模运营数字业务所必备的技术服务。以用户体验为核心的应用性能管理（APM）受到广泛关注，APM 在帮助企业实现数字化转型及智能化运维的道路上表现出巨大的价值。

例如，用户打开某个应用后，可能涉及上千次调用。打开这样一个页面的响应时间，不仅是前端应用的指标，也是所有服务中心都应该去关心的重要指标。当出现问题，传统运维通过排查、电话通知的操作，不仅低效还容易丢失信息。如何实时监控整个链路的运行情况，出现问题快速定位根因，对应到责任人，这些是企业在服务化过程中亟需解决的问题。

2017 年，阿里将内部锤炼多年的监控工具对外，应用实时监控服务 ARMS 正式商业化。作为云原生一体化可观测性平台，ARMS 提供全栈式的性能监控和端到端的全链路追踪诊断能力，同时，结合阿里云日志服务（SLS）的日志数据分析能力以及云监控丰富的云服务与基础设施监控能力，用户可以轻松完成用户体验、应用、云服务、容器的一站式监控。

阿里云在 APM 领域不仅建立了丰富的产品布局，其产品能力也得到了众多客户的认可。道旅科技凭借 ARMS，在数分钟内搭建和启动了基于大数据平台的应用实时监控系统，极大地提升了 IT 人员的效率。华润万家不管在应用上出现任何问题，ARMS 都可以清楚地呈现问题出在哪一行代码，大大缩短了修复故障的时间。

随着企业数字化转型进程加速，企业各类应用程序的性能状况直接影响了数字化业务的顺利开展，APM 产品的市场需求仍在不断扩大。经过 10 多年的技术实践，阿里云已拥有国内规模最大的云原生产品家族和开源生态，提供云原生裸金属服务器、云原生数据库、容器服务、微服务、可观测、高可用等超过 100 款创新产品，让企业更加从容地迈向云原生架构。

时至今日，Kubernetes 虽然变成了云原生这套系统化方法论和开源技术的核心一环，但已经无法独立存在，而是与云原生生态中所有的技术形态息息相关。为了将云原生生态中的各个技术形态结合起来，帮助企业最大化资源利用效率，KubeSphere 打造了一个以 Kubernetes 为内核的云原生分布式操作系统，提供可插拔的开放式架构，无缝对接第三方应用，极大地降低了企业用户的使用门槛，解决了云原生产品体验的一致性这个痛点。

KubeSphere v3.1.0 的发布是 KubeSphere 的一个重大拐点，将混合多云从云端延伸到了边缘场景，实现应用与工作负载在云端和边缘节点进行统一分发和管理。同时进一步增强了多集群管理和多租户管理等企业级功能，优化了在更多场景下的使用体验。

KubeSphere 之所以能够如此快速发展，得益于开源社区带来的天然优势，以及社区里长期活跃的用户、贡献者积极参与社区，帮助推动产品和社区快速成长，我们坚持认为 KubeSphere 开源社区的每一位用户和贡献者朋友都是 KubeSphere 生态中的重要组成部分。

自从去年 12 月份的年度 meetup 之后，KubeSphere 社区组织的 Kubernetes meetup 与大家阔别了四个月。如今，Kubernetes meetup 重新启程，于五月和六月，在上海、杭州、深圳、成都这四个城市分别与大家见面，致力于汇聚各个城市的优秀云原生人才，连接 KubeSphere 社区与云原生开发者，促进对云原生的推广和实践。

活动议程

上海站是今年 Kubernetes meetup 的第一站，目前已基本确定讲师和议题。

时间地点

活动时间：5月15日 下午 13:00-18:00

签到时间：13:30-14:00

活动地点：上海市虹口区杨树浦路 188 号 2 号楼 102 赤兔创业咖啡

活动报名

上海站目前已经开启招募，若您希望获取经验，期待和各位极客交流，那就抓紧报名吧！位置有限，先到先得！

扫描下方二维码即可进入到报名页面进行报名，活动免费！

活动礼品

我们特别定制了 KubeSphere 全套纪念周边礼品：T恤、马克杯、纪念徽章、帆布袋、口罩等。

报名参与或者提交议题即可获得定制周边纪念品！

除了提供周边礼品之外，我们还会赠送各种云原生相关的硬核书籍，有电子工业出版社提供的 《Kubernetes 生产化实践之路》：

还有人民邮电出版社图灵原创提供的张磊大神的巨著《深入剖析 Kubernetes》：

 

你以为只有这两套书吗？当然不是，本次 meetup 还会送出以下书籍（机械工业出版社华章公司）：

 

现场参与互动即可获取以上书籍奖品哟~

提交主题分享

您充满了开发创意却无处施展吗？我们已经为您搭好舞台：Serverless、微服务、DevOps、开源、容器… 任何关于云原生和 KubeSphere 的观点、干货、技术实践、用户故事都是我们社区非常欢迎的。

目前上海站还有一个主题演讲空缺，其他城市站还有多个主题演讲空缺，我们面向大家公开招募。只要您有兴趣分享，就可以提交您的议题，采纳后即可获得讲师专属大礼包一份！

扫描下方二维码提交您的议题吧！

 

2020 活动现场精彩回顾

关于 KubeSphere

KubeSphere （https://kubesphere.io）是在 Kubernetes 之上构建的开源容器混合云，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能，包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、审计事件、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。

 ✨ GitHub：https://github.com/kubesphere

 💻 官网（中国站）：https://kubesphere.com.cn

 👨‍💻‍ 微信群：请搜索添加群助手微信号 kubesphere

作者 | 刘晓敏
来源 | 阿里巴巴云原生公众号

Seata 是一款简单易用，高性能、开源的一站式分布式事务解决方案。Seata 从2019 年 1 月开源后就受到了大家的追捧，目前已经有几百家企业在生产环境进行了技术的落地。

2020 年 4 月，我们开始基于 Seata 着手做多语言 golang 项目，经过一年时间的开发，很高兴 seata-golang 发布了 1.0.0 版本。

今年 4 月 17 号，有幸在成都 gopher meetup 上将 seata-golang 介绍给热衷于 golang 的 gopher。

会上我们向大家演示了如何利用 seata-golang 来接入到微服务中保证服务间的数据一致性，另外还向大家介绍了 Seata 的核心原理、MySQL driver 原理和接入、seata-golang 的未来规划，最后就大家关注的 Seata 相关的问题做了 QA。

Seata 原理

活动上，我们结合 seata-golang 的demo 和大家分享了 seata 的工作原理。如下图所示，是一个 seata at 模式的简单工作流程。

• TC（即图中右半部分）：Transaction coordinator，它是一个分布式事务协调器。
• TM：Transaction manager，它是一个事务管理器，负责全局事务的开启、提交和回滚。
• RM：Resource Manager，它是管理分支事务资源的，它加入全局事务组后，向 TC 报告分支事务的执行状态。
• XID：TM 开启全局事务时，会在 TC 创建一个 GlobalSession，GlobalSession 的全局唯一标识即为 XID。
• BranchID：RM 向 TC 注册分支事务后，在 TC 侧生成一个 BranchSession，BranchID 全局唯一标识这个 BranchSession。

当 RM 向 TC 报告分支执行失败时，TC 会标记这个 BranchSession 的状态为失败，然后 TM 发起回滚时，TC 根据 XID 找到所有成功执行的事务分支，通知他们进行回滚。

MySQL Driver

最近研发开源出来的mysql driver 项目，基于 go-sql-driver/mysql 1.5.0 版本开发，天然集成了 seata-golang 的分布式事务能力，完全支持 database/sql 库这层抽象，由于很多 orm 框架都基于 database/sql 做了封装，所以对 database/sql 的支持意味着 seata-golang 可以完美无缝地接入各种 orm 框架。

driver 的 mysqlTx 对象执行 Commit 或者 Rollback 时，会根据 mysqlConn 的 connCtx 是否有值来决定是否和 tc 交互，报告分支事务的执行状态。如果执行 Commit，connCtx 有值则把 sqlUndoItemsBuffer 中的 undoLog 和业务数据一起提交到数据库，然后报告 tc 事务分支提交的状态（成功还是失败），否则执行正常的提交。如果执行 Rollback，connCtx 有值则回滚然后向 tc 报告分支执行失败，tc 会根据这个状态回滚整个全局事务，connCtx 没有值则只需正常回滚。

上图是 undoLog json 序列化后的结构数据，我们可以看到这条数据修改之前，它的 name 是 “TXC”，修改之后它的 name 是 “GTS”，如果对它进行回滚，则生成一个反向的补偿语句：update product set name = ‘TXC’ since = 2014 where id = 1。如果是 insert 操作，则反向补偿操作为 delete，如果是一个 delete 操作则方向补偿操作为 insert。

未来规划

社区已经有小伙伴将 mysql driver集成到 gorm，并将 seata-golang 用到生产环境。目前 seata-golang 只支持 mysql，小伙伴们可根据 mysql driver 的思路，实现 pgsql 和 oracle 的 driver 。这也是未来 seata-golang  将要规划做的事情之一。

随着 go 语言微服务开发的兴起，分布式事务问题会越来越受到关注，希望社区的朋友可以更多参与进来完善这个框架，让它发挥生命力、服务社区、创造价值。

如果你有任何疑问，欢迎钉钉扫码加入交流群【钉钉群号 33069364】

作者简介

刘晓敏(GitHubID dk-lockdown)，目前就职于 h3c 成都分公司，擅长使用 Java/Go 语言，在云原生和微服务相关技术方向均有涉猎，目前专攻分布式事务。

参考资料

• seata 官方：https://seata.io
• java 版 seata：https://github.com/seata/seata
• seata-golang 项目地址：https://github.com/opentrx/seata-golang
• driver 地址：https://github.com/opentrx/mysql
• seata-golang go 夜读 b 站分享：https://www.bilibili.com/video/BV1oz411e72T
• 基于 getty 的 seata-golang 通信模型详解：http://seata.io/zh-cn/blog/seata-golang-communication-mode.html
• seata-golang 接入指南
• Go Mysql Driver 集成 Seata-Golang 解决分布式事务问题

2021 年 4 月 29 日，KubeSphere 开源社区激动地向大家宣布，KubeSphere 3.1.0 正式发布！为了帮助企业最大化资源利用效率，KubeSphere 打造了一个以 Kubernetes 为内核的云原生分布式操作系统，提供可插拔的开放式架构，无缝对接第三方应用，极大地降低了企业用户的使用门槛。

KubeSphere v3.1.0 主打 “延伸至边缘侧的容器混合云”，新增了对 “边缘计算” 场景的支持。同时在 v3.0.0 的基础上新增了 计量计费，让基础设施的运营成本更清晰，并进一步优化了在 “多云、多集群、多团队、多租户” 等应用场景下的使用体验，增强了 “多集群管理、多租户管理、可观测性、DevOps、应用商店、微服务治理” 等特性，更进一步完善交互设计提升了用户体验。

云原生产业联盟撰写的《云原生发展白皮书》提到，万物互联时代加速了云-边协同的需求演进，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求，向边缘下沉并通过中心进行统一交付、运维、管控，已经成为云计算的重要发展趋势。

面对这一发展趋势，KubeSphere 与 KubeEdge 社区紧密合作，将 Kubernetes 从云端扩展至边缘，以统一的标准实现了对边缘基础设施的纳管。通过与 KubeEdge 集成，解决了边缘节点纳管、边缘工作负载调度和边缘可观测性等难题，结合 KubeSphere 已有的多集群管理将混合多云管理延伸至边缘侧。

并且，v3.1.0 得到了来自青云 QingCloud 之外的更多企业与用户的贡献和参与，无论是功能开发、功能测试、缺陷报告、需求建议、企业最佳实践，还是提供 Bug 修复、国际化翻译、文档贡献，这些来自开源社区的贡献都为 v3.1.0 的发布和推广提供了极大的帮助，我们将在文末予以特别致谢！

解读 v3.1.0 重大更新

KubeSphere 3.1.0 增加了计量计费功能，支持集群、企业空间的多层级与多租户在应用资源消耗的计量与统计。通过集成 KubeEdge，实现应用快速分发至边缘节点。同时还提供了更强大的可观测性能力，如兼容 PromQL、内置主流告警规则、可视化对接钉钉、企业微信、Slack 和 Webhook 等通知渠道。DevOps 的易用性在 3.1.0 也上了一个台阶，例如内置多套常用流水线模板，支持多分支流水线和流水线复制等，关于重大更新详情请查看文末海报。

多维度计量计费，让 K8s 运营成本更透明

在企业运营和管理 Kubernetes 容器平台时，通常需要分析资源消耗，查看集群及其中租户的消费账单，洞察资源使用情况，分析基础设施运营成本。

在 KubeSphere 3.1.0 中，可从多个维度来分析平台资源消耗：

• 从集群维度，可查看每个集群资源消耗，深入到节点中分析运行的工作负载，精准规划每个节点中工作负载的资源使用状况。
• 从企业空间维度，可查看每个企业空间资源消耗，获取企业空间中项目、应用、工作负载的消费账单，分析多租户环境中各个租户的资源使用是否合理。

另外，除了可以通过界面查看和导出数据，KubeSphere 计量计费平台也提供了所有操作的 API。接下来在后续的版本里，会持续加强并构筑端到端完整的计量计费可运营系统。

边缘节点管理

KubeEdge 是一个开源的边缘计算平台，它在 Kubernetes 原生的容器编排和调度能力之上，实现了 云边协同、计算下沉、海量边缘设备管理、边缘自治 等能力。但 KubeEdge 缺少云端控制层面的支持，如果将 KubeSphere 与 KubeEdge 相结合，可以很好解决这一问题，实现应用与工作负载在云端与边缘节点进行统一分发与管理。

这一设想在 v3.1.0 中得以实现，KubeSphere 现已支持 KubeEdge 边缘节点纳管、KubeEdge 云端组件的安装部署、以及边缘节点的日志和监控数据采集与展示。结合 KubeEdge 的边缘自治功能和 KubeSphere 的多云与多集群管理功能，可以实现云-边-端一体化管控，解决在海量边、端设备上统一完成应用交付、运维、管控的需求。

强化微服务治理能力

KubeSphere 基于 Istio 提供了金丝雀发布、蓝绿部署、熔断等流量治理功能，同时还支持可视化呈现微服务之间的拓扑关系，并提供细粒度的监控数据。在分布式链路追踪方面，KubeSphere 基于 Jaeger 让用户快速追踪微服务之间的通讯情况，从而更易于了解微服务的请求延迟、性能瓶颈、序列化和并行调用等。

KubeSphere 3.1.0 对微服务治理功能进行了强化，将 Istio 升级到了 1.6.10，支持图形化流量方向检测，图像化方式显示应用流量的流入/流出。同时还支持对 Nginx Ingress Gateway 进行监控，新增 Nginx Ingress Controller 的监控指标。

多云与多集群管理

虽然 KubeSphere 3.0.0 带来的多云与多集群管理提供了面向多个 Kubernetes 集群的中央控制面板，实现了应用跨云和跨集群的部署与运维，但 member 集群管理服务依赖 Redis、OpenLDAP、Prometheus 等组件，不适合轻量化部署。KubeSphere 3.1.0 移除了这些依赖组件，使 member 集群管理服务更加轻量化，并重构了集群控制器，支持以高可用方式运行 Tower 代理服务。

更强大的可观测性

可观测性是容器云平台非常关键的一环，狭义上主要包含监控、日志和追踪等，广义上还包括告警、事件、审计等。3.1.0 除了对已有的监控、日志、告警等功能进行优化升级，还新增了更多新特性。

• 监控：支持图形化方式配置 ServiceMonitor，添加集群层级的自定义监控，同时还实现了类似于 Grafana 的 PromQL 语法高亮。
• 告警：在 v3.1.0 进行了架构调整，不再使用 MySQL、Redis 和 etcd 等组件以及旧版告警规则格式，改为使用 Thanos Ruler 配合 Prometheus 内置告警规则进行告警管理，兼容 Prometheus 告警规则。
• 通知管理：完成架构调整，与自研 Notification Manager v1.0.0 的全面集成，实现了以图形化界面的方式对接邮件、钉钉、企业微信、Slack、Webhook 等通知渠道。
• 日志：新增了对 Loki 的支持，可以将日志输出到 Loki。还新增了对 kubelet/docker/containerd 的日志收集。

更易用的 DevOps

KubeSphere 3.1.0 新增了 GitLab 多分支流水线和流水线克隆等功能，并内置了常用的流水线模板，帮助 DevOps 工程师提升 CI/CD 流水线的创建与运维效率。大部分场景下可基于流水线模板进行修改，不再需要从头开始创建，实现了真正的开箱即用。

灵活可插拔的集群安装工具

KubeKey 不仅支持 Kubernetes 1.17 ~ 1.20 在 AMD 64 与 ARM 64 的安装，还支持了 K3s。并且，Kubekey 还新增支持 Cilium、Kube-OVN 等网络插件。鉴于 Dockershim 在 K8s 1.20 中被废弃，Kubekey 可用于部署 containerd、CRI-O、iSula 等容器运行时，让用户按需快速创建集群。

运维友好的网络管理

KubeSphere 将 IaaS 云平台强大的网络能力继承到容器云平台，让用户在 Kubernetes 之上获得与 IaaS 一样稳定、安全和易用的网络使用体验。v3.1.0 新增了网络可视化拓扑图，你可以通过拓扑图洞悉各个服务之间的网络调用关系。

鉴于 Calico 是目前最常用的 Kubernetes CNI 插件之一，v3.1.0 现已支持 Calico IP 池管理，也可以为 Deployment 指定静态 IP。此外，v3.1.0 还新增了对 Kube-OVN 插件的支持。

认证鉴权与多租户

统一的身份管理和完备的鉴权体系，是多租户系统中实现逻辑隔离不可或缺的能力。KubeSphere 基于 Kubernetes 的角色访问控制（RBAC），提供了细粒度的权限控制能力，在支持 Namespace 层级资源隔离的同时通过 Workspace 进一步对租户进行了定义，多层级的权限管控更加契合企业用户的使用场景。

v3.1.0 中新增了组织架构管理功能，可以通过用户组简化批量授权操作。除此之外还支持了企业空间的资源配额管理，实现对资源用量的管控，进一步满足企业用户的实际需求。

统一认证方面，v3.1.0 中简化了身份提供商（IdentityProvider, IdP）的配置方式，除 LDAP 之外新增了对 CAS（Central Authentication Service）、OIDC（OpenID Connect）、OAuth2 等通用认证协议的支持，并提供了插件化的拓展方式，以便不同账户系统之间的集成。

完全开源：社区化与国际化

借助于开源社区的力量，KubeSphere 迅速走向全球，目前 KubeSphere 在全球的 90 多个国家和地区有超过 10w 下载量。v3.1.0 Console 支持中、英、繁中和西班牙语，KubeSphere 未来将进一步拓展海外市场。

KubeSphere 3.1.0 将继续秉承 100% 开源的承诺，3.0.0 版本带来的诸多新功能也早已在 GitHub 开源，例如 Porter、OpenPitrix、Fluentbit Operator、 KubeKey、KubeEye、Notification Manager、Kube-Events，还开源了一套前端组件库 Kube Design，这些新特性的代码与设计文档在 GitHub 相关仓库都可以找到，欢迎大家在 GitHub 给我们 Star + Fork + PR 三连。

3.1.0 重要更新一览

安装升级

KubeSphere 已将 v3.1.0 所有镜像在国内镜像仓库进行了同步与备份，国内用户下载镜像的安装体验会更加友好。关于最新的 v3.1.0 安装与升级指南，可参考 KubeSphere 官方文档。

致谢

以下为 KubeSphere 3.1.0 主要仓库贡献者的 GitHub ID，排名不分先后：

---

Kubernetes and Cloud Native Meetup 上海站（5 月 15 日）强势来袭，快来和 KubeShpere Community 在上海的初夏里来一场线下的技术狂欢吧！

随着 KubeSphere 社区的不断发展，社区用户的持续增多，KubeShpere 生态也逐渐走向成熟。本次 Meetup 我们联合 CNCF 基金会邀请来自 DevOps、数据库、存储等行业专家畅聊他们在云原生的应用与实践；现场更有来自社区用户与大家分享容器化之路；同时，KubeSphere 社区也将现场解读 KubeSphere 3.1.0 的最新特性与 Roadmap。感兴趣的同学不要犹豫，扫描下方二维码免费报名吧！

关于 KubeSphere

KubeSphere （https://kubesphere.io）是在 Kubernetes 之上构建的开源容器混合云，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。

KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能，包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、审计事件、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。

 ✨ GitHub：https://github.com/kubesphere

 💻 官网（中国站）：https://kubesphere.com.cn

 👨‍💻‍ 微信群：请搜索添加群助手微信号 kubesphere