微服务是逐渐形成的，而不是一开始就有的

本文最初于 2018 年 8 月 21 日发布于： https: //nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with

软件开发者的职业相当有趣。我们可能前一天还在兴高采烈地写代码，然后读到一篇关于某事的文章，突然间你开始质疑自己与编程相关的整个生活，因为 Netflix 说了 XYZ。

就像这样，从对个人或公司的看法开始，您开始质疑自己多年来所做的一切，即使它对您来说效果很好。

你不是谷歌（除非你是谷歌）

我们浏览 HackerNews 和其他编程新闻媒体时，经常会看到谷歌、Netflix、亚马逊和 Facebook 的科技帖子，他们喜欢谈论自己运营着多少服务，并大肆宣扬以自己的方式运营的好处。这在过去几年里一直是一种趋势。

但让我们面对现实吧。你可能不会有 1,000 名开发人员来开发一个拥有 10 多年历史的大型项目。

仅仅因为谷歌这样做，并不意味着你也应该这样做。

我们身处一个完全不同的世界。谷歌面临着我们可能永远不会遇到的问题，但与此同时，我们却可以做谷歌做不到的事情。

大多数软件项目是如何开始的？

很多项目都是一个人完成所有编程工作的。这样的例子不胜枚举，但让我们来看看 Shopify。Shopify 最初是由 Tobias Lütke 编写的（顺便说一下，它基于 Ruby on Rails，现在仍然如此）。

您是否认为 Tobias 在编写任何代码之前，都会坐在那里犹豫不决，苦苦尝试创建一个完美的基于微服务的架构？

当然不是。他开发 Shopify 的第一个版本时我并不在场，它最初只是一个销售滑雪装备的电商商店，但如果他像我一样（一个典型的开发人员），事情可能会是这样的：

1. 在构建初始产品的同时学习新技术
2. 编写一些非常不规范/糟糕但可以正常工作的代码
3. 看到它开始聚集在一起并感到兴奋
4. 一旦出现问题，就将“用火杀死它！”代码重构为更好的代码
5. 在添加新功能和在生产环境中运行时不断重复此循环

这看起来似乎是一个非常简单的循环，但我花了大约 20 年的编程时间才真正理解这个循环有多么深刻。

在编写一行代码之前，通过理论上制定最佳设置并不能让你成为一名更好的程序员。

一旦您开始亲身遇到实际问题，您就可以通过编写大量代码并完全有意地用更好的代码替换几乎所有编写的代码来变得更好。

你重写的初始代码并非浪费时间或精力。随着时间的推移，它对你提升水平至关重要。它是你的秘诀。

让我们谈谈代码抽象

作为开发人员，我们都听过这句话“DRY：不要重复自己”，一般来说，这是一个合理的指导，但很多时候重复自己是非常值得的。

这值得重复，因为如果您试图抽象某些东西而没有真正理解您正在抽象的东西，那么您就会创建一种称为泄漏抽象的东西。

我通常会重复三次，才会考虑重构代码来消除重复。通常要到第四次或第五次我才会真正采取行动。

这是因为您确实需要了解如何在不同情况下重复代码几次，然后才知道需要将哪些内容转换为变量，并将其从最初内联的位置删除。

抽象级别，从内联代码到外部库：

1. 编写内联代码
2. 在不同位置重复几次代码
3. 将重复的代码提取到函数/等中。
4. 使用你的抽象一段时间
5. 看看该代码如何与其他代码交互
6. 将通用功能提取到内部库中
7. 长时间使用内部库
8. 真正理解所有部分是如何组合在一起的
9. 如果有意义的话，创建外部库（开源等）

这正是你无法“发明”一个好的库或框架的原因。我们今天使用的几乎所有非常成功的工具都来自现实世界的项目，而我们喜爱的工具都是从真实的内部用例中提取出来的。

Rails 就是一个很好的例子。DHH（Rails 的作者）可不是某天醒来突然说“哎呀！该创建 models/、controllers/ 和 views/ 目录了！”。

不。他开发了Basecamp（一个真正的产品），并由此衍生出一些模式，这些模式被推广，然后从Basecamp中移植到Rails中。这个过程至今仍在继续，在我看来，这也是Rails持续成功的唯一原因。

这是一场完美的风暴，由经过充分测试（而非理论构建）的抽象概念，以及一种允许你编写视觉吸引力代码的编程语言组成。这也是几乎所有“用 XYZ 语言实现的 Rails”框架失败的原因。他们跳过了抽象链的关键组件，以为只要复制 Rails 的功能就可以了。

将代码抽象与微服务关联起来

对我来说，微服务只是另一个抽象层次。我不一定会说它是上面列表中的第 10 步，因为并非所有库都旨在成为微服务，但在概念层面上，它们是相似的。

微服务并非你从第一天就开始做的事情，就像你不会在第一天写完一行代码之前就尝试创建一个完美的开源外部库一样。那时你甚至不知道自己在做什么。

随着您在使用代码库时遇到实际问题，您可能会逐渐采用基于微服务的架构。

你可能永远不会遇到这些问题，而且很多问题也可以通过其他方式解决。看看Basecamp和Shopify。它们都是运行良好的单体应用。

我认为没人会称它们为小型应用程序。当然，它们的运行规模远不及谷歌，但让我们从某个角度来看待这个问题。

Shopify 凭借单体应用每月盈利超过 1700 万美元

截至 2018 年中，Shopify 公开宣布其平台上有600,000 多家企业经营在线商店。

Shopify 是一款 SAAS 应用，其最便宜的套餐每月 29 美元，我感觉很多企业都在使用他们每月 79 美元的套餐。无论如何，即使有 60 万人使用他们最便宜的 29 美元/月套餐，仅 SAAS 业务每月就能带来 1740 万美元的收入。

Basecamp 是另一个相当庞大的单体应用。Basecamp 的有趣之处在于，他们只有大约 50 名员工，其中只有一小部分是开发主产品的软件工程师。

我的观点是，即使你不钻微服务的空子，也能走得非常远。微服务应该建立在“按需学习”的基础上。

何时应使用微服务？

这完全取决于你和你的团队如何决定。如果你觉得微服务更合适，你就不会在谷歌上搜索“微服务 vs 单体架构”了。你已经知道答案了。

但有一种情况是，如果你有大量开发人员，而他们最适合处理应用程序的各个子部分。让数十个团队独立地处理产品的各个组件，这是微服务的一个合理用例。

请记住，你的团队规模可能很小，随着时间的推移会慢慢壮大，所以你最终可能会从 1 到 2 个微服务开始，然后再逐步扩展。你可能不会一下子就把一个单体应用改造成 100 个服务。

榨汁值得吗？

值得一提的是，向微服务转型本身也伴随着一系列挑战和问题。你正在用一个问题换取另一个问题，所以你需要权衡利弊，看看它对你的项目来说是否值得。

最大的问题之一是监控。突然之间，你拥有一堆可能使用不同技术栈编写的服务，它们运行在多台机器上，你需要一种方法来窥探所有细节。

这是一项艰巨的任务，因为理想情况下您希望所有这些服务使用单一统一的服务来收集和显示这些指标。

你可能不想为此开发自己的工具，因为光是开发工具就可能是一项全职工作，这也是像LightStep这样的公司如此成功的部分原因。它们是我旅行中遇到的最有趣的监控服务之一。

他们的产品更侧重于大型应用（理由很充分），但也能适用于小型项目。我最近才听说他们，因为他们在Cloud Field Day 4上做了演示。

无论如何，监控只是众多挑战之一，但我想我会提出这一点，因为它是更痛苦的问题之一。

最后的想法

我写这篇文章主要有两个原因：

首先，两周前我参加了第四届云田野日 (Cloud Field Day)，碰巧做了一个相关主题的集体播客。这个播客应该会在几个月后发布（我会在这篇文章中更新链接），但我想在这里详细阐述一下我的一些观点。

其次，作为在线课程的创建者，我经常收到人们关于如何构建应用程序的问题。

我发现一个普遍的趋势是，很多人在还没写一行代码之前就试图将他们的应用拆分成独立的服务。甚至一开始就想把应用的各个组件拆分开来使用多个数据库。

这是阻碍他们前进的因素，作为一名开发人员，我知道陷入犹豫不决的循环是多么令人沮丧（我也经历过这样的事情！）。

顺便说一句，我目前正在开发一个相当大的SAAS应用，它是一个定制课程托管平台。目前只有我一个人在做这个项目，而且你肯定知道，我第一天就打开了代码编辑器，开始写代码了。

我完全有意将它保留为一个雄伟的整体，直到它不再有意义，但我的蜘蛛感应告诉我，无论如何我都永远不会达到这一点。

你对这个话题有什么看法？请在下方留言告诉我。