後端好書閱讀與推薦系列文章:
後端好書閱讀與推薦
後端好書閱讀與推薦(續)
後端好書閱讀與推薦(續二)
後端好書閱讀與推薦(續三)
後端好書閱讀與推薦(續四)
後端好書閱讀與推薦(續五)
後端好書閱讀與推薦(續六)
後端好書閱讀與推薦(續七)spring
Spring微服務實戰
Spring微服務實戰 (豆瓣): https://book.douban.com/subje...編程
Spring體系用來作微服務在當下可謂是風頭正勁,這本書就用一個實例來手把手教咱們實現微服務。實戰系列的口碑一直不錯,這本也不例外,看完就能夠對微服務的概念有一個完整的理解,而且想上手也有路可尋。json
亮點:segmentfault
- 編碼就像藝術,是一種創造性活動。構建分佈式應用就像指揮一個管絃樂隊演奏音樂,是一件使人驚奇的事情
- 微服務是一個小的、鬆耦合的分佈式服務,分解和分離大型複雜應用程序的功能,使它們獨立,這樣負責每一個功能的團隊都擁有本身的代碼庫和基礎設施,技術不限,能靈活地獨立開發部署,職責分離,下降團隊協做成本。隨着雲的普及,微服務單元的增減(每一個服務單元都是完整的)變得很是容易,使得整個應用更具彈性伸縮能力。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」問題,讓軟件交付再也不使人緊張,成爲一件簡單日常的事情。數組
亮點:tomcat
- 從決定修改到結果上線的時間爲週期時間,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實踐指南
DevOps實踐指南 (豆瓣): https://book.douban.com/subje...
DevOps是軟件開發、運維和質量保證三個部門之間的溝通、協做和集成所採用的流程、方法和體系的一個集合(因此也要基於CI/CD,前4本書能夠看作一個連續的專題,核心都是敏捷)。它取代了傳統開發、測試、運維職責大分離的思想,填平了部門之間的鴻溝,讓你們更有效的工做。咱們能夠經過這本書來對DevOps有一個全面的瞭解。
亮點:
- 開發部一般負責對市場變化作出響應,以最快的速度將新功能或者變動上線。而運維部則要以提供穩定、可靠和安全的服務爲已任,讓任何人都很難甚至沒法引入可能會危害生產環境的變動。這種配置方式讓開發部門和IT運維部門的目標和動因之間存在「根本的、長期的衝突」——公司對不一樣部門的考覈和激勵不一樣,這種衝突形成了一種惡性循環,阻礙了公司全局目標的實現。DevOps可以提升公司業績,實現開發、QA、IT運維、信息安全等各職能技術角色的目標,同時改善人們的境遇
- DevOps是精益、約束理論、豐田生產系統、柔性工程、學習型組織、康威定律等知識體系的集大成者
- DevOps「三步工做法」:流動、反饋、持續學習與實驗,並闡述了DevOps實施需遵照的原則與最佳實踐(流動:它加速了從開發、運維到交付給客戶的正向流程;反饋:它使組織構建安全可靠的工做體系,並得到反饋;持續學習與實驗:它打造出一種高度信任的文化,並將改進和創新融入平常工做中)
- 爲了能識別工做在哪裏流動、排隊或停滯,須要將工做盡量地可視化,如在看板或Sprint計劃板上,使用紙質或電子卡片將各項工做展現出來,經過這種方式,不只能將工做內容可視化,還能有效地管理工做,加速其從左至右的流動,還能夠經過卡片從在看板上建立到移動至「完成」這一列,度量出工做的前置時間。此外,看板還能控制在製品數量(隊列長度)
- 文中關於小批量和大批量的差別,我之前在博客中也提到過。如此看來,兩種方式各有優劣,關鍵看能分配的資源是什麼?更追求整體效率仍是效果出現的等待時間?對返工的要求是什麼?再來決定使用方法
- 第一步描述的原則,使得工做可以在價值流中從左向右快速地流動。第二步描述的原則,使得在從右向左的每一個階段中可以快速、持續地得到工做反饋。快速發現問題、羣策羣力解決問題,能夠避免把問題帶入下游環節,避免修復成本指數增長。根據精益原則,咱們最重要的客戶是咱們的下游(不必定是最終付費用戶),爲他們而優化咱們的工做,在源頭保障質量。第三步描述的原則能夠持續提高我的技能,進而轉化爲團隊的財富
- ......
感受歷史的天平老是左右搖擺,一開始職責混亂、一我的幹全部的事,後來職責分離、分工明確,如今又提倡填平鴻溝、部門融合。隨着時代的發展,適用於時代的技術也老是不停變動,要想不被淘汰就得終身學習呀。
Web容量規劃的藝術
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咱們可能都用過,可是極可能沒把它當成一項正經學問,都是大概過一下需求,稍微捋一捋邏輯而後就開始編碼了,實際上,在咱們這個過程咱們已經經歷了ddd,看完本書之後但願能把這個過程正規化,流程化,高效化。
Go語言實戰
Go語言實戰 (豆瓣): https://book.douban.com/subje...
上本書給咱們講了go的基礎知識和原理,這本書就帶領咱們用go的各類庫和工具進行實戰。
亮點:
查看原文,來自MageekChiu。