经过老师的案例分析，对Serverless有了一个新的认识！

老师您好，如何解决这个 "F" 不够纯函数的问题？FaaS 里面的函数理论上应该尽可能以函数式编程的思想去编写，那就意味着，函数本身是无状态的，但是业务逻辑是有状态的。比如，用户鉴权，如果只用一个函数去完成这样的逻辑，那这个函数与业务就强耦合了。怎么让这个函数与业务解耦呢？ 第二个问题是怎么实现像 Koa 中间件那样的场景呢？是一个 函数实例 调用另一个 函数实例吗？

"这个专栏是一堂服务端技术架构课" 这个描述一点也不夸张. 从一个简单项目的多次变迁,可以看清架构是如何演变的. 新引入的技术解决了原有中的什么问题. 其实在平常的工作中,很难有这种完整的经历. 特别是在业务比较平稳的企业,或业务规模不大的小企业中,原有的架构可能并不会遇到瓶颈. 领导可能并没有优化架构的意愿. 也许以后的人,都是直接基于云原生云平台来开发了. 但理清了历史的变迁过程,才能更好的用好当下,和展望未来. ----- 看了老师的答疑,我有了新的认识. 虽然现在的Serverless大多都是Node.js或TypeScript的案例,但并不代表就只适合这个. 后面还有很大的想象空间,我们可以基于自己熟悉的语言,熟悉的场景,来用好Serverless. 为以后的人提供一些经验和参考. ----- 感谢老师在此期间的辛苦付出!

对serverless的来龙去脉讲的很清楚，尤其是举的例子非常棒。 serverfull->devops->serverless，这条线很好的描述了软件研发不断优化的过程。 serveeless对前后端都会带来很大的影响，我们必须积极的拥抱这种变化。

课后作业: 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时是没有遇到过该问题的.

老师这个讲解够细致，本来真是一头雾水，看了之后，有种豁然开朗的感觉。

听了这节课感觉这钱没白花，妥妥的实力派。然后一开始吸引我的是省钱哈哈哈（我是说中长尾服务模块）。作为一个12年后台开发、架构师也来拥抱一下serverless。

老师好，在后台服务baas化的过程中，关于数据库跟以前微服务的方式有些不一样，微服务的各个节点是共享数据库的，但是baas化中，每个节点有自己的数据库，而且数据库的内容是一样的。这样是否带来2个问题： 1. 在数据量很大的情况下，每个节点都有一样的数据库，是否会使得数据存储量会翻几倍，成本会很高 2. 在扩容的情况下，如果数据量很大，新节点需要复制的数据也很多，启动时间会非常的长 3. 有多少个应用，就有多少个数据库实例。一般情况下，我们应用的数量会远高于数据库机器的数量。高并发场景下，会不会导致网络占用很高，性能整体上升 还是说这种方案本身就不适合大并发或者数据量很高的场景，谢谢了！

# 对于 用完即毁型和常驻进程型 的体会 以前我做游戏时,很多状态都是维护在内存中. 这种服务如果迁移到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时,用这个功能,简单的记录我函数计算服务的访问日志和时间. 仅仅只是测试,并未考虑到多实例并发访问的问题.

# 最近几天实战了下阿里云的函数计算服务. 使用golang按着官方文档,实现了几个常驻进程模型的服务. 也照着老师的操作,建了node.js和python的函数. 相比之下,python和node.js的冷启动时长确实比较短,我这边看冷启动时接口的响应耗时在600-800ms. 但是之后热启动时的耗时就只有30-50ms. 而golang的冷启动时长不知道为什么要2.5s.而热启动后的接口耗时也才60ms. 我还发现,阿里云上,5分钟以后,常驻进程模型的函数就被干掉了.症状就是初次接口耗时又要2s+. 可以肯定的是,不到10分钟,无响应的函数就被系统回收了.肯定是没到15分钟. 我还发现,介于冷启动和热启动之间,还有一个状态,接口的响应耗时也是介于两者之间. # 对服务编排的个人感悟 感觉函数服务配合服务编排,就像是在linux上使用shell组合各种命令,实现复杂的功能. 虽然每个命令都很简单,但是组合后的功能就很强大了. 现在的云服务都会有很多现成的sdk,确实如老师所说,需要用到某个云服务时临时把官方的文档拿出来,几乎只需要做很少的变动,就可以马上投入使用. 我目前使用函数服务,配合nas和日志服务,就可以很容易的把东西存在nas上,在阿里云的日志服务中搜索相关日志. 不足之处就是调试没有之前方便了.