Serverless

本文将为大家讲解 Serverless 工作原理、架构优势和 Serverless 应用的开发流程，以及如何使用 Serverless CI/CD 能力进行自动化部署。 本次和大家分享的提纲如下： 什么是 Serverless CI/CD？ Serverless 介绍 Serverless 架构 CI/CD 与 Serverless CI/CD Serverless CI/CD 应用 Serverless 应用开发流程 Serverless CI/CD 优势 Serverless CI/CD 实战 基于 Coding CI/CD 的自动化部署 基于 Github CI/CD 的自动化部署 什么是 Serverless CI/CD？ 1. Serverless 介绍 下图一张逻辑架构图，最上面application，下面是系统资源。我们可以通过虚拟机、容器、数据库、存储等来提供系统资源。同时，我们需要对这些系统资源进行维护，比如资源申请、环境搭建、容灾、扩缩容等。 Serverless 是什么呢？Serverless 就是把底层的这些资源以及对这些资源的运维都交给云厂商来维护、这些资源对业务来说是黑盒的，业务只需要关注自己业务逻辑的开发即可。 这种架构思想和方法就是 Serverless。 Serverless 直译过来叫无服务器，实际上他不是真的不需要服务器

云栖号最佳实践：【 点击查看更多上云最佳实践 】 这里有丰富的企业上云最佳实践，从典型场景入门，提供一系列项目实践方案，降低企业上云门槛的同时满足您的需求！ 场景描述 本实践适合使用Severless架构的函数计算产品来实现一些网站的文件处理的场景中，例如自动解压文件，自动打包压缩，自动爬取图片，自动处理图片分辨率等功能。 解决问题 搭建函数计算用于网站文件处理 自动压缩解压缩文件包 自动爬取图片，修改图片分辨率等 产品列表 函数计算FC 对象存储OSS 日志服务LOG 直达最佳实践 》》 云栖号最佳实践：【 点击查看更多上云最佳实践 】 这里有丰富的企业上云最佳实践，从典型场景入门，提供一系列项目实践方案，降低企业上云门槛的同时满足您的需求！ 来源： oschina 链接： https://my.oschina.net/u/4362791/blog/4332495

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

2020 年 6 月 19 日，全球最负盛名的 Serverless 大会 --ServerlessDays · China 于线上直播的形式正式召开举办。腾讯云作为 Serverless 的先行者，从 2017 年至今，经过三年的沉淀，腾讯云 Serverless 的用户规模以及产品下载、调用等次数每年都在急速增长。云计算的下半场会是无服务器化吗，Serverless 能否再次引领云计算领域的又一次红利？这一切，都在这场大会中得到揭晓。 Serverless 起势 2020 年 6 月 19 日，首次进入中国的 ServerlessDays 于线上直播的形式展开。期间 ServerlessDays Organiser--Ant Stanley、Author of “A Berkeley View on Serverless Computing”--Johann Schleier-Smith、Serverless.com CEO--Austen Collins 等众多国外知命的 Serverless 技术专家纷纷到场。 开场，ServerlessDays 会议的组织者、Serverless 社区的技术专家 Ant Stanley 通过分享了自己对于无服务器化的理解，从 Herman Hollerith 到简单的 Lambda 函数，Ant Stanley

行业前景与就业情况分析 这是很多还没开始学前端的同学心中的疑问，也是急需解决的一个核心问题。我想学习某个技术，总得知道它是否有前途吧，别急，我们慢慢分析。 根据2020年职友集的最新数据调查结果显示，目前而言web前端的人才缺口依然是巨大的。左侧是各地岗位需求量，右侧是平均薪资。 以深圳为例，一线城市的前端更是吃香，前端的就业形势仍然是一片大好。 市场的供不应求所带来的，就是Web前端薪资的水涨船高，一个初级Web前端起步是8K-10K左右，在技术成长和业务熟练之后往往可以达到20K-30K，这个薪资段的人占比9.1%。而10k-15k这个薪资段的人占比是最大的。 目前仍然是“大前端时代”，行业发展好，所以就业这一块是完全不用担心的。 前端技术发展趋势 前端的发展实际上是非常快的，入行早的同学们应该知道，12 - 15年的时候，前端工程师 = HTML+CSS+JS，而到19年。前端工程师 = HTML+CSS+JS+VUE +工程化+ Node服务端…… 那么，2020的前端发展趋势是什么呢？ ** a. ** 超级APP下，Web标准的重新定义——小程序 近几年，小程序可谓是火的一塌糊涂。甚至独立出来小程序开发这个岗位。在微信小程序出现以前，大家在谈 Hybird、ReactNative，但终归只是技术层面的狂欢，一直没有业务属性的注入。 而小程序的出现

- 点击领取《云原生架构白皮书》 - 导语： 有幸作为阿里云MVP提前获得了阿里云云原生团队编写的《云原生架构白皮书》，希望通过自己对于云原生的理解为开发者提供一篇观后感或者是能够参考的博文。 1 云原生与分布式系统架构的关系 1.1 云原生架构的定义 《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。” 1.2 分布式系统架构的定义 此处定义参考百度百科为“在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。” 1.3 云原生与分布式系统架构的关系 分布式架构的重点在于解决计算力的保障问题以及为了提高计算力并同时确保系统的可靠性、可用性和安全性而产生的诸如弹性伸缩、负载均衡、分布式存储等问题，其目标是在于构建一个分布式的安全可靠的计算力基础平台

跟大家分享几个好消息： 在今天“2020 可信云线上峰会”上，中国信通院公布了多项可信云认证的评估结果。 阿里云原生在容器平台安全能力、函数及服务、分布式消息队列服务、可信云服务最佳实践（服务云）、可信云技术最佳实践（容器及管理）等评选中获得可信云认证！ 多年来，阿里巴巴作为云原生领域的先行者、实践者，基于自身累积多年的最佳实践，对社区赋能，为企业提供普惠的云原生产品服务。在这次可信云评选中，阿里云原生更是拿到5项大奖，从技术到实践，以最全面的技术影响力推动云原生进入新的阶段！ 下面我们来一一揭开这些奖项！ NO.1：阿里云 49 个满分，获得可信云容器安全能力先进级认证 今天，信通院发布了国内云厂商的容器安全评估结果： 阿里云容器服务 ACK 和容器镜像服务 ACR 荣获最高级别先进级可信云安全能力认证，特别是在最小化攻击面，二进制镜像验签名，密文的 BYOK 加密等能力上国内领先，达到国际先进水平。 早在 2018 年，阿里云容器服务团队率先提出了“端到端的企业级安全能力”概念，并推出立体式的端到端云原生安全架构，从三个层面来解决安全问题： 最底层依托于阿里云平台已有的安全能力，包括物理安全，硬件安全，虚拟化安全和云产品安全能力; 中间是容器基础设施安全层，基于最小化攻击面原则，提供了包括访问控制，权限收敛，配置加固和身份管理等重要的底座安全能力；同时针对凭证下发，证书、密钥

作者 | 王思宇（酒祝） 阿里云技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利及作者答疑！ 概念介绍 原地升级 一词中，“升级”不难理解，是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢？ 我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用，包括 foo、bar 两个容器在 Pod 中。其中，foo 容器第一次部署时用的镜像版本是 v1，我们需要将其升级为 v2 版本镜像，该怎么做呢？ 如果这个应用使用 Deployment 部署，那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod，并删除旧版本 Pod。如下图所示： 在本次升级过程中，原 Pod 对象被删除，一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上，分配到一个新的 IP，并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。 如果这个应该使用 StatefulSet 部署，那么升级过程中 StatefulSet 会先删除旧 Pod 对象，等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示： 值得注意的是，尽管新旧两个 Pod 名字都叫 pod-0，但其实是两个完全不同的 Pod 对象（uid也变了）。StatefulSet 等到原先的

作者 | 声东 阿里巴巴技术专家 <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 导读：《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ 什么是 Kubernetes？ 我们来看一下什么是 Kubernetes。这部分内容我会从四个角度来跟大家分享一下我的看法。 1. 未来什么样 这是一张未来大部分公司后端 IT 基础设施的架构图。简单来说，以后所有公司的 IT 基础设施都会部署在云上。用户会基于 Kubernetes 把底层云资源分割成具体的集群单元，给不同的业务使用。而随着业务微服务化的深入，服务网格这样的服务治理逻辑会变得跟下边两层一样，成为基础设施的范畴。 目前，阿里基本上所有的业务都跑在云上。而其中大约有一半的业务已经迁移到了自己定制 Kubernetes 集群上。另外据我了解，阿里计划今年完成 100% 的基于 Kubernetes 集群的业务部署。 而服务网格这块，在阿里的一些部门，像蚂蚁金服，其实已经有线上业务在用了。大家可以通过蚂蚁一些同学的分享来了解他们的实践过程。 虽然这张图里的观点可能有点绝对，但是目前这个趋势是非常明显的。所以未来几年， Kubernetes 肯定会变成像 Linux 一样的，作为集群的操作系统无处不在。 2. Kubernetes

作者 | 周正喜 阿里云技术专家 爱好云原生，深度参与 OAM 社区 大家都知道，应用开放模型 Open Application Model（OAM） 将应用的工作负载（Workload）分为 三种 —— 核心型、标准型和扩展型，这三者的主要区别在于一个 OAM 平台对于具体某一类工作负载进行实现的自由度不同。其中，OAM 社区中目前唯一一个核心工作负载是 Containerized Workload ，它用来描述一个基于容器的工作负载，可以理解为是 Kubernetes Deployment 的简化版（去掉了 PodSecurityPolicy 等大量与业务研发无关的字段）。 不过，很多读者可能会有疑问：对于 Kubernetes 内置的工作负载 OAM 是否还能直接支持呢？ 答案当然是肯定的，而且这是 OAM 作为 Kubernetes 原生的应用定义模型的默认能力。 下面，本文就以 Deployment 为例，介绍如何使用 OAM 基于 Kubernetes 的内置工作负载来定义和管理云原生应用。 示例准备 基于 GitHub FoodTrucks （旧金山美味街边小吃地图应用）项目，构建镜像 zzxwill/foodtrucks-web:0.1.1，加上依赖的 Elasticsearch 镜像，在默认情况下，它的 Deployment 描述文件 food-truck