周末聊聊敏捷開發(fā)、K8s、中臺、架構(gòu)，還有云原生 | 文末送書

DevOps與敏捷開發(fā)

敏捷開發(fā)主要是針對應(yīng)用的開發(fā)，其目的是加快開發(fā)對應(yīng)用需求的響應(yīng)，快速交付價值，快速響應(yīng)變化。

敏捷開發(fā)是用短的迭代周期來適應(yīng)更快的變化，而且保持增量的持續(xù)改進(jìn)的過程。

DevOps涵蓋的不僅僅是開發(fā)，還包括開發(fā)之后的部署、發(fā)布、運維等應(yīng)用生命周期的整個流程，延伸整個響應(yīng)、交付的流程到實施、發(fā)布和運維，從而涵蓋整條IT價值流。

DevOps與Kubernetes

容器及Kubernetes促進(jìn)了DevOps，當(dāng)為一個應(yīng)用打包容器鏡像時，選擇基礎(chǔ)鏡像及安裝依賴部分就是原先需要運維人員所做的環(huán)境創(chuàng)建和配置。而使用容器后，此過程由開發(fā)人員和運維人員共同商議決定，從而促進(jìn)了開發(fā)人員與運維人員的合作。

Docker 使容器具備了較好的可操作性、可移植性，Kubernetes 使容器具備了企業(yè)級使用的條件，企業(yè)級容器平臺也成為CI/CD工具落地的新一代基礎(chǔ)架構(gòu)。

容器編排器帶來的一個巨大轉(zhuǎn)變是，原來只有運維人員關(guān)心環(huán)境的部署，無論是測試環(huán)境還是生產(chǎn)環(huán)境，都是運維人員搞定的；而容器化之后，需要開發(fā)人員自己寫Dockerfile或者Kubernetes的YAML文件，關(guān)心應(yīng)用運行環(huán)境的部署。

Kubernetes讓開發(fā)人員無須再關(guān)注底層資源，使得交付速度更快。

為了實現(xiàn)應(yīng)用的持續(xù)集成和持續(xù)交付，必須縮小本地與線上的差異，確保環(huán)境的一致性，保持開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境盡可能相似。

Kubernetes正好提供了這種一致性，并且通過Kubernetes配置文件構(gòu)建的環(huán)境可以實現(xiàn)版本化。

從開發(fā)人員的角度來講，使用Kubernetes絕對不像使用虛擬機(jī)一樣，開發(fā)人員除了寫代碼、做構(gòu)建、做測試，還需要知道應(yīng)用的容器運行環(huán)境。

開發(fā)人員需要知道容器和原來的部署方式是不一樣的，需要區(qū)分有狀態(tài)和無狀態(tài)。

開發(fā)人員需要寫Dockerfile，需要關(guān)心環(huán)境的交付，需要了解太多原來不了解的東西。

Kubernetes + Docker 是Dev和Ops融合的一個橋梁。

Docker是微服務(wù)的交付工具，有了微服務(wù)之后，服務(wù)太多了，單靠運維人員根本管不過來，而且很容易出錯，這就需要開發(fā)人員關(guān)心環(huán)境的交付。

例如配置改了什么、創(chuàng)建了哪些目錄、如何配置權(quán)限等，只有開發(fā)人員最清楚，這些信息很難通過文檔的形式及時、準(zhǔn)確地同步到運維部門，就算是同步過來了，運維部門的維護(hù)量也非常大。

所以有了Kubernetes，最大的改變就是環(huán)境交付提前——每個開發(fā)人員多花5%的時間，來換取運維人員200%的勞動，并且提高了穩(wěn)定性。此外，有了Kubernetes以后，運維層要關(guān)注服務(wù)發(fā)現(xiàn)、配置中心、熔斷降級。Kubernetes雖然復(fù)雜，但是其設(shè)計理念非常符合DevOps的思想。

DevOps與微服務(wù)

傳統(tǒng)的單體應(yīng)用模塊化并不注重模塊間接口的契約化，在進(jìn)行模塊集成時經(jīng)常會出現(xiàn)應(yīng)用功能不可用的情況，需要花費大量時間進(jìn)行修復(fù)。微服務(wù)架構(gòu)的應(yīng)用往往由數(shù)量眾多的微服務(wù)構(gòu)成，在這種情況下，DevOps的CI/CD必不可少。

通過CI/CD可以實現(xiàn)整個開發(fā)流程的自動化，從而極大地提升開發(fā)效率。

DevOps與應(yīng)用架構(gòu)模式

康威定律指出，軟件的架構(gòu)和軟件團(tuán)隊的結(jié)構(gòu)是一致的，所以應(yīng)用開發(fā)團(tuán)隊對軟件產(chǎn)品的架構(gòu)和成果有著巨大的影響。

為了使DevOps的IT價值流可以快速地流動，必須利用康威定律發(fā)揮團(tuán)隊的優(yōu)勢，靈活地組織團(tuán)隊。

如果不理解康威定律，就會妨礙團(tuán)隊安全、獨立地工作，它們會被緊緊地耦合在一起，所有工作都相互依賴和等待，即使做很小的變更也會導(dǎo)致全局性、災(zāi)難性的后果。

為了實現(xiàn)DevOps，不但要減少職能化導(dǎo)向的負(fù)面影響，而且還要更好地運用市場化導(dǎo)向的效果，從而使團(tuán)隊可以安全、獨立地工作，并且快速地向客戶交付價值。

因此，應(yīng)用的架構(gòu)模式需要保證團(tuán)隊可以獨立運作，彼此充分解耦，從而避免過多不必要的協(xié)調(diào)與溝通。

在傳統(tǒng)的緊耦合架構(gòu)中，即使做微小的變更也可能導(dǎo)致大規(guī)模的故障。

因此，負(fù)責(zé)某個組件的開發(fā)人員不得不和負(fù)責(zé)其他組件的開發(fā)人員不斷地協(xié)調(diào)與溝通。

為了測試整個應(yīng)用能否工作，需要集成數(shù)百名甚至數(shù)千名開發(fā)人員編寫的代碼，而這些開發(fā)人員編寫的代碼又依賴數(shù)十個甚至數(shù)百個其他應(yīng)用。

另外，測試需要在稀缺的集成環(huán)境中完成，而集成環(huán)境通常需要花費數(shù)周來安裝和配置。結(jié)果是不僅延長了交付周期，還導(dǎo)致開發(fā)人員的生產(chǎn)力低下和部署質(zhì)量不佳。

應(yīng)用賴以生存的架構(gòu)在很大程度上決定了代碼的測試和部署方式。

架構(gòu)是應(yīng)用開發(fā)的首要因素，它還決定了是否能夠快速和安全地實施變更。

如果架構(gòu)能夠支持團(tuán)隊獨立、安全、快速地進(jìn)行開發(fā)、測試和部署，那么就可以提高和維持開發(fā)人員的生產(chǎn)力，并且持續(xù)改善部署質(zhì)量。

微服務(wù)架構(gòu)模式就具有這種特性，松耦合的架構(gòu)意味著在生產(chǎn)環(huán)境中可以獨立更新某一個微服務(wù)，而無須更新其他微服務(wù)。

康威定律告訴我們，必須鼓勵建立小規(guī)模的團(tuán)隊，減少團(tuán)隊間的溝通，而微服務(wù)架構(gòu)真正從軟件架構(gòu)上支持這種工作模式，將DevOps的流動性和靈活性發(fā)揮到極致。

OK送書

說了這么多，那這本書里都講了，《云原生架構(gòu)，從技術(shù)演進(jìn)到最佳實踐》，了解新技術(shù)。

這次不搞那么麻煩了，送書5本，截止11月7號晚上8點，評論點贊數(shù)最高的5位同學(xué)分別贈送一本。

書籍目錄：

第1部分 系統(tǒng)資源（第1~5章）

針對不同的系統(tǒng)資源，應(yīng)用的部署、運行方式也不盡相同。這一部分將首先介紹操作系統(tǒng)、虛擬化等基本知識，然后講解云計算相關(guān)內(nèi)容，以及容器與容器編排的核心知識。

第2部分 應(yīng)用架構(gòu)（第6~11章）

這一部分將宏觀介紹應(yīng)用架構(gòu)的定義、分類、目標(biāo)等，列舉主流架構(gòu)視圖，并按照技術(shù)演進(jìn)過程介紹單體架構(gòu)、分布式架構(gòu)、SOA架構(gòu)、微服務(wù)架構(gòu)等內(nèi)容。

第3部分 軟件工程（第12~16章）

軟件工程的整個流程分為5個階段：應(yīng)用設(shè)計、軟件開發(fā)、開發(fā)運維一體化、SRE運維、數(shù)字化運營。在這一部分中，將緊密圍繞以上5個技術(shù)演進(jìn)階段，從軟件工程角度講解云原生應(yīng)用架構(gòu)的實現(xiàn)。

第4部分 架構(gòu)、應(yīng)用落地與中臺構(gòu)建（第17~19章）

在這一部分中，我們將詳細(xì)剖析云原生架構(gòu)，介紹其定義、涉及的關(guān)鍵技術(shù)，以及具體的實現(xiàn)過程。還會介紹應(yīng)用落地的最佳實踐，涉及應(yīng)用改造、應(yīng)用拆分、API設(shè)計與治理等。