孤立服务:(微)服务架构的缺点

Banki.ru 门户网站运营总监 Andrey Nikolsky 在去年的会议上发表了讲话 莫斯科 DevOpsDays 关于孤立服务:如何识别基础设施中的孤立服务、为什么孤立服务不好、如何处理它们以及如果没有任何帮助该怎么办。

剪辑下方是报告的文本版本。


同事们大家好!我叫安德烈 (Andrey),负责 Banki.ru 的运营。

我们有大型服务,这些都是单一的服务,有更经典意义上的服务,也有非常小的服务。用我工农的术语来说,如果一个服务简单、小,那么它就是微的,如果它不是很简单、小,那么它就是一个服务。

服务优点

我将快速介绍这些服务的优势。

孤立服务:(微)服务架构的缺点

首先是缩放。 您可以快速在服务上做一些事情并开始生产。 你已经收到了流量,你已经克隆了服务。 你有更多的流量,你已经克隆了它并接受它。 这是一个很好的奖励,原则上,当我们开始时,它被认为对我们来说是最重要的事情,为什么我们要做这一切。

孤立服务:(微)服务架构的缺点

其次,隔离开发,当你有多个开发团队,每个团队中有几个不同的开发人员,并且每个团队开发自己的服务时。

对于团队来说,存在细微差别。 开发商不一样。 还有,例如, 雪花人。我第一次看到这个是和马克西姆·多洛费耶夫(Maxim Dorofeev)一起。有时雪花人在某些团队中而不在其他团队中。这使得整个公司使用的不同服务有点参差不齐。

孤立服务:(微)服务架构的缺点

看图:这是一个很好的开发者,他有一双大手,他能做很多事情。 主要问题是这些手从哪里来。

孤立服务:(微)服务架构的缺点

服务使得使用更适合不同任务的不同编程语言成为可能。 有些服务是用 Go 编写的,有些是用 Erlang 编写的,有些是用 Ruby 编写的,有些是用 PHP 编写的,有些是用 Python 编写的。 一般来说,你可以非常广泛地扩展。 这里也存在细微差别。

孤立服务:(微)服务架构的缺点

面向服务的架构主要是关于 DevOps。 也就是说,如果你没有自动化,就没有部署过程,如果你手动配置它,你的配置可以从一个服务实例更改到另一个实例,你必须去那里做一些事情,那么你就陷入了地狱。

例如,你有20个服务,你需要手动部署,你有20个控制台,你像忍者一样同时按下“回车”。这不太好。

如果您在测试后有一个服务(当然,如果有测试的话),并且您仍然需要用一个文件来完成它,以便它在生产中工作,我也有坏消息要告诉您。

如果你依赖特定的亚马逊服务并在俄罗斯工作,那么两个月前你也会有“周围的一切都着火了,我很好,一切都很酷。”

孤立服务:(微)服务架构的缺点

我们使用 Ansible 来自动化部署,使用 Puppet 来实现融合,使用 Bamboo 来自动化部署,并使用 Confluence 来以某种方式描述这一切。

我不会详细讨论这个,因为报告更多的是交互实践,而不是技术实现。

孤立服务:(微)服务架构的缺点

例如,我们遇到过这样的问题:服务器上的 Puppet 可以与 Ruby 2 一起使用,但某些应用程序是为 Ruby 1.8 编写的,并且它们不能一起工作。 那里出了问题。 当您需要在一台机器上运行多个版本的 Ruby 时,通常会开始遇到问题。

例如,我们给每个开发人员一个平台,上面几乎有我们拥有的一切,所有可以开发的服务,这样他就有一个隔离的环境,他可以打破它并按照他想要的方式构建它。

碰巧您需要一些专门编译的软件包来支持那里的某些东西。 这是相当艰难的。 我听过一篇报道称 Docker 镜像有 45 GB。 当然,在 Linux 中,它更简单,一切都更小,但仍然没有足够的空间。

嗯,存在冲突的依赖关系,当项目的一部分依赖于一个版本的库时,项目的另一部分依赖于另一个版本,并且这些库根本不安装在一起。

孤立服务:(微)服务架构的缺点

我们在 PHP 5.6 中有网站和服务,我们为它们感到羞耻,但我们能做什么呢?这是我们唯一的网站。 PHP 7 上有网站和服务,还有更多,我们并不以此为耻。每个开发者都有自己的基地,他乐于看到那里。

如果您在公司中使用一种语言进行编写,那么每个开发人员拥有三个虚拟机听起来很正常。 如果您使用不同的编程语言,那么情况会变得更糟。

孤立服务:(微)服务架构的缺点

你在这上面有站点和服务,然后是另一个 Go 站点,一个 Ruby 站点,还有其他一些 Redis 站点。 结果,所有这一切都变成了一个巨大的支撑场,并且总是有一些可能会被打破。

孤立服务:(微)服务架构的缺点

因此,我们用不同的框架取代了编程语言的好处,因为PHP框架有很大不同,它们有不同的功能、不同的社区和不同的支持。 您可以编写一个服务,这样您就已经准备好了一些东西。

每个服务都有自己的团队

孤立服务:(微)服务架构的缺点

我们多年来的主要优势是每个服务都有自己的团队。这对于大型项目来说很方便,可以节省文档时间,经理非常了解他们的项目。

您可以轻松地从支持人员处提交任务。 例如,保险服务出现故障。 处理保险的团队立即去修复它。

新功能正在快速创建,因为当您拥有一项原子服务时,您可以快速将某些内容添加到其中。

当你破坏你的服务时,这种情况不可避免地发生,你并没有影响其他人的服务,其他团队的开发人员也不会拿着比特跑来告诉你:“哎呀,不要这样做。”

孤立服务:(微)服务架构的缺点

一如既往,存在细微差别。我们有稳定的团队,管理者是固定在团队中的。有明确的文件,管理者密切监控一切。每个拥有经理的团队都有多项服务,并且有特定的能力点。

如果团队是浮动的(我们有时也使用这个),有一个很好的方法,称为“星图”。

孤立服务:(微)服务架构的缺点

您有一份服务和人员列表。 星号表示该人是该服务的专家,书籍表示该人正在研究该服务。 该人的任务是将小册子更改为星号。 如果服务前面没有写任何内容,那么就会出现问题,我将进一步讨论这一点。

孤儿服务如何出现?

孤立服务:(微)服务架构的缺点

第一个问题,在基础设施中获得孤立服务的第一种方法是解雇人员。 有没有人曾经让企业在评估任务之前按时完成任务? 有时,期限很紧,根本没有足够的时间来记录文件。 “我们需要将服务移交给生产,然后我们将添加它。”

如果团队规模很小,那么很可能只有一位开发人员编写所有内容,其他人则在幕后工作。 “我写了基本架构,让我们添加接口吧。” 然后在某个时候,经理就会离开。 在此期间,当经理离开并且尚未任命新经理时,开发人员自己决定服务的走向以及那里发生的事情。 正如我们所知(让我们回顾几张幻灯片),在一些团队中有雪花人,有时还有雪花团队领导。 然后他辞职了,我们得到了孤儿服务。

孤立服务:(微)服务架构的缺点

与此同时,来自支持和业务的任务并没有消失;它们最终会积压。如果在服务开发过程中出现任何架构错误,它们也会被积压。服务正在慢慢恶化。

如何认定孤儿身份?

这份清单很好地描述了这种情况。 谁了解了他们的基础设施?

孤立服务:(微)服务架构的缺点

关于已记录的解决方法:有一项服务,一般来说,它可以工作,它有一本两页的手册,介绍如何使用它,但没有人知道它内部是如何工作的。

或者,例如,有某种链接缩短器。 例如,我们目前在不同的服务中出于不同的目的使用了三种链接缩短器。 这些只是后果。

孤立服务:(微)服务架构的缺点

现在我将成为显而易见的队长。应该做什么?首先,我们需要将服务转移给另一个经理、另一个团队。如果您的团队领导尚未退出,那么在另一个团队中,当您了解该服务就像一个孤儿时,您需要包括至少了解一些相关信息的人。

最重要的是:你必须有血写的转移程序。 就我们而言,我通常会监控这一点,因为我需要它一切正常工作。 管理者需要快速交付,之后发生的事情对他们来说不再那么重要。

孤立服务:(微)服务架构的缺点

下一个制作孤儿的方法是“我们将其外包,会更快,然后我们将其交给团队。” 很明显,团队里每个人都有一些计划,轮流转。 通常,企业客户认为外包商会做与公司技术部门相同的事情。 尽管他们的动机不同。 外包有奇怪的技术解决方案和奇怪的算法解决方案。

孤立服务:(微)服务架构的缺点

例如,我们有一项服务,在各种意想不到的地方都有狮身人面像。 稍后我会告诉你我必须做什么。

外包商有自己编写的框架。 这只是从以前的项目中复制粘贴的裸 PHP,您可以在其中找到各种各样的东西。 当您需要使用一些复杂的 Bash 脚本来更改某些文件中的多行并且这些部署脚本由某些第三个脚本调用时,部署脚本是一个很大的缺点。 结果,你改变了部署系统,选择了其他东西,跳了,但你的服务不起作用。 因为有必要在不同文件夹之间再放置 8 个链接。 或者碰巧有一千条记录有效,但十万条记录不再有效。

我将继续担任队长。 接受外包服务是强制性程序。 有没有人遇到过外包服务到达后却未被任何地方接受的经历? 当然,这不像孤儿服务那么受欢迎,但仍然如此。

孤立服务:(微)服务架构的缺点

服务需要检查,服务需要审核,密码需要更改。我们遇到过一个案例,当他们为我们提供服务时,有一个管理面板“如果登录==‘admin’&&密码==‘admin’...”,它就写在代码中。我们坐下来思考,人们在 2018 年写下这篇文章?

测试存储容量也是必要的事情。 即使在将此服务投入生产之前,您也需要了解十万条记录会发生什么。

孤立服务:(微)服务架构的缺点

发送服务进行改进应该没有什么可耻的。 当你说:“我们不会接受这项服务,我们有 20 个任务,完成它们,然后我们就会接受”,这是正常的。 您的良心不应该因为您正在设立经理或企业在浪费金钱而受到伤害。 然后企业将花费更多。

当我们决定外包一个试点项目时,我们遇到了一个案例。

孤立服务:(微)服务架构的缺点

按时交付,这是唯一的质量标准。 这就是为什么我们做了另一个试点项目,它甚至不再是一个真正的试点项目。 这些服务被接受了,他们通过行政手段说,这是你的代码,这是团队,这是你的经理。 这些服务实际上已经开始盈利。 与此同时,事实上,他们仍然是孤儿,没有人理解他们是如何工作的,管理者也尽力否认他们的任务。

孤立服务:(微)服务架构的缺点

还有一个伟大的理念——游击式发展。 当某个部门(通常是营销部门)想要检验一个假设并订购整个服务外包时。 流量开始涌入,他们关闭文件,与承包商签署文件,开始运营并说:“伙计们,我们这里有一项服务,它已经有了流量,它给我们带来了钱,让我们接受它。” 我们当时就想,“Oppa,怎么会这样。”

孤立服务:(微)服务架构的缺点

还有另一种获得孤儿服务的方法:当某个团队突然发现自己负载过重时,管理层会说:“让我们将该团队的服务转移到另一个团队,它的负载较小。” 然后我们会将其转移到第三支球队并更换经理。 最后我们又有了一个孤儿。

孤儿有什么问题?

孤立服务:(微)服务架构的缺点

谁不知道,这就是瑞典培养的瓦萨号战列舰,因下水5分钟就沉没而闻名。 顺便说一句,瑞典国王并没有因此处决任何人。 它是由两代不知道如何建造这种船的工程师建造的。 效果自然。

顺便说一句,这艘船可能会以更糟糕的方式沉没,例如,当国王已经在暴风雨中的某个地方乘坐它时。所以,他立刻就被淹死了,根据敏捷的说法,尽早失败是件好事。

如果我们尽早失败,通常不会有任何问题。 例如,在验收期间将其发送以进行修改。 但如果我们在生产中已经失败,当资金投入时,那么可能会出现问题。 后果,正如商业上所说的那样。

为什么孤儿服务很危险:

  • 服务可能会突然中断。
  • 该服务需要很长时间才能修复或根本无法修复。
  • 安全问题。
  • 改进和更新问题。
  • 如果一项重要服务出现故障,公司的声誉就会受到损害。

孤儿服务该怎么办?

孤立服务:(微)服务架构的缺点

我会再重复一遍该做什么。 首先,必须有文档。 在 Banki.ru 工作的 7 年告诉我,测试人员不应该相信开发人员的话,运营也不应该相信每个人的说法。 我们需要检查一下。

孤立服务:(微)服务架构的缺点

其次,有必要写交互图,因为有些不太受欢迎的服务往往包含着无人提及的依赖关系。 例如,开发人员在某些 Yandex.Maps 或 Dadata 的密钥上安装了该服务。 你已经用完了免费限制,一切都坏了,你根本不知道发生了什么。 所有这些耙子都必须被描述:该服务使用数据、短信或其他东西。

孤立服务:(微)服务架构的缺点

第三,处理技术债务。 当你拄着拐杖或接受服务并说需要做某事时,你需要确保它已经完成。 因为那样的话可能会发现这个小洞并没有那么小,你会从里面掉下去。

在建筑任务中,我们有一个关于狮身人面像的故事。 其中一项服务使用 Sphinx 来输入列表。 只是一个分页列表,但每天晚上都会重新索引。 它由两个索引组装而成:一个大索引每天晚上都会索引,还有一个小索引用螺丝固定在上面。 每天,有50%的概率,无论是否被炸,指数在计算过程中崩溃,我们的新闻在主页上停止更新。 起初,索引需要 5 分钟才能重新建立索引,然后索引不断增长,在某个时刻开始需要 40 分钟才能重新建立索引。 当我们删除这个时,我们松了一口气,因为很明显,还需要一点时间,我们的索引将完全重新索引。 这对我们的门户来说将是一个失败,八个小时没有消息——就这样,业务停止了。

与孤儿服务合作的计划

孤立服务:(微)服务架构的缺点

其实这是很难做到的,因为devops就是沟通。 你想与同事搞好关系,当你用规章制度打击同事和经理时,他们可能会对这样做的人产生矛盾的感觉。

除了所有这些点之外,还有另一件事很重要:特定的人必须负责每个特定的服务、部署过程的每个特定部分。 当没有人的时候,你必须吸引其他一些人,来研究整个事情,就变得困难了。

孤立服务:(微)服务架构的缺点

如果所有这些都没有帮助,并且您的孤立服务仍然是孤立的,没有人愿意接受它,没有编写文档,被召集到该服务的团队拒绝做任何事情,有一个简单的方法 - 重做一切 。

也就是说,您重新提出服务需求,并在更好的平台上编写更好的新服务,而无需奇怪的技术解决方案。 你会在战斗中迁移到它。

孤立服务:(微)服务架构的缺点

我们遇到过这样的情况,当我们在 Yii 1 上使用一个服务时,我们意识到我们无法进一步开发它,因为我们已经没有能够在 Yii 1 上写得好的开发人员了。所有开发人员都在 Symfony XNUMX 上写得很好。该怎么办?我们分配时间、分配团队、分配经理、重写项目并顺利切换流量。

此后,可以删除旧服务。 这是我最喜欢的过程,当您需要从配置管理系统中取出并清除某些服务,然后查看并看到所有生产中的汽车都已被禁用,以便开发人员不会留下任何痕迹时。 存储库保留在 Git 中。

这就是我想谈的一切,我准备讨论了,话题是holivar,很多人都在其中游泳。

幻灯片说你们统一了语言。 一个例子是调整图片的大小。 真的有必要严格限制为一种语言吗? 因为在 PHP 中调整图像大小实际上可以在 Golang 中完成。

事实上,就像所有实践一样,它是可选的。也许,在某些情况下,这甚至是不可取的。但你要明白,如果你的公司有一个 50 人的技术部门,其中 45 人是 PHP 专家,另外 3 人是懂 Python、Ansible、Puppet 之类的 DevOps,而且只有一个人会写一些东西。某种语言。一些 Go 图像大小调整服务,然后当它离开时,专业知识也随之消失。与此同时,您需要寻找了解这种语言的特定市场开发人员,尤其是在这种语言很少见的情况下。也就是说,从组织的角度来看,这是有问题的。从 DevOps 的角度来看,您不仅需要克隆一些用于部署服务的现成的剧本集,而且还必须重新编写它们。

我们目前正在 Node.js 上构建一项服务,这将只是每个使用单独语言的开发人员附近的一个平台。但我们坐下来认为这场比赛得不偿失。也就是说,这是一个需要你坐下来思考的问题。

您如何监控您的服务? 您如何收集和监控日志?

我们在Elasticsearch中收集日志并将其放入Kibana中,根据是生产环境还是测试环境,在那里使用不同的收集器。 我不记得在某个地方伐木工,在其他地方还有其他东西。 而且在某些服务中仍然有一些地方我们安装了 Telegraf,并在其他地方单独拍摄。

如何在同一环境中与 Puppet 和 Ansible 共存?

其实我们现在有两个环境,一个是Puppet,一个是Ansible。 我们正在努力将它们杂交。 Ansible 是一个很好的初始设置框架,Puppet 是一个糟糕的初始设置框架,因为它需要直接在平台上进行实际操作,而 Puppet 可确保配置收敛。 这意味着平台会保持自身处于最新状态,并且为了使 ansibilized 机器保持最新状态,您需要始终以一定频率在其上运行 playbook。 这就是区别。

如何保持兼容性?您在 Ansible 和 Puppet 中都有配置吗?

这是我们的巨大痛苦,我们保持与双手的兼容性,并思考如何从现在的这一切中继续前进。事实证明,Puppet 在那里推出软件包并维护一些链接,而 Ansible 则在那里推出代码并调整最新的应用程序配置。

该演示涉及 Ruby 的不同版本。 什么解决办法?

我们在一个地方遇到过这种情况,而且我们必须一直把它记在心里。 我们只是关闭了在 Ruby 上运行的与应用程序不兼容的部分,并将其分开。

今年的会议 莫斯科 DevOpsDays 将于 7 月 11 日在 Technopolis 举行。 我们在 XNUMX 月 XNUMX 日之前接受报告申请。 如果您想发言,请联系我们。

参与者报名现已开放,加入我们吧!

来源: habr.com

添加评论