最近在开发公司产品的核心主业务,因为此业务需要串起多个子应用,子应用都已经独立部署,而且拆分的独立应用非常多。比如企业任务子应用,订单子应用,任务执行总控应用(内含很多个子任务执行子应用),签章子应用,支付子应用,未来还有核算子应用,报告子应用。
在这样一个核心业务中的各相关应用调用中,有可能中断被介入,也可能部分必须同时完成,也可能应用宕机等情况。笔者之前一直做单体应用,刚从事互联网业务,才面临这些问题。如何把这些服务合理的整合在一个业务场景中,这是我一直在思考的一个问题。
虽然第一个版本已经上线了,但时间仓促,在目前的进一步重构优化中,需要很好的把握多个微服务的调用。虽然网上很多微服务编排的文章,还有多个微服务的分页式事务,但貌似不解决我的业务问题,还有些文章一知半解,到处复制。最近又看到网上的两个文章,基本上心里有思路了。
[size=large][b]一、(微)服务相关概念与关系[/b][/size]
标题中的编排与编制来自后面附的文章。
“编制的英文是Orchestration,本意是乐队指挥。微服务的编制强调的是通过一个可执行的中心流程来协同内部及外部的服务交互。通过中心流程来控制总体的目标,涉及的操作,服务调用顺序。”
“编排的英文是Choreography。微服务的编排强调的是协作,通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的,没有集中的控制。”
提到微服务技术,少不了以下一些概念,先分成几类:
[list]
[*]与外部有关的概念:注册、发
在这样一个核心业务中的各相关应用调用中,有可能中断被介入,也可能部分必须同时完成,也可能应用宕机等情况。笔者之前一直做单体应用,刚从事互联网业务,才面临这些问题。如何把这些服务合理的整合在一个业务场景中,这是我一直在思考的一个问题。
虽然第一个版本已经上线了,但时间仓促,在目前的进一步重构优化中,需要很好的把握多个微服务的调用。虽然网上很多微服务编排的文章,还有多个微服务的分页式事务,但貌似不解决我的业务问题,还有些文章一知半解,到处复制。最近又看到网上的两个文章,基本上心里有思路了。
[size=large][b]一、(微)服务相关概念与关系[/b][/size]
标题中的编排与编制来自后面附的文章。
“编制的英文是Orchestration,本意是乐队指挥。微服务的编制强调的是通过一个可执行的中心流程来协同内部及外部的服务交互。通过中心流程来控制总体的目标,涉及的操作,服务调用顺序。”
“编排的英文是Choreography。微服务的编排强调的是协作,通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的,没有集中的控制。”
提到微服务技术,少不了以下一些概念,先分成几类:
[list]
[*]与外部有关的概念:注册、发