Serverless

作者 | 孤弋 阿里云高级技术专家，负责 EDAS 的开发和用户体验优化工作。 导读 ：在上一篇文章 《SpringCloud 应用在 Kubernetes 上的云上实践 - 开发篇》 中讲到可以通过两个工具，轻松地将一个 SpringCloud 应用从初始化到本地运行。本篇文章，我们将介绍如何将上一篇文章中提到的应用在云上跑起来。 初始化集群 为了将应用运行在云端，首先我们需要一个 Kubernetes 集群，在 EDAS 中使用 Kubernetes 集群目前最快的方式，是将一个阿里云容器集群中的 Kubernetes 集群( ACK 集群 )，导入到 EDAS 中来。 如果还没有ACK集群的话，您可以通过以下两种方式来创建一个： 直接进入容器服务的控制台进行创建； 如果您已经有一个在云上建好的集群，或者有一个在其他 IDC 或友商中有的集群，也可以在容器服务这边通过“注册已有集群”的方式，导入到容器服务中来。 等到 Kubernetes 集群就绪之后，在 EDAS 上需要进行一次集群“导入”，导入方式如下图所示： 在导入集群时，EDAS 会做以下操作： 初始化 EDAS 的集群控制器和相关资源，主要包含：基于开放云原生应用标准的 OAM Controller、日志采集的 Agent、监控链路中的 Arms 环境信息等；其中大部分控制器运行时不会占用用户集群的资源，而会运行在

写了多年的代码，始终觉得如何写出干净优雅的代码并不是一件容易的事情。按 10000 小时刻意训练的定理，假设每天 8 小时，一个月 20 天，一年 12 个月，大概也需要 5 年左右的时间成为大师。其实我们每天的工作中真正用于写代码的时间不可能有 8 个小时，并且很多时候是在完成任务，在业务压力很大的时候，可能想要达到的目标是如何尽快的使得功能 work 起来，代码是否干净优雅非常可能没有能放在第一优先级上，而是怎么快怎么来。 在这样的情况下是非常容易欠下技术债的，时间长了，这样的代码基本上无法维护，只能推倒重来，这个成本是非常高的。欠债要还，只是迟早的问题，并且等到要还的时候还要赔上额外的不菲的利息。还债的有可能是自己，也有可能是后来的继任者，但都是团队在还债。所以从团队的角度来看，写好代码是一件非常有必要的事情。如何写出干净优雅的代码是个很困难的课题，我没有找到万能的 solution，更多的是一些 trade off，可以稍微讨论一下。 代码是写给人看的还是写给机器看的？ 在大部分的情况下我会认为代码是写给人看的。虽然代码最后的执行者是机器，但是实际上代码更多的时候是给人看的。我们来看看一段代码的生命周期：开发 --> 单元测试 --> Code Review --> 功能测试 --> 性能测试 --> 上线 --> 运维、Bug 修复 --> 测试上线 --> 退休下线

作者 | 刘军（陆龟） Apache Dubbo PMC 概述 社区版本 Dubbo 从 2.7.5 版本开始，新引入了一种基于实例（应用）粒度的服务发现机制，这是我们为 Dubbo 适配云原生基础设施的一步重要探索。版本发布到现在已有近半年时间，经过这段时间的探索与总结，我们对这套机制的可行性与稳定性有了更全面、深入的认识；同时在 Dubbo 3.0 的规划也在全面进行中，如何让应用级服务发现成为未来下一代服务框架 Dubbo 3.0 的基础服务模型，解决云原生、规模化微服务集群扩容与可伸缩性问题，也已经成为我们当前工作的重点。 既然这套新机制如此重要，那它到底是怎么工作的呢？今天我们就来详细解读一下。在最开始的社区版本，我们给这个机制取了一个神秘的名字 - 服务自省，下文将进一步解释这个名字的由来，并引用服务自省代指这套应用级服务发现机制。 熟悉 Dubbo 开发者应该都知道，一直以来都是面向 RPC 方法去定义服务的，并且这也是 Dubbo 开发友好性、治理功能强的基础。既然如此，那我们为什么还要定义个应用粒度的服务发现机制呢？这个机制到底是怎么工作的？它与当前机制的区别是什么？它能给我们带来哪些好处那？对适配云原生、性能提升又有哪些帮助？ 带着所有的这些问题，我们开始本文的讲解。 服务自省是什么？ 首先，我们先来解释文章开篇提到的问题：

作者 | 承风 阿里巴巴高级前端技术专家 导读： 建立结构化的思维，以结构化的模式驱动工作，以结构化的体系构建自身的能力，小到写 PPT、大到为业务提供更大价值，都是非常值得我们使用的模式。阿里巴巴数字供应链事业部高级前端技术专家 - 承风，将会在本文中和大家分享他在建立和践行结构化思维过程中的方法论。 引言 在每年自评、汇报、工作中总会感受到一些结构化带来的问题： 老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量······工作的进展，说了半小时，老板还是 get 不到我做的事情的情况和价值，是老板不在意这件事、还是我语言表达能力不行？ 我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大，是我做得不好、还是运气不好做的事情不好？ 最近流行 codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下 TMF······一年下来折腾了不少成果出来，似乎老板也没有很认可，是我不讨老板喜欢还是做的事情没价值？ 这些问题，根据我自己工作经验的总结，认为大都是对结构化认知不足和践行不佳导致的。 第一个问题：对事情的认知和表述结构化方面存在问题 - 结构化的思维相关问题； 第二个问题：做事儿多而杂不成体系 - 结构化的工作模式问题； 第三个问题：学习和成长缺乏重点 - 结构化的能力建设的问题。 关于结构化

社交，是游戏玩家的一项基本需求，那么，在游戏中，成熟稳定的聊天系统担负着玩家交流的重要使命。 做为一家从不 996 的游戏创业公司，我们的两款产品《世界争霸》和《农场小镇》都在使用自研的聊天系统。随着在线人数逐渐增多，系统的稳定性和成本面临着更多的考验。于是，升级技术栈势在必行。 至此，核心目标已经出现，以保障性能为前提，同时做到省事和省钱。最终，腾讯云的云函数产品进入了我们的视线。 云函数，无需服务器，省去运维烦恼，只需要关注于业务逻辑代码，可谓省事。按量付费，用多少花多少，避免业务低谷期的资源浪费，可谓省钱。非常适合游戏聊天系统 API 这种复杂度低的中小型需求。 那么接下来我们关注的是，现有系统能不能无缝迁移过去，也就是云函数能不能满足目前所有的特定需求，我们一个一个来说。 第一个需求：少改代码 原来的 API 部分是采用 swoole 做为底层扩展，部署在腾讯云的 CVM 上，并使用腾讯云的负载均衡来接收外部请求。代码层面则是使用了 composer 进行包管理，一款开源的 easyswoole 框架做为 http 业务的架子。 换用云函数的方案的话，非代码层面就变成了腾讯云 API 网关加云函数来提供服务，而为了方便，依然需要继续使用 composer 进行包管理。原来基于 swoole 的 http 框架无法继续使用，改代码的重点就在这里。 首先就是逻辑入口

作者 | 孔德慧（夏莞） 阿里云函数计算开发工程师 本文整理自《Serverless 技术公开课》， 关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT 。 什么是函数计算？ 大家都了解，Serverless 并不是没有服务器，而是开发者不再需要关心服务器。下图是一个应用从开发到上线的对比图： 在传统 Serverful 架构下，部署一个应用需要购买服务器，部署操作系统，搭建开发环境，编写代码，构建应用，部署应用，配置负载均衡机制，搭建日志分析与监控系统，应用上线后，继续监控应用的运行情况。而在 Serverless 架构下，开发者只需要关注应用的开发构建和部署，无需关心服务器相关操作与运维，在函数计算架构下，开发者只需要编写业务代码并监控业务运行情况。这将开发者从繁重的运维工作中解放出来，把精力投入到更有意义的业务开发上。 上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时，开发者也无需手动扩容，函数计算会根据请求量毫秒级自动扩容，弹性可靠地运行任务，并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。 函数计算核心优势 1. 敏捷开发 使用函数计算时，用户只需聚焦于业务逻辑的开发，编写最重要的 “核心代码”； 不再需要关心服务器购买

作者 | 王思宇、陈洁、陈有坤、宋净超 业界要闻 阿里云重磅发布云原生裸金属方案：裸金属 + 容器，解锁云计算的新方式 在 6 月 9 日 2020 阿里云线上峰会上，阿里云智能基础产品事业部高级研究员蒋江伟重磅发布了云原生裸金属方案。新一代容器服务 ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备极致性能、高效调度、全面安全的特点。 为云研发而生，阿里巴巴发布新一代 DevOps 平台云效 6 月 9 日，2020 阿里云线上峰会于云端举行，阿里巴巴云研发部门负责人陈鑫出席峰会并发表题为《新云效，新 DevOps 平台》的主题演讲，宣布新一代企业级 DevOps 平台——阿里云·云效正式发布。 上游重要进展 StatefulSet volume resize 为 StatefulSet 增加支持调整 PVC resize 的能力。 fix: leaderelection graceful release doesn't work 解决 client-go 中提供的 leaderelection 存在优雅释放不 work 的问题。 Fix DS expectations on recreate 修复了 DaemonSet 控制器重建 Pod 时，expectations cache 中信息未清理的 BUG。 Fix kube-apiserver panic

作者 | 徐运元，杭州谐云科技合伙人及资深架构师，云计算行业和 Kubernetes 生态资深从业者 导读： 什么是 OAM？2019 年 10 月 17 日，阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟（花名：小邪）在 QCon 上海 2019 重磅宣布，阿里云与微软联合推出开放应用模型 Open Application Model （OAM）开源项目 。 OAM 的核心关注点 关注点分离： 开发者关注应用本身，运维人员关注模块化运维能力，让应用管理变得更轻松、应用交付变得更可控； 平台无关与高可扩展： 应用定义与平台层实现解耦，应用描述支持任意扩展和跨环境实现； 模块化应用运维特征： 可以自由组合和支持模块化实现的运维特征描述。 OAM 的核心模块 1. 应用组件（Components） 在 OAM 中，“应用”是由多个概念共同组合而成。第一个概念是：应用组件（Components），它是整个应用的重要组成部分。应用组件既可以包括应用运行所依赖的服务：比如 MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 PHP 服务器。开发者可以把他们写的代码“打包”成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系。 应用组件的概念让平台架构师等能够将应用分解成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全

2008 年可以说是大家比较公认的云计算元年，因为在这一年中越来越多的行业巨头和玩家注意到这块市场并开始入局。至今已经过去了十多年，在这短短十几年的发展过程中，云计算持续爆发，落地应用不断涌现，对于行业的变革力量正逐步凸显。 但是力的作用是相互的，在改变行业的同时，行业也在改变着你。由于市场对于高效、快速的需求越来越重，因此能否让开发者专心在业务逻辑和功能实现上，能否淡化前后端开发界隙并提升研发效率，Serverless 去服务器化可以说是当下的不二选择。 Serverless 可以使几乎所有的互联网开发者以及互联网应用都从中受益，因为没有人会拒绝高效率和低成本，而 Serverless 则在开发成本、团队协作、高扩展性、计算资源等层面拥有众多优势，是实现高效与低成本的最佳方式之一。 这也是当下众多企业选择 Serverless 的原因所在，因此作为当前时代下的开发者，了解 Serverless 背景、学习 Serverless 实践就显得尤为重要。而现在就有这样一个机会， 6 月 19 日（周五）全天，全球最负盛名的 Serverless 大会 —— ServerlessDays 将首次进入中国 。 为什么推荐你参加此次大会 如果你是 Serverless 爱好者，如果你是互联网前沿技术的观察者，如果你在工作中需要用到 Serverless，如果你想要先人一步掌握关于

导读： 2019 年的大前端热闹非凡，Serverless，Flutter，Vue3.0，桌面应用开发，小程序，WebAssembly 的火爆发展还是超乎我们预期，2020 的大前端又有哪些不容错过的技术趋势呢？ 四位技术人不四、杜欢、海波和堂主对 2020 年前端发展趋势进行了展望，同时也阐述 2020 年前端从业者可能将要面临的挑战。 不四 蚂蚁金服高级前端技术专家，语雀产品技术负责人 杜欢 阿里云战略 & 合作部 高级前端技术专家、阿里巴巴经济体前端 Serverless 研发升级项目负责人 海波 网易云音乐前端负责人 堂主 政采云前端负责人 Q1：在 2019 年大前端领域，您印象最深刻或者最重要的一件事情是什么？ 不四： 随着大前端领域开始进入深水区，越来越多的资源开始往两端倾斜，Low Code 领域解决大量营销活动和中后台的业务场景， Pro Code 领域则通过基建赋能来提升开发者的研发效能，支持更复杂的研发场景。 杜欢： 2019 年，云厂商和整个前端开发者社区都在积极推动 Serverless 概念的落地，云 + 端的研发模式雏形初显，大前端的未来充满更多可能。 海波： 运营工具体系作为前端容易切入的业务赋能场景，近两年在各个大小厂如雨后春笋般涌现，诸如页面搭建工具以及图片、音视频等素材的合成制作工具等等，其中也有不乏结合视觉