6

我有一个相对较新的项目，它采用了微服务架构。除了我们的安全服务之外，我对各个服务的大小和粒度感觉非常好。

我有三个主要服务，比如说foo-service、bar-service和baz-service。这些服务从不需要通信，但所有三个服务都会定期通过 HTTP 请求与security-service. 我希望这停止有多种原因 - 最大的原因是对我的个人服务的每个请求都会产生对安全服务的请求，一旦考虑到负载平衡等，它可能会变成几个额外的跃点。我一直在阅读Mark Richards 的“软件架构模式”，他建议在这些情况下您应该共享数据库并违反 DRY：将所需的功能复制到每个服务中。尽管如此，他还是将这个示例与较小的“实用程序”类一起使用，这可能并不真正适用于这种情况。

安全服务并没有那么大，所以我绝对可以将它复制到其他每个服务中。也就是说，它足够大，以至于复制和粘贴它时我感觉不太好——根据工作服，有 314 行“相关”代码（java 所以有更多实际代码；-）。我可以很容易地把它变成一个模块，每个服务都会引入——但是我的服务有一个共享的依赖关系，这在过去一直困扰着我。当然，随着我们添加身份验证方法，安全代码会随着时间的推移而增长，但在身份验证方面我们并没有重新发明轮子，所以它主要与其他库和身份验证服务集成。也就是说，我不认为这个特定的代码库会变得庞大。

所以我的问题是，我应该复制并粘贴代码还是构建每个服务都引入的模块？谢谢！

4

3 回答 3

4

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

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

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

速度（性能）在这里可能会胜出，具体取决于需求，但它会伴随着开发成本的增加。

如果您确实将安全逻辑移动到其自己的可重用模块中，该模块可以从其他服务中调用，只需做好封装工作并遵循基本的损失耦合紧密内聚设计。此外，由于您可能需要在未来几年内为这个决定辩护，所以请好好解释一下，这样当您未来的老板问为什么更新我们的安全逻辑要花这么多钱时，她就不会解雇您。有现成的基准，人们撒谎，数字没有。我曾经有一个我请求的新数据库的一页基准测试结果。不同的人多次问我为什么选择新的数据库……我只会给他们发一页，然后再没有听到那个人提出任何进一步的问题。

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

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

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

于 2015-05-12T18:06:54.347 回答
1

如果你将安全逻辑嵌入到其他服务中，那么你现在真的不能称它为微服务架构吗？我也明白，为所有其他服务提供额外的和重复的服务器往返可能有点拖累。这里有一些可行的替代方案供您考虑。

将所有这四个微服务放在防火墙后面。公开一个面向公众的服务，该服务使用安全服务来验证传入请求，然后如果请求对给定凭据有效，则调用其他服务。其他服务始终信任调用者，调用者是在您的受信任环境中拥有和运行的服务。

如果这是一个“即发即弃”的用例，并且您对面向公众的服务有太多的编排责任感到不舒服，那么请考虑这种替代方案。面向公众的服务将入站请求发送到消息代理中的未授权队列。安全服务从该队列中消费并执行身份验证。如果有效，则安全服务将消息排入授权队列。之后的任意数量的微服务从授权队列中消费并执行它们各自的操作。

于 2015-06-07T00:05:00.417 回答
0

Security as a separate service that you need for every request as you describe it is an extremely bad idea. May I refer you to the basic ideas of modularisation that Parnas described so eloquently in On the Criteria To Be Used in Decomposing Systems into Modules . No coupling also means no cohesion, and engineering is about finding the sweet spot on that axis.

Contrary to popular belief, micro-services need to be rather large to be able to scale. The limits to scalability are mostly in communications, so they need to be designed to not be chatty. The problem is mostly (unless you're netflix) not bandwidth but delay.

Your security module needs to be closer to your services than a HTTP request, a linked-in module can be fine.

于 2016-01-29T11:01:09.793 回答