转自淘宝中间件 架构吧...挺好~~

from:http://rdc.taobao.com/team/jm/archives/934

 

一个公司大了，总有部分人要去做一些通用的东西给大家用，我这里说的基础产品就是这类通用性质的东西，不一定高科技，但是一定很多人依赖你的东西来完成各种各样的功能。做这样的东西，有些体会可以说下。

首先，能集中存储的，就不要分布存储，数据集中存储有单点的危险，但是比之分布式存储带来的复杂度不可同日而语。况且集中式的存储也可以利用各种机制做备份，所谓单点风险远没有想象中那么大。

其次，能利用开源框架的，就不要重复造轮子。程序员都喜欢造轮子，但是造轮子的周期长，并且不一定造的更好。在强调开发效率的互联网时代，如果能直接利用现有框架组装出你想要的东西，迅速占领市场，比你造的高性能、高可用、高科技的轮子更实用。这个跟做新产品开发有点类似，迅速组装，高效开发，然后再想办法改进。

第三，要文本，不要二进制。协议要文本化，配置要文本化。不要担心性能，在可见的时间里，你基本不会因为文本化的问题遇到性能瓶颈。

第四，要透明，不要黑盒。基础产品尤其需要对用户透明，你的用户不是小白用户，他们也是程序员，而程序员天生对黑盒性质的东西充满厌恶，他们总想知道你的东西背后在做什么，这对于查找问题分析问题也很重要。怎么做到透明呢？设计，统计，监控，日志等等。

第五，要拥抱标准，不要另搞一套。已经有了久经考验的HTTP协议，你就不要再搞个STTP，有了AMQP协议，你就不要再搞个BMQP。被广泛认可的标准是一些业界的顶尖专家制定出来的，他们早就将你没有考虑到的问题都考虑进去了。你自己搞的那一套，随着时间推移你会发现跟业界标准越来越像，因为面对的问题是一样的。使用标准的额外好处是，你有一大堆可用的代码或者类库可以直接使用，特别是在面对跨语言的时候。

第六，能Share nothing，就不要搞状态复制。无状态的东西是最可爱的，天然的无副作用。水平扩展不要太容易。

第七，要将你的系统做的越不“重要”越好，如果太多的产品依赖你的系统，那么当你的系统故障的时候，整个应用就完蛋了。我们不要担这个责任，我们要将系统做的越来越“不重要”，别人万一没了你也能重启，也能一定时间内支撑正常的工作。

第八，要专注眼前，适当关注未来。有远见是好事，但是太多远见就容易好高骛远。为很小可能性设计的东西，没有机会经历实际检验，当故障真的发生的时候，你也不可能完全信赖它。更好的办法是将系统设计得可介入，可在紧急情况下人工去介入处理，可介入是不够的，还要容易介入。

第九，不要对用户有假设，假设你的用户都是smart programmer，假设你的用户不需要位运算，假设你的用户要同步不要异步。除非你对这个领域非常熟悉并实际使用过类似的东西，否则还是不要假设。

第十，咳咳，似乎没有第十了，一大早憋了这么篇无头无脑的Blog，大伙将就看看。