分布式服務架構解決方案V1.02016年4月北京天禾元創(chuàng)股份有限公司

目錄1 引言 51.1 編寫目的 51.2 服務化架構演進 52 架構設計 62.1 設計原則 62.2 架構原理 72.3 功能特性 82.4 性能特性 92.5 可靠性 92.6 服務治理 103 架構組成 113.1 架構圖 113.2 服務路由 133.2.1 透明化路由 133.2.2 負載均衡 133.2.3 本地優(yōu)先策略 143.2.4 路由規(guī)則 143.2.5 路由策略定制 143.2.6 配置化路由 143.3 注冊中心 153.3.1 特性設計 153.4 發(fā)布和引用 163.4.1 發(fā)布設計 163.4.2 引用設計 183.4.3 灰度發(fā)布 193.5 優(yōu)先級調度 193.6 服務治理 193.6.1 治理定位 203.6.2 治理對象 203.6.3 治理策略 203.6.4 治理目標 203.6.5 架構設計 213.6.6 運行態(tài)功能設計 223.6.7 線下治理 223.6.8 安全和權限管理 243.7 中間聚合層 244 微服務架構 254.1 帶來的變革 254.1.1 應用解耦 254.1.2 分而治之 264.1.3 敏捷交付 274.2 架構解析 275 集成ESB 286 提供的服務 286.1 用戶和組織機構 286.2 權限管理 286.3 單點登錄 286.4 通信服務 296.5 業(yè)務提醒 296.6 待辦工作 296.7 工作流服務 296.7.1 流程定義 306.7.2 流程測試 326.7.3 數據清理 326.7.4 流程審批 336.7.5 流程部署 336.7.6 流程升級/注銷 336.7.7 調用接口 33

引言編寫目的本文檔的編寫目的是為xxx煙草信息中心提供分布式服務架構的解決方案，隨著企業(yè)內部業(yè)務的發(fā)展和應用規(guī)模的不斷擴大，系統(tǒng)內部的應用越來越多，常規(guī)的垂直應用架構已經無法應對復雜業(yè)務帶來的各種挑戰(zhàn)。通過將業(yè)務公共能力抽象成原子服務，對復雜應用進行水平拆分和服務化，實現服務消費者和提供者的解耦。服務化架構演進傳統(tǒng)軟件的垂直架構改造的核心就是要對應用做服務化的改造，服務化改造使用到的核心技術架構就是分布式服務架構。服務化架構演進圖如下圖所示：圖SEQ圖\*ARABIC1服務化架構演化圖單一應用架構：當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節(jié)點和成本；此時，用于簡化增刪改查工作量的數據訪問框架(ORM)是關鍵。垂直應用架構：當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率；此時，用于加速前端頁面開發(fā)的Web框架(MVC)是關鍵。分布式服務架構：當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來，作為獨立的服務，逐漸形成穩(wěn)定的服務中心，使前端應用能更快速的響應多變的市場需求；此時，用于提高業(yè)務復用及整合的分布式服務框架(RPC)是關鍵。流動計算架構：當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率，此時，用于提高機器利用率的資源調度和治理中心(SOA)是關鍵。微服務架構：隨著云計算、移動互聯(lián)網、Docker容器等技術的快速發(fā)展和應用，微服務架構（MicroServiceArchitecture）這一全新的架構風格越來越受到大家的關注，也有越來越多的企業(yè)和平臺服務提供商在實踐中嘗試并使用它來解決具體業(yè)務問題，微服務架構的流行已經成為未來技術發(fā)展的趨勢之一。架構設計設計原則面向服務的架構設計原則主要包括如下內容。服務可復用：不管是否存在即時的復用機會，服務均被設計為支持潛在的可復用性。服務共享一個標準契約：為了與服務提供者交互，消費者需要導入服務提供者的服務契約，這個契約可以是一個IDL文件、Java接口定義、WSDL文件，甚至是一個接口文檔。服務是松耦合的：服務被設計為功能相對獨立、盡量不依賴其他服務的獨立提供者。服務是底層邏輯的抽象：只有經服務契約所暴露的服務對外部世界可見，契約之外底層的實現邏輯是不可見的。服務是可組合、可編排的：多個服務可能被編排組合成一個新的服務，這允許不同邏輯抽象的自由組合，促進服務的復用。服務是自治的：邏輯由服務所控制，并位于一個清晰的邊界內，服務已經在邊界內被控制，不依賴于其他服務。服務是無狀態(tài)的：服務應當不需要管理狀態(tài)信息，因此能夠維持松耦合性。服務應當被設計成無狀態(tài)，即便這意味著要將狀態(tài)管理移至他處。服務是可以被自動發(fā)現的：服務發(fā)布上線后，允許被其他消費者自動發(fā)現；當服務提供者下線后，允許消費者接收服務下線通知。架構原理分布式服務架構核心邏輯架構圖如下圖所示：圖SEQ圖\*ARABIC2分布式服務框架的邏輯架構圖 通常分布式服務架構可以抽線為三層：RPC層：包括底層通信框架（例如NIO框架的封裝、公有協(xié)議的封裝等）、序列化和發(fā)序列化框架、用于屏蔽底層通信協(xié)議細節(jié)和序列化方式的差異的Remoting框架。FilterChain層：服務調用職責鏈，提供多種服務調用切面供框架自身和使用者擴展，例如負載均衡、服務調用性能統(tǒng)計、服務調用完成通知機制、失敗重發(fā)等。Service層：主要包括Java動態(tài)代理，消費者使用，主要用于將服務提供者的接口封裝成遠程服務調用：Java反射，服務提供者使用，根據消費者請求消息中的接口名、方法名、參數列表反射調用服務者提供的接口本地實現。再向上就是業(yè)務的服務接口定義和實現類，對于使用spring配置化開發(fā)的就是SpringBean，服務由業(yè)務來實現，平臺負責將業(yè)務接口發(fā)布成遠程服務。功能特性分布式服務框架必須實現一些公共功能，這些公共功能見下表：表SEQ表\*ARABIC1功能特性特性名功能名說明服務訂閱發(fā)布配置化發(fā)布和引用服務支持通過XML配置的方式發(fā)布和導入服務，降低對業(yè)務代碼的侵入服務自動發(fā)現機制支持服務實現自動發(fā)現，由注冊中心推送服務地址，消費者不需要配置服務提供者的地址，服務地址透明化服務在線注冊和去注冊支持運行態(tài)注冊新服務，也支持運行態(tài)取消某個服務的注冊服務路由默認提供隨機路由、輪詢、基于權重的路由策略等默認提供常用的路由策略，避免每個框架使用者都重復開發(fā)粘滯鏈接總是向同一個提供方發(fā)起請求，除非此提供方掛掉，再切換到另外一臺路由定制支持用戶自定義路由策略，擴展平臺的功能集群容錯Failover失敗自動切換，當出現失敗，重試其他服務，通常用于讀操作，也可以用于冪等性的寫操作Failback失敗自動恢復，后臺記錄失敗請求，定時重發(fā)，通常用于消息通知操作Failfast快速失敗，只發(fā)起一次調用，失敗立即報錯，通常用于非冪等性的寫操作服務調用同步調用消費者發(fā)起服務調用之后，同步阻塞等待服務端響應異步調用消費者發(fā)起服務調用之后，不阻塞立即返回，由服務端返回應答后異步通知消費者并行調用消費者同時對多個服務提供者批量發(fā)起服務調用請求，批量發(fā)起請求后，集中等待應答多協(xié)議私有協(xié)議支持二進制等私有協(xié)議，支持私有協(xié)議定制和擴展公有協(xié)議提供WebService等公有協(xié)議，用于外部服務對接序列化方式二進制類序列化支持Thrigt、ProtocolBuffer等二進制協(xié)議，提升序列化性能文本類序列化支持JSON,XML等文本類型的序列化方式，提升通用性和可讀性統(tǒng)一配置本地靜態(tài)配置安裝部署修改一次，運行態(tài)不修改的配置可以本地配置文件中基于配置中心的動態(tài)配置運行態(tài)需要調整的參數，統(tǒng)一放到配置中心(服務注冊中心)，修改后統(tǒng)一下發(fā)，實時生效性能特性應用服務化以后，由原來的本地API調用變成跨進程的遠程調用，網絡通信、消息序列化和發(fā)序列化、發(fā)射調用和動態(tài)代理等都會導致性能損耗、時延增加。因此，分布式服務框架的性能指標非常重要，性能特性總結如表所示：表SEQ表\*ARABIC2性能特性線性特性說明高性能在同等資源占用的情況下，單服務提供者的TPS要盡量提高低時延在同等資源占用情況下，服務調用時延要盡量低性能線性增長擴展服務提供者，性能要能夠線性增長可靠性應用由單機調用演進到分布式部署之后，由于網絡故障、服務提供者故障等因素，會導致業(yè)務失敗率增加，分布式服務框架要具備很強的可靠性，來保證業(yè)務的成功率，可靠性總結如下表所示：表SEQ表\*ARABIC3可靠性特性名功能名說明服務注冊中心服務健康狀態(tài)檢測注冊中心通過心跳檢測服務提供者的存在，服務提供者宕機，注冊中心將立即推送事件通知消費者故障切換注冊中心對等集群，任意一臺宕機后，將自動切換到另一臺高HA注冊中心全部宕機后，服務提供者和服務消費者仍能通過本地緩存通信消除單點故障服務無狀態(tài)服務提供者無狀態(tài)，任意一臺宕機后，不影響使用服務集群容錯只要集群中有一臺機器的服務提供者可用，業(yè)務就不會中斷鏈路健壯性心跳檢測鏈路空閑時沒有業(yè)務消息，通過定時心跳檢測鏈路是否可用斷連重連機制鏈路段連之后，根據客戶端配置的重連策略定時重連，重連成功之前消息不會路由到段連的服務提供者上服務治理服務治理是分布式服務架構重要的特性，如下表所示：表SEQ表\*ARABIC4服務治理特性名功能名說明服務運行態(tài)管控服務路由業(yè)務高峰期，通過動態(tài)修改路由策略實現導流服務限流資源成為瓶頸時，服務端和消費者的動態(tài)流控服務遷入遷出實現資源動態(tài)分配服務降級服務提供者故障時或者業(yè)務高峰期，進行服務強制或者容錯降級，執(zhí)行本地降級邏輯，保證系統(tǒng)平穩(wěn)運行服務超時控制動態(tài)調整超時時間，在業(yè)務高峰期保證業(yè)務調用成功率服務監(jiān)控性能統(tǒng)計統(tǒng)計項包括服務調用時延、成功率、調用次數等統(tǒng)計報表提供多維度、實時和歷史數據報表，同比、環(huán)比等性能對比數據，供運維、運營等使用告警指標異常、根據告警策略發(fā)送告警，包括但不限于短信，E-mail、記錄日志等服務生命周期管理上線審批服務提供者不能隨意線上發(fā)布服務，需要通過正規(guī)的審批流程批準后才能上線下線通知服務提供者在下線某個服務之前一段時間，需要根據SLA策略，通知消費者服務灰度發(fā)布灰度環(huán)境劃分原則，接口前向兼容性策略，以及消費者如何路由，都需要灰度發(fā)布引擎負責管理故障快速定界定位分布式日志采集支持在大規(guī)模分布式環(huán)境中實時采集容器、中間件和應用的各種日志海量日志在線檢索支持分布式環(huán)境海量日志的在線檢索，支持多維度索引和模糊查詢調用鏈接可視化展示通過分布式消息跟蹤系統(tǒng)輸出調用鏈，可視化快速地進行故障定界運行日志故障定位通過調用鏈的故障關鍵字，在日志檢索界面快速檢索故障日志，用于故障的精確定位服務安全敏感服務的授權策略敏感服務如何授權，防止惡意調用鏈路的安全防護消費者和服務者之間的長連接，需要增加安全防護。例如基于Token的安全認證機制架構組成架構圖分布式服務架構的架構圖如下圖所示：圖SEQ圖\*ARABIC3分布式服務架構圖節(jié)點角色說明提供者：暴露服務的服務提供方。消費者：調用遠程服務的服務消費方。服務注冊中心：服務注冊與發(fā)現的注冊中心。服務監(jiān)控中心：統(tǒng)計服務的調用次調和調用時間的監(jiān)控中心。服務容器：服務運行容器。調用關系說明0.開始：服務容器負責啟動，加載，運行服務提供者。1.注冊：服務提供者在啟動時，向注冊中心注冊自己提供的服務。1.0.審核：管理員對服務提供者注冊的服務進行審核。2.訂閱：服務消費者在啟動時，向注冊中心訂閱自己所需的服務。3.通報：注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。4.調用：服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。5.統(tǒng)計：服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發(fā)送一次統(tǒng)計數據到監(jiān)控中心。服務路由分布式服務框架上線運行時都是集群組網，這意味著集群中存在某個服務的多實例部署，消費者如何從服務列表中選擇合適的服務提供者進行調用，這就涉及到服務路由。分布式服務框架要能夠滿足用戶靈活的路由需求。透明化路由很多開源的RPC框架調用者需要配置服務提供者的地址信息，盡管可以通過讀取數據庫的服務地址列表等方式避免硬編碼地址信息，但是消費者依然要感知服務提供者的地址信息，這就違反了透明化路由的原則。基于服務注冊中心的訂閱發(fā)布，在分布式服務框架中，服務注冊中心用于存儲服務提供者的地址信息、服務發(fā)布相關的屬性信息，消費者通過主動查詢和被動通知的方式獲取服務提供者的地址信息，而不需要像之前那樣在代碼中硬編碼服務提供者的地址信息。消費者只需要知道當前系統(tǒng)發(fā)布了哪些服務，而不需要知道服務具體存在什么位置，這就是透明化路由。消費者緩存服務提供者的地址，消費者調用服務提供者時，不需要每次調用都去服務注冊中心查詢服務提供者地址列表。消費者客戶端從本地緩存的服務提供者路由表中查詢地址信息，根據路由策略進行路由選擇。負載均衡負載均衡策略是服務重要的屬性，分布式服務框架通常會提供多種負載均衡的策略，同時支持用戶擴展負載均衡的策略。采用隨機算法進行負載均衡。輪循，按公約后的權重設置輪循比率。服務調用時延，消費者緩存所有服務提供者的服務調用時延，周期性的計算服務調用平均時延，然后計算每個服務提供者服務調用時延于平均時延的差值，根據差值大小動態(tài)調整權重。一致性哈希，相同參數的請求總是發(fā)到同一個服務提供者，當某臺提供者宕機時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點平攤到其他提供者，不會引起劇烈變動。粘滯鏈接，用于有狀態(tài)的服務，盡可能讓客戶端總是向同一臺提供者發(fā)起服務調用，除非該提供者宕機再連接另一臺。本地優(yōu)先策略在一些業(yè)務場景中，本地JVM內部也發(fā)布了需要消費的服務，優(yōu)先調用本JVM內部發(fā)布的服務提供者，這種模式成為injvm模式。如果物理機或者VM配置比較好，多個應用進程往往會選擇合設。服務消費者和服務提供者可能會被部署到同一臺機器上。服務路由時優(yōu)先選擇本機的服務提供者，如果找不到再重新發(fā)起遠程服務調用，該模式成為innative模式。路由規(guī)則負載均衡、本地路由優(yōu)先等路由通常可以滿足大部分業(yè)務的線上需求，但是在一些場景中需要對路由策略設置一些過濾條件，比較常用的是基于表達式的條件路由和腳本路由。路由策略定制平臺除了提供默認的路由策略之外，在架構上還需要支持業(yè)務擴展路由算法，實現業(yè)務定義路由。配置化路由路由配置的優(yōu)先級：客戶端配置>服務端配置>全局配置。配置策略的設計如下：本地配置：包括服務提供者和服務消費者、默認全局配置三種。統(tǒng)一注冊管理：無論是服務提供者還是消費者，本地配置的路由策略統(tǒng)一注冊到服務注冊中心，進行集中化配置管理。動態(tài)下發(fā)：運維人員通過服務治理Portal修改路由規(guī)則，更新后的路由規(guī)則被持久化到服務注冊中心。服務注冊中心將變更后的服務路由策略或者規(guī)則下發(fā)給服務提供者和消費者。注冊中心對于服務提供者，它需要發(fā)布服務；對于服務消費者，它最關心的如何獲取它所需要的服務。對于服務提供方和服務消費方來說，它們還有可能兼具這兩種角色。如何有效地管理服務訂閱/發(fā)布，避免硬編碼地址信息是分布式服務框架需要解決的問題之一。通過將服務統(tǒng)一管理起來，可以有效地優(yōu)化內部應用對服務發(fā)布/使用的流程和管理，服務注冊中心就是專門來管理服務訂閱/發(fā)布的配置管理節(jié)點。特性設計服務注冊中心的工作原理圖如下圖所示：圖SEQ圖\*ARABIC4注冊中心工作原理圖服務提供者在啟動時，根據服務發(fā)布文件中配置的服務發(fā)布信息向注冊中心注冊自己提供的服務。服務消費者在啟動時，根據消費者配置文件中配置的服務消費信息向注冊中心訂閱自己所需要的服務，消費者刷新本地緩存的路由表。注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心主動推送變更數據給消費者，消費者刷新本地緩存的路由表。服務消費者從本地緩存的服務提供者地址列表中，基于負載均衡算法選擇一臺服務器提供者進行調用。注冊中心的功能設計特性主要包括：對等集群：注冊中心某一個或者多個服務注冊中心進程宕機，不會導致服務注冊中心集群功能不可用。對于客戶端，無論服務注冊中心配置多少個進程，客戶端只需要連接其中一個即可。提供CRUD接口。安全加固：主要涉及鏈路的安全性和數據的安全性。訂閱發(fā)布機制?？煽啃浴０l(fā)布和引用服務提供者需要支持配置、注解、API調用等方式，把本地接口發(fā)布成遠程服務；對于消費者，可以通過對等的方式引用遠程服務提供者，實現服務的發(fā)布和引用。發(fā)布設計消費者導入服務提供者的接口API定義，配置服務引用信息，即可在代碼中直接調用遠程服務，流程設計如下圖所示：圖SEQ圖\*ARABIC5服務發(fā)布流程圖服務發(fā)布的方式：XML配置化的方式、注解、API調用，其中XML配置的方式具有很多優(yōu)點，服務框架對業(yè)務代碼零侵入、擴展和修改方便、修改配置不需要重新編譯代碼等。例如：<beanid=”echoService”class=”edu.neu.EchoServiceImpl”/><xxx:serviceinterface=”edu.neu.EchoService”ref=”echoService”/>。代理：本地實現封裝成代理，對于服務提供者將本地實現類封裝成代理對象不是必須的；也可以利用一系列工具類解析服務提供者信息，然后將服務提供者的地址信息注冊到服務注冊中心。發(fā)布成指定協(xié)議：根據服務配置的屬性信息，將服務發(fā)布成指定協(xié)議。需要指出的是，同一個服務允許發(fā)布成多種協(xié)議，例如：<beanid=”echoService”class=”edu.neu.EchoServiceImpl”/><xxx:serviceinterface=”edu.neu.EchoService”ref=”echoService”protocol=”HTTP,thrift”/>服務提供者信息注冊：將服務按照指定協(xié)議發(fā)布之后，需要將服務發(fā)布信息注冊到信息中心。初始化服務注冊中心客戶端SDK，根據配置的注冊中心地址連接注冊中心，將服務提供者進行注冊。引用設計消費者導入服務提供者的接口API定義，配置服務引用信息，即可在代碼中直接調用遠程服務，流程如下圖所示：圖SEQ圖\*ARABIC6服務引用流程圖本地接口調用轉換成遠程服務調用：消費者導入服務提供者的本地API之后，在配置文件中引用遠程服務提供者。例如：<xxx:referenceid=”echoService”interface=”edu.neu.EchoService”/><beanclass=”edu.neu.xxxAction”init-method=”start”><propertyname=”echoService”ref=”echoService”/></bean>服務地址本地緩存：消費者根據引用的服務名等信息，連接服務注冊中心，獲取已經發(fā)布的服務提供者地址等信息，緩存到本地的服務路由表中。服務路由的時候，直接從本地緩存的地址表中獲取服務的地址信息，按照指定的策略進行服務路由。遠程服務調用：消費者從本地緩存的服務列表中按照指定策略路由，將請求消息封裝成協(xié)議消息；調用相關協(xié)議的客戶端將請求發(fā)送給服務提供者，業(yè)務線程按照服務調用方式選擇同步等待或者注冊監(jiān)聽器回調。協(xié)議客戶端讀取到應答消息，將數據包解碼成協(xié)議應答消息；在根據序列化格式將消息體反序列化成POJO對象，喚醒業(yè)務等待的線程（或者回調注冊的監(jiān)聽器）；業(yè)務線程獲得服務調用結果返回。如果消費者調用超時，按照集群容錯策略執(zhí)行Failover、Failcache等重試策略，來保證服務調用成功?；叶劝l(fā)布灰度發(fā)布是指在黑于白之間，能夠平滑過渡的一種發(fā)布方式。ABtest就是一種灰度發(fā)布方式：讓一部分用戶繼續(xù)用A，一部分用戶開始用B；如果用戶對B沒有反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上來?；叶劝l(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現、調整問題，以保證其影響度。優(yōu)先級調度當系統(tǒng)資源非常有限時，為了保證高優(yōu)先級的服務能夠正常運行，保障服務SLA，需要降低一些非核心服務的調度頻次，釋放部分資源占用，保障系統(tǒng)的整體運行平穩(wěn)。支持服務發(fā)布時設置優(yōu)先級策略，并在資源成為瓶頸時按照用戶配置的優(yōu)先級策略調度執(zhí)行服務。服務治理隨著業(yè)務的發(fā)展，服務越來越多，如何協(xié)調線上運行的各個服務，保障服務的SLA（Service-Level-Agreement服務等級協(xié)議），對服務架構和運維人員。是一個很大的挑戰(zhàn)。線上業(yè)務發(fā)生故障時，需要對故障業(yè)務做服務降級流量控制、流量遷移等，快速恢復業(yè)務。為了規(guī)范服務的上線和下線，在服務發(fā)布前，需要走服務預發(fā)布流程，由架構師或者項目經理對需要上線的服務做發(fā)布審核，審核通過后才能上線。服務治理框架就是為了滿足用戶以上的需求，對服務進行有效管控，保障服務的高效、健康的運行。服務治理的體系圖如下圖所示：圖SEQ圖\*ARABIC7服務治理體系圖治理定位面向物聯(lián)網業(yè)務的服務治理，聚焦在對內采用統(tǒng)一服務框架服務化的業(yè)務運行態(tài)、細粒度的敏捷治理體系。治理對象基于統(tǒng)一分布式框架開發(fā)的業(yè)務服務，于協(xié)議本身無關，治理的可以是SOA服務，也可以是基于內部服務框架私有協(xié)議開發(fā)的各種服務。治理策略針對互聯(lián)網服務的特點，例如突發(fā)的流量高峰、網絡延時、機房故障等，重點對大規(guī)?？鐧C房的海量服務進行運行態(tài)的治理，保障線上服務的SLA，滿足用戶體驗。常用的治理策略包括服務的限流降級、服務遷入遷出、服務動態(tài)路由和灰度發(fā)布等。治理目標防止業(yè)務服務架構的腐化：通過服務注冊中心對服務強弱依賴進行分析，結合運行時服務調用鏈分析，梳理不合理的依賴和調用路徑，優(yōu)化服務框架，防止代碼腐化?？焖俟收隙ń缍ㄎ唬和ㄟ^分布式日志采集框架，實時收集服務調用鏈日志、服務性能KPI數據、服務接口日志等，實時匯總和在線分析，集中存儲和展示，實現故障的自動發(fā)現、自動分析和在線條件檢索，方便運維人員、研發(fā)人員進行實時故障診斷。服務微管控：細粒度的運行期服務治理，包括限流降級、服務遷入遷出、服務超時控制、智能路由、統(tǒng)一配置、優(yōu)先級調度和流量遷移等，提供方法級治理和動態(tài)生效功能，通過一些列細粒度的治理策略，在故障發(fā)生時可以多管齊下，在線調整，快速恢復業(yè)務。服務生命周期管理：包括服務的上線審批、下線通知，服務的在線升級，以及線上線下服務文檔庫的建設。架構設計服務治理是分布式服務框架的一個可選特性，盡管從服務開發(fā)和運行角度看它不是必需的，但如果沒有服務治理功能，分布式服務框架的服務SLA很難得到保障，服務化很難真正實施成功。分布式服務框架的服務治理的架構圖如下圖所示：圖SEQ圖\*ARABIC8服務治理邏輯架構圖第一層叫做服務治理展示層，它主要由服務治理Portal組成，提供可視化的界面，方便服務運維人員進行治理操作。第二層叫做服務治理SDK層，它主要包括服務治理元數據，服務治理實體對象，服務模型、應用模型、治理組織模型、用戶權限模型等；服務治理接口，服務治理Portal調用服務治理接口實現服務治理；服務治理客戶端類庫，服務治理Portal需要集成分布式服務框架的客戶端類庫，實現服務的自動發(fā)現和調用；調用示例，客戶端SDK需要提供服務治理接口的參數說明、注意事項以及給出常用的調用示例，方便前端開發(fā)人員使用；集成開發(fā)指南，指導使用者如何在開發(fā)環(huán)境中搭建、集成和使用服務治理SDK。第三層叫做后臺服務治理服務層，由一組服務治理服務組成，可以單獨部署，也可以與應用組合部署。考慮到健壯性，通常選擇獨立集群部署。運行態(tài)功能設計運行態(tài)服務治理首先要能夠做到可視，包括當前系統(tǒng)發(fā)布了哪些服務，這些服務部署在哪些機器上，性能KPI數據如何，指標是否正常等。除了告警，對服務健康狀態(tài)和關鍵指標的日常巡檢也非常重要。服務的發(fā)布情況和運行狀態(tài)是首先需要關注的。線下治理隨著服務化的推進，服務的開發(fā)者越來越多，服務之間的互相調用和依賴也日趨復雜，另外搭建一套線下的全量化境成本非常高。為了解決這個問題，需要建立服務文檔中心，方便線上運維人員查看和多團隊之間協(xié)作。它的工作原理如圖所示：圖SEQ圖\*ARABIC9服務治理邏輯架構圖 服務的上線審批、下線通知機制需要建立并完善起來，它的工作原理如下圖所示：圖SEQ圖\*ARABIC10服務上線審批、下線通知圖 除了以上常用的治理措施，線下服務治理還包括：業(yè)務的梳理、服務劃分原則和方法論。服務跨團隊協(xié)作流程、準則、工具和方法論。服務的接口兼容性原則和規(guī)范。安全和權限管理分布式服務框架的安全主要涉及到兩個層面，一個是服務的開放和鑒權機制；另一個是服務治理的安全和權限管理。服務治理框架需要提供角色和權限模型，用于用戶定義角色并進行授權，同時要提供賬號和角色關聯(lián)管理功能，方便對賬號進行授權。中間聚合層服務本身是零散化的東西，通常要接入的是中間層。實際上會在中間層做聚合，聚合層本身即可以做業(yè)務聚合，也可以做中間層的聚合，每一層的聚合都要做異步調用的設計。同時要對接口進行抽取，。這樣的話才能給應用使用。因為應用。本身是沒有服務發(fā)現的下，圖是以服務的方式聚合中間層的架構圖：圖SEQ圖\*ARABIC11以服務的方式聚合中間層架構圖微服務架構帶來的變革應用解耦服務化之前，一個大型的應用系統(tǒng)通常會包含很多個子應用，不同子應用存在很多重復的公共代碼，所有應用公用一套數據庫。架構圖如下圖所示：圖SEQ圖\*ARABIC12傳統(tǒng)應用架構圖微服務架構出現將功能服務化，應用作為消費者直接調用服務，這樣就實現了對原因重復代碼的收編，同時系統(tǒng)之間的調用關系也更加清晰。架構圖如下所示：圖SEQ圖\*ARABIC13傳統(tǒng)應用架構圖分而治之當垂直應用越來越多時，應用之間的交互不可避免，將核心業(yè)務抽取出來，作為獨立的服務，逐漸形成穩(wěn)定的底層微服務，使得前端應用能更快速的響應多變的市場需求。敏捷交付軟件解決方案的敏捷性，指的是它能夠快速進行變更的能力。敏捷性是微服務架構特性中最顯著的一點：敏捷性的產生，是將運行中的系統(tǒng)解耦為一些列功能單一服務的結果。微服務架構能夠對系統(tǒng)中其他部分的依賴加以限制，這種特性能夠讓基于微服務架構的應用在應對Bug或是對新特性需求時，能夠快速的進行變更。架構解析微服務架構是一種架構風格，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。傳統(tǒng)架構和微服務架構對比圖如下圖所示：圖SEQ圖\*ARABIC14傳統(tǒng)架構和微服務架構對比圖集成ESB企業(yè)服務總線（EnterpriseServiceBus，ESB）從面向服務體系架構發(fā)展而來，是傳統(tǒng)中間件技術與XML、Web服務等技術結合的產物。服務框架對ESB進行了集成。ESB提供了網絡中最基本的連接中樞，是構筑企業(yè)神經系統(tǒng)的必要元素。ESB采用了“總線”這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣為接受的開放標準為基礎來支持應用之間在消息、事件和服務級別上動態(tài)的互聯(lián)互通，是一種在松散耦合的服務和應用之間標準的集成方式。分布式服務框架雖然集成了ESB總線的功能，但是不作為框架服務的首選。因為ESB要求用戶手工注冊和管理服務，這樣增加用戶使用和維護成本。提供的服務用戶和組織機構分布式服務框架能夠提供統(tǒng)一的用戶和組織機構管理，通過建立一整套完成的、獨立基礎信息數據庫，框架可以對外提供用戶登錄服務。權限管理分布式服務框架能夠提供統(tǒng)一的角色權限管理，權限包括操作權限和數據權限。通過建立一整套完整的、獨立的角色、映射、模塊、操作、數據權限配置等基礎信息數據庫，框架可以對外提供權限服務。單點登錄分布式服務礦建能夠提供統(tǒng)一的單點登錄服務，用戶第一次登陸系統(tǒng)是，首先跳轉到框架的認證中心，認證中心根據用戶提供的登錄信息，認證系統(tǒng)進行身份校驗，如果通過校驗，應該返回給用戶一個認證的憑據－－ticket；用戶再訪問別的應用的時候，就會將這個ticket帶上，作為自己認證的憑據，應用系統(tǒng)接受到請求之后會把ticket送到認證系統(tǒng)進行校驗，檢查ticket的合法性。如果通過校驗，用戶就可以在不用再次登錄的情況下訪問應用系統(tǒng)2和應用系統(tǒng)3了。通信服務分布式服務框架能夠提供基本的通信服務，例如集成發(fā)送短信或者微信的功能。通過框架提供的統(tǒng)一短信配置Portal或者微信公共賬號，在某個業(yè)務工作節(jié)點給指定用戶發(fā)送短信或者微信信息。業(yè)務提醒分布式服務框架能夠提供業(yè)務提醒的功能，通過建立業(yè)務提醒數據表和發(fā)布統(tǒng)一的提醒服務，實現框架的業(yè)務提醒功能。各個業(yè)務應用的前臺頁面通過定時請求，來自動獲取該業(yè)務的提醒信息，顯示在前臺頁面中?；蛘卟捎冒l(fā)送短信、微信等方式提醒系統(tǒng)內的相關人員。待辦工作分布式服務框架能夠提供個人待辦工作處理的功能，通過建立待辦工作數據表和發(fā)布待辦工作服務，實現個人的待辦工作的處理功能。工作流服務首先用戶的業(yè)務流程梳理是一項非常繁重的工作，往往在信息系統(tǒng)應用之前用戶有一套完成的工作流程。在開展信息系統(tǒng)工作之后，又針對信息系統(tǒng)的特點對業(yè)務流程進行規(guī)范。不同的信息系統(tǒng)應用又存在不同的業(yè)務流程定義，這又增加了業(yè)務流程梳理的難度。因此在分布式服務框架產生之初，就應該對本單位系統(tǒng)的業(yè)務流程進行梳理和標準化。分布式服務框架提供了統(tǒng)一的業(yè)務流程調用服務，其工作步驟包括流程設計、流程測試、數據清理、流程部署和流程注銷等功能。流程定義分布式服務框架應提供可視化的流程設計界面，開發(fā)人員或者系統(tǒng)運維人員可以通過可視化的流程設計器進行業(yè)務流程設計。如下圖所示：圖SEQ圖\*ARABIC15流程設計圖 在流程設計頁面中設計人員可以采用鼠標拖拽的方式進行流程設計。生成的流程XML文件如下：<?xmlversion="1.0"encoding="GBK"?><workflowdump="true"xmlns:c="c"xmlns:wf="wf"xmlns:demo_wf="demo_wf"alwaysAssignOwner="true"><description>財務處子流程</description><config></config><actions><actionid="rejectStep"forReject="true"visible="false"><meta><argNames>rejectStepIds</argNames></meta></action><actionid="start"name="啟動財務流程"><t