2019年云原生時代的應用開發-微服務、service mesh與serverless.pdf

《2019年云原生時代的應用開發-微服務、service mesh與serverless.pdf》由會員分享，可在線閱讀，更多相關《2019年云原生時代的應用開發-微服務、service mesh與serverless.pdf（93頁珍藏版）》請在三個皮匠報告上搜索。

1、云原生時代的應用開發：微服務、service mesh與serverless應用云原生微服務容器CI/CDDevOps服務網格無服務器本交流包含以下內容 云原生應用設計的一些指導思想 衡量微服務架構的一種角度 微服務、服務網格、無服務器的各種玩法 業務微服務化的一些示例云原生00什么是云原生？容器 微服務 服務網格 不可變基礎設施 聲明式API 自動化 彈性 持續交付微服務概述01微服務大量功能在單個服務里整體部署，整體擴展單個服務包含獨立的一組功能分別部署，分別擴展切分配合+切分要切分的不只是業務邏輯 數據 配置 工具 運行環境 切分指導方針 Domain Driven Design（領域驅

2、動設計）Twelve-Factor App（十二要素）Beyond the Twelve-Factor App這些方針主要針對業務應用，基礎組件服務有部分不太適用應用設計時請記住 應用中需要的功能不一定需要自己實現 應用可能被不同人運行在很多個環境 應用運行中可能隨時會發生故障 應用未來會需要被不同人進行很多次升級一些可能的做法 為了讓我的程序可以運行在各套環境，我的代碼資源中為各套環境提供了相應配置文件/src/main/resources-application-dev.yaml-application-test.yaml-application-pre.yaml-application-

3、prod.yaml 為了減少網絡調用提高性能，我讓依賴的X服務封裝成SDK，我直接本地調用 為了提高性能，我從數據庫把數據直接加載到本地內存緩存起來基準代碼 一份基準代碼（Codebase），多份部署（deploy）不同應用的代碼在一個代碼庫 線上常態化運行一個代碼庫多個分支 線上直接修改代碼 不同應用的代碼用不同代碼庫 相同邏輯抽象為類庫或者單獨服務 在代碼庫修改代碼并重新測試上線建議的方式不好的方式依賴 顯式聲明依賴關系（dependency）依賴項不明確 確切聲明依賴項建議的方式不好的方式配置 在環境中存儲配置 代碼中寫死配置 在代碼庫中包含配置文件 環境變量*全局配置服務*每個環境分別

4、管理的配置文件*建議的方式不好的方式后端服務 把后端服務(backing services)當作附加資源 要求后端服務必須以某種方式部署在某個網絡位置 應用與后端服務松耦合，后端服務只是一個可替換的網絡地址 更多使用獨立的后端服務而不是全部自己實現建議的方式不好的方式構建，發布，運行 嚴格分離構建和運行 線上直接修改代碼 上線過程遇到問題立即修改代碼直接上線 在代碼庫修改代碼并重新測試上線 上線過程遇到問題先回滾建議的方式不好的方式進程 以一個或多個無狀態進程運行應用 使用本地磁盤存儲數據 應用內存保存不可重新載入的關鍵數據 粘滯會話 使用單獨的存儲服務 應用完全無狀態 可以用本地緩存，但必須

5、是可以從存儲服務重建的 分布式緩存Session數據建議的方式不好的方式端口綁定 通過端口綁定(Port binding)來提供服務 監聽端口代碼中寫死 所有服務都監聽80 主要靠ip來區分服務 通過配置指定監聽端口，并綁定到對外端口上建議的方式不好的方式并發 通過進程模型進行擴展 使用更大的機器以便啟動更多的線程 使用本地鎖實現同步 擴展更多的進程實例 減少需要鎖定的資源，若需要使用分布式鎖 投入更多精力優化應用的整體性能，而不是單個進程的性能建議的方式不好的方式易處理 快速啟動和優雅終止可最大化健壯性 啟動時加載大量數據 請求處理中包含大量邏輯 請求處理未完成前不可終止 應用被設計成可以隨

6、時終止隨時重新啟動 優雅終止：先停止接受新請求，同時將正在處理的請求精力執行完成建議的方式不好的方式開發環境與線上環境等價 盡可能的保持開發，預發布，線上環境相同 開發環境使用本地緩存和SqlLite，線上用分布式緩存和數據庫 開發或預發環境關閉某些配置 每個月打包一大堆功能整體上線 開發和線上依賴的服務要完全一致 每個小功能獨立上線建議的方式不好的方式日志 把日志當做事件流 應用本地存儲日志 應用統一收集和展現建議的方式不好的方式管理進程 后臺管理任務當作一次性進程運行 管理服務可以隨便搞 同樣遵循上述要素建議的方式不好的方式API優先 合理、高兼容性的API作為服務間交互的契約 集成能力提

7、供方的代碼 API不兼容升級 使用標準化API調用 API兼容升級 Rest風格的API建議的方式不好的方式觀測 收集和展現觀測數據 先把業務跑起來 日志、監控、調用鏈一個也不能少建議的方式不好的方式認證和授權 重視安全問題 靠保密保證安全 內網完全不設防 依靠算法和機制 內網也需要鑒權，尤其是對于核心應用和數據建議的方式不好的方式 靠規定？這么多要素，如何保證執行？靠懲罰？靠框架和系統？基準代碼 依賴 配置 后端服務 構建，發布，運行 進程 端口綁定 并發 易處理 開發環境與線上環境等價 日志 管理進程 API優先 觀測 認證和授權配合配合的目標 讓微服務之間更好的配合 讓微服務和依賴的服務

8、更好的配合 讓微服務和研發上線過程更好的配合 讓微服務和問題定位過程更好的配合服務治理服務治理能力流量治理 服務發現 健康檢查 負載均衡 熔斷 調用協議 策略路由 流量復制 錯誤或信息注入 API管理安全治理 代碼安全 運行安全 數據安全 配置安全 調用安全生命周期治理 CI/CD 服務部署 彈性伸縮 故障恢復業務輔助 配置管理 分布式鎖 分布式事務 任務調度 消息總線服務觀測 日志匯集 服務監控 調用圖譜 調用鏈 性能分析流量治理 服務發現 健康檢查 負載均衡 熔斷 調用協議 策略路由 流量復制 錯誤或信息注入 API管理安全治理 代碼安全 運行安全 數據安全 配置安全 調用安全生命周期治理

9、 CI/CD 服務部署 彈性伸縮 故障恢復業務輔助 配置管理 分布式鎖 分布式事務 任務調度 消息總線服務觀測 日志匯集 服務監控 調用圖譜 調用鏈 性能分析服務治理能力如何使用 集成方式 服務網格業務模塊與服務治理分開 開發語言無關，開發框架無關 業務開發者不用關心服務治理特性 運行時動態調整各種規則和策略 服務治理功能升級獨立于業務模塊應用sidecar應用sidecar注冊中心應用應用注冊中心業務模塊與服務治理整合 依托特定開發語言和開發框架 業務開發者調用服務治理特性 規則和策略通過配置來調整 服務治理功能升級依賴業務上線網格場景動態流量策略 Day 1V1V2其他用戶測試賬號 Day

10、 3 Day 4V1V295%5%V1V280%20%Day nV1V2100%Day xDebug logWarnlog/user/sub其他接口 Day x+1Debug logWarnlog/user/subUser：xxx其他接口微服務運維方式 傳統方式 從運維主機上的應用進化到運維標準的容器鏡像 人工伸縮或有限范圍內的彈性伸縮 按固定占用的資源付費 Serverless（無服務器）僅上傳鏡像或代碼，基本沒有運維工作 完全彈性伸縮，可以縮至0 按實際調用占用的資源付費Serverless場景抽獎函數服務Serverless KVAPI網關活動配置簽到抽獎結束活動對象存儲服務頁面代碼活動

11、配置頁面活動結束頁面簽到頁面抽獎頁面組織方參與者抽獎者服務治理相關開源項目一覽組件類 Kubernetes Eureka/Consul/etcd ZipKin/Jagger Envoy gRPC/Thrift Prometheus Kong/Zuul Apollo集成類 Spring Cloud Dubbo Motan Tars go-micro網格類 Istio Linkerd Nginmesh Consul Connect Kong Mesh Kuma無服務器類 Knative OpenFaas Kubeless Fission常見微服務框架02Spring CloudSpring Clo

12、ud Spring體系服務治理的整體框架 統一規范和接口使各種開源組件可以按統一的方式接入且無縫切換 服務注冊與發現 調用協議和工具 客戶端負載均衡 請求容錯 配置中心 網關 調度 主庫92個項目,孵化器7個項目spring-cloud-netflixspring-cloud-consulspring-cloud-zookeeperspring-cloud-etcdspring-cloud-kubernetesspring-cloud-configspring-cloud-sleuthspring-cloud-gatewaySpring-cloud-awsspring-cloud-deploy

13、er支持多種可選組件Spring Cloud常見使用方式外部服務API Gateway服務AEurekaRibbonHystrixEureka配置中心SleuthBusELKZipkinConfig服務BEurekaRibbonHystrixSleuthConfigEurekaRibbonHystrixSleuthZuulSpring Cloud功能流量治理 服務發現 健康檢查 負載均衡 熔斷 調用協議 策略路由 流量復制 錯誤或信息注入 API管理安全治理 代碼安全 運行安全 數據安全 配置安全 調用安全生命周期治理 CI/CD 服務部署 彈性伸縮 故障恢復業務輔助 配置管理 分布式鎖 分布

14、式事務 任務調度 消息總線服務觀測 日志匯集 服務監控 調用圖譜 調用鏈 性能分析缺的功能怎么辦？SpringCloud+微服務平臺微服務應用SpringCloud應用Dubbo應用其它應用API 網關（+Web應用防火墻）第三方服務用戶Go應用微服務治理服務注冊與發現配置中心服務路由調用鑒權負載均衡容錯保護應用觀測應用日志應用監控調用鏈操作審計應用對外開放代碼托管持續集成持續交付彈性伸縮生命周期管理SpringCloud+Kubernetes外部服務API Gateway服務AEurekaRibbonHystrixEureka配置中心SleuthBusELKZipkinConfig服務BEu

15、rekaRibbonHystrixSleuthConfigEurekaRibbonHystrixSleuthZuulKubernetes感覺Kubernetes功能有點每太用起來？KubernetesSpringCloud+Kubernetes（方式二）外部服務API Gateway服務AKubernetesRibbonHystrixEureka配置中心SleuthBusELKZipkinConfig服務BEurekaRibbonHystrixSleuthConfigKubernetesRibbonHystrixSleuthZuulServiceSecretConfigMapspring-cl

16、oud-kubernetesspring-cloud-kubernetesstarter功能spring-cloud-starter-kubernetes使用K8S Service進行服務發現，無客戶端負載均衡支持。spring-cloud-starter-kubernetes-config基于K8S的ConfigMap和Secrets實現配置中心邏輯。spring-cloud-starter-kubernetes-ribbon查詢服務對應的K8S端點，可進行客戶端負載均衡spring-cloud-starter-kubernetes-all全部特性 Spring Cloud+Kubernet

17、es部署 Spring Cloud+Kubernetes服務發現如何選擇？Envoy專為服務網格架構而設計 高性能、資源占用少、運行依賴少 HTTP/2和GRPC支持 負載均衡+（自動重試，熔斷、全局流控等）豐富觀測數據 豐富的動態配置API接口 Cluster Discovery Service(CDS)Endpoint Discovery Service(EDS)Route Discovery Service(RDS)Listener Discovery Service(LDS)Secret Discovery Service(SDS)Aggregated Discovery Servic

18、e(ADS)靜態配置動態配置CDSEDSIstioIstio 架構清晰 數據面 控制面 功能完整 調用 安全 控制 觀察 實現開放 插件化 多種可選實現Istio-Pilot能做什么 根據Host、Path、Header等靈活配置路由 百分比，指定用戶，指定接口，指定版本 流量鏡像（拋棄鏡像的響應）靈活配置容錯 故障注入（如一定比例的HTTP延遲或者500錯誤）服務發現 客戶端負載均衡Istio-Mixer能做什么 配置Quota 配置訪問控制(match:destination.labelsapp=ratings&source.labelsapp=reviews)配置請求轉換邏輯 配置黑白名

19、單 統一日志 統計和監控 Grafana可視化 分布式跟蹤（jaeger）生成服務調用關系圖Kubernetes+Istio功能流量治理 服務發現 健康檢查 負載均衡 熔斷 調用協議 策略路由 流量復制 錯誤或信息注入 API管理安全治理 代碼安全 運行安全 數據安全 配置安全 調用安全生命周期治理 CI/CD 服務部署 彈性伸縮 故障恢復業務輔助 配置管理 分布式鎖 分布式事務 任務調度 消息總線服務觀測 日志匯集 服務監控 調用圖譜 調用鏈 性能分析服務網格網格場景全鏈路AB測試首頁服務V1用戶服務V1用戶服務V2訂閱服務V1訂閱服務V2熱點服務V1熱點服務V2首頁服務V2網關5%95%G

20、roup:V1Group:V1Group:V1Group:V2Group:V2Group:V2怎么讓同一個用戶在所有微服務都在同一個組？其他一些網格的業務場景 容錯測試 部署階段流量控制 統一基準日志和觀測能力 統一基準安全能力優勢 開發語言無關，開發框架無關 業務開發者不用關心服務治理特性 運行時動態調整規則和策略 服務治理升級獨立于業務模塊 功能豐富 一次接入，持續受益劣勢長期 不可避免的性能損失 業務并不能完全“不用關心”短期 高昂的學習成本 網格方案成熟度有限遷移到服務網格的難點 服務不在Kubernetes上 技術因素 使用習慣因素 服務使用了上一代服務治理框架 SpringClou

21、d目前可考慮網格的業務或許是？業務已經穩定運行在Kubernetes超過半年 服務治理能力升級需求明確 業務的技術棧不統一 業務可以接受引入10ms級別的總延遲探討 非Kubernetes環境是否能上網格？基于Envoy自研網格是否可行？繼續觀望還是采納？ServerLess03AWS眼中的Serverless“現代化的架構是使用AWS的服務、Lambda的功能，把它們連接在一起。沒有中間層、沒有應用層，也沒有數據庫層，它是一系列web服務連接在一起，由功能連接在一起，無需服務器，而安全、可靠性、規模、性能、成本管理這些事項由AWS做好?！?Everyone wants just to foc

22、us on business logic.UC Berkley定義的ServerlessAs a result,cloud providers are quick to emphasize that serverless is not only FaaS.It is FaaS supported by a standard library:the various multitenanted,autoscaling services provided by the vendor.In the case of AWS,this includes S3(large object storage),D

23、ynamoDB(key-value storage),SQS(queuing services),SNS(notification services),and more.This entire infrastructure is managed and operated by AWS;developers simply register FaaS code that uses these services and receive pay-as-you-go bills that scale up and down according to their storage and compute u

24、sage.目前云廠商的常見Serverless架構目前云廠商的常見Serverless架構云服務函數服務響應各種事件其他云服務調用發送Events返回FaaSFaaS是計算層的Serverless架構實現方式之一，天然無狀態的設計，實現自動的水平擴展。FaaS就像是一個強力膠水一樣，連接了云上的各種服務，可用于輕松構建業務系統，實現高可用，可擴展，同時又很經濟實惠的架構。越豐富的云上服務，例如大數據分析系統，AI系統，越能增強FaaS的能力。函數有兩種觸發方式：HTTP請求 事件BaaSBaaS（Backend as a Service）作為后端基礎服務，由云廠商托管或者第三方提供，實現了超高

25、的擴展性，并作為商品化的服務提供標準SLA，作為支撐FaaS外置狀態或者持久化數據的基本組件，負責用戶對于數據庫、消息隊列、對象或者KV存儲等需求。多以API的方式對用提供服務，用戶無需關心底層的服務器或者運行時的擴容縮容問題。Serverless的架構實現-1原始架構實現-2Serverless核心要點 No OPS Auto Scaling（Scaling in/out)Buy for what you use私有云里Serverless是否有價值？knative Build 從代碼編譯出鏡像 Serving 執行鏡像 流量策略 動態伸縮 Event 觸發執行Knative Serving

26、Serverless有哪些可能的落地場景應用后端 移動APP的后端 物聯網Iot的后端AI應用 智能客服 視頻和圖片識別，分析實時數據處理 文件處理 流數據處理 ETL業務微服務化變遷示例04主機主機主機主機主機主機原始架構數據庫緩存前臺服務(登錄、商品展示、下單、訂單查看等)后臺系統(商品及庫存管理、訂單管理等)定時任務(對賬、結算等)負載均衡VPC云主機云主機云主機使用云的能力云存儲和基礎中間件服務前臺服務后臺系統定時任務云負載均衡云API網關VPC云主機云主機新服務接入微服務平臺云主機云主機前臺服務后臺系統定時任務云負載均衡積分云注冊中心云微服務網關云API網關云調用鏈分析云存儲和基礎中

27、間件服務云主機會員卡VPC引入Kubernetes云主機云Kubernetes云主機前臺服務后臺系統定時任務云負載均衡積分會員卡云注冊中心云微服務網關云API網關云調用鏈分析云存儲和基礎中間件服務逐漸拆分原有服務VPC云主機云Kubernetes云主機前臺服務后臺系統定時任務云負載均衡積分會員卡云注冊中心云微服務網關云API網關云調用鏈分析訂單商品庫存云存儲和基礎中間件服務服務分層VPC云主機云Kubernetes云主機前臺服務后臺系統定時任務云負載均衡積分會員卡云API網關訂單商品庫存記賬首頁商品頁業務層中臺基礎層云注冊中心云微服務治理云調用鏈分析云存儲和基礎中間件服務部分新業務采納無服務器

28、架構VPC云主機云Kubernetes云主機前臺服務后臺系統定時任務云負載均衡積分會員卡云API網關訂單商品庫存記賬首頁商品頁業務層中臺基礎層云函數服務簽到云注冊中心云微服務治理云調用鏈分析云存儲和基礎中間件服務全面Kubernetes化VPC云Kubernetes前臺服務后臺系統定時任務云負載均衡積分會員卡云注冊中心云微服務治理云API網關云調用鏈分析訂單商品庫存云存儲和基礎中間件服務記賬首頁商品頁業務層中臺基礎層云函數服務簽到服務網格。小結05微服務大量功能在單個服務里整體部署，整體擴展單個服務包含獨立的一組功能分別部署，分別擴展切分配合+基準代碼 依賴 配置 后端服務 構建，發布，運行

29、進程 端口綁定 并發 易處理 開發環境與線上環境等價 日志 管理進程 API優先 觀測 認證和授權云原生應用12+3要素服務治理能力流量治理 服務發現 健康檢查 負載均衡 熔斷 調用協議 策略路由 流量復制 錯誤或信息注入 API管理安全治理 代碼安全 運行安全 數據安全 配置安全 調用安全生命周期治理 CI/CD 服務部署 彈性伸縮 故障恢復業務輔助 配置管理 分布式鎖 分布式事務 任務調度 消息總線服務觀測 日志匯集 服務監控 調用圖譜 調用鏈 性能分析只用SpringCloud只用KubernetesSpringCloud+Kubernetes服務網格Serverless優勢開發效率治理能力中運維效率開發效率治理能力中運維效率治理能力高開發節約語言及框架無關運維效率成本節約劣勢框架綁定治理能力弱框架綁定運行效率使用習慣適用場景搭配一個微服務平臺使用搭配各種觀測組件使用Java技術棧大多數業務非延遲敏感，流量規則復雜的業務事件觸發型業務微服務治理框架小結