Serverless

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

KubeCon EU 前几天刚刚结束，6月24日 KubeCon China 又要来了。KubeCon + CloudNativeCon + Open Source Summit China 2019，它的前身为 LinuxCon + CloudOpen + ContainerCon China（LC3），是国内开源技术届最大的盛会之一。本次活动将聚焦 Kubernetes 和 Cloud Native 生态最新进展，对于关注云原生领域的同学来说不容错过。 在这次 KuberCon上，蚂蚁金服核心技术团队将举办一场全天的 Workshop，给大家分享分布式架构 SOFAStack、Service Mesh、Serverless、分布式事务 Seata 的实践案例，跟大家一起轻松上手云原生技术。 Service Mesh + Serverless 快速上手 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，如何轻松的实践 Service Mesh 技术？在活动现场，我们将带你感受 CloudMesh 通过将 Service Mesh 托管在云上，助力轻松实践 Service Mesh 技术。 作为云原生技术前进方向之一， Serverless 架构 让您进一步提高资源利用率，更专注于业务研发

作者 | 许晓斌 阿里云高级技术专家，目前负责阿里集团 Serverless 研发运维平台建设，《Maven 实战》作者，曾经是 Maven 中央仓库的维护者。 **导读：**本文作者作为阿里集团 Serverless 研发运维平台负责人，从应用架构的角度去分析 Serverless 为何会让那么多人着迷，它的核心概念究竟是什么，并总结了一些落地 Serverless 必然会面临的问题。 前言 我曾在 《Serverless 的喧哗与骚动》 一文中对 Serverless 今天在行业中所处的状态做了一个比喻，这个比喻是这么说的： Serverless is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it. 虽然距离写那篇文章已经过去了半年的时间，但是这种状态在我看来其实没有发生太大的变化，有很多的一线研发或者管理者对 Serverless 技术的理解是非常片面的，有些甚至是错误的。如果缺乏对应用架构演进的理解，缺乏对于云基础设施能力的理解，缺乏对风险的判断，盲目的上新技术可能不仅无法兑现业务价值，浪费精力

作者 | 山猎 近年来，Serverless 一直在高速发展，并呈现出越来越大的影响力。主流的云服务商也在不断地丰富云产品体系，提供更好的开发工具，更高效的应用交付流水线，更好的可观测性，更细腻的产品间集成，但一切才刚刚开始。 国内一些大公司已经有了一些成熟的 Serverless 应用案例，一些创业公司也开始加入 Serverless 阵营，如果说Serverless 到底解决了什么问题，核心就是节约成本、节省精力。 蓝墨是一家由美国留学生回国创业的高科技公司，专注于移动互联时代数字出版和移动学习领域的新技术研究及平台运营，依托自主研发的蓝墨移动交互式数字教材核心技术体系，为出版社、学校和教师提供移动交互式数字教材、校园移动学习平台及教师自助数字出版等解决方案。 自 2012 年成立以来，蓝墨的技术团队对于一些开放的新技术抱有极大的热情，并愿意应用快速迭代的互联网新技术，来确保其业务系统稳定运行。2020 年初，疫情期间，在线教育迎来需求爆发。为了应对高流量，蓝墨加大了整合业界优质课程资源的力度，不断拓展自身的业务边界，在赢得机遇的同时，技术团队也面临了前所未有的挑战。 面临挑战 作为教学平台，蓝墨每天要处理大量视频教材资源，涉及到视频剪辑、切分、组合、转码、分辨率调整、客户端适配等一系列复杂的技术工作，视频处理相关业务是蓝墨的技术团队面临的最大挑战之一。通过几年的技术实践

简介： 针对Yeahmobi在全球业务中需要统一治理数据资产和提供高并发、高弹性的存储服务需求，阿里云为Yeahmobi构建了一站式的数据湖解决方案。 Yeahmobi介绍 Yeahmobi是一家技术驱动发展的国际化智能营销服务公司，致力于为客户提供精准的全球营销推广服务，帮助企业在全球范围内高效地获取用户、提升品牌知名度、实现商业化变现。 作为全球领先的第三方独立广告服务商，Yeahmobi拥有丰富的全球媒体资源。平台数据覆盖全球200多个国家和地区。经过多年的不断积累，Yeahmobi目前与全球各大平台的头部与中长尾优质媒体建立了长期稳定的合作关系，构建起以优质头部流量、垂直领域细分流量、中长尾聚合流量的移动端媒体矩阵。 Yeahmobi业务场景介绍 由于Yeahmobi的投放业务覆盖全球，在执行过程中，发现来自全球各地、各行业广告主针对不同细分市场的需求。为了更好地实现精准营销落地，就需要从技术上打通上下游数据，完成跨Region的数据采集、管理，并最终有效地形成可持续优化的算法模型，最终反哺业务决策。 三大业务难点 在数字营销广告业务执行过程中，为了实现全球数字资产统一治理，Yeahmobi常常需要面对以下几个不同的挑战 原生数据本地化部署，统一收归治理成难题 由于服务的国家范围较广，为了实现服务质量的一致性，需要实现不同区域的本地化部署

简介： 2020 年，新冠肺炎疫情催化数字化生活方式渐成常态。在企业积极进行数字化转型、全面提升效率的今天，几乎无人否认背负“降本增效”使命诞生的 Serverless 即将成为云时代新的计算范式。 来源| 阿里巴巴云原生公众号 2020 年，新冠肺炎疫情催化数字化生活方式渐成常态。在企业积极进行数字化转型、全面提升效率的今天，几乎无人否认背负“降本增效”使命诞生的 Serverless 即将成为云时代新的计算范式。 Serverless 将开发者从繁重的手动资源管理和性能优化中解放出来，正在引发云计算生产力的新变革。 然而，Serverless 的落地问题却往往很棘手，例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。 尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于 Serverless 核心场景规模化落地最佳实践的呼唤更加迫切。 总交易额 4982 亿元，订单创建峰值 58.3 万笔/秒，2020 年天猫 双11 又一次创造记录。对于阿里云来说，今年的 双11 还有另一个意义： 阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地

2020 年，新冠肺炎疫情催化数字化生活方式渐成常态。在企业积极进行数字化转型、全面提升效率的今天，几乎无人否认背负“降本增效”使命诞生的 Serverless 即将成为云时代新的计算范式。 Serverless 将开发者从繁重的手动资源管理和性能优化中解放出来，正在引发云计算生产力的新变革。 然而，Serverless 的落地问题却往往很棘手，例如传统项目如何迁移到 Serverless，同时保障迁移过程业务连续性，在 Serverless 架构下如何提供完善的开发工具、有效的调试诊断工具，如何利用 Serverless 做更好的节约成本等，每一个都是难题。 尤其涉及到在主流场景大规模的落地 Serverless ，更是并非易事。正因为这样，业界对于 Serverless 核心场景规模化落地最佳实践的呼唤更加迫切。 总交易额 4982 亿元，订单创建峰值 58.3 万笔/秒，2020 年天猫 双11 又一次创造记录。对于阿里云来说，今年的 双11 还有另一个意义： 阿里云实现了国内首例 Serverless 在核心业务场景下的大规模落地，扛住了全球最大规模的流量洪峰，创造了 Serverless 落地应用的里程碑 。 Serverless 落地之痛 挑战一：冷启动耗时长 快弹是 Serverless 天然自带的属性，但是快弹的条件是要有极致的冷启动速度去支撑。在非核心的业务上

抽象的 DevOps “ DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践，以便他们可以更快，更可靠地构建，测试和发布软件。DevOps 的概念建立在建立团队之间协作文化的基础上，这些团队过去一直在相对孤岛中运作。” 类似于这种的 DevOps 相关的描述听起来特别抽象，非常学术，非常教科书，让人感觉无法落地，不知道该如何入手。很多团队在了解 DevOps，实践 DevOps 的时候不能很好的多维度看待 DevOps，实践的过程也很痛苦，不知道这种新型的理念如何实际提升自己团队的战斗力。 本文从开发和运维两个视角多层次的讲解什么场景应该 Dev 和 Ops、什么场景应该 DevOps，即 DevOps 的分与合，并使用一个 Demo 示例告诉大家 DevOps 中的关键步骤持续部署如何实践。 DevOps 的两个视角 DevOps 从字面上看就是开发和运维，也有翻译为开发运维（运营）一体化。我们这里的两个视角不是别的东西，正是开发和运维。这里的开发，不能简单的理解为开发工程师，指代的是整个软件的研发过程所含的所有要素，涵盖需求分析、开发、测试等等，其终点是可交付的软件制品。同样运维不仅仅是运维工程师，指代的是软件交付后投产过程以及后续的运营，反馈等系列过程，其起点是接受交付的软件制品。 这么两个视角的区分是隐含着软件工程背后的逻辑的，就像一栋大楼

作者 | changshuai 来源 | Serverless 公众号 FaaS 的门槛 Serverless 形态的云服务帮助开发者承担了大量复杂的扩缩容、运维、容量规划、云产品打通集成等责任，使得开发者可以专注业务逻辑、提高交付速度 (Time-to-market) ，持续优化成本。Function-as-a-Service (FaaS) 作为云上最早也是应用最广泛的 Serverless 计算形态，在几年的时间内吸引了大批开发者，逐渐建立了 Serverless 优先的选型逻辑。然而从传统应用迁移到 FaaS 在开发者体验上还面临诸多挑战： 环境不统一 ：各厂商定义的交付物格式，运行环境兼容性、丰富度都不尽相同，需要开发者适配，甚至重新编译； 学习成本 ：打包依赖库、构建成压缩代码包和熟悉的开发部署方式不同； 服务限制 ：如代码包限制在百 MB 级别，迫使交付物代码依赖分离，加大管理和发布难度； 交付物缺乏版本管理 ：格式不标准，最佳实践不统一，需要开发者自行负责； 生态不成熟 ：缺少流行开源工具（如 CI/CD 流水线）的支持和集成。 另一方面，容器在可移植性和交付敏捷性上实现了颠覆式创新。围绕容器的生态沉淀非常丰富且成熟，被广泛接受使用，应用容器化正在快速成为开发和部署的事实标准。然而容器本身并没有减轻运维、扩缩容、闲置成本、和云服务集成等难题。 函数计算支持容器镜像