过早优化_过早的微服务

过早优化

从一开始就构建您的应用程序，因为微服务不是一个好主意！ 无论您的微服务基础设施多么出色，它们的部署都很复杂。 它们在您的应用程序中创建了抵抗变化的边界。 软件应用程序是复杂的系统，而复杂的系统并非设计成的。 为了发展高效的系统，我们必须让其朝着需要的方向发展。 当增长的方向最不可预测时，一开始设计的边界将使该增长在某些轴上受阻。

整个系统的测试也非常麻烦。 有人可以辩称，应该对服务进行足够的解耦，以使在需要运行所有服务的应用程序中进行的测试保持在最低水平。 当然可以，但以我的经验，即使进行最少的测试也是一种痛苦。 尽可能长时间减轻或完全避免的疼痛。

那么为什么我们要这样做呢？ 为什么微服务器如此引人注目？ 隔离变更的前提非常有吸引力。 我们都被“巨石” st住了。 我们查看系统并看到变化的热点，然后想知道：“如果仅将那些热点隔离开，以便在它们发生变化时我不必重新部署整个系统”或“如果仅需重新设计此部分而无需是的，基于微服务的体系结构可以帮助您实现这一目标（记住！我说过，在项目开始时，这是一个坏主意，而不是一个坏主意。），但是这时您已经了解了其中的热点该应用程序和您对该域的了解已经成熟。 我的问题是在我们应用程序的不同方面之间建立牢固的界限。 如果理解发生变化，并且某些界限不再有效，那么这些抵制就会发生变化。 由于不容易更改边界，因此它使人们不敢质疑已经划定的边界。

一个想法

那么，至少在开始时，我们是否可以在不必划定界限的情况下进行微服务？ 就像生活中的任何事情一样，它并不是那么简单。 从弱到强–我们可以使用类/模块，接口/协议，包/命名空间，子项目，库和过程来画出这些界限。 常规微服务的问题在于，我们直接进入流程级别以画出边界，这是可以分离系统的最强级别。 但是，边界越弱，由于依赖关系就会泄漏，您将不得不做更多的工作来加强该边界的机会就越大。 但是同时，较弱的边界更易于重新定义。

如果我们继续处理边界但将边界明确，该怎么办？ 例如，我们将系统分为多个组件，这些组件仅允许像我们的微服务一样通过定义明确的接口相互通信，但它们都在同一进程中运行。 可以将其序列化为特定的东西，例如JSON或更抽象的交换格式。 可以将代码分成顶级程序包，以确保模块之间没有直接的二进制依赖性。 这样模块就可以真正地彼此传递消息，就像老式的老式面向对象编程一样。 我们必须确保模块之间没有直接依赖关系，例如共享代码，共享内存或共享数据库表。 使用版本库可以重用代码。 这将使我们能够在代码库中的模块之间保持明确的边界，这些边界足够强大，可以在需要时将各个模块提取到自己的微服务中，但也足够脆弱，可以在需要时轻松更改它们。 即使是这样的划分，一开始也不是很理想，我们可能会从一个单一的组件开始，直到至少划分为两个部分的程度。

结论

因此，建议（如果您还没有猜到的话）是，我们应该以最小的假设和限制启动系统，然后感知系统以了解其需要去的地方。 微服务可能是目的地的愿景，但我们不应该试图猜测目的地，甚至不应该计划行程。 我们应该感知和适应。 过早的抽象和边界将在某些领域淹没这种意义，导致系统无法像应有的那样全面发展。

翻译自: https://www.javacodegeeks.com/2016/01/premature-microservices.html

过早优化