我想计划一个管理我的架构中丰富数据的解决方案.
更清楚的是,我有几十个微服务.
让我们说 - 国家,建筑,地板,工人.
全部运行在单独的NoSql数据存储中.
当我从工作服务获取数据时,我想要提供楼层名称(工作人员正在处理),建筑物名称和国家名称.
解决方法1.
客户端将查询所有微服务.
问题 - 多个请求并使客户端了解结构.
我知道多个请求不应该打扰我,但我相信在一次调用中返回描述实体的json更好.
解决方案2.
创建一个从多个服务检索数据的业务流程.
问题 - 如果数据(例如实体名称)未存储在DB中的同一文档中,则很难按这些字段进行排序和筛选.
解决方案3.
在保存实体(例如worker)之前,调用所有其他服务并填写相关数据(建筑物名称,国家/地区名称).
问题 - 更改建筑物名称时,它不会反映在工作服务中.
解决方案4.
(这是我能想到的最好的一个).
创建订阅代理并接收所有实体更改的流程.
对于每个实体,它更新所有相关实体.
当实体发生变化时,假设建筑物名称发生变化,它会更新所有包含建筑物名称的文件.
问题:每个服务都必须知道可以更新的内容.当发生尾随更新时,它不应该再次更新代理(递归更新),因此这可能会使微服务复杂化.
解决方案5.
保持一切正常化.在ElasticSearch中进行文件管理和排序.问题:在ES中保持规范化数据在性能上太昂贵了
很难在解决方案 N 级别上提供建议，但可以通过以下建议来避免某些问题：
使用实体的全局唯一标识符。例如，通过为某种 URI 分配键值。
全局 ID 还简化了更新，因为您可以跟踪实际更改的内容、名称或实体。（实体与全局URI具有一对一的关系）
CAP 定理说你只能从 CAP 中选择两个。您想要 CA 架构吗？还是CP？或者也许是美联社？这将强烈影响您分发数据的方式。
对于“排序和过滤”，有 MapReduce 方法，它可以分配计算这些事情的负载。
仔细考虑规范化/非规范化的平衡。如果您的服务在 URI 上运行，您可以拥有将 URI 转换为标签（名称、描述等）的服务，但您不需要到处保留冗余信息并更新它。不要做初步优化，但尽量保持数据标准化。这样，工人甚至可能不需要建筑物名称，但它是全局 ID。该微服务从另一个微服务查找元数据。
换句话说，作为关注点分离的一部分，最大限度地减少服务之间共享的密钥数量。
重点关注底层模型，而不是往返的 JSON。对系统中的数据进行正确建模比节省 JSON 调用更有价值。
至于NoSQL，看看Riak数据库：它具有可调整的CAP属性，IIRC。即使您不这样使用它，阅读它的文档也可能有助于为您的分布式微服务系统找到合适的架构。（当然，如果您有本质上并行的系统，这适用）
| 归档时间： |
|
| 查看次数： |
2435 次 |
| 最近记录： |