實施微服務我們需要哪些基礎框架

實施微效勞，我們需要哪些根底框架？微效勞(MicroServices)架構是當前互聯(lián)網(wǎng)業(yè)界的一個技術熱點，圈里有不少同行朋友當前有方案在各自公司開展微效勞化體系建設，他們都有相同的疑問：一個微效勞架構有哪些技術關注點(technicalconcerns)？需要哪些根底框架或組件來支持微效勞架構？這些框架或組件該如何選型？筆者之前在兩家大型互聯(lián)網(wǎng)公司參與和主導過大型效勞化體系和框架建設，同時在這塊也投入了很多時間去學習和研究，有一些經(jīng)驗和學習心得，可以和大家一起分享。效勞注冊、發(fā)現(xiàn)、負載均衡和健康檢查和單塊(Monolithic)架構不同，微效勞架構是由一系列職責單一的細粒度效勞構成的分布式網(wǎng)狀結構，效勞之間通過輕量機制進行通信，這時候必然引入一個效勞注冊發(fā)現(xiàn)問題，也就是說效勞提供方要注冊通告效勞地址，效勞的調用方要能發(fā)現(xiàn)目標效勞，同時效勞提供方一般以集群方式提供效勞，也就引入了負載均衡和健康檢查問題。根據(jù)負載均衡LB所在位置的不同，目前主要的效勞注冊、發(fā)現(xiàn)和負載均衡方案有三種：第一種是集中式LB方案，如下列圖Fig1，在效勞消費者和效勞提供者之間有一個獨立的LB，LB通常是專門的硬件設備如F5，或者基于軟件如LVS，HAproxy等實現(xiàn)。LB上有所有效勞的地址映射表，通常由運維配置注冊，當效勞消費方調用某個目標效勞時，它向LB發(fā)起請求，由LB以某種策略〔比方Round-Robin〕做負載均衡后將請求轉發(fā)到目標效勞。LB一般具備健康檢查能力，能自動摘除不健康的效勞實例。效勞消費方如何發(fā)現(xiàn)LB呢？通常的做法是通過DNS，運維人員為效勞配置一個DNS域名，這個域名指向LB。Fig1,集中式LB方案集中式LB方案實現(xiàn)簡單，在LB上也容易做集中式的訪問控制，這一方案目前還是業(yè)界主流。集中式LB的主要問題是單點問題，所有效勞調用流量都經(jīng)過LB，當效勞數(shù)量和調用量大的時候，LB容易成為瓶頸，且一旦LB發(fā)生故障對整個系統(tǒng)的影響是災難性的。另外，LB在效勞消費方和效勞提供方之間增加了一跳(hop)，有一定性能開銷。相關廠商內容百度APS深度剖析手淘如何從無到有的HybridApp框架創(chuàng)立歷程。萬人在線直播教室如何搭建？公司高速開展，研發(fā)團隊如何調優(yōu)支付寶紅包瞬時支付量挑戰(zhàn)雙十一零點峰值！相關贊助商全球架構師峰會，12月18-19日，北京·國際會議中心，精彩內容邀您參與！第二種是進程內LB方案，針對集中式LB的缺乏，進程內LB方案將LB的功能以庫的形式集成到效勞消費方進程里頭，該方案也被稱為軟負載(SoftLoadBalancing)或者客戶端負載方案，下列圖Fig2展示了這種方案的工作原理。這一方案需要一個效勞注冊表(ServiceRegistry)配合支持效勞自注冊和自發(fā)現(xiàn)，效勞提供方啟動時，首先將效勞地址注冊到效勞注冊表〔同時定期報心跳到效勞注冊表以說明效勞的存活狀態(tài)，相當于健康檢查〕，效勞消費方要訪問某個效勞時，它通過內置的LB組件向效勞注冊表查詢〔同時緩存并定期刷新〕目標效勞地址列表，然后以某種負載均衡策略選擇一個目標效勞地址，最后向目標效勞發(fā)起請求。這一方案對效勞注冊表的可用性(Availability)要求很高，一般采用能滿足高可用分布式一致的組件〔例如Zookeeper,Consul,Etcd等〕來實現(xiàn)。Fig2,進程內LB方案進程內LB方案是一種分布式方案，LB和效勞發(fā)現(xiàn)能力被分散到每一個效勞消費者的進程內部，同時效勞消費方和效勞提供方之間是直接調用，沒有額外開銷，性能比擬好。但是，該方案以客戶庫(ClientLibrary)的方式集成到效勞調用方進程里頭，如果企業(yè)內有多種不同的語言棧，就要配合開發(fā)多種不同的客戶端，有一定的研發(fā)和維護本錢。另外，一旦客戶端跟隨效勞調用方發(fā)布到生產環(huán)境中，后續(xù)如果要對客戶庫進行升級，勢必要求效勞調用方修改代碼并重新發(fā)布，所以該方案的升級推廣有不小的阻力。進程內LB的案例是Netflix的開源效勞框架，對應的組件分別是：Eureka效勞注冊表，Karyon效勞端框架支持效勞自注冊和健康檢查，Ribbon客戶端框架支持效勞自發(fā)現(xiàn)和軟路由。另外，阿里開源的效勞框架Dubbo也是采用類似機制。第三種是主機獨立LB進程方案，該方案是針對第二種方案的缺乏而提出的一種折中方案，原理和第二種方案根本類似，不同之處是，他將LB和效勞發(fā)現(xiàn)功能從進程內移出來，變成主機上的一個獨立進程，主機上的一個或者多個效勞要訪問目標效勞時，他們都通過同一主機上的獨立LB進程做效勞發(fā)現(xiàn)和負載均衡，見下列圖Fig3。Fig3主機獨立LB進程方案該方案也是一種分布式方案，沒有單點問題，一個LB進程掛了只影響該主機上的效勞調用方，效勞調用方和LB之間是進程內調用，性能好，同時，該方案還簡化了效勞調用方，不需要為不同語言開發(fā)客戶庫，LB的升級不需要效勞調用方改代碼。該方案的缺乏是部署較復雜，環(huán)節(jié)多，出錯調試排查問題不方便。該方案的典型案例是Airbnb的SmartStack效勞發(fā)現(xiàn)框架，對應組件分別是：Zookeeper作為效勞注冊表，Nerve獨立進程負責效勞注冊和健康檢查，Synapse/HAproxy獨立進程負責效勞發(fā)現(xiàn)和負載均衡。Google最新推出的基于容器的PaaS平臺Kubernetes，其內部效勞發(fā)現(xiàn)采用類似的機制。效勞前端路由微效勞除了內部相互之間調用和通信之外，最終要以某種方式暴露出去，才能讓外界系統(tǒng)〔例如客戶的瀏覽器、移動設備等等〕訪問到，這就涉及效勞的前端路由，對應的組件是效勞網(wǎng)關(ServiceGateway)，見圖Fig4，網(wǎng)關是連接企業(yè)內部和外部系統(tǒng)的一道門，有如下關鍵作用：效勞反向路由，網(wǎng)關要負責將外部請求反向路由到內部具體的微效勞，這樣雖然企業(yè)內部是復雜的分布式微效勞結構，但是外部系統(tǒng)從網(wǎng)關上看到的就像是一個統(tǒng)一的完整效勞，網(wǎng)關屏蔽了后臺效勞的復雜性，同時也屏蔽了后臺效勞的升級和變化。平安認證和防爬蟲，所有外部請求必須經(jīng)過網(wǎng)關，網(wǎng)關可以集中對訪問進行平安控制，比方用戶認證和授權，同時還可以分析訪問模式實現(xiàn)防爬蟲功能，網(wǎng)關是連接企業(yè)內外系統(tǒng)的平安之門。限流和容錯，在流量頂峰期，網(wǎng)關可以限制流量，保護后臺系統(tǒng)不被大流量沖垮，在內部系統(tǒng)出現(xiàn)故障時，網(wǎng)關可以集中做容錯，保持外部良好的用戶體驗。監(jiān)控，網(wǎng)關可以集中監(jiān)控訪問量，調用延遲，錯誤計數(shù)和訪問模式，為后端的性能優(yōu)化或者擴容提供數(shù)據(jù)支持。日志，網(wǎng)關可以收集所有的訪問日志，進入后臺系統(tǒng)做進一步分析。Fig4,效勞網(wǎng)關除以上根本能力外，網(wǎng)關還可以實現(xiàn)線上引流，線上壓測，線上調試(Surgicaldebugging)，金絲雀測試(CanaryTesting)，數(shù)據(jù)中心雙活(Active-ActiveHA)等高級功能。網(wǎng)關通常工作在7層，有一定的計算邏輯，一般以集群方式部署，前置LB進行負載均衡。開源的網(wǎng)關組件有Netflix的Zuul，特點是動態(tài)可熱部署的過濾器(filter)機制，其它如HAproxy，Nginx等都可以擴展作為網(wǎng)關使用。在介紹過效勞注冊表和網(wǎng)關等組件之后，我們可以通過一個簡化的微效勞架構圖(Fig5)來更加直觀地展示整個微效勞體系內的效勞注冊發(fā)現(xiàn)和路由機制，該圖假定采用進程內LB效勞發(fā)現(xiàn)和負載均衡機制。在下列圖Fig5的微效勞架構中，效勞簡化為兩層，后端通用效勞〔也稱中間層效勞MiddleTierService〕和前端效勞〔也稱邊緣效勞EdgeService，前端效勞的作用是對后端效勞做必要的聚合和裁剪后暴露給外部不同的設備，如PC，Pad或者Phone〕。后端效勞啟動時會將地址信息注冊到效勞注冊表，前端效勞通過查詢效勞注冊表就可以發(fā)現(xiàn)然后調用后端效勞；前端效勞啟動時也會將地址信息注冊到效勞注冊表，這樣網(wǎng)關通過查詢效勞注冊表就可以將請求路由到目標前端效勞，這樣整個微效勞體系的效勞自注冊自發(fā)現(xiàn)和軟路由就通過效勞注冊表和網(wǎng)關串聯(lián)起來了。如果以面向對象設計模式的視角來看，網(wǎng)關類似Proxy代理或者Fa?ade門面模式，而效勞注冊表和效勞自注冊自發(fā)現(xiàn)類似IoC依賴注入模式，微效勞可以理解為基于網(wǎng)關代理和注冊表IoC構建的分布式系統(tǒng)。Fig5,簡化的微效勞架構圖效勞容錯當企業(yè)微效勞化以后，效勞之間會有錯綜復雜的依賴關系，例如，一個前端請求一般會依賴于多個后端效勞，技術上稱為1->N扇出(見圖Fig6)。在實際生產環(huán)境中，效勞往往不是百分百可靠，效勞可能會出錯或者產生延遲，如果一個應用不能對其依賴的故障進行容錯和隔離，那么該應用本身就處在被拖垮的風險中。在一個高流量的網(wǎng)站中，某個單一后端一旦發(fā)生延遲，可能在數(shù)秒內導致所有應用資源(線程，隊列等)被耗盡，造成所謂的雪崩效應(CascadingFailure，見圖Fig7)，嚴重時可致整個網(wǎng)站癱瘓。Fig6,效勞依賴Fig7,頂峰期單個效勞延遲致雪崩效應經(jīng)過多年的探索和實踐，業(yè)界在分布式效勞容錯一塊探索出了一套有效的容錯模式和最正確實踐，主要包括：電路熔斷器模式(CircuitBreakerPatten),該模式的原理類似于家里的電路熔斷器，如果家里的電路發(fā)生短路，熔斷器能夠主動熔斷電路，以防止災難性損失。在分布式系統(tǒng)中應用電路熔斷器模式后，當目標效勞慢或者大量超時，調用方能夠主動熔斷，以防止效勞被進一步拖垮；如果情況又好轉了，電路又能自動恢復，這就是所謂的彈性容錯，系統(tǒng)有自恢復能力。下列圖Fig8是一個典型的具備彈性恢復能力的電路保護器狀態(tài)圖，正常狀態(tài)下，電路處于關閉狀態(tài)(Closed)，如果調用持續(xù)出錯或者超時，電路被翻開進入熔斷狀態(tài)(Open)，后續(xù)一段時間內的所有調用都會被拒絕(FailFast)，一段時間以后，保護器會嘗試進入半熔斷狀態(tài)(Half-Open)，允許少量請求進來嘗試，如果調用仍然失敗，那么回到熔斷狀態(tài)，如果調用成功，那么回到電路閉合狀態(tài)。Fig8,彈性電路保護狀態(tài)圖艙壁隔離模式(BulkheadIsolationPattern)，顧名思義，該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響。線程隔離(ThreadIsolation)就是艙壁隔離模式的一個例子，假定一個應用程序A調用了Svc1/Svc2/Svc3三個效勞，且部署A的容器一共有120個工作線程，采用線程隔離機制，可以給對Svc1/Svc2/Svc3的調用各分配40個線程，當Svc2慢了，給Svc2分配的40個線程因慢而阻塞并最終耗盡，線程隔離可以保證給Svc1/Svc3分配的80個線程可以不受影響，如果沒有這種隔離機制，當Svc2慢的時候，120個工作線程會很快全部被對Svc2的調用吃光，整個應用程序會全部慢下來。限流(RateLimiting/LoadShedder)，效勞總有容量限制，沒有限流機制的效勞很容易在突發(fā)流量(秒殺，雙十一)時被沖垮。限流通常指對效勞限定并發(fā)訪問量，比方單位時間只允許100個并發(fā)調用，對超過這個限制的請求要拒絕并回退?；赝?fallback)，在熔斷或者限流發(fā)生的時候，應用程序的后續(xù)處理邏輯是什么？回退是系統(tǒng)的彈性恢復能力，常見的處理策略有，直接拋出異常，也稱快速失敗(FailFast)，也可以返回空值或缺省值，還可以返回備份數(shù)據(jù)，如果主效勞熔斷了，可以從備份效勞獲取數(shù)據(jù)。Netflix將上述容錯模式和最正確實踐集成到一個稱為Hystrix的開源組件中，但凡需要容錯的依賴點(效勞，緩存，數(shù)據(jù)庫訪問等)，開發(fā)人員只需要將調用封裝在HystrixCommand里頭，那么相關調用就自動置于Hystrix的彈性容錯保護之下。Hystrix組件已經(jīng)在Netflix經(jīng)過多年運維驗證，是Netflix微效勞平臺穩(wěn)定性和彈性的基石，正逐漸被社區(qū)接受為標準容錯組件。效勞框架微效勞化以后，為了讓業(yè)務開發(fā)人員專注于業(yè)務邏輯實現(xiàn)，防止冗余和重復勞動，標準研發(fā)提升效率，必然要將一些公共關注點推到框架層面。效勞框架(Fig9)主要封裝公共關注點邏輯，包括：Fig9,效勞框架效勞注冊、發(fā)現(xiàn)、負載均衡和健康檢查，假定采用進程內LB方案，那么效勞自注冊一般統(tǒng)一做在效勞器端框架中，健康檢查邏輯由具體業(yè)務效勞定制，框架層提供調用健康檢查邏輯的機制，效勞發(fā)現(xiàn)和負載均衡那么集成在效勞客戶端框架中。監(jiān)控日志，框架一方面要記錄重要的框架層日志、metrics和調用鏈數(shù)據(jù)，還要將日志、metrics等接口暴露出來，讓業(yè)務層能根據(jù)需要記錄業(yè)務日志數(shù)據(jù)。在運行環(huán)境中，所有日志數(shù)據(jù)一般集中落地到企業(yè)后臺日志系統(tǒng)，做進一步分析和處理。REST/RPC和序列化，框架層要支持將業(yè)務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當前主流API暴露方式，在性能要求高的場合那么可采用Binary/RPC方式。針對當前多樣化的設備類型(瀏覽器、普通PC、無線設備等)，框架層要支持可定制的序列化機制，例如，對瀏覽器，框架支持輸出Ajax友好的JSON消息格式，而對無線設備上的NativeApp，框架支持輸出性能高的Binary消息格式。配置，除了支持普通配置文件方式的配置，框架層還可集成動態(tài)運行時配置，能夠在運行時針對不同環(huán)境動態(tài)調整效勞的參數(shù)和配置。限流和容錯，框架集成限流容錯組件，能夠在運行時自動限流和容錯，保護效勞，如果進一步和動態(tài)配置相結合，還可以實現(xiàn)動態(tài)限流和熔斷。管理接口，框架集成管理接口，一方面可以在線查看框架和效勞內部狀態(tài)，同時還可以動態(tài)調整內部狀態(tài)，對調試、監(jiān)控和管理能提供快速反應。SpringBoot微框架的Actuator模塊就是一個強大的管理接口。統(tǒng)一錯誤處理，對于框架層和效勞的內部異常，如果框架層能夠統(tǒng)一處理并記錄日志，對效勞監(jiān)控和快速問題定位有很大幫助。平安，平安和訪問控制邏輯可以在框架層統(tǒng)一進行封裝，可做成插件形式，具體業(yè)務效勞根據(jù)需要加載相關平安插件。文檔自動生成，文檔的書寫和同步一直是一個痛點，框架層如果能支持文檔的自動生成和同步，會給使用API的開發(fā)和測試人員帶來極大便利。Swagger是一種流行RestfulAPI的文檔方案。當前業(yè)界比擬成熟的微效勞框架有Netflix的Karyon/Ribbon，Spring的SpringBoot/Cloud，阿里的Dubbo等。運行期配置管理效勞一般有很多依賴配置，例如訪問數(shù)據(jù)庫有連接字符串配置，連接池大小和連接超時配置，這些配置在不同環(huán)境(開發(fā)/測試/生產)一般不同，比方生產環(huán)境需要配連接池，而開發(fā)測試環(huán)境可能不配，另外有些參數(shù)配置在運行期可能還要動態(tài)調整，例如，運行時根據(jù)流量狀況動態(tài)調整限流和熔斷閥值。目前比擬常見的做法是搭建一個運行時配置中心支持微效勞的動態(tài)配置，簡化架構如下列圖(Fig10):Fig10,效勞配置中心動態(tài)配置存放在集中的配置效勞器上，用戶通過管理界面配置和調整效勞配置，具體效勞通過定期拉(ScheduledPull)的方式或者效勞器推(Server-sidePush)的方式更新動態(tài)配置，拉方式比擬可靠，但會有延遲同