2020国产成人精品视频,性做久久久久久久久,亚洲国产成人久久综合一区,亚洲影院天堂中文av色

分享

大神講解微服務(wù)治理的技術(shù)演進(jìn)和架構(gòu)實(shí)踐

 xujin3 2019-05-13

摘要:隨著業(yè)務(wù)的發(fā)展,規(guī)模擴(kuò)大,服務(wù)越來(lái)越多,需要協(xié)調(diào)線(xiàn)上運(yùn)行的各個(gè)服務(wù),保障服務(wù)的SLA;基于服務(wù)調(diào)用的性能KPI數(shù)據(jù)進(jìn)行容量管理,合理分配各服務(wù)的資源占用;對(duì)故障業(yè)務(wù)做服務(wù)降級(jí)、流量控制、流量遷移等快速恢復(fù)業(yè)務(wù)。怎樣的服務(wù)治理框架能滿(mǎn)足需求?


李林鋒
,華為PaaS平臺(tái)架構(gòu)師,8年Java NIO通信框架、平臺(tái)中間件架構(gòu)設(shè)計(jì)和開(kāi)發(fā)經(jīng)驗(yàn),開(kāi)源框架Netty中國(guó)推廣者。精通Netty、Mina、RPC框架、企業(yè)ESB總線(xiàn)、分布式服務(wù)框架、云計(jì)算等技術(shù),《Netty權(quán)威指南》、《分布式服務(wù)框架原理與實(shí)踐》作者,公司總裁技術(shù)創(chuàng)新獎(jiǎng)獲得者


我今天分享的主題是《微服務(wù)治理的技術(shù)演進(jìn)和架構(gòu)實(shí)踐》

本次分享,將分為三個(gè)部分。

  1. 為什么需要服務(wù)治理

  2. 服務(wù)治理的技術(shù)演進(jìn)歷程

  3. 云端微服務(wù)治理框架設(shè)計(jì)

為什么需要服務(wù)治理?

第一、業(yè)務(wù)需求

隨著業(yè)務(wù)的發(fā)展,服務(wù)越來(lái)越多,如何協(xié)調(diào)線(xiàn)上運(yùn)行的各個(gè)服務(wù),保障服務(wù)的SLA,對(duì)服務(wù)架構(gòu)和運(yùn)維人員是一個(gè)很大的挑戰(zhàn)。隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大,小服務(wù)資源浪費(fèi)等問(wèn)題逐漸顯現(xiàn),需要能夠基于服務(wù)調(diào)用的性能KPI數(shù)據(jù)進(jìn)行容量管理,合理分配各個(gè)服務(wù)的資源占用,提高機(jī)器的利用率。線(xiàn)上業(yè)務(wù)發(fā)生故障時(shí),需要對(duì)故障業(yè)務(wù)做服務(wù)降級(jí)、流量控制、流量遷移等,快速恢復(fù)業(yè)務(wù)。

著開(kāi)發(fā)團(tuán)隊(duì)的不斷擴(kuò)大,服務(wù)的上線(xiàn)越來(lái)越隨意,甚至發(fā)生功能相同、服務(wù)名不同的服務(wù)同時(shí)上線(xiàn)。上線(xiàn)容易下線(xiàn)難,為了規(guī)范服務(wù)的上線(xiàn)和下線(xiàn),在服務(wù)發(fā)布前,需要走服務(wù)預(yù)發(fā)布流程,由架構(gòu)師或者項(xiàng)目經(jīng)理對(duì)需要上線(xiàn)的服務(wù)做發(fā)布審核,審核通過(guò)的才能夠上線(xiàn)。為了滿(mǎn)足服務(wù)線(xiàn)下管控、保障線(xiàn)上高效運(yùn)行,需要有一個(gè)統(tǒng)一的服務(wù)治理框架對(duì)服務(wù)進(jìn)行統(tǒng)一、有效管控,保障服務(wù)的高效、健康運(yùn)行。

第二、技術(shù)需求

大部分服務(wù)化框架的服務(wù)屬性通過(guò)XML配置或者Java注解的方式進(jìn)行定義,以服務(wù)端流量控制為例:


服務(wù)發(fā)布的XML文件通常會(huì)打包到服務(wù)提供者的jar包中,部署在Java Web或者Java Container容器中,存儲(chǔ)在服務(wù)端的本地磁盤(pán)中。


無(wú)論采用注解還是XML配置的方式,如果需要在運(yùn)行態(tài)動(dòng)態(tài)修改服務(wù)提供者的流控閾值,都需要在本地修改配置或者修改源碼,重新打包部署并升級(jí)應(yīng)用。無(wú)法實(shí)現(xiàn)在線(xiàn)、配置化的修改和動(dòng)態(tài)生效。由于諸如流控閾值、服務(wù)的超時(shí)時(shí)間等無(wú)法預(yù)測(cè)出最優(yōu)值,需要修改之后上線(xiàn)驗(yàn)證,根據(jù)服務(wù)運(yùn)行效果決定是否再做調(diào)整,因此經(jīng)常需要反復(fù)調(diào)整,采用修改源碼-重新打包部署-應(yīng)用升級(jí)的方式進(jìn)行服務(wù)治理,效率低下。因此,在技術(shù)上需要一個(gè)服務(wù)治理框架,提供Web Portal,微服務(wù)運(yùn)維或者治理人員通過(guò)在線(xiàn)配置化的方式修改服務(wù)提供者或者消費(fèi)者的屬性,可以實(shí)時(shí)動(dòng)態(tài)生效。

服務(wù)治理的技術(shù)演進(jìn)歷程

第一代服務(wù)治理 SOA Governance: 以IBM為首的SOA解決方案提供商推出的針對(duì)企業(yè)IT系統(tǒng)的服務(wù)治理框架,它主要聚焦在對(duì)企業(yè)IT系統(tǒng)中異構(gòu)服務(wù)的質(zhì)量管理、服務(wù)發(fā)布審批流程管理和服務(wù)建模、開(kāi)發(fā)、測(cè)試以及運(yùn)行的全生命周期管理。

第二代以分布式服務(wù)框架為中心的服務(wù)治理:隨著電商和移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展,基于電商平臺(tái)的統(tǒng)一分布式服務(wù)框架的全新服務(wù)治理理念誕生,它聚焦于對(duì)內(nèi)部同構(gòu)服務(wù)的線(xiàn)上治理,保障線(xiàn)上服務(wù)的運(yùn)行質(zhì)量。相比于傳統(tǒng)IT架構(gòu)的服務(wù)治理,由于服務(wù)的開(kāi)發(fā)模式、部署規(guī)模、組網(wǎng)類(lèi)型、業(yè)務(wù)特點(diǎn)等差異巨大,因此服務(wù)治理的重點(diǎn)也從線(xiàn)下轉(zhuǎn)移到了線(xiàn)上服務(wù)質(zhì)量保障。

第三代以云化為核心的云端微服務(wù)治理架構(gòu):2013年至今,隨著云計(jì)算和微服務(wù)架構(gòu)的發(fā)展,以AWS為首的基于微服務(wù)架構(gòu)   云服務(wù)化的云端服務(wù)治理體系誕生,它的核心理念是服務(wù)微自治,利用云調(diào)度的彈性和敏捷,逐漸消除人工治理。微服務(wù)架構(gòu)可以實(shí)現(xiàn)服務(wù)一定程度的自治,例如服務(wù)獨(dú)立打包、獨(dú)立部署、獨(dú)立升級(jí)和獨(dú)立擴(kuò)容。通過(guò)云計(jì)算的彈性伸縮、單點(diǎn)故障遷移、服務(wù)健康度管理和自動(dòng)容量規(guī)劃等措施,結(jié)合微服務(wù)治理,逐步實(shí)現(xiàn)微服務(wù)的自治。

第一代 SOA Governance服務(wù)治理

第一代SOA Service GovernanceSOA Governance的定位:面向企業(yè)IT系統(tǒng)異構(gòu)服務(wù)的治理和服務(wù)生命周期管理,它治理的服務(wù)通常是SOA服務(wù)。傳統(tǒng)的SOA Governance包含四部分內(nèi)容:1.服務(wù)建模:驗(yàn)證功能需求與業(yè)務(wù)需求,發(fā)現(xiàn)和評(píng)估當(dāng)前服務(wù),服務(wù)建模和性能需求,開(kāi)發(fā)治理規(guī)劃。2.服務(wù)組裝:創(chuàng)建服務(wù)更新計(jì)劃,創(chuàng)建和修改服務(wù)以滿(mǎn)足所有業(yè)務(wù)需求,根據(jù)治理策略評(píng)估服務(wù),批準(zhǔn)組裝完成。3.服務(wù)部署:確保服務(wù)的質(zhì)量,措施包括功能測(cè)試、性能測(cè)試和滿(mǎn)足度測(cè)試,批準(zhǔn)服務(wù)部署。4.服務(wù)管理:在整個(gè)生命周期內(nèi)管理和監(jiān)控服務(wù),跟蹤服務(wù)注冊(cè)表中的服務(wù),根據(jù)服務(wù)質(zhì)量等級(jí)協(xié)議(SLA)上報(bào)服務(wù)的性能KPI數(shù)據(jù)進(jìn)行服務(wù)質(zhì)量管理。

SOA Governance 工作原理圖如下所示:


傳統(tǒng)SOA Governance的主要缺點(diǎn)如下:1.分布式服務(wù)框架的發(fā)展,內(nèi)部服務(wù)框架需要統(tǒng)一,服務(wù)治理也需要適應(yīng)新的架構(gòu),能夠由表及里,對(duì)服務(wù)進(jìn)行細(xì)粒度的管控。2.微服務(wù)架構(gòu)的發(fā)展和業(yè)務(wù)規(guī)模的擴(kuò)大,導(dǎo)致服務(wù)規(guī)模量變引起質(zhì)變,服務(wù)治理的特點(diǎn)和難點(diǎn)也隨之發(fā)生變化。3.缺少服務(wù)運(yùn)行時(shí)動(dòng)態(tài)治理能力,面對(duì)突發(fā)的流量高峰和業(yè)務(wù)沖擊,傳統(tǒng)的服務(wù)治理在響應(yīng)速度、故障快速恢復(fù)等方面存在不足,無(wú)法更敏捷應(yīng)對(duì)業(yè)務(wù)需求。

第二代分布式服務(wù)框架服務(wù)治理

分布式服務(wù)框架的服務(wù)治理定位:面向互聯(lián)網(wǎng)業(yè)務(wù)的服務(wù)治理,聚焦在對(duì)內(nèi)部采用統(tǒng)一服務(wù)框架服務(wù)化的業(yè)務(wù)運(yùn)行態(tài)、細(xì)粒度的敏捷治理體系。

治理的對(duì)象:基于統(tǒng)一分布式服務(wù)框架開(kāi)發(fā)的業(yè)務(wù)服務(wù),與協(xié)議本身無(wú)關(guān),治理的可以是SOA服務(wù),也可以是基于內(nèi)部服務(wù)框架私有協(xié)議開(kāi)發(fā)的各種服務(wù)。

治理策略:針對(duì)互聯(lián)網(wǎng)業(yè)務(wù)的特點(diǎn),例如突發(fā)的流量高峰、網(wǎng)絡(luò)延時(shí)、機(jī)房故障等,重點(diǎn)針對(duì)大規(guī)??鐧C(jī)房的海量服務(wù)進(jìn)行運(yùn)行態(tài)治理,保障線(xiàn)上服務(wù)的高SLA,滿(mǎn)足用戶(hù)的體驗(yàn)。常用的治理策略包括服務(wù)的限流降級(jí)、服務(wù)遷入遷出、服務(wù)動(dòng)態(tài)路由和灰度發(fā)布等。

分布式服務(wù)框架典型的服務(wù)治理體系如下所示:


第三代云端微服務(wù)治理

隨著云計(jì)算的發(fā)展,Dev&Ops逐漸流行起來(lái),基礎(chǔ)設(shè)施服務(wù)化(IaaS)為大規(guī)模、批量流水線(xiàn)式軟件交付提供了便利,AWS做為全球最大的云計(jì)算解決方案提供商,在微服務(wù)云化開(kāi)發(fā)和治理方面積累了非常多的經(jīng)驗(yàn),具體總結(jié)如下

  1. 全公司統(tǒng)一服務(wù)化開(kāi)發(fā)環(huán)境,統(tǒng)一簡(jiǎn)單化服務(wù)框架(Coral Service),統(tǒng)一運(yùn)行平臺(tái),快速高效服務(wù)開(kāi)發(fā);

  2. 所有后端應(yīng)用服務(wù)化,系統(tǒng)由多項(xiàng)服務(wù)化組件構(gòu)成。

  3. 服務(wù)共享、原子化、重用。

  4. 服務(wù)由小研發(fā)團(tuán)隊(duì)(2 Pizza Team)負(fù)責(zé)服務(wù)開(kāi)發(fā)、測(cè)試、部署和治理,運(yùn)維整個(gè)生命周期支撐。

  5. 高度自動(dòng)化和Dev&Ops支持,一鍵式服務(wù)部署和回退。

  6. 超大規(guī)模支持:后臺(tái)幾十萬(wàn)個(gè)服務(wù),成千上萬(wàn)開(kāi)發(fā)者同時(shí)使用,平均每秒鐘有1-2個(gè)服務(wù)部署。

  7. 嘗試基于Docker容器部署微服務(wù)。

8.服務(wù)治理是核心:服務(wù)性能KPI統(tǒng)計(jì)、告警、服務(wù)健康度管理、靈活的彈性伸縮策略、故障自動(dòng)遷移、服務(wù)限流和服務(wù)降級(jí)等多種治理手段,保障服務(wù)高質(zhì)量運(yùn)行。

云端微服務(wù)治理架構(gòu)設(shè)計(jì)

云端微服務(wù)治理架構(gòu)設(shè)計(jì)的目標(biāo)如下:

  1. 防止業(yè)務(wù)服務(wù)架構(gòu)腐化:通過(guò)服務(wù)注冊(cè)中心對(duì)服務(wù)強(qiáng)弱依賴(lài)進(jìn)行分析,結(jié)合運(yùn)行時(shí)服務(wù)調(diào)用鏈關(guān)系分析,梳理不合理的依賴(lài)和調(diào)用路徑,優(yōu)化服務(wù)化架構(gòu),防止代碼腐化。

  2. 快速故障定界定位:通過(guò)Flume等分布式日志采集框架,實(shí)時(shí)收集服務(wù)調(diào)用鏈日志、服務(wù)性能KPI數(shù)據(jù)、服務(wù)接口日志、運(yùn)行日志等,實(shí)時(shí)匯總和在線(xiàn)分析,集中存儲(chǔ)和展示,實(shí)現(xiàn)故障的自動(dòng)發(fā)現(xiàn)、自動(dòng)分析和在線(xiàn)條件檢索,方便運(yùn)維人員、研發(fā)人員進(jìn)行實(shí)時(shí)故障診斷。

  3. 服務(wù)微管控:細(xì)粒度的運(yùn)行期服務(wù)治理,包括限流降級(jí)、服務(wù)遷入遷出、服務(wù)超時(shí)控制、智能路由、統(tǒng)一配置、優(yōu)先級(jí)調(diào)度和流量遷移等,提供方法級(jí)治理和動(dòng)態(tài)生效功能,通過(guò)一系列細(xì)粒度的治理策略,在故障發(fā)生時(shí)可以多管齊下,在線(xiàn)調(diào)整,快速恢復(fù)業(yè)務(wù)。

  4. 服務(wù)生命周期管理:包括服務(wù)的上線(xiàn)審批、下線(xiàn)通知,服務(wù)的在線(xiàn)升級(jí),以及線(xiàn)上和線(xiàn)下服務(wù)文檔庫(kù)的建設(shè)。

  5. 靈活的資源調(diào)度:基于Docker容器,可以實(shí)現(xiàn)微服務(wù)的獨(dú)立部署和細(xì)粒度的資源隔離?;谠贫说膹椥陨炜s,可以實(shí)現(xiàn)微服務(wù)級(jí)別的按需伸縮和故障隔離。

云端微服務(wù)治理架構(gòu)設(shè)計(jì)云端微服務(wù)治理從架構(gòu)上可以分為三層:


  • 第一層:微服務(wù)治理展示層,它的實(shí)現(xiàn)為微服務(wù)治理Portal,主要面向系統(tǒng)運(yùn)維人員或者治理人員,提供在線(xiàn)、配置化的治理界面。

  • 第二層:微服務(wù)治理SDK,向服務(wù)治理提供治理元數(shù)據(jù)、治理接口、以及客戶(hù)端的治理類(lèi)庫(kù)。

  • 第三層:微服務(wù)治理服務(wù)實(shí)現(xiàn)層,微服務(wù)治理服務(wù),通過(guò)服務(wù)注冊(cè)中心,刷新服務(wù)治理屬性,同時(shí)通知服務(wù)提供者和消費(fèi)者集群各節(jié)點(diǎn)刷新內(nèi)存,使服務(wù)治理Portal下發(fā)的服務(wù)治理策略動(dòng)態(tài)生效。

1.  微服務(wù)治理Portal

微服務(wù)治理Portal是微服務(wù)治理的門(mén)戶(hù),它提供服務(wù)治理操作界面,供系統(tǒng)運(yùn)維人員或者測(cè)試人員對(duì)線(xiàn)上運(yùn)行的微服務(wù)進(jìn)行動(dòng)態(tài)治理,以保障服務(wù)的SLA。

Portal框架可以基于AngularJS等Web框架進(jìn)行開(kāi)發(fā),它的門(mén)戶(hù)界面如下所示:可以支持同時(shí)配置多個(gè)服務(wù)注冊(cè)中心集群,對(duì)不同的微服務(wù)集群進(jìn)行治理。


選擇某個(gè)微服務(wù)集群之后,就可以對(duì)該集群的微服務(wù)進(jìn)行治理,界面示例如下:


點(diǎn)擊查看,可以查看微服務(wù)的狀態(tài),以及各種性能指標(biāo)。點(diǎn)擊治理,彈出選擇菜單,可以對(duì)選擇的微服務(wù)進(jìn)行相關(guān)的治理操作。

2.  微服務(wù)治理SDK

服務(wù)治理SDK層,它主要由如下幾部分組成:

  1. 服務(wù)治理元數(shù)據(jù):服務(wù)治理元數(shù)據(jù)主要包括服務(wù)治理實(shí)體對(duì)象,包括服務(wù)模型、應(yīng)用模型、治理組織模型、用戶(hù)權(quán)限模型、數(shù)據(jù)展示模型等。元數(shù)據(jù)模型通過(guò)Data Mapper和模型擴(kuò)展,向上層界面屏蔽底層服務(wù)框架的數(shù)據(jù)模型,實(shí)現(xiàn)展示層和服務(wù)框架的解耦,元數(shù)據(jù)也可以用于展示界面的定制擴(kuò)展;

  2. 服務(wù)治理接口:服務(wù)治理Portal調(diào)用服務(wù)治理接口,實(shí)現(xiàn)服務(wù)治理。例如服務(wù)降級(jí)接口、服務(wù)流控接口、服務(wù)路由權(quán)重調(diào)整接口、服務(wù)遷移接口等。服務(wù)接口與具體的協(xié)議無(wú)關(guān),它通?;诜植际椒?wù)框架自身實(shí)現(xiàn),可以是Restful接口,也可以是內(nèi)部的私有協(xié)議;

  3. 服務(wù)治理客戶(hù)端類(lèi)庫(kù):由于服務(wù)治理服務(wù)本身通常也是基于分布式服務(wù)框架開(kāi)發(fā),因此服務(wù)治理Portal需要集成分布式服務(wù)框架的客戶(hù)端類(lèi)庫(kù),實(shí)現(xiàn)服務(wù)的自動(dòng)發(fā)現(xiàn)和調(diào)用;

  4. 調(diào)用示例:客戶(hù)端SDK需要提供服務(wù)治理接口的參數(shù)說(shuō)明、注意事項(xiàng)以及給出常用的調(diào)用示例,方便前端開(kāi)發(fā)人員使用;

  5. 集成開(kāi)發(fā)指南:服務(wù)治理SDK需要提供集成開(kāi)發(fā)指南,指導(dǎo)使用者如何在開(kāi)發(fā)環(huán)境中搭建、集成和使用服務(wù)治理SDK。

3.  線(xiàn)上服務(wù)治理

線(xiàn)上服務(wù)治理包含多種策略,例如:流量控制、服務(wù)降級(jí)、優(yōu)先級(jí)調(diào)度等。微服務(wù)啟動(dòng)的時(shí)候,將XML或者注解的服務(wù)提供者或者消費(fèi)者屬性注冊(cè)到服務(wù)注冊(cè)中心,由運(yùn)維人員通過(guò)服務(wù)治理Portal進(jìn)行在線(xiàn)修改,注冊(cè)中心通知服務(wù)提供者和消費(fèi)者刷新內(nèi)存,動(dòng)態(tài)生效。

下面就這幾種典型的治理策略進(jìn)行說(shuō)明。

第一、流量控制

當(dāng)資源成為瓶頸時(shí),服務(wù)框架需要對(duì)消費(fèi)者做限流,啟動(dòng)流控保護(hù)機(jī)制。流量控制有多種策略,比較常用的有:針對(duì)訪(fǎng)問(wèn)速率的靜態(tài)流控、針對(duì)資源占用的動(dòng)態(tài)流控、針對(duì)消費(fèi)者并發(fā)連接數(shù)的連接控制和針對(duì)并行訪(fǎng)問(wèn)數(shù)的并發(fā)控制。

  • 靜態(tài)流控主要針對(duì)客戶(hù)端訪(fǎng)問(wèn)速率進(jìn)行控制,它通常根據(jù)服務(wù)質(zhì)量等級(jí)協(xié)定(SLA)中約定的QPS做全局流量控制,例如訂單服務(wù)的靜態(tài)流控閾值為100 QPS,則無(wú)論集群有多少個(gè)訂單服務(wù)實(shí)例,它們總的處理速率之和不能超過(guò)100 QPS。

  • 動(dòng)態(tài)流控:它的最終目標(biāo)是為了保命,并不是對(duì)流量或者訪(fǎng)問(wèn)速度做精確控制。當(dāng)系統(tǒng)負(fù)載壓力非常大時(shí),系統(tǒng)進(jìn)入過(guò)負(fù)載狀態(tài),可能是CPU、內(nèi)存資源已經(jīng)過(guò)載,也可能是應(yīng)用進(jìn)程內(nèi)部的資源幾乎耗盡,如果繼續(xù)全量處理業(yè)務(wù),可能會(huì)導(dǎo)致長(zhǎng)時(shí)間的Full GC、消息嚴(yán)重積壓或者應(yīng)用進(jìn)程宕機(jī),最終將壓力轉(zhuǎn)移到集群其它節(jié)點(diǎn),引起級(jí)聯(lián)故障。觸發(fā)動(dòng)態(tài)流控的因子是資源,資源又分為系統(tǒng)資源和應(yīng)用資源兩大類(lèi),根據(jù)不同的資源負(fù)載情況,動(dòng)態(tài)流控又分為多個(gè)級(jí)別,每個(gè)級(jí)別流控系數(shù)都不同,也就是被拒絕掉的消息比例不同。每個(gè)級(jí)別都有相應(yīng)的流控閾值,這個(gè)閾值通常支持在線(xiàn)動(dòng)態(tài)調(diào)整。

  • 并發(fā)控制:針對(duì)線(xiàn)程的并發(fā)執(zhí)行數(shù)進(jìn)行控制,它的本質(zhì)是限制對(duì)某個(gè)服務(wù)或者服務(wù)的方法過(guò)度消費(fèi),耗用過(guò)多的資源而影響其它服務(wù)的正常運(yùn)行。并發(fā)控制有兩種形式:針對(duì)服務(wù)提供者的全局控制和針對(duì)服務(wù)消費(fèi)者的局部控制。

  • 連接控制:通常分布式服務(wù)框架服務(wù)提供者和消費(fèi)者之間采用長(zhǎng)連接私有協(xié)議,為了防止因?yàn)橄M(fèi)者連接數(shù)過(guò)多導(dǎo)致服務(wù)端負(fù)載壓力過(guò)大,系統(tǒng)需要支持針對(duì)連接數(shù)進(jìn)行流控。

4.  服務(wù)降級(jí)

大促或者業(yè)務(wù)高峰時(shí),為了保證核心服務(wù)的SLA,往往需要停掉一些不太重要的業(yè)務(wù),例如商品評(píng)論、論壇或者粉絲積分等。

另外一種場(chǎng)景就是某些服務(wù)因?yàn)槟撤N原因不可用,但是流程不能直接失敗,需要本地Mock服務(wù)端實(shí)現(xiàn),做流程放通。以圖書(shū)閱讀為例,如果用戶(hù)登錄余額鑒權(quán)服務(wù)不能正常工作,需要做業(yè)務(wù)放通,記錄消費(fèi)話(huà)單,允許用戶(hù)繼續(xù)閱讀,而不是返回失敗。

通過(guò)服務(wù)治理的服務(wù)降級(jí)功能,即可以滿(mǎn)足上述兩種場(chǎng)景的需求。服務(wù)降級(jí)主要包括屏蔽降級(jí)和容錯(cuò)降級(jí)兩種策略:

  • 屏蔽降級(jí)當(dāng)外界的觸發(fā)條件達(dá)到某個(gè)臨界值時(shí),由運(yùn)維人員/開(kāi)發(fā)人員決策,對(duì)某類(lèi)或者某個(gè)服務(wù)進(jìn)行強(qiáng)制降級(jí)。

它的處理流程如下所示:


第1步:運(yùn)維人員以管理員身份登錄服務(wù)治理控制臺(tái),管理員具備服務(wù)治理的全套權(quán)限。

第2步:運(yùn)維人員選擇服務(wù)降級(jí)菜單,在服務(wù)降級(jí)界面中選擇屏蔽降級(jí)。

第3步:通過(guò)服務(wù)查詢(xún)界面選擇需要降級(jí)的服務(wù),注意服務(wù)的分組和版本信息,指定具體的降級(jí)策略:返回null、返回指定異常還是執(zhí)行本地Mock接口實(shí)現(xiàn)。第4步:服務(wù)治理Portal通過(guò)服務(wù)注冊(cè)中心客戶(hù)端SDK,將屏蔽降級(jí)指令和相關(guān)信息發(fā)送到服務(wù)注冊(cè)中心。

第5、6步:服務(wù)注冊(cè)中心接收到屏蔽降級(jí)消息后,以事件的形式下分別群發(fā)給服務(wù)提供者集群和服務(wù)消費(fèi)者集群。

第7步:服務(wù)消費(fèi)者接收到屏蔽降級(jí)事件通知之后,獲取相關(guān)內(nèi)容,更新本地緩存的服務(wù)訂閱信息。當(dāng)發(fā)起遠(yuǎn)程服務(wù)調(diào)用時(shí),需要與屏蔽降級(jí)策略做匹配,如果匹配成功,則執(zhí)行屏蔽降級(jí)邏輯,不發(fā)起遠(yuǎn)程服務(wù)調(diào)用。

第8步:服務(wù)提供者集群接收到屏蔽降級(jí)事件通知之后,獲取相關(guān)內(nèi)容,更新本地的服務(wù)發(fā)布緩存信息,將對(duì)應(yīng)的服務(wù)降級(jí)屬性修改為屏蔽降級(jí)。

第9步:操作成功之后,服務(wù)注冊(cè)中心返回降級(jí)成功的應(yīng)答消息,由服務(wù)治理Portal界面展示。

第10步:運(yùn)維人員查詢(xún)服務(wù)提供者列表,查看服務(wù)狀態(tài)。

第11步:服務(wù)注冊(cè)中心返回服務(wù)狀態(tài)為屏蔽降級(jí)狀態(tài)。

  • 容錯(cuò)降級(jí):當(dāng)非核心服務(wù)不可用時(shí),可以對(duì)故障服務(wù)做業(yè)務(wù)邏輯放通,以保障核心服務(wù)的運(yùn)行。容錯(cuò)降級(jí)的工作原理如下所示:


5.  服務(wù)優(yōu)先級(jí)調(diào)度

當(dāng)系統(tǒng)當(dāng)前資源非常有限時(shí),為了保證高優(yōu)先級(jí)的服務(wù)能夠正常運(yùn)行,保障服務(wù)SLA,需要降低一些非核心服務(wù)的調(diào)度頻次,釋放部分資源占用,保障系統(tǒng)的整體運(yùn)行平穩(wěn)。

服務(wù)在發(fā)布的時(shí)候,可以指定服務(wù)的優(yōu)先級(jí),如果用戶(hù)沒(méi)有指定,采用默認(rèn)優(yōu)先級(jí)策略,它的配置如下所示:


服務(wù)的優(yōu)先級(jí)可以采用傳統(tǒng)的低、中、高三級(jí)配置策略,每個(gè)級(jí)別的執(zhí)行比例可以靈活配置,如下所示:


服務(wù)發(fā)布通過(guò)擴(kuò)展priority屬性的方式指定優(yōu)先級(jí),服務(wù)提供者將優(yōu)先級(jí)屬性注冊(cè)到服務(wù)注冊(cè)中心并通知消費(fèi)者,由消費(fèi)者緩存服務(wù)的優(yōu)先級(jí),根據(jù)不同的優(yōu)先級(jí)策略進(jìn)行調(diào)度。服務(wù)治理Portal通過(guò)動(dòng)態(tài)修改注冊(cè)中心指定服務(wù)priority屬性的方式,實(shí)現(xiàn)運(yùn)行態(tài)動(dòng)態(tài)調(diào)整微服務(wù)的優(yōu)先級(jí)。

總結(jié)除了上面介紹的幾種常用線(xiàn)上治理策略,比較重要的微服務(wù)治理策略還包括:

微服務(wù)超時(shí)控制:由于微服務(wù)調(diào)用通常使用RPC方式,是同步阻塞的,因此需要設(shè)置服務(wù)調(diào)用超時(shí)時(shí)間,防止對(duì)端長(zhǎng)時(shí)間不響應(yīng)導(dǎo)致的應(yīng)用線(xiàn)程掛死。超時(shí)控制支持在服務(wù)端或者消費(fèi)端配置,需要支持方法級(jí)超時(shí)控制。

微服務(wù)路由策略:負(fù)載均衡策略是服務(wù)治理的重要特性,分布式服務(wù)框架通常會(huì)提供多種負(fù)載均衡策略,同時(shí)支持用戶(hù)擴(kuò)展負(fù)載均衡策略。常用的路由策略包括:

  1. 隨機(jī):采用隨機(jī)算法進(jìn)行負(fù)載均衡,通常在對(duì)等集群組網(wǎng)中,隨機(jī)路由算法消息分發(fā)還是比較均勻的。

  2. 輪循:按公約后的權(quán)重設(shè)置輪循比率,到達(dá)邊界之后,繼續(xù)繞接。

  3. 服務(wù)調(diào)用時(shí)延:消費(fèi)者緩存所有服務(wù)提供者的服務(wù)調(diào)用時(shí)延,周期性的計(jì)算服務(wù)調(diào)用平均時(shí)延,然后計(jì)算每個(gè)服務(wù)提供者服務(wù)調(diào)用時(shí)延與平均時(shí)延的差值,根據(jù)差值大小動(dòng)態(tài)調(diào)整權(quán)重,保證服務(wù)時(shí)延大的服務(wù)提供者接收更少的消息,防止消息堆積。

  4. 一致性Hash:相同參數(shù)的請(qǐng)求總是發(fā)到同一個(gè)服務(wù)提供者,當(dāng)某一臺(tái)提供者宕機(jī)時(shí),原本發(fā)往該提供者的請(qǐng)求,基于虛擬節(jié)點(diǎn),平攤到其它提供者,不會(huì)引起劇烈變動(dòng)。

  5. 粘滯連接:粘滯連接用于有狀態(tài)服務(wù),盡可能讓客戶(hù)端總是向同一提供者發(fā)起服務(wù)調(diào)用,除非該提供者宕機(jī),再連接另一臺(tái)。

集群容錯(cuò)策略:消費(fèi)者根據(jù)配置的路由策略選擇某個(gè)目標(biāo)地址之后,發(fā)起遠(yuǎn)程服務(wù)調(diào)用,在此期間如果發(fā)生了遠(yuǎn)程服務(wù)調(diào)用異常,則需要服務(wù)框架進(jìn)行集群容錯(cuò),重新進(jìn)行選路和調(diào)用。集群容錯(cuò)是系統(tǒng)自動(dòng)執(zhí)行的,上層用戶(hù)并不需要關(guān)心底層的服務(wù)調(diào)用過(guò)程。集群容錯(cuò)和路由策略的關(guān)系如下所示:


常用的集群容錯(cuò)策略如下:

  1. Failover策略:服務(wù)調(diào)用失敗自動(dòng)切換策略指的是當(dāng)發(fā)生RPC調(diào)用異常時(shí),重新選路,查找下一個(gè)可用的服務(wù)提供者。通??梢耘渲檬∏袚Q的最大次數(shù)和間隔周期,以防止E2E服務(wù)調(diào)用時(shí)延過(guò)大。

  2. Failback策略:在很多業(yè)務(wù)場(chǎng)景中,消費(fèi)者需要能夠獲取到服務(wù)調(diào)用失敗的具體信息,通過(guò)對(duì)失敗錯(cuò)誤碼等異常信息的判斷,決定后續(xù)的執(zhí)行策略,例如非冪等性的服務(wù)調(diào)用。

  3. Failcache策略:Failcache策略是失敗自動(dòng)恢復(fù)的一種,在實(shí)際項(xiàng)目中它的應(yīng)用場(chǎng)景如下:- 服務(wù)有狀態(tài)路由,必須定點(diǎn)發(fā)送到指定的服務(wù)提供者。當(dāng)發(fā)生鏈路中斷、流控等服務(wù)暫時(shí)不可用時(shí),服務(wù)框架將消息臨時(shí)緩存起來(lái),等待周期T,重新發(fā)送,直到服務(wù)提供者能夠正常處理該消息。- 對(duì)時(shí)延要求不敏感的服務(wù)。系統(tǒng)服務(wù)調(diào)用失敗,通常是鏈路暫時(shí)不可用、服務(wù)流控、GC掛住服務(wù)提供者進(jìn)程等,這種失敗不是永久性的失敗,它的恢復(fù)是可預(yù)期的。如果消費(fèi)者對(duì)服務(wù)調(diào)用時(shí)延不敏感,可以考慮采用自動(dòng)恢復(fù)模式,即先緩存,再等待,最后重試。-通知類(lèi)服務(wù)。例如通知粉絲積分增長(zhǎng)、記錄接口日志等,對(duì)服務(wù)調(diào)用的實(shí)時(shí)性要求不高,可以容忍自動(dòng)恢復(fù)帶來(lái)的時(shí)延增加。

  4. Failfast策略:在業(yè)務(wù)高峰期,對(duì)于一些非核心的服務(wù),希望只調(diào)用一次,失敗也不再重試,為重要的核心服務(wù)節(jié)約寶貴的運(yùn)行資源。此時(shí),快速失敗是個(gè)不錯(cuò)的選擇。

服務(wù)灰度發(fā)布:灰度發(fā)布是指在黑與白之間,能夠平滑過(guò)渡的一種發(fā)布方式。AB test就是一種灰度發(fā)布方式,讓一部用戶(hù)繼續(xù)用A,一部分用戶(hù)開(kāi)始用B,如果用戶(hù)對(duì)B沒(méi)有什么反對(duì)意見(jiàn),那么逐步擴(kuò)大范圍,把所有用戶(hù)都遷移到B上面來(lái)。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定,在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問(wèn)題,以保證其影響度。

基于微服務(wù)的多版本管理機(jī)制   灰度路由策略,即可實(shí)現(xiàn)基于業(yè)務(wù)規(guī)則的灰度發(fā)布。

多版本管理:服務(wù)上線(xiàn)之后,隨著業(yè)務(wù)的發(fā)展,需要對(duì)功能進(jìn)行變更,或者修復(fù)線(xiàn)上的BUG,服務(wù)升級(jí)之后,往往需要對(duì)服務(wù)做多版本管理。服務(wù)多版本管理是分布式服務(wù)框架的重要特性,它涉及到服務(wù)的開(kāi)發(fā)、部署、在線(xiàn)升級(jí)和服務(wù)治理。

調(diào)用分組管理:可以對(duì)服務(wù)按照業(yè)務(wù)領(lǐng)域、部署的DC信息、服務(wù)提供商等角度對(duì)微服務(wù)進(jìn)行群組化管理,同群組之間的微服務(wù)可以自由調(diào)用,跨群組的微服務(wù)需要進(jìn)行審批和授權(quán),以實(shí)現(xiàn)不同分組之間的微服務(wù)隔離。不同分組之間可以有同名同接口的微服務(wù)的不同實(shí)現(xiàn),分組信息也是服務(wù)路由的一個(gè)因子。

全在線(xiàn)服務(wù)文檔

相對(duì)于平臺(tái)產(chǎn)品,業(yè)務(wù)服務(wù)的升級(jí)和修改非常頻繁,傳統(tǒng)依靠Java DOC進(jìn)行接口說(shuō)明和傳遞的方式,往往會(huì)因?yàn)槿狈ξ臋n建設(shè)或API DOC沒(méi)有及時(shí)刷新,導(dǎo)致消費(fèi)者拿到的接口定義說(shuō)明不準(zhǔn)確。相比于沒(méi)有文檔,拿到過(guò)時(shí)、錯(cuò)誤的API DOC文檔對(duì)使用者的危害更大。

為了解決這個(gè)問(wèn)題,需要建立服務(wù)文檔中心,方便線(xiàn)上運(yùn)維人員查看和多團(tuán)隊(duì)之間的協(xié)作,它的工作原理如下:


可以基于Swagger UI,構(gòu)建微服務(wù)在線(xiàn)文檔庫(kù),如下所示:


可以參考如下鏈接:https://github.com/swagger-api/swagger-ui

服務(wù)上線(xiàn)審批下線(xiàn)通知機(jī)制

當(dāng)團(tuán)隊(duì)規(guī)模擴(kuò)大之后,會(huì)劃分成平臺(tái)基線(xiàn)組、業(yè)務(wù)定制組等不同研發(fā)團(tuán)隊(duì),一些團(tuán)隊(duì)甚至跨多地協(xié)同開(kāi)發(fā)和運(yùn)維。服務(wù)的上線(xiàn)和下線(xiàn)必須要嚴(yán)格管控起來(lái),一旦不合格的服務(wù)上線(xiàn)并被消費(fèi)者消息,再想下線(xiàn)就非常困難了。

對(duì)于需要下線(xiàn)的服務(wù)管控也很重要,有些服務(wù)雖然調(diào)用頻次不高,業(yè)務(wù)量也不大。但是如果貿(mào)然下線(xiàn),很有可能導(dǎo)致依賴(lài)它的消費(fèi)者業(yè)務(wù)調(diào)用失敗,這會(huì)違反服務(wù)的SLA協(xié)定,給服務(wù)提供商造成損失。

服務(wù)的上線(xiàn)審批、下線(xiàn)通知機(jī)制需要建立完善起來(lái),它的工作原理如下所示:


除了以上介紹的常用服務(wù)治理措施,線(xiàn)下服務(wù)治理還包括:1.業(yè)務(wù)的梳理、服務(wù)劃分原則和方法論;2.服務(wù)跨團(tuán)隊(duì)協(xié)作流程、準(zhǔn)則、工具和方法論;3.服務(wù)的接口兼容性原則和規(guī)范;4.其它...線(xiàn)下服務(wù)治理依團(tuán)隊(duì)和業(yè)務(wù)不同,需求也不同,需要業(yè)務(wù)團(tuán)隊(duì)和服務(wù)框架團(tuán)隊(duì)長(zhǎng)期梳理、實(shí)踐和優(yōu)化,才能夠提升線(xiàn)下服務(wù)治理的效率,它的建設(shè)是個(gè)長(zhǎng)期過(guò)程,并非一蹴而就。

云端自治理

微服務(wù)彈性伸縮

基于PaaS云化平臺(tái)或者Docker容器服務(wù),可以實(shí)現(xiàn)基于負(fù)載的微服務(wù)彈性伸縮。

基于PaaS平臺(tái)部署微服務(wù)架構(gòu)示例如下:


基于Docker容器部署微服務(wù)示例如下:


基于云的動(dòng)態(tài)資源調(diào)度,可以實(shí)現(xiàn)微服務(wù)的彈性伸縮:基于CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)帶寬等資源占用率的彈性伸縮策略。當(dāng)VM或者容器的資源占用達(dá)到設(shè)置的閾值之后,自動(dòng)執(zhí)行擴(kuò)容策略,動(dòng)態(tài)創(chuàng)建微服務(wù)的運(yùn)行環(huán)境,部署并運(yùn)行新的微服務(wù)實(shí)例。基于業(yè)務(wù)指標(biāo)的彈性伸縮策略。例如微服務(wù)的平均時(shí)延、吞吐量、成功率等。通過(guò)對(duì)微服務(wù)的性能指標(biāo)進(jìn)行分布式采集、匯總和計(jì)算,判斷業(yè)務(wù)指標(biāo)是否達(dá)到伸縮閾值,如果達(dá)到,則自動(dòng)觸發(fā)微服務(wù)的伸縮流程,執(zhí)行彈性伸縮。用戶(hù)自定義的彈性伸縮策略??梢詫?duì)基于資源占用率的伸縮策略和基于業(yè)務(wù)指標(biāo)的伸縮策略做組合,實(shí)現(xiàn)更復(fù)雜的彈性伸縮?;谠破脚_(tái)的微服務(wù)彈性伸縮流程如下所示:


E2E微服務(wù)生命周期管理

利用云平臺(tái)對(duì)資源的動(dòng)態(tài)編排和調(diào)度,可以實(shí)現(xiàn)基礎(chǔ)設(shè)施自動(dòng)化。利用ALM(應(yīng)用生命周期管理)可以實(shí)現(xiàn)微服務(wù)的E2E生命周期管理。

基于Docker容器的微服務(wù)基礎(chǔ)設(shè)施自動(dòng)化流程如下所示:


微服務(wù)上線(xiàn)運(yùn)行之后,利用云平臺(tái)的ALM服務(wù),可以對(duì)微服務(wù)進(jìn)行上下線(xiàn)、升級(jí)、回滾等生命周期管理操作:


基于云平臺(tái)提供的微服務(wù)生命周期管理服務(wù),可以實(shí)現(xiàn)海量微服務(wù)的高效部署、升級(jí)和管理,而不需要關(guān)心物理基礎(chǔ)設(shè)施的環(huán)境準(zhǔn)備和安裝,以及資源規(guī)劃等,極大的提升了微服務(wù)的上線(xiàn)運(yùn)行效率,降低了微服務(wù)的管理成本。

微服務(wù)治理全景圖


微服務(wù)治理涵蓋的范圍非常廣,很多治理手段也需要業(yè)務(wù)在實(shí)際開(kāi)發(fā)中積累和沉淀,并沒(méi)有統(tǒng)一的標(biāo)準(zhǔn),這就是實(shí)施微服務(wù)治理的困難之處。

在微服務(wù)治理發(fā)展的同時(shí),云化和容器化革命也正在進(jìn)行,結(jié)合云平臺(tái)的敏捷性和彈性資源調(diào)度,微服務(wù)治理將逐步由人工治理向自動(dòng)化治理演進(jìn)。

微服務(wù)治理總體結(jié)構(gòu)圖如下所示:


Q&A

Q1:請(qǐng)問(wèn)在實(shí)際使用時(shí),前端網(wǎng)關(guān)有什么來(lái)源框架,還有分布式跟蹤系統(tǒng),有推薦嗎?

A1: 前端網(wǎng)關(guān),開(kāi)源的有WSO2,基于Java語(yǔ)言的,GO語(yǔ)言的有Tyk。

Q2:能展開(kāi)講一下優(yōu)先級(jí)調(diào)度么

A1:分布式跟蹤系統(tǒng)打印 埋點(diǎn)日志比較簡(jiǎn)單,但是復(fù)雜的是后端的大數(shù)據(jù)分析。采集可以基于FLume等,后端的分析可以基于HBase   Spark

Q3:請(qǐng)教一下,對(duì)應(yīng)用層擴(kuò)容很容易,很多時(shí)候一個(gè)服務(wù)慢了,根本原因是依賴(lài)的存儲(chǔ)  數(shù)據(jù)庫(kù)  外部接口的原因,這個(gè)時(shí)候?qū)?yīng)用層擴(kuò)容解決不了問(wèn)題,paas的擴(kuò)容還有什么意義呢?數(shù)據(jù)庫(kù)擴(kuò)容  涉及數(shù)據(jù)遷移,應(yīng)用層連接池更新等等  paas不能簡(jiǎn)單擴(kuò)容

A3:PaaS層的擴(kuò)容通常會(huì)有幾種策略:

1、基于資源使用率的擴(kuò)容;

2、基于服務(wù)性能指標(biāo)的擴(kuò)容;

3、混合模式;

4、業(yè)務(wù)自定義擴(kuò)容策略,這種場(chǎng)景通常是級(jí)聯(lián)擴(kuò)容,也就是應(yīng)用依賴(lài)的服務(wù)也需要同時(shí)做擴(kuò)容,例如緩存、MQ等。但是,不是所有的PaaS都支持策略4。

Q4:怎樣從傳統(tǒng)的系統(tǒng)轉(zhuǎn)化到云服務(wù)上,在系統(tǒng)設(shè)計(jì)及技術(shù)架構(gòu)有什么需要注意點(diǎn)。

A4: 不知道你講的傳統(tǒng)系統(tǒng)是不是指的非云系統(tǒng)。非云應(yīng)用轉(zhuǎn)到云化服務(wù)有幾點(diǎn)設(shè)計(jì)考慮:1、服務(wù)化;2、利用云的動(dòng)態(tài)性,例如彈性伸縮等;3、統(tǒng)一配置,使用云化的統(tǒng)一配置服務(wù)。

Q5:那mq 緩存 數(shù)據(jù)庫(kù)的client都要改造  支持后端自動(dòng)發(fā)現(xiàn)了,好多中間價(jià)的client都是配置死的,有可分享的開(kāi)源實(shí)現(xiàn)么

A5:包括前端的URL地址,MQ服務(wù)端的URL等,云化之后,MQ等服務(wù)也是一種云化服務(wù),例如AWS的S3服務(wù)。在我們的實(shí)踐中,原來(lái)的本地配置都統(tǒng)一放到了配置服務(wù)上,它是基于ZK的云化統(tǒng)一配置服務(wù),地址都是從注冊(cè)中心讀取的,而不是本地配置。這樣,就可以支持動(dòng)態(tài)發(fā)現(xiàn)。

Q6:應(yīng)用服務(wù)化后,涉及服務(wù)與服務(wù)之間的遠(yuǎn)程rpc,請(qǐng)問(wèn)數(shù)據(jù)傳輸過(guò)程中一般采用哪種系列化方式,之間的優(yōu)缺點(diǎn)都有哪些?還有場(chǎng)景

A6:幾種場(chǎng)景考量:1、如果服務(wù)看中的是標(biāo)準(zhǔn)化、開(kāi)放性,對(duì)性能要求不是特別苛刻。則建議采用 Restful   JSON的方式;2、如果是內(nèi)部各模塊之間的服務(wù)化調(diào)用,對(duì)性能、時(shí)延要求非常高,則建議采用二進(jìn)制   私有協(xié)議的方式,例如可以參考或者選擇ProtocolBuf、Thrift等。通常而言,服務(wù)跟協(xié)議是解耦的,也就是說(shuō)某個(gè)服務(wù),可以同時(shí)發(fā)布成多種協(xié)議。

    本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間,所有內(nèi)容均由用戶(hù)發(fā)布,不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評(píng)論

    發(fā)表

    請(qǐng)遵守用戶(hù) 評(píng)論公約

    類(lèi)似文章 更多