微服務(wù)已經(jīng)成為過去幾年軟件架構(gòu)設(shè)計的“事實標準”，大多數(shù)企業(yè)在推動內(nèi)部數(shù)字化轉(zhuǎn)型的過程中，服務(wù)軟件系統(tǒng)開始由單一或者SOA服務(wù)向微服務(wù)轉(zhuǎn)型。那么轉(zhuǎn)型過程需要遵循哪些原則呢?本文結(jié)合過往博云微服務(wù)落地實踐經(jīng)驗，分享微服務(wù)落地實踐的過程中思考。

目前當(dāng)技術(shù)人員提及微服務(wù)的時候，首先想到的是Spring Cloud、Dubbo等實現(xiàn)服務(wù)的技術(shù)框架。這在我們采用微服務(wù)的初期階段是最先考慮的因素?？墒请S著服務(wù)化的進行，我們并沒有享受到由框架的便利性與快捷性所帶來的業(yè)務(wù)突飛猛進的成就感。恰恰相反，過多的服務(wù)化以及服務(wù)間冗余且多元化通信機制反而加重了業(yè)務(wù)處理的負擔(dān)。這必然不是我們想要的微服務(wù)，卻是大多數(shù)企業(yè)在執(zhí)行的微服務(wù)。

因此我們開始重新審視整個行業(yè)，審視微服務(wù)的發(fā)展歷程。與過往不同的是：前期階段，我們把更多的精力投入到業(yè)務(wù)上，而一定程度上“忽略”技術(shù)，因為此時我們建立的信念是無論何種形式的“服務(wù)形態(tài)”一定是為業(yè)務(wù)服務(wù)的。

當(dāng)我們站在全局的角度，觀看整理后的服務(wù)，發(fā)現(xiàn)了一個及其優(yōu)美的圖形化結(jié)構(gòu)，各個節(jié)點的邊界清晰，職責(zé)分明;節(jié)點間的鏈路暢通，協(xié)議規(guī)整。這時我們知道我們終于走在了正確的道路上。

我們遵循的原則

當(dāng)經(jīng)過一定時間的掙扎以后，我們覺得微服務(wù)的關(guān)注點不在于技術(shù)本身，但并不意味著不關(guān)注技術(shù)。在反思過程中，我們認為微服務(wù)實踐中有兩個原則不能變：服務(wù)一定是圍繞業(yè)務(wù)的，服務(wù)的交互是標準的。我們把原則分為兩個階段：初期階段，實踐階段。

初期階段

初期階段，遵循第一條原則，服務(wù)一定是圍繞業(yè)務(wù)的。微服務(wù)初期階段，重要的是業(yè)務(wù)梳理，而不是花費大量時間在RPC、Service Discovery、 Circuit Breaker這些概念或者Eureka，Docker，Gateway，Dubbo等技術(shù)框架的調(diào)研上，此時我們重心關(guān)注服務(wù)的邊界與職責(zé)劃分。

這是遵循的兩條原則：

• 保證單一業(yè)務(wù)服務(wù)高效聚合;
• 降低服務(wù)間的相互調(diào)用(此舉是避免陷入大量分布式業(yè)務(wù)的處理)。

這樣的原則下，DDD為我們提供了幫助，也依據(jù)業(yè)務(wù)本身的特性實現(xiàn)了服務(wù)初期階段的整理。同時我們發(fā)現(xiàn)就算借助DDD的指導(dǎo)，在不同的業(yè)務(wù)應(yīng)用中，各個服務(wù)也有不同的聚合形態(tài)和調(diào)用方式。因此我們覺得微服務(wù)本身沒有一成不變的模式，一切都是圍繞業(yè)務(wù)動態(tài)變化的。合理性也僅僅體現(xiàn)在一定階段的時間范圍之內(nèi)。

實踐階段

當(dāng)業(yè)務(wù)建模完成，我們能夠清晰的知道各個業(yè)務(wù)的職責(zé)以及與其他業(yè)務(wù)的關(guān)聯(lián)關(guān)系，從理論層面我們完成了業(yè)務(wù)微服務(wù)建模。此時我們開始著手服務(wù)的落地實踐，在落地實踐階段我們更多關(guān)注點同樣不在于技術(shù)框架，而是在于技術(shù)框架的內(nèi)涵-即服務(wù)交互標準。

此時我們遵循了第二條原則：服務(wù)的交互是標準的。所謂服務(wù)交互標準從三個層面解讀：協(xié)議標準，框架標準，接口標準。

協(xié)議標準

目前網(wǎng)絡(luò)應(yīng)用的協(xié)議比較復(fù)雜，我們希望選取能夠符合業(yè)務(wù)場景的協(xié)議作為通信標準。因此我們考慮了統(tǒng)一的認證鑒權(quán)協(xié)議、加密解密協(xié)議、內(nèi)部接口交互協(xié)議，外圍接口服務(wù)協(xié)議等，各個協(xié)議各司其職，用來支撐服務(wù)通信的標準化。協(xié)議標準不僅僅為平臺自身服務(wù)，同時與其他業(yè)務(wù)單元進行通信時，只需要遵循協(xié)議標準，就可以實現(xiàn)業(yè)務(wù)單元之間的快速聯(lián)動。

框架標準

為了支撐業(yè)務(wù)，我們沒有依賴任何的自動化代碼生成框架，而是根據(jù)我們的協(xié)議支持情況，選擇最小的服務(wù)運行框架，來構(gòu)建統(tǒng)一的業(yè)務(wù)單元支撐框架。這里需要說明的一點，框架標準需要考慮業(yè)務(wù)特性，協(xié)議特性，不能一概而論，因此它的有效性也許只在當(dāng)前構(gòu)建的業(yè)務(wù)平臺本身。構(gòu)建標準框架的好處是針對應(yīng)用內(nèi)的所有業(yè)務(wù)單元可以快速復(fù)制，簡化因為各自開發(fā)框架不同導(dǎo)致聯(lián)調(diào)階段出現(xiàn)問題。

接口標準

接口分兩種：業(yè)務(wù)內(nèi)部接口和業(yè)務(wù)服務(wù)接口。無論哪種接口同樣遵循標準化原則。

業(yè)務(wù)內(nèi)部接口的核心在于壓縮協(xié)議，加快業(yè)務(wù)的處理流程，因此可以采用RPC等高效率的協(xié)議支持的接口模式;業(yè)務(wù)服務(wù)接口的核心在于表明業(yè)務(wù)攜帶的信息，因此采用restful接口規(guī)范更合適一些。接口設(shè)計需要涵蓋但不限于標準化的請求方式、統(tǒng)一的參數(shù)處理、統(tǒng)一的結(jié)果返回、統(tǒng)一的異常處理、統(tǒng)一的日志處理等。

服務(wù)拆分與聚合

前提：服務(wù)拆分與聚合在本篇文章中暫時不考慮web的微服務(wù)化設(shè)計，只說明后端服務(wù)的拆分與聚合實踐。

服務(wù)拆分與聚合需要遵循的原則：服務(wù)一定是圍繞業(yè)務(wù)的。但事實情況是，在現(xiàn)在追求“開源整合”的背景下，純粹的業(yè)務(wù)單元在不借助第三方工具的前提下，需要消耗巨大的代價才能實現(xiàn)業(yè)務(wù)需求，同時也出現(xiàn)不同業(yè)務(wù)單元對同一個工具的強依賴性。因此在服務(wù)拆分與聚合時，我們考慮了兩種形態(tài)的實現(xiàn)方式：業(yè)務(wù)支撐與工具支撐。

業(yè)務(wù)支撐

業(yè)務(wù)支撐需要考慮的是業(yè)務(wù)服務(wù)對象和業(yè)務(wù)內(nèi)部邏輯。業(yè)務(wù)服務(wù)對象作為整個業(yè)務(wù)單元的對外形態(tài)，通過命名能夠清晰的表達其涵蓋的業(yè)務(wù)范圍;業(yè)務(wù)內(nèi)部邏輯需要對業(yè)務(wù)單元進行細粒度的拆分，類似一個實體類可以包括多個其他相關(guān)聯(lián)的實體對象(當(dāng)然如果服務(wù)拆分的足夠細化，也可以把內(nèi)部邏輯作為獨立的業(yè)務(wù)單元，但是這樣會加重業(yè)務(wù)直接的通信負載)?；跇I(yè)務(wù)內(nèi)部邏輯構(gòu)建業(yè)務(wù)服務(wù)對象的真實場景。具體的拆分細節(jié)可以依賴DDD的實踐方法進行(當(dāng)然也需要根據(jù)業(yè)務(wù)做相應(yīng)調(diào)整，沒有普世之道)。

工具支撐

工具支撐需要結(jié)合業(yè)務(wù)考慮，分為兩種：通用性工具和專用性工具。通用性工具旨在為所有業(yè)務(wù)單元運行提供統(tǒng)一的支撐平臺，從而減少由于工具維護花費的精力，使得業(yè)務(wù)開發(fā)人員聚焦業(yè)務(wù)實現(xiàn)，一般通用工具包包括統(tǒng)一日志處理，統(tǒng)一攔截處理，返回數(shù)據(jù)統(tǒng)一封裝，異常統(tǒng)一處理等等;專用性工具聚焦某個具體的業(yè)務(wù)單元，由業(yè)務(wù)單元自身維護(例如迭代升級)。工具支撐層面不會提供對外restful或者rpc的接口，對外的表現(xiàn)形式為編譯好的依賴工具包(例如Github的管理接口的封裝)。

服務(wù)架構(gòu)選型

依照執(zhí)行原則完成服務(wù)拆分以后，我們需要考慮的是合適的落地選型。選型方案要考慮的因素有很多：技術(shù)背景(尤其是團隊內(nèi)編程語言的設(shè)定)，服務(wù)支撐工具(注冊中心，網(wǎng)關(guān)，服務(wù)調(diào)用，負載均衡數(shù)據(jù)庫等)，服務(wù)運行工具(tomcat，jetty，jboss等)，服務(wù)部署工具(物理部署，虛擬化，容器等)，工具的協(xié)議支撐集合(http，rpc，mtqq，idoc等)。但是無論如何選型最終一定要結(jié)合團隊開發(fā)人員當(dāng)下的技能支撐，這也是我們選型的核心因素，因為白盒相對來說始終比黑盒安全，也相對可控。

這里給出我們的技術(shù)棧選型框架(僅限我們熟悉的內(nèi)容)，暫時不涉及技術(shù)框架的對比說明。

• 服務(wù)開發(fā)框架：springboot，dubbo，grpc，ServiceMesh(基于ServiceMesh的開發(fā)服務(wù)框架)
• 分布式存儲/注冊中心：Zookeeper，Consul，Eureka，Etcd
• 服務(wù)網(wǎng)關(guān)：Kong，Openresty，Spring cloud Zuul，Spring cloud gateway
• 負載均衡：nginx，spring cloud Ribbon，haproxy，Kubernetes service
• 服務(wù)遠程調(diào)用：Spring cloud feign
• 緩存服務(wù)：memchace，redis
• 數(shù)據(jù)庫：mariadb，mysql
• 消息服務(wù)：RabbitMQ，NATS，Kafka
• 配置中心：spring cloud config，Apollo，Consul
• 事件機制：Cloud Event
• 服務(wù)編排：Conductor ，Kubernetes
• 服務(wù)治理：spring cloud，Dubbo，ServiceMesh

基于消息機制的分布式事務(wù)處理(遵循CAP或者BASE理論模型的實現(xiàn))

• 業(yè)務(wù)運行工具：jvm，nginx或者其他可運行環(huán)境支撐
• 開發(fā)編譯工具：Jenkins，maven，gitlab
• 接口文檔：Swagger
• 部署工具：物理部署(jar包或者可運行的編譯的二進制文件)虛擬化部署(虛擬鏡像模板)容器化部署(Docker)

我們在落地的過程中，根據(jù)團隊技術(shù)特點開發(fā)階段重點選擇了Spring Cloud中涵蓋的技術(shù)棧。方便易用，能夠快速入手。運行階段選擇具備服務(wù)編排能力的Kubernetes容器化運行環(huán)境，并且結(jié)合Devops工具鏈能夠快速迭代部署。

服務(wù)接口設(shè)計

服務(wù)接口是對外展現(xiàn)業(yè)務(wù)邏輯的唯一入口，接口定義的規(guī)范與否也是微服務(wù)落地的關(guān)鍵指標之一，我們在實踐的過程中參考了多個開源項目的接口設(shè)計，針對任何一個資源對象，整體分為幾類場景：資源集合類操作，資源實體操作，異常處理，參數(shù)處理，統(tǒng)一數(shù)據(jù)返回，審計日志以及其他具體場景。

統(tǒng)一的接口請求與響應(yīng)標準

其中業(yè)務(wù)單元絕大多數(shù)端口圍繞著資源集合類、資源實體類進行操作，因此我們從restful接口規(guī)范出發(fā)，結(jié)合具體場景，規(guī)范了請求方式，請求url，請求參數(shù)，請求header，響應(yīng)header，響應(yīng)值等信息。

請求參數(shù)涵蓋默認語義，包括：Get(獲取信息)，Post(創(chuàng)建)，Put(全量修改)，Patch(部分修改)，Delete(刪除)

以Students實體對象的新建為例，給出請求與響應(yīng)標準。

URL

URL請求包括三部分：請求方式，統(tǒng)一前綴以及具體url，統(tǒng)一前綴具備一定含義的命名規(guī)則，包括api申明，供應(yīng)商標識，版本說明等必要信息，例如：

Post /api/cloud/v1/students?exist={skip,replace}

請求header

• type
• aplication/json：用于single和bulk時，用來表示請求數(shù)據(jù)為json格式
• application/vnd.ms-excel：從excel格式的文件導(dǎo)入創(chuàng)建
• Accept
• aplication/json：接受json格式的響應(yīng)數(shù)據(jù)
• Authorization
• Oauth2.0的access token(bearer token)
• Accept-Language(可選)
• 可接受的語言，國際化，en-US表示美國英語

請求數(shù)據(jù)格式+類型

• json格式：{items:[]}
• 請求創(chuàng)建students對象json(表達)：
• 請求(批量)創(chuàng)建student對象列表json(表達)
• 請求(批量)創(chuàng)建student信息excel文

響應(yīng)header

• Content-Type
• aplication/json
• Content-Language(可選)
• 內(nèi)容語言
• Last-Modified
• 數(shù)據(jù)最近一次修改的時間戳信息

響應(yīng)值

• Success message：多種類型
• Error message：多種類型
• Exception：多種類型

統(tǒng)一異常處理

統(tǒng)一異常處理包括狀態(tài)碼以及狀態(tài)碼涵蓋的異常信息，具體部分定義如下：

• 200/201+success message(含資源數(shù)量信息+uri信息)：創(chuàng)建成功，適用于數(shù)量不多(比如小于500)的創(chuàng)建操作，大于設(shè)定的值時進行異步處理，參加返回值202
• 202+success message with status uri：異步處理，返回進度查詢資源uri(/api/vendor/v1/status/{id})
• 400+success+errors(含出錯項index的錯誤列表)：批量創(chuàng)建時部分成功，返回成功信息和錯誤信息
• 401+exception{error_code+message}：缺乏認證信息
• 403+exception{error_code+message}：未授權(quán)訪問，訪問被拒絕
• 406+exception{ error_code+message}：不支持client要求的格式或語言時返回該信息(Not Acceptable)
• 415+exception{error_code+message}:請求中的文檔格式不支持
• 422+exception{error_code+message}：不能處理的數(shù)據(jù)，比如json格式錯誤、文件內(nèi)容項錯誤或會破壞業(yè)務(wù)規(guī)則
• 429+exception{ error_code+message}：太多請求，流控時使用
• 500+exception{error_code+message}：服務(wù)器內(nèi)部錯誤

統(tǒng)一日志攔截

基于AOP模式攔截所有請求，在請求入站與出站的時候，做統(tǒng)一日志記錄以及需要的其他非業(yè)務(wù)處理(例如鑒權(quán))

統(tǒng)一的數(shù)據(jù)返回標準

我們參考Restful數(shù)據(jù)返回標準，封裝我們自己的數(shù)據(jù)返回格式：code，message，body，error，統(tǒng)一的數(shù)據(jù)返回格式可以在接口層做統(tǒng)一的攔截處理。實現(xiàn)返回數(shù)據(jù)的標準化。

• code：返回狀態(tài)碼
• message：返回響應(yīng)結(jié)果的語義解釋
• body：響應(yīng)的具體數(shù)據(jù)信息，包括metada信息，具體響應(yīng)數(shù)據(jù)以及請求連接
• error：代表返回的錯誤信息

具體的響應(yīng)格式如下所示：

{ 
"code": 200, 
"message": "獲取學(xué)生列表成功", 
"body": { 
"links": [ 
{ 
"rel": "self", 
"href": "http://localhost:8080/api/clou ... t%3D0{&fields}", 
"hreflang": null, 
"media": null, 
"title": null, 
"type": null, 
"deprecation": null 
} 
], 
"metadata": [] 
"content": [ 
{ 
"id": 1, 
"name": "test3", 
"status": "running", 
"props": "test", 
"remark": "test", 
"ownerId": 1, 
"createrId": 1, 
"menderId": 1, 
"gmtCreate": "2019-03-11 10:42:15", 
"gmtModify": null, 
"startDate": null, 
"endDate": null, 
"links": [ 
{ 
"rel": "self", 
"href": "http://localhost:8080/api/clou ... ot%3B, 
"hreflang": null, 
"media": null, 
"title": null, 
"type": null, 
"deprecation": null 
} 
] 
} 
] 
} 
"errors": {} 
} 

服務(wù)接口的設(shè)計一定是圍繞標準化的規(guī)則進行的，這樣才能在后期減少因為接口變動導(dǎo)致不斷出現(xiàn)的前后端聯(lián)調(diào)問題。因為在實踐中我們經(jīng)常遇到格式不統(tǒng)一導(dǎo)致web要寫不同的數(shù)據(jù)解析方式，從而造成大量重復(fù)的工作。

遺留問題

當(dāng)然我們落地過程的選擇也不一定盡善盡美，也有很多隨著業(yè)務(wù)處理能力的加強而在之前沒有考慮到的問題，例如：

• 各個服務(wù)自身并發(fā)數(shù)據(jù)支撐能力
• 服務(wù)交互的內(nèi)部代碼瓶頸，包括調(diào)用鏈路冗余，響應(yīng)偏慢等
• 數(shù)據(jù)庫的并發(fā)支撐與性能優(yōu)化
• 與容器服務(wù)集成的參數(shù)配置，開發(fā)與部署環(huán)境的轉(zhuǎn)變
• 調(diào)用鏈路可能出現(xiàn)的回環(huán)問題，交叉的業(yè)務(wù)單元調(diào)用，導(dǎo)致調(diào)用鏈路混亂
• 數(shù)據(jù)的緩存設(shè)計，加快業(yè)務(wù)響應(yīng)速率

這些問題我們在后續(xù)不斷深入地理解和探索中會找到相應(yīng)的解決方案，大家可以在后續(xù)繼續(xù)關(guān)注我們的微服務(wù)解決方案。

文章題目：微服務(wù)落地，我們在考慮什么？
網(wǎng)頁鏈接：http://jinyejixie.com/news/100860.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、網(wǎng)站設(shè)計公司、做網(wǎng)站、網(wǎng)站營銷、網(wǎng)頁設(shè)計公司、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)