草根開發群體的大力支持正在將微服務架構的采用率推到新的高度。據紅帽公司中間件專家Mark Little博士聲稱，微服務是個好東西，卻不是世界和平的答案。
紅帽公司中間件部門工程副總裁Mark Little博士：采用微服務并不意味著你那架構差強的泥球突然變得架構很好。
鑒于微服務的人氣扶搖直上，那些記性不好的人可能忽略了這種方法極其類似面向服務的架構(SOA)，20年前SOA第一次出現在世人眼前。
不過紅帽公司中間件部門工程副總裁Mark Little博士喜歡將微服務看成面向服務的架構中的精華部分，它得益于出現了更先進的工程和運維技術及技巧。
Little說：“區別就在于，推動它的主要是開發軟件和分布式軟件領域的新方法。Linux容器等技術――Docker就是個典例。你現在有了不變的服務，有了Kuberneters之類用于協調那些服務的技術――很顯然，你有了開發運維(DevOps)，而開發運維受到敏捷開發理念的重大影響。”
“那些技術讓人們真正回顧我們在過去開發分布式系統的方法，面向服務的架構就是這方面的一個例子，并挑選與那些技術相匹配的精華部分。或者反之亦然，找到與面向服務的架構的一些精華部分相匹配的那些技術。這可能就是區別所在。架構方法并非不一樣，但是其背后的技術確實不一樣。”
在微服務架構中，應用程序組裝成一組小小的半自主式進程，這些進程執行特定的任務，并使用API彼此進行聯系。微服務旨在易于使用、靈活擴展，在Web應用程序、移動應用程序和物聯網應用程序中日益嶄露頭角。
在面向服務的架構的以往不足中，Little提到了一個不足：無法在客戶機和服務之間提供很好的契約定義，他還提到了Web服務描述語言(WSDL)的不足，這種語言對松散耦合、分布式的系統而言差強人意。
然而，就因為許多因素和技術融合到一起，讓微服務成為當下風光無限的架構，并不能保證它就能一帆風順。
Little說：“認識到微服務不是世界和平的答案，這一點很重要。它對一些任務來說很好。但是它跟任何技術一樣，也有缺點。就因為你采用了微服務，并不突然意味著你那架構差勁的泥球(ball of mud)突然架構變得很好，不再是泥球。它有可能變成了好多分布式泥球。”
“這讓我有點擔憂。我長期以來就在關注面向服務的架構，知道優點和缺點。我喜歡微服務，因為它讓我們得以關注優點，但是人們以為它能解決根本就解決不了的許多問題，這確實讓我擔心。”
如果你正在考慮微服務，最好從良好的軟件工程實踐開始入手。
Little說：“從根本上來說，這正是面向服務的架構背后的思想。如果你不從那方面開始入手，無論你使用Docker、虛擬化、Java虛擬機還是使用其他什么都不重要，合適的工具不會為你解決架構問題。”
微架構或者甚至面向服務的架構真正發揮所長的地方在于，應彼此獨立部署的邏輯服務，這些邏輯服務可以獨立于其他服務進行擴展，而且能夠實現獨立的故障切換。
Little說：“我在微服務方面擔心的問題之一就是，你有一個整體式系統(monolith)，假設你開始把它分解成多個服務，可是分解時很隨意，到頭來就會分解得過細，最后會有10個、100個甚至1000個微服務。”
“但是這些微服務又彼此高度依賴，以至于如果某一個服務出現故障，其余服務很有可能也會出現故障。這種情況下，你一無所獲。你有999個服務就在那里干等著另一個服務恢復正常運行。”
據Little聲稱，那些開始使用微服務的人應該找出未能實現其功能的軟件，而不是就因為使用年限而把那些舊軟件挑出來。
[page]他說：“找出對你來說確實沒有發揮功能的軟件――我強調的是沒有發揮功能的那個組件，因為你如今可能擁有在過去30年一直順暢運行的整體式系統，而且全年365天很順利地處理你交給它處理的負載。”
“在這種情況下，把整體式系統分解成微服務可能不會給你帶來多大的好處。但是你可能會有完全相反的整體式系統：來來去去的不同團隊長年累月構建了某套系統，你只好不斷給它打補丁。”
“該系統甚至可能很不可靠，用許多不同的語言來實施，你在考慮無論如何要重新實施它。這種情況下，就很適合使用微服務。”
除了深入了解應用程序的功能、它在哪里沒有實現功能外，還要明白它里面的哪些組件可以分解成微服務，但切忌過猶不及。
Little說：“你不應該把它分解成太小的微服務。有些人甚至在談論納米服務(nano service)，那未免也太過了。別這么做。明白你將如何衡量成功，這通常很重要，對微服務來說尤為重要。”
即使在軟件沒有發揮功能的情況下，也要避免從頭開始重新實施一切，因為有些部分可以保留下來。
Little說：“如果你擁有的軟件沒有發揮功能，仍應該看看有些部分能不能保留下來――要是軟件部署已有二十三年，好多人在使用它，更是要有所保留，要是它是用COBOL實施的，更是要有所保留，這表明它久經考驗。”
“比如說，由于你在圣誕節那天的請求規模比30年前多出幾個數量級，軟件如今對你來說可能沒發揮功能。但是這并不意味著那些COBOL代碼中就沒有一些基礎的部分可以拿來重復使用。應該可以重復使用，因為就算軟件錯誤出現在新的系統中，你也希望它們是新的軟件錯誤。你不希望重新引入已加以解決的舊軟件錯誤。”
所以，有的操作系統(unit of work)可以獨立于其他一切而部署;它們可能會出故障，但不會引起應用程序的其余部分陷入停頓;還可以獨立于其他一切進行擴展，找出了這種操作單元后，下一步就是考慮你可以對它定義什么樣的契約。
Little說：“該契約將包括其接口：我如何遠程調用它，我用什么來遠程調用它?許多人談論微服務和代表狀態傳輸協議(REST);REST對微服務來說絕對是一種根本方法。但是它未必就是你想與服務進行聯系的唯一方法。”
“你可能想使用一種二進制協議與服務進行聯系。可能除了使用一些老式協議與它進行聯系外，你別無選擇。如果是COBOL，盡管你改用微服務，你的架構中可能仍有相當多一部分仍與公共對象請求代理架構(CORBA)緊密相關。它可能不是與你的微服務進行聯系的獨家方式，但是你可能得在某個地方要有CORBA適配件。”
之后是典型的分布式系統問題，因為一旦你開始創建可獨立擴展的微服務，通過HTTP或二進制協議的遠程交互其速度將不如內存中的過程調用。
Little說：“所以你要擔心調用遠程服務意味著什么，如果你在響應時間方面有嚴格要求，更要擔心了。越是將這些東西分解成服務，無論它們是宏服務、微服務還是納米服務，你越要開始擔心：我是在分布式環境中運行。這對我來說意味著什么?我的應用程序實際上忍受得了嗎?”
“因為我可能確實需要微服務，可是很遺憾，除非有人發明一種網絡使用超光速粒子來傳輸信息，否則我其實無法調用任何東西，因為我從來無法履行我的契約義務。我的一切都在大泥球里面。”
原文標題：Microservices 101: The good, the bad and the ugly
京公網安備 11010502049343號