微服务架构下，您是否常面临如下挑战？
网站编辑2020-09-29 12:01:39621
微服务架构下，您是否常面临如下挑战？1 通讯机制更为复杂
单体应用改造为分布式系统后，应用间的通讯机制及故障处理变得复杂。
2 系统应用之间依赖强
各个业务模组之间通过串联消息通讯，彼此之间相互影响且依赖性强，可用性差。
3 数据一致性难以保障
微服务化后，简单功能需要调用多个服务并操作多个数据库实现，数据一致性难以保障。
MQ事务消息，帮助实现类似 X/Open XA 的分布事务功能，达到分布式事务的最终一致。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
什么是事务消息？
通过消息的异步事务，可以保证本地事务和消息发送同时执行成功或失败，既能实现系统之间的解耦，又能保证数据的最终一致性，广泛应用于电商交易系统、支付红包等场景。
事务消息：消息队列 RocketMQ 版提供类似 X/Open XA 的分布式事务功能，通过消息队列 RocketMQ 版事务消息能达到分布式事务的最终一致。
半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到了消息队列 RocketMQ 版服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该询问过程即消息回查。
新用户 9.9 元尝鲜体验
