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式的服務