Serverless

作者 | 万佳 嘉宾 | 巴滕 闲鱼是从阿里巴巴某一茶水间“游”出来的。2014 年 6 月，闲鱼诞生，2 年时间不到，其用户数突破 1 亿。如今，它已经成为国内最知名的闲置交易平台，拥有数亿用户，年交易额超过 2000 亿，并开启了一个万亿市场。闲鱼能有今天的成绩，离不开背后的技术迭代、架构升级和技术人的付出。闲鱼初创时，架构设计面临着哪些挑战？闲鱼服务端架构在 6 年时间里是怎样演进的？闲鱼在服务端架构上还在做哪些新尝试？...... 带着这些问题，InfoQ 记者采访了闲鱼技术部高级技术专家巴滕。自闲鱼创立以来，他一直参与闲鱼服务端架构持续演进的工作。 1、闲鱼的业务特点 据巴滕介绍，闲鱼是一个典型的双边市场，买家和卖家规模相互影响，“如何同时服务好买家和卖家双方，这是我们一直努力的方向”。 对买家来说，要提升商品发现效率，帮助他们尽快地买到商品。 对卖家而言，要降低发布门槛，帮助他们尽快地把商品卖出去。 对于平台，要持续优化用户的使用体验，比如降低纠纷和欺诈问题，同时持续扩大市场规模。 2、闲鱼服务端最初的架构设计 众所周知，闲鱼的前身是 PC 时代的淘宝二手，它属于淘宝的一个小频道。当时，闲鱼整体业务规模和用户量都非常小。基本上，单一应用就支撑所有业务，并且整体架构和服务完全是面向 PC 设计的。 “当时，服务端同学需要时常编写 Velocity 模板代码

简介： 由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月 18-19 日在线上召开。本次大会聚焦微服务架构前沿发展和业界最佳实践，重点探讨云原生语境下微服务的挑战和技术趋势，帮助企业技术决策者、架构师、开发者们迎接云原生时代的到来。 最近，O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示，在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后，有 77％ 的组织反馈采用了微服务，其中 92％ 的组织成功使用了微服务。 如果以这份报告为依据，微服务在企业的普及率已接近八成。看起来，企业对微服务的兴趣可能已经接近顶峰。 云原生的基础设施从设计上保证了它是微服务部署的最佳平台，但是也对现有的微服务框架带来了新的挑战 ，在云原生大行其道的今天： 我们对微服务还应该继续投入精力关注吗？ 云原生和微服务之间的关系是什么？ 随着 Serviece Mesh 等技术的不断成熟，微服务的体系和思想会产生怎样的演化？ Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗？ 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角，会如何助力下一代微服务架构为业务发展赋能？ 这些问题值得每一位技术从业人员去思考，并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说：

作者 | 夏莞 阿里巴巴函数计算团队 本文整理自 《Serverless 技术公开课》 导读 ：本文主要分为三个部分：概述中介绍可观测性的基本概念，主要包括 Logging、Metrics、Tracing 三个方面；然后详细介绍函数计算上的 Logging、Metrics、Tracing；最后以几个常见场景为例，介绍在函数计算中如何快速定位问题并解决问题。 概述 可观测性是什么呢？维基百科中这样说：可观测性是通过外部表现判断系统内部状态的衡量方式。 在应用开发中，可观测性帮助我们判断系统内部的健康状况。在系统出现问题时，帮助我们定位问题、排查问题、分析问题；在系统平稳运行时，帮助我们评估风险，预测可能出现的问题。评估风险类似于天气预报，预测到明天下雨，那出门就要带伞。在函数计算的应用开发中，如果观察到函数的并发度持续升高，很可能是业务推广团队的努力工作导致业务规模迅速扩张，为了避免达到并发度限制触发流控，开发者就需要提前提升并发度。 可观测性包括三个方面：Logging、Metrics、Tracing Logging 是日志，日志记录了函数运行中的关键信息，这些信息是离散且具体的，结合错误日志与函数代码可以迅速定位问题。 Metrics 是指标，是聚合的数据，通常以图表的形式展现。图表中的 tps、错误率等核心指标，可以反映函数的运行情况与健康状况。 Tracing 是链路追踪

作者|孙棋(空蒙) 出品|阿里巴巴新零售淘系技术部 导读：当前移动互联网业务研发运维模式，云与多端互相割裂，有些全栈的探索缺乏成功案例，行业对云端一体化研发这块仍是空白，我们要思考： 如何能实现 1 个研发支撑云 + android + iOS 三端的业务快速落地。 是否有新的研发运维模式，让程序员回归程序，“一次编码、到处运行”是我们的答案。我们在闲鱼项目验证，原本 60 天的项目时间减少了 20 天，提效 33% 。希望本文的分析也能够给大家带来收获。 业务研发模式的演进 效率是业务研发运维模式演进核心驱动力 PC 互联网时代，单体应用包含前后端是最初的研发模式（淘宝经历开发人员写 velocity 模板，以及更早的 jsp、asp 页面）其实质是中心化搭火车的研发模型。 随着业务发展复杂性快速增加，赶火车的交付模式，极大的限制了业务发展，因此诞生了服务化的拆分，淘宝在 09 年的五彩石项目即基于这样的背景，微服务是一种软件架构，这背后更是一种研发模式的变革，从中心化研发模式到分布式的研发模式升级。 在业务分布式研发模式升级的同时，前后端分离研发模式也在同步的演进，从 ajax 到专业前端独立完成业务闭环，职业分工细化提效。但对前端同学而言，服务端的运维始终是其痛苦的技术门槛，以及在阿里以 Java 语言为基础的中间件生态内，一直没有很好解决。 进入移动互联网时代

简介： 整体介绍一下淘系前端在今年双11的思考和沉淀。 今年双11的整体节奏从之前的“光棍节”变为“双节棍”，具体业务上也有很多变化和调整，应了阿里的土话“唯一不变的是变化”。面对这些变化，是挑战也是机会，我们要做的就是，“既要”高效支撑保障业务先赢，“又要”确保体验和稳定性带给用户极致体验，“还要”追求创新让前端持续演进。为了实现“既要、又要、还要”，包括技术方案、流程机制、人员组织等各方面都进行了大量的设计和保障。最终第一次双峰的双11圆满结束，淘系前端也实现了自己的目标，包括应用大量优化手段和创新方案带来业务转化提升；将FaaS、PHA、ESR等技术应用在更多场景，分别向服务端、客户端、CDN节点进一步拓展了前端的能力和边界；应用视觉还原、一体化研发等提升研发效率，大幅缓解资源瓶颈等等。下面会整体介绍一下淘系前端在今年双11的思考和沉淀，希望对大家有所助益。后续也会有各个专项的系列文章，希望大家持续关注。 变化 & 挑战 今年的双11，首先感受到的就是源源不断的变化。 单峰变双峰：双11从之前的一个波段变成今年的两个波段，大促的三个阶段预售、预热、正式也都对应的翻倍。首先带来的是研发工作量的大幅增加，在时间排期不变、工作量增加、人员不变的情况高效的完成需求研发是第一重挑战；其次面对6个阶段的状态变化，如何保持准确切换、稳定运行、体验流畅是在双峰期间要重点保障的内容

KubeSphere v3.0 发布是 KubeSphere 社区最重要的里程碑，v3.0 刚刚 GA 发布了两个多月，就受到了来自合作伙伴、用户、贡献者等多方面的高度认可。例如， KubeSphere 上架 AWS Quickstart 深度集成 Amazon EKS，还与 AWS、Cisco、Intel 等国际巨头厂商发布了联合解决方案；KubeSphere 在头部互联网和金融行业也有了更多的用户落地实践，比如 中通基于 KubeSphere 构建了大规模的 ZKE 容器平台 ， 微众银行基于 KubeSphere 打造了一站式云原生机器学习平台 Prophecis ， 遥望网络使用 KubeSphere 支撑了 “双十一” 活动完成了 13.2 亿规模的交易 ；开源社区贡献者数量的增长也迎来了新的一轮井喷，几个核心开源项目的贡献者总数已经超过了 100 人。 KubeSphere 之所以能够如此快速发展，得益于开源社区带来的天然优势，以及社区里长期活跃的用户、贡献者积极参与社区，帮助推动产品和社区快速成长， 我们坚持认为 KubeSphere 开源社区的每一位用户和贡献者朋友都是 KubeSphere 生态中的重要组成部分 。为了跟社区朋友们零距离交流，12 月 19 日，KubeSphere 社区联合 CNCF 将在北京举办一场年度的云原生 Meetup，