Serverless Developer Meetup 深圳站|学习笔记（四）-阿里云开发者社区

开发者学堂课程【Serverless Develpoer Meetup 课程：Serverless Developer Meetup 深圳站】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/943/detail/14746

Serverless Developer Meetup 深圳站

GiteeGo x Serverless Devs 让持续集成更简单

前言：

gitee 一直在做国内开源的活动，与 Serverless Devs 合作，做了分类，如果有合适的 Serverless Devs 的组件或项目，可以放在 gitee，用开源的方式完细。

gitee 代码托管·研发协作管理平台

目录/TOC

一.我眼中的 Serverless

二.现有 Serverless 的困惑/困境与机会

三.如何在 Gitee 上使用 Serverless-Devs

四. Serverless-Devs+Gitee 案例展示

一. 我眼中的 Serverless

Serverless 与 Serverless-Devs 是完全的两个东西，Serverless 与之前的开发有哪些区别，给我们的生活带来了哪些颠覆，开发更关注代码，运维关注运维的工作，这些与我们有什么关系。

Serverless 从复杂多变的云上环境出发，目标回归纯粹的业务开发。

这为开发者提供了全新的 DevOps 体验，让业务更专注业务让架构更加直观易懂。

不管是业务入门还是学习架构，Serverless 是不可多得的选择。

Serverless 更多的是运维上的东西，产品经理经常提出无厘头需求，不太关注怎么做的但就要。从开发的角度理解产品经理是比较困难的，开发更多的是将复杂的业务逻辑简单化。产品经理不理解开发，是不理解复杂度。

两者的关系从 Serverless 云厂商理解为开发，用户不太关心网络怎么样、服务器是怎样的甚至具体到机房，机房的交换机一般有四个网口，内网的一条线、外网的一条线、备用线。在日常开发和运维工作里运维机房的级别。

随着实践越来越复杂，最终看到的 Serverless 是怎样的。创建一个工程引用一个包，一个 SDK，无后端开发，直接用 CURD 做。完全不需要后端，前端顶 SDK 后对后端的 DB 做 CURD，都是 Serverless 上层应用的体现。是非常新颖的方式，让业务不用 care 太多。但在从业者来说如果只懂基础的结构是比较危险的事情。行业会慢慢两极化，不会永远不会，能懂的人更懂，中间层会断掉。

Serverless 提供了一个场景，不断的深入底层架构级别，运维机房的级别，但如果是 IVE 或 VE 的角色，去接触 Serverless 可以打破右层向下的壁垒的门槛。可以关注领域的技术，包括中间用了什么，在网络层、应用层怎样去解决的一些具体问题。

把过去几年的东西重新包一下，包的比以前更彻底，以前可能有虚拟机、Docker ，现在 Docker 的编排已经看不到了，甚至不理解在本地，远端跑了一个 Docker。各个云厂商将自己的能力，APi 以及实践向外放，过程是学习不可多得的机会。

结论

.抛弃传统架构的运维负担，让 Ops 更简单。

.高度灵活拓展，低成本，见效快

.按量付费

.....

二.现有 Serverless 的困惑/困境与机会

研发:对应用本身精细化程度要求高

架构解决运维复杂度问题，但没有解决业务研发的复杂度问题。

数据:数据持久化的处理

从传统架构转变到 Serverless 架构，需要对数据持久化有一个新的认识与处理方式的转换。

测试:服务集成测试复杂度提升迁移:业务迁移代价

平台:需要更多的 SAAS 厂商支持，否则容易出现平台锁定。

此行业处于稳定的爬坡期，为什么会处于爬坡期。因为技术多数是承接业务或现实的需求所增长出来的，现有的计算能力在不断的向前翻的情况下，业务的膨胀并不是能跟上的节奏。过于新的技术是否有诉求，一定要现在 ready 或者怎么去论证是很困难的事情。

人工智能 AI 能够自动编排、自动调动，事实上做到这层，对现有业务的助力，大部分用户，用服务的平台或开发者对于调度感觉比较小。

今天上了一个平台创建一个服务，比平时少了几秒钟的延迟。但为了延迟很多云厂商投入很多人力和资源去解决这个问题，保证它的高可用和高可靠。

眼下遇到的第一个问题膨胀出来认证价值的问题。第二个问题对现有技术的挑战，从教育的角度。Serverless 很多人听过产生各种各样的歧义，大部分开发者开始学的简单的 HTML 快速的入门，直至从业两三年，不会太多接触架构级别，行业、技术很卷，破解局面的方法，读书，读书破万卷。

面对新东西，像是一只未知但很凶猛的野兽。建议可以大胆的去接触了解。

Serverless 只解决了运维的复杂度问题，运维不用管多少台机器，只要按量去花钱、需要的时候调动，但应用并不是这样。

一个后台包了 20 几个模块，将它解耦能够让它用函数调用的方式去做，而不是业务上的强耦合，很多的服务是不够的。对于 nfc 的转型，不是全部去拆而是先把能够做的小的部分，或者能快速拆出来的部分，是所谓的降本增效过程中解决的最关键的部分。其它部分做了都是在拖慢后退，提高成本。

数据的持久化，一旦无状态后数据的持久化是头疼的问题。但从云厂商角度看，提供了很多数据库对象存储服务，数据库是好解决的问题，数据除非高可用做的非常彻底。不然会有各种各样的延迟，但目前使用云数据库的成本比较高。对一家企业所有的服务都转为云部分，云数据库徒增的成本比将现有的服务切成 Devs 所降下来的成本高。

如果想要尝试开发或项目落地时可以从这个角度琢磨，分析合不合适。

对于测试好的是面向一个函数，测试用力比较好写。但业务上最复杂的是为了去满足功能或最后一个接口，连着调一堆接口，整体的服务集成测试复杂度提高。如果本身的项目即便拆解的非常好，但在集成测试做的不好，要求非常高。

业务的迁移代价是比较现实的问题。

拨开迷雾，现有 Serverless 的机会

研发:对应用本身精细化程度要求高

架构解决运维复杂度问题，但没有解决业务研发的复杂度问题。业务的稳定取决于研发水平的完整度，技术债迟早要还。数据:数据持久化的处理

业务云化，依托云厂商的数据存储服务可以很大程度解决数据持久化维护的问题。

测试:服务集成测试复杂度提升

大量 CI/CD 工具的能力是可以与 Serverless 共存的

迁移:业务迁移代价

业务架构演进往往是一个缓慢的过程，Serverless 对传统架构不会产生太大的侵入与破坏

平台:需要更多的 SAAS 厂商支持，否则容易出现平台锁定。

越来越多的厂商重视并发力 Serverless Serverless-Devs 跨云厂商能力的支持

Serverless 解决了运维测的问题，研发测不是它的问题。如果产品本身的技术化程度不高，随着技术的淘汰迟早遇到性能瓶颈。如果不跟着学新技术自然卷是很自然的事情。

数据持久化在业务云化时基于云端的数据存储服务是必要的，不管是在高可用还是服务时间的角度说已经是现状。

测试是最简单的。平台锁定已经不是问题，依赖于上层设计与解决方案，越早认识问题能做的准备越多。

三、如何在 Gitee 上使用 Serverless-Devs

1.如何用 Gitee 的 CICD 产品做持续集成

什么是 GiteeGo

Gitee Go 是 Gitee 全新推出的一款 CICD 工具，可提供持续集成、持续交付(部署)能力，帮助企业不断提升应用交付的质量和效率。通过构建自动化、测试自动化、部署自动化，完成从代码提交到应用交付的自动化。通过交付流程度量，发现效率问题，并推荐优化方案。

下图是描述持续集成

如果想在代码提交贡献，与在公司一样，有多个人在写代码时，总有一个写的最菜。之前的方式组织代码评审会，随着工具的使用发现自动化的工具不单单可以解决在生产上的问题，测试场景是更多公司关注喜欢用的。

交付到部署的过程中，一般会遇到过程和内容。在集成过程做一些编译构建，是最简单的。作为开发自己给自己做单元测试，服务起来后做基本的接口响应。比如全部为 200 反应的参数入参是否符合预期。这些过程可以通过高程度的集成解决问题。

通过结构化的方式对应了接口文档，接口文档把功能实现，接口文档可以衍生出接口自动化测试的内容。包括现有测试框架，并不是维护一遍后面都要重来。

交付过程中更多的是做部署、部署发布动作。最简单的每一开发每一功能有自己流水线，除了本地可以推到 test 环境，自己将环境验证。如果业务越庞大越需要，因为本地只有一台电脑，应用是分布式的，应用只是配了其中一个模块，这时测试不全面。

高级的做灰度、蓝绿的流量控制以及运维层面上做的事，大部分情况下，很多中小企业只讲到运维监控，甚至运维监控都没有。一般验证系统好不好，打开看快不快，能不能打开。

2.基于单机版本的 Serverless 环境的开发部署模式

非常简单的动作不需要测试环境，在本地开发调试时中间不会有太多内容，直接部署到云上环境。

最典型的例子，博客写到代码仓库里，开通后给一个域名，只管写，写完代码后提交，页面自动部署。阿里最早 13-15 年一个产品 ace，底下是 svn 做的。只要推了 svn 自动拉代码，对应给一个万有域名，每一次拿它做测试环境，每次推代码大概 1-4 秒中间会重启。拉完代码重启。

Serverless-Devs 目前提供的工具功能大概是一个人。如果团队里面有三四个小伙伴，会出现刚推出来的东西不是自己的，因为隔壁在自己推完以后又推了一把，面对这种情况会出现问题。

好处对个人来说管理非常灵活，对应用来说没有测试。如果是多个人协作，可能面临单点的问题。Serverless 除了用函数调用的方式，现在的 Serverless 是换汤不换药的说法，用的是 Serverless 但所谓的调用链、工具是给自己用的，自己就是这样的产品，但是最后跑了 K8、Docker，把应用放进去。本质上对开发同学在相当长时间发现该写什么写什么，很多东西与变化没有太大关系。但需要了解在环境开发不一样的地方。这样结构下将 csd 加进来，在 gitee 上如果做协作开发，如何保证同学在推代码时需要整合，如果有四个人去推代码，最终有一个单点发布，单点发布与传统相同，三个同学写了代码集合，一样要去评审处理。

优点:灵活便捷，调试开发后即可部署，个人开发展者友好小型应用友好。

不足:缺少有效的集成测试多人协作仍然需要单点(个人或特定发布环境)发布。代码协作缺少评审，开发质量难以保障

本地自己调试，Serverless-Devs 提供了本地 debug 的能力，自己调完后像本地自测，自测完成后推到远程的代码仓库。

gitee 目前提供的与 action 差不多的产品能力，可以通过自己编排流程的流水线，触发对应的几个能力。第一个做基本构建，单元测试目前依赖的是开源项目本身自己做的单元测试。单元测试很难在 CICD 上产品化，如果用 Go，用 Gitee 这类框架，自己做集成，最后可以将结果、报告与平台去买云主机，如果手头开发很多，需要的测试环境或并行测的内容很多，用 Serverless-Devs 成本可控，可以起 n 个通过一两个域名把业务此域名绑上，可以形成几条固定的流水线。比如 UAT、TEST 一些基本的预测环境。

CI 先过，很多公司纠结要不要投入很多资源在 CI 上去建设。没有经过自动化门进去做，与做自动化的效率低 10%-20%

自动的测试通过后分叉到 QA。很多公司自动化的提成率没有超过 30%，最稳妥的测试是人肉 10%-20%。因为开发的代码经常有问题，各种各样的小问题，自己提交上并不是完整的时候会影响后面所有人的工作。在基本的 CI 过完后进入到 Code Review,Code Review 一开始推完代码也可以做。如果有很低的错误这时组织 Review 的价值不大，还要回头再组织。完成两个之后进入 QA 、Code Review 最后集成到生产。通过服务对外发布，有 Serverless-Devs 部署，不可能只用一个架构，可能有各种额外的。例如前端资源需要额外的 cdn 的分发，目前这一部分 Serverless-Devs 覆盖，可能有自己的冒烟。没有 Serverless-Devs 就是日常的开发内容，Serverless 解决运维端的问题，提供了监控，不需要发布，本身自己有此能力。上生产 DEBUG 的动作，提供了工具相比之下更安全。基于基础后更多的是循环，不断改进、调整代码、调整业务,团队去落实持续集成做参考。

资料文档:

.持续集成:依托于 CI 工具的构建编译与测试

.部署发布:依托于 Serverless-Devs+GiteeGo 的部署与交付，满足业务在传统架构与 Serverless 架构业务并存的发布与交付上的诉求

.相关文档:

Serverless-Devs 文档:https://www.serverless-

devs.com/zh-cn/docs/overview/intro.html

GiteeGo 帮助中心:https://gitee.com/help/categories/69

2. Serverless 与 GiteeGo 集成一本地开发调试

很多同学配置样文件比较头疼，目前 SET Steps 出了 desktop 工具，上边是本地开发，可以在 desktop 工具里去配置应用包括秘钥。可以不生产，但不建议。自测时需要自动化工具帮助解决问题。

3. Serverless 与 GiteeGo 集成一流水线编排

配置文件，流水线的配置存在仓库里，前面是集成测试，UAT，还处于测试环境的部分。大的企业基础设施强的可以自已做流量控制，通过流量投放去发布。UAT 测试完成后进入预发布阶段，预发布有审批功能、制品的存档。

Serverless 提供了回滚的机制，目前状态大多数应用不好控制。回滚是很困难的事情，比如在生产上换了架包，假设是手动发布或自动发布，一开始脚本这样写，为了平滑去做，架包起一个端口，前端去该配置，改完配置切到端口上平滑重返，把现有的服务干掉。上完线后发现架包是有问题的，发现架包被删,上一个版本被删，这时返回快速恢复。

二. Serverless 与 GiteeGo 集成一效果一览

现有集成的效果,有些测试环境也有 gitee 的环境，以及具体运行出来大概的效果。

Serverless Kubernetes 的落地实践

一.为什么要做 Serverless Kubernetes

二.如何实现 Serverless Kubernetes

三.Serverless Kubernetes 落地实践

一.为什么要做 Serverless Kubernetes

1.K8s 已经是原生业界的实施标准

Kubernetes 是一个开源的容器编排。

通过 K8s 降低运维成本，提高运维效率，提供了标准化的 AKI。已经形成了以 K8s 为核心的生态，K8s 已经是原生业界的实施标准

2.面向标准 K8s API 进行 Serverless 编程

Serverless 与 Kubernetes

Serverless 理念:

Serverless 我们可以理解为云原生技术发展的高级阶段，用户更聚焦在业务逻辑，而减少对基础设施的关注。

Serverless 运维主要包括两部分，一为应用的运维，二为底层资源的运维。

怎样在原生基础标准上做 Serverless

思考:

在 K8s 上是否也能做到更专注于应用业务逻辑?

Kubernetes 做 Serverless 有哪些优势

二. 如何实现 Serverless Kubernetes

1.LaaS 节点免运维

减少对基础设施的关注：LaaS 免运维

三个阶段首先对于原生使用 K8s 关注节点，减少关注节点做托管节点池，相当于用户节点通过托管节点池的方式管理起来，让用户减少对节点的关注。托管节点池需要维护节点池策略。通过虚拟节点和 ECI，ECI 是阿里云底层弹性容器池里，通过这种方式真正做到节点免运维。

2.Serverless Kubernetes

ASK（Serverless Kubernetes）

.基于容器

敏捷部署

安全隔离

生态连接

高移植性

.无服务器管理

无需节点容量规划

无需 OS 和系统软件维护

无需升级服务器零基础设施运维

.弹性扩容

“无限”容量

秒级扩容

基于容器扩容

.按需付费

没有闲置资源

更高资源利用率

总体更低计算成本

3.聚焦业务逻辑：以应用为核心

聚焦业务逻辑以应用为核心，应用的元素离不开应用部署、灰度发布、自动弹性、多版本管理、可观测性、流量管理。

多版本管理，如果每一次发布一个版本可以管理起来，回滚非常方便。一种开箱即用的方案去解，答案是 Knative

Knative 是什么

Knative 是基于 Kubernetes 之上提供的一款开源 Serverless 应用框架，帮助用户部署和管理现代化的 Serverless 工作负载，打造企业级 Serverless 平台。

Knative 具备如下优势:

.在几秒钟内建立可扩展、安全、无状态的服务。

.具有更高级别 Kubernetes 应用抽象的 API

.可插拔组件，让您可以使用自己的日志记录和监控、网络和服务网格。

.在 Kubernetes 运行的任何地方都可以运行 Knative，无需担心供应商锁定。

.开发者无缝体验，支持 GitOpsDockerOpsManualOps 等。

.支持常用工具和框架，例如 Django、Ruby on RailsSpring 等。

4.Serverless Framework:Knative

简单应用模型自动弹性缩容到 0 事件驱动流量灰度发布

用于工作部署负载 Serving,用于事件驱动的 Eventing。Serving 本身在 K8s 原生的资源,负责版本的管理，支持流量灰度发布策略此外支持缩容到 0。Eventing 提供了丰富的事件源的对接，还提供了 Broker、Trigger 的事件模型，模型是对模型订阅分类的处理。

5.为什么是 Knative

像阿里巴巴、谷歌已经提供了生产级别的 Knative 能力。看到 Knative 被越来越多开发者所接受

三.Knative 落地挑战、应对与效果

开源的项目真正落地到产品，需要接触用户的受界面，建立网关，在网关对请求进行分发，分发时做自动弹性。

阿里云 Serverless Kubernetes 落地方案

典型应用场景

Web 服务托管

·自动管理 Ingress

·自动管理 Service

·集成灰度发布能力

应用 Serverless 编排

.弹性伸缩

.接管应用流量，可按百分比拆分

.自动集成灰度发布能力

AI 服务托管

·基于任务队列的弹性伸缩

·自动集成灰度发布能力

.Pod 安全下线

.使用 ECI 节省保有成本

SaaS 服务托管

·用户提交代码自动构建

·自动集成灰度发布能力

·流量和弹性伸缩

1.落地实践:异构资源，按需使用

客户痛点

用户希望通过 Serverless 技术按需使用资源，节省资源使用成本，简化运维部署。另外有 GPU 的业务诉求。希望使用容器化的 Serverless，支持使用 GPU 资源，同时简化应用运维音署(尽可能少的操作 k8sdeployment/svc/ingress/hpa 等资源)，IaaS 资源免运维。

解决方案

使用 Knative+ASK 作为 Serverless 架构。数据采集之后，通过服务网关访问数据处理服务数据处理服务根据请求量按需自动扩缩容