一，可靠性的挑戰
1，人為故障是線上系統故障的首要原因，應該怎麼避免
1.1簡化設計，易於測試
1.2充分測試，覆蓋場景
1.3快速回滾，降低損失
1.4完善監控
1.5規範流程，這點最重要
2，軟體故障
2.1簡單架構，降低複雜度帶來的不可控
2.2選擇穩定的軟體，包括開源
2.3要有自動恢復機制，比如限流，程序自動拉起
3，硬體故障
3.1多機服務，但會帶來資料複製和一致性問題
二，可擴充套件性
1，響應時間定義：客戶端發起請求，收到結果的時間
2，時延定義：服務處理請求的時長
3，如何描述效能
3.1通常效能是指吞吐量和時延
3.2時延應關注95line，99line，99.9line，平均時延會掩蓋問題
4，無狀態服務擴充套件相對容易，有狀態服務從單個節點擴充套件到分布式多機系統複雜性會大大增加
5，很難有一種通用的架構，背後取捨因素包括資料讀取量、寫入量、待儲存的資料量、資料的複雜程度、響應時間要求等等
三，可維護性
1，可運維性，自動化與規範流程
2，簡單性，新接手的工程師易理解，消除意外複雜性的最好手段之一是抽象
3，可演化性，易於改變，比如相容性
參考《資料密集型應用系統設計》
原文出自：
end
建立可維護 可擴充套件的 XML 格式
xml 是一種交換結構化文件和資料的通訊格式。人們經常隨意地在開發過程中臨時決定選擇 xml 格式，而沒有提前計畫或設計。只有提前設計好正確的 xml 格式，才能滿足通訊各方的要求。否則就不得不反覆地修改。了解如何設計一種不經常進行修改的格式，足夠敏捷，不需要徹底修改而僅需填加少許擴充套件就能適應新...
系統的可擴充套件性
到底什麼是可擴充套件性？這年頭，作為軟體設計架構師如果系統沒有可擴充套件性對外交流時都不好意思。但是如何選擇可擴充套件性方案？水平擴充套件還是垂直擴充套件？是不是很矛盾呢，本文為你分析可擴充套件性的真實含義和實際專案中的取捨。每每和別人提及可擴充套件性的含義時，很多人開始討論提高效能，實施高可用性，...
可擴充套件系統設計的要點
根據以往經驗和的總結 縱向擴充套件 硬體方面可以更換更強勁的伺服器，增加 cpu 記憶體，使用高速磁碟。軟體方面可以對現有 的優化，重構。使用 non blocking 非阻塞 io 模式，或者非同步 io 模式，使用執行緒模式或者改用 事件驅動形模式。目標是提高單機 qps 連線數，來支援更多的連...