Serverless

闲鱼基于Flutter+FaaS的业务框架思考与实践

别来无恙 提交于 2021-02-14 15:58:59
作者| 熊华丽(匠修) 出品|阿里巴巴新零售淘系技术部 前言 闲鱼将使用 Flutter 和 FaaS 来建设未来的技术开发体系,这是一项长期的规划,新的技术在现在看来犹如雾里看花,需要我们不断的思考,探索,实践才能渐渐描绘出它的轮廓。 本文对此提供一种思考角度,对未来基于 FaaS+Flutter 之上的编程形态做思考,并介绍自己的初步实践。 Flutter,Faas,与闲鱼的一体化 闲鱼长期在做技术一体化的探索与实践: 我们希望使用一门语言,一套技术栈,能让开发工程师在任何场景完成业务开发,实现开发模式和技术栈的统一。 这是对开发效率的极致追求,也是对开发人员的深度赋能,更好的释放人员价值,驱动业务成长。 闲鱼已经借助 Flutter 良好的跨栈能力来对 App 上的技术栈做统一,并取得了初步的成果。 因此想更近一步的整合前后端,结合 Flutter 来建立统一的技术栈。 FaaS 的兴起给我们带来了新的视角和机会,在后端开发场景中,FaaS 将运行环境和部署运维从日常开发中剥离出来,让开发者更聚焦于业务,降低了后端开发准入门槛,闲鱼基于此已经在做 Flutter+FaaS 的一体化开发体系建设。 技术在发展中会对当前的解决方案不断的抽象,总结和提炼,逐渐分离出其中的变化的部分与不变的部分,让原来的问题变得收敛,开发的关注点会变的更聚焦,开发效率得以提升。 这样会出现分层

基于 ThinkJS 的云开发体验

眉间皱痕 提交于 2021-02-14 14:21:09
ThinkJS 是一款企业级的 Node.js Web 开发框架,致力于集成项目最佳实践,规范项目让企业级团队开发变得更加简单,更加高效。 它基于 Koa 2.0 开发,兼容 Koa 的所有 Middleware。 内核小巧,支持 Adapter, Extend 等多种插件扩展方式,框架内的大部分功能也是通过这些方式进行扩展的。 性能优异,支持 TypeScript。 云开发 CloudBase 是云原生一体化应用研发平台为开发者提供高可用、自动弹性扩缩的后端云服务,包含计算、存储、托管等能力,可用于云端一体化开发多种端应用(小程序、公众号、Web 应用、Flutter 客户端等),帮助开发者统一构建和管理后端服务和云资源,避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。 其实在云开发中使用 ThinkJS 和我们日常使用大同小异,除了启动文件需要按照云开发的要求修改一下以外,内部的业务逻辑基本不需要改动。 我们可以使用云开发的 CLI 工具 快速的初始化一个适配云开发的 ThinkJS 项目。 其中 thinkjs-app 是你的项目文件夹名称。 tcb new thinkjs-app thinkjs-starter 初始化完毕进入项目目录后执行 npm install 安装好依赖,就可以通过 npm start 启动开发环境了

云原生|消息中间件的演进路线

三世轮回 提交于 2021-02-13 09:39:22
Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS/PaaS/SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年, Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施,是微服务架构应用的核心依赖,也是实践云原生的核心设计理念的关键技术,通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

云原生|消息中间件的演进路线

北城以北 提交于 2021-02-13 01:57:53
Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS/PaaS/SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年, Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施,是微服务架构应用的核心依赖,也是实践云原生的核心设计理念的关键技术,通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

云原生时代消息中间件的演进路线

笑着哭i 提交于 2021-02-13 01:45:53
简介: 本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》,主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 作者 | 周礼(不铭) 阿里巴巴集团消息中间件架构师 导读 :本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》,主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 引言 本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线,但本文绝对不是“开局一张图,内容全靠编”。 从虚拟化技术诞生以来,IaaS / PaaS / SaaS 概念陆续被提了出来,各种容器技术层出不穷。到 2015 年,Cloud Native 概念应运而生,一时间,各种云厂商,云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考,传统的消息中间件需要做些什么才能加上云原生这个修饰词,这也是本文探讨的主题:传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 1. 什么是云原生 首先来谈谈什么是云原生,云原生是一个天然适用于云计算的架构理念,实践云原生技术理念的应用可以最大化享受云计算的技术红利,包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素: 采取 DevOps 领域的最佳实践来管理研发和运维流程; 通过 CICD

AWS Aurora Serverless Spring Boot Communication Link Error

﹥>﹥吖頭↗ 提交于 2021-02-11 17:01:51
问题 I am doing a prototype for moving our Spring Boot based application to AWS Aurora DB including Serverless mode. With Provisioned mode things work as expected. However with serverless mode the application is not able to connect to the DB from EC2 instance with exception as: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]:

Not able to solve throttlingException in DynamoDB

喜夏-厌秋 提交于 2021-02-11 16:48:34
问题 I have a lambda function which does a transaction in DynamoDB similar to this. try { const reservationId = genId(); await transactionFn(); return { statusCode: 200, body: JSON.stringify({id: reservationId}) }; async function transactionFn() { try { await docClient.transactWrite({ TransactItems: [ { Put: { TableName: ReservationTable, Item: { reservationId, userId, retryCount: Number(retryCount), } } }, { Update: { TableName: EventDetailsTable, Key: {eventId}, ConditionExpression: 'available >

AWS Lambda doesn't recognize NODE_EXTRA_CA_CERTS

六眼飞鱼酱① 提交于 2021-02-11 14:33:05
问题 I'm using the serverless framework and I'm trying to reference a bundled certificate in a lambda function for some API calls. Locally, when setting and pointing NODE_EXTRA_CA_CERTS to my cert, everything works as it should. I've configured an environment variable for NODE_EXTRA_CA_CERTS with my lambda and point it to the bundled cert as follows in my serverless.yml , but the AWS node environment doesn't pick it up: provider: name: aws region: us-east-2 runtime: nodejs12.x endpointType:

Serverless with localstack-serverless plugin not querying template locally

心不动则不痛 提交于 2021-02-11 13:41:59
问题 Based on the official example on GitHub demonstrating a serverless REST API I enabled the localstack-serverless plugin so I could develop my services locally. I adjusted the serverless.yml file accordingly: service: serverless-rest-api-with-dynamodb frameworkVersion: ">=1.1.0 <2.0.0" provider: name: aws runtime: python2.7 deploymentBucket: name: ${self:service}-${opt:stage}-deployment-bucket environment: DYNAMODB_TABLE: ${self:service}-${opt:stage, self:provider.stage} iamRoleStatements: -

从零入门 Serverless | 函数计算的可观测性

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