云计算敏捷团队的 10 个最佳实践工具

前言

2020 年以来，随着国家在 “新基建” 领域的政策导向，推动云计算自 2017 年后再次迎来了新一轮的发展机遇。同时，由于新冠疫情黑天鹅从根本上冲击了企业的业务模式乃至经营安全，促进企业加速完成数字化转型，也对云计算的应用效能提出了新的需求。

我们观察到，随着企业数字化转型的进一步深化，云计算和云原生技术已经成为了 CIO 和 CDO 们首要考虑的业务增长因素之一。随之的，也有越来越多传统领域的企业主们开始着手组建专业的云 IT 团队。可以说，在后疫情的今天，依托于企业上云的数字化转型需求比以往任何时候都更加强烈。作为云计算敏捷研发团队中的一员，笔者也正在亲身经历着这场变革，并希望可以通过文章的形式来记录下一些心得与经验，抛砖引玉。

工欲善其事，必先利其器。本篇就先从我认为的 10 个云计算敏捷团队最佳实践工具说起。

1. Docker

在实践 Container 之前，当我们要部署或更新一个应用程序时，就要运维同事对物理服务器进行频繁的配置修改。这并不是一件容易的工作，尤其在分布式软件架构要求的大规模服务器场景中，除了工作量繁重之外，往往需要面对较高的人为失误导致的故障风险。现在，我们将这种 IT 模式归类为一种 “可变基础设施” 范式，即：在交付软件的时候，需要连带着对硬件服务器进行相应的适配变更。

相对的，Container 提出的是一种 “不可变基础设施” 范例，这意味着当我们采用 Container 的方式进行软件交付时，可以不对物理服务器进行任何更改。这得益于 Container 的本质是一种操作系统虚拟化技术（OS-level virtualization），其带来的好处包括：更高的运行环境兼容性，以及更简单且可预测的部署过程，可以有效缓解甚至完全防止可变基础架构中常见的问题，例如：配置漂移和雪花服务器。

Container 技术的诞生最早可追溯到 1979 年 Unix 引入的 chroot 技术，但直到 2013 年，dotCloud 公司（后改名 Docker）推出 Docker 技术并提出 “Build, Ship and Run” 和 “Build?once, Run?anywhere” 的口号后，才真正掀起了 IT 行业对 Container 技术的热情。

虽然，随着 Container 技术的发展，Docker 早已经不是唯一的选择。Docker 公司甚至一度将企业业务线（Docker Enterprise）打包出售给了 Mirantis。但好在 Docker 公司及时转型专注于开发者群体，在开发者业务线（Docker Developer Desktop）上稳住了阵脚，至今仍是最受到敏捷开发团队欢迎的实践工具之一。

2. Kubernetes

伴随着 Container 技术成长起来的还有 Container Orchestration 技术，目前 Kubernetes 已经是该领域的事实标准。如果我们将 Container 类比为 Linux 上的 Application，那么 Kubernetes 就是云原生时代的 Linux 操作系统。

最初，Google 开源 Kubernetes 项目的初衷就是为了提供一种方便、快速、优雅地 Containers 编排平台。通过将 Kubernetes 提供的 “容器编排能力” 和 Container 提供的 “不可变基础设施能力” 有机的结合起来，使得底层基础设施更加标准化，用户可以不必操心底层资源管理的问题，在降低了复杂度的同时还有助于提升资源的利用率。

近年来，随着 Kubernetes 技术的成熟以及 Microservice architecture 生态的完善，我们不再局限于将 Kubernetes 作为一个 Containers 的编排平台，而是进一步地将 Kubernetes 定位为一个 “Platform for Platform” 项目，即：“用来构建分布式系统的分布式系统”。在开发微服务架构应用时，将 Kubernetes 作为基础设施层底座进行打包和整体交付，以此来实现了更高层次的基础设施抽象层。

3. 腾讯云 Serverless

Serverless Computing（无服务器计算）是当前最重要的云原生技术发展方向之一，是一种从底层开始的技术变革，被业界认为是继虚拟化、容器技术之后的第 3 代通用计算平台。而 FaaS（Function as a Service，函数即服务）和 BaaS（Backend as a Service，后端即服务）则是由 Serverless 技术所衍生出来的 2 个主流云服务模式。

据 Gartner 统计，2020 年全球有 20% 的企业采用了 Serverless 技术部署。在关注到这一趋势后，我们就开始考虑如何将 Serverless 技术应用于新型业务创新以及 IT 研发管理创新之上，并在腾讯云 SCF （Serverless Cloud Function，云函数）服务中得到了验证。

在传统的研发模式中，当我们的研发人员需要扩展一个新的基于 RESTful API 的微服务组件时，往往需要全局考虑到编程语言的选择、Web 开发框架的版本、运行时环境的设置、底层资源的利用率、性能以及高可用集群横向扩展的部署配置等等一系列的因素。在以往，这是行之有效的一套方法论，但显然，也存在着开发周期长，开发小组之间的沟通协作成本高，需求变更慢的情况。

针对这些问题，我们评估并确定了可以通过 Serverless 来进行优化，并基于腾讯云 Serverless Framework 一站式开发平台和工具来完成了架构改造。Serverless 因为其提供的是 Function-let（函数式）的计算单元，所以非常适用于 Stateless（无状态）业务类型，将微服务架构中的无状态代码逻辑（e.g. 外部系统资源对接程序），通过简单的代码实现即可快速上线一个功能，无需再花费一个较长的周期。

另外，在传统的业务部署场景中，运维人员需要根据以往的数据经验对流量洪峰发生的时间进行预测，并提前通过手动的方式对云 IT 资源作扩容部署。然而，在需求变化越来越快的今天，这种僵化的 IT 资产管理方式已经不再适用。

所以，针对此类具有时间周期特性的高并发请求业务，我们利用腾讯云 Serverless 基于事件触发的自动伸缩机制进行优化。实现了只有当业务请求到达时，才会启动相应的进程来进行响应，能够更加随心所欲的去应对流量洪峰。

从上述两个方面可以看出，腾讯云 Serverless 从根本上改变了我们的 IT 研发模式。通过 Serverless 我们可以更加低成本且高效的去探索新型业务场景、对 MVP（最小可用模型）进行快速验证。更重要的是，在整个 Serverless 服务体验中，用户只需为 “真正的业务资源” 付费，而不需要为周边的基础设施付费，真正的实现了云计算的核心价值就是 “敏捷、弹性和按需付费”。

4. Minikube

在以往，应用程序交付是运维团队的专属工作云计算实现，现如今随着 DevOps 的实践价值被得到了证明，越来越多的企业也开始将运维团队转型为运维开发部门。同样，越来越多程序员的工作平台也从最初的 Windows 迁移到了 Linux 再迁移到了现在的 Kubernetes 之上。

但是，Kubernetes 作为一个分布式的平台系统，想掌握和运行它显然存在一定的门槛。针对这一问题，Kubernetes 社区推出了 Minikube 项目，作为一种专为学习者和云原生开发者打造的轻量化 Kubernetes 集群管理工具。通过 Minikube，开发者完全可以基于自己的开发机器来运行一套 Kubernetes 运行环境，并支持 Kubernetes 的大部分功能，极大的帮助研发人员节省了搭建研发调试环境的时间。

5. Helm

如果我们将 Container 类似为 Linux 上的 Application，将 Kubernetes 类似为 Linux 本身，那么 Helm 就是 Linux 上的 Application Software Package 管理工具了（e.g. CentOS yum or Ubuntu apt etc..）。

在 Kubernetes 中部署一个应用程序，往往涉及多个 Kubernetes Resources 之间的共同协作。例如：当我们部署一个 WordPress 应用时，可能会使用到 Deployment（执行部署）、Service（提供服务发现）、Secret（配置 WordPress 的用户名和密码）、PV/PVC（提供持久化存储服务）等多种 Resources API。更甚的，WordPress 还会依赖 MariaDB 等等其他应用。随着 Micro-services 架构的流行，在 Kubernetes 之上部署的 Applications 实际上已经变得非常复杂，再通过原始的 YAML 方式进行部署显然不现实。

Helm 就是解决 Micro-services Application 在 Kubernetes Cluster 上进行便捷安装、卸载和更新的实践工具。使用户能够简单高效地查找、下载、安装指定的应用。当我们向客户交付一个云原生应用时，必然会使用 Helm 工具进行打包，以及来提供更优雅的部署体验和最佳运维实践。

6. Ansible

在云计算环境中，一个现代化的自动化的运维工具能够有效的帮助团队管理和使用一个相对复杂且大规模的 IT 基础设施集群，包括：全面的部署自动化以及云计算环境中的快速服务器配置等等。

Ansible 就是目前最佳的 IT 自动化运维工具之一。相比于其他自动化运维工具，Ansible 的主要特点有 2 个：首先，Ansibel 的底层基于 OpenSSH 实现，所以无需在客户主机和目标主机安装任何代理程序，所以也不存在由于卸载了代理程序故障导致的主机失联问题。这一特性，使得 Ansible 可以被应用于几乎任何能够被 SSH 的服务器；其次，Ansible 通过 Playbook（剧本）的方式来组织代码逻辑，具有非常优秀的 “模块化” 编程理念，通过对 Playbook YAML Module 的编写，开发者可以重复利用不同的功能模块来灵活实现一个复杂的功能。

7. EFK

随着 Micro-services 应用软件的复杂度越来越高，特别是部署到云上之后，再想登录到大规模分布式部署的各个节点上查看各个进程模块的日志信息，几乎是不可行的。不仅仅是效率低下，更因为出于安全性的考虑，云主机或服务器不能随意让工程师直接访问。而且在云原生的环境中，Pod 的弹性扩展和漂移特性都让分布式系统的日志查看更加困难。

所以在云原生时代，我们需要一个集中式的日志审计系统来帮助完成日志收集、过滤、检索的工具。甚至还可以进行基于大数据的统计和分析，用于支撑闭环的智能运维。

EFK 就是一个面向分布式系统的集中式日志解决方案，由 Elasticsearch、Fluentd 和 Kibana 这 3 款开源软件产品的首字母缩写，简称为 EFK Stack。

8. Swagger/OpenAPI

Swagger Specification 是一种 API Specification（API 规范），2015 年，SmartBear Software 将 Swagger Specification 捐赠给 Linux Foundation，并改称为 OpenAPI Specification，简称（OAS）。

OpenAPI Specification 本质上是一种 RESTful API 的 API Description Format（描述格式），允许用户用于描述整个 API。OpenAPI 规范可以用 YAML 或 JSON 编写，包括：

在敏捷团队的实践中，基于 API 的协作至关重要，Swagger/OpenAPI 可以基于规范的方式来支撑 Design First 的 API 协作模式，快速拉通各微服务组件之间的协同研发。

Design-First 具有很多好处：

提高开发效率。开发团队将根据 API 规范进行并行开发和对接工作，而无需等待接口逻辑开发完毕。降低接口开发的成本，无需修改代码逻辑即可轻松地修改 API 规范，因为 API 描述语言（如：OpenAPI）与编码语言无关。开发人员更加专注于设计 API 规范，对比 Code-First 可以描写更多 API 的细节，如：校验规则、范例数据等，同时开发人员对 API 的全局一致性、扩展性、规范性也有更好的把控。在联调开发的过程中可以提前发现和解决问题，避免问题在开发完毕后修改的成本过高。由于 API 描述更加标准化，可以方便做更多的 API 生态延伸，比如基于 API 规范生成 Mock API Server，开发 API 自动化测试代码，接入 API 网关等。

另外，Swagger/OpenAPI 结合 Mock API Server 可以实现自动生成 Mock API，通过提供真实 API 响应的范例数据来模拟真实的 API 服务，并且支持路由及参数校验。

9. K1s

K1s 是一个非常有趣且实用的 Kubernetes 仪表盘工具，它的本体只有短短的 50 多行 Bash 代码，可能是世界上最小的 Kubernetes Dashboard。正式因为 K1s 这种非常极致的 Unix-like 美学，所以受到了 Linux Shell Terminal 用户的喜爱。并且由于 K1s 极致的轻巧，几乎不占用任何资源，所以在本就资源非常紧张的开发环境中很实用。

K1s 可以展示所有或任意 Namespaces 中的 Resource List，打开 Shell 并输入 k1s CLI 即可完成实现 Kubernetes 资源信息查看和实时监视。下图是一个官方提供的使用效果，分别实时监视着 Deployment、ReplicasSet 和 Pod 资源的运行状态。

10. Wireshark

云计算研发中大部分的棘手问题都是网络导致的，Wireshark 作为一款功能强大的数据报文分析实用工具，几乎是我们每次遇见网络问题必定使用的工具。

Wireshark 可以截取各种网络数据包，并显示数据包详细信息，常用于开发测试过程中各种问题定位。例如：随着 HTTP/2 协议的应用越来越广泛，我们也将微服务 APIGW 的 HTTP Server 升级成了 HTTP/2 版本。

在 API 调试的过程中，我们经常需要面对分析 API 信令的情况。但由于 HTTP/2 采用的是二进制分帧层（Binary Framing）实现，会将每个请求和响应分割成为更小的帧，并对它们进行了二进制编码。所幸的是，新版本的 Wireshark 能够支持解析 HTTP/2 数据报文，有效的支持了我们的 API 研发工作。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!