msg based architecture

tensaix2j

你们对 message based 的 software architecture 有什么看法？

message based 的 基本上就是 一个系统是 由 多个 processes 组成的， 这些 processes 要跟彼此 沟通都要 通过 msg router
thru subscription to msg topics 。 基本上就是 publisher and consumer 的模式。。

任何一个 process 要什么 msg 就要 subscribe。 同时， 他publish 的msg 也会传到所有的subscribers 那里
那个 message router 可能 是 third party 的 ，也可能是你自己建的。。。 不过跟系统的主要功能无关，只是负责route msg 的。。


你们觉得 这种 architecture 有什么 好， 有什么 坏?


本人 觉得， 好是在 scalability 方面，例如 可以 完全不碰原本的 系统，可以很方便的加一个新的 component


你们有什么看法吗

晨天

RSS???????????

tensaix2j

no。
我在讲着 software architecture  ，不是某某 technology..

nayiq

原帖由 tensaix2j 于 24-5-2008 07:55 PM 发表
你们对 message based 的 software architecture 有什么看法？

message based 的 基本上就是 一个系统是 由 多个 processes 组成的， 这些 processes 要跟彼此 沟通都要 通过 msg router
thru subscription to  ...

pros:
- 容易maintain，容易debug，哪一个process有问题就改该process，不用全部动到完。
- 如你所说的容易增加components及module。
- 只要protocol定制的好，基本上什么功能都能拥有。
- library及architecture够稳的话，全部module统一的话，msg基本面就不用担心了，有新project或module的时候，只要处理application logic layer就够了。
- document足够的话，容易handover，大家负责好自己的module就行了，而且module机制一样，会一个其他的都很容易上手。

cons:
- 如何处理message传递？tcp/ip？ipc？file descriptor？自己的queue？无论如何，全部都有一些有点难度的缺点。
- 太频繁的传来传去及subsribe，效率不高，在一些critical及需要high performance的情况下，system会很吃力。
- 很难trace，msg飞来飞去，出错的时候不知道去了那里。log及tracefile不统一，讯息集中不了，出错的时候，core或者back trace讯息会很乱，debug有点费时。
- msg router够快吗？有delay吗？不然就会成bottle neck。
- msg router除错能力如何？读错一个byte，会不会全部乱到完？
- msg protocol如何定制？扩充性高不搞？够不够灵活？需要增加parameter或variable时，其他module会被影响吗？
- document够不够？不够的话，senior一走，整个system就很难mantain了，再经过几手的话，system肯定挂。

tensaix2j

通常都是 tcp/ip socket

我也是觉得 performance wise，会比 一个monolithic process 差 ，但如果 impact 不大的话，应该 可以接受。

另一个 好处 就是 components 可以 分布 在不同的电脑上跑。。
而且 components 可以 由不同的语言写的。

bottleneck 是有可能，因为通常是个 msg queue。
所以这个queue 可能会囤到很长。。
而且 msg router 通常 如果 无法 传递 msg 给 subscriber 的话，
会 cache 起来， 直到subscriber up，在传递之前错过的msg。
但是挺浪费memory 除非 dump进file 里


msg 的 format 必须要define 好。
但通常 args 都是 arbitrary 个
<msg topic> <msg args>*..
更改msg 的 format 就会 影响 所有 的 subscribers

nayiq

- 嗯，tcp是最普遍的了。但通常应该要有两种界面，internal queue和tcp socket。内部处理或者components在同一machine，可以全部用queue，queue会比tcp快很多。tcp好处就是components可以在不同machine跑。

- 不是critical system的话，那performance wise只差一点点应该不是大问题。

- 用msgqueue要很小心。你的msgqueue是什么queue？ipc queue? pipe？ipc queue很危险，因为它是system wide的，system里如果有其他ipc queue full你的queue也是会死掉，而且handle timeout有点难度。其他queue很难做到跨module，但是timeout好处理而且比较独立，不受其他影响。我这里是用tcp + queue。

- 你cache起来的msg，components关掉的话就没有了，不知道你需要handle redundant 和load sharing 问题吗？同时开两个module做同样事情，一个死掉另一个能take over，如果你cache起来，另一个如何take over？

tensaix2j

原帖由 nayiq 于 27-5-2008 10:00 AM 发表
- 用msgqueue要很小心。你的msgqueue是什么queue？ipc queue? pipe？ipcqueue很危险，因为它是system wide的，system里如果有其他ipc queuefull你的queue也是会死掉，而且handletimeout有点难度。其他queue很难做到跨module，但是timeout好处理而且比较独立，不受其他影响。我这里是用tcp +queue。

- 你cache起来的msg，components关掉的话就没有了，不知道你需要handle redundant 和load sharing问题吗？同时开两个module做同样事情，一个死掉另一个能take over，如果你cache起来，另一个如何take over？.

我做过一次是用 tcp 的， 那个 msg router 收到 msg 后 会加到它自己内部的queue。然后再dispatch

基本上，每个 module/process 有个 appID。 当 msg router 可以把 msg dispatch 到 那个 appID 的话， 它就不cache 了。
若有两个 processes subscribe 用同个appID 的话， 基本是两个都会收到它们subscribe 的msg。