http://www.infoq.com/cn/articles/spring-cloud-based-service-governance

大家好，我是來自貝殼金控的趙文樂，目前主要從事架構(gòu)方面的工作。今天我想跟大家分享《基于 Spring Cloud 的服務治理實踐》。我先簡單向大家介紹一下服務治理的概念，然后介紹實際案例中的實踐。

服務治理的范圍及原因

上圖是我簡單制作的「服務治理實踐過程中遇到的問題和解決方法」，不是非常完全，但也可以代表服務治理的大致范圍。

服務治理的范圍

在服務治理方面，我們需要解決四個方面的問題：

服務質(zhì)量。包括：服務列表、服務性能KPI 、鏈路監(jiān)控、依賴監(jiān)控、故障管理與報警系統(tǒng)等；

線上治理，包括服務發(fā)現(xiàn)（讓客戶端能夠發(fā)現(xiàn)這個服務）、服務調(diào)度（包括客戶端和服務端的負載均衡、服務路由、升降級熔斷和監(jiān)控）和配置管理；

線下治理，包括開發(fā)工具、上線審批、下線通知、服務文檔；

運維生態(tài)。如容器云、用戶角色權(quán)限管理、服務的流程審批。

為什么要進行服務治理？

• 當服務越來越多時，過去簡單記錄服務的?end point就越來越復雜。所以注冊中心是我們需要做的第一步，在這之后，才是服務發(fā)現(xiàn)和客戶端定制；
• 當服務開始越來越復雜，我們就要依賴于管理服務。如果架構(gòu)師不了解系統(tǒng)里所有服務之間的依賴關(guān)系，則需要借助框架自動畫出依賴關(guān)系并予以管理；
• 當調(diào)用越來越多時，我們需要增加監(jiān)控、容量規(guī)劃以及度量；
• 當依賴變得復雜時，除了了解服務的依賴關(guān)系，還要動態(tài)的察覺依賴；
• 一般情況下，下層服務如果反調(diào)上層服務，會造成循環(huán)依賴，需要SOA做到服務之間互相溝通，使管理更加容易；
• 如果想要防止文檔變得混亂，就需要更集中化的文檔管理，讓大家能夠搜到、看到所有的服務的文檔；
• 如果大家都可以公開調(diào)用內(nèi)部服務，那么就會出現(xiàn)安全問題；
• 質(zhì)量問題也會難以保障，需要有非常好的服務監(jiān)控；
• 當調(diào)用多個服務時，需要做服務聚合。特別是當我們依賴于服務編排時，如果用框架來做會更方便。

服務拆分和治理的原則

服務拆分的原則

當我們在說微服務時，我們是在說：到底微服務的顆粒度要做到多細或多粗。這就需要我們先定義服務的不同分類，可以按照不同的維度來做。如服務業(yè)務、服務流程或不同的業(yè)務域，這是第一種流程服務，即滿足最高層服務的流程。在流程服務下還會出現(xiàn)組合服務，會調(diào)用多個其他服務進行封裝組合。再下面還會有平臺服務 —— 在某業(yè)務域下的核心服務。最后是基礎服務，它通常沒有特別的業(yè)務含義，是比較通用的服務。

同時，我們也可以根據(jù)服務的屬性來分類：

穩(wěn)定服務和不穩(wěn)定/?易變服務需要隔離；

核心服務和非核心服務需要隔離；

非功能服務和功能服務。非功能服務通常更容易復用，會把它放在最底層，由不同的服務來調(diào)用；

高可用服務和容錯服務。有些服務能容忍一定錯誤率，這樣的服務不能和高可用服務部署在一起。

所以，我們可以按照以上原則做系統(tǒng)分解：

• 不同的業(yè)務域劃分大的業(yè)務系統(tǒng)，每個業(yè)務調(diào)用數(shù)據(jù)量最大的需要拆分；
• 風險高、頻率高、經(jīng)常更新的需要拆分的；
• 經(jīng)常會被復用的底層服務需要拆分；
• 服務需要專業(yè)技能、專業(yè)團隊，特別是技術(shù)棧不統(tǒng)一時進行拆分。

服務設計原則

服務設計原因包括：

• 服務無狀態(tài)，冪等性。在設計微服務時，一般都會從領(lǐng)域模型。基于這些領(lǐng)域來驅(qū)動微服務REST API的設計；
• 服務業(yè)務隔離，領(lǐng)域驅(qū)動（ Domain Driven Design ）；
• 服務契約驅(qū)動（ Design by Contract ）。先定義接口，再去做服務的實現(xiàn)；
• 服務資源隔離（數(shù)據(jù)庫，線程池等）。如果不隔離服務的數(shù)據(jù)庫，就很難知道有沒有其他服務在調(diào)用我們的數(shù)據(jù)庫，至少數(shù)據(jù)庫的用戶是需要隔離，不同用戶要有不同的權(quán)限；
• 故障可隔離（熔斷機制）。Spring Cloud里有Hystrix框架就可以很好的解決這個問題。

服務治理原則包括：

• 服務SLA；
• 服務需自治；
• 服務可開關(guān)，降級，限流，動態(tài)調(diào)整負載路由；
• 服務可監(jiān)控，可統(tǒng)計，提供Metrics和Health Check（ Metrics Driven Design ）；
• 服務文檔和版本管理；
• 服務權(quán)限控制；
• 服務調(diào)用鏈可監(jiān)控。

Spring Cloud的服務治理

Spring Cloud 組件

上圖中比較核心的組建包括：

• 服務注冊提供很多選型。默認是Eureka，還支持Consul和Zookeeper服務注冊；
• 服務調(diào)用，REST API通常用Feign Client做服務調(diào)用，集成客戶端的負載均衡，所以Feign Client在服務治理中非常重要；
• 服務路由和服務過濾，在Spring Cloud提供的route API、gateway之類的工具；

其他還包括：

• 服務監(jiān)控，在?Spring Cloud環(huán)境下用的較多的是Hystrix —— 監(jiān)控控制臺，集成的Turbine可以做跨集群的監(jiān)控；
• 配置中心，Spring Cloud默認提供的配置管理是通過地址文件進行管理，也支持諸如Zookeeper之類配置中心；
• 安全控制集成SpringSecurity，它本身不是屬于Spring Cloud的范疇，但會提供SpringSecurity Starter，幫助我們快速的建立權(quán)限管理；
• 用?Spring Cloud Sleuth做分布式的鏈路監(jiān)控，集成Zipkin之類的框架。

Spring Cloud 存在的問題和痛點

配置管理。Spring Cloud的配置管理比較簡陋，沒有特別好的配置管理中心，也沒有共享配置。另外，Spring Cloud?配置不支持灰度；

網(wǎng)關(guān)（API Gateway）。網(wǎng)關(guān)需要做很多二次開發(fā)，沒有動態(tài)路由；同時，Zuul做不了服務編排，而在市場上也沒有一個很好的服務編排的框架；

服務跟蹤。Sleuth框架不成熟。如果跟一些比較成熟的APM框架相比，它是非常欠缺的；

UI。spring cloud?的UI界面非常分散，像Hystrix、eureka、tubine、zipkin都有自己的界面。但這些缺乏集中的管理，用戶體也普遍比較差、感覺比較簡單，跟商業(yè)級的服務治理平臺無法相比。

如何改善

更換配置中心。攜程的Apollo是一個更好的選擇。它里面的很多功能都是原生Spring Cloud配置中心不支持的。所以建議大家嘗試一下比較成熟的配置中心。

因為?API Gateway在Spring Cloud中沒有操作界面，所以我們就為之定制了專屬界面，讓它能夠管理不同的路由規(guī)則。我們還開發(fā)了一系列Filter，可以在API Gateway里做簽名檢查和解密。同時，我們還集成了自己的賬戶系統(tǒng)和單點登錄，支持不同的登錄方式。

除此之外，我們集成了用戶中心（ Accountservice ）。因為當?API Gateway開放給渠道用戶或合作伙伴用戶時，通常沒有交互，所以我們就需要通過參數(shù)的自動抓取匹配用戶，據(jù)此判斷這個用戶是否已經(jīng)注冊。如果還未注冊，我們就會自動注冊。同時，當一個潛在用戶使用我們系統(tǒng)、調(diào)用API時，我們就可以通過這種方式把硬件指紋記錄下來，后臺會給這些用戶打標簽，我們就可以針對這些用戶做push等營銷手段。

最后，還有一些前置Filter用于抽取數(shù)據(jù)。當API請求時，會異步通過日志抽取報文做數(shù)據(jù)清洗，通過ETL寫到數(shù)據(jù)倉庫里。

API gateway的動態(tài)路由

舉個例子，比如我們把年齡小于30歲的男性路由到一個不同的endpoint ，我們在這過程中會在請求頭、請求參數(shù)或請求頭中通過Json Parse抽取參數(shù)和數(shù)據(jù)轉(zhuǎn)換。我們可以從body里第一個customer對象的ID得到uid，之后保存到上下文中，輸出到output，當我們指定endpoint為另外一個URL時把UID這個參數(shù)傳過去。

還有一種是報文的轉(zhuǎn)換，即Payload Transformation。這個技術(shù)其實在很久以前就已經(jīng)存在了，在ESB、SOAP時代，我們通常會利用XML來做報文的轉(zhuǎn)換。所以現(xiàn)在通常用來做報文轉(zhuǎn)換的工具是Json、Json Paser、Velocity Template、FreeMarker等。還有一些協(xié)議的轉(zhuǎn)換，我們內(nèi)部有很多API都是基于dubbo或者是其他的一些RPC協(xié)議。所以當收到外部REST API請求時，我們會做一個協(xié)議、格式的轉(zhuǎn)換。

在上圖中，入?yún)⑹潜容^復雜的Json，我們通過Input Mapping模板上邏輯輸出變量，嵌入到另外的Json對象中。如果我們在內(nèi)部有一套比較標準的API，可以通過這種方式適配到外部不同的API。這樣便集成了規(guī)則引擎，可以做一些比較基本的服務編排。

一體化的服務監(jiān)控和跟蹤

在Spring Cloud里提供了很多不同的服務監(jiān)控工具，利用這些工具可以做服務的業(yè)務監(jiān)控和埋點，來收集各種Metrics。當我們發(fā)送消息時，我們會在適當?shù)牡胤阶雎顸c，收集數(shù)據(jù)，最后再把這些集成起來，做報表展示和告警。所以整個這套服務監(jiān)控和跟蹤都是一體化的。

我們在做中間件埋點時，可以有許多的選擇，比如JDK proxy、http client、Servlet filters、Spring MVC handler都可以添加埋點，但我們更多會在Feign Client提供一些攔截器，當服務調(diào)用時，會有一些不同的event。

在DB里，我們用的比較多的是Druid datasource filter，它提供了很多擴展，我們可以在這里邊做SQL查詢的埋點，記錄每條SQL的響應時間和調(diào)用頻次。同時，Mybatis也可以做埋點，定制一些插件。

服務監(jiān)控的整體架構(gòu)

過去我們使用日志做服務監(jiān)控的數(shù)據(jù)收集，大家都知道也有不少的服務監(jiān)控都是基于上報的API。但我們通過日志的方式收集數(shù)據(jù)對應用的性能比較友好，不會因為我們埋點影響到業(yè)務。同時，耦合度也比較低，只是分析度量數(shù)據(jù)。通過不同的Instruments寫到日志里。最后通過Logstash到Kafka進入ElasticSearch，基于這些查詢可以快速生成簡單的報表。

以上所說的內(nèi)容，如果都只是停留在框架級別，用戶和程序員根本看不到服務治理的概念。所以我們做了一套服務治理平臺，可以看到所有服務治理內(nèi)容。同時，我們還把配置中心嵌到了服務治理平臺中，將服務網(wǎng)關(guān)管理、Rabbit MQ消息隊列管理、通過消息隊列業(yè)務ID查詢消息軌跡以及一些項目管理相關(guān)的離線服務治理等功能集成在一起。

Q & A

問：下層服務和上層服務指的是什么？

答：所謂的下層服務，就是底下平臺級的服務。比如你有一個發(fā)短信的服務，如果這個服務跟你的賬戶體系耦合在一起，它就是反向調(diào)用，如果在短信服務里需要到會員中心獲取手機號，這就是不合理的設計，就是下層服務調(diào)上層服務的例子。

問：服務調(diào)用是每個服務各自寫一個FeignClient，還是由服務方提供統(tǒng)一的jar包？

答：我們現(xiàn)在做法是：在定義服務接口時，這個服務接口就是FeignClient，然后把服務接口和它領(lǐng)域的對象封裝成統(tǒng)一的jar包，作為服務方提供。之后，客戶端用它來調(diào)用就可以了。在調(diào)用過程中，框架里的攔截器會做埋點、注入及監(jiān)控的工作。

問：老的服務如何調(diào)用FeignClient？

答：用延伸注解來實現(xiàn)。FeignClient在Spring Cloud用的是比較新的OpenFeign注解，支持一些特殊功能。比如插入自己的http client和做很多攔截器，老的FeignClient不是很友好，而且它跟Spring mvc的注解也不一致，但是作為一個很老的服務，如果要調(diào)用FeignClient的話，我們通常會把所有FeignClient用到的class打成一個大的jar包，為這些老的服務實現(xiàn)調(diào)用。

問：如果有機會是不是直接選擇自研好一點？

答：作為開發(fā)人員或架構(gòu)師，每個人都想自研，確實也有很多團隊自己做自研框架。但自研的問題是從入門到融會貫通的時間。雖然Spring Cloud現(xiàn)在十分簡陋，但上手就可以用。如果在整個團隊里都用Spring Cloud，可以很快地做一些簡單的服務治理，然后再慢慢的優(yōu)化這個過程。還有一個原因，Spring Cloud在行業(yè)里的接受度比較高，大家的學習曲線比較短，通常自研的框架很多工程師可能不太接受或不太信任。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9274139.html

總結(jié)

以上是生活随笔為你收集整理的基于 Spring Cloud 的服务治理实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。