我不服！這開源項目竟然才888個星！？

你好呀，我是why。

是的，我又發現了一個寶藏，又火燒眉毛的想分享給你們。

這個寶藏是一個開源項目，或者叫作一本開源的書。

讓我意難平的是，這本寫的如此具備學習潛力和指導意義的開源書，目前才 887 個 Star。

趕得早不如趕得巧，我就是第 888 個點 Star 的人，聽起來就頗有緣分的樣子：

https://icyfenix.cn/

先看一下我看了以後整理的思惟導圖吧：

看不清不要緊，文末會給你領取連接的。

看完以後我我的的一個感覺是：

關於分佈式架構方向，寫的不少很全。並且都是筆者一路走過來的經驗之談，濃縮在了文章裏面。

對的起首頁的這一句口號：構建可靠的大型分佈式系統。

誰寫的？

那麼這個開源書的做者是誰呢？

周志明。

是的，就是你想到的那個寫了 JVM 的書的男人。

其實你仔細看周佬寫的自我介紹，頗有小細節。

程序員、研究員、做者、佈道師這四個職業，排在第一的是最沒有噱頭的「程序員」一職。

而在程序員裏面，給本身的描述是：

一名兼職一些管理與研究工做的程序員。

其實關於這個點，我看過周佬的一些公開場合的自我介紹，都是說本身是一個「兼職一些管理工做的程序員」，給本身這樣的人設標籤。

他在本身寫的《程序員之路》一文中解釋過這個標籤。

他想要透過這個標籤表達的是對於一枚程序員，之後是想要發展爲一個架構師仍是研發管理者，都不要輕易地離開技術領域的一線前沿，離開技術、放棄編碼的決定極可能會像你高考以後放下的數學、生物、地理等知識那樣，一旦放手，畢生就很難有機會再從新撿起來。

當你放下代碼的時間越長，長此以往，你對代碼、技術、產品狀態與團隊研發狀態的理解，漸漸的會和團隊成員產生了誤差錯位，喪失了細節上給予指導的能力，喪失了專業問題上提出接地氣解決方案的能力，只能在沒法短時間難以校驗對錯的大戰略方向提意見。

在會議、流程及團隊管理措施上下功夫，在職業經理人式的宣講與彙報上尋找存在感。

此刻，你便從團隊的導師變成了管理者，最終你與團隊的關係，從攜手並肩奮鬥的夥伴，徹底演變成只能靠公司制度與管理職位的權力來維繫僱傭關係。

我能理解周佬說的現象，實際上是一個很是廣泛的現象。甚至有的朋友走上管理崗位的目標就是再也不寫代碼了，基於當前的市場和行業現狀，這樣的選擇是無可厚非的。

只是，有沒有那麼一點點可能，不要徹底拋棄代碼。這也須要是你和團隊之間的最行之有效的紐帶。

就像《代碼整潔之道》一書中說的：

軟件架構師自己就是最好的程序員，他們會一直編寫代碼，雖然可能不會像其餘程序員輸出的代碼量那樣多，可是隻有持續地編程，才能確保他們碰見其餘程序員所面對的問題，體會其餘程序員心中的感覺，所以若是不編程，他們亦將沒法勝任軟件架構這項工做。

這本《鳳凰架構》，周佬本身對它的定位是這樣的：

給開發人員整理的關於軟件架構方面的技能地圖，同時系統的梳理本身的知識，並配備了對應技術方案的演示程序。

真的是一件利人利己的事情。

我原本的想法是先帶着你們囫圇吞棗的走一圈這一本書，主要起到一個介紹的做用。

可是越寫越不得勁的感受。由於即便我寫的這麼賣力認真，都沒有體現出這本書的價值的千分之一。

你得本身去讀，你才知道我沒有騙你：

這真的是個寶藏啊！

因此我決定換個思路，告訴你們這裏面有什麼就好了，其實就是書中的探索起步一小節。

探索起步

這是探索起步的更新日誌部分，能夠看到周佬對於該項目一直在進行維護新內容：

而對於已有的內容，其中的錯別字、不通順的地方、含義不清的地方，他也在抽時間修改，最近的一次修改就是 6 月 6 日，昨天，上週日：

因此，相比於其餘的大部分網上的文章來講，會更加實時、系統、優質一點。

全書分爲五大部分和兩個篇外，而爲了讓你快速定位到合適本身的部分，周佬也細心的介紹了每一部分對應的讀者類型。

• 引導篇 探索起步:這部分面向於準備對文檔介紹的內容親身實踐的探索者。
• 第一部分 演進中的架構：這部分適合全部開發者，但尤爲推薦剛剛從單體架構向微服務架構轉型的開發者去閱讀。
• 第二部分 架構師的視角：這部分討論與風格無關的架構知識，適合全部技術架構師、系統設計、開發人員。
• 第三部分 分佈式的基石：這部分面向於使用分佈式架構的開發人員。
• 第四部分 不可變基礎設施：這部分面向於基礎設施運維人員、技術平臺的開發者。
• 第五部分 技術方法論：這部分面向於在企業中能對重要技術決策進行拍板的決策者。
• 篇外 隨筆文章：這部分無特定讀者對象，內容是筆者平常文章的整理。
• 篇外 附錄：這部分面向剛開始接觸雲原生環境的設計者、開發者。

其中第一部分的我讀完以後作的思惟導圖以下：

能夠你們對於其中的後微服務時代和無服務時代稍微有點陌生，可是我換個英文名稱，你們就應該是很是熟悉了。

後微服務時代其實就是雲原生時代，Cloud Native。

而無服務其實就是 Serverless。

可是須要注意的是，周佬把 Serverless 排在了 Cloud Native 以後，其實它們二者並無繼承替代關係。不要由於周老對於二者的書寫順序產生了「無服務就會比微服務更加先進」的錯誤想法。

周佬對於這二者之間的關係描述是這樣的：

• 若是說微服務架構是分佈式系統這條路當前所能作到的極致，那無服務架構，也許就是「不分佈式」的雲端系統這條路的起點。

第二部分的思惟導圖以下：

這一部分主要聊了咱們作分佈式服務時，必定會涉及到的問題，好比：遠程服務調用（RPC）、分佈式事務的處理、多級分流、架構安全。

我我的認爲這一部分是乾貨滿滿的。

其中訪問遠程服務，對 RPC 和 REST 從各自的起源開始進行了一個詳盡的描述：

事務處理小節，你們能夠看看「共享事務」的概念，其實我發現有一部分號稱是微服務架構的項目，走向了「共享事務」的路線。

我認爲這是一種僞分佈式。

透明多級分流系統從客戶端到網絡在到服務端的拆析，這是一種上帝視角的描述，而這一部分的主題就是「架構師的視角」。

架構師就應該是從這樣的一個比較統籌規劃的角度去看待系統，沒必要進入到具體系統的細枝末節中去：

第三部分分佈式的基石：

共識算法、服務發現、流量治理、網絡通訊、監控預警共同構成了分佈式的基石。

能夠說若是是一個分佈式的服務，都能找到上面的這些關鍵詞的影子。

有些是應用系統本身作的。

有些是開源框架就幫你搞定了，你甚至不知道它們的存在。

可是上面的諸如流量治理和監控預警（可觀察性）不是一個分佈式服務一開始搭建時所必須的。

大多數狀況下，剛剛搭建好的分佈式都處於一個蠻荒狀態。

隨着時間推動和業務的發展，會慢慢補充上流量治理和監控預警。

也就是說若是想要分佈式服務發展的監控可控，那麼這些東西都是應該有的。

「基石」一詞，像是手術刀同樣精準。

來到了第四部分，不可變基礎設施：

到這裏咱們就要從微服務走向雲原生了。

在這一章，周佬以容器、編排系統和服務網格的發展爲主線，介紹虛擬化容器與服務網格是如何模糊掉軟件與硬件之間的界限，如何在基礎設施與通信層面上幫助微服務隱藏複雜性，解決本來只能由程序員經過軟件編程來解決的分佈式問題。

接下來的「技術方法論」屬於微服務避坑指南，從目的、前提、邊界、治理四個角度去闡述如何更好的使用微服務。

最後一部分是「隨筆文章」：

其中的《雲原生時代，Java 的危與機》和《程序員之路》這兩篇文章，建議你們反覆觀看。

前者是技術方向的，後者是軟技能方向的。

讀完《Java 的危與機》，我感覺到的是一場關於 Java 的自我革命已經悄然開始了。

Java 並非一個優秀的開發語言，這一點我是很是認可且肯定的。可是 Java 有一個龐大的用戶羣體和異常豐富的生態，這是它的護城河。因此短期內還倒不下來。

可是大風起於青萍之末。風雨欲來，而包括我在內的不少人都渾然不知。

在文章裏面，周佬有這樣的一段話：

Java 支持提早編譯最大的困難在於它是一門動態連接的語言，它假設程序的代碼空間是開放的（Open World），容許在程序的任什麼時候候經過類加載器去加載新的類，做爲程序的一部分運行。要進行提早編譯，就必須放棄這部分動態性，假設程序的代碼空間是封閉的（Closed World），全部要運行的代碼都必須在編譯期所有可知。這一點不只僅影響到了類加載器的正常運做，除了沒法再動態加載外，反射（經過反射能夠調用在編譯期不可知的方法）、動態代理、字節碼生成庫（如 CGLib）等一切會運行時產生新代碼的功能都再也不可用，若是將這些基礎能力直接抽離掉，Helloworld 仍是能跑起來，但 Spring 確定跑不起來，Hibernate 也跑不起來，大部分的生產力工具都跑不起來，整個 Java 生態中絕大多數上層建築都會轟然崩塌。

「整個 Java 生態中絕大多數上層建築都會轟然崩塌。」

因此，Java 的此次變革屬於要釜底抽薪。

讀完《Java 的危與機》以後，你再去看《Graal VM》一文，你就明白了：爲何說 Graal VM 的成功與否，與 Java 的前途命運息息相關。

而這場變革已然悄悄開始，好比說一個小點：

大多數運行期對字節碼的生成和修改操做，在 Graal VM 看來都是沒法接受的。

可是好比 CGLIB 就是經過運行時產生字節碼（生成代理類的子類）來作動態代理的。

這是目前的主流形式。

如今由於Graal VM 支持不了，因此必須由和框架一塊兒來共同解決。

所以自 Spring Framework 5.2 起，@Configuration 註解中加入了一個新的 proxyBeanMethods 參數，設置爲 false 則可避免 Spring 對與非接口類型的 Bean 進行代理。

一樣地，對應在 Spring Boot 2.2 中，@SpringBootApplication 註解也增長了 proxyBeanMethods 參數，一般採用 Graal VM 去構建的 Spring Boot 本地應用都須要設置該參數。

我最喜歡的仍是技術演示工程部分，直接把項目 Demo 都給你準備好了，開箱即用：

並且周佬寫的這個開源項目有個特色，引用的部分會給出具體的官方的地址。嚴謹又權威，好比寫到項目中用到的技術組件的時候：

一個問答

在項目裏面，我還發現了一個問答。

問題和回答都很是的好，搬運過來給你們看看。

評論區： https://icyfenix.cn/methodolo...

問題以下：

周大哥，看到了您說的馬太效應。再聯想到以前您講的軟件涅槃，而完善的微服務體系容許服務有涅槃的過程，有強大的容錯能力。微服務發展又如此迅猛，以爲馬太效應真的不遠。

我不由對最須要掌握的技能進行了思考，併產生了更強的焦慮感。

我是一名有七年工做經驗的java開發工程師，28歲，目前在一家北京的傳統信息軟件技術公司，工資相對計算機行業偏低。

侷限在java語言來講，jvm調優與併發編程等比較高階的能力，是否是就很不關鍵了？

jvm我讀了您寫的《深刻理解Java虛擬機：JVM高級特性與最佳實踐》的第二版與第三版，因爲工做中鮮有機會實踐，只停留在一些理論理解，而缺失實踐，理論知識也會淡忘。

併發編程讀過《Java併發編程實戰》，對併發編程有些瞭解，也有一些實踐，通常水平。

微服務公司並無用起來，實踐經驗也缺乏。遠程調用、分佈式事務、註冊中心、配置中心、熔斷、限流等知識，經過看視頻跟您的這個文檔有一些瞭解。

java基礎知識，通過這些年的磨練，是挺紮實了，spring能熟練使用。

經常使用設計模式有了解，也理解的比較到位。

我不想淪爲螺絲釘。

我應該提高本身的哪些能力呢？

這些年只是作到了勝任分配給本身的工做。

如今發現本身缺乏前瞻性思考，缺乏對本身職業生涯的把控。

我如今想把握本身的職業生涯，請周大哥給一些指導。

我會經過招聘市場去挖掘市場需求，作整理，進行思考。

可是火燒眉毛的想跟您述說一下，請您不吝賜教，但願個人請求不是很唐突。

這個問題實際上是很具備廣泛性的：學了沒地方實踐，慢慢就忘記了。理論學了一大堆，聊起來能夠談笑風生，可是就是沒有實際使用過。本身就是一顆螺絲釘。

周佬的回覆以下：

寫這文章不是爲了販賣焦慮，我也沒有能力指導別人的職業生涯，但針對「應該提高本身的哪些能力」這類問題，我之前被問過不少次，這裏能夠重複一下。

個人建議就兩個：

• 不要輕視不直接產生實踐價值的知識；
• 不要對陷入已經被你熟練掌握的技術中不能自拔。

爲了便於你理解，我作一個很土的比喻，把程序員提高本身類比成武俠中的練功，軟件中的技能其實有很明顯的「內力」和「武功」之分，譬如你提到的Java虛擬機，這類知識不只是你在工做中鮮有機會實踐，我也是差很少的。

大學計算機課程中，以「原理」二字結尾的課程，譬如計算機原理、操做系統原理、編譯原理、數據庫原理，等等，對絕大多數人而言，都不太會去設計處理器邏輯電路、設計程序語言和編譯器，開發操做系統內核。

這些都有很經典的書：編譯原理的龍書，計算機體系結構和程序運行的CSAPP，分佈式與數據庫原理的DDIA、操做系統原理的MOS，等等。這些書系統嚴謹全面，但可讀性並不優秀，在B站/Coursera刷這些書做者們的公開課翻譯視頻也許是更好的方法。

這些技能可以輔助你去思考和分析問題，可是很難直接爲你解決生產中的問題，以實踐價值，就是以工做中是否有機會用到來衡量它們的做用是不合適的。

但這些課程之因此會是必修，是由於學習它們，可以爲一名程序員的知識框架構築好基礎。

這話聽起來很教條，但是當你一旦創建了相對完備穩固的知識框架，發現遇到的新知識、新技術，可以很天然地安放在已有知識體系的某個位置上，可以清楚感知到語言、技術、框架的設計意圖和目標，甚至能共鳴到設計者當時所想，就會產生一種理所固然的感受。

這樣你接受新知識的認知負荷就會比別人更低，掌握起來更快速，理解起來更深入。

我在這文檔開篇中所說的，寫這部文檔是以整理本身的知識框架爲目的，並不是場面話，這點的確就是程序員如何學習新知識的關鍵，在知識快速迭代IT業界，這也是決定一名程序員能力上限有多高的根本因素。

相對的，那些具體的、用來解決生產中問題的技術和方法，譬如你提到的Spring、設計模式，我將其類比爲「武功」。

這固然也是重要的，只有內力沒有武功沒法行走江湖，空有一身理論，但寫不出代碼來（包括那些只定大方向的架構師、設計者），我認爲不願定是合格的程序員，也很難期望能成爲一名出色的技術領導（難以服衆）。

可是具體的「武功」應該是可以快速撿起的，也能快速「忘掉」的，就是避免將一件事情作熟了，就一直陷在這件事情裏面，避免拿到一把好的錘子，就看着一切問題都像是釘子。

不少程序員都抱怨，本身是CRUD Boy，本身在業務邏輯中打滾，沒有機會接觸底層的或者前瞻性的技術，因此本身技術難以提高。

這裏固然有客觀緣由的存在，但每每也是受到了主觀緣由放大。

程序員其實與舊時代的手工技藝者差很少，骨子裏就有天生的技術崇拜，你寫的代碼比別人的優雅健壯高性能，你殺BUG比別人快速乾淨利索，就會受到你們的承認。

很天然地，更多偏向技術偏向深層次的工做就會落到你這裏，至少你會有話語權，有選擇作哪些事情的權利，是否要一直在圍繞着你最熟悉的業務去打滾是由你決定的。

學習武藝成爲「武林高手」，是成爲大BOSS以後纔沒必要長期面對蝦兵蟹將的糾纏。

學習一門具體的技術，也是爲了用它解決好問題，而後把它忘掉，去掌握那些更深層次的、更前沿，並且本身還不會的技術。

最後還有個追問和回答以下：

不知道你們看到這個回答後的感覺是怎麼樣的。

至少對我而言，振聾發聵。特別是這兩點：

• 不要輕視不直接產生實踐價值的知識；
• 不要對陷入已經被你熟練掌握的技術中不能自拔。

已經放入手機標籤中，時常提醒本身。

與君共勉。