工程

我们的微服务之旅,开始

发表于十一月21,2017
通过TC

技术团队迁移到微服务的原因很多。微服务所提供的灵活性是业界公认的许多“成功关键”:

这些都很好,我们当然会关心所有这些。但是,在Redox,我们迁移到微服务的主要原因是:

帮助开发人员尽可能快地制作出很棒的东西。

换句话说,我们的开发人员具有“摆脱困境,让我做出令人敬畏的东西”的态度,并且我们认为微服务是使这种态度真正得以实现的最佳方法。 成为 很棒的东西。

在整个系列中,我们希望记录从整体到微服务的旅程,希望我们可以分享我们的经验,而其他人也可以从我们的错误中学习,而不必自己犯错误。

 

我们到达这里的简要历史…

 

氧化还原平台大约已有三年历史了。我们的发展方式与许多平台和团队在我们之前的发展(以及在我们之后的发展)相同。当我们开始时,我们有一项服务可以完成所有工作。我们真的不知道我们要构建什么,因此其中一个服务中包含一点Web前端内容,一点后端处理,一点数据库定义,一点监视以及一点点其他的一切。长期以来,这种方法非常有效,因为只需一点点即可管理,而且我们所有人都可以轻松地看到发生了什么。

大约一年后,我们很清楚自己在构建什么,尽管我们想构建很多东西,但我们很容易看到它如何适合我们现有的体系结构,因此我们不断增加…然后添加...然后添加。

所有这些加在一起构成了一项服务,其中包含约12万行节点代码,还有许多其他内容。这不是您所见过的最大的巨石,但是在工作时,您需要掌握12万行代码。

随着平台的发展,我们的团队也随之发展。我们从一个小型团队发展到了多个小型团队,所有这些团队都仍在尝试使用同一服务。尽管尽我们最大的努力让每个团队负责服务的不同部分,但仍然存在大量冲突和混乱,由于需要进行大量测试,最简单的更改开始需要几天(甚至几周!)才能完成。即使拥有完整的自动化测试套件!

团队很快就发现,通过API进行通信的小型应用程序会变得更加有趣并且易于使用。因此,偶然地,我们开始进入微服务世界,缓慢而又不了解正确做对什么意味着什么。

 

那把我们带到了现在

基本上就是我们现在的位置。我们拥有一项几乎可以完成所有工作的巨型服务,以及数量不断增长但数量不断增加的微型服务,这些服务以不同的方式进行交互,内置不同的样式要求并以不同的方式运行测试等。所有的事情。

但是,微服务不是万灵丹。

正如我们从第一次意外进入微服务中学到的那样,它们不一定会使情况变得更好。如果我们不谨慎的话,最终会遇到一系列其他问题,这些问题将变得更加糟糕,难以解决。使用微服务,您需要将一组问题(很难处理的庞大组件)换成另一组问题(很多难以协调和管理的小服务)。

我们的赌注是,通过将当今存在的问题与微服务所带来的问题进行交易,我们作为工程团队的整体速度将大大提高,只要我们可以标准化我们创建和维护这些服务的方式.

这就是原因。在本系列博客的整个过程中,我们将分享分割整体的方法。我们会尝试尽可能多地写一些有趣的事情,在开始的时候(每两周一次)会相对频繁,并且很可能在我们安顿下来后就消失了。

 

哦,如果您想帮助我们进行微服务, 我们正在招聘!