微服务消息传递数据库分配的标识符
我工作的公司正在研究从目前的单片API转向微服务。我们当前的API严重依赖于spring，我们使用SQL server实现大部分持久性。我们的微服务研究倾向于spring-cloud、spring-cloud-stream、kafka和polyglot persistence（每个微服务的独立数据库）。
人们是如何处理这个问题的？数据库分配的标识符是微服务中的反模式吗？我们是否应该公开返回数据库分配的标识符的单独的微服务endpoint，以便协调层可以在调用异步插入之前进行同步调用以获取标识符？我们可以使用UUID，但我们的DBA讨厌将其作为主键，并且它们不能用作订单号或其他面向用户的生成ID。
共有1个答案
如果可以在从消息源接收时以编程方式提前创建标识符，则可以将标识符作为消息头的一部分嵌入，然后在数据库插入期间和任何其他使用者中使用消息头信息。
但是这种方法需要其他使用者对数据库进行单独的验证，以便只处理提交的事务（如果您担心只处理插入）。
-
我听说亚马逊使用HTTP作为其基于微服务的架构。另一种方法是使用RabbitMQ或Solace Systems这样的消息传递系统。我个人对基于Solace的微服务架构有经验，但从未使用过REST。 知道像Amazon、Netflix、UK Gov等各种大联盟实现使用什么吗？ 其他方面是，在微服务中，还需要以下东西（除了其他东西）: *模式匹配 *异步消息传递。接收系统可能已关闭 *发布订阅 *缓存
-
我正在计划开发一个基于微服务的架构应用程序，当我阅读Ronnie Mitra的书《微服务架构》时，我决定使用Kafka进行内部通信；马特·麦克拉蒂；迈克·阿蒙森；伊拉克利·纳达雷什维利说： 让微服务直接与消息代理（如RabbitMQ等）交互很少是个好主意。如果两个微服务通过消息队列通道直接通信，那么它们共享一个数据空间（通道），我们已经详细讨论了两个微服务共享一个数据空间的弊病。相反，我们可以做的
-
我对尝试将微服务/SOA作为一种体系结构非常感兴趣，并且很难对服务之间的集成进行概念化。 我喜欢使用消息传递将客户端与服务分离的想法，但不理解系统如何独占地使用它。典型的异步操作和发布/订阅显然是有意义的——比如创建新订单、广播数据以进行报告等。我不明白的是，人们是否通常尝试在常见的请求/回复场景中使用消息传递——例如，用户点击他们的“个人资料”页面，而需要在页面上呈现的部分数据来自用户服务。 我
-
我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。 由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。 我们面临的最大问题是谁将负责微服务之间的事件共享。例如，
-
我知道消息传递系统是无阻塞和可扩展的，应该在微服务环境中使用。 我质疑的用例是： 假设有一个admin dashboard客户机负责发送API请求以创建Item对象。有一个微服务提供APIendpoint，它使用一个MySQL数据库来存储项目。还有一个微服务使用弹性搜索进行文本搜索。 如果此管理仪表板客户端： a.发送2个API调用；1次调用MySQL服务和另一个elasticsearch服务 或
-
如果一个微服务只知道它自己的领域，但是有一个数据流需要多个服务以某种方式交互，那该怎么做呢？ 假设我们有这样的东西： 为论证起见，假设一个订单发货后，就应该创建发票。 我确实知道这可以被认为是高度基于意见的。但它也有具体的一面，因为微服务不应该做上述的事情。因此，必须有一个“根据定义它应该做什么”，这不是基于意见的。 开枪啊。
-
新服务器密钥是否仅限于消息传递？ 说明：在firebase项目设置中，我可以获得“旧”和新服务器密钥（云消息选项卡）。旧版本无法通过发送推送通知https://fcm.googleapis.com/fcm/send 因为响应说它是一个遗留服务器密钥。但在这里，它可以被限制在某些谷歌API中https://console.developers.google.com/apis. 谷歌API控制台中没有
-
我需要一个用于谷歌云消息传递的示例应用程序。使用示例服务器来测试我的应用程序，任何人都可以帮助我吗？ 我需要一个样本服务器来测试我的代码，我已经写了代码，但我不知道它是否会工作。我不知道服务器端编码，所以任何人都可以在这方面帮助我。这是我的代码 意向服务 我的主要活动