最新章節
書友吧
品牌：人郵圖書
譯者：陸明剛 胡世杰
上架時間：2024-12-12 17:11:08
出版社：人民郵電出版社
本書數字版權由人郵圖書提供，并由其授權上海閱文信息技術有限公司制作發行
- 小結 更新時間：2024-12-12 17:55:02
- 13.4 對比延遲和急切初始化
- 13.3.3 利用不可變性
- 13.3.2 尾部遞歸優化
- 13.3.1 用非函數式語言寫函數式代碼
- 13.3 什么時候應該使用函數式編程
- 13.2.3 實現一個響應式方案
- 13.2.2 使用CompletableFuture
- 13.2.1 創建一個單線程阻塞式處理模型
- 13.2 什么時候應該使用響應式編程
- 13.1.2 使用依賴注入框架
- 13.1.1 DIY依賴注入
- 13.1 什么時候應該使用依賴注入框架
- 第13章 緊跟最新技術趨勢和維護舊代碼之間的權衡
- 小結
- 12.4.6 評估存儲格式
- 12.4.5 分離網絡API和存儲的數據格式
- 12.4.4 準備好面對未知
- 12.4.3 在存儲系統內部遷移數據
- 12.4.2 哪些是破壞性改動
- 12.4.1 簡要介紹Protobuf
- 12.4 數據存儲的版本管理
- 12.3.4 版本管理的其他考慮因素
- 12.3.3 常見的版本策略
- 12.3.2 用戶喜歡公開透明的版本策略
- 12.3.1 網絡API調用的環境
- 12.3 網絡API的版本管理
- 12.2.4 管理內部庫
- 12.2.3 處理破壞性改動的技術手段
- 12.2.2 依賴圖和菱形依賴
- 12.2.1 源碼、二進制和語義兼容性
- 12.2 庫的版本管理
- 12.1.4 營銷版本
- 12.1.3 語義版本規范
- 12.1.2 向后兼容性和向前兼容性
- 12.1.1 版本的屬性
- 12.1 版本管理的抽象思考
- 第12章 版本管理和兼容性
- 小結
- 11.5 用傳輸保證提供容錯能力
- 11.4.3 （最終）恰好一次傳輸語義
- 11.4.2 從最早或最晚的偏移量開始重啟
- 11.4.1 消費者手動提交
- 11.4 在消費者端實現不同的傳輸語義
- 選擇數據一致性還是系統可用性
- 11.3 生產者的邏輯
- 11.2.2 理解Kafka broker設置
- 11.2.1 Kafka消費者
- 11.2 基于Apache Kafka的生產者和消費者應用程序
- 11.1 事件驅動應用程序的架構
- 第11章 分布式系統的傳輸語義
- 小結
- 10.4 用原子性的邏輯避免競爭條件
- 10.3.2 多節點環境
- 10.3.1 單節點環境
- 10.3 在分布式系統里實現去重會遇到的常見錯誤
- 10.2 去重庫的簡單實現
- 10.1.4 理解CQRS
- 10.1.3 生成數據和冪等性
- 10.1.2 應用程序重試請求
- 10.1.1 單節點服務之間的網絡訪問
- 10.1 數據源的至少一次傳輸語義
- 第10章 分布式系統的一致性和原子性
- 小結
- 9.5.7 選擇第三方庫的檢查列表
- 9.5.6 安全和更新
- 9.5.5 庫和框架
- 9.5.4 軟件許可證
- 9.5.3 鎖定供應商
- 9.5.2 復用代碼的不同方式
- 9.5.1 第一印象
- 9.5 選擇和維護第三方依賴
- 9.4.2 太多的依賴
- 9.4.1 避免版本沖突
- 9.4 第三方庫的依賴
- 9.3.3 集成測試工具包
- 9.3.2 用偽造值和模擬函數來進行測試
- 9.3.1 測試庫
- 9.3 可測試性
- 9.2.2 分布式的可擴展性
- 9.2.1 使用異步和同步API
- 9.2 并發模型和可擴展性
- 9.1 引用一個庫就要對它的配置選項負責：小心那些默認配置
- 第9章 第三方庫：你所用的庫將成為你的代碼
- 小結
- 8.5.2 使用廣播的連接
- 8.5.1 不使用廣播的連接
- 8.5 用Apache Spark實現連接
- 8.4.4 基于內存的處理
- 8.4.3 計算訪問時間
- 8.4.2 我們為什么需要映射-化簡？
- 8.4.1 基于磁盤的處理
- 8.4 在內存還是磁盤中進行數據處理的權衡
- 8.3.3 利用廣播優化連接
- 8.3.2 需要數據移動的連接
- 8.3.1 在同一臺物理機上連接數據
- 8.3 連接多個分區上的大數據集
- 8.2.3 分區算法
- 8.2.2 分區和分片的區別
- 8.2.1 線下大數據分區
- 8.2 數據的分區
- 8.1.2 用數據本地性擴展數據處理
- 8.1.1 將計算移動到數據處
- 8.1 數據本地性是什么
- 第8章 利用機器的數據本地性和內存
- 小結
- 7.4.4 處理不斷變化的時區數據
- 7.4.3 處理不明確或者跳過的時間
- 7.4.2 發生在午夜時分的時區轉換
- 7.4.1 日歷計算
- 7.4 有必要單獨指出并測試的極端情況
- 7.3.4 通過注釋解釋代碼
- 7.3.3 以文本方式表示日期和時間
- 7.3.2 通過避免使用默認值提升可測試性
- 7.3.1 保持概念的一致性
- 7.3 實現日期和時間代碼
- 7.2.3 使用恰當的庫或者包
- 7.2.2 澄清日期和時間的需求
- 7.2.1 對范疇做界定
- 7.2 準備處理日期和時間信息
- 7.1.4 讓人頭疼的日期和時間概念
- 7.1.3 時區、UTC以及UTC偏移量
- 7.1.2 民用時間：日歷系統、日期時間以及期間
- 7.1.1 機器時間：時間戳、紀元以及持續時間
- 7.1 日期和時間信息的概念
- 第7章 高效使用日期和時間數據
- 小結
- 6.5.3 兩種方案用戶體驗與維護成本的比較
- 6.5.2 刪除流服務中某個配置
- 6.5.1 刪除批處理工具的某個配置
- 6.5 棄用/刪除云服務客戶端庫的某個配置
- 6.4.3 方案對比：用戶體驗的友好性vs維護成本
- 6.4.2 為流處理工具添加新配置
- 6.4.1 為批處理工具添加新配置
- 6.4 為云服務客戶端庫添加新的配置
- 配置流處理工具
- 6.3 一個將依賴庫的配置抽象化的工具
- 配置批處理工具
- 6.2 直接暴露依賴庫的配置
- 6.1.3 理解配置的機制
- 6.1.2 漫談認證策略
- 6.1.1 創建云服務客戶端
- 6.1 一個為其他工具服務的基礎庫
- 第6章 API的簡潔性vs維護成本
- 小結
- 5.5.3 調整性能測試，使用更多的輸入單詞
- 5.5.2 利用緩存優化word-exists程序
- 5.5.1 為現有代碼創建JMH基準測試
- 5.5 改進熱路徑的性能
- 5.4.2 使用MetricRegistry度量代碼路徑
- 5.4.1 使用Gatling創建API的性能測試
- 5.4 檢測代碼中的熱路徑
- 5.3.3 使用HTTP服務，向外提供單詞服務
- 5.3.2 驗證單詞是否存在
- 5.3.1 獲取每日一詞
- 5.3 具有潛在熱路徑的單詞服務
- 5.2.2 依據SLA配置線程（并發用戶）數
- 5.2.1 從軟件系統的角度理解帕累托法則
- 5.2 代碼中的熱路徑
- 5.1.3 對性能優化進行基準測試
- 5.1.2 依據錯誤的假設進行優化處理
- 5.1.1 構建賬戶處理管道
- 5.1 過早優化是萬惡之源
- 第5章 過早優化vs熱路徑優化：影響代碼性能的決策
- 小結
- 4.5 API的靈活性分析及維護開銷的權衡
- 4.4.2 設計的不可修改性
- 4.4.1 使用偵聽器與鉤子的取舍
- 4.4 通過偵聽器為你的API提供可擴展性
- 4.3.2 鉤子API的性能影響
- 4.3.1 防范鉤子API的過度使用
- 4.3 通過鉤子為你的API提供可擴展性
- 4.2 允許客戶使用自己的指標框架
- 4.1.2 從最簡單的代碼開始
- 4.1.1 設計一個新組件
- 4.1 一個健壯但無法擴展的API
- 第4章 靈活性與復雜性的權衡
- 小結
- 3.7 異常處理策略的性能對比
- 3.6.2 混合使用Try與拋出異常的代碼
- 3.6.1 在生產代碼中使用Try
- 3.6 使用Try以函數式的途徑處理異常
- 使用promise API處理異步工作流中的異常
- 3.5 多線程環境中的異常
- 3.4 源自第三方庫的異常
- 3.3.2 反模式：利用異常控制應用流
- 3.3.1 異常時，關閉資源
- 3.3 異常處理的反模式
- 3.2.2 公共API的未檢測異常處理
- 3.2.1 公共API的已檢測異常處理
- 3.2 代碼異常處理的最佳模式
- 捕獲所有異常vs更細粒度的錯誤處理方案
- 3.1 異常的層次結構
- 第3章 異常及其他——代碼錯誤的處理模式
- 小結
- 2.5.4 一貫性的重復與偶然性的重復
- 2.5.3 繼承與組合的取舍
- 2.5.2 繼承與緊耦合的取舍
- 2.5.1 抽取出一個請求處理器作為基類
- 2.5 利用繼承減少API設計中的重復
- 2.4 通過代碼重復改善松耦合
- 2.3.2 關于獨立微服務的總結
- 2.3.1 采用獨立微服務方式的取舍與弊端
- 2.3 抽取代碼為一個獨立的微服務
- 2.2.2 創建共享庫
- 2.2.1 共享庫的取舍與不足
- 2.2 通過庫在代碼庫之間共享代碼
- 2.1.3 結果評估
- 2.1.2 實現新的業務需求
- 2.1.1 添加新需求導致的代碼重復
- 2.1 代碼庫間的通用代碼及重復代碼
- 第2章 代碼重復不一定是壞事：代碼重復與靈活性的權衡
- 小結
- 1.3.3 微服務的復雜性
- 1.3.2 開發速度
- 1.3.1 可擴展性與彈性
- 1.3 架構設計模式及其失效分析
- 度量代碼
- 1.2 設計模式及其失效分析
- 1.1.2 單元測試與集成測試的比例
- 1.1.1 單元測試
- 1.1 決策的后果與模式
- 第1章 引言
- 關于異步社區和異步圖書
- 與我們聯系
- 提交勘誤信息
- 資源獲取
- 資源與支持
- 本書封面插圖介紹
- 喬恩·斯基特（Jon Skeet）
- 托馬斯·萊萊克（Tomasz Lelek）
- 作者介紹
- 關于本書的代碼
- 本書的組織結構
- 本書面向的讀者
- 本書介紹
- 致謝
- 前言
- 獻詞
- 內容提要
- 版權
- 版權信息
- 封面
- 封面
- 版權信息
- 版權
- 內容提要
- 獻詞
- 前言
- 致謝
- 本書介紹
- 本書面向的讀者
- 本書的組織結構
- 關于本書的代碼
- 作者介紹
- 托馬斯·萊萊克（Tomasz Lelek）
- 喬恩·斯基特（Jon Skeet）
- 本書封面插圖介紹
- 資源與支持
- 資源獲取
- 提交勘誤信息
- 與我們聯系
- 關于異步社區和異步圖書
- 第1章 引言
- 1.1 決策的后果與模式
- 1.1.1 單元測試
- 1.1.2 單元測試與集成測試的比例
- 1.2 設計模式及其失效分析
- 度量代碼
- 1.3 架構設計模式及其失效分析
- 1.3.1 可擴展性與彈性
- 1.3.2 開發速度
- 1.3.3 微服務的復雜性
- 小結
- 第2章 代碼重復不一定是壞事：代碼重復與靈活性的權衡
- 2.1 代碼庫間的通用代碼及重復代碼
- 2.1.1 添加新需求導致的代碼重復
- 2.1.2 實現新的業務需求
- 2.1.3 結果評估
- 2.2 通過庫在代碼庫之間共享代碼
- 2.2.1 共享庫的取舍與不足
- 2.2.2 創建共享庫
- 2.3 抽取代碼為一個獨立的微服務
- 2.3.1 采用獨立微服務方式的取舍與弊端
- 2.3.2 關于獨立微服務的總結
- 2.4 通過代碼重復改善松耦合
- 2.5 利用繼承減少API設計中的重復
- 2.5.1 抽取出一個請求處理器作為基類
- 2.5.2 繼承與緊耦合的取舍
- 2.5.3 繼承與組合的取舍
- 2.5.4 一貫性的重復與偶然性的重復
- 小結
- 第3章 異常及其他——代碼錯誤的處理模式
- 3.1 異常的層次結構
- 捕獲所有異常vs更細粒度的錯誤處理方案
- 3.2 代碼異常處理的最佳模式
- 3.2.1 公共API的已檢測異常處理
- 3.2.2 公共API的未檢測異常處理
- 3.3 異常處理的反模式
- 3.3.1 異常時，關閉資源
- 3.3.2 反模式：利用異常控制應用流
- 3.4 源自第三方庫的異常
- 3.5 多線程環境中的異常
- 使用promise API處理異步工作流中的異常
- 3.6 使用Try以函數式的途徑處理異常
- 3.6.1 在生產代碼中使用Try
- 3.6.2 混合使用Try與拋出異常的代碼
- 3.7 異常處理策略的性能對比
- 小結
- 第4章 靈活性與復雜性的權衡
- 4.1 一個健壯但無法擴展的API
- 4.1.1 設計一個新組件
- 4.1.2 從最簡單的代碼開始
- 4.2 允許客戶使用自己的指標框架
- 4.3 通過鉤子為你的API提供可擴展性
- 4.3.1 防范鉤子API的過度使用
- 4.3.2 鉤子API的性能影響
- 4.4 通過偵聽器為你的API提供可擴展性
- 4.4.1 使用偵聽器與鉤子的取舍
- 4.4.2 設計的不可修改性
- 4.5 API的靈活性分析及維護開銷的權衡
- 小結
- 第5章 過早優化vs熱路徑優化：影響代碼性能的決策
- 5.1 過早優化是萬惡之源
- 5.1.1 構建賬戶處理管道
- 5.1.2 依據錯誤的假設進行優化處理
- 5.1.3 對性能優化進行基準測試
- 5.2 代碼中的熱路徑
- 5.2.1 從軟件系統的角度理解帕累托法則
- 5.2.2 依據SLA配置線程（并發用戶）數
- 5.3 具有潛在熱路徑的單詞服務
- 5.3.1 獲取每日一詞
- 5.3.2 驗證單詞是否存在
- 5.3.3 使用HTTP服務，向外提供單詞服務
- 5.4 檢測代碼中的熱路徑
- 5.4.1 使用Gatling創建API的性能測試
- 5.4.2 使用MetricRegistry度量代碼路徑
- 5.5 改進熱路徑的性能
- 5.5.1 為現有代碼創建JMH基準測試
- 5.5.2 利用緩存優化word-exists程序
- 5.5.3 調整性能測試，使用更多的輸入單詞
- 小結
- 第6章 API的簡潔性vs維護成本
- 6.1 一個為其他工具服務的基礎庫
- 6.1.1 創建云服務客戶端
- 6.1.2 漫談認證策略
- 6.1.3 理解配置的機制
- 6.2 直接暴露依賴庫的配置
- 配置批處理工具
- 6.3 一個將依賴庫的配置抽象化的工具
- 配置流處理工具
- 6.4 為云服務客戶端庫添加新的配置
- 6.4.1 為批處理工具添加新配置
- 6.4.2 為流處理工具添加新配置
- 6.4.3 方案對比：用戶體驗的友好性vs維護成本
- 6.5 棄用/刪除云服務客戶端庫的某個配置
- 6.5.1 刪除批處理工具的某個配置
- 6.5.2 刪除流服務中某個配置
- 6.5.3 兩種方案用戶體驗與維護成本的比較
- 小結
- 第7章 高效使用日期和時間數據
- 7.1 日期和時間信息的概念
- 7.1.1 機器時間：時間戳、紀元以及持續時間
- 7.1.2 民用時間：日歷系統、日期時間以及期間
- 7.1.3 時區、UTC以及UTC偏移量
- 7.1.4 讓人頭疼的日期和時間概念
- 7.2 準備處理日期和時間信息
- 7.2.1 對范疇做界定
- 7.2.2 澄清日期和時間的需求
- 7.2.3 使用恰當的庫或者包
- 7.3 實現日期和時間代碼
- 7.3.1 保持概念的一致性
- 7.3.2 通過避免使用默認值提升可測試性
- 7.3.3 以文本方式表示日期和時間
- 7.3.4 通過注釋解釋代碼
- 7.4 有必要單獨指出并測試的極端情況
- 7.4.1 日歷計算
- 7.4.2 發生在午夜時分的時區轉換
- 7.4.3 處理不明確或者跳過的時間
- 7.4.4 處理不斷變化的時區數據
- 小結
- 第8章 利用機器的數據本地性和內存
- 8.1 數據本地性是什么
- 8.1.1 將計算移動到數據處
- 8.1.2 用數據本地性擴展數據處理
- 8.2 數據的分區
- 8.2.1 線下大數據分區
- 8.2.2 分區和分片的區別
- 8.2.3 分區算法
- 8.3 連接多個分區上的大數據集
- 8.3.1 在同一臺物理機上連接數據
- 8.3.2 需要數據移動的連接
- 8.3.3 利用廣播優化連接
- 8.4 在內存還是磁盤中進行數據處理的權衡
- 8.4.1 基于磁盤的處理
- 8.4.2 我們為什么需要映射-化簡？
- 8.4.3 計算訪問時間
- 8.4.4 基于內存的處理
- 8.5 用Apache Spark實現連接
- 8.5.1 不使用廣播的連接
- 8.5.2 使用廣播的連接
- 小結
- 第9章 第三方庫：你所用的庫將成為你的代碼
- 9.1 引用一個庫就要對它的配置選項負責：小心那些默認配置
- 9.2 并發模型和可擴展性
- 9.2.1 使用異步和同步API
- 9.2.2 分布式的可擴展性
- 9.3 可測試性
- 9.3.1 測試庫
- 9.3.2 用偽造值和模擬函數來進行測試
- 9.3.3 集成測試工具包
- 9.4 第三方庫的依賴
- 9.4.1 避免版本沖突
- 9.4.2 太多的依賴
- 9.5 選擇和維護第三方依賴
- 9.5.1 第一印象
- 9.5.2 復用代碼的不同方式
- 9.5.3 鎖定供應商
- 9.5.4 軟件許可證
- 9.5.5 庫和框架
- 9.5.6 安全和更新
- 9.5.7 選擇第三方庫的檢查列表
- 小結
- 第10章 分布式系統的一致性和原子性
- 10.1 數據源的至少一次傳輸語義
- 10.1.1 單節點服務之間的網絡訪問
- 10.1.2 應用程序重試請求
- 10.1.3 生成數據和冪等性
- 10.1.4 理解CQRS
- 10.2 去重庫的簡單實現
- 10.3 在分布式系統里實現去重會遇到的常見錯誤
- 10.3.1 單節點環境
- 10.3.2 多節點環境
- 10.4 用原子性的邏輯避免競爭條件
- 小結
- 第11章 分布式系統的傳輸語義
- 11.1 事件驅動應用程序的架構
- 11.2 基于Apache Kafka的生產者和消費者應用程序
- 11.2.1 Kafka消費者
- 11.2.2 理解Kafka broker設置
- 11.3 生產者的邏輯
- 選擇數據一致性還是系統可用性
- 11.4 在消費者端實現不同的傳輸語義
- 11.4.1 消費者手動提交
- 11.4.2 從最早或最晚的偏移量開始重啟
- 11.4.3 （最終）恰好一次傳輸語義
- 11.5 用傳輸保證提供容錯能力
- 小結
- 第12章 版本管理和兼容性
- 12.1 版本管理的抽象思考
- 12.1.1 版本的屬性
- 12.1.2 向后兼容性和向前兼容性
- 12.1.3 語義版本規范
- 12.1.4 營銷版本
- 12.2 庫的版本管理
- 12.2.1 源碼、二進制和語義兼容性
- 12.2.2 依賴圖和菱形依賴
- 12.2.3 處理破壞性改動的技術手段
- 12.2.4 管理內部庫
- 12.3 網絡API的版本管理
- 12.3.1 網絡API調用的環境
- 12.3.2 用戶喜歡公開透明的版本策略
- 12.3.3 常見的版本策略
- 12.3.4 版本管理的其他考慮因素
- 12.4 數據存儲的版本管理
- 12.4.1 簡要介紹Protobuf
- 12.4.2 哪些是破壞性改動
- 12.4.3 在存儲系統內部遷移數據
- 12.4.4 準備好面對未知
- 12.4.5 分離網絡API和存儲的數據格式
- 12.4.6 評估存儲格式
- 小結
- 第13章 緊跟最新技術趨勢和維護舊代碼之間的權衡
- 13.1 什么時候應該使用依賴注入框架
- 13.1.1 DIY依賴注入
- 13.1.2 使用依賴注入框架
- 13.2 什么時候應該使用響應式編程
- 13.2.1 創建一個單線程阻塞式處理模型
- 13.2.2 使用CompletableFuture
- 13.2.3 實現一個響應式方案
- 13.3 什么時候應該使用函數式編程
- 13.3.1 用非函數式語言寫函數式代碼
- 13.3.2 尾部遞歸優化
- 13.3.3 利用不可變性
- 13.4 對比延遲和急切初始化
- 小結 更新時間：2024-12-12 17:55:02
