Kubernetes與Openstack融合的企業(yè)級微服務架構課件

1、Kubernetes與Openstack融合的企業(yè)級微服務架構技術創(chuàng)新 變革未來第1頁，共28頁。第2頁，共28頁。2016年，中國人看手機的時間平均超過2小時2016年，全球平均每個用戶花在移動互聯(lián)網上的時間為3.1小時第3頁，共28頁。云計算拉開”互聯(lián)網”架構變革序幕OpenStack is not the end , it is the beginning or a journey towards ”Internet” Architecture移動互聯(lián)（Mobile）社交（Social）大數(shù)據(jù)（Information）微服務和分布式架構（ Micro-service）云計算平臺（ Clo

2、ud & OpenStack ）軟件定義網絡（ SDN）軟件定義存儲（ SDS）虛擬化（ virtualization）IT基礎設施（硬件和操作系統(tǒng)）互聯(lián)網（”Internet” Architecture）第4頁，共28頁。單體架構 VS 微服務架構 https:/bliki/MicroservicePremium.html伴隨業(yè)務的快速成長，當你的應用面臨以下瓶頸：業(yè)務復雜度日益增高 團隊規(guī)模日益龐大原有單體應用的維護、升級和部署難度變大 應用的迭代效率越來越慢應對高并發(fā)業(yè)務存在性能瓶頸 缺乏足夠的容錯性是時候考慮微服務架構了！第5頁，共28頁。單體架構 VS 微服務架構 https:/ar

3、ticles/microservices.html微服務架構是隨著云計算的發(fā)展應運而生的一種軟 件設計風格，與之對立的是傳統(tǒng)的單體架構技術視角采用一組服務的方式來構建一個應用系統(tǒng)微服務具備自包含性，可作為獨立的進程存在不同微服務之間通過一些輕量級交互機制來通信，通常是HTTP型的API業(yè)務視角單一職責原則 (Single Responsibility Principle)按照業(yè)務(而非技術)的邊界來確定服務的邊界第6頁，共28頁。提升迭代效率與傳統(tǒng)單體架構應用不 同，每個微服務是一個 能獨立發(fā)布的應用服 務，可作為獨立組件進 行編譯、部署升級代價小，大大提 升效率，需求變更響應 速度快彈性擴展

4、容錯能力豐富的技術棧提高組織效率單體架構緊耦合，而微 服務強調模塊化的結構， 微服務之間是松耦合的在應用擴展時，僅需擴 展有瓶頸的微服務，有 利于應用的模塊化擴 展單體架構應用所有功能 在同一進程內實現(xiàn)，一 個功能bug可能導致整 體崩潰，而微服務可實 現(xiàn)進程級別隔離每個微服務是自治的， 單個服務的異常通常不 會導致整個系統(tǒng)的故障根據(jù)業(yè)務的需求，不同 的服務可以根據(jù)業(yè)務特 性實現(xiàn)靈活的技術選型不同的微服務可以依賴 不同的編程語言、開發(fā) 框架以及數(shù)據(jù)存儲技術。 針對不同的微服務，可 以選擇最合適的技術棧每個微服務可以由獨立 的Team開發(fā)和維護，依 賴方按照統(tǒng)一的接口規(guī) 范定義好輸入和輸出即 可

5、，溝通成本低、效率 高“2 pizza”原則，團隊 小而精，釋放生產力12345第7頁，共28頁。2017，基于云環(huán)境的創(chuàng)新模式設計者和開發(fā)者的比例直線上升第8頁，共28頁。Step 1架構設計與實現(xiàn)微服務開發(fā)框架：Spring Cloud / Dubbo / 支撐平臺：容器（Kubernetes / Docker / ）IaaS平臺（OpenStack / 公有云 / ）PaaS平臺（OpenShift / CloudFoundry / ）業(yè)務域&技術域技術域組織結構域&技術域DevOps持續(xù)集成: Jenkins / 代碼管理: GitLab / GitHub / 自動部署：Ansible

6、 / Puppet / Step 2Step 3服務建模微服務拆分：領域驅動設計 (DDD)第9頁，共28頁。第10頁，共28頁。Kubernetes設計理念源于Google過去15年在生產環(huán)境中運行容器的管理經 驗（前身為Google數(shù)據(jù)中心資源管理系統(tǒng)Borg）2014年開源，目前已經迭代到V1.5版本為管理容器而生，核心是面向應用集合了社區(qū)中先進的理念和實戰(zhàn)技術由CNCF(Cloud Native Computing Foundation) 管理主要功能完備的應用生命周期管理彈性伸縮負載均衡服務編排服務發(fā)現(xiàn)資源調度服務自愈機制第11頁，共28頁。服務發(fā)現(xiàn)Kube-DNSService配置

7、中心ConfigMapSecret負載均衡Kube-ProxyService容錯性Self-HealingHealth Check彈性伸縮Auto-Scaling服務編排DeploymentHelm任務管理JobCronJob日志管理EFK監(jiān)控PrometheusHeapster升級Rolling-Update第12頁，共28頁。kubednsdnsmasqexechealthzPodK8s livenessProbeK8s ServiceKube-DNSLookup upstreamnslookupnslookupHealth APIService ClusterIPLookup with

8、ServiceName.NamespaceK8s ServiceresourcesList/watch API基于云平臺構建的微服務架構的應用，由于頻繁的擴縮容和更新升級，微服務的網絡標識經常會動態(tài)變化，因此需要引入服務發(fā)現(xiàn)機制服務發(fā)現(xiàn)的實現(xiàn)方式：云平臺內置的服務發(fā)現(xiàn)組件、自建服務發(fā)現(xiàn)系統(tǒng)（如Etcd、ZooKeeper、Consul）、微服務框架（如SpringCloud Eureka）Kubernetes通過集群內部的DNS服務(Kube-DNS)，配合Service，實現(xiàn)服務發(fā)現(xiàn)實現(xiàn)原理： Kubernetes將Service的名稱當做域名注冊到Kube-DNS中，通過DNS服務完成Se

9、rvice名稱到Service的ClusterIP的解析，因此通過Service的名稱就可以訪問其提供的服務第13頁，共28頁。企業(yè)級應用的配置管理復雜：配置信息的種類繁多多套環(huán)境并存：開發(fā)、測試、預發(fā)布、生產采用微服務設計，服務數(shù)量增加導致配置管理復雜度增加ConfigMapService A-1Service B-1Service A-2Service B-2配置更新繁瑣：更新配置經常需要重新構建、部署應用構建微服務架構的統(tǒng)一配置中心：Kubernetes ConfigMap配置與容器應用分離集中管理應用配置批量動態(tài)更新應用配置Secret：處理敏感信息第14頁，共28頁。Service

10、ClusterIP : PortNodeNodePodPodPodPodPodPodKube-Proxy (Iptables)外部 ClientPodKubernetes Service到后端一組Pod實例的負載均衡和請求轉發(fā)， 由Kubernetes組件Kube-Proxy實現(xiàn)Kube-Proxy借助Iptables工具，設置轉發(fā)規(guī)則，將Service的流量進行重定向默認采用輪詢方式（Round Robin）進行分配，支持會話保持外部負載均衡實現(xiàn)：自建軟件/硬件負載均衡器(HAProxy/Nginx/F5）Kubernetes Ingress使用IaaS平臺的負載均衡器第15頁，共28頁。應

11、對高并發(fā)高流量業(yè)務場景定時性/周期性秒殺活動促銷活動定時搶票突發(fā)性突發(fā)應急性事件熱點事件提前規(guī)劃， 手動實施彈 性伸縮基于監(jiān)控指 標，設置自 動彈性伸縮典型應用行業(yè)金融電商運營商公共服務應急管理調整RC/RS 控制的Pod 實例副本數(shù) 量設置HPA， 根據(jù)Pod負 載動態(tài)調整 實例數(shù)量第16頁，共28頁。故障自愈（Self-Healing）：容器異常時，自動重啟Node節(jié)點宕機時，重新調度并啟動容器應用健康檢查（Health-Check）：Liveness探針：檢查容器是否處于運行狀態(tài)，如檢測到容器運行狀態(tài)不正常，則Kubelet會 殺掉容器，并根據(jù)設置的Restart Policy進行相應操

12、作（如本地重啟）Readness探針：判斷容器內服務是否已正常工作，如未啟動完成或工作異常，則將該服務 所在Pod的IP從Service的Endpoint中移除，不接受請求三種類型的檢測：TCP檢查：通過容器的IP和端口號進行TCP檢查HTTP檢查：通過容器的IP、端口號及路徑，進行HTTP檢查在容器內部執(zhí)行一條命令，以判斷容器健康狀態(tài)第17頁，共28頁。Deployment 編排文件示例副本數(shù)量Pod定義模板Deployment對Pod和Replica Set的定義和描述模板，目的 是更好的解決容器應用的編排問題典型應用場景：通過創(chuàng)建Deployment對象來生成Pod和RSDeployme

13、nt更新/回滾（均采用灰度方式）檢查Deployment狀態(tài)來查看部署進度Helm項目第18頁，共28頁?；叶壬墸翰捎肒ubernetes原生的灰度升級方式，保證業(yè)務系統(tǒng)在升級過程中不中斷，升級過程中新/舊版本并存快速回滾：Docker鏡像版本管理機制，在升級發(fā)生問題時，保障鏡像版本可隨時進行回滾操作降低微服務升級的風險第19頁，共28頁。第20頁，共28頁。狀態(tài)問題：有狀態(tài)（集群）服務并不完全適合部署在容器上，如何處理？管理問題：容器需要與虛擬機、物理機協(xié)同工作，如何管理和編排？安全問題：容器化微服務應用，應用之間如何實現(xiàn)安全隔離？新的問題網絡問題：異構支撐平臺的SDN網絡解決方案，如何選

14、擇？存儲問題：異構支撐平臺的軟件定義存儲解決方案，如何選擇？通過Kubernetes與OpenStack的融合，構建一體化支撐平臺第21頁，共28頁。OpenStack專注于云數(shù)據(jù)中心基礎設 施的編排、管理和調度Kubernetes以應用為中心，專注于創(chuàng)新型云原生應用的交付和管理融合架構愿景1+1 2二者優(yōu)勢互補，打通云數(shù)據(jù)中心 新一代應用交付的最后一公里加速應用交付，助力業(yè)務創(chuàng)新第22頁，共28頁。一體化運維管理統(tǒng)一管理視圖統(tǒng)一編排統(tǒng)一應用中心統(tǒng)一網絡鏡像管理容器集群管理企業(yè)級容器云平臺DevOps應用管理Neutron統(tǒng)一存儲計算資源管理企業(yè)級OpenStack平臺 網絡資源管理存儲資源管

15、理LBaaS / FWaaS / VPNaaS / Cinder / ManilaCeph 分布式存儲集中式商業(yè)存儲虛擬機物理機VMVMVMVM監(jiān)控告警日志管理租戶管理安全認證計量計費自動部署Kubernetes容器集群容器VMVMVM虛擬機Kubernetes容器集群容器 物理機第23頁，共28頁。接入API層AppAppAppWEB負載均衡器ZoZookoekeepeepre集r集群群（服務Z注oZoo冊koe和keep發(fā)eep現(xiàn)re集）r集群群（服服務務注Z注o冊o冊和ke和發(fā)ep發(fā)現(xiàn)e現(xiàn)）r集）群（服服務務注注冊冊和和發(fā)發(fā)現(xiàn)現(xiàn)）負載均衡器負載均衡器登錄服務 下單服務搶單服務 下單服務

16、搶單服務 監(jiān)控指揮 搶單服務 監(jiān)控指揮撮合系統(tǒng) 廣告操控 路徑分析撮合系統(tǒng) 廣告操控 路徑分析 撮合系統(tǒng) 廣告操控 路徑分析ReRdeids集is集群群（緩緩存存服Re服務di務器s集器）群）（緩存服務器）MMonognogDoBD集B集群群（文文檔M檔型o型n數(shù)g數(shù)據(jù)oD據(jù)庫B庫）集）群（文檔型數(shù)據(jù)庫）MMMaraaiarriDiaaBDDBB集群（關系型數(shù)據(jù)庫）微服務應用層登錄服務優(yōu)惠券統(tǒng)計分析登錄服務優(yōu)惠券統(tǒng)計分析支付支付 清算 清算RPC狀態(tài)數(shù)據(jù)，撮合數(shù)據(jù)， 訂單數(shù)據(jù)位置數(shù)據(jù)訂單數(shù)據(jù)請求服務AppAppAppWEBWEBWEBAPIAPISocket SocketRestRestAPIAPISocket SocketRestRestAPIAPISocket SocketRestRestAPIAPISocket Socket RestRest第24頁，共28頁。統(tǒng) 一云 計 算 管 理平 臺 裸機 部署區(qū)容器 部署區(qū)虛機 部署區(qū)登錄服務搶單 服務撮合系統(tǒng)優(yōu)惠券下單服務登錄 服務搶單 服務撮合 系統(tǒng)優(yōu)惠券下單 服務支付清算支付清算API服務VMAPI服務VMZooke eper VMRedisVMRedisVM監(jiān)控指揮統(tǒng)計分析廣告 操控路徑 分