阿里云云原生架构专家王彬：云原生 Serverless 微服务落地实践

云布道师

近日，阿里云用户组（AUG）第 12 期活动在厦门举办。活动现场，阿里云云原生架构专家王彬，向参会企业代表分享了云原生 Serverless 微服务落地实践。本文根据演讲内容整理而成。

大家好，我是阿里云消息和 serverless 解决方案架构师王彬，下面我会聚焦来讲我们其中一款 Serverless 产品：Serverless 微服务应用引擎的落地实践。内容分三个部分，产品介绍，最佳实践，以及客户案例。

产品简介

 企业应用架构的演进

首先我们看一下一般企业上云的演进架构。

第一阶段，在企业规模比较小的情况下，一般是单体服务。单体服务在规模比较小的时候是可以快速演进的。

第二阶段，随着企业业务的复杂度上升，程序会增加各种各样的组件，这时候一般会选用微服务框架，比如 spring cloud，dubbo。

第三阶段，上云，在容器化之前，企业很多应用都在 IDC 机房。现在很多云厂商都提供了各种 IAAS，PAAS 层组件。企业可以选用云上的组件，这样可以大大减少基础资源的维护。

 企业应用上云之路

下面我们看下企业上云的一般路径。

第一个路径是 Rehost，Rehost 就是自建转云上托管，原本企业的程序部署在 IDC 机房，现在直接通过云上的虚拟机替代，这种方案整体对用户的迁移成本是非常低的。

第二阶段是 Re-platform，Re-platform 的意思就是在企业的应用里面有很多的组件，这些组件很多跟客户的业务相关性不强，比如一些基础组件，数据库 Mysql、消息队列 Kafka，这些组件本身的后端技术是相当复杂的，一般企业不会，也不必要分很多精力去研究维护这些组件。这类基础组件可以快速的用云上的一些产品去替代。比如，Mysql 可以用云上的 RDS，Kafka 可以用消息队列 Kafka，这样对整体的代码的修改非常少，只需要去修改接入点，可以用很小的修改成本获得很大的收益。

第三阶段是采用新架构，把原先的系统使用云相关技术架构重组。云上有一些 Serverless 架构，需要通过 Serverless 技术把企业原本的一些应用拆分成更小的粒度或者说更小的模块，这种方式投入的成本是很大的，当然获得的收益也是最大的。

 选型困难？

现在云厂商提供了很多的产品，那企业上云的时候需要怎样去选型呢？企业从自身业务需求出发，对系统会有各种各样的需求，但总结起来无非就是：系统的稳定性、容灾能力、自动弹缩能力，服务架构的支持，发布回滚，轻运维等。针对这些需求，企业应该选用哪些产品呢？

从阿里云看，阿里云提供了很多可选的产品。比如说云主机 ECS 、容器调度服务 ACK 、应用托管服务 Serverless 应用引擎 SAE，从功能的实现上，这些产品都能够满足企业的需求，区别无非是有些云产品提供的原生能力多一些，有些产品针对企业的功能需求需要自己做一些开发。

比如说 ECS，它是一个虚拟云主机，业务相关的需求都需要企业自己去定制。ACK 主要是容器资源的调度能力，像一些负载均衡、弹性这个 ACK 都是一些业务层的，比如说微服务的治理能力，原生可能就没有，需要通过外部插件或者企业定制开发。Serverless 应用引擎 SAE，底层实现上跟 ACK 有些类似，都是基于 K8S 技术，除了基础的资源调度，SAE 还增加了一些应用层面的能力，比如微服务治理，多样的扩缩策略，强大的监控能力等。对于微服务应用，业务有明显的波峰波谷，想减轻运维压力的场景是不错的选择。

 Serverless 应用引擎 SAE

下面这张图展示了 Serverless 应用引擎 SAE 的周边组件集成，SAE 不是一个单一的产品，SAE 集成了云上很多的其他产品。比如服务发现，SAE 集成了 MSE；限流降级集成了 AHAS；监控告警集成了 Arms；日志管理集成了 SLS；SAE 本身是无服务器架构的底座，这些组合起来，将 SAE 打造成云上微服务领域最佳 Serverless 实践。

 Serverless 应用引擎[容器化/应用上云]最简平台

下面看下 SAE 整体的架构图，这张图我们可以从上往下看，企业应用可能有各种各样的语言和框架，比如 Java 应用可以通过 war，jar 部署；php 应用可以通过 zip 部署；其他多语言的应用，可以通过通用的 docker 镜像部署。

接着是 SAE 的整体架构，这张图我们可以从下往上看，SAE 底座是基于 K8S，在 K8S 的基础上提供了一些额外能力，像应用管理、全套的微服务治理、运维配套的一些能力。企业用户把应用上到 SAE 之后，可以直接通过 SAE 的白屏化界面操作。

最佳实践

 集成部署最佳实践

接下来我们看一下 SAE 提供的一些具体功能。

首先是集成部署的最佳的实践：

• 对接 Jenkins：SAE 对接 Jenkins，Jenkins 在业界的使用是比较广泛的，SAE 提供了 Jenkins 插件，企业用户在本地开发完应用之后，可以直接部署到 SAE。
• 快速部署运维：第二个是部署 SAE 的整个过程，传统云主机/K8S 的方式，需要经过几个步骤，首先需要先购买 ECS 或者创建 K8S 集群，然后企业用户按照规范部署应用，并且安装相关插件，最后程序运行时还会不少运维工作；在 SAE 上，整个操作就简单很多。SAE 免开通，只需要按照规范部署应用，程序运行之后直接通过 SAE 白屏化的操作界面直接运维，整个过程都非常简单高效。
• Java冷启动：Java 冷启动利用了 Dragonwell 的能力，对于 Java 类的应用，在启动上有不错的加速效果。
• 一键启停：对很多业务还是非常需要的，比如企业很多应用，可以分为开发环境、运行环境、测试环境。测试环境只需要在上班时间使用，在夜间，可以完全回收测试环境资源，SAE 完全是按照资源收费的，所以资源回收之后，测试环境在夜间也不会产生任务的资源费用。

 稳定性和复杂网络最佳实践

接着是稳定性和复杂网络的最佳实践：

• 多可用区部署：稳定性方面 SAE 采用了多可用区部署，加强了机房环境的容错性。
• 白屏化的发布：直接在 SAE 的控制台上就可以完成应用的分批发布，比如说企业应用有十个实例，可以分批次发布，比如说先发布三个实例，然后再发布三个，最后发布剩下的四个实例，这样就可以保证应用在发布期间也可以正常对外提供服务。
• 复杂网络支持：再下面是 SAE 对网络的支持，像南北流量、东西流量，SAE 都是支持的，SAE 主要通过集成 SLB，NAT 网关，EIP 弹性公网等完成了各种应用的网络需求。

 微服务最佳实践

第三个是微服务最佳实践，很多国内应用会使用 SpringBoot，SpringCloud 或者 Double 这些微服务框架。SAE 对于这一类的应用都做了很好的支持：

• 弹性伸缩：SAE 除了提供一些基础的基于 CPU、Mem 这些硬件的策略，做了进一步的增强，如基于 QPS、RT、定时的一些策略，利用这些策略，可以构建业务精准弹性。
• 健康检查：企业用户可以直接在 SAE 控制台设置健康检查的策略。当应用有异常时，SAE 可以自动监测并重启。
• 微服务无损上下线：前瞻性的开发了 Agent 组件，通过 Agent 组件在微服务应用上下线时，可以达到无损的效果。
• Java 微服务全链路灰度：当一个新版本上线的时候，可以引入一些特定的灰度规则，比如说 UID，企业用户可以设置某些规则的 UID 先验证功能，然后再把这个功能开放给所有的用户。

 运维审计最佳实践

最后一个是运维审计的最佳实践，对很多公司来说，安全和审计是非常重要的，SAE 在这方面也做了很好的实践：

• Web shell 登陆运行环境：虽然 SAE 是一个全托管的服务，但 SAE 是提供了入口，供企业用户登陆实际的运行环境，用于企业用户查看实际的运行环境，比如运行机器指标，环境变量等。
• 日志监控：日志监控分为两部分，一部分是实时的操作日志，在控制台上可以直接查看，另一部分是历史的操作日志，可以在设置应用时选择转储到 sls 或者 kafka。
• 权限助手和企业分账：权限助手、发布审批和企业分账主要是一些更加精细化的权限和审计管理。

 SAE 上的一些最佳实践

下面介绍的是一些 SAE 上的一些最佳实践。现在如果企业用户要把应用迁上来，操作其实非常容易，下图展示了迁移的过程。

可以看到整体的过程其实非常简单，直接将原来部署在 ECS 上的微服务/Web 服务使用 SAE 部署，其他组件部署方式不变。相比原部署，新的部署方式主要可以获得三方面的增益：

• 一是免运维的能力，降低运维压力。
• 二是自动弹缩的能力，从容应对突增流量。
• 三是微服务治理方面的能力，轻松构建强大的微服务管控系统。

客户案例

 案例一：谱尼测试与阿里云 SAE 联手抗疫

最后看下 SAE 的两个应用案例。

第一个案例是谱尼测试，谱尼测试在全国有很多的核酸检测点，目前业务十分稳定。但其实一开始，谱尼测试的系统并没有这么稳定，主要遇到三个问题：

1. 之前全国刚开始做核酸检验，并没有常态化，常常有些突发的情况需要加强监测，为应对业务洪峰，需要提前预估容量，运维成本非常高。
2. 业务的洪峰应对能力是不足的，为应对突发的流量高峰，只能去手工扩机器，时效性比较低，并且系统比较复杂。
3. 版本的迭代风险比较大，谱尼测试核酸检测是持续的，目前系统需要快速迭代，但内部没有一套开发迭代系统，应用变更风险高。

于是谱尼测试找到了阿里云，跟阿里云探讨合适的解决方案。经过评估，最终选择了 SAE，并且在很快的时间内把谱尼测试的核心系统都迁到 SAE 上。上线之后，SAE 上基本就没有出现之前的故障，主要收益如下：

• 在 SAE 上快速的构建核心系统。
• 从容的应对流量洪峰。
• 实时的感知机器的健康状态，并且在机器异常时，SAE 可以自动重启。
• 极大的提高了运维效率和运维成本。

 案例二：互动娱乐-爱奇艺体育（直播平台）

最后一个案例是国内知名的视频网站爱奇艺体育，爱奇艺体育有很多的体育联赛，像西甲和欧洲杯，这类节目有明显的波峰波谷。主要遇到的问题如下：

• 资源利用率低：在晚上的时候，有某场著名的球星比赛，就会出现流量高峰；没有热门球队或球星的比赛，流量就会很低；在流量高峰到来时，很难预测流量峰值会达到多少。爱奇艺体育之前的策略是多备机器，这种方式可以很好的应对峰值流量，但同时也导致资源利用率很低。
• 扩容繁琐：在实际场景中，会因为预估不准导致机器资源不足，这种只能运维同学快速扩容机器，工作量大。
• 缺少应用级监控：比如调用链路出现延迟的情况，很难排查具体哪一步出现了问题，定位链路场，每个环节定位繁琐。

后来爱奇艺体育找到了阿里云，并将核心系统快速的部署到了 SAE，之前的痛点也得到了解决：

• 弹性：SAE 有丰富的弹性策略，通过配置 SAE 的弹性策略，可以从容的应对突增流量。
• 内置监控：SAE 是内置的监控的，特别是对 Java 微服务框架的支持。所以当有类似 mysql 慢查询的时候，SAE 直接可以看到是哪一个环节出现了问题，方便企业用户有针对性的优化。
• 节省资源：不再需要提前准备资源。SAE 可以在 15 秒左右扩展出一个新的实例。对大多数企业用户，弹性的时间已经可以很好的满足业务需求。

/ 相关推荐 /

↓↓↓

你可能还想看

关注我们

欢迎关注加星标✨ 每日推送不错过