rest
处理事件
当使用多个解耦的服务时(例如，在微服务体系结构中)，很有可能需要一种将某种域事件从一个服务发布到一个或多个其他服务的方法。
许多广泛采用的解决方案依赖于单独的基础结构来解决此问题(例如事件总线或消息队列)。
活动提要
解决此问题的另一种方法是使用提要。 RSS或ATOM之类的提要通常用于订阅网页。 每当将新文章发布到订阅的网页时，提要阅读器应用程序(例如，浏览器插件或移动应用程序)都可以将新文章通知用户。 提要阅读器通常会定期轮询提供的提要端点，以查看是否有新文章。
可以使用提要将事件发布到其他服务，而不是将新文章发布到RSS阅读器。 除了用于存储事件(您可能已经拥有)的标准数据库之外，这不需要任何其他基础结构。
RSS和ATOM都是XML格式，因此如果我们要提供JSON API，则不合适。 还有JSON Feed ，类似于RSS和ATOM，但使用JSON。 像RSS和ATOM一样，JSON Feed专注于网站内容，因此，许多(可选)提要和提要项属性对于发布域事件(例如favicon ， content_html ， image ， banner和附件)不是很有用。 但是，JSON Feed具有简单的扩展机制，可让我们在Feed中定义自定义字段。 这些字段必须以下划线开头。 如果JSON Feed不能满足您的需求，您还可以提出自己的feed格式，这应该不难。
具有两个已发布域事件的示例JSON Feed可能如下所示：
{"version" : " https://jsonfeed.org/version/1 " ,"title" : "user service events" ,"feed_url" : " http://userservice.myapi.com/events " ,"next_url" : " http://userservice.myapi.com/events?offset=2 " ,"items" : [{"id" : "42" ,"url" : " http://userservice.myapi.com/user/123 " ,"date_published" : "2020-05-01T14:00:00-07:00" ,"_type" : "NameChanged" ,"_data" : {"oldName" : "John Foo" ,"newName" : "John Bar"}}, {"id" : "43" ,"url" : " http://userservice.myapi.com/user/789 " ,"date_published" : "2020-05-02T17:00:00-03:00" ,"_type" : "UserDeleted" ,"_data" : {"name" : "Anna Smith" ,"email" : "anna@smith.com"}}]}
第一个事件(ID为42 )指示用户资源/ user / 123的名称已更改。 在_data块中，我们提供了一些可能对订户有用的附加事件信息。 第二个事件表明资源/ user / 789已被删除， _data块包含已删除的用户数据。 _type和_data没有以JSON Feed格式定义，因此以下划线(JSON Feed扩展格式)开头。
提要属性next_url可用于提供某种分页。 它告诉客户端在当前提要中的所有事件都已处理后，在哪里可以查找更多事件。 我们的提要仅包含两个事件，因此我们告诉客户端使用偏移量参数2调用提要端点以获取下一个事件。
一般注意事项
如果您使用JSON Feed或使用自己的Feed格式，则在构建用于发布事件的Feed时应考虑以下一些常规事项：
提要项是不可变的
提要项表示域事件，它们是不可变的。 必要时，客户可以使用唯一的Feed项目ID来检查他们是否已经处理过Feed项目。
Feed项目订单未修改
提要中项目的顺序不变。 较新的项目会附加到Feed的末尾。
客户应该只能请求到目前为止尚未处理的提要项。
为避免客户需要一遍又一遍地处理所有提要项以查看是否有新项(例如，通过检查date_published项属性)，提要应提供一种仅返回新项的方法。 使用JSON Feed时，可以通过next_url属性完成。
下图试图显示可能的next_url行为：
在第一个Feed请求中，只有两个事件可用。 两者均由服务器以及包含偏移量参数2的next_url一起返回。客户端处理完两个提要项目后，客户端将使用偏移量2请求下一个项目。没有新项目可用，因此没有内容的空提要服务器返回一个新的next_url 。 客户端会记住先前的next_url，并在稍后再重试该请求。 这次返回的是新项目，其更新的next_url包含偏移量3。
当然，您可以想出不同的方法来达到相同的结果。
和性能？
显然，从性能的角度来看，提要不能与任何高吞吐量的消息传递解决方案竞争。 但是，我认为对于许多用例来说就足够了。 如果它降低了系统的复杂性，那可能是一个值得权衡的问题。
要考虑的事情是：
- 服务器创建的事件数
- 供稿订户数
- 与事件关联的数据量
- 事件发布和处理之间的可接受延迟。 这定义了订户的轮询间隔
由于域事件具有不变性，因此可以在服务器上选择使用事件缓存来减少数据库查找。 长轮询和条件GET请求是减少网络负载的可能选项。
结论
提要提供了一种使用REST API将事件发布到其他系统的替代方法，除了用于存储事件的数据库外，无需其他基础结构。 您可以使用现有的Feed格式(如JSON Feed)，也可以使用自己的自定义Feed格式。
由于提要的轮询性质，如果您有大量事件和很多消费者，则此解决方案可能不是最佳选择。
翻译自: https://www.javacodegeeks.com/2020/05/rest-using-feeds-to-publish-events.html
rest
