DevOps是微服务的秘方

查看原文

其他

DevOps是微服务的秘方

Original Alex Handy 中生代技术 2021-08-09

ALEX HANDY

读完需要

6分钟

速读仅需 2 分钟

作者丨Alex Handy译者丨大白
策划丨中生代技术社区

DevOps

迁移到微服务通常需要数量庞大的自动化，自动化意味着运维部署。在当今云开发、敏捷开发为主的情况下，运维正朝着优秀的 DevOps 实践迈进。自然地，自动化需要代码，并且如今的运维工程师拥有一些有史以来最强大的工具和系统，可以将比如说环境复杂性降低为更容易编程的模块。

但是，要实现这一目标，微服务的真正研磨是必须有复杂的编织系统到位，负载均衡，网关监控，并在第一个微服务部署之前将整个应用程序堆栈中分发安全模型；这有点像一个厨师需要一个干净的、有厨具的厨房，以准备晚餐服务。这甚至延伸可以到服务员和点餐系统，工作人员需要把那些精心准备的牛肉盘子端给饥饿的顾客。

DevOps 的技能不是为了成为一名出色的厨师，而是成为一名出色的管理者：管理服务员，管理送餐窗口，管理厨师和管理账目，并且整个流程链，产品和人员完全可视化。

在微服务领域，这意味着通常由 DevOps 负责建立构建大规模环境所需的所有基础架构。这意味着 Web 应用程序服务器，注册表和存储库，操作系统和容器映像，虚拟化网络，防火墙，负载平衡器，消息队列和反向代理。DevOps 团队还必须支持开发团队所需的新技术：HTTP2，GRPC 和可靠的 SSL。

GitLab 首席执行官 Sid Sijbrandij 说：“随着微服务的爆炸式增长，越来越多的项目涌现。公司发现，他们不仅必须自动化 DevOps 生命周期，而且还必须实现自动化。对于每个项目，您都必须设置创建工具，打包和管理。如果您每次都必须这样做，那将花费很多时间。微服务复杂性不断提高，因此需要在开发和运维之间进行更紧密的协作，达成共识更为重要。”

是数据啊，笨蛋！

一个可能变得棘手的地方是数据。从使数据库在 Kubernetes 中可靠地大规模运行到开发人员在通过微服务体系结构释放时可以采用的外部数据存储的突然激增，对于基于云的基础架构来说，数据都是一个大问题：问题如此之多，以至于最早的云时代就有了关于“从应用程序中删除状态”的整体性建议。

今天，我们知道有状态和无状态应用程序都可以在云上愉快地共存，但是管理数据的实际日常工作并不总是那么容易。Kasten 产品负责人 Georgi Matev 说：“我们看到的是数据遵循的模式与计算端相同。随着事务分解成更小，更合乎逻辑的组件，在数据端亦如此。”

虽然听起来不错，但敏捷的移动数据与移植代码完全不同。Datical 首席技术官 Robert Reeves 说，这不是不自动化数据层的借口。“每个人都可以更快地编译部署应用程序。但是，他们仍然依靠手动更改数据库来支持该应用程序。这导致速度差。Reeves 说：“您的房子中有一部分按时离开家，而房子的另一侧（数据库人员）则处于自杀观察状态。”

准备微服务有点像厨师需要一个正确清洁，工具齐全的厨房，以便准备晚餐服务。

Reeves 说：“我们需要让人们摆脱困境。我们需要消除人工干预。过去系统管理员认为构建服务器就像构建手工咖啡桌一样。‘看看这布线！看看咱们数据中心的有多漂亮？’今天，谁在乎，老兄？”

Reeves 说：“首先需要克服的想法是，我们需要人工来手动查看和执行我们的 SQL 脚本。” “我们的第一个企业客户是一家非常大的银行。当我们的执行发起人开始与 DBA 交谈并说：“嘿，您如何看待数据库的自动化，”他说，“那不是我们在这里做事的方式。”

Reeves 说：“我们是微服务的忠实拥护者，但您需要将更新这些服务和支持微服务的数据库的力量交给产品团队。” “我们有使用 Pivotal 的客户，他们可以在几秒钟内更新，但是必须等到外部服务团队可以在数据库上运行脚本之后再进行。他们需要等待 10 至 12 天。重点是什么呢？”

复杂问题

更加复杂的是引入 Kubernetes 作为容器编排的新标准。随着采用 Kubernetes 的应用不断增长，围绕它的一些与现有基础架构模式相适应的问题尚未完全解答。尽管如此，还是由 DevOps 来理解和管理 Kubernetes，以便开发人员可以按需获取他们的数据库，管道和部署。

IBM 只是已经在 Kubernetes 上建立基础架构的众多公司之一。例如，Istio 项目允许 DevOps 团队完全控制其微服务周围的数据和流量。Daniel Berg 是 IBM 杰出工程师，负责容器和微服务，在给 newstack 的电子邮件中写道，“在 open community[theopencommunity.org]，[IBM 公司]曾与其他顶级技术公司，如谷歌和 Lyft 建立 Istio，把业务流程层装备在开发与容器上，以更好地保护和流量监控。我们还与 Google 合作推出了 Grafeas，这有助于在部署和使用容器时保护围绕容器的供应链代码。”

IBM 的工作还致力于使 Kubernetes 更易于使用，因此不必通过在复杂的系统上旋转旋钮来垄断 DevOps。“尽管使用 Kubernetes 构建基于容器的解决方案仍然存在学习上的弯路，但我们正在 IBM 内部以及与社区一起开发工具和功能，以使其更容易在 Kubernetes 中开发应用程序而不必成为 Kubernetes 专家，”Berg 写道。

所有这些服务的背后都需要一套统一的流程。投资于公司内部微服务的各种团队需要开放的沟通渠道，并且需要以无可避免的方式来实施它们。这是一项工作，它是将人类行为编码到自动化，部署和开发管道中。

Nginx 的微服务工程首席架构师和高级总监 Chris Stetson 表示：“您必须围绕应用程序开发方式改变思维方式。最近，我们一直在做的事情之一就是创建一个统一的开发和部署过程，在此过程中，您的应用程序开发人员将在 Docker 化版本的应用程序中工作，并基本上在该 Docker 环境中进行编码和测试，这非常类似于我们将最终为客户部署的环境。Stetson 说：“建立这一流程使开发人员轻松上手非常有价值。”

Stetson 说，Nginx 已经实施了一个几乎古老但有效的解决方案。“我们使用 Makefiles，我们一直在使用 Makefiles 来封装更复杂的 Docker 组合命令，这些命令已经组合在一起，成为前端开发人员能够进行 Webpack 前端开发的构建目标。他们重新连接到他们需要动态重新加载正在使用的更改的所有服务，我们喜欢使用 Makefile，因为它本质上类似于声明性的 Bash 脚本，” Stetson 说。

作者简介

4.1

Alex Handy

Alex Handy 是拥有 20 年经验的资深技术记者，他的作品发表在 Wired， the Atlanta Journal Constitution, and The Austin American Statesman. 他还是位于奥克兰的非营利性电子游戏博物馆艺术和数字娱乐博物馆（themade.org）的创始人和总监。他在 VonGuard.net 进行咨询。