我目前正在为我的公司(物流公司(设计微服务方法。现在，我们有一个带有单个关系数据库的单片系统。
我理解微服务拥有独立数据库的方法。不幸的是，我不知道如何管理不同服务中所需的数据。也就是说，在开具发票、预订、路径查找等方面都需要关于地理层次结构的数据。它描述了世界上任何地方的层次结构(即，有一个城镇位于一个县，该县位于一个州，该国位于一个大陆(。在我看来，这些数据不属于上述任何一项服务，而是任何一项所需的。
我该如何处理此类数据？
我可以想象的一个解决方案是为这些数据提供自己的微服务，但这与按功能而非服务划分服务的领域驱动设计理念不一致。
有人能帮我吗？
在做出决定时，您需要考虑如何更新和更改这些数据。
假设偶尔需要更新这些数据(例如新市镇(，那么管理这些更新的责任对于包含地理层次权威数据库的独立服务来说是一个非常好的候选者。
然后，您可以选择其他服务如何获得所需的地理层次结构数据。
-
他们可以针对地理层次结构服务进行查询，但这意味着该服务的不可用意味着他们无法实现目标。这些服务与地理层次结构服务深度耦合。
-
或者，地理层次结构服务可以发布描述地理层次结构变化的事件：其他服务订阅这些事件，并更新自己的本地模型，该模型包含他们实现目标所需的地理层次结构数据。因为这些数据与他们需要的其他数据一起存储，所以它将与他们拥有的其他数据一样可用；地理层次结构下降只意味着没有更新。像Kafka或Pulsar这样耐用的日志结构存储系统非常适合事件发布。
第二种方法确实需要明确处理最终的一致性问题(在一段时间内，并非所有服务部门都同意当前的地理等级制度，就像在现实世界中有一段时间，一些地图只有一个南斯拉夫，而另一些地图则有斯洛文尼亚/克罗地亚/波斯尼亚/塞尔维亚/黑山/科索沃的子集(，但在第一种方法中也有类似的问题(考虑一下当更新发生在查询之后，但在查询器完成对结果的使用之前(进一步：考虑缓存…((，这被掩盖了。
第二种方法的一个优点是，由于地理层次结构服务只需要进行更新，所以它不必总是在运行。
如果数据几乎永远不会更新，那么也值得考虑将其作为可以加载到各种服务中的静态配置数据。这并不能避免最终的一致性问题(除非你愿意在更新时关闭使用地理层次结构的每个服务(，但它可能会节省数据库的成本(无论你将其存储在哪个版本控制或配置管理中，实际上都是数据库(。