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

以下是任何架構(gòu)都遵循的三個標準和常見的業(yè)務驅(qū)動力：

·提高敏捷性——及時響應業(yè)務需求，促進企業(yè)發(fā)展

·提升用戶體驗——提升客戶體驗，減少客戶流失

·降低成本——降低增加產(chǎn)品、客戶或業(yè)務方案的成本

實際上，在日常工作中，所有人都試圖這樣做。SOA 創(chuàng)建了一種業(yè)務一致的軟件框架，使企業(yè)可以達成上述目標。已經(jīng)出現(xiàn)了幾家大型的軟件供應商，宣稱他們的產(chǎn)品套件可以推動企業(yè)實現(xiàn) SOA。

如果沒有合適的人員、文化和投入，那么 SOA 會無法實現(xiàn)業(yè)務價值。微服務同 SOA 并沒有根本的不同，它們的目標和目的是相同的，但微服務方法更精煉。事實上，簡單來說，微服務就是可擴展的 SOA。對于迫切需要由單體實現(xiàn)轉(zhuǎn)變成分布式、去中心化的服務平臺并為許多應用程序提供服務的應用程序 / 系統(tǒng)，微服務提供了這種可能。微服務是獨立的，它擁抱敏捷，并允許應用程序隨企業(yè)的數(shù)字化轉(zhuǎn)型進化。微服務的成功取決于服務獨立性和靈活度。

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

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

例子

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

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

當需求逐步增加（需求總是會增加）時，由于應用程序同消費者之間集成復雜度很高，所以難以實現(xiàn)方案的快速發(fā)布。集成、功能測試、產(chǎn)品發(fā)布需要緊密協(xié)作。隨著業(yè)務開始擴展，與初次發(fā)布相比，變更多了 10 多倍，而且，由于交付周期中的大部分任務都是手工的，所以推向市場的時間無法達到企業(yè)預期。很快，糟糕的微服務自動化和生命周期管理導致了“交付熵（delivery entropy）”，我們的目標一個也實現(xiàn)不了了。