微服务架构 - 跨域干扰

Question

我有一个采用微服务架构的相对较新的项目.除了我们的安全服务之外,我对各个服务的大小和粒度感觉相当不错.

我有三个主要的服务,让我们说foo-service,bar-service和baz-service.这些服务从不需要通信,但所有这三种服务都经常通过HTTP请求与之通信security-service.我希望这种情况因各种原因而停止 - 最大的问题是每个对我个人服务的请求都会产生对安全服务的请求,一旦你考虑到负载平衡等问题就会变成几个额外的跳跃.我一直在阅读Mark Richards撰写的"软件架构模式",他建议在这些情况下,您应共享数据库并违反DRY:将所需功能复制到每个服务中.不过,他将此示例用于较小的"实用程序"类,这可能不适用于此实例.

安全服务并不是那么大,所以我绝对可以将其复制到其他每个服务中.也就是说,它足够大,以至于我感觉很难复制并粘贴它 - 根据工作服的314'相关'代码行(java所以有更多的实际代码;-).我可以很容易地把它变成一个每个服务带来的模块 - 但是我的服务有一个共享的依赖关系,而且过去一直困扰着我.当然,随着我们添加身份验证方法,安全代码会随着时间的推移而增长,但是当涉及到auth时,我们并没有重新发明轮子,所以它主要与其他库和身份验证服务集成.也就是说,我不认为这个特定的代码库变得巨大.

所以我的问题是,我应该复制并粘贴代码还是构建每个服务带来的模块？谢谢!

Answer 1

我希望这种情况停止有多种原因 - 最大的原因是对我的各个服务的每个请求都会产生对安全服务的请求，一旦考虑到负载平衡等，这可能会变成几个额外的跃点。

作为单独服务的优点：
- 安全业务逻辑的更改仅影响安全服务，不需要更改客户端服务。

将安全逻辑转移到客户端服务的优点：
- 速度/性能。
- 减少一项需要管理的服务可能意味着运营成本的降低。

速度（性能）在这里可能会更重要，具体取决于需求是什么，但它会增加开发成本。

如果您确实将安全逻辑移动到自己的可重用模块中，该模块可以从其他服务中调用，只需做好封装它并遵循基本的松耦合紧内聚设计即可。另外，由于您可能需要在未来几年内捍卫这一决定，因此请有一个好的解释，以便您未来的老板在询问为什么更新我们的安全逻辑要花这么多钱时不会解雇您。有现成的基准，人们会撒谎，但数字不会。我曾经获得过我所请求的新数据库的一页基准测试结果。不同的人多次问我为什么选择新的数据库......我只会向他们发送一页，再也没有听到那个人提出任何进一步的问题。

该视频可能会让您在逆势而行方面感觉更好： https://www.youtube.com/watch ?v=StCrm572aEs

它展示了 Netflix 如何以及为何逆势而上，没有为其 API 采用 REST 架构。基本上，架构是需求和成本的客户，而不是相反。

编辑：作为服务离开的另一个大优点是您可能必须为每种支持的语言创建多个模块。在我的工作中，我们的安全服务被多种语言的客户服务所使用。