门店-中心分布式系统的问题解答
 |
凤舞凰扬
2011-05-22
Alexyin_sc 写道 LZ所述问题实际上是属于事务工作流所讨论的范围。
“中心系统进行修改或取消订单的时候,需要判断在业务规则控制下当前订单能否进行当前操作. 同样门店系统在进行备餐,送出等操作时也需要判断业务规则是否允许进行当前的操作. ” 这样的运行时控制有些问题，应该修改为：中心系统用户在特定时刻向引擎申请对订单的操作，引擎根据上下文返回用户可以发出的操作，如果其中包含修改或者取消操作，那么说明是允许的。在实际发出操作后，引擎应该再次验证操作的合法性（因为在申请操作和发出操作期间存在其它系统用户对订单进行操作的可能）。运行时，如果所有与订单相关的用户都照这种方式进行操作时，结果将不会产生冲突，或者说订单事务将正确执行。 顺便说一句，目前BPEL描述的过程模型还达不到这样的要求，WS-Transaction是一种基于补偿的事务模型，目前所能解决的问题范围还没有完全覆盖LZ所述问题。MQ只是应用层面上的一种具有可靠性保证的解决方法，与工作流事务几乎是正交的。 工作流事务有些复杂，但大多数情况下又必不可少，即使是OA，有些也涉及事务问题，现在关于这一问题的讨论已经引起相当的重视，LZ可以看看相关资料。 你谈到带结果不会冲突，是说明分部的用户也要对中心的引擎进行操作申请吧。呵呵，如果是这样，那就恐怖了。如果架构师这样设计系统，会被别人狠狠批的... Rich Client的存在其实包含两个目的，一个是客户端较强的人机交互应用，另一个则是相对独立的运行环境。（即算中心的系统无法访问，也不会对客户端产生毁灭性影响，只是订单暂时无法提交罢了，本身的系统一样可以运行）楼上丝毫不想一下，万一互联网有个什么问题，或者中心的系统软硬件（包括网络）出现任何一个故障，所有带门店都无法编辑修改订单会带来业务上多大的灾难性影响啊？ WS-Transaction包括两个部分，一个是原子事务，一个是业务活动。后者对于不支持两阶段提交的WS系统，采取的是如楼上所说的补偿性事务，但不是说WS-Transaction就只是补偿性事务。另外BPEL只是模型，而冲突的解决方案是两码事。我提出的问题是应用场景带问题，这里面包括事务一致性，包括数据集成，也包括业务流程的问题。不是单纯事务工作流的问题。 |
 |
Alexyin_sc
2011-05-29
“你谈到带结果不会冲突，是说明分部的用户也要对中心的引擎进行操作申请吧。”我有这样说吗？
 中心用户与中心系统的引擎交互，分店用户与分店系统引擎交互，中心系统引擎与各分店系统引擎各自独立， 通过服务来交换业务处理消息，这难道不是此问题讨论的前提？为什么会挨批呢？还狠狠批。。？有这种讨论氛围？难道非要先把异步通信这种N年前就有的东东先搬出来？这些应该是设计分布式系统时最起码的常识吧？  我说“WS-Transaction是一种基于补偿的事务模型”，并不意味着楼主理解的“WS-Transaction就只是补偿性事务”，只是想表达采用补偿机制是WS-Transaction的一大特色，使它区别其它众多的事务模型（包括它现在尚不能支持的预执行事务等） 。  确实，“BPEL只是模型”（严格地说是一种半形式化的过程模型描述语言），但个人认为它与冲突的解决方案并非完全就是两码事。在大多数实际的应用场景中，事务都是需要考虑的。业务过程中的事务问题非常有趣，真的。WS-Transaction只是涉及了其中的某些方面。 |
|
凤舞凰扬
2011-06-02
Alexyin_sc 写道 “你谈到带结果不会冲突，是说明分部的用户也要对中心的引擎进行操作申请吧。”我有这样说吗？
中心用户与中心系统的引擎交互，分店用户与分店系统引擎交互，中心系统引擎与各分店系统引擎各自独立， 通过服务来交换业务处理消息，这难道不是此问题讨论的前提？为什么会挨批呢？还狠狠批。。？有这种讨论氛围？难道非要先把异步通信这种N年前就有的东东先搬出来？这些应该是设计分布式系统时最起码的常识吧？
我说“WS-Transaction是一种基于补偿的事务模型”，并不意味着楼主理解的“WS-Transaction就只是补偿性事务”，只是想表达采用补偿机制是WS-Transaction的一大特色，使它区别其它众多的事务模型（包括它现在尚不能支持的预执行事务等） 。
确实，“BPEL只是模型”（严格地说是一种半形式化的过程模型描述语言），但个人认为它与冲突的解决方案并非完全就是两码事。在大多数实际的应用场景中，事务都是需要考虑的。业务过程中的事务问题非常有趣，真的。WS-Transaction只是涉及了其中的某些方面。 呵呵，看来是我对你的话理解有些问题了。不过让我疑惑的是“中心系统进行修改或取消订单的时候,需要判断在业务规则控制下当前订单能否进行当前操作. ”所谓的判断是如何来的？ 这种判断是否需要与中心交互呢？ 从你后面的理解，两个引擎是独立的（这个观点我是支持的，不过，这也就没有所谓的操作前的所谓有效判断了） 另外，关于WS-Transaction的补偿机制是一大特色，这个让我有些疑惑，对于异构系统来说，如果不支持全局事务，本身就只能使用补偿机制，WS-Transaction提供了这种机制（或者更多地说是提供了服务基于事务的联系罢了），但是事务的处理还必须要应用程序自己实现。还有你所说的预执行事务是什么？（两阶段提交的prepare么？如果交互的两个系统支持JTA，那么WS-Transaction是支持的） 你说的业务过程中事务是需要考虑的，这个非常认同。不过这种分布式事务（需要使用补偿性事务而非全局事务）的处理本身就是和业务或者说业务设计有关，与具体的技术（比如WS, MQ, BPEL)没有太多关系。 |
|
mobilezht
2011-06-21
可以参考一下 铁路的订票系统，就是 一个中心 ，无数个 订票点“门店”的结构。
这是sybase 的得意之作。 |
|
BigBlue
2011-07-05
WS-Transaction的理论是不错的，但是WS-Transaction有成功案例么？各家产品的交互性如何？
其实我更倾向基于MQ的方案。 另外一种解决方案是对数据进行版本管理，以中心店为中心来进行数据同步 |
|
BigBlue
2011-07-05
mobilezht 写道 可以参考一下 铁路的订票系统，就是 一个中心 ，无数个 订票点“门店”的结构。
这是sybase 的得意之作。 那是个典型的联机事务处理系统吧?和本议题的场景不符 |
|
mobilezht
2011-08-01
是 主从 分布式结构
|
|
Phoenixnzd
2012-02-09
个人觉得这个项目更好的方式是采用BS结构而不是将系统分别部署在门店和呼叫中心。
1. 通讯的问题完全可以采用有线+无线的方式进行相互后备。 2. 数据同步的问题在BS结构中相对比较好解决，而且对于日后的维护，也会相对来说简单的多。尤其是在餐饮行业中应用，因为餐饮行业的菜单，套餐优惠，过节优惠等等信息会非常频繁的发生变化，如果将系统设计成CS结构，那么会遇到非常严重的后期维护问题，工作量会很大。而BS只需要在服务端进行必要的修改。 3. .net开发此类程序会相对来说非常容易。客户端（也就是门店）可以通过使用浏览器打开固定的应用（页面），来实现订单的增删改查等操作。 |
|
凤舞凰扬
2012-02-10
Phoenixnzd 写道 个人觉得这个项目更好的方式是采用BS结构而不是将系统分别部署在门店和呼叫中心。
1. 通讯的问题完全可以采用有线+无线的方式进行相互后备。 2. 数据同步的问题在BS结构中相对比较好解决，而且对于日后的维护，也会相对来说简单的多。尤其是在餐饮行业中应用，因为餐饮行业的菜单，套餐优惠，过节优惠等等信息会非常频繁的发生变化，如果将系统设计成CS结构，那么会遇到非常严重的后期维护问题，工作量会很大。而BS只需要在服务端进行必要的修改。 3. .net开发此类程序会相对来说非常容易。客户端（也就是门店）可以通过使用浏览器打开固定的应用（页面），来实现订单的增删改查等操作。 门店系统一般不会使用B/S结构，最主要的原因是，如果网络存在问题或者服务端系统存在问题，整个公司的所有门店就无法运营了，这对于商业是非常悲剧的事。 所以，作为一个架构师，看待问题不要只从技术角度出面。 |
