转载自：http://blog.csdn.net/historyasamirror/article/details/6966672
突然发现自己很久没有更新博客了。主要的原因还是这阵子特别懒，没有努力学习新的东西，光忙着每天的日常任务。佛曰：这样不好，不好...
这些体会是基于一个这样的系统：它包含有十几个大小不一的模块，这些模块分布在不同的机器上，每个请求都需要这些模块的协作才能够完成。我不是太好
意思称它为大系统或者分布式系统，因为它确实还差了那么点东西。但我也相信，任何一个真正的大系统/分布式系统也是从这么一个系统开始的。
对于这样一个系统，消息通信模块，日志模块和监控模块是非常基础却至关重要的几个模块：
消息通信模块是一切的基础。为了使得所有的模块尽可能的独立和解耦合，并且能够部署到不同的机器上，你应该让他 们只使用某种基于网络协议的通信机制进行交互，而抛弃诸如管道，共享内存等方式。这种情况下， 一个统一的消息通信模块非常必要：它提供统一的协议去定义服务的接口；它应该支持多语言，因为你的模块实现的语言可能各不相同；它至少要提供同步的消息通 信机制，比如RPC，最好能够有异步的方式；它的性能会对整个系统有很大的影响。
所以，google有Protocol Buffer，Facebook有Thrift（严格的说，Profocol Buffer只开放了多语言之间消息交互的格式和编解码）。当一个公司的系统越做越大以后，一定会出现这样的东西。
日志模块的重要是因为这样一个系统的调试非常的困难。每个模块接口的正确并不代表整个流程的正确，而且一旦出现 问题，定位到问题的发生地点也并不容易，很多时候，唯一的办法就是分析日志。这样一个日志模块应该提供：统一的日志格式，所有的语言输出的日志是一致的； 日志附带的信息应该足够丰富；能够将所有机器上所有模块的日志汇总，整理（最好还能实时整理）；提供良好的接口能够对日志做查询（最好也能实时）。
我所了解的大部分这样的系统都是这么实现的：每台机器有一个日志模块的agent，它收集这台机器的所有模块的日志，同时有一个日志中心，将所有机器的日志汇总（或推或拉）。模块与agent之间，agent与中心之间的交互也应该都基于消息通信模块。
监控模块除了能够了解到整个系统的运行状况以外，它也应该能够用于系统的调试。因为监控模块对于运维人员和开发人员都很重要。最近一篇很火的文章《SteveY对Amazon和Google平台的长篇大论》中提到“...直到你的监控系统能够全面性地系统地检查所有的Services和数据，此时，监控系统就跟自动化测试QA没什么两样了，所以两者完美的统一了...”，我深以为然。
而且，监控系统应该早规划早做，不要等到整个系统完成之后才开始上马，而应该在系统第一次迭代的雏形完成后就开始开发（甚至可以更早），并且随着系 统的开发而不断完善。在实现每个模块的时候，都应该要考虑这个模块应该提供怎样的监控接口，输出什么样的监控信息。同样，监控系统和模块之间的交互也应该 基于消息通信模块。还有一个方案就是将监控模块完全构建于日志模块之上，所有的监控信息都写入到日志，对日志的统计分析就能够得到所有的监控信息。
最后，除了这三个组件，如果系统存在着大数据量的交互，那么一个提供统一接口的分布式存储模块也很有用。GFS，BigTable已经证明了这一点。