Serverless

作者 | 周正喜 阿里云技术专家 爱好云原生，深度参与 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

笔者有幸经历了 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

作者 | 易立 阿里云资深技术专家 导读 ：近年来，容器技术及相关应用得到了国内外越来越多的关注度。在国外，容器技术已经形成了较成熟的生态圈；而在国内，金融企业、互联网企业、IT 企业积极投入容器技术的应用。本文将重点介绍容器技术在企业落地最佳实践，包括容器技术的背景，阿里云容器服务概述，容器技术在企业落地的正确姿势，以及容器服务的演进方向。 前言 容器的英语是 Container，它的意思是集装箱，经济全球化的基础就是现代化的运输体系，其核心就是集装箱。 集装箱的出现，实现了物流运输的标准化、自动化，大大降低了运输成本，使得整合全球的供应链变成可能，这就是著名的《经济学人》杂志提到的 “没有集装箱，就没有全球化”。容器可以理解为云时代的 “应用集装箱” ，重塑了整个软件供应链。 什么是容器？ 容器是一种轻量化的虚拟机，轻量化的应用信息化技术。打个比方，传统的物理机就是一个独栋大别墅，一家人独占，住的很舒适，不会被别人打扰。缺点就是贵，并且交付时间长，利用率也不高。虚拟机可以理解为联排住宅，每栋房屋是共享水、电、地基等基础设施，整体的容积率提升了，公摊下降，这样成本也下降，交易速度也加快了。但是每户都有独立的一个空间，具有很好的隔离性。 虚拟化正是通过这样的技术实现了安全隔离，有效提升了资源利用率，但是交付之后还需要对它进行一个应用的配置和安装。容器就好比是集装箱板房

作者 | 张羽辰（同昭）阿里云交付专家 导读 ：如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。 当我们谈论架构时，我们到底在谈论什么？ 面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，的确我们这个领域充满了很多难以理解的词汇，这些词汇从英语翻译到中文已经丧失了部分上下文，再随着上下文的改变使得意义彻底扭曲，比如：引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识，在工作中使用这些词汇进行沟通，某时就是指“我们都懂的那个东西”，但是在我深入的想聊聊架构或者说软件架构时，的确不得不问自己这个问题，我们到底是谈论什么？ 事实上，架构这个词根据上下文所确定的范围较为固定，建筑学上的架构指代房屋结构、整体设计、组合构成等，而这些 high-level 设计往往并不需要全面了解底层，就像使用 RestTemplate 进行 WebService 调用时，我们也不关心 socket 是在四层连接的一样， 因为细节被隐藏了 。 但是，建筑学上的架构与软件架构却又极大的不同之处，问题出现在“软件”这个词上，按照 software 的词解，ware 是指产品一样的东西，而 soft 则强调易变，这是与 hardware 所对应的

第一步，环境配置 打开微信 小程序开发 IDE，创建一个小程序项目，AppID 需要自己去小程序官网注册一个，然后后端服务注意选择 小程序-云开发 。 注意，以前的老版本 IDE，在蓝色框那里会有一个 腾讯云 的选项。实际上都是使用的腾讯云服务，统一选择小程序-云开发就好。 点击 新建 ，会出现这样一个界面： 可以看到，微信开发者工具的脚手架已经为我们创建好了一些模板代码，今天，猪脚就是我们的 cloudfunctions 部分，即如何利用 腾讯云 为我们即将写的新闻小程序提供数据服务。 在开发之前，我们发现控制台报了一个错误，提示我们没有开通云服务。我们发现微信开发者工具的顶部工具栏中，云开发那个按钮是灰色的，点击进去，提示我们开通，表示我们没有开通云开发服务，点击它，新建一个。 配置完毕之后，你可能会关系费用问题，不用担心，默认的配置是完全免费的，如果你用户量不太大，基本上够你的日常需求了，对个人开发者来说，相当的友好。 第二步：云函数开发及部署 云服务开通完毕，接下来可以部署下脚手架为我们提供的云函数，可以看到 cloudfunctions 文件夹提示未选择环境，我们右键点击，选择我们刚才开通的那个云开发环境。然后展开目录，对准 login 这个目录，右键，选择 然后，关闭 IDE，重启 IDE，在点击第一个按钮，获取 openid，此时可以看到获取 openid 是成功的了

一分钟速览资讯 ☁ 云计算报告 ① CNCF 2019 年度调查重磅报告发布 <推荐> ☁ 业界新闻 ② GitHub 宣布正式收购 npm ③ 受疫情影响，一系列 IT 活动已经取消和推迟 ☁ 程序员专区 ④ Kubernetes1.18 版本发 布 <推荐> ⑤ Spring Boot 2.3.0.M1发布 ⑥ Istio 1.5 正式 发布 云计算报告 01 CNCF 2019 年度调查报告发布，84%受访者已经在应用容器 报告中包含了几条重要信息： Cloud Native 社区项目在生产环境中应用成为新常态，超过 50% 的 Cloud Native 项目在生产中应用； Service Mesh 真正进入生产实践，超过 18% 的受访者表示已经在生产环境中使用 Service Mesh； Serverless 技术正逐渐成为主流，超过 40% 的受访者表示在使用 Serverless 技术； 容器在生产环境中的使用显著提升，相比于 2018 年的 73% 上升到了 84%； 越来越多的应用开始通过 CI/CD 工具自动发布。 报告pdf下载↓↓ 业界新闻 02 GitHub 宣布正式收购 npm npm 自十年前发布以来，经过发展目前已经是最流行的 javascript 包管理工具。 收购以后，Github 承诺会对 npm 的安全性、注册表基础架构提供增强； 在商业上

前端发展到如今，在众多领域发光发热，比如Node.js、浏览器、客户端、小程序、小游戏、IOT等，宽度之广前所未见，不管在哪个领域，或多或少的体现了大家对研发效率的追求。谈到研发效率，谁都不能忽略Serverless的影响力，在未来这可能突破性的提升研发效率，就像CDN一样，成为前端的基础设施。 回顾2019年，你会发现，每年的关键词都不一样，这就是前端的变化速度。 回望： 回望这一年，几个大的方向发展非常明显，在基础语言和框架方面，随着很多前端团队的不断壮大和业务复杂度的提升，规模化编程越来越依赖类型系统和面向对象的支持，Typescript被越来越多的开发者所采纳，落地难度不大，效率提升明显，另外，前端三大框架已经趋于成熟，平稳并标准化，对Typescript的支持也越来越完善，Typescript+三大框架已经成为很多前端团队技术栈的标配； 在 小程序方面 ， 19年仍然是小程序突飞猛进的一年 ，各大主流的App都上线了小程序能力的支持，各前端团队也都有了专门的小程序开发团队，以适应更快的小程序开发需求，同时App里很多关键的功能都被小程序所替代，甚至有些App已经变成Native小程序壳，上层的应用实现全部是小程序，这里的好处也显而易见； 跨端开发方面 ， RN生态已经非常成熟 ，或者说看不到太多发展前景，很多团队转战Google生态的Flutter，特别是Flutter

7月9日 19:00-21:30 阿里云开发者社区首场“Offer 5000”直播开启！15位团队技术大牛在线招人，更有《阿里云技术面试红宝书》助你拿下Offer！ 点击图片或戳我查看详情和投简历 作者 | 箫逸 阿里文娱高级技术专家 导读： 转眼 2020 已经过去了一半，是时候来做一次年中总结了。本文中，阿里文娱高级技术专家箫逸总结了自己在阿里 6 年来的成长和收获，分享他在工作中的一些思维方法，以及对生活的一些感悟，希望对同学们有所启发。 观察自己的成长，才能收获更大的成长 很长时间以来我基本都是基于天性或本能在做事情，不是说没有思考，是从来没有思考过自己为什么那么思考。过去一年最大的觉悟是逐渐向内看，自己怎么做的，怎么思考的，怎么成长的，自己为什么是那么想的，为什么是那样做的，抓住思维过程，让更多的天性或本能暴露，向内审视自己做事情的逻辑，从而建立起自己的体系去思考，去想问题。在这个过程中逐渐地形成了自己在成长过程中所遵循的一系列“章法”，我想这是我这一年来最大的成长。 1. 从孩子身上重新学习 闺女 1 岁半，逐渐可以认识挂在墙上的各种水果卡片，虽然她不会说，但是当我问起诸如苹果在哪儿，豌豆射手在哪儿之类的问题时，她总能快速指到正确的位置。我欣喜于这种快速的成长，不禁想她到底是怎么学会的？有意识的观察结果发现，她始终坚持了一个最简单的法则：模仿 -> 重复 -> 学会 -

API 网关结合云函数 SCF 的使用场景非常丰富，本文将介绍如何基于 API 网关+云函数 SCF 快速部署 Serverless 的外卖订单系统。 消息推送使用的典型场景 外卖订单系统架构图 Demo 实战 1. 安装Serverless Framework npm install -g serverless 2. 初始化项目模板 sls init -t websocket-order 3. 查看项目目录 下载到本地后，查看项目目录结构如下： 包含 DB、网关、函数等多个子模块。 db 目录用于创建 PG Serverless 数据库实例 apigateway 用于创建对应的 API ： /bill 下单 API，HTTP 类型 /get_shop_info，获取店铺菜单 API /pgws，用于做消息推送的 websocket API 函数列表如下： 消息推送相关函数： 注册函数 ws_register.py， 配置 DB 的环境变量 传输函数 ws_trans.py ，配置 DB 的环境变量以及 apiid= 消息推送API 注销函数 ws_unregister.py ，配置 DB 的环境变量以及 apiid= 消息推送API 下单函数 bill.py ， 配置 DB 的环境变量以及 apiid= 消息推送API 拉取店铺信息函数 get_shop_info.py，配置

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