peter
经过老师的案例分析,对Serverless有了一个新的认识!
作者回复:谢谢你的反馈,让我感觉这门课值得我的投入
2020-05-19
麦乐
老师您好,如何解决这个 "F" 不够纯函数的问题?FaaS 里面的函数理论上应该尽可能以函数式编程的思想去编写,那就意味着,函数本身是无状态的,但是业务逻辑是有状态的。比如,用户鉴权,如果只用一个函数去完成这样的逻辑,那这个函数与业务就强耦合了。怎么让这个函数与业务解耦呢?
第二个问题是怎么实现像 Koa 中间件那样的场景呢?是一个 函数实例 调用另一个 函数实例吗?
作者回复:后面的课程会讲到,状态要放到BaaS中。FaaS虽然叫函数即服务,实际使用也可以部署整个应用,不过有体积大小限制。拆解成一堆函数也有调用成本,所以通常是需要折中。中间件的用法是一样的,你可以通过npm安装,在代码中require使用。
2020-06-20
3
我来也
"这个专栏是一堂服务端技术架构课"
这个描述一点也不夸张.
从一个简单项目的多次变迁,可以看清架构是如何演变的.
新引入的技术解决了原有中的什么问题.
其实在平常的工作中,很难有这种完整的经历.
特别是在业务比较平稳的企业,或业务规模不大的小企业中,原有的架构可能并不会遇到瓶颈.
领导可能并没有优化架构的意愿.
也许以后的人,都是直接基于云原生云平台来开发了.
但理清了历史的变迁过程,才能更好的用好当下,和展望未来.
-----
看了老师的答疑,我有了新的认识.
虽然现在的Serverless大多都是Node.js或TypeScript的案例,但并不代表就只适合这个.
后面还有很大的想象空间,我们可以基于自己熟悉的语言,熟悉的场景,来用好Serverless.
为以后的人提供一些经验和参考.
-----
感谢老师在此期间的辛苦付出!
作者回复:感谢你一路的支持,坚持做课后作业。我的课后作业也都画了很多心思设计的,以后我还想做成一个更完整的例子,不过只会更新github仓库了。
因为目前Serverless应用,我碰到好多前端同学学习,他们中间的知识跨度太大,所以才有了这门课的想法。使用Serverless不难,难的是怎么在实际工作中使用Serverless,目前也是百家齐鸣,这里无论是创业,就业,还是提升自我影响力,机会都很多。
2020-05-13
8
技术修行者
对serverless的来龙去脉讲的很清楚,尤其是举的例子非常棒。
serverfull->devops->serverless,这条线很好的描述了软件研发不断优化的过程。
serveeless对前后端都会带来很大的影响,我们必须积极的拥抱这种变化。
作者回复:不难看出你的互联网经验很丰富,Serverless也是互联网发展的产物。
我以前刚开始工作时,就要蹲到电信机房,自带键盘和显示器,调试服务器。
一步步发展过来,更能体会Serverless带来的变革。
2020-05-09
我来也
课后作业:
1. 由于镜像中有aliyunConfig,所以不建议将镜像公开.(即不要推送到默认的 https://hub.docker.com/)
2. 我是在template.yml文件中添加了一行`Initializer: index.initializer`实现了作业1:部署的 rule-faas 函数添加初始化入口
3. 使用阿里云ECI部署时,需要申请弹性公网EIP.
注意: 这里需要指定端口号3001访问服务, 默认的80端口是无法访问到服务的!!!
与本地调试一样,某些操作会触发容器重启.
4. 本地调试时,使用get方法访问`http://localhost:3001/api/rule`可以正常获取结果.
但是完成/删除(使用put/delete方法)时,会提示403"用户得到授权,但是访问是被禁止的。"
docker反馈的日志如下:
```
/home/myhome/myapp/node_modules/tablestore/lib/request.js:66
throw err;
^
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
at ServerResponse.setHeader (_http_outgoing.js:470:11)
at ServerResponse.header (/home/myhome/myapp/node_modules/express/lib/response.js:771:10)
at ServerResponse.send (/home/myhome/myapp/node_modules/express/lib/response.js:170:12)
at ServerResponse.json (/home/myhome/myapp/node_modules/express/lib/response.js:267:15)
at Response.<anonymous> (/home/myhome/myapp/index.js:151:16)
at Request.<anonymous> (/home/myhome/myapp/node_modules/tablestore/lib/request.js:162:18)
at Request.callListeners (/home/myhome/myapp/node_modules/tablestore/lib/sequential_executor.js:113:20)
at Request.emit (/home/myhome/myapp/node_modules/tablestore/lib/sequential_executor.js:81:10)
at Request.emit (/home/myhome/myapp/node_modules/tablestore/lib/request.js:189:14)
at Request.transition (/home/myhome/myapp/node_modules/tablestore/lib/request.js:57:10)
```
由于不太懂node.js,所以也不知道如何解决.
之前部署到阿里云FC时是没有遇到过该问题的.
作者回复:我刚刚看了一下,是因为JWT token的原因。这个分支加了JWT验证,如果不是浏览器访问请求中带JWT token过来,或者token校验失败,put/post/delete都会报403.
2020-05-01
TKbook
老师这个讲解够细致,本来真是一头雾水,看了之后,有种豁然开朗的感觉。
作者回复:谢谢你的支持。
也欢迎你将自己的理解整理成笔记,加深自己的记忆,还可以分享给更多的人。
2020-04-29
大表哥
听了这节课感觉这钱没白花,妥妥的实力派。然后一开始吸引我的是省钱哈哈哈(我是说中长尾服务模块)。作为一个12年后台开发、架构师也来拥抱一下serverless。
作者回复:Serverless对于中长尾应用的场景,的确比较适合。在没有流量的时候缩容为0,节省流量。可以节省不少开支。
2020-04-28
6
电光火石
老师好,在后台服务baas化的过程中,关于数据库跟以前微服务的方式有些不一样,微服务的各个节点是共享数据库的,但是baas化中,每个节点有自己的数据库,而且数据库的内容是一样的。这样是否带来2个问题:
1. 在数据量很大的情况下,每个节点都有一样的数据库,是否会使得数据存储量会翻几倍,成本会很高
2. 在扩容的情况下,如果数据量很大,新节点需要复制的数据也很多,启动时间会非常的长
3. 有多少个应用,就有多少个数据库实例。一般情况下,我们应用的数量会远高于数据库机器的数量。高并发场景下,会不会导致网络占用很高,性能整体上升
还是说这种方案本身就不适合大并发或者数据量很高的场景,谢谢了!
作者回复:微服务标准的做法是一个微服务实例独享一个数据库实例的。当然你业务量不大,可以多个微服务实例共享一个数据库实例。
微服务架构在docker流行后才火,就是因为docker可以让计算资源进一步碎片化,所以成本并不会很高。
数据实例的启动时,通常是先从现有数据库副本创建,再根据消息队列同步后续数据。启动实例过程是秒级的。
微服务架构,本身就是通过拆解将复杂的业务问题变成一个个小的职责单一的小服务。运维的复杂度会上升,但是整体性能并不会下降多少。
你可以想想,现在的京东,淘宝这样的网站,背后都是微服务架构的。如果你用单体应用开发这么庞大的一个应用,这么多团队和人员参与,怎么去运维和开发。
2020-04-27
4
我来也
# 对于 用完即毁型和常驻进程型 的体会
以前我做游戏时,很多状态都是维护在内存中.
这种服务如果迁移到FaaS就很困难.需要做改造,把需要持久化的数据存储到其他地方.
现在做的服务,是基于接口对外提供的服务.
本身不存储状态,都是根据数据库中的数据库反馈结果.
现在的服务,理论上其实可以很方便的迁移到FaaS.
虽然是常驻进程型的,但本身并不存储状态.
就是在初始化阶段,需要连各种数据库,会耽误点时间.
# 对于并发访问的思考
昨天晚上还在想,明天要抽时间用ab压测一下函数计算提供的接口.
看看所谓的`并发度`到底是什么.
之前在文档上看过,一个函数实例可以配置允许的同时并发度,如果不够了,就会冷启动新的实例.
我之前测试的服务都是常驻进程型的,我就想搞个定时任务,每分钟请求一次,保证服务进程不会被回收.
其实每分钟请求一次的消耗也不大,但如果能消除冷启动,绝对是划算的.
但后来一想,这个只针对单实例有效,如果想保证同时有N个实例,如何才能保证定时请求可以将N个实例都访问到呢?
这个需要用再实践一下.
# 课后作业
由于前几天已经配置了阿里云的fun本地环境,自己也有备案了域名,所以实践老师的作业只需要简单的几部.
[我在老师的专栏开始之前完全未接触过node.js 现在也只是跟着老师部署了几个简单的node.js服务]
1. 克隆代码
git clone https://github.com/pusongyang/todolist-backend
2. 拷贝文件
cp index-faas.js index.js
3. 安装依赖
npm install
4. 创建template.yml文件
```
ROSTemplateFormatVersion: '2015-09-01'
Transform: 'Aliyun::Serverless-2018-04-03'
Resources:
todolist-backend:
Type: 'Aliyun::Serverless::Service'
Properties:
Description: 'helloworld'
todolist-backend:
Type: 'Aliyun::Serverless::Function'
Properties:
Handler: index.handler
Runtime: nodejs10
CodeUri: './'
Events:
httpTrigger:
Type: HTTP
Properties:
AuthType: ANONYMOUS
Methods:
- GET
- POST
```
5. 部署服务
fun deploy -y
6. 绑定自定义域名
需要把路径/*都绑定到该服务上
7. 验证效果
可以重现老师的服务: http://todo.jike-serverless.online/list
# 扩展思考
如果只是测试,可以配合NAS服务来持久化部分数据.
我之前写demo时,用这个功能,简单的记录我函数计算服务的访问日志和时间.
仅仅只是测试,并未考虑到多实例并发访问的问题.
作者回复:欢迎将你的做法也提MR到github上面来。
https://github.com/pusongyang/todolist-backend/
2020-04-24
6
我来也
# 最近几天实战了下阿里云的函数计算服务.
使用golang按着官方文档,实现了几个常驻进程模型的服务.
也照着老师的操作,建了node.js和python的函数.
相比之下,python和node.js的冷启动时长确实比较短,我这边看冷启动时接口的响应耗时在600-800ms.
但是之后热启动时的耗时就只有30-50ms.
而golang的冷启动时长不知道为什么要2.5s.而热启动后的接口耗时也才60ms.
我还发现,阿里云上,5分钟以后,常驻进程模型的函数就被干掉了.症状就是初次接口耗时又要2s+.
可以肯定的是,不到10分钟,无响应的函数就被系统回收了.肯定是没到15分钟.
我还发现,介于冷启动和热启动之间,还有一个状态,接口的响应耗时也是介于两者之间.
# 对服务编排的个人感悟
感觉函数服务配合服务编排,就像是在linux上使用shell组合各种命令,实现复杂的功能.
虽然每个命令都很简单,但是组合后的功能就很强大了.
现在的云服务都会有很多现成的sdk,确实如老师所说,需要用到某个云服务时临时把官方的文档拿出来,几乎只需要做很少的变动,就可以马上投入使用.
我目前使用函数服务,配合nas和日志服务,就可以很容易的把东西存在nas上,在阿里云的日志服务中搜索相关日志.
不足之处就是调试没有之前方便了.
作者回复:必须给你手动点赞,写的非常详细。云服务商承诺的回收时间,目前其实是不确定的。能够承诺时间的只有AWS(所以我的文章中没有给出具体回收时间)。通常阿里云1分钟到10分钟,没有请求就会被回收,不过1分钟是可以承诺的。因为冷启动的时间很快,所以通常影响不大。如果对冷启动增加的几百毫秒比较敏感的场景,还是建议使用CaaS服务。
2020-04-22
17
编辑推荐
包含这门课的学习路径
前端工程师
24门课程 109.3w人学习
云原生工程师
14门课程 86.5w人学习
看过的人还看了