摘要：持續交付持續交付豆瓣微服務離不開，而核心就是幾點自動化連續小范圍快速可靠。敏捷革命敏捷革命提升個人創造力與企業效率的全新協作模式豆瓣實際上正是敏捷開發的最佳實踐，有了前面的鋪墊，我們可以通過這本書我們來真正了解敏捷開發的全貌。

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

Spring微服務實戰 (豆瓣): https://book.douban.com/subje...

Spring體系用來做微服務在當下可謂是風頭正勁，這本書就用一個實例來手把手教我們實現微服務。實戰系列的口碑一直不錯，這本也不例外，看完就可以對微服務的概念有一個完整的理解，并且想上手也有路可尋。

亮點：

編碼就像藝術，是一種創造性活動。構建分布式應用就像指揮一個管弦樂隊演奏音樂，是一件令人驚奇的事情

微服務是一個小的、松耦合的分布式服務，分解和分離大型復雜應用程序的功能，使它們獨立，這樣負責每個功能的團隊都擁有自己的代碼庫和基礎設施，技術不限，能靈活地獨立開發部署，職責分離，降低團隊協作成本。隨著云的普及，微服務單元的增減（每個服務單元都是完整的）變得非常容易，使得整個應用更具彈性伸縮能力。Spring勇于自我革新，當初出場取代了沉重的J2EE，后面的Spring Boot使用簡單注解去掉了自己原本繁重的配置，后來的Spring Cloud更是為分布式服務提供了一套完整的解決方案，所以Spring體系是我們構建微服務的絕佳選擇

微服務構建的一個關鍵是劃分，而劃分的一個關鍵是粒度，這個沒有絕對標準，但是有幾個原則：開始可以讓服務設計范圍大一些，后續可以重構至更小的服務；重點關注服務之間如何交互；隨著對問題域的理解變化，服務的職責也要變化（演化思維）。需要注意微服務的幾個壞味道（太粗；太細）：職責過多，跨表超過5個，URL太長，測試用例太多；數量巨大、彼此依賴嚴重、成為簡單的curd、只在一個表操作等

微服務沒有標準，但是作者提出了12種最佳實踐：獨立代碼庫、顯式依賴、配置存儲、后端可切換、構建發布運行必須完整、進程無狀態、端口命令行制定、橫向擴展并發、可down可up、環境一致、日志流式處理、管理腳本化。微服務的生命周期：裝配、引導、發現、服務和監控、關閉

少量程序可以使用低層級文件（YAML、json、XML）來存儲配置，將其與代碼分開，但是到了數百單元（每個單元可能有多個實例）時就不行了。手動管理既慢又復雜還可能配置漂移，這時應該引入配置管理工具（etcd、eureka、consul、zookeeper、spring cloud config等），服務啟動時通過環境變量注入配置或者從集中式存儲中獲取

服務發現提供了快速水平伸縮的能力，且當服務不健康時可以快速刪除，還能取代傳統的手動管理負載均衡。主要涉及服務注冊、客戶端服務地址查找、信息共享、健康監測4個方面

一般大家關注高可用都是某個組件徹底不可用（容易檢測）的情況，但是一個性能不佳而沒有完全垮掉（不易檢測）的服務也可以徹底拖垮整個應用，因此也需要保護這些不佳服務，避免連鎖效應，導致徹底不可用。一般有客戶端負載均衡（Ribbon）、斷路器、后備、艙壁（Hystrix）等四個彈性模式來實現保護緩沖區

AOP的思想幫我們分離關注點，那么要在微服務中實現靠啥？答案就是網關（比如Zuul，核心就是反向代理）了，我們可以在網關中實現驗證授權、數據搜集與日志等關注點，但是要注意，避免網關成為單點要注意使其輕量且無狀態（無狀態就可以很容易擴展，而服務發現必須有狀態，所以要擴展還要用Gossip等協議來同步狀態數據，保障一致性和可用性）

安全注意事項：都要使用HTTPSSSL、所有服務都要經過網關、將服務劃分為公共API和私有API、封鎖不必要的端口來限制微服務的攻擊面

微服務不是單體，其好處是靈活，代價就是解決問題時難以定位，所以需要追蹤并聚合日志，最終定位問題。spring cloud 給每一個事務開啟之前注入關聯ID（一般由網關完成），每個服務都可以傳播關聯ID并將其添加進日志中，這些日志被統一發送到日志聚合點中，就可以供我們統一檢索了，常見實現有ELK、Splunk等。光能檢索還不夠，一張直觀的事務流圖抵過1萬條日志，Sleuth和ZipKin一起可以實現該功能

微服務強調靈活迅速，所以一個成熟的構建與部署管道（引入CI/CD）必不可少：提交代碼、自動構建（鉤子實現）、構建期間進行單元測試與集成測試后獲得一個jar（自包含tomcat）、用jar構建并提交機器鏡像、在新環境中拉取機器鏡像并進行平臺測試后啟動鏡像、每個新環境都要重復前面一個步驟

書很厚，所以很多具體工具可以跳過，嘗試幾個即可，將來使用的時候知道這本書里有就行了。

持續交付 (豆瓣): https://book.douban.com/subje...

微服務離不開CI/CD，而CI/CD核心就是幾點：自動化、連續、小范圍、快速、可靠。我們通過這本書來了解CI/CD，也看看持續交付是如何解決“Last Mile”問題，讓軟件交付不再令人緊張，成為一件簡單平常的事情。

亮點：

從決定修改到結果上線的時間為周期時間，CI/CD技術能讓周期從傳統手段的周月單位變成小時甚至分鐘級別（產品快速落地，降低機會成本），發布過程可靠可重復（減少錯誤與人力資源），核心技術就是部署流水線（一個應用從構建、部署、測試到發布這整個過程的自動化實現，過程中需要的所有東西包括需求、源碼、配置、腳本、文檔、運行環境等都要納入VCS的管理，但是結果性的東西比如二進制鏡像就不用，因為它可以隨時構建得到，作者羅列了一些相應的工具）

提出了一些反模式，讓我們避免：手工部署軟件（復雜 不可重復和審計 易出錯）、開發完成之后才向類生產環境部署（不確定性很大 發布有風險）、生產環境手工配置管理（不能完全掌握 不可重復）。同時也提出了一些應該遵循的正面原則

持續集成的前提是版本控制、自動化構建、團隊共識，需要做到頻繁提交、自動化測試、保持構建和測試過程較短、管理開發工作區、構建失敗之后修復成功之前不能提交新代碼、提交之前自己運行測試、提交測試通過之后再繼續工作、時刻準備回滾（回滾之前要有一個修復時間）、為自己的問題負責、測試驅動等等

持續集成能提高團隊對復雜系統的自信心與控制力，其主要關注是開發團隊，并不能解決軟件部署、交付過程的低效，所以需要一個端到端的自動化構建、部署、測試和發布流程，也就是部署流水線（關注的是軟件從CVS到用戶手中這個過程），它有一些相關實踐：只生成一次二進制包、不同環境統一部署、對部署進行冒煙測試、向生產環境的副本部署、每次變更都要立即在流水線中傳遞、只要有環節失敗停止整個流水線。CI/CD的關鍵都是記錄變更，為盡早發現問題提供信息，消除低效環節

部署流水線的幾個要點：構建與部署腳本化（配置初始化數據、基礎設施、中間件等）、提交階段快速反饋與及時修復、自動化驗收測試（驗收測試是驗證客戶的期待，單元測試是驗證開發人員的期待）、注意非功能測試（主要指性能）、部署與發布要有策略并且可重復執行（文本化）且可回滾（不同版本文件不刪除，用符號鏈接到當前版本）

作者說無論項目大小都應使用CI/CD，這個我感覺有點偏激了，所謂磨刀不誤砍柴工，前提是這個柴要么很多，要么很大，如果只是幾根細柴，有那個磨刀的功夫柴都砍完了。但是實際工作中這么小的項目應該很少，所以大多數項目我們還是都還是應該搭建部署流水線，用上CI/CD。
書很厚，其實好多地方可以跳過，你只需要看標題就能抓住主旨而無需多看。
PS：可以先看看這本持續集成。

敏捷革命：提升個人創造力與企業效率的全新協作模式 (豆瓣): https://book.douban.com/subje...

CI/CD 實際上正是敏捷開發的最佳實踐，有了前面的鋪墊，我們可以通過這本書我們來真正了解敏捷開發的全貌。

亮點：

2005年之前，大多數軟件開發項目都是采用“瀑布法”：整個項目被劃分為多個階段，每個階段都要經過嚴格的評審，以期為客戶或軟件使用者提供完美的產品（甘特圖表現），每一階段的工作做得足夠好時才允許進入下一階段。這種工作方式看似完美，實際全憑想象和猜測、華而不實，往往導致開發進度緩慢，常常超出預算，且現實和規劃差異巨大，Scrum（敏捷開發流程）的出現就是解決這個問題的（不憑猜測，而是PDCA：計劃、執行、檢查、行動）

任何項目的管理都需要實現兩個目標：可控性與可預測性

管理層的職責在于制定戰略目標，團隊的工作則是決定如何完成目標。無論任何人，只要不在現場，都不可能及時跟上事態變化的步調，所以團隊要有自主決策權，此外一個團隊需要包含完成一個項目的所有技能，同時要小而精（7人左右）。團隊成員之間不要互相指責，而是盡量改善制度

“沖刺”（一般以星期為周期）可以讓團隊成員集中精力快速做出成果并得到反饋，“每日立會”（15分鐘以內）能讓成員清楚地知道沖刺進度如何。Scrum的核心就是節奏

確定懂項目、懂市場、懂顧客的產品負責人，擬定待辦事項清單并檢測兩遍，重要的事情優先做

這本書細看的話真的很洗腦，看完感覺自己迫不及待地想要沖進一家公司試試Scrum了。

DevOps實踐指南 (豆瓣): https://book.douban.com/subje...

DevOps是軟件開發、運維和質量保證三個部門之間的溝通、協作和集成所采用的流程、方法和體系的一個集合（所以也要基于CI/CD，前4本書可以看做一個連續的專題，核心都是敏捷）。它取代了傳統開發、測試、運維職責大分離的思想，填平了部門之間的鴻溝，讓大家更有效的工作。我們可以通過這本書來對DevOps有一個全面的了解。

亮點：

開發部通常負責對市場變化做出響應，以最快的速度將新功能或者變更上線。而運維部則要以提供穩定、可靠和安全的服務為已任，讓任何人都很難甚至無法引入可能會危害生產環境的變更。這種配置方式讓開發部門和IT運維部門的目標和動因之間存在“根本的、長期的沖突”——公司對不同部門的考核和激勵不同，這種沖突造成了一種惡性循環，阻礙了公司全局目標的實現。DevOps能夠提高公司業績，實現開發、QA、IT運維、信息安全等各職能技術角色的目標，同時改善人們的境遇

DevOps是精益、約束理論、豐田生產系統、柔性工程、學習型組織、康威定律等知識體系的集大成者

DevOps“三步工作法”：流動、反饋、持續學習與實驗，并闡述了DevOps實施需遵守的原則與最佳實踐（流動：它加速了從開發、運維到交付給客戶的正向流程；反饋：它使組織構建安全可靠的工作體系，并獲得反饋；持續學習與實驗：它打造出一種高度信任的文化，并將改進和創新融入日常工作中）

為了能識別工作在哪里流動、排隊或停滯，需要將工作盡可能地可視化，如在看板或Sprint計劃板上，使用紙質或電子卡片將各項工作展示出來,通過這種方式，不僅能將工作內容可視化，還能有效地管理工作，加速其從左至右的流動,還可以通過卡片從在看板上創建到移動至“完成”這一列，度量出工作的前置時間。此外，看板還能控制在制品數量（隊列長度）

文中關于小批量和大批量的差異，我以前在博客中也提到過。如此看來，兩種方式各有優劣，關鍵看能分配的資源是什么？更追求總體效率還是效果出現的等待時間？對返工的要求是什么？再來決定使用方法

第一步描述的原則，使得工作能夠在價值流中從左向右快速地流動。第二步描述的原則，使得在從右向左的每個階段中能夠快速、持續地獲得工作反饋。快速發現問題、群策群力解決問題，可以避免把問題帶入下游環節，避免修復成本指數增加。根據精益原則，我們最重要的客戶是我們的下游（不一定是最終付費用戶），為他們而優化我們的工作，在源頭保障質量。第三步描述的原則可以持續提升個人技能，進而轉化為團隊的財富

......

感覺歷史的天平總是左右搖擺，一開始職責混亂、一個人干所有的事，后來職責分離、分工明確，現在又提倡填平鴻溝、部門融合。隨著時代的發展，適用于時代的技術也總是不停變更，要想不被淘汰就得終身學習呀。

Web容量規劃的藝術 (豆瓣): https://book.douban.com/subje...

容量規劃（很早就有了，如道路規劃、電力運營）是一門省錢的藝術，保證用合理的資源來實現最大化需求，通過這本書我們來敲開容量規劃在互聯網世界中實際運用的大門。

亮點：

容量規劃整個過程：首先要明確定義響應時間、可供消耗容量以及峰值驅動處理等明確指標來定義總體負載和容量需求，然后了解當前基礎設施的負荷特征，預測需要的資源來達到這種性能，然后如何管理資源，最后不斷迭代，最終目標介于“沒有買足夠資源”和“浪費太多資源”之間

有幾個方法：預測系統何時失敗、用統計圖表（比數字更直觀）呈現問題、性能調優與容量規劃要同步進行、搜集數據驅動未來的規劃

測量是規劃的前提，要有堅實的數據支撐而不是猜測，有許多工具可以測量，他們應該可以隨著時間記錄和保存數據、自定義度量、比較指標、導入和導出指標，當然測量工具本身要輕量，盡量對資源本身影響較小。

如果說測量是對已有情況的了解，那么估計就是根據數據趨勢預測未來。預測部分靠直覺，部分靠數學。我們可以做曲線擬合，注意到趨勢和變更，并進行迭代和校準（看來基于機器學習或者說AI的運維是未來啊）

文章除了基于傳統模式的容量規劃，還涉及到了基于虛擬化和云計算的模式，所以我們學習也要注意趨勢和變化。

領域驅動設計 (豆瓣): https://book.douban.com/subje...

構建程序之前，我們都要對業務進行梳理和理解，然后是領域劃分與建模等一系列重要步驟，最后才是編碼實現，這就是一本講解這些步驟的好書。而且本書會告訴你，設計和實現可以交錯進行和演化，來達到最優。還提出了專業術語，你在和別人交流時可以使用。
我在讀到假同源這個詞語時真是猶如醍醐灌頂，因為之前開發項目就有過：同一個對象，這個模塊改吧改吧，那個模塊改吧改吧，最后導致對兩個模塊而言，這個對象都不完全屬于它，要修改都得小心翼翼怕影響對方，本書告訴我，遇上假同源，要么重新理解和建模，統一該對象表示，要么果斷分開這兩個模塊，用兩個對象分別服務這兩個模塊。

亮點：

模型是一種簡化，是對現實的解釋，把與解決問題密切相關的方面抽象出來，而忽略無關的細節（所以需要我們消化和提煉已有知識，包括深層次探索）。用戶應用軟件的問題區域就是軟件的領域（有形的如機票系統，無形的如會計系統）。成功的項目有一個共同特征：都有一個豐富的領域模型，這個模型在迭代設計過程中不斷演變（我們要持續學習），與實現綁定，成為項目不可分割的一部分

很多因素可能會導致項目偏離軌道，但真正決定軟件復雜性的是設計方法。當復雜性失去控制時，開發人員就無法很好地理解軟件，因此無法輕易、安全地更改和擴展它，而好的設計則可以為開發復雜特性創造更多機會。一些設計因素是技術上的，很多技術人員都能輕易注意到并改進，但是很多程序主要的復雜性并不在技術上，而是來自領域本身、用戶的活動或業務，這部分往往被許多人忽略

要避免不設計和過度設計（極限編程）

模型、設計的核心、實現互相影響和關聯；模型是團隊所有人員溝通的中樞，使得開發人員和領域專家無需翻譯就能溝通，高效簡潔；模型是濃縮的知識

技術人才更愿意從事精細的框架工作，試圖用技術來解決領域問題，把學習領域知識和領域建模的工作留給別人去做。軟件核心的復雜性需要我們直接去面對和解決，如果不這樣做，則可能導致工作重點的偏離——軟件的初衷以及核心就是為了解決領域問題

對于比較重要的業務規則（這個知識點需要我們自己去理解）比如貨船超訂110%，應該多帶帶抽象成1個實體（具體就可以是1個方法），而不是簡單的用一個guard clause來實現，這樣既能明確這個知識點本身，又利于代碼的擴展性。當然，把不重要的細節也多帶帶抽象就是典型的過度設計了

以文本為主，簡潔的小圖為輔（大而全的圖反而失去了解釋能力）來闡釋模型最好。文檔是代碼和口頭交流的補充，為團隊提供穩定和共享的交流。只用代碼做文檔容易使人陷入細節，不能把控全局，所以應該文檔和代碼互補，文檔不再重復闡述代碼能表現的內容而是著重核心元素，闡明設計意圖，文檔還要注意和代碼保持同步不脫節（不再適用的文檔要進行歷史歸檔），不然就失去了意義。模型與實現也要同步，通過模型驅動設計MDD實現，保證模型既利于實現，也利于前期的分析

要想創建出能處理復雜任務的程序，需要做到關注點分離，使設計中的每個部分都得到多帶帶的關注，行業普遍采用分層架構，分層的價值在于每一層都只代表程序中的某一特定方面，每個方面的設計都更具內聚性，更容易解釋。分層設計大都是“用戶層界面-應用層-領域層-基礎設施層”這種四層架構的變體，其中領域層是軟件的核心，將其分離才是MDD的關鍵，也是領域驅動設計DDD的前提。領域層與應用層的區分關鍵在于領域層包含實際業務規則（如轉賬操作），而應用層是為了實現業務的輔助功能（如導入轉賬文本記錄）

DDD適用于大型項目，小項目用“Smart UI”更合適，還有其他的架構模式都有自己的使用場景和局限

領域中用來表示某種具有連續性和標識（比如銀行賬戶）的事物是ENTITY，用于描述某種狀態的屬性是VALUE OBJECT（不可變，無標識，比如數字3，盡量設計為不可變，便于復制和共享），動作或操作最好用SERVICE來表示（在大型系統中，中等粒度、無狀態的SERVICE更容易被復用），對象之間的關聯可以通過限定條件進行簡化，MODULE是一種更粗粒度的建模和設計單元（提供了兩種觀察模型的方式，一是可以在MODULE中查看細節，而不會被整個模型淹沒，二是觀察MODULE之間的關系，而不考慮其內部細節）。領域模型中的每個概念都應該在實現元素中反映出來

由于汽車的裝配和駕駛永遠不會同時發生，因此將這兩種功能合并到同一個機制中是毫無價值的。同理，裝配復雜的復合對象的工作也最好與對象要執行的工作分開。應該將創建復雜對象（比如依賴其他對象B的對象A就是復雜對象，不要直接在A構造函數中調用B的構造函數）的實例和AGGREGATE（一組相關對象的集合，比如車輛與發動機）的職責轉移給多帶帶的對象：FACTORY

初始模型通常都是基于對領域的淺顯認知而構建的，不夠成熟也不夠深入，通過重構（不僅是一般的代碼細節的重構，還有領域的重構，后者通常風險很高，但是回報也很高，需要在前者的不斷積累下尋找突破）最終開發出能夠捕捉到領域深層含義的模型，這也是管理項目的規模和復雜性的要素，加上柔性設計（軟件易于修改）就能讓項目穩步發展。持續重構漸漸被認為是一種“最佳實踐”，但大部分項目團隊仍然對它抱有很大的戒心。人們雖然看到了修改代碼會有風險，還要花費開發時間，但卻不容易看到維持一個拙劣設計也有風險，而且遷就這種設計也要付出代價

代碼除了要能準確得到結果外，還要能顯式的表達出領域的規則，易于理解和預測修改代碼的影響。所以有一些原則：揭示意圖的接口，能避免用戶去研究它的實現（失去了封裝的價值）；無副作用的函數，安全地預見函數的作用，避免組合爆炸；斷言可以幫助展示和理解副作用

技術角度的設計模式中的一些也適用于領域設計，比如Strategy和Composite模式，把設計模式用作領域模式的唯一要求是這些模式能夠描述關于概念領域的一些事情，而不僅是作為解決技術問題的技術解決方案

大型系統的模型很復雜，需要注意三個要素：上下文（不要強制在大型系統中統一模型，可以在不同的上下文使用不同的模型（注意重復概念和假同源），劃定好邊界即可）、精煉和大型結構，才能操縱和理解這個模型

......

DDD我們可能都用過，但是很可能沒把它當成一項正經學問，都是大概過一下需求，稍微捋一捋邏輯然后就開始編碼了，實際上，在我們這個過程我們已經經歷了ffffd，看完本書以后希望能把這個過程正規化，流程化，高效化。

Go語言實戰 (豆瓣): https://book.douban.com/subje...

上本書給我們講了go的基礎知識和原理，這本書就帶領我們用go的各種庫和工具進行實戰。

亮點：

計算機一直在演化，但是編程語言并沒有以同樣的速度演化。現在的高性能服務器擁有 64 核、128 核，甚至更多核。但是我們依舊在使用為單核設計的技術在編程。Go語言對傳統的面向對象開發進行了重新思考，并且提供了更高效的復用代碼的手段。Go語言還讓用戶能更高效地利用昂貴服務器上的所有核心，而且它編譯大型項目的速度也很快

經驗，如果需要聲明初始為零值的變量，應該使用 var 關鍵字聲明變量；如果提供確切的非零值初始化變量或者使用函數返回值創建變量，應該使用簡化變量聲明運算符 :=

go vet工具不能讓開發者避免嚴重的邏輯錯誤，或者避免編寫充滿小錯的代碼。不過可以很好地捕獲一部分常見錯誤。每次對代碼先執行 go vet 再將其簽入源代碼庫是一個很好的習慣；在保存文件或者提交到代碼庫前執行 go fmt可以統一代碼風格

go在函數之間傳遞變量時，總是以值的方式傳遞的。函數間傳遞數組可能涉及大量數據拷貝，最好傳遞數組的指針，就只用拷貝8字節的指針而非拷貝數組本身。相反，與切片關聯的數據包含在底層數組里，不屬于切片本身，所函數間直接傳遞切片沒有性能影響，映射也是；在創建切片時設置切片的容量和長度一樣，就可以強制讓新切片的第一個 append 操作創建新的底層數組，與原有的底層數組分離，可以安全地進行修改而不影響原切片，同時也保持了為切片申請新的底層數組的代碼簡潔性

關鍵字 func 和函數名之間的參數被稱作接收者，將函數與接收者的類型綁在一起。如果一個函數有接收者，這個函數就被稱為方法。值接收者使用值的拷貝副本來調用方法，而指針接受者使用實際值來調用方法。Go語言會調整傳入的參數，無論是指針接受者還是值接受者都可以接受指針或者值兩種類型，說是方便開發，但我覺得這反而是一個不必要的歧義，比如到了接口的方法集中，如果使用指針接收者來實現一個接口，那么只有指向那個類型的指針才能夠實現對應的接口。如果使用值接收者來實現一個接口，那么那個類型的值和指針都能夠實現對應的接口，主要原因是編譯器并不是總能自動獲得一個值的地址

通過嵌入類型，與內部類型相關的標識符會提升到外部類型上。這些被提升的標識符就像直接聲明在外部類型里的標識符一樣，也是外部類型的一部分，可以無縫實現對象組合，需要注意嵌入類型不需要聲明字段。如

  type admin struct {            type admin struct {
      user // 嵌入類型                user user//聲明字段，不是嵌入
      level string                   level string
  }                              }

Go語言的并發同步模型來自一個叫作通信順序進程（Communicating Sequential Processes，CSP）的范型（ paradigm）。CSP 是一種消息傳遞模型，通過在 goroutine 之間傳遞數據來傳遞消息，而不是對數據進行加鎖來實現同步訪問。go 的競爭檢測器 go build -race 可以有效檢測代碼里面的競爭狀態。go可以通過原子函數、互斥鎖和通道發送接受共享資源來實現同步

查看原文，來自MageekChiu。