雲原生和微服務，都是近幾年後端研發小夥伴耳熟能詳的的詞，熱門的有些不像話。但還是相信很多小夥伴，並不是能很好的理解
-
究竟什麼是雲原生？
-
微服務架構體系實踐，需要考慮哪些關注點？
那麼，這篇文章，我想跟大家一起來探討關於雲原生與微服務架構體系實踐的一些思考，拋磚引玉並期望在實際生產實踐中帶來一些幫助。
1.什麼是雲原生
雲原生，有兩個層面的關注點，一個研發層面，再一個是運維層面。我們來看一個關於雲原生比較貼切的定義，它是說
-
軟件應用，基於微服務架構體系實踐，並採用持續交付（CI/CD）和DevOps工程實踐
-
運行時，以容器方式打包，且最終由運行於雲基礎設施上的平臺（比如k8s）進行調度執行
從定義上抽象出相關的關鍵詞
-
微服務
-
持續交付（CI/CD）
-
DevOps
-
容器化、雲平臺調度
可見雲原生工程化實踐，涉及到的東西非常多，想要實踐好並不是一件容易的事情！接下來，我們把每一個方面都展開來探討。
2.關於微服務
關於微服務，與之對應的是單塊應用。在微服務之前，我們叫做一個war包打天下，隨着業務發展，不管是團隊規模，還是應用體量都越來越多，於是帶來了一些問題
-
溝通協調成本變高
-
應用耦合嚴重
-
需求響應遲緩
-
構建部署效率低下
最離譜的是，發佈一個補丁，整個項目組小夥伴都得留下來隨時待命，因爲不知道發佈過程中你負責的那一塊會不會出現問題！
有問題，就需要解決問題。既然問題的根源是團隊成員過多、應用體量過大，那就“拆”
-
將一個大團隊，拆成小團隊
-
將一個大的單塊應用，拆成一系列小的應用
這便是微服務，分而治之的解決問題之道。舉個例子
微服務，組織架構變遷參考模型
-
傳統職能型團隊，它的特點是從人的角度，按照職能劃分團隊，比如說產品、研發、測試、運維等。當啓動一個項目，我們其實是從不同的職能部門找人，組建成一個臨時的項目團隊。這個時候團隊成員之間的溝通協作成本其實是很高的，大家習慣不一樣，風格不一樣，需要一個磨合的過程。
-
跨職能型團隊，它的特點是從產品（或者項目）的角度來劃分團隊，比如說訂單團隊、商品團隊、物流團隊等。每個團隊成員都是長期、全職服務某個產品線，團隊成員之間的溝通協作會更加高效
微服務，應用架構變遷參考模型
-
單塊應用，從業務邊界參考，採用模塊化分層架構，所有模塊（用戶、商品、訂單）等，都將在一個war包內構建，部署到一個web服務器（tomcat），模塊之間是進程內協作
-
微服務應用，從業務邊界參考，採用服務化分層架構，將每個模塊獨立成一個服務，部署到獨立的web服務器（tomcat），每個服務都是獨立的進程，通過rpc跨進程方式協作
微服務公共關注點參考模型
當企業引入微服務工程化架構實踐以後，一併引入了分佈式系統固有的複雜性，因此有一些公共的關注點，是我們不得不去權衡及考量的
微服務，中臺化架構參考模型
3.關於CI/CD
CI（Continuous Integration）持續集成，是指開發不同功能模塊代碼的團隊成員之間，支持將代碼頻繁合併到一起，且相互之間不受到影響。
持續集成前置條件
-
自動化測試，研發團隊要爲每個新特性、代碼改進、bug修復創建自動化測試用例
-
持續集成服務器（gitLab、jenkins），監控代碼提交情況，針對每個提交執行自動化測試用例
持續集成收益
-
儘早獲取迴歸測試結果反饋，避免將問題提交到生產環境中
-
發佈編譯更容易，合併之初即將問題進行了有效規避
-
測試成本降低，提升QA團隊工作效率，不再需要花費大量時間成本在測試上面
CD（Continuous Deployment）持續部署，是指藉助平臺工具實現自動化構建、測試、部署，最終實現產品的高質量交付。
持續部署前置條件
-
研發團隊深入理解測試理念，因爲測試單元的健壯性，直接決定交付質量
-
文檔與部署頻率保持一致
持續部署收益
-
發佈頻率，交付更快，不需要停下來等待發布（不再強調發布日）
-
降低發佈風險，通過小批量發佈，發現問題可以更容易解決
-
提升客戶滿意度，客戶可以每天看到持續改進提升（不再是每月、每個季度、每年）
CI/CD實踐參考模型
下圖是一個完整的CI/CD實踐參考模型，可以看到從研發，到測試，到構建，到部署整個流程實現了自動化。
4.關於DevOps
DevOps其實是離不開CI/CD的，它的目標是將研發運維一體化，最終形成 Code -> Build -> Test -> Release -> Operate -> Code 循環。Dev代表研發階段；Ops代表運維階段。
DevOps參考模型
5.關於容器化、雲平臺調度
容器、雲平臺調度，業界當前應用最廣泛的Docker+K8s組合，這個話題比較大，後面再通過其它文章我們進行專門探討