应用程序中的微服务：日常生活中出现的用例

微服务已成为现代性的代名词。许多人采用它们是因为“大公司使用它们”，而没有问唯一重要的问题：它们今天为我解决了什么具体问题？

这篇文章扭转了这种方法。它不是抽象地解释架构，而是从真实的用例、操作产品的人日常生活中出现的情况出发，将系统划分为独立的服务不再是理论，而是成为实际的解决方案。

因为微服务不是客观的。这是一个工具。与任何工具一样，它在某些情况下会发挥作用，但在其他情况下却会产生阻碍。知道如何区分是时装工程决策与简历的区别所在。

什么是微服务，用一句诚实的话来说

微服务是将系统组织为一组小型且独立的服务的方式，每个服务负责一项业务功能，并通过定义良好的接口进行通信。

相反的是[单体0：一切都在单个应用程序、单个进程、单个部署中。两者都没有本质上的正确或错误。区别在于每一个都有意义。在日常使用案例中，这种差异变得显而易见。

最常见的情况是应用程序的某一部分比其他部分的需求量大得多。

考虑一个电子商务应用程序。产品搜索收到大量请求；用户注册，几乎什么都没有。在[单体]中，你被迫一起攀登所有东西，你为闲置容量付出代价，只是因为搜索需要喘息空间。

通过将搜索分离到其自己的服务中，您只需在需要时扩展所需的内容。在日常生活中，这会转化为基础设施和弹性节省：搜索量的激增并不会降低结帐率。这是微服务收回成本的情况之一。

当团队成长并开始被自己绊倒时，就会出现另一种情况。

在一个大型[单体2]中，几个人更改相同的代码，部署变成一个队列，一个角落的更改会破坏远处的另一个角落。生产力的下降不是因为缺乏人才，而是因为过度耦合。

当您将系统划分为与域、支付、目录、通知一致的服务时，每个团队都拥有自己的服务，按照自己的节奏进行部署，并减少对其他团队的干扰。在日常生活中，这意味着以更少的协调来更快地交付。它既是一种组织用例，也是一种技术用例。

您知道，当“代码就绪”和“代码投入生产”之间的时间延长时，就会出现这种情况，因为团队必须互相等待。这种协调摩擦就是症状。在这里，微服务购买了自主权。

在某些情况下，系统的各个部分具有不同的技术需求，迫使它们进入同一堆栈会适得其反。

图像处理服务可以受益于面向性能的语言。业务规则服务可能要求生产力。数据组件可能需要专门的数据库。在[monolith3]中，你为所有事情选择一个堆栈，并在每一端做出让步。

微服务允许您为每项服务使用正确的工具。在日常生活中，这可以避免变通办法并提高重要的性能。这是一个强有力的案例，也是一个危险的案例，因为太多的技术多样性会成为维护的噩梦。谨慎使用。

一个不太明显的用例是风险隔离。

在某些功能至关重要而另一些功能不那么重要的系统中，将所有功能放在一起意味着愚蠢的故障可能会破坏必需的功能。想象一下一个公共卫生调度服务应用程序：管理报告模块在任何情况下都不能推翻公民的调度。

将关键部件与附件分开可以限制损坏半径。如果报告卡住，调度将继续。在公共部门，服务的连续性是对公民的直接责任，这种隔离不再是一种奢侈，而是成为一项项目要求。

成熟需要认识到这种架构造成损害的情况。

对于拥有精干团队的小型早期产品来说，微服务几乎总是矫枉过正。您会遇到分布式系统的复杂性、网络不稳定、数据一致性困难、分散的[可观测性4]，但没有它们解决的问题。初创公司花费数月时间整合数十项服务来为一百个用户提供服务的情况很常见。这不是复杂，这是自我破坏。

分布式复杂性是真实存在的。在[单体5]中微不足道的调用在服务之间变成了可能失败、有延迟并且需要错误处理的网络调用。调试跨五个服务的问题比使用单个代码要困难得多。该费用是永久性的，您每天都要支付。

谨慎的规则：从整体开始，内部组织良好，当具体用例（如上面的用例）实际出现时迁移到[微服务6]。建筑应该追随问题，而不是时尚。

微服务并不是现代性的奖杯。它们是对特定问题的回应：规模不平等、团队相互竞争、技术需求不同、需要隔离的风险。当这些案例出现在你的日常生活中时，它们就会闪闪发光。如果没有，它们只会增加重量。

好的工程不会问“什么是最先进的架构？”问“我现在遇到什么问题以及解决它的最简单方法是什么？”微服务很多时候是正确的答案，很多时候也是最昂贵的项目错误。

如果您正在决定是否值得拆分系统，则值得首先查看操作的实际症状。我在博客上还有其他关于架构、可扩展性和单体与 [微服务7] 的文章，如果你想考虑一下你的案例，这是一个很好的对话。