什麼是鳳凰架構
1、提出重程式設計能力還是重架構的問題
2、提出構建乙個大規模但依然可靠的軟體系統是否是可行的
通過馮諾依曼研發自複製自動機的例子舉例我們一直是在用不可靠部件構造可靠的系統。比如我們開發的每個環節都是有可能出錯的，但最終設計出的軟體必然是不可靠的，但事實並非如此。用馮諾依曼的自動機這個例子來講就是說這些零部件可能會出錯，某個具體的零部件可能會崩潰消亡，但在存續生命的微生態系統中一定會有其後代的出現，重新代替該零部件的作用，以維持系統的整體穩定。在這個微生態裡，每乙個部件都可以看作乙隻不死鳥，它會老去然後又能涅槃重生。
3、強調架構演變最終都是為了使我們的服務更好地死去和重生
軟體架構風格演變順序：大型機 -> 原始分布式 -> 大型單體 -> 面向服務 -> 微服務 -> 服務網格 -> 無服務
技術架構上呈現出從大到小的發展趨勢。作者提出了：相比於易於伸縮拓展應對更高的效能等新架構的優點，架構演變最重要的驅動力始終都是為了方便某個服務能夠順利地「死去」與「重生」而設計的，個體服務的生死更迭，是關係到整個系統能否可靠續存的關鍵因素。
服務架構演進史
原始分布式時代
unix 的設計原則提出了：保持介面與實現的簡單性，比系統的任何其他屬性，包括準確性、一致性和完整性，都來得更加重要。
負責制定 unix 系統技術標準的開放軟體**會(也叫osf) 邀請了各大計算機廠商一起參與共同制訂了名為「分布式運算環境」(也叫dce)的分布式技術體系。dce 包含一套相對完整的分布式服務元件規範與參考實現。
osf 嚴格遵循 unix 設計風格，有乙個預設的重要原則是使分布式環境中的服務呼叫、資源訪問、資料儲存等操作盡可能透明化、簡單化，使開發人員不必過於關注他們訪問的方法或其他資源是位於本地還是遠端。這樣的主旨非常符合一貫的unix 設計哲學。但是實現的目標背後包含著當時根本不可能完美解決的技術困難。 因為dce一旦要考慮效能上的差異就不太行了。為了讓程式在執行效率上可被使用者接受，開發者只能在方法本身執行時間很長，可以相對忽略遠端呼叫成本時的情況下才能考慮分布式，如果方法本身執行時間不夠長，就要人為用各種方式刻意地構造出這樣的場景，譬如將幾個原本毫無關係的方法打包到乙個方法體內，一塊進行遠端呼叫。這種構造長耗時方法本身就與期望用分布式來突破硬體算力限制、提公升效能的初衷相互矛盾。並且此時的開發人員實際上仍然必須每時每刻都意識到自己是在編寫分布式程式，不可輕易踏過本地與遠端的界限。這和簡單透明的原則相違背。
通過這個原始分布式開發得出了乙個教訓：某個功能能夠進行分布式，並不意味著它就應該進行分布式，強行追求透明的分布式操作，只會自尋苦果。
基於當時的情況擺在電腦科學面前有兩條通往更大規模軟體系統的道路，一條是盡快提公升單機的處理能力，以避免分布式帶來的種種問題；另一條路是找到更完美的解決如何構築分布式系統的解決方案
CSAPP讀書筆記，其一
不是所有的書都需要寫筆記，比如 大全這種就是需要經常讀讀，結合專案自我體驗昇華。但是對於某些涉及大量細節，或者繁雜的邏輯的書，如果只是順序的往下讀，基本上只是過眼即忘，更好的方法是仔細的看一遍，認真的做完習題，然後自己再總結一下脈絡梗概。如果時間比較匆忙，習題沒時間做也最好認真的做筆記，腦子裡面有一...
讀書筆記 人月神話 其一
人月神話 是大學剛開始就很熟悉的一本書，當時被奉為軟體工程的聖書，似乎都要在書架上擺上它才能表明軟體工程學生的身份。時至今日我再讀它，因為有了之前參與系統的開發的經驗，很多的內容都通過記憶得到了驗證，讀來與大一時的 雖然不懂你在講什麼但好像很有道理 的體會有了明顯的不同。這裡選擇一些感觸較深的章節寫...
讀書筆記 大話設計模式 其一
簡單工廠模式 緊耦合 松耦合 簡單工廠模式 用乙個單獨的類來做創造例項的過程 物件導向程式設計，不是類越多越好，類的劃分是為了封裝，分類的基礎是抽象，具有相同屬性和功能的物件的抽象集合才是類 最大的優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態例項化相關的類，對於客戶端來說，去除了與...