共计 5138 个字符，预计需要花费 13 分钟才能阅读完成。
这篇文章给大家介绍如何让单体 / 微服务应用成为 Serverless Application，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
一、天然云原生的 Serverless1. 云原生时代
随着 2013 年以 Docker 为代表的容器技术、CNCF 基金会以及 K8s 的发展等，云原生开始被广大开发者所熟知。云原生时代之前还有两个阶段：一是自建 IDC 机房，二是简单地把原有的应用搬迁到云上。自建 IDC 机房很难获得高可用、高可扩展以及运维提效等能力；而第二个阶段就是云计算时代，相比 IDC 有了一定的进步，但大部分还是在相对原始地用云，很难用好云，这个阶段的资源已经接近无限，但是基于虚拟机及各种自建服务的方式还有待改善。
云原生时代指的是在设计应用的时候，就考虑到将来应用会运行在云的环境里，充分利用了云资源的优点，比如云服务的弹性、分布式的优势。如上图所示，云原生可以分为几部分：
一是云原生技术，包括容器、K8s、微服务、DevOps。而这些技术只是一个工具，要想真正地用好这些技术，还需要一些最佳的实践和组合，也就是云原生架构。
云原生架构是基于云原生技术的一种架构原则和设计模式的集合，是一些指导原则，比如要求做好可观测，只有在做好可观测的前提下才能做好后续的弹性，包括高可用相关的建设及基础设施的下沉，希望对非业务代码的部分进行最大化的剥离，在这样的技术和架构设计的指导下，就可以设计出云原生应用。
云原生应用具有轻量、敏捷、高度自动化等方面的特点，可以充分发挥云的优势，在现代数字化转型的时代，更好地适应业务的发展变化。
2. Serverless 天然云原生
为什么说 Serverless 是天然云原生的呢？虽然 Serverless 出现的时间比云原生更早一些，我们向前追溯，AWS 率先推出初代 Serverless 产品——Lambda，其按请求计费和极致伸缩的特点，非常符合云原生的定义，比如基础设施下沉。在 Lambda 里，不需要管理服务器，它会根据请求去伸缩服务器，实现了高度自动化；它还以函数的形式来组织代码，函数相对于应用来说要更轻量，交付速度也更快。但是这种模式的缺点就是改造成本高，因为很多应用原来是一个巨大的单体或者微服务应用，很难改造成函数模式。
3. 认识 SAE
Serverless 理念及相关产品的推出已经走过差不多 7 个年头，在这个过程中云原生的技术也在不断成熟，包括 Docker、K8s 等。阿里云在 2018 年的时候就开始思考另一种 Serverless 形态，即 Serverless application，也就是 SAE 这款产品，其于 18 年 9 月上线，19 年商业化，至今也走过了 3 个年头。
SAE 的特点：
不可变基础设施、可观测、自动恢复
基于 K8s 底座，背后代表的是镜像之类的不可变基础设施以及可观测、自动恢复，如果检测到请求失败，会自动切流或重启实例。
免运维、极致弹性、极致成本
托管服务器资源，不需要用户自己运维服务器，同时也相应地具备极致弹性和极致成本的能力。
易上手、0 改造、一体化
如上图，最上层为客户感知层，是 aPaaS 产品形态，是一个应用 PaaS，经过三年多的实践，最终达到让用户真正易上手、0 改造的效果，而且做了很多一体化的集成。
SAE 这样一款以 K8s 为底座、具备 Serverless 的特点、以 aPaaS 为形态的产品，完全符合云原生的特点。在技术层面，底层使用容器、K8s，集成了微服务，包括各种 DevOps 工具。在架构层面，因为底层依赖于这些技术，所以可以非常方便地让用户遵照云原生架构的原则，去设计出自己的应用实践，最终让客户的应用可以最大化地享受到云原生的红利，实现应用的轻量、敏捷以及高度自动化，极大地降低迈入云原生时代的门槛。
SAE 产品架构图
SAE 是一款面向应用的 Serverless PaaS，0 改造 0 门槛 0 容器基础是它的特点，可以让用户非常方便地享受到 Serverless、K8s 以及微服务带来的技术红利。同时也支持多种微服务框架、多种部署渠道（包括自己产品的 UI 部署 / 云效 / Jenkins / 插件部署等）、多种部署方式（包括 War / Jar / 镜像部署等）。
其底层是一个 IaaS 资源层，上面是 K8s 集群，对用户来说这些都是透明的，不需要自己购置服务器，也不需要理解 K8s，再上一层有两个核心能力：一是应用托管，二是微服务治理，应用托管就是应用生命周期等，微服务治理就是服务发现、优雅下线等，这些在 SAE 里都做了较好的集成。
SAE 的核心特点可以总结为三个：一个是 0 代码改造，二是 15s 弹性效率，三是 57% 的降本提效。
二、SAE 设计理念 1. Kubernetes 底座
容器
在 K8s 容器编排生态中，最基础的是容器或镜像，依托于镜像，用户就相当于实现了不可变的基础设施，其好处是镜像可以到处分发、复制，相当于实现了可移植性，没有了厂商绑定。另外针对不太熟悉镜像或者不想感受复杂性的用户，我们也提供了 War / Jar 层面的部署，极大降低用户享受红利的门槛。
面向终态
在传统的运维领域有很多问题比较难解决，比如服务器因为各种各样的原因，突然负载高或者 CPU 高等，这时在传统领域通常需要大量的手动运维操作，而在 K8s 领域结合可观测、健康检查，只需配置好 liveness 和 readiness，就可以实现自动化的运维，K8s 会自动进行切流以及自动化地重新调度，极大地降低了运维成本。
资源托管
不仅 ECS 机是托管的，K8s 也是内部托管运维的，客户完全不需要购买服务器或者购买 K8s 或者运维 K8s，甚至都不需要懂 K8s，极大地降低了客户的入门门槛和薪资负担。
2. Serverless 特性
极致弹性
我们已经实现了端到端的 15 秒，也就是 15 秒内可以创建出一个 pod，让用户的应用开始启动。在弹性能力上，我们具有基础指标弹性（如 CPU、Memory 等）、业务指标条件弹性（如 QPS、RT 等）和定时弹性。如果手动设置弹性指标，仍有一些门槛和负担，因为客户不知道指标应该设成多少，在这个背景下，我们也在考虑智能弹性，自动帮用户算出弹性指标推荐给用户，进一步降低门槛。
精益成本
SAE 免去了资源托管和运维成本，在此之前客户需要运维大量的 ECS 服务器，当需要安全升级、漏洞修复，特别是高密部署时，成本会很高。另外 SAE 计费模式是以分钟计费，用户完全可以实现精益成本，比如在业务高峰的 1 小时扩容到 10 个实例，在高峰结束后变成 2 个实例。
语言增强
在弹性领域，我们针对性地做了一些语言增强。比如 Java，结合阿里的大规模 Java 应用实践，阿里的 JDK——Dragonwell11 相比于其它开源的 JDK，可以让 Java 应用的启动速度提高 40%。未来我们还会在其它语言上探索更多的可能性。
3. (application)PaaS 产品形态
应用托管
应用托管，相当于应用生命周期的管理，包括应用发布、重启、扩容、灰度发布等，其使用的心智和大家在使用应用或其他 PaaS 平台是一样的，上手门槛非常低。
一体化集成
因为云产品有几百多款，如果要每一款都用好也是额外成本。所以我们对最常用的云服务进行了一体化集成，包括基础监控、业务监控 ARMS、NAS 存储、SLS 的日志收集等各方面，降低用户使用产品的门槛。
另外我们还额外地做了微服务增强，包括托管注册中心、优雅上下线和微服务治理等。因为使用微服务通常需要一个注册中心，SAE 内置托管注册中心，用户不需要再重新购置，完全可以把应用直接注册上来，进一步降低用户门槛和成本。
SAE 将这些能力组合起来，最终让用户在迁移传统单体应用或者微服务应用时，基本可以实现 0 改造迁移，0 门槛地享受到这款产品背后带来的技术红利。
三、SAE 技术架构 1. SAE 技术架构图
SAE 帮用户托管 K8s 背后的技术架构如上图所示，在 1 个宿主机上，最上层是 SAE 的 PaaS 界面，第二层是 K8s 的 Master（包括 API server 等），最下面一层是 K8s 真正运行资源的宿主机，这些都是完全由 SAE 托管的，用户只需要在自己的 VPC 或网络段内创建 Pod 资源并做一个连通，即可实现应用的正常运行。
这里有两个核心问题：
一是防穿透，比如我们的 Pod 或容器使用的是像 Docker 这样的传统容器技术，把公有云的 a 和 b 两个用户跑到一个物理机上，其实有非常高的安全风险，b 用户很有可能会侵入到 a 用户的容器里获取用户信息，所以这里面的核心就是要限制用户能力，防止其逃逸。
二是网络的连通或者云体系的打通，我们要跟用户的网络体系打通，这样用户才可以方便地和他的安全组、安全的规则、RDS 等连通，这也是一个核心的问题。
2. 安全容器
在这里具体展开一下防逃逸问题。上图表格是现在大家讨论的比较广泛的安全容器技术，安全容器简单理解就是虚拟机思想。如果使用传统的像 Docker 这样的容器化技术，很难做好安全的防护或隔离，而安全容器可以理解为一个轻量级的虚拟机，既有容器的启动速度，又有虚拟机的安全。
目前安全容器已经超脱出了安全，不仅仅有安全的隔离，也有性能的隔离以及故障的隔离，以故障隔离为例，如果采用 Docker 这种容器技术，遇到一些内核问题，就有可能因为一个 Docker 容器的失败而影响到其他用户，整个宿主机都可能会受到影响，而如果采用安全容器技术就不会有这样的问题。
SAE 采用了 Kata 安全容器技术，从时间和开源界的事实来说，Kata 是 runV 和 Clear Container 两个项目的结合，相比于 Firecracker 以及 gVisor 方案更加成熟。
四、SAE 最佳实践最佳实践 1：低门槛微服务架构转型
熟悉微服务的客户都知道，如果要自己运维一套微服务技术架构，需要考虑很多因素，不仅是开源、框架层面，还有资源层面及后续的问题排查，包括注册中心、链路追踪、监控、服务治理等等，如上图左侧所示，在传统开发模式下，这些能力都需要用户自己托管和运维。
而在 SAE 中，用户就可以把一些与业务无关的特性交给 SAE，用户只需要关注自己的业务，包括微服务的用户中心、群组中心等，以及和 SAE 的 CI/CD 工具做一个集成，就可以快速实现微服务架构。
最佳实践 2：一键启停开发测试环境降本增效
有些中大型企业会有多套的测试环境，这些测试环境一般晚上都不使用，在 ECS 模式下，是需要长期保有这些应用实例的，闲置浪费的成本比较高。
而如果在 SAE 里就可以结合命名空间，比如一键启停或定时启停的能力，可以将测试环境的应用全部建在测试环境的命名空间下，再配置早上如 8:00 启动测试环境命名空间所有实例，在晚上 8:00 全部停止，停止后的时间段就完全不计费，可以让用户最大化地降低成本。
根据计算，在比较极致的情况下，基本上可以节省用户 2/3 的硬件成本，而且也不需要额外付出其他运维成本，只需配置好定时启停的规则即可。
最佳实践 3：精准容量 + 极致弹性的解决方案
在今年疫情情况下，大量学生在家进行在线教育，很多在线教育行业的客户面临业务流量暴涨七八倍的情况，如果基于原来自己运维的 ECS 架构，用户就需要在非常短的时间内做架构升级，不仅是运维架构升级，还有应用架构升级，这对用户的成本及精力都是非常大的挑战。
而如果依托于 SAE 中各种各样的一体化集成以及底层 K8s 这样高度自动化的平台，就可以简单很多。比如可以结合 PTS 压缩工具评估容量水位；比如压测有问题，可以结合基础监控和应用监控，包括调用链、诊断报告等，可以分析瓶颈在哪里，有没有可能尽短的时间内解决；如果发现是比较难解决的瓶颈，可以使用应用高可用服务，实现限流降级，确保业务不会因为突发洪峰而垮掉。
最后 SAE 可以根据压测模型配置相应的弹性策略，比如根据 CPU memory、RT 或者 QPS 等，在有容量模型的情况下设置行业策略，达到非常贴合实际使用量的效果，实现低成本及架构的最大化升级。
五、总结
数字化转型已经渗透到各行各业，不管是因为时间发展原因还是疫情原因，在数字化转型里，企业要有应用好云的能力，来应对业务上的快速变化及高洪峰高流量场景下的挑战，这一过程包含几个阶段：Rehost（新托管）、Re-platform（新平台）、Refactor（新架构），随着架构改造的深入，企业能够获得的云的价值越高，同时迁移改造成本也会随之上涨，如果只是把应用简单托管到云上，很难获得云的弹性能力，遇到问题时还是很难及时处理。
通过 SAE，我们希望能够让用户 0 改造、0 门槛、0 容器基础即可享受到 Serverless + K8s + 微服务的价值红利，最终帮助用户更好面对业务上的挑战。
关于如何让单体 / 微服务应用成为 Serverless Application 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
