我正在计划一个使用事件源的微服务模型。为了实现高可伸缩性和高吞吐量处理能力，我将使用kafka作为微服务的消息代理。
在这一点上，我对Kafka模式的实施有疑问，能够对其进行有益的主题和划分。我的模型需要满足一些要求：
微服务必须从消息代理接收数据（post/patch/put/delete）
数据一致性是强制性的，如果实体a需要实体b的先前存在，则必须只存在指向实体b的有效记录的实体a的记录
微服务不能耦合他们的域（参考ddd）
系统必须处理高吞吐量的读写操作
好吧，考虑到这些要求，我最终得到了一个模型：
使用具有当前有效状态的elasticsearch数据库
所有写请求都由“微服务网关”接收，该网关：
验证请求和请求的新状态
在消息代理中生成写操作
从消息代理接收状态更改事件
以更改的新状态响应请求者
所有写操作都由“微服务处理器”使用，该处理器：
处理所有业务逻辑和数据非规范化
更新elasticsearch数据库中的状态
在消息代理中生成状态更改事件
所有读取请求都由“微服务网关”处理，该网关：
在elasticsearch数据库中搜索请求资源的记录
用结果响应请求者
我的问题：
这个模型做一些耦合的领域？网关正在验证子资源id，以确保一个elasticsearch数据库中的数据一致性（在a指向b的情况下）。
我不知道这个模型是否适合报表请求，有一些复杂的报表处理大量数据，并带有用户的输入参数，从他的Angular 来看，操作必须是“同步的”（请求/响应rest）
请求/新状态的验证是否是业务逻辑的一部分（与ddd相关）？如果是这样的话，我的模型将它们分为两个微服务是不正确的？
编辑
我对我的客户的新建议：
与其让网关充当微服务的一部分，不如让网关只用于：路由（微服务注册表）、平衡和身份验证（调用专用微服务进行身份验证/授权）
微服务拥有自己的数据/数据库，事件源架构确保了一致性
报告：如果是关于一个域的，可以是微服务中保存数据的资源，如果需要多个域，则另一个微服务将提供报告
1条答案
按热度按时间lvmkulzt1#
这个模型做一些耦合的领域？网关正在验证子资源id，以确保一个elasticsearch数据库中的数据一致性（在a指向b的情况下）。
你用以下句子回答了自己的问题：
所有读取请求都由“微服务网关”处理
如果这是真的，你的系统根本没有域分离。事实上，你有一个神之门，需要知道所有领域。
网关应被限制为特定于域的服务无法实现的专用目的（例如，安全性、路由/代理、负载平衡、整合、恢复能力等）。
我不知道这个模型是否适合报表请求，有一些复杂的报表处理大量数据，并带有用户的输入参数，从他的Angular 来看，操作必须是“同步的”（请求/响应rest）
我将报表视为一个独立的服务，理想情况下使用现有的服务来获取所需的任何信息。根据您的域和要求，您可能希望在您的服务中为此设置一些专用的非公共端点，或者您可能希望直接访问数据库（例如，通过对图形数据库的专门查询）。
请求/新状态的验证是否是业务逻辑的一部分（与ddd相关）？如果是这样的话，我的模型将它们分为两个微服务是不正确的？
这取决于验证的类型。为了从域的Angular 验证正确性，您需要相应的服务。如果您想验证系统的其他部分可能负责的其他事情（日志记录、授权、阻止恶意尝试等）
与其让网关作为微服务的一部分，不如让网关只用于：路由（微服务发现）、平衡和身份验证（调用专用微服务进行身份验证/授权）
关于这件事：
通常，您不会在api网关上执行实际的服务发现。相反，它应该是集群编排的一个函数（请参阅kubernetes如何为您做这件事）。网关只需使用服务注册表来正确代理（例如，使用正确的dns条目）。
microservices架构风格的发明是为了让非常大的组织能够扩展快速增长的服务器应用程序。它确实有缺点，尤其是在为需要快速取得成果的小型项目设置时。来自那些较大组织的大多数人都会告诉您，最初从一个整体开始，当团队变得太大时就分离出来（通过绘制组件边界，您可以在最初的开发中为这种分离做好准备）。即使使用“单片”服务，您仍然可以使用cicd拥有现代的构建/测试/部署基础设施，并且该服务仍然可以具有水平可伸缩性。因为我不知道你的领域/项目的规模，我只是想把它作为一个一般性的想法。