只看到自己想看到的東西,只做老闆安排的任務。這是很多傳統IT已經被淘汰還不知如何適應的關鍵原因之一。要時刻對外面發生了什麼保持敏感度。這些年,雲原生已在不斷蠶食傳統IT,一個又一個企業的內部IT員工與傳統IT廠商消失在我們的視野裡,從研發模式到服務模式都必須做調整。我們今天來談敏捷開發與雲原生技術棧。
一、關於敏捷開發
敏捷開發與其說是嚴謹的方法體系,不如說是一組行事原則。符合敏捷價值觀和原則的開發方法包括:極限程式設計(XP),Scrum,精益軟體開發(Lean Software Development),動態系統開發方法(DSDM),特徵驅動開發(Feature Driver Development),水晶開發(Crystal Clear)等等。
所有這些方法都具有以下共同特徵:
- 迭代式開發。即整個開發過程被分為幾個迭代週期,每個迭代週期是一個定長或不定長的時間塊,每個迭代週期持續的時間一般較短,通常為一到六週。
- 增量交付。產品是在每個迭代週期結束時被逐步交付使用,而不是在整個開發過程結束的時候一次性交付使用。每次交付的都是可以被部署到使用者應用環境中被使用者使用的、能給使用者帶來即時效益和價值的產品。
- 開發團隊和使用者反饋推動產品開發。敏捷開發方法主張使用者能夠全程參與到整個開發過程中。這使需求變化和使用者反饋能被動態管理並及時整合到產品中。同時,團隊對於使用者的需求也能及時提供反饋意見。
- 持續整合。新的功能或需求變化總是儘可能頻繁地被整合到產品中。一些專案是在每個迭代週期結束的時候整合,有些專案則每天都在這麼做。
- 開發團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發團隊,是每個敏捷專案必不可少的條件。人是敏捷開發的核心。敏捷開發總是以人為中心建立開發的過程和機制,而非把過程和機制強加給人。
二、常規敏捷開發案例
- 需求評審(參與人員是 客戶+產品+UI+開發+測試,也就是所有人員)
主要是產品人員講解需求,使用者需要給出反饋或者提出意見,其他人員可以相應的提出自己的見解。
- Story劃分(產品+UI+開發)
產品根據UI做出來的原型圖給開發人員講解系統構成和執行,將整個網站按照功能劃分成一個個細粒度的story來說明,開發人員(前端和後端)也需要明白自己應該關注那些關鍵點。
- 人員劃分(leader+開發)
主要是專案小組的leader 根據story劃分,給前端和後端開發人員劃分story,開發人員根據自己的情況去估算所需時間。
- 方案設計(資料庫設計文件、介面設計文件、方案設計文件)
先根據系統的實際情況去設計DB,包括資料庫和表的名字,以及具體的欄位。然後設計介面文件,按照頁面和功能進行設計,包括具體的請求地址和入參出參。最後是根據介面文件中出現的疑難點去做方案設計文件,對遇到的問題進行分析並拿出至少兩種具體的解決方案。
- 方案評審(所有人員)
對前端和後端給出的方案評審其它人員給出各自的意見,有問題的話下次再次開始。
- 禪道任務拆分(開發人員)
方案評審透過以後開發人員就需要按照預估的總開發時間去拆分story,可以分成多個小的任務,但是一個任務的時間最好不要超過4個小時。
- 開發(專案日報+工作日報+進度郵件)
每天實際開發過程中遇到問題可以寫成專案日報;每天的任務完成情況寫成工作日報;相比較整個系統的進度完成情況需要寫進度郵件。
- 端對端(介面)測試(開發人員)
前端寫好了頁面,後端完實現了介面,就可以進行端到端的測試,可以遠端測試,也可以本地測試。
- 壓力測試+整合測試
系統完成以後需要用Jmeter 進行模擬使用者訪問,透過設定執行緒來提高併發量的方式達到一定的效果,測試生成的資料需要總結成測試報告。
- Demo
對於覆盤來說,這就是最後一個程式了,在前後端大師兄的評審下,主要是前端人員進行系統演示,各個功能是否實現、頁面是否達到使用者要求、有沒有什麼需要完善的地方。點評過之後如果有問題那就修改之後再次評審;如果沒有問題那就算完成覆盤專案了。
三、雲原生技術棧
3.1 CNCF landscape
這裡主要分成了幾個技術板塊,技術思維其實沒那麼複雜,無外乎是用IT在重構服務過程,實現上層應用,對接好下層資源,因此IT本身也即服務:
- 應用定義及部署(App Definition and Development)
- 編排與管理(Orchestration & Management)
- 執行環境(Runtime)
- 配置(Provisioning)
- 平臺(Platform)
- 可觀測性和分析(Observability and Analysis)
- 無服務(Serverless)
這幾大板塊基本把雲原生技術所涉及領域都涵括進去了,下面詳細介紹下各板塊所涉及到的技術棧。從系統層次來看,從上到下分別是:
- 應用層:應用定義及部署(App Definition and Development)、配置(Provisioning)、可觀測性和分析(Observability and Analysis)、無服務(Serverless)
- 叢集:編排與管理(Orchestration & Management)
- 底層執行環境:執行環境(Runtime)
這個板塊的技術棧主要是應用開發過程中都會用到的,像資料庫、流式處理和訊息佇列、應用定義和映象構建、持續整合和持續部署。
1)應用定義及部署
資料庫(Database)
流式處理和訊息佇列(Streaming and Messaging)
應用定義和映象構建(App Definition and Image Build)
持續整合與持續部署(Continuous Integration and Continuous Delivery)
2)編排與管理
編排與管理板塊可以說是雲原生的核心,其包括了容器編排、一致性與服務發現、遠端程式呼叫(RPC)、服務代理、API閘道器、服務網格。
容器編排與排程(Orchestration and Scheduling)
一致性與服務發現(Coordination and Service Discovery)
遠端呼叫服務(Remote Procedure Call)
服務代理(Service Proxy)
API閘道器(API Gateway)
服務網格(Service Mesh)
3)執行環境
這裡的執行時板塊指的就是容器執行環境,包括了容器儲存、容器計算、容器網路三大工具,在k8s分別對應的是CSI、CRI和CNI三類介面定義。
雲原生儲存(Cloud Native Storage)
容器執行時(Container Runtime)
雲原生網路(Cloud Native Network)
4)配置
- 自動化與配置(Automation & Configuration)
- 容器註冊(Container Registry)
- 安全與合規性(Security & Compliance)
- 金鑰管理(Key Management)
5)平臺
從服務到安裝到主機到分佈管理的各廠家技術分佈如圖
6)可觀測性與分析
從混沌到追蹤到日誌分析到監控的各廠家技術分佈如圖
可觀測性與分析板塊主要包括:
- 監控(Monitoring)
- 日誌(Logging)
- 追蹤(Tracing)
- 混沌工程(Chaos Engineering)
7)無服務
Serverless是一個很大的領域,因此針對 serverless 這裡專門又細分了五個模組:工具、安全、框架、註冊平臺和可安裝平臺。
- 工具(Tools)
- 安全(Security)
- 框架(Framework)
- 註冊平臺(Hosted Platfrom)
- 可安裝平臺(Installable Platform)
來源:球迷Long筆記
作者:球迷Long