Serverless

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

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

导读： 在 2020 阿里云合作伙伴峰会上，阿里巴巴合伙人、阿里云智能基础产品事业部高级研究员蒋江伟发表了《深耕“被集成”，共建新生态》主题演讲，他在演讲中提到，阿里云将继续深耕“被集成”战略，做强生态，未来一年投入 20 亿专项资金，启动“云原生合作伙伴计划”，优选扶持 100 家头部合作伙伴，赋能 10000 家合作伙伴和 50 万开发者，共同服务百万云上客户，帮助合作伙伴实现云原生技术升级，合力加速百行千业实现数字化转型。 企业上云已经成为一种必然趋势。疫情之下，虽然各行各业都受到了不同程度的影响，但那些数字化能力健全的企业抵御风险的能力更强。经过此次疫情，越来越多的企业坚定了上云和实现数字化转型的信念和步伐， 而云原生技术则是实现数字化转型的最短路径。 阿里云在全球领域内是云原生技术的定义者和领导者。目前，阿里云原生推出的技术栈已经覆盖了容器服务、Serverless 应用引擎、函数计算等技术，并结合自身在电商业务的生产实践进行了落地。借助阿里云原生产品，包括企业级分布式应用服务 EDAS、消息队列 MQ、性能测试 PTS、容器服务 ACK/ASK、Serverless 工作流、无服务器应用引擎 SAE 等云原生产品，可以加速企业数字化转型，享受云原生时代的技术红利。 “云原生合作伙伴计划”可以为企业带来哪些价值？ 「伯俊」 成立于 1999 年

“云原生（Cloud Native）”现在已经是一个唱遍大江南北的词，相比它的上一代术语“云计算”，云原生更加强调“应用原生长在云上”。 上世纪 50 年代末，虚拟化被提出来，如今看来，这成了云计算基础架构的基石。云计算发展到如今近 60 年，期间各种云相关的技术不断出现，PaaS、IaaS 与 SaaS 是最早一批基于云概念的实际应用，而后出现的 FaaS、BaaS 与 Serverless 等，也在为云不断增添新的动力。 在这个过程中，为了达到在构建应用时“云端优先”的新兴思想，云原生的概念应运而生。云原生的原生指的是在 最初设计应用时就原生为云环境做出相应考量 ，以此在云上充分利用和发挥云平台的各种能力，包括低成本、按需付费、系统弹性可伸缩、高度可管理、业务逻辑解耦等。 Linux 基金会专门成立了云原生计算基金会（CNCF，Cloud Native Computing Foundation）以发展云原生技术，伴随着这几年云原生的快速发展，CNCF 如今也成为了该领域最权威的组织。 由 CNCF 主办的 “CloudNative + Open Source Virtual Summit China 2020 中国线上峰会” 正在进行中，为期 3 天的大会将带来上百场分享，内容将覆盖云原生的方方面面，包括微服务架构、容器、可观察性、存储、安全、身份、策略、开源生态、网络与 CI

从软件工程的角度来看，软件开发经历了如下三个阶段：传统开发->敏捷迭代->Serverless。 传统的开发模式和敏捷迭代开发模式除了需要开发者编写核心的业务逻辑外，都不可避免地需要对后端的基础设施进行管控和优化。比如，一个应用的逻辑可以很简单，可一旦涉及到应用的发布部署，就需要开发者花费大量精力进行服务器、数据库、网络等基础设施的申请和搭建，还要考虑这些后端基础设施的稳定性、可用性和监控指标。这一切耗时耗力又与产品的核心功能无关，对于需要快速开发和试错的产品，传统的模式开发速度慢、部署和运维成本较高。 随着 Serverless 概念的火热，越来越多的开发者开始转向Serverless发展。“Serverless”并不是指后端没有服务器，而是将后端服务器及相关运维操作变得对上层应用开发者不可见和透明，使得用户无需关心后端的基础设施，直接通过云API一键接入云函数、云数据库和云存储来获取算力、数据库、存储等基础的后端能力。这种随用随取的开发模式，不但可以让开发者能更专注于自身的业务逻辑，还具有低成本、开发速度快以及免运维等诸多优势。 小程序需求 + Serverless理念 = 小程序云开发 基于此，小程序云开发以微信作为小程序前端运行的依托，同时又通过接入云函数、云数据库和云存储，来达到对后端基础设施的开箱即用。这些特性可以在很大程度上解放小程序开发者的生产力

“云原生编程挑战赛”是“中间件性能挑战赛”的全新升级！自 2015 年开始，大赛已经成功举办了五届，共吸引超过 12000 支队伍，15000 名顶尖选手参加，覆盖 10 余个国家和地区。 往届大赛毕业生是这样说的： 视频点击 这里 经历了跌宕起伏的比赛过程，感悟到冠军不是最重要的，重要的是参与了这场提升自己的赛事，攻克了自己的懈怠，结识了优秀的技术同胞。 --北京字节跳动网络技术有限公司--吴得瑀/微软中国有限公司--黎强/北京大学在读博士--张博洋 比赛带我们的不仅仅是荣誉，对生活和工作都会产生影响，这些影响可能是生活上更积极，工作上更注重个人技术能力提升。 --原中央军委后勤保障部信息中心--刘兰峥/深圳市烟草专卖--陆华俊 赛题本身的吸引力激发了我们参加比赛的欲望，通过参加比赛，让我们更相信，只要用心去做自己所热爱的事情，纵使是平凡的人也会做出伟大的事情。 --成都钛数智能科技有限公司--吴小刚/贵阳货车帮科技有限公司--陈林江/成都国美大数据科技有限公司--叶琦 中间件挑战赛的赛题场景性强，更具有挑战性。比赛过程中有分歧，有争议，最终克服困难，共同冲到了终点。 --成都电子科技大学，（在校生）程智凌&彭禹豪 作为尚未毕业的大学生，赛题对我们来说难度较高，有过想放弃的想法，但还是坚持到了最后，这份经历对我们来说是宝贵的，将让我们更加坚定以后的职业选择。 --广东工业大学，

笔者有幸经历了 IaaS（OS）、CaaS（Container），在这两年又听到了 FaaS（Funtion），这也是运维开发领域里的第三个阶段了吧，今天我将从一个不懂得开发的系统工程师视角以及结合之前的几篇系列文章为各位诠释这个概念。 本文来自 Serverless 社区用户「StatLee」投稿 一、简述 一开始听到 ServerLess 我以为是类似于 VPS（建站主机）亦或者是 VM、Container 之类的具备完整 OS 或半完整 OS 生态的一个全新开发方式，后来发现我完全理解错了，如果说传统的云计算是这样分层的： 那么 FaaS（ServerLess 为代表的的 Funtion As A Service）就是把 SaaS 再进行精细化拆分，可以看这张图就明白了（特别是红圈部分）： 传统以为 Application 就是业务的最终形态，可是随着以开发领域为首的「微服务」及运维领域为首的「SRE/DevOps」理念出来后，传统的业务运维明显已经不能满足新一代业务的需求，为了更贴合这些新的需求，实现： 模块拆分化（即一个功能作为一个模块，而非一个业务作为一个模块） 最小颗粒化变更（即分层变更，变更时通过合理调度时变更间隔缩短，实现快速迭代）的目的 云厂商最终在以往的「最终形态」上又拆分了 Function 出来，多个 Function 再组成 Application

作者 | 孤弋 阿里云高级技术专家，负责 EDAS 的开发和用户体验优化工作。 前言 近年来，云原生、Kubernetes、微服务、SpringCloud 这些名词在技术圈内不绝于耳，数据显示，使用 SpringCloud 作为微服务的框架，同时选择 Kubernetes 作为应用与基础设施运维底座的团队越来越多，这二者的搭档基本上成为了业界的主流配搭。 为了顺应这一趋势，EDAS 也紧紧围绕这一典型场景，对它的开发、测试、部署、联调、线上运维等诸多环节中的开发者体验进行深度打磨，发布了全新的 3.0 版本。同时，针对如何在采用了 SpringCloud + Kubernetes 架构的应用上使用 EDAS，我们团队提供各个环节的最佳实践，供开发者参考。 本篇进入我们的第一章节：开发。 初始化项目 阿里巴巴从 2018 年开始开源了以原阿里集团中间件为主要能力、全方位对标 SpringCloud Netflix 的全家桶服务，也就是目前的 Spring Cloud Alibaba 项目( https://github.com/alibaba/spring-cloud-alibaba )，经过两年多的发展，这个项目受到了越来越多开发者的喜爱，目前的 star 数也达到了 14K。 不过对于开发者而言，选择变多的同时，往往也会伴随一些烦恼，比如：我们到底需要使用什么版本

作者 | 许晓斌 阿里云高级技术专家 本文整理自《Serverless 技术公开课》第 1 讲， 点击开始学习 。 关注 “ Serverless ” 公众号，回复 **入门 **，即可获取 Serverless 系列文章 PPT。 传统单体应用架构 十多年前主流的应用架构都是单体应用，部署形式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地维护这台服务器，以保证服务的可用性。 （单体架构） 随着业务的增长，这种最简单的单体应用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器出现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务量变大之后，一台服务器的资源很快会无法承载所有流量。 解决这两个问题最直接的方法就是在流量入口加一个负载均衡器，使单体应用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体应用也具备了水平伸缩的能力。 （单体架构-水平伸缩） 微服务架构 1. 微服务架构演进出通用服务 随着业务的进一步增长，更多的研发人员加入到团队中，共同在单体应用上开发特性。由于单体应用内的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，以及大量的 conflict merge 操作，研发效率直线下降。 因此大家开始把单体应用拆分成一个个可以独立开发、独立测试、独立部署的微服务应用，服务和服务之间通过 API 通讯，如

作者 | 酒祝 阿里云技术专家 背景 OpenKruise 是阿里云开源的大规模应用自动化管理引擎，在功能上对标了 Kubernetes 原生的 Deployment / StatefulSet 等控制器，但 OpenKruise 提供了更多的增强功能如：优雅原地升级、发布优先级/打散策略、多可用区workload抽象管理、统一 sidecar 容器注入管理等，都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。 目前在阿里巴巴内部云原生环境中，绝大部分应用都统一使用 OpenKruise 的能力做 Pod 部署、发布管理，而不少业界公司和阿里云上客户由于 K8s 原生 Deployment 等负载不能完全满足需求，也转而采用 OpenKruise 作为应用部署载体。 今天的分享文章就从一个阿里云上客户对接 OpenKruise 的疑问开始。这里还原一下这位同学的用法（以下 YAML 数据仅为 demo）： 准备一份 Advanced StatefulSet 的 YAML 文件，并提交创建。如： apiVersion: apps.kruise.io/v1alpha1 kind: StatefulSet metadata: name: sample spec: # .