我建议谈论何时需要微服务，何时不需要微服务。 剧透：这取决于项目。我们，软件开发人员，有着相当有趣的职业。 我们可以安全地编码几天，然后阅读有关某事的文章-这对我们的整个工作提出了质疑，因为有些Netflix告诉XYZ。
就像那样，由于一个人或一家公司的意见，即使一切工作正常，您也开始怀疑自己多年来所做的一切。
您不是Google（除非您是Google）
当我们阅读HackerNews和其他新闻站点时，我们经常会看到来自Google，Netflix，Amazon和Facebook的技术信息，他们喜欢谈论他们启动了数百或数千个服务。 他们谈论用自己的方式做事的好处。 这是过去几年的趋势。
但是，让我们面对现实吧。 您不可能有1000名开发人员从事具有超过10年历史的大型项目。
仅仅因为Google这样做并不意味着您也应该这样做。我们在一个完全不同的星系中工作。 Google面临着我们可能永远不会遇到的问题，但是与此同时，我们可以做Google无法做的事情。
大多数软件项目如何开始？
许多项目都是由一个人完成所有工作开始的。 有上百万个示例，但让我们看一下Shopify。 最初，该服务对Tobias Lyutke进行了编码（它基于Ruby on Rails，并且仍然可以在Rails上运行）。
在编写第一行代码之前，您是否认为Tobias犹豫不决，仔细考虑了微服务的理想体系结构？
地狱号 在开发Shopify的第一个版本时我不在场，该版本最初只是一个在线滑雪板商店，但是如果Tobias看起来像我（一个典型的开发人员），则过程如下所示：
- 在编写原始产品时学习新技术。
- 编写相当不标准（讨厌）但可以正常工作的代码。
- 看看一切如何协同工作并感到兴奋。
- 像发生“着火燃烧”一样进行重构，并在出现问题时改进代码。
- 添加新功能并在生产环境中启动时，请重复此循环。
这似乎是一个非常简单的周期，但是我花了大约20年的编程时间来弄清楚它的深度。
作为程序员，您并没有变得更好，在编写第一行代码之前，从理论上考虑了最佳设置。
通过编写大量代码，使您变得更好，因为它的绝对明确的意图是，一旦您遇到实际问题，便用更好的代码替换几乎所有编写的代码。您替换的原始代码不会浪费时间或精力。 随着时间的推移，它可以帮助您提高水平。 这是一个秘密成分。
谈论代码抽象
作为开发人员，我们都听到过
“干：不要重复自己”的字眼 ，总的来说，合理的建议是不要再做这项工作。 但是通常这是值得做的。
当您在没有完全理解的情况下尝试抽象某些东西并创建所谓的泄漏抽象时，值得重复一遍。
我通常在不考虑重构某些代码并删除重复项之前就进行三次工作。 通常，只有在第4次或第5次之后，我才采取一些措施。
您确实需要多次查看在不同情况下如何复制代码，才能清楚地知道将什么内容确切地转换为变量并从最初编写此代码的地方删除。
从嵌入式代码到外部库的抽象级别：- 编写内联代码。
- 在几个不同的地方复制代码。
- 提取函数中的重复代码等
- 暂时使用这些抽象。
- 查看此代码如何与其他代码交互。
- 将常规功能提取到内部库中。
- 长时间使用内部库。
- 真正了解所有部分如何组合在一起。
- 如果可以的话，请创建一个外部库（开源等）。
关键是您不能“发明”一个好的库或框架。 我们今天使用的几乎所有非常成功的工具都来自真实世界的项目。 在这里，我们最喜欢的工具是从内部使用的实际案例中提取的。
Rails是一个很好的例子。 DHH（Rails的作者）有一天没有醒来，说：“哦！ 现在该创建模型/，控制器/和视图/！目录了。”
不行 他开发了Basecamp（真正的产品），然后出现了某些模板，然后对这些模板进行了概括，然后从Rails的Basecamp中提取了这些模板。 这个过程今天仍在进行中，我认为，这是Rails如此成功的唯一原因。
这是运行良好（阅读：理论上未开发）的抽象与编程语言相结合的理想风暴，该编程语言使您可以编写有吸引力的代码。 这也解释了为什么几乎所有的框架（如“仅在XYZ中使用导轨”）都不起作用。 他们跳过了抽象链的关键组成部分，并认为他们可以简单地复制Rails。
从抽象到微服务
对我来说，微服务只是抽象的另一个层次。 这不一定是上面列表中的第10步，因为并非所有库都针对微服务而设计，但从概念上讲，似乎是这样。
微服务并不是您的起点，就像您不会在编写至少一行代码之前就尝试创建完美的外部开源库一样。 此刻，您甚至不知道自己在开发什么。
当您遇到实际问题时，基于微服务的体系结构就是项目可以随着时间的推移而变成的。也许您永远不会遇到这些问题，并且其中许多问题可以通过不同的方式解决。 看看Basecamp和Shopify。 它们都可以作为整体应用程序很好地工作。
我认为没有人会称他们为小型公司，尽管他们无法在Google规模上工作。
Shopify每月赚1700万美元
截至2018年中，Shopify已公开宣布
超过600,000个在线商店在其平台上运营。
Shopify是一个SaaS应用程序，具有每月29美元的最低费率，我感到许多公司选择每月79美元的费率。 无论如何，即使600,000个客户使用了最便宜的计划（29美元），也仅从其业务的SaaS线获得每月1,740万美元的收入。
Basecamp应用程序是另一个出色的整体应用程序。 Basecamp有趣的是，他们只有大约50名员工，而且只有其中一些是从事主要产品工作的软件开发人员。
我想说的是，您可以不走微服务的麻烦而走得很远。 不要像那样创建微服务。
什么时候应该使用微服务？
这完全取决于您的决定。 这只是您不会在Google上搜索“针对整体的微服务”的事情之一。 如果您真的需要微服务，您将已经知道。
但是，可能会出现这样的情况：您有一堆最适合在应用程序的各个部分上工作的开发人员。 数十个团队
单独从事产品各个组件的工作是将其用于微服务的合理原因之一。
请记住，如果您的团队规模随着时间的推移而缓慢增长，则可以从一两个微服务开始。 在这种情况下，您可能不应该从采石场开始立即将整体拆分为100个微服务。
这个游戏值得吗？
还值得一提的是，向微服务的过渡伴随着其自身的一系列问题。 您将一个问题换为另一个问题，因此您需要权衡该游戏是否值得专门针对您的项目的利弊。
主要问题之一是监视。 突然，您可以获得一堆可以在不同技术堆栈上编写，可以在多台机器上运行的服务-并且您需要一种详细跟踪它们的方法。
这是一项艰巨的任务，因为理想情况下，我们希望所有微服务都使用单个监视服务。
您可能不想开发自己的工具，因为这本身可能会变成一项完善的工作。 这就是
LightStep等公司成功的原因。 这是我遇到的最有趣的监视服务之一。
他们的产品更专注于大规模应用（这是可以理解的原因），但它也适用于小型项目。 我最近听说了它们，因为它们是在
Cloud Field Day 4上展示的 。
无论如何，监视只是许多困难之一，但是我决定提及它，因为它是最痛苦的问题之一。
最后的想法
基本上，我写这篇文章有两个原因：
首先 ，两个星期前，我参观了
Cloud Field Day 4，并偶然参加了有关相关主题的小组播客。 它应该在几个月后发布，但在这里我想谈谈一些观点。
其次 ，作为在线课程的作者，我对如何创建自己的应用程序有很多疑问。
许多开发人员“冻结”，试图在编写第一行代码之前就将其应用程序拆分为隔离的服务。 可以说，他们从一开始就尝试使用多个数据库作为应用程序组件。
这一刻阻止他们前进，作为开发同事，我知道陷入犹豫不决的难度有多大（我做过！）。
顺便说一下，我目前正在开发一个相当大的SaaS应用程序-一个用于托管自定义课程的平台。 现在，我仅在一个项目上工作，您可以确定我刚打开编辑器并在第一天就开始编写代码。
我将把该项目保存为一个完全独立的应用程序，直到实现微服务有意义为止，但是我的直觉告诉我，这样的时刻永远不会到来。
您如何看待？ 在评论中让我知道。