微服务扩展/插件架构

Posted 2023-03-09

【中文标题】微服务扩展/插件架构

【英文标题】：Microservices extensions/plugins architecture

【发布时间】：2020-11-07 10:13:52

【问题描述】：

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

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

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

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

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

【参考方案1】：

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

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

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