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

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

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

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

我們遵循的原則

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

初期階段

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

這是遵循的兩條原則：

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

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

實踐階段

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

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

協(xié)議標準

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

框架標準

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

接口標準

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

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

服務拆分與聚合

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

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

業(yè)務支撐

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

工具支撐

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

服務架構選型

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

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

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

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

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

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

服務接口設計

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

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

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

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

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

URL

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

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

請求header

• type
• aplication/json：用于single和bulk時，用來表示請求數(shù)據(jù)為json格式
• application/vnd.ms-excel：從excel格式的文件導入創(chuàng)建
• Accept
• aplication/json：接受json格式的響應數(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文

響應header

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

響應值

• 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)建操作，大于設定的值時進行異步處理，參加返回值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}：未授權訪問，訪問被拒絕
• 406+exception{ error_code+message}：不支持client要求的格式或語言時返回該信息(Not Acceptable)
• 415+exception{error_code+message}:請求中的文檔格式不支持
• 422+exception{error_code+message}：不能處理的數(shù)據(jù)，比如json格式錯誤、文件內(nèi)容項錯誤或會破壞業(yè)務規(guī)則
• 429+exception{ error_code+message}：太多請求，流控時使用
• 500+exception{error_code+message}：服務器內(nèi)部錯誤

統(tǒng)一日志攔截

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

統(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：返回響應結果的語義解釋
• body：響應的具體數(shù)據(jù)信息，包括metada信息，具體響應數(shù)據(jù)以及請求連接
• error：代表返回的錯誤信息

具體的響應格式如下所示：

{ 
"code": 200, 
"message": "獲取學生列表成功", 
"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": {} 
} 

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

遺留問題

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

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

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

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

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、電子商務、App開發(fā)、定制網(wǎng)站、網(wǎng)站設計公司、搜索引擎優(yōu)化

廣告

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