Java 和微服務系列：第 1 部分微服務

微服務是一種架構，其中的大型、複雜的軟件應用程序由一個或多個更小的服務組成。每個微服務僅負責完成一項代表一種小業務能力的任務。這些微服務可使用任何編程語言開發。本系列內容針對 Java 的微服務最佳實踐展開講解。

微服務架構

微服務是相對較小的自主服務，它們合作完成工作。每個服務都實現一種業務需求。

微服務架構是 Martin Fowler 和 James Lewis 定義的一種架構風格。他們將這種風格描述爲"一種使用小型服務構建系統的架構方法，每個服務都在自己的進程中，它們通過輕量型協議進行通信"。有關的更多信息，請參閱 Martin Fowler 編寫的"微服務：一個新的架構術語"。

每個服務都是相互獨立開發和部署的。每個微服務都專注執行一個它所擅長的相對較小的任務。

以下各節將重點介紹典型的微服務架構的一些特徵，讓您大體瞭解該架構。

小型且專注於業務領域

小並不能充分描述微服務，使用這個詞只是爲了嘗試表明微服務相對於整體式應用程序的大小。在此上下文中，小的定義可能在各個系統中各不相同，而且沒有規則來定義服務必須有多小。

微服務通常負責一個精細的工作單元，所以它在規模上相對較小。一條著名的指導原則是"兩塊披薩的團隊規模"方案，意思是說，如果兩塊披薩不能將整個團隊餵飽，那麼這個開發微服務的團隊可能太大了。微服務必須足夠小，使得團隊中的每個人都能理解該服務的整體設計和實現。另外，它的大小必須足以讓團隊在必要時輕鬆地維護或重寫服務。

微服務的另一個重要特徵是，每個服務專注負責一項精細的業務。Vaughn Vernon 在他撰寫的圖書《實現領域驅動設計》中定義了術語業務領域。他將業務領域定義爲，"某個組織執行的操作和它執行操作的環境。"他還指定，"每個組織都有自己獨特的知識範圍和操作方式。這個理解範圍和它執行操作的方法就是它的領域。"被分解爲微服務的單元實際上就是領域內的業務實體，這意味着每個微服務處理完成一個完整的業務任務。例如：Mortgage Services 是一個業務領域。Loan Origination 是該領域中一個可能的微服務。Loan Refinancing 可能是同一個領域中的另一個微服務。跨服務邊界的調用和更改通常很耗資源，必須避免。擁有這些服務的團隊成爲相應業務領域或子領域的專家，而不是任意技術領域的專家。

與技術中立

開發微服務的團隊必須使用他們熟悉的技術。不要規定開發團隊應該使用何種編程語言。讓開發人員自由選擇對任務最有意義的技術和執行任務的人。這種工作方式能夠充分利用團隊成員擁有的最佳技術和技能。微服務架構仍需要技術決策；舉例而言，使用具象狀態傳輸 (REST) 應用編程接口 (API) 訪問更好一些，還是使用某種類型的排隊來訪問更好一些？但是，一般而言，您可以爲微服務架構選擇廣泛範圍內的任何技術。

鬆散耦合

鬆散耦合對基於微服務的系統至關重要。每個微服務都必須採用使其與其他服務的關聯很小的方式來設計接口。這樣，在更改一個服務並部署它時，就無需更改和重新部署系統的其他部分。

爲了避免服務之間的耦合，必須瞭解導致緊密耦合的原因。緊密耦合的一個原因是通過 API 公開服務的內部實現。這種公開方式將服務的使用者與它的內部實現綁定在一起，從而導致更高的耦合度。在這種情況下，如果更改微服務的內部架構，可能還需要更改服務的使用者，否則就會破壞使用者。這可能會增加更改的成本，給實現更改帶來潛在隱患，進而增加服務中的技術債務。必須避免任何導致公開服務的內部實現的方法，以確保微服務之間鬆散耦合。

另一個錯誤是讓服務的 API 太過精細。如果 API 太過精細，服務之間的調用可能變得太過頻繁，也就是說，會通過網絡執行更多的調用。除了前綴的性能問題，過度頻繁的通信還可能造成緊密耦合。因此，設計服務接口的方式必須能夠最大限度地減少網絡中執行的來回調用。

必須避免一個服務內的實現過於分散，方法是將表示業務實體的相關屬性、行爲放在儘可能相近的地方。將相關屬性放在一個微服務中；如果更改某個屬性或行爲，可以在一個位置更改它並快速部署該更改。否則，必須在不同部分中執行更改，然後同時一起部署這些散亂的部分；這會導致這些部門之間緊密耦合。

每個微服務必須有自己的源代碼管理存儲，以及用於構建和部署的交付管道。這樣即可在必要時部署每個服務，而不需要與其他服務的所有者進行協調。如果您有兩個服務，而且始終在一次部署中一起發佈這兩個服務，這可能表明兩個服務最好合併爲一個服務，而且必須對當前服務執行更多分解工作。鬆散耦合還支持更頻繁、更快速的部署，最終提高應用程序對其用戶需求的響應能力。

容易觀察

微服務架構要求您能夠可視化系統中所有服務的健康狀態，以及它們之間的連接。這使您能快速找到並響應可能發生的問題。實現可視化的工具包含一種全面的日誌機制，能夠記錄日誌，存儲日誌，並使日誌容易搜索，以便執行更有效的分析。

向系統中配置和添加的新服務越多，讓這些服務變得可觀察就會越難。因爲在添加更多動態部分時，微服務架構會增加複雜性，所以觀察設計必須明確，使可視化的日誌和監視數據能爲分析提供有幫助的信息。

自動化

自動化是有效設計和實現軟件應用程序的一個重要要求。對於微服務，自動化是一個至關重要但又充滿挑戰的任務。除了需要在生產中運行系統之外，微服務架構還向系統的實現引入了更多複雜性。在處理的機器和組件數量較少時，可能可以接受手動配置機器，安裝中間件，部署組件，或者手動登錄到服務器並收集日誌，以及執行其他手動任務。但是，當組件數量增加時，在某個時刻後，您可能無法使用手動方法。

自動化可幫助組建一個服務器並安裝必要的運行時環境。然後，只需使用幾行代碼，就能快速將微服務放在這些運行時環境上。這種自動化使您能編寫微結構代碼，訪問用於部署生產服務的準確的工具鏈，從而及早發現問題。自動化是連續集成和連續交付方法的核心推動力量。如果您想將微服務架構的複雜性保持在控制範圍內，推崇自動化文化是關鍵。爲此，您需要一種綜合的、端到端的方法，以便在整個軟件開發生命週期中推廣自動化。這個生命週期涉及通過一些操作執行測試驅動開發，比如 IBM Bluemix® Garage Method。有關更多信息，請訪問網站。

有界上下文

開發模型時，請記住識別它的有界上下文，即模型的有效範圍。有界上下文是具有明確邊界的模型，模型在該邊界內是沒有歧義的。如果您不在模型周圍設置一條邊界，最終使用的上下文可能不在您的應用程序內。適合應用程序的某個部分的上下文不得適合另一個部分，即使它們具有相同的名稱，而且指向相同的實體。例如，如果您構建一個預約系統，則必須知道客戶的基本信息。但是，如果您在賬單上下文中有一個賬單系統，您可能希望在其中包含客戶的聯繫信息和支付信息，而在預約系統上下文中，不需要該信息。如果您嘗試在多個地方重用完全相同的客戶模型，可能會在系統中導致不一致的行爲。這是一個放入預約系統的上下文中的簡單模型，包含一些除客戶名稱外的行爲。

例如，您可能決定在客戶模型上包含某種形式的驗證，以確保擁有足夠的信息來向他們收賬。如果您不夠小心，驗證可能意外地阻止您使用客戶模型安排預約；這不是那您想要的行爲。賬單系統可能要求客戶擁有有效的信用卡，然後才能保存更改。但是，如果缺少信用卡信息，則會阻止您將客戶預約信息保存到預約系統中，這是不合理的。

在這個示例中，您有兩個上下文，但它們之間的邊界是模糊和重疊的。Eric Evans 在他撰寫的圖書《領域驅動設計》中說道"模型僅在特定的上下文內有效。因此，最好顯式定義應用該模型的上下文。您可以避免損壞該上下文內的模型，將它嚴格保持在這些邊界內，並避免被外部問題分心或混淆。"

當顯示定義了有界上下文後，通常能看到您是否擁有一個嘗試擴展到多個上下文中的模型元素。在這個示例中，您希望在預約系統中保持簡單的客戶視圖，而在賬單上下文中提供包含聯繫信息和賬單信息的更完整的客戶視圖版本。在兩個不同的類中定義客戶的這兩個視圖，然後將它們放在不同的應用程序中。Eric Evans 建議，通過爲每個上下文提供它們自己的團隊、代碼庫、數據庫模式和交付管道，讓有界上下文保持分離。

有界上下文的原則在微服務架構中至關重要。可使用這些原則作爲指導，正確地確定系統並將其分解爲微服務。明確定義有界上下文（意味着業務領域是通過顯式邊界分離的），有助於推斷系統中最終包含的微服務。擁有有界上下文，還有助於正式化不同服務之間的交互，有效且高效地構建它們之間的接口。

採用微服務架構的原因

本節將介紹採用微服務架構的一些主要原因。微服務架構是產品或服務所有者跟上或超越 IT 行業的快速發展節奏的推動因素之一。

現有整體式應用程序面臨的挑戰

在整體式應用程序中，大部分邏輯都部署在一個集中化、單一的運行時環境或服務器中，並在其中運行。整體式應用程序通常很大，由一個大型團隊或多個團隊構建。採用此方法，各個團隊需要花更多精力和統籌安排才能執行更改或部署。

隨着時間的推移，整體式模型中已引入了更好的架構模式，有助於顯著提高架構的靈活性。例如，一種著名的模式是模型-視圖-控制器 (MVC)，它將應用程序分解爲層和合理的組件。這些模式有多種優點，比如更快的初始開發、更簡單的應用程序治理，等等。但是，整體式模型也有缺點，尤其是在當今環境中的技術瞬息萬變的背景下。

整體式方法可能帶來許多挑戰，有以下四點：

龐大的應用程序代碼庫龐大的代碼庫可能給希望熟悉代碼的開發人員帶來困擾，尤其是團隊的新成員。龐大的應用程序代碼庫可能還會讓應用程序開發過程中使用的開發環境工具和運行時容器不堪重負。最終，這會導致開發人員效率降低，可能會阻止對執行更改的嘗試。
不頻繁的更新在典型的整體式應用程序中，大部分（幾乎是全部）邏輯組件都部署在單一運行時容器中，並在其中運行。這意味着要更新對某個組件的一處細微更改，必須重新部署整個應用程序。另外，如果需要推廣細微但關鍵的應用程序更改，則需要投入大量精力來對未更改的部分運行迴歸測試。這些挑戰意味着整體式應用程序很難連續交付，這導致部署次數減少，對需要的更改的響應變慢。
依賴單一類型的技術對於整體式模型，由於應用更改方面的挑戰，以增量方式採用新技術或技術棧開發框架的新版本會變得很困難。最終，整體式架構應用程序通常必須一直使用這一種技術，這最終會阻礙應用程序跟上新的發展趨勢。
可擴展性可擴展性是整體式架構面臨的最大挑戰之一。Martin Abbot 和 Michael Fisher 在他們合著圖書《可擴展的藝術》中介紹了一種查看系統的可擴展性的有用方式；他們使用了一種三維可擴展性模型或擴展立方體。在此模型中，通過在負載平衡器後運行克隆版本來擴展應用程序稱爲 X 軸擴展或水平復制。另外兩種擴展是 Y 軸擴展（或功能分解）和 Z 軸擴展（或數據分割），Y 軸擴展通過拆分不同實體來實現擴展，Z 軸擴展通過拆分類似實體來實現擴展。由於整體上的凝聚性，典型的整體式應用程序通常只能在擴展立方體的一個維度上擴展。隨着生產環境收到更多請求，該應用程序通常採用的垂直擴展方式是添加更多資源供其使用，或者克隆到多個副本來進行響應。這種擴展方式低效且很耗資源。當應用程序達到一定規模時，開發團隊必須拆分爲更小的團隊，每個小團隊專注於一個特定的功能區域，各團隊彼此獨立工作，而且通常位於不同地理位置。但是，由於應用程序的各部分間的自然凝聚性，需要各個團隊協力執行更改和重新部署。圖 1 顯示了擴展立方體。

圖 1. 擴展立方體

適用於各種涉衆的微服務

使用微服務架構的最重要目的是，解決整體式模型面臨的難題。本節將從應用程序的不同涉衆角度，介紹微服務方法如何幫助解決整體式系統的問題。

對於業務所有者

作爲業務所有者，您希望您的服務適用於新客戶和業務需求。但是，在整體式模型中，由於龐大的代碼庫，爲滿足業務需求而執行並推廣更改的過程會很緩慢。這個過程緩慢的另一個原因是，各個組件和層之間有嚴格的內部限制和依賴關係。

微服務架構原則是圍繞高靈活性和恢復能力而建立的。這兩個特徵有助於快速推廣更改。這有助於業務所有者更快地收到反饋，調整業務和投資戰略，從而讓客戶滿意和提高市場競爭力。

從資源分配的角度講，由於團隊更小且更專注，所以可以更輕鬆地測量和可視化效率。然後，業務所有者可以更輕鬆地制定投資決策，可將資源從低業務影響區域轉移到高業務影響區域。

對於服務管理人員

作爲服務管理團隊成員，您希望協調各個團隊的管理操作負擔更少，以便您可以提高服務的生產力。整體式模型需要做大量的工作。活動之間需要的協調更多，因爲整體式應用程序通常擁有龐大的業務範圍，以及許多基礎架構和操作接觸點。因此，對應用程序的每次更改都可能需要不同涉衆多次評審和批准。微服務架構推崇利用自助服務，在服務交付管道的每個階段利用自動化。

這有助於減少服務管理團隊的日常管理協調。

微服務架構中的一個重要原則是高可觀察性。高可觀察性功能爲服務管理團隊提供了必要的工具，以便更好地監督系統中或產品中的每個微服務的狀態。這有助於提高服務管理效率。

對於開發人員

作爲加入團隊的新開發人員，您希望快速熟悉源代碼，以便快速上手並帶來成果。典型整體式應用程序中的代碼庫很大，可能阻礙您並潛在地延長學習曲線。對於所有開發人員，龐大的代碼庫會增加載入開發環境中並運行的負擔，從而導致生產力降低。

龐大的代碼庫可能讓代碼評審和其他合作開發活動面臨更大壓力。此外，在處理更改時，破壞其他功能的風險可能導致開發人員對創新和增強應用程序猶豫不決。然而，微服務更小且更輕量，這可以縮短新開發人員的學習曲線。微服務還可以幫助消除加載和運行的繁重負擔，鼓勵引入突破性的更改，從而幫助提高生產力和創新水平。

雲時代和其他工具準備就緒

本節探討爲什麼現在是採用微服務架構的好時機。

雲環境和產品的激增

微服務架構體現了使用連續集成和連續部署的許多優勢。該架構也引入了新的複雜性，需要一種在構建應用程序的每個步驟中實施自動化的現代方法。例如，從基礎架構和治理的角度講，首先需要一個能動態地快速爲服務組建運行時環境的業務連續性基礎架構。該環境可能是一個虛擬機、容器等。另外，還需要一種統籌安排和監視服務的高效方式。當今環境中的雲平臺（比如 IBM Bluemix）可通過其自然的動態性和恢復能力滿足此需求。

藉助可用於各種服務模型的不同雲產品，無論是基礎架構即服務 (IaaS) 還是平臺即服務 (PaaS)，開發人員都可以通過更多選擇轉變爲微服務戰略。藉助 IaaS 選項，您可以在幾分鐘內快速組建一臺機器，而且可以將基礎架構配置打包到一組腳本中，以便根據需要自動化該流程。如果您不想接觸基礎架構級別的複雜性，也可採用平臺級選項，採用不同的語言和服務的形式來快速打包，然後根據意願包含和啓動微服務。

IBM Bluemix 是這些平臺的一個示例。IBM Bluemix 有許多適合使用雲技術構建微服務的服務，比如 IBM 容器、消息中心、日誌記錄、監視和其他技術。Bluemix 使開發人員能夠快速創建、部署和管理他們的雲應用程序，爲簡化操作、確定安全策略和管理系統中微服務的健康提供關鍵基礎。

工具的可用性和成熟性

除了雲基礎架構可爲微服務戰略的採用所提供的動態性和恢復能力，擁有全面的工具也是採用微服務戰略的關鍵需求。微服務工具在不斷演變和進步。在當今環境中，開發人員有許多選擇，他們可以使用一組合適的工具來實施其微服務戰略，比如日誌工具組合、監視工具組合、服務註冊表或容器化技術。這些先進工具可幫助解決微服務架構所引入的挑戰，以便更有效地交付、管理和統籌安排服務。

圖 2 展示了基於微服務架構而構建的 IBM Watson™ 雲服務的完整組合示例。這種革命性架構有云技術、一組全面的工具及敏捷流程提供支持。

圖 2. 支持微服務架構的工具示例

該架構包含多個主要的技術組合：

DevOps 每個 Watson 雲服務在開發後，都會在一個不可變的虛擬機中容器化，然後通過明顯的 DevOps 流程自動部署到 IBM SoftLayer 雲基礎架構上。微服務架構的典型模式（比如服務發現、API 網關等）是通過 IBM 獨有的和開源的技術來使用的。然後，可以在 IBM Bluemix 平臺上公開這些服務。
Elasticsearch、Logstash、Kibana (ELK) 組合或 Elastic 組合 Elk 組合是該系統的日誌工具組合，包含一組工具來捕獲日誌，並將其存儲在一個強大的、集中化的、可搜索的日誌數據庫中。有關更多信息，請查閱 elastic 網站。
監視工具組合圖 2 展示了一組工具，它們可從一箇中央儀表板監視整個系統，包含一種通知機制，以便基於特定事件來發送提醒。

從整體式應用程序向微服務的轉變

本節介紹一種將整體式應用程序轉變爲微服務的實際方案。

虛構公司 A 的業務問題

虛構公司 A 是一家電子商務公司，它使用了一個名爲 Customer Order Service 的基於 Java EE 的傳統 Web 應用程序來提供在線購買服務和運營業務。儘管該應用程序能很好地處理業務，但公司 A 已開始努力響應新的業務需求。這些需求包括：