谈设计精简的IM架构(转载)

来源:百度文库 编辑:神马文学网 时间:2024/07/07 11:18:05
喜欢memcached这样简单清晰的系统,但是底层服务的系统通常都要向功能屈服,总是要不断的打破原有的逻辑添加新的特性。
拿MySQL来说,比如mysql4就挺好的,只是为4条SQL语句服务。到了mysql 5身材发福了,也就跑不动了,功能特性一大堆,比如ndb cluster, partition等,尽管这些特性还没法用在生产环境,但从5.0到5.1的门槛跑了几年还没跨过去,虽然最近将Release Candidate变成GA版,但是业界还是抱着谨慎的态度,没人去急着当小白鼠。而且最近核心4条SQL语句的性能又被一个第三方的storage engine XtraDB 超越。自己不知道在忙什么的时候,核心功能却被别人超越,真够丢面子的了。
腾讯也有类似的问题,它一个致命的软肋就是非常担心用户一夜之间跟着一个更易用的第三方外挂跑了,但是他自己却无法提供用户友好体验的产品,于是就不断挥舞着手中的法律大棒在阻止各种创意,这种阻碍创新的方法实际上是一种行业倒退,所以目前的IM客户端产品设计依旧和10年前的ICQ惊人的一 致。
开源社区类似的案例很多,一个软件变得庞大之后就容易被对手打败,如 apache, sendmail, JBoss 等。XMPP Server目前相对来说还算健康,但也日趋庞大,比如Openfire目前的Java Source Code已经达到20万行。一方面受实现XEP扩展的诱惑,另外一方面也受商业化的诱惑,不断往服务器上增加周边服务的支持。这个我也不反对,Openfire在易用性和扩展性上确实比其他XMPP Server产品强很多。但另外一方面对核心层的重构代价可能会相当大,或者逐渐变成不可能的任务了。
技术人员通常有优化各种不够优雅的系统的冲动,或者经常想“如果重写……我会怎样做”,我今天也想如果要做一个非常精简的XMPP Server,我应该这样设计。
IM Server只做4个事情,处理对客户端的Roster, Presence, Message以及互联的S2S,其他都属于周边服务或者通过XMPP Component解决。

这个Server提供的功能比较简单,类似XP默认带的MSN Messenger那样少量的功能。

核心关注的指标:
  • 登录速度
  • 状态更改速度
  • 消息投递速度和可靠性
一些扩展的想法
  • 输出Presence的API, 可以是XMPP或HTTP
  • 可以embed, 象Berkeley DB一样,可以嵌入到各种应用。
  • 功能不够用则业务根据自己情况去扩展,就象mysql一样,不应该提供stored procedure和trigger
  • 想到了再补充