關於微服務的發展方向，我們和5位專家聊了聊

微服務已經從少數幾個「獨角獸」公司的內部開發實踐變成了廣為人知的架構模式，很多開發者正在考慮是否採用微服務架構。很多人認為，為了從DevOps中獲得好處，採用微服務架構是必要的前提。

在過去幾年，我們見證了很多促進微服務成形的新技術，它們在與面向服務架構（SOA）尋求差異化的同時卻也鞏固了它們之間的關係。有些人認為，如果採用微服務的組織沒有做出相應的調整，那麼微服務技術和方法論可能不會起到太大作用。

InfoQ與五位專家從不同的角度針對微服務當前的狀況展開討論，預測了微服務的發展趨勢，專家們也分享了他們在微服務開發中獲得的各種經驗。

參與討論的專家：

• Chris Richardson —— 開發者和架構師，Java Champion，《POJO in Action》的作者

• James Lewis —— ThoughtWorks技術委員會成員

• Martijn Verburg —— jClarity的CEO和聯合創始人

• Christian Posta —— Red Hat首席架構師，《Microservices for Java Developers》的作者

• Adam Bien —— Java（SE/EE/FX）諮詢師和佈道者

InfoQ：我們關注微服務已經好多年了，從一開始到現在，我們從中學到了什麼？

Richardson：「微服務」是一個很糟糕的名字。它強調了服務的大小，導致開發人員創建了很多粒度很小的服務，每個服務擁有一個單獨的REST端點。不僅如此，這個名字還暗示了微服務在開發者心目中的重要位置。例如，人們會說「我們可以用微服務來解決這個問題」，我也看到了越來越多的「某某微服務框架」，而實際上，這些框架跟微服務架構不一定有太多聯繫，它們只是簡單的Web框架。

使用「微服務架構」這個名字會更恰當些。它是一種架構風格，它把一系列協作的服務組織成一個系統來支撐業務。

Lewis：我認為，微服務的大範圍採用造成了一定程度的語義折射。我和Martin Fowler對微服務進行了清晰的定義，微服務的特性可以幫助公司走向成功。我與很多大型公司進行過交流，他們想要採用微服務架構，他們接受了微服務的第一個特性，對服務進行組件化，但他們並沒有根據微服務的其它特性對組織結構做出相應調整，特別是對於產品、業務能力和去中心化的監管來說。我個人認為組織調整是成功實施微服務的關鍵因素。

Verburg：太多了！不過我挑幾個我最喜歡的：

• 服務發現 —— 不管是在開發時還是在運行時，服務發現比我們想象得要難得多。我經常看見整個團隊的開發人員在爭論「下一步應該把消息發到哪裡」。

• 分散式跟蹤 —— 我們很難通過簡單的方式完成對業務邏輯和事務的跟蹤。例如，如果一個業務邏輯需要經過十個以上的微服務，而且這些微服務使用了不同的技術，那麼該如何為此創建一條跟蹤信息？

• 分散式架構 —— 基於微服務的應用一般都是分散式的，需要橫向伸縮和負載均衡。傳統單體應用開發人員和系統管理員必須學習一系列新的技能。例如，如何對Websocket連接進行負載均衡？要知道，Websocket連接是雙向且「持久」的。

Posta：現在微服務的概念如日中天，我希望我們能夠弄明白一件事情，烏托邦式的架構是不存在，簡單地使用時髦技術並不等於微服務，而且組織的溝通結構與服務架構有著更深層次的關係，這個聯繫比我們先前意識到的要更加緊密。

還有一點很關鍵，在微服務架構里，我們應用了很多分散式的理論和實踐，它們都是我們從過去的40年經驗里學習而來的，多年來它們鮮有變化，我們只是用它們來解決新的業務問題。

Bien：我花了很多時間在Java EE項目上。在2009年推出的Java EE 6成為推進微服務架構發展的主力。在過去，我們把業務邏輯打包成WAR，不過Java EE 6打破了這條規則。在2009年，我們把我們的項目架構稱為「非共享式架構」，那時「微服務」這個名詞還沒有出現。

在當時，監控和壓力測試是一個艱難的任務。有了微服務，現在可以專註於壓力測試、系統測試，並對各種使用場景進行監控。在微服務之前，很多項目專註於使用單元測試來提高代碼覆蓋率。而這一切開始在發生變化。

早期Java EE 6項目和現在的項目之間存在的最大區別在於通信協議的不同。在2009，我們更多地依賴二進位RPC協議，而現在默認使用JAX-RS（REST/HTTP）和Websocket。

InfoQ：最開始是那些「獨角獸」在驅動微服務，你們認為現在還是這種情況嗎？如果不是，那麼誰是繼任者呢？

Richardson：是的。大部分關於微服務架構的大會似乎都是在談論「關於Netflix/Uber/Slack/Twitter……的微服務架構主題」。一方面，這些討論是很有意義的，而且促進了微服務架構的傳播。另一方面，這讓很多開發人員認為微服務架構是為了解決應用程序的伸縮性問題，但實際上，它解決的是複雜性問題。總的來說，能夠從主流公司聽到關於他們使用微服務的經驗是很有價值的。

Lewis：是的，我認為這些公司仍然處在不可取代的位置上。他們為微服務帶來了很多先進的東西。它不是一種「101」式的架構風格，當微服務架構被大規模使用時，你就能明顯地看到它的好處。

Verburg：他們還是的。BBC、Netflix、Twitter、Amazon這類公司都是基於微服務架構的，因為它們有橫向伸縮的需求。不過這也是大部分IT組織在盲目跟風時無法解決的一個主要問題。「我們真的需要微服務嗎？我們的規模需要使用微服務嗎？我們的業務需要微服務嗎？」對於很多組織來說，答案是否定的。

Posta：引用Branden Williams博士的一句話「再也不存在什麼獨角獸了，只有那些蹦向膠水工廠的純種馬……」那些互聯網公司已經向我們展示過這一點，不過我認為在傳統企業領域（FS、製造商、零售商，等等），還是有很多公司正在展示他們使用新技術快步前進的能力。

Bien：最開始沒有人知道「微」意味著什麼。關於服務大小的討論是沒有意義的。在Java EE里，一個微服務就是一個WAR包，它們通常由「單披薩」團隊創建（「雙披薩」的團隊規模太大了）。

在我看來，繼任者是那些基於微服務的企業項目。獨角獸來了又去，如果他們只是在剛開始獲得成功，那麼對於他們的成功就很難給予平價。企業項目會持續更長時間。

InfoQ：有些公司將微服務架構用於全新的應用開發，而有些則關注如何將單體應用遷移到微服務架構。對於這兩種情況，微服務的原則是否同時適用於架構師和開發人員？

Richardson：對於大型的複雜系統來說，不管是哪一種情況，微服務架構都是適用的。這要取決於實際的開發場景。例如，對於一個初創公司來說，他們還處在探索業務模型的階段，那麼應該更傾向於使用單體架構。

我認為大部分關鍵性的業務應用都是大型的複雜單體應用。這些業務無法快速演化，只能循序漸進地將其遷移到微服務架構。

Lewis：我參與過的團隊經歷過上述兩種開發場景。對於遷移開發來說，遷移到微服務通常是有好處的，因為它會給我們帶來更多的選擇，而且它們包含了之前系統的功能。對於全新的開發來說，就要考慮功能和跨功能需求，以及系統所運行的環境。有時候可以使用微服務架構，但有時候不是必需的。

Verburg：原則都是適用的，但會有一些折衷。完全分解一個單體應用是終極目標，但應用在它生命周期的大部分時間裡都會處於微服務和單體共存的狀態（有些人把這稱為怪物Cthulu的化身）。例如，微服務純化論者在對單體應用進行遷移時，他們會把原則撇在一邊，仍然會「通過存儲過程來傳遞消息」，直到他們把整個應用重構完畢。

這個時候集成測試變得很重要。

Posta：從它們對開發速度的影響來說，這些原則是相似的。你可能會有很多全新的開發項目，不過難點在於如何找到它們與現有系統的結合點，從而對其進行安全的擴展、加速和創新。

Bien： 2016年，大部分用戶對於引入微服務架構是抱著很大希望的，他們希望微服務能夠帶來更好的可維護性，並降低成本。微服務並不缺乏受眾，只是有太多人盲從，缺乏好的實現模式。

把一個超級複雜的單體分解成更加複雜的小型單體只會讓事情變得更糟。對於已有的項目來說，首先要避免盲從，並重新對領域概念進行分析。將一個精益的單體分解成獨立的單元完全是一件可有可無的事情。

對於新項目來說，首先要聚焦在業務邏輯上，在最開始的迭代中可以使用單體。只有在你對優缺點做過明確的了解之後才考慮引入微服務。畢竟交付一個精益的單體應用仍然是最為簡單的方案。

不管怎樣，新項目和已有項目都需要聚焦業務邏輯。

InfoQ：你們能列出關於微服務的5個要做和5個不要做的注意事項嗎？

Richardson：最重要的一點是要知道微服務並非銀彈。你需要仔細評估你的應用，並做出權衡。

Lewis：

要做的：

• 監控，監控，監控。

• 做好服務的獨立部署。

• 傾向於使用快速變更和canary部署而非集成測試。

• 傾向於編排而非編配。

• 對調用結構進行限制。系統的服務越多，就越難保證可用性。

不要做的：

• 不要一下子構建中500個服務，而是先構建合理數量的服務，最起碼當前的基礎設施能夠支撐得起。

• 不要把它們看成銀彈。要構建好微服務系統，你需要了解更多的分散式計算知識。

• 不要被廠商的萬靈油蒙蔽了雙眼，面向服務架構當初就是這麼死掉的。

• 不要忽略了可替換性。微服務要小到可以直接被替換掉。

• 不要使用分散式事務。

Verburg：

要做的：

• 確保你的團隊使用的是敏捷開發模式。

• 確保你的團隊具有DevOps文化。

• 在構建整個系統之前先構建3個互相交互的服務原型，找出實現非功能需求的解決方案，比如安全問題、服務發現、健康監控、回壓、失效備援，等等。

• 讓工程師為每個服務選擇合適的技術，這是微服務的一個主要優勢。關注集成測試。

不要做的：

• 不要因為Netflix使用了微服務你也跟著用。

• 忽略了數據一致性。「我們的微服務架構沒有ACID事務，讓你的金錢蒙受損失我們感到很抱歉」，這樣的情況是不能被接受的。

• 忽略了基礎設施需求，甚至忽略了開發者的開發環境。所以要儘快讓開發人員可以在一個模擬的生產環境里進行開發。

• 忽視了命名的重要性。一旦發布了公開的API，你就被牢牢地綁在一起了。另外，不要忘了為你的API添加版本管理。

• 拋棄多年的開發經驗和已經寫好的業務邏輯。要知道，微服務開發是一個演化的過程，不是重新發明輪子的過程。

Posta：

要做的：

• 對微服務架構的實施進行評審，並把它作為指南。微服務可以用于衡量團隊在不影響其他服務的情況下能夠以多快的速度做出變更和部署。可以關注一些指標，比如構建的次數、部署的次數、缺陷的個數、部署的審批時間、恢復服務的平均時間，等等。

• 為功能團隊建立反饋閉環。對系統或服務做出變更，卻不知道變更將會帶來怎樣的影響，這樣做一點好處都沒有。讓開發人員和功能團隊儘可能地接近用戶（或者站在用戶的角度），這樣他們就可以更直觀地感受他們的系統給用戶帶來的痛苦。

• 關注數據。數據是公司的生存之本。在構建微服務時，要注意用例邊界、事務邊界、一致性問題，以及數據的處理（數據流、數據存儲，等等）。

• 賦予微服務開發團隊自主權和自由，讓他們擔起職責。為他們提供自助的工具服務、API服務和基礎設施服務。

• 讓微服務儀錶化、可調試，並提供度量指標，把測試作為一等公民，而不是馬後炮。

不要做的：

• 不要簡單地複製獨角獸公司的模式，要找到他們成功的原理，並把這些原則作為指引。只是簡單地採用Netflix的技術不會讓你的公司也成為Netflix。

• 不要試圖通過微服務來降低成本，微服務能夠帶來創新和業務成果，但不能用來最小化運營成本，這個跟傳統的IT不一樣。

• 不要為了分解系統而分解系統。隨意分解系統可能會讓你的系統變成難以伸縮的分散式單體系統，事務處理會成為大難題。

• 不要忽略了分散式系統存在的陷阱以及在系統集成方面存在的挑戰。

• 如果在CI/CD、API、DevOps、自助平台、自助團隊等方面存在問題，那麼就不要強行使用微服務架構。在使用微服務架構前要先了解微服務的原則和最佳實踐。使用微服務本身不是目的，通過微服務打造具有創新能力且能夠快速行動的團隊才是目的。所以首先要打好實施微服務的基礎。

Bien：

要做的：

• 對容器部署技術進行評估。容器技術有很大優勢。

• 關注業務邏輯。

• 對關鍵用例或性能指標進行監控。

• 關注系統測試，而不是單元測試。

• 通過CI/CD進行自動化。

不要做的：

• 不要盲目複製Netflix、Twitter、Facebook或者Google的做法，除非你也有他們那樣的規模和需求。

• 不要忽視緩慢的部署過程。部署一個大的WAR包要比一個小包要花更多時間。效率很重要。

• 不要嘗試在微服務間協調事物。

• 不要在新項目里使用太多技術。少即是多。每一個依賴項都會拖慢部署速度，它們還需要額外的安全審計和缺陷修復工作。從來不存在「免費」的依賴項。

• 如果可以不使用分散式，精益的單體會是更好的選擇。

InfoQ：HTTP或REST/HTTP通常被認為是微服務事實上的通信標準，不過最近有很多組織在談論使用非同步或消息服務作為取代方案，你們是怎麼看待這個問題的？

Richardson：是的。HTTP/REST是目前主要的IPC通信協議。它為人們所熟知，使用起來很簡單。不足之處在於它在服務和客戶端之間引入了一定程度的耦合，這在某些情況下多多少少會成為一個問題。例如，在處理一個需要從多個服務獲取數據的請求時，就不會有問題，但如果這個請求是一個更新數據的操作，那麼就需要使用非同步的消息服務來實現事務的最終一致性，也就是sagas。

Lewis：對於我來說，微服務的端點問題不在於是否使用了REST/HTTP，而是微服務之間是否具有統一的介面。我曾經所在的一個團隊同時使用了輕量級的消息服務和RESTful框架來實現統一的介面，而且這兩種方式都很成功。解決問題的關鍵在於為問題選擇合適的模式。如果你的業務流程具有非同步特點，那麼就應該使用非同步的集成技術。反過來，如果你的問題可以使用map-reduce的模式來處理，那麼就應該使用反應式的方案。我們總是嘗試尋找簡約的方案來解決問題，這完全取決於你自己是怎麼想的。

Verburg：我認為，隨著時間推移，這兩種模式都會流行起來的。以jClarity為例，我們使用了非同步的消息服務，不過同時也為開放介面使用了REST/HTTP(S)。

Posta：在對微服務系統進行擴展時，它們會表現出類似其他複雜自適應系統的特徵（股票交易系統、蟻群系統、社區系統）：自治的代理、獨立的決策、反饋驅動的自我學習、非線性的迭代，等等。在這類系統里，事件、消息和時間戳讓它們看起來更像是一個「非同步」模型。時間戳成為這些系統的關注點（系統間的通信通道是不可靠的，這也是一個客觀存在的事實），我們必須事先處理好這些問題，並讓已知的模型在其它應用里得到擴展。

Bien：在我的項目里，HTTP/REST（一般是JAX-RS）已經足以應付大多數的使用場景。有時候我們也會使用Websocket進行非同步通信、P2P（peer-2-peer）交互和消息傳遞。這些場景更像是例外，而不是規則。

InfoQ：相比傳統的開發，微服務架構更偏向於分散式，對於一個微服務新手來說，他應該從哪裡開始入手？

Richardson：開發人員依然要使用很多他們熟悉的框架和軟體包來開發單獨的服務，這個跟過去相比沒有多大改變。不過，如果使用了微服務架構，事務管理和查詢操作需要用不同的方式來處理。可以參考我最近發表的InfoQ文章和我的網站來了解這方面的問題以及如何解決它們。

微服務架構的核心是為業務能力和業務子領域組織微服務。我推薦閱讀Eric Evan的《Domain Driven Design》這本書，他的設計策略都是以微服務架構為中心的。

Lewis：我認為Sam Newman的《Building Microservices》是一本很好的書，我會從這本書讀起。如果要了解微服務的背景，我推薦閱讀Eric Evans的《Domain Driven Design》，還有Webber、Robinson和Parastatidis合著的《REST in Practice》、Hohpe和Woolf合著的《Enterprice Integration Patterns》，以及Michael Nygard的《Release It！》。關於構建組合系統背後的哲學，我極力推薦Eric Raymond的《The Art of UNIX Programming》。在Martin Fowler的網站上可以找到更多相關資源。

Verburg：對於從傳統Java企業開發轉到微服務開發的新手來說，microprofile.io社區是一個很好的地方。不管他們從什麼地方開始入手，他們必須知道該如何建立基礎設施。可以租用一些Linux主機（或者使用Docker），並構建一個「hello world」服務，這個服務與另一個「機器」上的「Hi Back！」服務進行交談。在這個過程中，你需要使用到HTTP(S)、認證、負載均衡、IP tables、分散式數據存儲引擎（比如MongoDB）等等。

在微服務架構里，應用程序代碼是最簡單的部分，難點在於系統工程。

Posta：這是一個很好的問題。過去40年關於分散式系統的研究和實踐是實現微服務架構的核心基礎。認識ACID資料庫對你的重要程度，了解在採用分散式時所要面臨的挑戰，這是首要的任務。有很多這方面的論文可以參考，Jim Gray、Peter Bailis、Alan Fekete、Pat Helland、Leslie Lamport，他們的論文我都很喜歡。我主攻系統集成和消息服務，不過這些論文加固了我對基礎概念的理解。

Bien：關注領域概念、目標領域和用戶。舉個例子，最好的Java EE項目只包含業務邏輯，這些業務邏輯只有少量的註解，沒有多餘的雜七雜八的東西、模式或間接依賴。

忘記以往的模塊化概念，讓代碼保持簡潔，小型化的WAR就是最好的模塊。

總是假設微服務的基礎設施會發生故障，並針對故障場景進行測試，提供最簡單的解決方案（在類級別，而不是框架級別）。

InfoQ：是否有一些開發語言或技術可以推薦用於開發微服務？如果有，為什麼？是否有一些是需要避免使用的？如果有，又是為什麼呢？

Richardson：簡而言之，微服務架構是獨立於開發語言和框架的。不過有些經典的框架是基於某些語言開發的，這些框架可以用於構建分散式的應用。例如，Java開發者可以在Spring Cloud里使用Eureka/Ribbon來實現客戶端的服務發現，也可以使用Hystrix的迴路斷路器。另外，也有人建議使用一些能夠提供服務端發現的部署平台，這樣開發者就不需要關注服務發現細節了。

Lewis：過去幾年，人們更關注簡單的事物，這是個好現象。我喜歡談論Java的生態系統，那麼就從Dropwizard和Spring Boot開始吧。我特別喜歡Dropwizard的設計思想，我記得關於它的宣傳詞是「一系列不那麼糟糕的軟體包」，相比那些重型框架，或許這些才是你需要的東西。在生態系統之外，我知道有很多團隊在使用Go和Elixir，他們也很成功。不過我不能對JavaScript生態系統做任何評論，因為我對它並不了解。

Verburg：

• microprofile.io、Vert.x、Spring Boot、JHipster對Java開發者來說都是很好的資源。在jClarity，我們使用了Vert.x，它是一種基於JVM的混合型語言，非常適合用於開發微服務，我極力推薦。

• Scala開發者可以使用Akka。

• JavaScript開發者可以使用NodeJS。

Posta：使用合適的東西可以幫助你走得更快。在我看來，Go、Java、.NET、NodeJS是最為常用的微服務開發語言。

在企業里，如果你需要將Java服務模塊化，可以使用一些技術，比如Linux容器和像Dropwizard這樣的「微框架」、WildFly Swarm和Spring Boot。如果要使用基於領域驅動的事件框架，那麼像Vert.x這樣的反應式框架是個不錯的選擇。其它的跟平台和應用相關的雲服務技術，比如Kubernetes、Hystrix和Envoy可以用於解決複雜的分散式系統問題。

Bien： Java已經誕生20多年了，它是一門成熟的開發語言，具有強大的工具和監控能力。Java在一開始就融入了微服務概念，比如Jini/JXTA框架，它們與No-SQL資料庫（比如JavaSpaces）混在一起。可以說，Java超前了15年，那個時候市場還沒有做好使用這些技術的準備。不過，從1999年以來的那些技術在今天仍然適用。我們並沒有重新發明輪子。

我經常會建議將Java EE的應用伺服器（Payara、TomEE和Wildfly）作為初創項目的微服務平台。在最初的業務邏輯探索階段，我們沒有必要把時間浪費在這些事情上。在一開始我們要十分注重效率。開發人員會對現代應用伺服器的開發效率、內存使用和內建特性感到驚訝。Java SE/EE內建的功能可以完成很多事情，這要超出開發人員的想象。目前我只看到正向的反饋。

Docker是另一個關鍵因素。Docker結合Java EE是最理想的組合。

InfoQ：你們認為2年之後微服務會有怎樣的發展？

Richardson：誰知道呢？早在2012年4月，我做了一場關於當時微服務架構情況的演講。到目前為止，微服務架構的核心概念並沒有發生改變。不過我見證了技術上的巨大變化：比如Docker和AWS Lambda的崛起。所以，我們很難對此做出預言。不過話雖如此，我仍然希望微服務架構能夠順著Gartner的發展曲線一路進入平穩狀態。

Lewis：我認為，將來有些公司會因此大賺一筆，而有些公司則在嘗試了微服務之後仍然不明白其深層的意義，並給自己招來大麻煩。我希望能夠出現一些很酷的工具，用於服務可視化、請求消息跟蹤和更智能的故障檢測。那樣的話就太棒了！

Verburg：從趨勢周期來看，曲線會先到達頂峰，然後再跌入谷底。有部分組織會沿著斜坡前進。

Posta：如果你不介意，我想重新組織一下你的問題：假設給微服務2年時間，那麼它是否可以達到給面向服務架構4年時間所達到的相同狀態？答案是肯定的。

不同之處在於，互聯網公司和初創企業把技術作為抗擊傳統企業的主要武器（遊戲規則已經發生了變化）。至於技術趨勢，它跟面向服務架構不會有太多的不同。只是那些沒有採用DevOps、敏捷和微服務的公司會落後於那些採用了這些技術的公司。

Bien：有個開發者在一個Java User Group會議上自豪地聲稱：「我的團隊只有4個人，但我們交付了35個微服務」。還有個諮詢顧問向我演示了他如何在筆記本上運行70個JVM實例。

我的問題是：「你們為什麼要這麼做？這樣做給你們的服務帶來什麼好處了嗎？」

我期望看到第一批言過其實的微服務項目會比預想的需要耗費更高的成本。這些項目在一開始成為一些文章或大會的談資，但卻降低了開發者的效率。

糟糕的大會把事情引向了另一個極端。我不知道以後會不會出現Macroservice或者Nanoservice。不過我可以肯定的是，它們只是新瓶裝舊酒。

在這個虛擬研討會裡，我們了解了微服務當前的狀態、微服務的最佳實踐和一些關於微服務在未來幾年發展情況的預言。我們從這些專家那裡得到了關於如何成功實施微服務的各種技術建議，不過我們也要意識到，微服務架構是一種分散式系統，過去幾十年的理論和實踐經驗深藏其中，等待開發者去發現。我們還了解了專家們關於將REST/HTTP作為微服務通信手段的看法，並將其與非同步和消息服務進行了對比。

34 歲華為技術員工的裁員風波；深圳的工程師在買房買車生娃的結點上突然告知被裁；創業公司在資金困難時找相對高薪的程序員開刀.....工作數年的技術該怎麼走出這個囚徒困境？斯達克學院 StuQ ，特別邀請擁有 15 年軟體行業從業經驗的什馬金融CTO汪曉明，給我們做知乎Live分享。他將結合自己的實際經歷，引入「技術半衰期」和「資源穩定度」兩個概念，幫助大家建立思考框架，瞄準自己的目標，不再彷徨，不再浪費時光。