微服务扩展/插件架构

Question

我们正在构建一个基于微服务的平台。该平台将提供许多将用于各种独立项目的基本功能。我们需要提出这样一种架构，使我们能够扩展基本功能并与现有服务进行交互。主要任务是确保主要服务的代码保持不变，并且基于平台的自定义解决方案可以轻松复用。

我们正在考虑几种选择。例如，有一个服务“foo”提供了函数 foo1 和 foo2。为了扩展功能，我们可以创建一个独立的“foobar”服务并将其放在foo服务的前面，接受API请求，执行自定义函数，然后将请求重定向到foo。它是一种中介服务，它充当特定项目和主平台特定功能实现的主要环节。这种方法的优势可以归因于完全独立于基本服务的代码库。而主要的缺点是实现的复杂性和需要对主要服务的功能进行极大的碎片化。

正在考虑的第二个选项类似于单体应用程序中经常使用的方法 - 钩子系统，它允许您覆盖系统的行为。例如，您可以创建一个独立的服务来连接事件和订阅者。这种方式比较灵活，但同时实现起来还是比较困难的。这种方法的主要缺点是同步阻塞网络调用。

我们正在考虑的第三个选项是构建微服务本身，这样可以向它们添加额外的模块，以便可以在构建阶段定制服务。主要代码保持不变，但在流程内部，实现了已经提到的钩子和事件方案（在单个服务的代码级别）。好处是易于实施。在缺点中，在涉及多个服务的情况下很难实现定制。

也许我们正在尝试发明一辆自行车，并且有很好的解决方案。如果您知道这样，或者您对解决此问题的可能方法有很好的想法，请分享。

Answer 1

我认为这个普遍问题没有答案。第三种解决方案似乎相当不错。您可以利用责任链或请求响应管道范例来非常轻松地实现开放/封闭原则。这应该确保您可以在 foo 服务中添加/修改功能，而无需触及现有代码。

如果您正在寻找解决整个架构而不是单个微服务的问题，您可能想看看事件驱动的微服务设计。

此设计方法与选项 2 类似，不同之处在于它使用消息代理和异步通信来让微服务进行通信。有很多优点，例如更高的弹性和服务的解耦。