http://blog.csdn.net/Solstice/archive/2010/10/19/5950190.aspx
此文写的不错，有一定的深度
1 分布式系统的工程化开发方法
2 一听到“分布式”系统我的反应是
多层次系统，并发多进程，协同计算
附 corba,ejb ,webservice,rest分布式 区别
3 今天我们谈的分布式系统
4 今天不谈
5 先谈钱
分布式系统的成本包括：软硬件的成本，运维成本。这几方面的成本应该是相互影响的，在一定的投入上产生出最大的收益（运算时间，支持用户数等等），是分布式系统设计的关键因素。
6 我们在技术浪潮中的位置
单机编程的问题并没有解决，随着CUDA，多核编程的出现，在单机也会出现分布式设计遇到的问题，分布并行成为程序设计的重难点。
分布式对象由于容错性问题面临淘汰，这句话也许是真的。
soap正在被REST所取代（REST技术需要仔细查看一下 ）
7 你的系统可以这样设计
无状态取决于用户需求，这里面有几个名词：LVS,Heartbeat,HAProxy,keepAlive 这些都是常见的做负载均衡，心跳的工具
VCS 可能是链接里面的东西，Erlang是一种并行语言（期待进一步的研究来评价其优略 ）
8 技术浪潮的前夕
分布式系统，不算是新的东西，由于其开发的复杂性，主流的框架不是很多，文中谈到了一些主流技术，然后又否定了，确没能提出更好的解决方案
9 我们怎么办
没有哪个“C＋＋分布式中间件”是成熟的！？
10 分布式系统是一个险恶的问题
有些难题其实可以绕道走，并不需要钻牛角尖
11 开发可靠的商用系统的关键技术
支持重启和恢复
容错策略
12 分布式系统本质困难
检错 可靠性 可恢复
13 可靠性的基本指标MTBF
14 避免不切实际的可靠性指标
15 单机硬件的可靠性和容错
16 硬盘与内存的误码率
17 其它必需停机和重启的情况
18 对程序开发的影响
（不认同）程序的可靠性依赖于程序逻辑的正确性，软件系统的可靠性依赖于程序，操作系统以及硬件，文中犯了概念错误
对于服务器而言，错误需要酌情处理，优化需要认真对待。重启只是手段，不是目标，在合理的情况下优化服务器是可行的
19 “能重启”作为设计目标
进程在设计时必需想清楚重启的代价和方式
20 能重启的进程
只使用操作系统能回收的IPC （TCP）
不使用生命期大于进程的IPC （跨进程的mutex，共享内存）
不使用不能重建的IPC （Pipes，父子共享文件描述符）
21 如何优雅的重启
客户端failover
22 硬件故障与软件故障
23 accept失败的例子
EMFILE错误，无法close socketfd，解决方法：open("/dev/null")
24 监控
监控包括：自身进程，系统设备，文件等等
25 Naming Service
DNS不适合快速failover，在程序中配置自己的name service
26 在程序中内置http服务器
可以在运行时探察 procfs，提供html页面进行状态反馈
包括：进程的状态，业务对象状态，支持stats命令 （需调查Muduo Inspector ）
27 从TCP协议中能学到什么
应用层协议中应该包含一段时间不重复的序号，以及超时处理，必要时可以校验可靠性
28 阻塞
a 单线程僵死
b 固定容量线程池超限
c 动态线程池资源耗尽
d 网络IO的阻塞
29 心跳协议的设计
要设计在同一线程内，同一socket上面
30 RPC与HTTP
RPC使用方便，但隐藏了很多不容忽视的细节；HTTP更适合做RPC
31 为系统演化做准备
a 应对客户端和服务器的版本升级
b 保存原有版本的log
c 应对不同组建使用不同语言来写
32 消息格式的选择
参考Google Protocol buffer或Apache Thrift
33 只使用最土最烂熟的技术
进程间通讯只用TCP >100MB/s时，不使用OOB，SCTP，UDP
进程内读写锁不要用，信号量不要用
用one event loop per thread + non blocking IO 作为基本线程模型
附：
使用Erlang和Yaws开发REST式的服务