做者 | 许成铭（竞霄） 来源 | 阿里巴巴云原生公众号数据库
DevOps 简析
传统软件开发过程当中，开发和运维是极其分裂的两个环节，运维人员不关心代码是怎样运做的，开发人员也不知道代码是如何运行的。后端
而对于互联网公司而言，其业务发展迅速，须要快速更新以知足用户差别化的需求或者竞对的产品策略，须要进行产品的快速迭代，经过小步快跑的方式进行敏捷开发。安全
对于这种每周发布 n 次甚至天天发布 n 次的场景，高效的协做文化就显得尤其重要。DevOps 就在这种场景下应运而生，它打破了开发人员和运维人员之间的壁垒。服务器
DevOps 是一种重视“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通合做的文化、运动或惯例。经过自动化“软件交付”和“架构变动”的流程，来使得构建、测试、发布软件可以更加地快捷、频繁和可靠。架构
上图是一个完整的软件开发生命周期，DevOps 运动的主要特色是倡导对构建软件的整个生命周期进行全面的管理。负载均衡
DevOps 工程师的职责：框架
- 管理应用的全生命周期，好比需求、设计、开发、QA、发布、运行；
- 关注全流程效率提高，挖掘瓶颈点并将其解决；
- 经过标准化、自动化、平台化的工具来解决问题。
DevOps 的关注点在于缩短开发周期，增长部署频率，更可靠地发布。经过将 DevOps 的理念引入到整个系统的开发过程当中，可以显著提高软件的开发效率，缩短软件交付的周期，更加适应当今快速发展的互联网时代。less
Serverless 简析
上图左侧是谷歌趋势，对比了 Serverless 和微服务的关键词趋势走向，可看出随着时间变化，Serverless 的热度已经逐渐超过微服务，这说明全世界的开发人员及公司对 Serverless 很是青睐。运维
那 Serverless 到底是什么？上图右侧是软件逻辑架构图，有开发工程师写的应用，也有应用部署的 Server（服务器），还有 Server 的维护操做，好比资源申请、环境搭建、负载均衡、扩缩容、监控、日志、告警、容灾、安全、权限等。而 Serverless 其实是把 Server 的维护工做屏蔽了，对于开发者是黑盒，这些工做都由平台方支持，对业务来讲只需关注核心逻辑便可。分布式
总得来讲，Serverless 架构是“无服务器”架构，是云计算时代的一种架构模式，可以让开发者在构建应用的过程当中无需关注计算资源的获取和运维，下降运营成本，缩短上线时间。
Serverless 时代 DevOps 的变化
1. Serverless 的特性
上图左侧为 2020 年中国云原生用户调查报告中 Serverless 技术在国内的采用状况，图中显示近三成用户已经把 Serverless 应用在生产环境中，16% 的用户已经将 Serverless 应用在核心业务的生产环境，12% 的用户也已经在非核心业务的生产环境中用到 Serverless，可见国内对 Serverless 接受度较高。
上图右侧为咨询公司 O'Reilly 对全球不一样地区不一样行业的公司进行的调查报告结果，图中显示身先士卒使用 Serverless 架构的就是 DevOps 人员。
那么当 Serverless 赶上 DevOps，会发生哪些变化呢？首先咱们看一下云原生架构白皮书中对 Serverless 特性的概括总结：
- 全托管的计算服务
用户只须要编写本身的代码来构建应用，无需关注同质化的复杂的基础设施的开发运维工做。
- 通用性
可以在云上构建普适的各类类型应用。
- 自动的弹性伸缩
用户无需对资源进行预先的容量规划，业务若是有明显的波峰波谷或临时容量需求，Serverless 平台都可以及时且稳定地提供对应资源。
- 按量计费
企业可使成本管理更加有效，不用为闲置资源付费。
Serverless 让运维行为对开发透明，开发人员只需关注核心业务逻辑的开发，进而精益整个产品开发流程，快速适应市场变化。而上述 Serverless 的这些特性与 DevOps 的文化理念及目标是自然契合的。
2. Serverless 开发运维体验
传统应用构建的流程中，DevOps 人员管理整个生命周期的步骤很是多：
- 在资源准备阶段，要购买 ECS 进行机器初始化等系列操做；
- 在研发部署阶段，须要把业务应用、监控系统、日志系统等旁路系统部署在 ECS 上；
- 在运维阶段，你不只须要运维本身的应用，还需运维 Iaas 及其余旁路的监控、日志、告警组件。
而若是迁到 Serverless，其开发体验是怎么样的呢？
- 在资源准备阶段，不须要任何资源准备，由于 Serverless 是按需使用、按量付费的，不用关注底层 Server；
- 在研发部署阶段，只须要将本身的业务部署到对应的 Serverless 平台上；
- 在运维阶段，完全作到了免运维。
能够看到，传统应用构建流程中的 Iaas 及监控、日志、告警，在 Serverless 上彻底没有，它以全托管、免运维的形式展示给用户。
Serverless 时代 DevOps 的最佳实践
上文介绍的体验其实就是基于阿里云的一款 Serverless 产品——SAE 来实现的。Serverless 应用引擎（SAE）是阿里云 Serverless 产品矩阵中提供的 DevOps 最佳实践。先简单介绍一下 SAE：
1. Serverless 应用引擎（SAE）
SAE 是一款面向应用 Serverless PaaS 平台，支持 Spring Cloud、Dubbo、HSF 等主流的应用开发框架。用户能够零代码改造，直接将应用部署到 SAE 上，而且按需使用、按量付费、秒级弹性，能够充分发挥 Serverless 的优点，为用户节省闲置的资源成本。
在体验上，SAE 采用全托管、免运维的方式，用户能够聚焦于核心的业务逻辑开发，而应用的整个生命周期管理，如监控、日志、告警，这些都由 SAE 完成。能够说，SAE 提供了一个成本更优、效率更高的一站式应用托管方案，用户能够作到零门槛、零改造、零容器基础就能够享受到 Serverless 带来的技术红利。
Serverless 应用引擎（SAE）三大特色：
- 0 代码改造：微服务无缝迁移，开箱即用，支持 War/Jar 自动构建镜像；
- 15s 弹性效率：应用端到端快速扩容，应对突发流量；
- 57% 降本提效：多套环境按需启停，降本且提效。
2. 构建高效闭环的 DevOps 体系
SAE 内构建了高效闭环 DevOps 体系，覆盖开发态、部署态和运维态的整个过程。
中大型企业通常都使用企业级的 CICD 工具（如 Jenkins 或云效）部署到 SAE，从而完成从源码到构建再到部署的整个流程。
对于我的开发者或者中小企业，更倾向于使用 Maven 插件或 IDEA 插件一键部署到云端，方便本地调试，也提高了整个的用户体验。
当部署到 SAE 以后，能够进行可视化的智能运维操做，好比高可用运维（服务治理、性能压测、限流降级等）、应用诊断（线程诊断、日志诊断、数据库诊断等）以及数据化运营。以上操做都是部署到 SAE 以后，用户能够开箱即用的现成的功能。
用户经过 SAE 能够很是方便地实现总体的开发运维流程，感觉 Serverless 带来的全方位体验和效率上的提高。下面介绍几个 SAE 的最佳实践：
3. 部署态最佳实践：CI/CD
SAE 目前支持三种部署方式，分别是 War、Jar 和镜像。
若是用户使用 Spring Cloud、Dubbo 或 HSF 这类应用，能够直接打包或者填写对应的 URL 地址，就能够直接部署到 SAE 上。而对于非 Java 语言的场景，能够经过镜像方式进行部署。后续咱们也会支持其余的语言包以自动化构建的方式进行部署。
除了直接部署以外，SAE 也支持本地部署、云效部署和自建部署这三种方式。
本地部署依赖 CloudToolkit 插件，对 IDEA/Eclipse 进行了支持，用户能够在 IDEA 里一键部署到 SAE 上，无需登陆，方便地进行自动化操做。
云效部署是阿里云提供的企业级一体化 CICD 平台型产品，经过云效能够监听代码库的变更，若是进行 Push 操做，就会触发云效的整个发布流程。好比进行代码检查或者单元测试，在对这个代码进行编译、打包、构建，构建好后会生成对应的构建物，以后它会调用 SAE 的 API，而后执行总体的部署操做。这一整套流程也是开箱即用的，用户只须要在云效控制台上进行可视化配置就能够把整个流程串起来。
自建部署指用户的公司若是是直接经过 Jenkins 进行构建的话，也能够直接使用 SAE。Jenkins 做为开源的最大的 CICD 平台，咱们也提供了有力支持，许多用户也经过 Jenkins 成功地部署到 SAE 上。
4. 部署态最佳实践：应用发布三板斧
应用发布三板斧包括：可灰度、可监控、可回滚。在阿里内部全部的变动都须要严格作到上述的“三板斧”，而 SAE 做为一款云产品，也是把阿里巴巴的最佳实践对外输出进行产品化的集成。
- 可灰度：支持单批、分批、金丝雀等多种发布策略；支持按流量灰度，批次间自动/手动发布，分批间隔等多种发布选项；
- 可监控：发布过程当中清晰对比不一样批次基础监控与应用监控指标异动，及时暴露问题，定位变动风险；
- 可回滚：在发布过程当中，容许人工介入控制发布流程，如异常停止、一键回滚。
上图为控制台截图，能够看到在部署上咱们支持单批、分批和灰度三种方式进行发布。
执行发布的过程都是经过发布端进行，每一个发布端都有具体的步骤，首先进行构建镜像，而后初始化环境，接着建立和更新部署配置。用户能够清晰地看到发布端当前的运行进度与状态，方便排查。
5. 运维态最佳实践：全方位可观测
SAE 提供全方位可观测，能够对分布式系统中的任何变化进行观测。当系统出现问题时，能够便捷地定位问题、排查问题、分析问题；当系统平稳运行时，也能够提早暴露风险，预测可能出现的问题。经过 SAE 用户能够对本身的应用了如指掌。
这里列举了可观测性的三个方面：Metrics、Logging 、Tracing。
- Metrics
表明聚合的数据，SAE 提供以下基础监控指标：
1）基础监控：CPU、MEM、Load、Network、Disk、IO； 2）应用监控：QPS、RT、异常数、HTTP 状态码、JVM 指标； 3）监控告警：丰富的告警源上报、告警收敛处理、多种告警渠道触达（如邮箱、短信、电话等）。
- Logging
表明离散的数据，提供如下功能：
1）实时日志：Stdout、Stderr 实时查看； 2）文件日志：自定义采集规则、持久化存储、高效查询； 3）事件：发布单变动事件、应用生命周期事件、事件通知回调机制。
- Tracing
意味着能够按请求维度进行排查，提供以下开箱即用的功能：
1）请求调用链堆栈查询； 2）应用拓扑自动发现； 3）经常使用诊断场景的指标下钻分析； 4）事务快照查询； 5）异常事务和慢事务捕捉。
6. 运维态最佳实践：在线调试
经过 SAE 在线调试能够访问单实例的目标端口，至关于用户在本地能够直接访问云端某个应用的某个具体实例，原理是为实例提供了端口映射的 SLB，经过这个能力用户能够实现以下功能：
- SSH / SFTP 访问实例
能够在本地经过 SSH 直接连到应用的具体的实例上，或者经过 SFTP 进行上传/下载文件。
- Java retmote debug
至关于在 IDEA 里配置一个断点，再远程链接到对应的 SAE 的实例上，这样就能够经过断点来查看整个方法的调用站与上下文信息，对线上正在运行的应用进行诊断。
- 其余诊断工具链接实例
其余诊断工具也能够经过在线调试的手段链接到 SAE 的实例上，进而看到 Java 的一些信息，好比堆栈或者线程等。 适用场景：针对运行时在线应用的实时观测运维及问题排查求解。
7. 开发态最佳实践：端云联调
针对微服务场景，咱们提供了一个很是好用的能力：端云联调。它基于 CloudToolkit 插件+ 跳板机，能够实现：
1）本地服务订阅并注册到云端 SAE 内置的注册中心； 2）本地服务能够和云端 SAE 服务互相调用。
适用场景：
1）微服务应用迁移到云端 SAE，迁移过程当中的开发联调； 2）本地开发测试验证。
这个功能的原理是须要在用户的 VPC 内，而后经过 ECS 代理服务器做为跳板机，ECS 能够和同一个 VPC 内的 SAE 应用进行互调，而后这台 ECS 经过反应代理的方式，能够与本地进行链接。
CloudToolkit 插件会在应用启动时就注入对应 SAE 注册中心的地址，以及微服务的一些上下文参数，使得用户本地的应用经过跳板机连到 SAE 的应用上，从而进行整个端云联调的过程。
做者简介
许成铭，花名：竞霄，前后参与 aPaaS 领域 EDAS 和 SAE 后端研发工做，经历云原生与 Serverless 技术趋势变革。
本文整理自【Serverless Live 系列直播】2 月 2 日场 直播回看连接：https://developer.aliyun.com/topic/serverless/practices
Serverless 电子书下载
本书亮点：
- 从架构演进开始，介绍 Serverless 架构及技术选型构建 Serverless 思惟；
- 了解业界流行的 Serverless 架构运行原理；
- 掌握 10 大 Serverless 真实落地案例，活学活用。