微服务架构中的可配置错误消息
Configurable error messages in microservice architecture
我们正在使用 microservice 使用 spring-boot 的架构。目前，我们正在根据特定条件在代码中创建消息。
我们希望通过将消息放在 database 中来使消息 可配置，以便可以从中心位置更改和管理它们。
我们有大约 8-9 个微服务，我们决定添加一个新的微服务（名为 commons-utils），我们将在其中创建一个数据库来放置所有消息。
因此，如果消息中需要更改，我们只需更新数据库即可。
我们可以在数据库中添加不同类型的成功和错误消息，以及 API 自定义响应消息，因为它们对所有微服务都是通用的。
例如
ID | Code | Messge
1 ORD0001 Order placed by Client: {ClientName}
2 ORD0002 Order Completed.
.
3 INV0001 Invoice generated for ordernumber: {Ordernumber}
.
11 NOT0001 Order accepted by Supplier: {SupplierName}
..
2.. A0001 Order was cancelled.
我们将在成功登录后获取所有这些消息并将其存储在 cache 中，这样就不会调用此 commons-utils 微服务来获取每条消息，然后根据代码并用所需的值填充它，然后发送它。
这就是我们心中的实现。我想知道有没有更好的方法。
提前致谢。
如果错误消息的数量可能会变得相当大，那么您尝试的方法似乎是最好的（支持您需要中央服务的要求）。休眠缓存机制可以为您提供良好的性能，即使您正在调用数据库来获取消息。
如果你没有。文件中的消息数可以 controlled/maintained，请使用配置服务器，因为它可以启动并且 运行 无需太多编码。请参考：
https://cloud.spring.io/spring-cloud-config/
这将允许您轻松使用不同的配置文件（对应于 dev、qa、uat prod 环境等），并且可以使用 git 管理属性。
这将帮助您开始使用配置服务器：https://spring.io/guides/gs/centralized-configuration/
但在这两种情况下，请记住，如果此服务出现故障，您的所有消息方案都会中断！
对我来说，每个微服务负责自己的业务逻辑和相关的错误消息更有意义。
因此“订单”微服务具有它可能面临的所有相关错误消息。
通过将所有错误消息放在一个地方，您可以在服务 X 和 commons-utils 之间创建耦合。这样服务 X 将无法在 commons-utils 知道此类错误之前发送错误。
这也会迫使您在添加新业务逻辑时进行多次提交（服务 X 中的一次提交和 commons-utils 服务中的一次数据库更改），然后同步它们的部署和发布。
我会将错误消息保存在每个服务配置文件中，它们紧挨着与之一起工作的代码。
这里有很多的注意事项。
首先（正如@riorio 所说），您要耦合微服务、前端和实用程序服务。微服务架构的主要好处是解耦业务领域，但你引入了依赖关系。
接下来，您可能希望使用国际化来管理显示给最终用户的字符串。这在几乎每个应用程序框架中都得到了很好的支持 out-of-the-box。
那么，你就要考虑微服务的架构目标了。每个限界上下文都是其自身的、连贯的、独立的业务领域实现。应用程序在这些上下文中编排它们的逻辑；每个应用程序都可以有自己的逻辑流。通过尝试在一个地方捕获消息，您最终会在那个数据库中定义那些逻辑流。消息在不同的上下文中可能会有所不同，并且通常具有相当多的附加信息。我会说 (front-end) 应用程序负责理解它自己的逻辑流程，以及随之而来的 end-user 消息。
最后，您的设计依赖于缓存来提高性能；缓存会带来复杂性，而复杂性会导致错误。您缓存的数据可能很少更改，而且可能仅在应用程序部署的上下文中更改 - 我不希望企业想要更改“订单已创建！”经常发信息。您现在必须处理缓存失效、测试缓存和管理缓存配置。
因此，这个问题没有正确或错误的解决方案，但您引入了耦合和缓存的复杂性，您正在集中应用程序决策，并且您没有使用“开箱即用”的方式来管理字符串.我不确定这些决定是否会得到好处的回报。
我们正在使用 microservice 使用 spring-boot 的架构。目前，我们正在根据特定条件在代码中创建消息。
我们希望通过将消息放在 database 中来使消息 可配置，以便可以从中心位置更改和管理它们。
我们有大约 8-9 个微服务，我们决定添加一个新的微服务（名为 commons-utils），我们将在其中创建一个数据库来放置所有消息。
因此，如果消息中需要更改，我们只需更新数据库即可。
我们可以在数据库中添加不同类型的成功和错误消息，以及 API 自定义响应消息，因为它们对所有微服务都是通用的。
例如
ID | Code | Messge
1 ORD0001 Order placed by Client: {ClientName}
2 ORD0002 Order Completed.
.
3 INV0001 Invoice generated for ordernumber: {Ordernumber}
.
11 NOT0001 Order accepted by Supplier: {SupplierName}
..
2.. A0001 Order was cancelled.
我们将在成功登录后获取所有这些消息并将其存储在 cache 中，这样就不会调用此 commons-utils 微服务来获取每条消息，然后根据代码并用所需的值填充它，然后发送它。
这就是我们心中的实现。我想知道有没有更好的方法。
提前致谢。
如果错误消息的数量可能会变得相当大，那么您尝试的方法似乎是最好的（支持您需要中央服务的要求）。休眠缓存机制可以为您提供良好的性能，即使您正在调用数据库来获取消息。
如果你没有。文件中的消息数可以 controlled/maintained，请使用配置服务器，因为它可以启动并且 运行 无需太多编码。请参考： https://cloud.spring.io/spring-cloud-config/ 这将允许您轻松使用不同的配置文件（对应于 dev、qa、uat prod 环境等），并且可以使用 git 管理属性。 这将帮助您开始使用配置服务器：https://spring.io/guides/gs/centralized-configuration/
但在这两种情况下，请记住，如果此服务出现故障，您的所有消息方案都会中断！
对我来说，每个微服务负责自己的业务逻辑和相关的错误消息更有意义。
因此“订单”微服务具有它可能面临的所有相关错误消息。
通过将所有错误消息放在一个地方，您可以在服务 X 和 commons-utils 之间创建耦合。这样服务 X 将无法在 commons-utils 知道此类错误之前发送错误。
这也会迫使您在添加新业务逻辑时进行多次提交（服务 X 中的一次提交和 commons-utils 服务中的一次数据库更改），然后同步它们的部署和发布。
我会将错误消息保存在每个服务配置文件中，它们紧挨着与之一起工作的代码。
这里有很多的注意事项。
首先（正如@riorio 所说），您要耦合微服务、前端和实用程序服务。微服务架构的主要好处是解耦业务领域，但你引入了依赖关系。
接下来，您可能希望使用国际化来管理显示给最终用户的字符串。这在几乎每个应用程序框架中都得到了很好的支持 out-of-the-box。
那么，你就要考虑微服务的架构目标了。每个限界上下文都是其自身的、连贯的、独立的业务领域实现。应用程序在这些上下文中编排它们的逻辑；每个应用程序都可以有自己的逻辑流。通过尝试在一个地方捕获消息，您最终会在那个数据库中定义那些逻辑流。消息在不同的上下文中可能会有所不同，并且通常具有相当多的附加信息。我会说 (front-end) 应用程序负责理解它自己的逻辑流程，以及随之而来的 end-user 消息。
最后，您的设计依赖于缓存来提高性能；缓存会带来复杂性，而复杂性会导致错误。您缓存的数据可能很少更改，而且可能仅在应用程序部署的上下文中更改 - 我不希望企业想要更改“订单已创建！”经常发信息。您现在必须处理缓存失效、测试缓存和管理缓存配置。
因此，这个问题没有正确或错误的解决方案，但您引入了耦合和缓存的复杂性，您正在集中应用程序决策，并且您没有使用“开箱即用”的方式来管理字符串.我不确定这些决定是否会得到好处的回报。