後端好書閱讀與推薦（續八）

後端好書閱讀與推薦系列文章：
後端好書閱讀與推薦
後端好書閱讀與推薦（續）
後端好書閱讀與推薦（續二）
後端好書閱讀與推薦（續三）
後端好書閱讀與推薦（續四）
後端好書閱讀與推薦（續五）
後端好書閱讀與推薦（續六）
後端好書閱讀與推薦（續七）
後端好書閱讀與推薦（續八）

阿里巴巴Java開發手冊

阿里巴巴Java開發手冊 (豆瓣): https://book.douban.com/subje...

阿里在Java技術方面具備廣闊而深刻的研究和應用，而本書正是阿里技術團隊的集體智慧結晶和經驗總結，很是值得借鑑和學習。

亮點：

• 現代軟件行業的高速發展對開發者的綜合素質要求愈來愈高，由於不只是編程知識點，其它維度的知識點也會影響到軟件的最終交付質量。的確是這樣，這一行不存在「一招鮮吃遍天」的說法，每一個人都要進行普遍而深刻的終身學習
• 現代軟件架構的複雜性須要協同開發完成，如何高效地協同呢？無規矩不成方圓，無規範難以協同。適當的規範絕對不是扼殺創新性，而是管理軟件複雜度的一種手段
• 爲了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡可能完整的單詞組合來表達其意。不要嫌長，畢竟這是Java的一大特點(*￣︶￣)
• 任何類、方法、參數、變量，嚴控訪問範圍。過於寬泛的訪問範圍，不利於模塊解耦。變量像本身的小孩，儘可能在本身的視線內，變量做用域太大，無限制的處處跑，那麼你會擔憂的。這一句說的很貼切
• 在高併發場景中，避免使用」 等於」 判斷做爲中斷或退出的條件。若是併發控制沒有處理好，容易產生等值判斷被「擊穿」 的狀況（亦即瞬時狀態跳變），使用大於或小於的區間判斷條件來代替能夠保證必定能終止
• 捕獲異常與拋異常，必須是徹底匹配，或者捕獲異常是拋異常的父類。若是預期對方拋的是繡球，實際接到的是鉛球，就會產生意外狀況。
• 好的單元測試必須遵照 AIR 原則：Automatic（自動的，不要人工的print而是自動的Assert）、Independent（獨立的，不依賴於其餘單元測試、也不依賴於其餘模塊，必要時能夠Mock）、Repeatable（可重複執行，支持持續集成）
• 對用戶相關的數據要作校驗（防止攻擊）、鑑權（防止越權操做）、脫敏（防止信息泄露）、轉義展現（避免代碼邏輯泄露，或者讓用戶懵逼），還要作防刷（避免資損或騷擾用戶）、違禁詞過濾等風控策略
• MySQL中 varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，若是長度大於此值，定義字段類型爲 text，獨立一張表，用主鍵對應，避免影響其它字段索引效率（由於MySQL是按行存儲的）
• 分層設計中，Dao層異常不要打印，而是直接拋出，由於Service層必定會藉助日誌並記錄；web層毫不應拋出異常，由於已處於頂層，應本身記錄，並選擇合適頁面渲染給用戶；對於領域對象，DO與數據表一致,DTO是service向外傳輸對象,BO是Service層封裝的業務邏輯對象,AO是Web與Service之間的複用對象模型,VO是顯示層對象,Querry是上層給下層的查詢對象

書比較薄，涉及面也較廣，能夠把本書當作一個目錄，咱們本身按需去發散，針對每一個方面進行更深刻的學習。
此外本書還有進階版，能夠看作是對本書的一個擴充。

Clean Architecture

Clean Architecture (豆瓣): https://book.douban.com/subje...

本書是代碼整潔之道做者 Robert C·Martin 的Clean系列的最新大做，譯爲架構整潔之道，是做者多年軟件架構經驗的合集，值得細細品味。

亮點：

• 軟件架構的終極目標是用最小的人力成原本構建知足和維護該系統的需求。若是你以爲好的架構太費錢，大可看看先用隨意的架構而後再慢慢改的成本，事實上國內好多公司也是這樣作的，都是快速擴張追求速度，後面再慢慢還技術債。從軟件開發的角度看，一開始偷懶妄想後期重構是不大可能的（由於市場的壓力永遠不會消退，你永遠都在完成新功能，重構舊代碼的機會不會再有了，系統愈來愈亂），因此精心設計的架構的確對後來的工做有好處，可是我以爲對於須要快速搶佔市場的應用，先跑起來纔是王道，這是已經超出了軟件開發的範疇的理念。
• 軟件的價值來自於兩個維度：行爲（業務邏輯，是直接產生利潤的價值，也是大多數人惟一關注的價值）和架構（軟件的靈活性，具體下來能夠理解爲可擴展性、複雜性管理等，這部分價值常被人忽略，但確是軟件能夠持續低成本地產生行爲價值的基礎，也是軟件之因此「軟的緣由」）。若是用艾森豪威爾矩陣來衡量，行爲價值是緊急的，但並不老是特別重要，架構價值是重要的，但並不老是特別緊急。咱們須要很好的平衡這兩個價值
• 結構化編程限制了goto語句，賦予了咱們創造可證僞程序單元的能力，相應的，在架構領域，功能性降解拆分是最佳實踐之一；C支持完美的封裝，部分支持繼承（結構體超集），支持多態（函數指針模擬，getchar、putchar等函數），因此這三大特性並不能表明OOP，OOP的真正精髓在於對於程序間接控制權的轉移，亦即安全的多態（好比Java將函數指針封裝到jvm中，程序員不可直接用指針了），這種多態能方便地實現依賴反轉（implemention源碼依賴於interface，控制流和源碼依賴相反），讓底層組件插件化，獨立於高層組件進行開發和部署（邊界劃分的藝術）；函數式編程中變量（叫參數更好）不可變，借鑑到架構中就是隔離不可變與可變的部分（咱們目前作不到徹底不可變性，要麼速度太慢，要麼空間過小，若是有足夠的空間和速度，就能夠實現只需CR而不是CRUD的程序）
• 軟件構建的底層目標（也就是具體的代碼邏輯，類比磚頭）應遵循「整潔之道」；中層目標（也就是組件，類比房間）是軟件可容忍改動、更易理解、組件可複用，應遵循SOLID原則（是設計類和模塊適用的原則，在架構領域也適用）；高層目標（也就是軟件系統。類比建築）要遵循複用和發佈等同（爲複用而組合）、共同閉包（爲維護性而組合）、共同複用（爲避免沒必要要的發佈而切分）三個原則，這三個原則互相牽制，架構師要在這三者中找到平衡；組件之間要避免循環依賴，打破循環依賴的方式有DIP、建立新組件兩種方式，依賴要指向更穩定的方向
• 軟件架構師首先是程序員，也許不是代碼量最多的，可是應該親自承接編程任務，否則體會不到不良設計帶來的麻煩，逐漸就會迷失正確的設計方向；軟件架構的最高優先級是系統正常工做，同時也要保留儘量多的選項（這是讓系統好理解、可擴展、易修改，爲其未來正常工做打下基礎），架構是要考慮軟件系統的全週期，而非僅是當前；軟件架構的目標是讓系統的策略和細節分離，以容許具體決策過程當中推遲與細節相關的內容，留下更多的選項
• 咱們常說「Don't repeat yourself」，頗有可能就陷入了見到重複就消滅的應激模式中，事實上，要區分真重複和假重複，若是兩段代碼走的是不一樣的演進路徑，那麼即便他們如今看起來比較像也要即時分開，否則後期的改動就會難如下手

我發現老外寫書大體有兩種風格，一種是大部頭，經書似的。這種書看着人頭疼，可是每每能把一個領域說的很是清楚和考究，屬於科研派的，好比TCP/IP詳解 卷1：協議這種；另外一種是散文似的，每一部分都短小精悍，看着也不累，好比Head First 設計模式。這本書顯然是後者，感受學了很多，也不以爲累，究其緣由我想是由於本書通篇就反覆講了一個概念：隔離變化（重要的事情說三遍？），因此看完仍是感受稍微有點水。

可伸縮架構

可伸縮架構：面向增加應用的高可用 (豆瓣): https://book.douban.com/subje...

高可用是咱們作系統的人不變的追求，本書就是該領域的一部佳做，從可用性談起，介紹了監控並提升可用性的方法，而後重點講了風險管理和伸縮性，最後講了最近幾年流行的微服務和逐漸成爲主流趨勢的上雲。看完以後就能對高可用這個概念有一個全面系統的瞭解。

亮點：

• 程序員一開始接觸的是一個肯定性的世界，什麼樣的輸入就有什麼樣的輸出，可是在面對分佈式系統時首先要認可的就是不肯定性，不能再把系統看作單體應用那樣穩定，要充分考慮不肯定狀態（機器自己、代碼質量、網絡等因素所致），並把整個系統的不肯定性因素梳理出來，做爲風險進行管理，制定相應的措施，並持續地進行測試和評估，避免問題發生時手足無措
• 提升可用性的5個要點：時刻考慮應對故障（everything can fail at anytime，因此要爲故障作出計劃）；時刻考慮應對伸縮（具有快速擴展數據庫、應用等的能力）；緩和風險（風險不能徹底消除，可是應該作出緩和風險亦即下降問題帶來的影響的努力）；監控可用性（眼睛，問題定位）；以可預期及明確的方式來處理可用性問題（對監控出的問題進行標準化流程處理，下降不可用時間）
• 計劃和平常維護致使的不可用時間也應計算在可用性百分比之中，由於用戶只在意可用與否，而無論你是意外故障仍是計劃維修
• 可用性降低時有幾點能夠作：首先要跟蹤並測量可用性（包括關鍵事件如變動和可用性之間的關係）；手動流程自動化（人肉操做不靠譜，自動化操做則有預期、可審查、可重複、易版本控制和回滾）；關注一致性、可重複性、標準的配置管理流程
• 風險管理就是在消除風險的成本與風險發生的成本之間保持平衡，其第一步就是列出全部已知風險，包括可能性和危害性並依此分級（最嚴重的風險天然就是可能性大、危害性大的），制定風險緩和措施（下降可能性和危害性，危險性更要首先關注）來控制風險並按期檢查和持續維護（比賽日，也就是容災演練）。當風險仍然不可避免的發生後採用恢復計劃（風險發生後採起的行動，也屬於風險緩和措施，如容災計劃）下降問題的危害性
• 如何從根本上緩和風險呢？那就是從一開始就考慮構建低風險系統，要素有：冗餘（合適的冗餘能夠下降總體故障機率，可是過分冗餘帶來了複雜性，反而增長了風險）、冪等接口（經過簡單重試避免失敗）、獨立性（看似冗餘的服務若是運行中同一個物理機或者機架上那就不獨立了）、簡單（微服務下降了單體複雜性，可是服務數量增多也帶來了構建大規模系統的總體複雜性，因此構建微服務要在單個服務和總體應用之間的複雜性作權衡，這個權衡取決於你的系統、組織和公司文化）、自修復（人工修復會顯著下降可用性，好比半夜你還得先起牀，因此要自修復，好比負載均衡自動剔除壞server、熱備數據庫自動上線等）、自動化流程（人老是會犯錯）
• 微服務主要解決的是單體程序臃腫難理解、沒法多組人員並行開發、難以測試、發佈緩慢等問題，且能夠給更重要的業務單獨增長更多資源，固然這個進步的前提是服務之間邊界明確且獨立（代碼庫、數據、API、Owner的權利和責任），不然既不能解決這些問題，反而因爲組件數量增多而增長了系統的複雜性。服務邊界劃分的原則有：業務需求、團隊全部權、自然隔離的數據、對外服務的能力
• AWS的可用區針對不一樣用戶來講是不一樣的，主要是爲了負載均衡，避免用戶集中選擇字母表中靠前字母的可用區，致使負載不均，同一個數據中心對甲是a可能對乙就是b，這個設計仍是挺巧妙的

文中說可靠性很容易經過測試解決，因此主要講了可用性，可是分佈式數據一致性、持久化等也應屬於可靠性，可是很難測試，因此書裏的可靠性定義仍是狹隘了一點，僅指傳統軟件測試方面的。並且我以爲廣義上的可靠性應該是包含正確性和可用性兩方面的，而廣義上的可用性又包含能用和性能兩方面（好比你的一個簡單的服務雖然能用，可是RT是5分鐘也可認爲該服務是不可用的）。
另外後面關於雲計算方面的內容稍有注水和廣告之嫌，畢竟按固定量和使用量的方式分配資源這種話題太過淺顯（雖然也屬於伸縮性的範疇）。

軟件架構師的12項修煉

軟件架構師的12項修煉 (豆瓣): https://book.douban.com/subje...

架構師的技術能力屬於硬技能，關係技能、我的技能和商務技能等屬於軟技能。在商業化的社會，硬技能的確很是重要，是咱們生存的基礎，可是軟技能也一樣重要，是咱們擴大影響力和業務面的基礎，能幫咱們超脫技術自己，爲公司創造利潤，爲社會創造價值。這本書就着重幫咱們培養這些軟技能，而且基本按照原則、策略等要點來組織，很是有條理。

亮點：

• 對於更高職位的人而言，深諳技術細節當然有用，但能力已經開始向與別人成功交互方向傾斜，爲了將事情辦成而傾銷其觀點，一個項目要成功，支付帳單的人要得到最大回報其實並不必定須要完美的技術解決方案，因此趕上爭執首先問本身：糾正重要嗎？不糾正公司會付出很大成本嗎？很大可能答案是不，此時最好就是保持平靜而非面紅耳赤，記住人不是軟件（有問題就必定要立馬解決），人有情緒，因此要時刻保持文雅
• 就像好的web服務同樣，你應採用「無狀態」的方式——只對當前輸入作出響應（而不是好久以前別人對你冒犯），畢竟你的腦子是能處理幾件事，不要將你的精力浪費在過期、無用的信息上，記住你學會的知識，放下不快的事情，你會成爲一個真正進步、快樂的人
• 架構師一般不能直接管理別人，這樣指示別人完成特定行動的能力就受到限制了，因此真正有效的手段就是你的影響力，一方面體如今你的專業知識上，另外一方面就是溝通技能
• 出於本能，當別人說出對咱們不是正面意義的話的時候咱們每每會找藉口、轉移話題或者責怪別人，但事實上別人不必定出於惡意，先想一想本身能從別人的話中獲得改進嗎？若是是，則是你成長的機會，因此要避免這種本能
• 咱們經常會說「我早就告訴你會這樣」，是下意識的想展現本身的優越感或者甩鍋，可是這樣對團隊合做與項目進度毫無用處，因此要想成爲一名好的team worker，咱們要扔掉許多下意識的東西，而且嘗試去了解肢體語言和心理學能夠幫你更好的進行協商
• 管理是將事情作對，而領導力是作對的事。應該經過影響而不是要求別人來作一件事纔是真正的領導力。領導力創建於信任之上，是爲了創建一種共識，取決於創建戰略伙伴關係和身體力行的能力。
• 透明化能爲本身和他人帶來清晰性，讓公司充分評估風險。包括三大類：自我透明，向別人充分展現本身，不隱藏，讓別人可信賴並對你有合理的期待；項目透明，展現項目的優缺點、風險、成本和假設條件，讓別人也能夠充分參與決策；關係透明，給別人信任，傾聽，讓別人對你也透明
• 激情是推進你事業進步的內在動力
• 商務就是爲了賺錢，瞭解一些商務知識能夠大大促進你瞭解夥伴（市場、銷售）、領導和客戶的能力，能幫你作出真正有商業價值的產品。
• 創新不會憑空而來，須要多閱讀（書記、博客等），這樣你纔有知識儲備，在你面臨一個挑戰性問題時，你纔有原材料進行創新；平時有了點子均可以記錄下來（好記性的確不如爛筆頭，並且現在你們都很忙，不少想法不記錄就溜走了），這就是未來靈感的種子

這本書還有個好處就是全書都在培養咱們問本身問題的習慣，趕上一件事時先全方位多角度地問本身若干問題，而後再下手，這樣纔不會片面，不會走入「錘子與釘子」的桎梏，纔能有更寬闊的眼界，走向創新的大門。
另外說一點和書不要緊的話，咱們工做中本身是錘子，不能看見啥都是釘子，這樣容易走入死衚衕。可是咱們本身是錘子，看見啥都要想想是否是釘子，這樣纔有可能發揮本身工做的最大價值。
最後，我以爲本書不僅是架構師須要，而是各行各業的各種人都須要。

和秋葉一塊兒學PPT

和秋葉一塊兒學PPT (豆瓣): https://book.douban.com/subje...

若是說代碼能力、架構能力等技能屬於咱們的硬實力，那麼表達能力、溝通能力就是咱們的軟實力，只有軟硬兼修才能立於不敗之地。在現在的學習和工做中，少不了彙報、組會等，製做一個好的PPT能幫咱們更好地表達、展示和溝通。經過本書能夠學到PPT的製做技術，並且書自己就能夠看作一個素材庫，針對不一樣行業、場合，幫助你選擇不一樣的風格和素材，適合長留案邊，以備不時之需。

亮點：

• 感受寫書和寫PPT有共性，做者一開始就把本身的書和其餘書做對比，強調突出了本身的優點（好比同名微博+微信+書籍，打造學習閉環），一會兒就把我震住了，可見PPT作得好不只能會說，還能會寫書，好處多多
• 從結果導向來講，仍是要關注業務。office2003出來後，一衆發燒友作了一大堆複雜動畫模擬翻書切換效果，結果office2010直接一鍵實現，因此對於好多工具（好比開發語言、中間件）不必耗費時間徹底搞清楚它全部花裏胡哨看起來高大上的特性，而是要關注業務的實現，在必要的時候再去了解特性（由於所謂特性其實很容易過期）
• serif（有襯線字體），在字的筆畫開始、結束的地方有額外的裝飾，且筆畫的粗細有所不一樣；反之，sans serif 沒有額外的裝飾，且筆畫的粗細差很少。投影狀態下受設備影響，大字部分適合serif（透氣、美觀） ，小字部分適合sans serif（簡潔、識別度高、有衝擊力）；此外，不一樣字體的使用要注意法律風險
• 打造一個高大上的PPT其實也是有章可循的，通常四步走起：統一字體、突出標題、巧取顏色（經過沿用logo或企業VI用色對PPT進行簡單配色）和快速搜圖（用關鍵詞搜圖法對PPT進行配圖）
• ......

這本書連真小白均可以看，因此老手們要跳着看啊，否則浪費不少時間（好比教你怎麼下百度雲，￣□￣｜｜）。

Kubernetes in Action

Kubernetes in Action中文版 (豆瓣): https://book.douban.com/subje...

xx in action 系列的書一直不錯，既有原理性的解讀，又有實戰性的上手指導，閱讀價值很是高。而k8s做爲雲原生的表明技術，很是值得學習。

亮點：

• Kubermetes 抽象了數據中心的硬件基礎設施，使得對外暴露的只是一個巨大的資源地，能夠被看成集羣的一個操做系統 看待，它讓咱們在部署和運行組件時，不用關注底層的服務器，使開發者能夠自主部署應用，徹底脫離運維團隊的幫助，同時能讓運維團隊監控整個系統，而且在硬件故障時從新調度應用，系統管理員的工做重心，從監管應用轉移到了監管 Kubermetes，以及剩餘的系統資源，由於 Kubermetes 會幫助監管全部的應用
• 做者不喜歡先解釋事物是如何工做的，而後再解釋它的功能並教人們如何使用它 。 就像學習開車，你不想知道引擎蓋下是什麼，你首先想要學習怎樣從 A 點開到 B 點 。只有在你學會了如何作到這一點後，你纔會對汽車如何使這成爲可能產生興趣。畢竟，知道引擎蓋下面是什麼，可能在有一天它拋錨後你被困在路邊時，會幫助你讓車再次移動
• 一個 pod 是一組緊密相關的容器，它們老是一塊兒運行在同一個工做節點上，以及同一個 Linux 命名空間中。爲何發明了pod的概念呢？ 首先，容器被設計爲每一個容器只運行一個進程（除非進程自己產生子進程），若是在單個容器中運行多個不相關的進程，那麼保持全部進程運行、管理它們的日誌等將會是咱們的責任，因此不能將多個進程彙集在一個單獨的容器中，咱們須要另外一種更高級的結構來將容器綁定在一塊兒，並將它們做爲一個單元進行管理，這就是 pod 背後的根本原理
• 註解也是鍵值對，因此們本質上與標籤很是類似，但註解並非爲了保存標識信息而存在的，通常用來保存更多的信息，而標籤更像是索引。此外，向Kubemetes引入新特性時，一般也會使用註解，通常來講，新功能的alpha和beta版本不會向API對象引入任何新字段而是用註解，當API更改變得清晰並獲得全部相關人員的承認，就會引入新的字段並廢棄相關注解。
• 儘管工做節點上的組件都須要運行在同一個節點上，控制平面的組件能夠被簡單地分割在多臺服務器上。爲了保證高可用性，控制平面的每一個組件能夠有多個實例。etcd和API服務器的多個實例能夠同時並行工做，可是調度器和控制器管理器在給定時間內只能有一個實例起做用，其餘實例處於待命模式
• 控制器執行一個「調和」循環，將實際狀態調整爲指望狀態（在資源spec部分定義），而後將新的實際狀態寫入資源的 status 部分。控制器監聽API Server來訂閱變動，但使用監聽機制並不保證不漏掉事件，因此仍然要按期執行重列舉操做來確保不會丟掉什麼
• ......

Kubernetes網絡權威指南

Kubernetes網絡權威指南：基礎、原理與實踐 (豆瓣): https://book.douban.com/subje...

本書是要不要推薦我其實猶豫了一下，由於本書有許多代碼，有充數之嫌，並且在闡述上有許多不清晰的地方。可是我仍是推薦給你們，由於本書勾勒了一個基本上完整的k8s網絡大圖，值得通盤瞭解。

亮點：

• 結合CNM，Libnetwork要達成的效果是，用戶能夠建立多個網絡，也能夠建立多個容器，最後選擇讓容器加入某個網絡，從而使容器和網絡分離，讓開發者專一於本身感興趣的地方
• 要支持大規模的容器集羣，網絡纔是最基礎的一環，其中的挑戰是「以隔離的方式部署容器，在提供隔離本身容器內數據所需功能的同時，保持有效的鏈接」，隔離和鏈接是兩個矛盾可是又缺一不可的關鍵詞
• Overlay是指在傳統底層網絡上構建一個虛擬網絡，底層網絡不需作任何適配，虛擬網絡在底層網絡上進行封包拆包完成通訊，L2 overlay是一個大二層的概念，大是指這個網絡能夠跨越數據中心，二層是指通訊雙方在一個邏輯網段內，支持容器遷移而不用改變Ip的特性，L3 overlay相似，可是在節點上增長網關（不一樣節點網段能夠不一樣），節點內通訊走L2,節點間走L3；Underlay是指底層網絡，傳統組網就是underlay類型，L2 underlay就是2層互通的網絡，L3 underlay就是L3互通的網絡
• Docker在容器的普及和迅速推廣起到了很是重要的做用，可是它也正在集成網絡、編排等功能，勢必會被k8s弱化其做用，而擁抱更輕量的容器技術好比containerd、cri-o等
• k8s網絡策略和一些安全組在某些功能上有重疊，可是區別也較爲明顯，安全組通常記錄在上層網關，網絡策略則實施在每一個節點上，節點上的agent須要watch pod、namespace、policy等資源
• Linux內核在作SNAT時，因爲端口分配和將鏈接插入contrack表存在時延，可能致使端口衝突而丟包（尤爲是高併發模式下），因此不推薦在生產環境使用nodePort模式
• 受制於k8s的基於客戶端的負載均衡架構（由每一個節點的kube-proxy決定real server），即便用了支持多種負載均衡算法的ipvs也很難支持，好比least-connection算法，每一個kube-proxy只能知道本身連接數最小的rs，而不能知道全局最小的rs
• Flannel 經過監視etcd獲取可用ip範圍，在啓動容器時指定ip範圍，從而使得不一樣節點成爲一個子網，容器ip不重複；經過overlay（用戶態udp或內核態的vxlan）或者host-gateway（直接刷節點路由表，因爲不能刷路由器因此須要節點2層可達）的方式實現容器間通訊。Calico 也是經過相似的刷節點（虛擬路由器）路由表來實現容器通訊，可是因爲採用了BGP協議，其模擬的路由表信息能夠被傳遞到其它路由設備中，直接實現了3層網絡通訊
• BPF 能夠理解爲一個高性能沙箱，使得內核變成可編程，內核有其加持後，linux的安全則不侷限於傳統的ip+port的包過濾模式，內核能夠理解什麼是微服務、安全性如何等問題。Cilium就把BPF帶入了K8S

大型系統應用架構實戰

大型系統應用架構實戰：部署、容災、性能優化 (豆瓣): https://book.douban.com/subje...

本書做爲阿里全球化的經驗沉澱之做，不只介紹了宏觀的架構策略，還探討了具體的算法實現，很是值得急速擴張的互聯網公司借鑑。
此外，本書展示出來的知識面也告訴咱們，要想做一個優秀的架構師，既要了解業務，也要了解技術，這樣才能作出最適合業務的技術方案

亮點：

• 互聯網的本質是提升信息傳遞的效率，它極大地促進了全球化，而全球化對技術有以下幾個要求：性能、可用性、互聯互通、數據一致性、隱私保護、本地化對接、可伸縮性
• 區域化部署技術的本質是多層路由，每一層都要基於用戶來調用路由服務，肯定該用戶所屬的機房。而多層路由的最佳方式是接入層RPC調用路由服務後緩存起來（有必定的失效期）並透傳給下面的服務層、消息層和數據層。有人可能會問了，都在接入層判斷了，爲啥後面每一層都要再判斷一次？由於有可能路由服務變動了，還有可能一份數據被多個用戶共享，因此每一層都要作路由決策
• 區域化容災技術，在進行災備切換時並不須要更新整個機房的用戶路由表，也不會由於徹底依賴DNS切換而必須等待DNS失效，由於區域化部署已經提早在路由服務中準備好了災備機房，因此在統一接入層便可完成災備切換，即便統一接入掛了，也只是會影響部分用戶而不會帶來危害
• ......

後記

有時候會以爲「知道了許多道理，卻依然過很差這一輩子」，看了許多書，卻以爲本身依然沒有進步。我以爲主要有兩點，一是看書要帶着思考去看，不要用眼睛過一遍就完事了，要對書中的內容多想一想：書裏說的對不對？若是是對的我有沒有作到？書對個人學習和工做有實際價值嗎？等等，多問幾個問題書裏的內容就能天然而然轉化爲本身的知識，日常和別人交流就能用上了。二是要及時地把書中的知識運用起來，並有意識的對本身進行相應的訓練，好比對於很內向的人，看了《架構師修煉這本書》後就能夠好好實踐一下透明化這一章節，多展現本身，讓別人瞭解並信任你，這就是你的進步。

查看原文，來自MageekChiu。