基于域/业务功能，将整体架构分解为许多微服务。
此整体式架构具有管理仪表板，用于更新整体式架构中的配置和功能标志。通过配置，我的意思是需要从管理控制台频繁更新的域级别配置。
问题是我们如何将这些管理员控制的配置从整体式数据库中移出。
两种思想流派：
>
集中配置：我们制作中央配置服务来保存所有配置和功能数据。它有一个与现有管理 UI 集成的 API 层。管理 UI 调用这些 API 来更新数据。其他微服务最终使用事件从此处同步。优点：更易于管理 缺点：数据在服务边界之外，数据仍然像在整体式架构中一样耦合。
我们根据配置及其应属于的位置拆分每个微服务要维护的配置。来自这些微服务的数据通过事件流向中心服务。管理 UI 调用此中心服务。优点：微服务拥有自己的配置 缺点：难以维护
让我知道您将如何解决这个问题？
您已经指出了每种方法的优缺点。
但是，还要记住，微服务体系结构的目标是您应该能够彼此独立地交付和部署服务。此外，开发团队应该能够独立于其他服务实现服务。
那么，微服务最终是否会在未来添加或删除一些配置设置呢？如果发生这种情况，则必须在方案 1 中同时更改该服务和配置服务，但在方案 2 中则不更改。
另一方面，如果设置本身永远不会更改，并且您仅在操作期间更改其内容，则可以决定接受耦合（即使这不再是纯微服务体系结构）。
顺便说一句：Spring有一个Spring Cloud Config Service，用于管理分布式系统的属性（其他文章在这里）。这似乎主要用于为不同的环境（例如开发、测试、生产）保留配置，但您可能会感兴趣。
在单一责任原则的最佳表达中，每个服务将维护自己的配置，并通过管理仪表板提供自己的可配置性。
“提供其自身的可配置性”将使用控制反转来实现。每个服务都会向仪表板服务注册导航信息和回调终结点（可能在部署时），然后管理仪表板将在运行时调用这些入口点，以生成仪表板，其中包含从所有这些服务聚合的组件。
回调终结点可以提供架构 CRUD 操作，允许仪表板合成自己的 UI，或者如果服务需要自定义 UI 进行配置，则允许 HTML 小组件。
