微服务扩展/插件架构

Question

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

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

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

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

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