捍卫巨石

最新推荐文章于 2024-10-10 23:42:47 发布

danpu0978

最新推荐文章于 2024-10-10 23:42:47 发布

阅读量49

点赞数

文章标签： java 大数据编程语言 python 人工智能

我参加的第一次微服务演讲是一年半以前。我的第一个反应是“为什么有些新东西？”。然后我意识到它已经被夸大了，所以我听了一些更多的演讲，阅读了更多的文章，因此我有充分的理由不喜欢这种炒作。

什么是微服务可能是在这里定义的，还是由Martin Fowler 定义的，或者在Google的第一个“微服务”结果中都定义了什么。它基本上是将您的功能拆分为可单独部署的模块，这些模块可以相互通信以实现业务目标，并且每个微服务都限于一个很小的，定义明确的范围。产品购买是一种微服务，用户注册是另一种微服务，“当前促销”是另一种微服务，依此类推。或者它们甚至可以更细粒度–似乎值得商bat。

每当遇到新的“事物”时，我都会尝试回答“重点是什么”和“这对我有用吗”的问题。我想指出的是，我不是拒绝任何新事物的人，因为事情可以“旧方式”完成，但是好的新技术/体系结构和炒作之间存在很好的界限。此外，微服务并不是什么新鲜事物。我记得几年前，当我们将一个应用程序拆分为几个与Web服务通信的部分时。当我加入时，我将其重构为一个“整体”，从而将响应时间缩短了约20％。事实证明，我们永远不需要拆分。

这就是我要写的原因-您可能不需要微服务。马丁·福勒（Martin Fowler）说得很好：

…甚至不要考虑微服务，除非您的系统过于复杂而无法作为一个整体来管理。大多数软件系统应构建为单个整体应用程序。请务必注意该整体中的良好模块化，但不要尝试将其分为单独的服务

在那里，完成。现在去建立一个整体。但是微服务的拥护者们不会同意，并会指出微服务架构的各种好处（或者会指出您的系统过于复杂，因此您必须使用微服务。并向他们支付咨询费用）。因此，让我们研究一下微服务具有的一些所谓优势（例如，该视频的 30:57左右）。我要问的问题是–这可以很容易地以整体方式完成吗？（我必须澄清，“整体”是微服务的对立面，例如一个代码库，一个部署。）

完全围绕业务领域建模。您可以围绕业务域构建程序包和运行时依赖项。
自动化文化–与体系结构无关–您可以自动化任何应用程序的部署。（例如，我们正在为整体进行自动化的蓝绿色部署）。
隐藏实现细节–这就是面向对象编程的目的。您的类和您的程序包将隐藏其实现细节并公开接口。微服务对此没有任何作用（网络开销除外）。您甚至还可以拥有多个项目，这些项目是作为主项目的依赖项而构建的。
分散所有事物–好的，无论您如何拆分，服务仍然在逻辑上耦合。一个取决于另一个。从这个意义上说，“去中心化”只是听起来不错，但实际上在这种特定情况下没有任何意义。也许是下一点的代名词。
独立部署和独立监视。仅凭这一点并不能给您带来任何好处，您可以在其中收集指标（例如，使用statsd）或获取有关每个类或包的性能分析和性能信息。
孤立的故障–现在可能是一件好事。如果一个模块“失败”，您可以显示“对不起，此功能目前无法正常工作”并处理失败。但是，整体也不必完全失败。重要的是失败的细节，而我从未见过任何详细的解释。服务器出现故障？好吧，无论代码的结构如何，您都有一个高度可用的群集。

声称具有更多，宽松定义的好处，例如“易于修改”和“易于理解”。但是，同样，编写良好，结构良好且经过测试的整体可以很容易理解和修改。

从根本上讲，许多常识，软件工程，持续集成/交付和基础架构管理最佳实践被认为是微服务的优势，而实际上，它们与整体服务完美结合。

适当降级的能力可能是微服务的一个重要方面，但是同样，您也可以使用整体来处理它-这将需要一点额外的代码-例如，如果在发生故障时进行切换的功能。但这与您为了获得有效的微服务应用程序而付出的额外努力相比无济于事。

这就是很多–您必须协调服务。您必须决定如何处理公用数据。通常的建议是“复制”。如果两个微服务需要一些公共数据，则它们不能仅使用相同的共享数据库–每个微服务都有自己的数据库，因此必须复制数据。听起来很容易，除非您必须保持数据同步。你总是要做的。而且，当您必须在5个微服务之间保持重复的数据同步时，开销可能会超出任何可能的优势。

另一个大问题是交易。您要么不需要事务（在这种情况下，您很幸运），要么您最终（如果可以引用Martin Kleppmann的话）是“临时的，非正式指定的，漏洞百出的缓慢执行一半事务” （这里是整个讨论交易）。

也不应低估微服务的通信开销，包括网络开销以及所有序列化和反序列化。在实践中很少见到我有争议的建议，即使用快速的二进制格式进行内部通信，而不是JSON / XML。

因此，我再次建议遵循Martin Fowler的建议，并保持整体状态。当然，请遵循最佳做法，包括：