开发者学堂课程【深入浅出白话 Serverless-1024 程序员节创造营公益课：课程2：从一个博客说起】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/890/detail/14263
课程2：从一个博客说起
目录
一、实现 Hello World
二、一个 Wed 服务版的 Hello World
三、查询 IP 地址的服务
四、一个传统博客部署到 Serverless 架构
五、Serverless 架构的开发流程
一、实现 Hello World
打开阿里云首页
登陆注册
选择 Serverless 下面的函数计算控制台
进入之后开始创建服务 输入服务的名称
点击确定
完成创建之后进一步创建函数
输入函数名称
选择事件函数
点击确定
创建完成之后编辑代码
编辑完成之后保存代码（部署）
执行代码
完成之后点击目标输出结果
二、一个 Wed 服务版的 Hello World
阿里云创建函数
httpworld
进行简单的代码修改
部署
然后控制台测试
选择地址，复制
通过 post man 进行测试
测试完成之后再进一步修改代码
进行部署
部署完成之后
在 post man 进行测试
出现了新的结果
三、查询 IP 地址的服务
打印参数 environ
部署
然后执行
第一个参数包含了路径、http 参数信息等一系列的内容
对代码进行升级或完善
返回
取得刚刚所圈的 IP 地址
保存
通过控制台测试
/post nan 测试/网页查找
四、一个传统博客部署到 Serverless 架构
首先在本地进行 local 博客的开发，开发完成之后，同步数据库
同步完成数据库之后，进行一些静态文件的处理
创建一个管理员的账号
创建完成之后输入账号邮箱以及其他信息
完成之后本地启动服务
发现这个基于 Python 专攻框架的博客已经正式运行了
此时可以尝试登录到后台进行一些文章的发布，进一步看看整体的效果
登录账号之后，选择新建一些内容（新建一些分类或者是新建一些标签）
完成之后创建第1个博客
输入测试内容
完成之后返回主站观察是否是否正常
接下来将项目部署到函数计算上
首先，由于函数计算它是让事件触发的，所以在 wsga 这里做一些小小的文章，要找到对应的 IP ，来创建一个文件，也就是引带字的文件，然后 APP 放到这里
打开阿里云的控制台，找到函数计算这个服务
进行服务的创建以及函数的创建
创建完成之后，进行简单的测试运行一下是否正常
为 HTTP 函数绑定一个自定义域名，以便之后测试使用
绑定的时候，选择与服务名称、函数名称、对应的版本，点击确定
此时可以在浏览器测试域名，可以看到已经正常输出了预期结果
完成之后还需要将刚刚的业务代码包进行上传
同步代码，完成之后需要进行一个依赖的安装
在整个左侧的文件数，已经逐渐看到安装后的内容
安装完成之后，保存代码
保存成功之后，注意函数的详情，在函数详情里面修改一下函数的入口，而后面的入口方法 -application ，此时保存一下，保存完之后打开刚刚绑定的域名，会发现整个网站已经可以正常使用了
到后台来发布一些文章，看看它是否流畅
填写文章的测试名称
再写一下简单的内容
可以选择一下分类与标签，然后确定保存，此时再回到主站，会发现整个文章已经被创建好了
五、Serverless 架构的开发流程
伯克利认为，select 架构的出现，类似于40多年前从汇编语言转向高级语言的过程，在未来，SOS 架构的使用会进一步的飙升，或许服务器是个云计算不会消失，但是服务器式的云计算将是为了促进 bus 以为更好的为 SOS 架构提供支持。
是在逐渐取代 soho 计算的过程中，流程在逐渐的清晰基于 select 架构进行应用，开发将会形成一套新的应用开发流程，这种应用开发流程，将会比传统架构更为简单，由于 sos 架构传递的是 Serverless 的新制即并不需要开发者付出更多的精力关心服务器等顶层资源。
所以在一定程度上，sos 架构下的应用开发流程相对于来说会更简洁，在 servlet 架构下进行应用开发，通常用户只需要按照规范编写代码构建产物，然后部署到线上即可 ccf ，认为函数的生命周期从编写代码并且提供规范源数据开始，一个 build 的实体将获取代码和规范，然后编译并将其转换为工件，接下来将工件部署在具有控制器实体的集群上，该控制器实体负责机构。
在路上扩展函数实例的数量由于 sos 的架构传递的是 note4o 的性质，函数创建和更新的完整流程基本上是如这张图所示在创建函数时提供起源数据作为函数创建的一部分，将对其进行编译，使其具有可发布的特性，接下来可以启动禁用函数，用户可以发布一个函数，这叫创建一个新的版本，最新的版本的副本发布的版本，可能会被标记或用别名，用户可能希望直接执行或者是调用函数以进行调试和开发的过程，用户可以指定调用参数，比如说所需的版本同步或者是异步操作详细的日志级别的用户，也可能想要获得用户的统计信息，比如说调用次数，平均的运行时间，平均的延时失败重试的用户，可能还想要检索日志数。通过严重性级别可以通过严重性级别时间范围内容来进行过滤，落个数据是每个函数级别的，它包括了诸如函数的创建和删除警告，或者是调试消息之类的事件。
结论：在一定程度上，Serverless 架构下的应用开发流程相对于来说更简洁。通常情况下，一些 web 应用开发都是传统的三层 CS 架构，例如说一个常见的电子商务应用假设，它的服务端用了 Java 客户端，使用 htmlJavaScript ，在这个架构下，服务端仅为云服务器，其承载了大量的业务功能和业务逻辑，比如说我们常见的大部分逻辑，就包括身份验证，页面导航搜索交易，都是在服务端来完成的。
实际上已经逐渐的演变成为了一个单页，还有一些任务，需要保留在服务器上，比如繁重的计算任务，或者需要访问大量数据的操作，这里以搜索为例，搜索功能，可以从持续运行的服务器中拆解出来以 fast 的方式进行实现，从 API 网关接收到请求，然后做出一个响应，这个服务端函数，可以和客户端一样，从同一个客户端。图中的读取产品数据，原先的搜索代码越作修改就可以实现这个搜索函数，也就是部周四这一部分还可以把购买的功能改写成一个函数，出于安全考虑呢，他需要放在服务器端，而非客户端实现它，同样经由 APP 在传统到原主中间。
在传统的云主机架构下呢进行应用的开发和上线，可以认为是如上面这张图所示，当开发者开发完成代码之后呢，需要进行上线前的准备，包括不限于资源的评估，服务器的购买，操作系统的安装，服务器软件的安装等等完成之后呢要进行代码的部署。
处操作部署完成之后呢，还要有专业的人或者团队对服务器等资源进行持续性的监控和运维等，例如流量突然提升，需要进行服务器的平滑扩容，流量突然走低，需要对服务器进行平滑的缩容等。
架构开发者实际上关心的也就是函数中的业务逻辑，至于身份认证的逻辑呀，至于 API 网关的逻辑以及数据库的一些产品或者是服务全都交给云厂商来提供，在整个项目过程中呢，上线以及维护的过程中呢，用户并不需要关注服务器层面的维护，也无需为流量的波峰与波谷进行运维资源的投入，这一切的安全性弹性能力以及运维工作都可以交给云厂商来进行统一的处理和调度用户所需要关注的就是自己的业务代码是否符合自己的业务需求，同时呢，Serverless 架构下用户也无需为资源闲置进行额外的支出，Serverless 架构呢提供到按量付费的模型以及弹性伸缩的能力，服务端低运维和免运维等等，可以让 Serverless 的用户呢资源成本更低，人力成本更低，整体的研发效能得到进一步的提升，让项目的整体性能的安全。
研发项目得到进一步的提升，让项目的整体性能，安全性，稳定性都有一个极大的保障，综上所述，与传统架构或者传统应用开发流程的区别，有明显不同的是，Serverless 架构所主张的是，让开发者将更多的精力关注到自身的业务逻辑之上，并强调 Serverless 的性质可以在一定程度上让应用的开发部署流程，进一步的缩短，将更专业的事情交给更专业的人去做有助于业务的创新效率提升，降低业务的上线迭代周期等。
