7種微服務反模式

什麼是微服務

\

流行術語為那些逐步形成的、需要一個好的“標籤”來方便交流的概念提供了一個上下文。微服務就是這樣的一個新“標籤”，它定義了一個領域，這個領域我自己也發現了，並且現在已經使用了一段時間。我慢慢認識到，相關文章和會議所描述的東西，我已經從自己過去幾年的個人經歷中引申出來。行業和專家對微服務的討論讓Netflix、亞馬遜、谷歌等已經成功實現微服務的公司成為了焦點，而我有一些個人經驗，可以為成功實現微服務提供一些啟發。\

以下是任何架構都遵循的三個標準和最常見的業務驅動力：\

• 提高敏捷性——及時響應業務需求，促進企業發展 \
• 提升使用者體驗——提升客戶體驗，減少客戶流失 \
• 降低成本——降低增加產品、客戶或業務方案的成本

實際上，在日常工作中，所有人都試圖這樣做。SOA建立了一種業務一致的軟體框架，使企業可以達成上述目標。已經出現了幾家大型的軟體供應商，宣稱他們的產品套件可以推動企業實現SOA。\

如果沒有合適的人員、文化和投入，那麼SOA會無法實現業務價值。微服務同SOA並沒有根本的不同，它們的目標和目的是相同的，但微服務方法更精煉。事實上，簡單來說，微服務就是可擴充套件的SOA。對於迫切需要由單體實現轉變成分散式、去中心化的服務平臺併為許多應用程式提供服務的應用程式/系統，微服務提供了這種可能。微服務是獨立的，它擁抱敏捷，並允許應用程式隨企業的數字化轉型進化。微服務的成功取決於服務獨立性和靈活度。\

我會將微服務定義為“一種實現SOA的方法，它通過構建細粒度的服務支援分散式的、按功能域組織的業務能力”。沒有哪種模式是魔法棒或銀彈。你應該專門針對一個企業構思和定製模式。企業應該重點解決那些可以為建立自適應平臺的架構提供支援的必要事項。\

非常不幸的是，一些企業在實現SOA時失敗了——因為他們沒有充分分析他們的業務能力模型，認為開發Web服務就是SOA，或者從大型供應商那裡購買一個SOA套件就實現了SOA，或者他們沒有能力闡述SOA同其業務驅動力/目標的一致性。\

例子

\

我經歷過的一個例子也許可以說明這一點。在以前的一個崗位上，企業的目標是提高敏捷性、提升使用者體驗以及降低成本。我們決定構建一個標準的多租戶SOA平臺。我們選擇的方法是開發細粒度的服務，以便我們能夠經常修改，並將便於管理的小變更部署到平臺。如果今天我們採用了同樣的方法，那麼我們會稱其為微服務架構。當時還沒有這個術語，但它就是有效。\

服務根據業務能力建模，初次釋出進展順利。這是些基於JMS的XML同步服務，主要用於為面向代理商、Web和語音通道應用程式的索賠平臺提供其所需的業務能力。它為我們提供了敏捷性，使我們可以頻繁部署小變更，使我們的應用程式可以完美支援A/B功能。\

當需求逐步增加（需求總是會增加）時，由於應用程式同消費者之間整合複雜度很高，所以難以實現方案的快速釋出。整合、功能測試、產品釋出需要緊密協作。隨著業務開始擴充套件，與初次釋出相比，變更多了10多倍，而且，由於交付週期中的大部分任務都是手工的，所以推向市場的時間無法達到企業預期。很快，糟糕的微服務自動化和生命週期管理導致了“交付熵（delivery entropy）”，我們的目標一個也實現不了了。\

經驗教訓——不要做這些事，而是……做其它事

\

這促使我想要分享一些經驗教訓，它們是我微服務之旅的一部分，希望你在踏上微服務旅途的時候能夠時刻留意這些事項。\

1）“內聚混亂（Cohesion Chaos）”

\

我們開發了一個服務，用於獲取客戶資訊。按照設計，該服務可以獲取客戶策略資訊、個人資料和他們報名參加的計劃。過了一段時間，該服務所做的事情開始超出獲取客戶資訊。隨著新需求的到來，這個服務經歷了頻繁的變更和部署。它已經無法擴充套件和滿足可用性要求，變成了眾所周知的“大泥球”。它是怎麼走到這一步的？首先，我們沒有針對功能上相互隔離的問題採取治理措施。如果一個有影響力的服務消費者要求將不相關的邏輯新增到這個服務中，理由是減少往返，那麼毫無疑問，那個功能就遭到了破壞。也許閘道器或BPM層可以避免這種情況的出現，但我們沒有時間那樣做……僅有匆匆構建另一個業務功能點的時間。\

預防措施是抑制與服務不相關的業務功能。服務必須清楚地與業務能力保持一致，不應該試圖做一些超出範圍的事。功能隔離問題對架構治理而言至關重要，否則，它會破壞敏捷性、效能和可擴充套件性，最後建立了一個鬆耦合的架構，導致交付熵和內聚混亂。\

2）不重視自動化

\

我們沒有服務自動部署和運維監控策略（執行時QoS指標）。這明顯增加了運維成本和人為部署錯誤。有幾次生產部署因為配置錯誤導致了當機。服務總是以HA模式部署，因此容器數量是全部服務總數的3倍。運維團隊無法人工處理每個服務的配置。一段時間之後，運維團隊開始抱怨架構低效，因為他們無法處理日益增加的容器數量。\

什麼疫苗能預防這種情況？處方包含多種材料。如果你還沒有這樣做的話，持續部署是一項必須的投資，也是每個企業都應該追求的一種文化變革。至少，如果沒有自動測試和部署方法，就不要使用微服務。微服務的目標是驅動敏捷，為我們提供所需的變更速度；質量保證需要每個服務都有自動的單元、功能、安全和效能測試。當我們開發的服務需要與不受我們控制的服務整合時，服務視覺化是另一個功能強大的概念。\

3）服務架構分層

\

對於SOA，人們常犯的一個錯誤是誤解了如何實現服務重用性。團隊主要關注技術層面的內聚，而不是功能相關的重用。例如，多個服務充當資料訪問層（ORM），將表暴露為服務；他們認為該服務有很高的重用性。這樣，他們就建立了一個由橫向團隊管理的人造物理層，導致交付依賴。建立的任何服務都應該是高度自治的——就是彼此獨立。\

建立多個技術上的服務物理層只會導致交付複雜、執行低效。最後，我們有包裝器服務、編排服務、業務服務和資料服務。這些服務模型均是服務於技術上關切的問題。每個服務層都會形成一個管理團隊，最終的結果是，業務邏輯無計劃的擴充套件，功能沒有單獨的所有者，效率低下，團隊之間總是相互指責。\

\

同一個服務內實現邏輯隔離很好，不過不應該有任何過程呼叫。盡力將每個服務視為一個原子業務實體，它必須實現與所需業務功能有關的一切。與分層服務相比，自包含的服務有更高的自治性和可擴充套件性。最好能重寫可以跨多個服務使用的公共程式碼，在保持一定的自治水平的前提下，這是一種很好的權衡。關鍵是不要根據技術上關切的問題隔離服務，一定要根據業務功能來隔離。容器化概念的興起就是因為這種特性。\

4）依賴客戶簽字

\

我們有一個供多個應用程式消費的服務，它有三種不同的消費通道，包括代理、Web和語音。代理通道是最根本的，因此，服務在進入生產環境前必須獲得他們的簽字。這會延遲語音和Web應用程式的生產釋出。是什麼將那三個通道緊緊地綁在了一起？\

當涉及到特定於通道的功能時，服務就不是鬆耦合了。要讓服務有獨立性。交付的每個服務都必須有一個測試套件，該套件應該涵蓋所有的服務功能、安全、效能、錯誤處理以及針對每一個現有消費者和未來消費者的消費驅動測試。這必須作為構建自動化迴歸測試通道的一部分。\

5）手動配置管理

\

當我們開始建立更多的服務（並且由於缺少服務生命週期治理而導致了無計劃的擴充套件），服務的配置管理失控了。大部分生產部署不順利的情況都是由於配置錯誤，如錯誤的密碼、URL和值。手動管理配置資訊越來越困難。要是我們將應用程式配置管理工具作為PaaS或CD的一部分……但我們沒有。\

（點選檢視大圖）\

\

6）未使用版本控制

\

我們天真地以為，一個服務只會需要一個版本。然後，為了適應多樣的消費者和頻繁的變更，我們開始增加大、小版本。最後，由於服務依賴客戶簽字，所以每個版本都不得不是個大版本。結果，容器數量增長得非常快，管理它們成了一個巨大的痛苦。缺少執行時治理是導致這個問題的另一個原因。部分企業愚蠢地試圖避免版本控制。如果變更不可避免，服務就需要有良好的架構設計。制定一種策略，管理向前相容的服務變更，使消費者可以輕鬆升級。否則，消費者會緊緊地繫結到一個服務版本，當服務變更時，就會破壞這種繫結關係。\

在微服務的世界裡，可以預見，複雜度會隨著服務數量的增加而增加。制定一個版本控制策略可以使消費者輕鬆遷移，並且服務提供者可以透明地部署變更而不影響其他任何人。限制生產環境中並行的大版本數量，並治理它們。\

（點選檢視大圖） \

\\

7）在每個服務中構建閘道器

\

我們沒有一個API閘道器，也沒有執行時治理（我們不知道誰在什麼時間以什麼速率消費什麼服務）。我們開始在每個服務中實現終端使用者身份驗證、限流、編排、轉換和路由等操作。這增加了每個服務的複雜度，而且失去了服務之間實現的一致性，導致我們不知道誰在哪裡實現了什麼功能。此外，我們構建的部分服務是為了滿足一個特定消費者的非功能需求，而不是其它消費者的。如果我們有一個閘道器，並運用一些資料過濾和增強模式，那原本是可以做到的。要真是這樣就好了。\

在API管理方案上投入精力，集中化部分非功能性問題的管理和監控，這同時也會減少消費者管理若干微服務配置的負擔。API閘道器可以編排跨功能的微服務，可以減少Web應用程式的請求往返次數。\

\

小結

\

微服務的目標是解決這三個最常見的問題，即提升客戶體驗、非常敏捷地響應新需求和以更細粒度的服務交付業務功能降低成本。微服務不是銀彈，它需要一個合乎經驗規律的平臺，使以敏捷方式交付高質量服務成為可能。從他人（我）的錯誤中吸取教訓，在架構設計和交付過程中避免上述模式。這是我們可以談論容器化、雲實施等之前的關鍵一步。我希望這篇文章能夠提供一些資訊，讓你可以針對自己的企業進行思考，爭取在將它們引入到你的架構之前解決這些反模式。上述各項大部分都會推動組織的文化變革，僅僅靠你自己是無法完成的，務必要同主管及高層領導合作。\

關於作者

\

Vijay Alagarasan是Asurion企業架構和策略部門的首席架構師。這是一家全球領先的技術支援和安全公司。他主要從事企業級服務、API和整合（A2A、B2B和B2C）。他定義並管理這些領域的原則、模式、技術選擇和標準。他通過制訂完整的解決方案或開發原型來提供參考實現，使交付組織可以比平時更快地學習新概念和技術。他還評估和引入新技術產品，使企業更快地實現戰略目標，並在市場中處於領先地位。他最初是一名Java/J2EE應用程式開發人員，然後是作為一名EAI開發人員，之後不久就成為了 SOA實施者/架構師。他的工作主要涉及TIBCO的產品、Java、Weblogic、JMS及一堆其它技術（LinkedIn使用者資料）。他能勝任多種角色，如軟體開發人員、團隊負責人、交付經理、整合架構師、解決方案架構師和領域架構師。近年來，他一直致力於Web API（像Layer 7、Apigee、AWS API Gateway、Azure API Management這樣的API管理工具）、雲技術（AWS、Azure）、容器、服務視覺化和圖資料庫等方面的工作。

檢視英文原文：Seven Microservices Anti-patterns