架構師在軟件項目中的作用是提供待解決問題的工作模型。架構師的工作是提供腳手架，開發人員將根據這些腳手架構建他們的代碼，使應用程序所有部件都組合在一起。

在構建微服務架構時，項目的架構師主要關注以下3個關鍵任務：

(1)分解業務問題；

(2)建立服務粒度；

(3)定義服務接口。

2.1.1　分解業務問題

面對復雜性，大多數人試圖將他們正在處理的問題分解成可管理的塊。因為這樣他們就不必努力把問題的所有細節都考慮進來。他們將問題抽象地分解成幾個關鍵部分，然后尋找這些部分之間存在的關系。

在微服務架構中，架構師將業務問題分解成代表離散活動領域的塊。這些塊封裝了與業務域特定部分相關聯的業務規則和數據邏輯。

雖然我們希望微服務封裝執行單個事務的所有業務規則，但這并不總是行得通。我們經常會遇到需要跨業務領域不同部分的一組微服務來完成整個事務的情況。架構師通過查看數據域中那些不適合放到一起的地方來劃分一組微服務的服務邊界。

例如，架構師可能會看到代碼執行的業務流程，并意識到它們同時需要客戶和產品信息。存在兩個離散的數據域時，通常就意味著需要使用多個微服務。業務事務的兩個不同部分如何交互通常成為微服務的服務接口。

分離業務領域是一門藝術，而不是非黑即白的科學。讀者可以使用以下指導方針將業務問題識別和分解為備選的微服務。

(1)描述業務問題，并聆聽用來描述問題的名詞。在描述問題時，反復使用的同一名詞通常意味著它們是核心業務領域并且適合創建微服務。第1章中EagleEye域的目標名詞可能會是合同、許可證和資產。

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

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

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

EagleEye是一個傳統的單體Web應用程序，部署在位于客戶數據中心內的J2EE應用程序服務器。我們的目標是將現有的單體應用程序梳理成一組服務。

首先，我們要采訪EagleEye應用程序的所有用戶，并討論他們是如何交互和使用EagleEye的。圖2-1描述了與不同業務客戶進行的對話的總結。通過查看EagleEye的用戶是如何與應用程序進行交互的，以及如何將應用程序的數據模型分解出來，可以將EagleEye問題域分解為以下備選微服務。

圖2-1　采訪EagleEye用戶，了解他們如何做日常工作

圖2-1強調了與業務用戶對話時出現的一些名詞和動詞。因為這是現有的應用程序，所以可以查看應用程序并將主要名詞映射到物理數據模型中的表。現有應用程序可能有數百張表，但每張表通常會映射回一組邏輯實體。

圖2-2展示了基于與EagleEye客戶對話的簡化數據模型?；跇I務對話和數據模型，備選微服務是組織、許可證、合同和資產服務。

圖2-2　簡化的EagleEye數據模型

2.1.2　建立服務粒度

擁有了一個簡化的數據模型，就可以開始定義在應用程序中需要哪些微服務。根據圖2-2中的數據模型，可以看到潛在的4個微服務基于以下元素：

• 資產；
• 許可證；
• 合同；
• 組織。

我們的目標是將這些主要的功能部件提取到完全獨立的單元中，這些單元可以獨立構建和部署。但是，從數據模型中提取服務需要的不只是將代碼重新打包到單獨的項目中，還涉及梳理出服務訪問的實際數據庫表，并且只允許每個單獨的服務訪問其特定域中的表。圖2-3展示了應用程序代碼和數據模型如何被“分塊”到各個部分。

圖2-3　將數據模型作為把單體應用程序分解為微服務的基礎

將問題域分解成不同的部分后，開發人員通常會發現自己不確定是否為服務劃分了適當的粒度級別。一個太粗粒度或太細粒度的微服務將具有很多的特征，我們將在稍后討論。

構建微服務架構時，粒度的問題很重要，可以采用以下思想來確定正確的解決方案。

(1)開始的時候可以讓微服務涉及的范圍更廣泛一些，然后將其重構到更小的服務——在開始微服務旅程之初，容易出現的一個極端情況就是將所有的事情都變成微服務。但是將問題域分解為小型的服務通常會導致過早的復雜性，因為微服務變成了細粒度的數據服務。

(2)重點關注服務如何相互交互——這有助于建立問題域的粗粒度接口。從粗粒度重構到細粒度是比較容易的。

(3)隨著對問題域的理解不斷增長，服務的職責將隨著時間的推移而改變——通常來說，當需要新的應用功能時，微服務就會承擔起職責。最初的微服務可能會發展為多個服務，原始的微服務則充當這些新服務的編排層，負責將應用的其他部分的功能封裝起來。

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

應該通過演化思維的過程來開發一個微服務架構，在這個過程中，你知道不會第一次就得到正確的設計。這就是最好從一組粗粒度的服務而不是一組細粒度的服務開始的原因。同樣重要的是，不要對設計帶有教條主義。我們可能會面臨兩個單獨的服務之間交互過于頻繁，或者服務的域之間不存在明確的邊界這樣的物理約束，當面臨這樣的約束時，需要創建一個聚合服務來將數據連接在一起。

最后，采取務實的做法并進行交付，而不是浪費時間試圖讓設計變得完美，最終導致沒有東西可以展現你的努力。

2.1.3　互相交流：定義服務接口

架構師需要關心的最后一部分，是應用程序中的微服務該如何彼此交流。使用微服務構建業務邏輯時，服務的接口應該是直觀的，開發人員應該通過學習應用程序中的一兩個服務來獲得應用程序中所有服務的工作節奏。

一般來說，可使用以下指導方針思考服務接口設計。

(1)擁抱REST的理念——REST對服務的處理方式是將HTTP作為服務的調用協議并使用標準HTTP動詞(GET、PUT、POST和DELETE)。圍繞這些HTTP動詞對基本行為進行建模。

(2)使用URI來傳達意圖——用作服務端點的URI應描述問題域中的不同資源，并為問題域內的資源的關系提供一種基本機制。

(3)請求和響應使用JSON——JavaScript對象表示法(JavaScript Object Notation，JSON)是一個非常輕量級的數據序列化協議，并且比XML更容易使用。

(4)使用HTTP狀態碼來傳達結果——HTTP協議具有豐富的標準響應代碼，以指示服務的成功或失敗。學習這些狀態碼，并且最重要的是在所有服務中始終如一地使用它們。

所有這些指導方針都是為了完成一件事，那就是使服務接口易于理解和使用。我們希望開發人員坐下來查看一下服務接口就能開始使用它們。如果微服務不容易使用，開發人員就會另辟道路，破壞架構的意圖。

本文摘自《Spring微服務實戰》

本書教讀者如何使用Java和Spring平臺構建基于微服務的應用程序。在構建和部署第1個Spring Cloud應用程序時，讀者將學習如何進行微服務設計。在本書中，精心挑選的真實案例展示了基于微服務的各種模式，這些模式用于配置、路由、擴展和部署服務。讀者將了解Spring易于使用的工具，并看到其如何助力用微服務來增強和重構現有的應用程序。

本書主要內容

● 核心微服務設計原則。

● 使用Spring Cloud Config管理配置。

● 使用Spring、Hystrix和Ribbon實現客戶端彈性。

● 使用Netflix Zuul進行智能路由。

● 部署Spring Cloud應用程序。

本書是為具有Java和Spring經驗的開發人員編寫的。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。