这个问题不是代码，而是与体系结构有关。
在Web应用程序中构建微服务时，您将需要以某种方式公开该服务并使之可访问。
我知道的方式：
所以我的问题是，如果我有一个正在运行的微服务，例如以事件驱动的方式连续收集数据，将端点添加到该微服务是一个好主意吗？我的争执是我对RESTFul API的理解是，如果没有请求，则该API应该空闲并且不执行任何操作，这将实现基于请求的可伸缩性。
如果我向已经基于事件驱动程序运行代码的微服务添加RESTFul API，则微服务可以通过两种方式接收工作负载，一种是API请求，另一种是来自实际计算部分的事件。服务。
比方说，我有一个微服务，可从Twitter阅读推文。该服务将推文流化，这意味着每次发布推文时都会触发事件。为了简单起见，假设服务将接收到的推文保留在RAM中，并且不将其存储在任何类型的数据库中。现在，该服务的RESTFul API部分应该通过允许用户请求收集的tweet列表来公开tweet。
在这种情况下，可以从两个方向接收工作负载：发布推文或用户请求推文。
在我看来，这是一个可扩展性问题，因为您必须注意微服务的两个不同方面。
关于此主题是否有普遍共识？
答案 0 :(得分：1)
将端点添加到此微服务中是一个好主意吗？
从我的角度来看，并从体系结构的角度来看，如果事件驱动的服务与服务域保持一致，则事件驱动的服务公开其余端点不是问题，但是您需要考虑一些方面：
扩展服务变得更加复杂，因为您需要检查两个值来触发扩展过程：请求数（从服务的REST角度）和内存消耗（从事件驱动的角度）服务方面）。
即使您的内存消耗很少，但请求数量却很多，也许在扩展时，服务，处理器和/或存储的其余部分也会有较大的内存占用...或者相反，在事件驱动的服务方面，您有大量的内存消耗，但在请求量很少的情况下，一侧（REST或事件驱动器）的重量将成为总占用空间的一部分。
针对您提出的问题，我认为，更加统一的解决方案是将您的服务分为两部分（两项服务），一项专门用于读取（其余一项），另一项专门用于写入（事件驱动一项）。这种情况下，您可以根据其内存，处理器，请求或存储需求独立地扩展这些组件。
此描述的场景由称为CQRS的模式覆盖，您可以在此处查看：https://martinfowler.com/bliki/CQRS.html
关于此主题是否有普遍共识？
共识...很难说，您将看到一些可用于解决此场景的模式，一种比其他模式更正确的...服务治理的组织方面...环境方面的因素等等...我认为，一个好的解决方案是将两个服务中的责任分开。