架構(gòu)師在軟件項(xiàng)目中的作用是提供待解決問(wèn)題的工作模型。架構(gòu)師的工作是提供腳手架，開(kāi)發(fā)人員將根據(jù)這些腳手架構(gòu)建他們的代碼，使應(yīng)用程序所有部件都組合在一起。

在構(gòu)建微服務(wù)架構(gòu)時(shí)，項(xiàng)目的架構(gòu)師主要關(guān)注以下3個(gè)關(guān)鍵任務(wù)：

(1)分解業(yè)務(wù)問(wèn)題；

(2)建立服務(wù)粒度；

(3)定義服務(wù)接口。

2.1.1　分解業(yè)務(wù)問(wèn)題

面對(duì)復(fù)雜性，大多數(shù)人試圖將他們正在處理的問(wèn)題分解成可管理的塊。因?yàn)檫@樣他們就不必努力把問(wèn)題的所有細(xì)節(jié)都考慮進(jìn)來(lái)。他們將問(wèn)題抽象地分解成幾個(gè)關(guān)鍵部分，然后尋找這些部分之間存在的關(guān)系。

在微服務(wù)架構(gòu)中，架構(gòu)師將業(yè)務(wù)問(wèn)題分解成代表離散活動(dòng)領(lǐng)域的塊。這些塊封裝了與業(yè)務(wù)域特定部分相關(guān)聯(lián)的業(yè)務(wù)規(guī)則和數(shù)據(jù)邏輯。

雖然我們希望微服務(wù)封裝執(zhí)行單個(gè)事務(wù)的所有業(yè)務(wù)規(guī)則，但這并不總是行得通。我們經(jīng)常會(huì)遇到需要跨業(yè)務(wù)領(lǐng)域不同部分的一組微服務(wù)來(lái)完成整個(gè)事務(wù)的情況。架構(gòu)師通過(guò)查看數(shù)據(jù)域中那些不適合放到一起的地方來(lái)劃分一組微服務(wù)的服務(wù)邊界。

例如，架構(gòu)師可能會(huì)看到代碼執(zhí)行的業(yè)務(wù)流程，并意識(shí)到它們同時(shí)需要客戶(hù)和產(chǎn)品信息。存在兩個(gè)離散的數(shù)據(jù)域時(shí)，通常就意味著需要使用多個(gè)微服務(wù)。業(yè)務(wù)事務(wù)的兩個(gè)不同部分如何交互通常成為微服務(wù)的服務(wù)接口。

分離業(yè)務(wù)領(lǐng)域是一門(mén)藝術(shù)，而不是非黑即白的科學(xué)。讀者可以使用以下指導(dǎo)方針將業(yè)務(wù)問(wèn)題識(shí)別和分解為備選的微服務(wù)。

(1)描述業(yè)務(wù)問(wèn)題，并聆聽(tīng)用來(lái)描述問(wèn)題的名詞。在描述問(wèn)題時(shí)，反復(fù)使用的同一名詞通常意味著它們是核心業(yè)務(wù)領(lǐng)域并且適合創(chuàng)建微服務(wù)。第1章中EagleEye域的目標(biāo)名詞可能會(huì)是合同、許可證和資產(chǎn)。

(2)注意動(dòng)詞。動(dòng)詞突出了動(dòng)作，通常代表問(wèn)題域的自然輪廓。如果發(fā)現(xiàn)自己說(shuō)出“事務(wù)X需要從事物A和事物B獲取數(shù)據(jù)”這樣的話(huà)，通常表明多個(gè)服務(wù)正在起作用。如果把注意動(dòng)詞的方法應(yīng)用到EagleEye上，那么就可能會(huì)查找像“來(lái)自桌面服務(wù)的Mike安裝新PC時(shí)，他會(huì)查找軟件X可用的許可證數(shù)量，如果有許可證，就安裝軟件。然后他更新了跟蹤電子表格中使用的許可證的數(shù)量”這樣的陳述句。這里的關(guān)鍵動(dòng)詞是查找和更新。

(3)尋找數(shù)據(jù)內(nèi)聚。將業(yè)務(wù)問(wèn)題分解成離散的部分時(shí)，要尋找彼此高度相關(guān)的數(shù)據(jù)。如果在會(huì)話(huà)過(guò)程中，突然讀取或更新與迄今為止所討論的內(nèi)容完全不同的數(shù)據(jù)，那么就可能還存在其他候選服務(wù)。微服務(wù)應(yīng)完全擁有自己的數(shù)據(jù)。

讓我們將這些指導(dǎo)方針應(yīng)用到現(xiàn)實(shí)世界的問(wèn)題中。第1章介紹了一種名為EagleEye的現(xiàn)有軟件產(chǎn)品，該軟件產(chǎn)品用于管理軟件資產(chǎn)，如軟件許可證和安全套接字層(SSL)證書(shū)。這些軟件資產(chǎn)被部署到組織中的各種服務(wù)器上。

EagleEye是一個(gè)傳統(tǒng)的單體Web應(yīng)用程序，部署在位于客戶(hù)數(shù)據(jù)中心內(nèi)的J2EE應(yīng)用程序服務(wù)器。我們的目標(biāo)是將現(xiàn)有的單體應(yīng)用程序梳理成一組服務(wù)。

首先，我們要采訪(fǎng)EagleEye應(yīng)用程序的所有用戶(hù)，并討論他們是如何交互和使用EagleEye的。圖2-1描述了與不同業(yè)務(wù)客戶(hù)進(jìn)行的對(duì)話(huà)的總結(jié)。通過(guò)查看EagleEye的用戶(hù)是如何與應(yīng)用程序進(jìn)行交互的，以及如何將應(yīng)用程序的數(shù)據(jù)模型分解出來(lái)，可以將EagleEye問(wèn)題域分解為以下備選微服務(wù)。

圖2-1　采訪(fǎng)EagleEye用戶(hù)，了解他們?nèi)绾巫鋈粘９ぷ?/p>

圖2-1強(qiáng)調(diào)了與業(yè)務(wù)用戶(hù)對(duì)話(huà)時(shí)出現(xiàn)的一些名詞和動(dòng)詞。因?yàn)檫@是現(xiàn)有的應(yīng)用程序，所以可以查看應(yīng)用程序并將主要名詞映射到物理數(shù)據(jù)模型中的表。現(xiàn)有應(yīng)用程序可能有數(shù)百?gòu)埍?#xff0c;但每張表通常會(huì)映射回一組邏輯實(shí)體。

圖2-2展示了基于與EagleEye客戶(hù)對(duì)話(huà)的簡(jiǎn)化數(shù)據(jù)模型。基于業(yè)務(wù)對(duì)話(huà)和數(shù)據(jù)模型，備選微服務(wù)是組織、許可證、合同和資產(chǎn)服務(wù)。

圖2-2　簡(jiǎn)化的EagleEye數(shù)據(jù)模型

2.1.2　建立服務(wù)粒度

擁有了一個(gè)簡(jiǎn)化的數(shù)據(jù)模型，就可以開(kāi)始定義在應(yīng)用程序中需要哪些微服務(wù)。根據(jù)圖2-2中的數(shù)據(jù)模型，可以看到潛在的4個(gè)微服務(wù)基于以下元素：

• 資產(chǎn)；
• 許可證；
• 合同；
• 組織。

我們的目標(biāo)是將這些主要的功能部件提取到完全獨(dú)立的單元中，這些單元可以獨(dú)立構(gòu)建和部署。但是，從數(shù)據(jù)模型中提取服務(wù)需要的不只是將代碼重新打包到單獨(dú)的項(xiàng)目中，還涉及梳理出服務(wù)訪(fǎng)問(wèn)的實(shí)際數(shù)據(jù)庫(kù)表，并且只允許每個(gè)單獨(dú)的服務(wù)訪(fǎng)問(wèn)其特定域中的表。圖2-3展示了應(yīng)用程序代碼和數(shù)據(jù)模型如何被“分塊”到各個(gè)部分。

圖2-3　將數(shù)據(jù)模型作為把單體應(yīng)用程序分解為微服務(wù)的基礎(chǔ)

將問(wèn)題域分解成不同的部分后，開(kāi)發(fā)人員通常會(huì)發(fā)現(xiàn)自己不確定是否為服務(wù)劃分了適當(dāng)?shù)牧６燃?jí)別。一個(gè)太粗粒度或太細(xì)粒度的微服務(wù)將具有很多的特征，我們將在稍后討論。

構(gòu)建微服務(wù)架構(gòu)時(shí)，粒度的問(wèn)題很重要，可以采用以下思想來(lái)確定正確的解決方案。

(1)開(kāi)始的時(shí)候可以讓微服務(wù)涉及的范圍更廣泛一些，然后將其重構(gòu)到更小的服務(wù)——在開(kāi)始微服務(wù)旅程之初，容易出現(xiàn)的一個(gè)極端情況就是將所有的事情都變成微服務(wù)。但是將問(wèn)題域分解為小型的服務(wù)通常會(huì)導(dǎo)致過(guò)早的復(fù)雜性，因?yàn)槲⒎?wù)變成了細(xì)粒度的數(shù)據(jù)服務(wù)。

(2)重點(diǎn)關(guān)注服務(wù)如何相互交互——這有助于建立問(wèn)題域的粗粒度接口。從粗粒度重構(gòu)到細(xì)粒度是比較容易的。

(3)隨著對(duì)問(wèn)題域的理解不斷增長(zhǎng)，服務(wù)的職責(zé)將隨著時(shí)間的推移而改變——通常來(lái)說(shuō)，當(dāng)需要新的應(yīng)用功能時(shí)，微服務(wù)就會(huì)承擔(dān)起職責(zé)。最初的微服務(wù)可能會(huì)發(fā)展為多個(gè)服務(wù)，原始的微服務(wù)則充當(dāng)這些新服務(wù)的編排層，負(fù)責(zé)將應(yīng)用的其他部分的功能封裝起來(lái)。

糟糕的微服務(wù)的“味道” 如何知道微服務(wù)的劃分是否正確？如果微服務(wù)過(guò)于粗粒度，可能會(huì)看到以下現(xiàn)象。 服務(wù)承擔(dān)過(guò)多的職責(zé)——服務(wù)中的業(yè)務(wù)邏輯的一般流程很復(fù)雜，并且似乎正在執(zhí)行一組過(guò)于多樣化的業(yè)務(wù)規(guī)則。 該服務(wù)正在跨大量表來(lái)管理數(shù)據(jù)——微服務(wù)是它管理的數(shù)據(jù)的記錄系統(tǒng)。如果發(fā)現(xiàn)自己將數(shù)據(jù)持久化存儲(chǔ)到多個(gè)表或接觸到當(dāng)前數(shù)據(jù)庫(kù)以外的表，那么這就是一條服務(wù)過(guò)于粗粒度的線(xiàn)索。我喜歡使用這么一個(gè)指導(dǎo)方針——微服務(wù)應(yīng)該不超過(guò)3～5個(gè)表。再多一點(diǎn)，服務(wù)就可能承擔(dān)了太多的職責(zé)。 測(cè)試用例太多——隨著時(shí)間的推移，服務(wù)的規(guī)模和職責(zé)會(huì)增長(zhǎng)。如果一開(kāi)始有一個(gè)只有少量測(cè)試用例的服務(wù)，到了最后該服務(wù)需要數(shù)百個(gè)單元測(cè)試用例和集成測(cè)試用例，那么就可能需要重構(gòu)。 如果微服務(wù)過(guò)于細(xì)粒度呢？ 問(wèn)題域的一部分微服務(wù)像兔子一樣繁殖——如果一切都成為微服務(wù)，將服務(wù)中的業(yè)務(wù)邏輯組合起來(lái)會(huì)變得復(fù)雜和困難，因?yàn)橥瓿梢豁?xiàng)工作所需的服務(wù)數(shù)量會(huì)快速增長(zhǎng)。一種常見(jiàn)的“壞味道”出現(xiàn)在應(yīng)用程序有幾十個(gè)微服務(wù)，并且每個(gè)服務(wù)只與一個(gè)數(shù)據(jù)庫(kù)表進(jìn)行交互時(shí)。 微服務(wù)彼此間嚴(yán)重相互依賴(lài)——在問(wèn)題域的某一部分中，微服務(wù)相互來(lái)回調(diào)用以完成單個(gè)用戶(hù)請(qǐng)求。 微服務(wù)成為簡(jiǎn)單CRUD(Create，Read，Update，Delete)服務(wù)的集合——微服務(wù)是業(yè)務(wù)邏輯的表達(dá)，而不是數(shù)據(jù)源的抽象層。如果微服務(wù)除了CRUD相關(guān)邏輯之外什么都不做，那么它們可能被劃分得太細(xì)粒度了。

應(yīng)該通過(guò)演化思維的過(guò)程來(lái)開(kāi)發(fā)一個(gè)微服務(wù)架構(gòu)，在這個(gè)過(guò)程中，你知道不會(huì)第一次就得到正確的設(shè)計(jì)。這就是最好從一組粗粒度的服務(wù)而不是一組細(xì)粒度的服務(wù)開(kāi)始的原因。同樣重要的是，不要對(duì)設(shè)計(jì)帶有教條主義。我們可能會(huì)面臨兩個(gè)單獨(dú)的服務(wù)之間交互過(guò)于頻繁，或者服務(wù)的域之間不存在明確的邊界這樣的物理約束，當(dāng)面臨這樣的約束時(shí)，需要?jiǎng)?chuàng)建一個(gè)聚合服務(wù)來(lái)將數(shù)據(jù)連接在一起。

最后，采取務(wù)實(shí)的做法并進(jìn)行交付，而不是浪費(fèi)時(shí)間試圖讓設(shè)計(jì)變得完美，最終導(dǎo)致沒(méi)有東西可以展現(xiàn)你的努力。

2.1.3　互相交流：定義服務(wù)接口

架構(gòu)師需要關(guān)心的最后一部分，是應(yīng)用程序中的微服務(wù)該如何彼此交流。使用微服務(wù)構(gòu)建業(yè)務(wù)邏輯時(shí)，服務(wù)的接口應(yīng)該是直觀(guān)的，開(kāi)發(fā)人員應(yīng)該通過(guò)學(xué)習(xí)應(yīng)用程序中的一兩個(gè)服務(wù)來(lái)獲得應(yīng)用程序中所有服務(wù)的工作節(jié)奏。

一般來(lái)說(shuō)，可使用以下指導(dǎo)方針?biāo)伎挤?wù)接口設(shè)計(jì)。

(1)擁抱REST的理念——REST對(duì)服務(wù)的處理方式是將HTTP作為服務(wù)的調(diào)用協(xié)議并使用標(biāo)準(zhǔn)HTTP動(dòng)詞(GET、PUT、POST和DELETE)。圍繞這些HTTP動(dòng)詞對(duì)基本行為進(jìn)行建模。

(2)使用URI來(lái)傳達(dá)意圖——用作服務(wù)端點(diǎn)的URI應(yīng)描述問(wèn)題域中的不同資源，并為問(wèn)題域內(nèi)的資源的關(guān)系提供一種基本機(jī)制。

(3)請(qǐng)求和響應(yīng)使用JSON——JavaScript對(duì)象表示法(JavaScript Object Notation，JSON)是一個(gè)非常輕量級(jí)的數(shù)據(jù)序列化協(xié)議，并且比XML更容易使用。

(4)使用HTTP狀態(tài)碼來(lái)傳達(dá)結(jié)果——HTTP協(xié)議具有豐富的標(biāo)準(zhǔn)響應(yīng)代碼，以指示服務(wù)的成功或失敗。學(xué)習(xí)這些狀態(tài)碼，并且最重要的是在所有服務(wù)中始終如一地使用它們。

所有這些指導(dǎo)方針都是為了完成一件事，那就是使服務(wù)接口易于理解和使用。我們希望開(kāi)發(fā)人員坐下來(lái)查看一下服務(wù)接口就能開(kāi)始使用它們。如果微服務(wù)不容易使用，開(kāi)發(fā)人員就會(huì)另辟道路，破壞架構(gòu)的意圖。

本文摘自《Spring微服務(wù)實(shí)戰(zhàn)》

本書(shū)教讀者如何使用Java和Spring平臺(tái)構(gòu)建基于微服務(wù)的應(yīng)用程序。在構(gòu)建和部署第1個(gè)Spring Cloud應(yīng)用程序時(shí)，讀者將學(xué)習(xí)如何進(jìn)行微服務(wù)設(shè)計(jì)。在本書(shū)中，精心挑選的真實(shí)案例展示了基于微服務(wù)的各種模式，這些模式用于配置、路由、擴(kuò)展和部署服務(wù)。讀者將了解Spring易于使用的工具，并看到其如何助力用微服務(wù)來(lái)增強(qiáng)和重構(gòu)現(xiàn)有的應(yīng)用程序。

本書(shū)主要內(nèi)容

● 核心微服務(wù)設(shè)計(jì)原則。

● 使用Spring Cloud Config管理配置。

● 使用Spring、Hystrix和Ribbon實(shí)現(xiàn)客戶(hù)端彈性。

● 使用Netflix Zuul進(jìn)行智能路由。

● 部署Spring Cloud應(yīng)用程序。

本書(shū)是為具有Java和Spring經(jīng)驗(yàn)的開(kāi)發(fā)人員編寫(xiě)的。

總結(jié)

以上是生活随笔為你收集整理的微服务架构 接口交互问题_架构师的故事：设计微服务架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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