说一说微服务开发中的设计要点

2023-01-10  本文已影响0人  天草二十六_简村人

一、背景

本文只讲述一些我们在实际开发和联调走过的弯路,在这里及时做个总结,所以不定期地更新。

当然,我们说的设计要点,都是针对重要的功能,切不可过度设计。

二、目标

三、设计要点

微服务团队中,我们往往是侧重于自己的业务实现,容易忽视其他团队,缺少全局思维。所以我们在做大型业务的开发设计,一定要有一个架构师对服务之间的协作做一个架构设计。

相信很多人都经常被其他团队的人追问,为什么两边的数据或状态不一致,当时的请求是怎么样的,为什么还没回调过来,等等一系列问题随之而来。

往往最后会抛出一句,你们服务最近有发版修改过这一块代码吗?

话外之音,问题不在他那,指向你这里。所以你得拿出证据,翻找日志和数据库,证明他是对的。

1、无处不在的任务

2、跨服务调用的日志打印

3、交互一定要形成闭环

4、本地日志表替代分布式事务

5、合理使用业务类型区分不同的业务

四、设计举例

4.1、无处不在的任务

有意思的是,我发现好多系统都定义了任务这么一个领域。或者说xx计划,其实也是一个“任务”。视频转换的请求,也可以看作是一个转换任务。延迟回调业务方,被看成是一个回调任务。明天上午9点要给一批私域用户发送sms短信,对于消息网关来说,就是一批发消息的任务。

要成为“任务”的前提是:该操作的结果是非实时的,允许一定的延迟。
而本文要讲的任务,可能还是耗时长的,可能是支持并发操作的。
调用方不仅可以查询任务的状态,且对已分发的任务进行重试。

下面举例说明:

下面总结下,既然这些业务都抽象出了任务这么一个领域,那么有哪些共性呢?

4.2、跨服务调用的日志打印

前提是非查询类的请求!! 这是解决跨服务之间调用的问题排查,从日志可以给出直接证据。

4.3、交互上的闭环

如果你对上面的支付流程所有了解的话,相信会对你业务对接中怎么做到闭环,会有相当大的帮助。

上一篇 下一篇

猜你喜欢

热点阅读