微服務的未來：功能性服務設計和可觀測性

為了準備將于柏林舉行的第16屆和第17屆 microXchg 會議，InfoQ與 Uwe Friedrichsen 和 Adrian Cole 一同討論了功能性服務設計（functional service design）和對于監測分布式系統的新挑戰，以及未來微服務架構的類型應該是怎樣的。

同Uwe Friedrichsen（codecentric的CEO）和Adrian Cole（Pivotal的軟件工程師）談話的關鍵信息總結如下：

• 和微服務相關的關鍵理念，一個是支持獨立性的特性，支持應用生態中另外部分的獨立性，另一個是支持快速演化的特性。這些是經常被實現者們所忽略的。
• 監測系統和記錄系統應該以反映當前軟件架構的方式進行演化，同時這會產生技術上和認知上的影響。
• 在傳統的軟件工程教育中學到的如何進行功能劃分的許多東西（比如“不要寫重復的代碼”）在分布式系統中是不適用的，例如微服務。
• “微服務”這個術語本身可能會在將來出現，但是功能分解的新架構形式已經被大家所接收。
• 使已經成為商品的事物標準化是很有價值的，然而分裂化、缺乏公平和缺少交互性會引起終端用戶價值損失。

采訪的全部內容如下所示：

InfoQ：Uwe，當前的各個組織機構實現微服務遇到的最有挑戰性的問題是什么呢？

Friedrichsen：是他們在一開始就在做微服務。

“微服務”成為了流行的、主流的術語，在使用 Spring Boot 的人或者使用類似Spring Boot的人都聲稱他們在做微服務。不過，別曲解我的意思：Spring Boot沒有任何問題，但是寫一個獨立的、暴露了幾個HTTP接口的應用并不意味著你在做微服務。

和微服務相關的關鍵理念一個是支持獨立性的特性，支持應用生態中另外部分的獨立性，另一個是支持快速演化的特性。不幸的是，就我的觀察而言，大家并沒有在這些定義了微服務的特性上花很大的功夫。

微服務是一種能幫你快速演化的架構類型。如果你的公司在一個發展非常快的市場中，如果你的業務需要信息技術的支持才能快速發展，你就必須要在信息技術領域快速進步、演化。但是，即便如此，不僅僅是架構類型需要像信息技術一樣快速演化，還有許多東西也需要像信息技術一樣快速發展。

像微服務目前這樣的炒作趨勢存在的問題是，即使微服務不能充分解決他們的問題，他們也會使用微服務。如果你并不需要更快的信息技術，那么你可能并不需要微服務。你可以繼續使用Spring Boot（這很有趣），但是你不應該把它稱為“微服務”。

InfoQ：Adrian，談到快速演化（并不是說拔苗助長），有多少傳統的系統監測方法在演化，對分布式應用提供有價值的監測？

Cole：監測系統和記錄系統應該以反映當前軟件架構的方式進行演化，或者以反映他們正在實踐的架構的方式進行演化。例如，從一個更小的范圍來看，從微服務到各個功能都會產生技術上和認知上的影響。例如，如果可視化和交付的度量指標不能捕獲到短期的管理函數，這就是有問題的。

我們也必須強調認知負擔。例如，我們向發送錯誤報告的操作中添加分布式的交易上下文，然后用更多的上下文不斷堆積，再進行進一步解釋。這是一個困難的任務，因為演化需要針對系統或者認知負擔進行平衡。

InfoQ：我們已經聽Uwe談了關于像Spring Boot（和go-micro，Seneca.js）這些“微服務”架構的使用；在一個現代的開發環境中實現可觀測性容易嗎？

Cole：正因如此，我正在microxchg上做一個關于 Zipkin 分布式監測的訪談，其中會談到一點有關Java和Spring Boot的內容。添加“sleuth”是很容易的，“sleuth”是Spring Boot上的一款分布式監測插件，是由 Marcin Grzejszczak 帶頭實現的。使用 start.spring.io ，你只需要通過字面意思，點擊像Zipkin這樣的文字就能得到一個不錯的結果。從我所看到的已發布博客來判斷，我認為大家都覺得這已經足夠簡單了。

在golang中，我沒有聽到太多關于“微”和“監測”這樣的字眼，但是 Peter Bourgon 的 go-kit 工具包通過實現了一個叫OpenTracing項目的類庫接口，提供了對監測的支持。文檔中提到 appdash 和Zipkin是開箱即用的。后者由Bas van Beek進一步確保可用性，Bas van Beek是Zipkin的golang常駐支持者。

InfoQ：Uwe，現在演化這個詞對于開發模式也有很大幫助，你能推薦一種激勵開發者和架構師考慮功能性服務設計的技術嗎？

Friedrichsen：如果我知道這種技術的話，我會把它賣掉，換很多錢，變成富翁...但是，老實地說，我發現了三個因素，這三個因素在某種程度上影響了開發者們和架構師們需要考慮到的功能性服務設計：

1. 這是一件很難、非常難的事情，甚至對于40年以后的軟件架構師來說也很難，這是一種很難理解的設計。

   很多人后來談到了 DDD（領域驅動設計 Domain Driven Design） ，DDD確實是一個很好的出發點。然而，僅僅知道這個模式完全不同于你將這個模式應用到你的當前業務問題中，尤其是當你的產品經理或產品負責人成天坐在你旁邊，一直催促你要“更高效”。

   同時，我們在軟件工程教育中所學到的如何進行功能劃分的知識，例如，功能分解，DRY（不要寫重復的代碼 Don't Repeat Yourself），或者是創建可重用功能，這些對于像微服務這種分布式系統來說是不可用的。如果你使用這些所謂的設計最佳實踐，你最終會得到一個很糟糕的設計，會讓你對它的效率困擾不已。我們基本上要重新學習對于分布式系統的設計和基于個人定制的監控系統的設計，我們仍然需要學習許多東西，學習怎樣才能正確實現它。

2. 真正的問題是，信息技術的發展受到了許多更具誘惑力的、曇花一現的技術的阻礙。

   新的框架、新的編程語言、無窮無盡的辯論，該怎么做這個，該怎么做那個，還有一群固執己見的人告訴你說，如果你不這樣做、不那樣做，你就是錯的。我們被各種新鮮的事物和觀點淹沒。你去參加一場會議，你去讀一本IT雜志，或者去看看你的推特上的時間線，你就會明白我說的是什么意思。所有的這些都比學習如何設計一個更好的系統有趣得多。

3. 我們每五年就會丟掉我們的共同記憶（collective memory）。

   據我的觀察，我們大約每五年就會迎來一批新的來自大學（或者來自其它地方）的開發者。從另一個角度來看，這意味著我們每五年就會丟掉我們的共同記憶。這些人沒有看過幾年前開拓你眼界的那些訪談和文章。他們需要從頭重新學習，向從前那些開拓信息技術的所有人學習。

   使得情況更糟糕的是像功能設計這種“永恒的”話題。在信息技術中，“新的”被認為是“有價值的”，“舊的”就被認為是“無價值的”。我們正在一個快速發展的商業社會中，不是嗎？五年以前、十年以前、甚至二十年以前的舊知識還有哪些價值？即便有人意識到不是所有的舊的知識都是無價值的，我們也要一遍一遍的重述然后再忽略這些知識，每年加入IT行業的新開發者們大部分都沒有聽說過這些知識。

InfoQ：你談到了IT工業中的人們都在快速改變：微服務架構類型的未來是什么？

Friedrichsen：坦白地說：我不知道。“微服務”這個詞語最終可能會像所有被大肆宣傳的那些詞一樣爆發，尤其在一些人開始用之后，像那些大多數的供銷商、咨詢師，和那些想要用一些很新、很酷的詞包裝自己的那些人。另一方面，這個架構類型是沒有變的。事實上，當我們開始稱它為“微服務”時，它就不是什么新鮮的事物了，它已經存在了許多年。它只是由于信息技術的進步而進行升級了，然后被稱為“微服務”。并且有可能在下次更新換代之后，它又有了其它的什么新的名字。

在不遠的將來，我們可能會看到微服務類型的分化。并不是所有人都需要一個“純凈”微服務的所有特性。一些人可能僅僅需要微服務特性的一個子集，僅僅為了滿足他們當前問題的需求。

但是，在最后，我坦率地說，我不知道。

InfoQ：在最后，Adrian，談到微服務類型的未來，你對這個領域開放的標準是怎么看的呢，對于建立一個管理這些的組織/基金會你又怎么看呢？

Cole：這個問題是最難回答的！在實踐中，我們對開放（Open）和標準（Standard）這兩個詞的使用是非常寬泛的，所以這個問題是很難回答的。例如，有許多小工作團體都用開放這個詞來修飾各種事物，每一個修飾都有著不同的標準，不同的對于開放的定義以及不同的開放的程度。同樣也有標準說，不要把開放這個詞用到它們身上去，還有一些標準的開放程度似乎與像 IETF 這樣的正式團體相媲美。例如，我對提出reactive streams標準的工作組印象深刻，并且如果你去看看他們的網站，你會發現提到開放這個詞的地方只有“開放一個問題（Open an issue）”。

回到重點，使已經成為商品的事物標準化是很有價值的，然而分裂化、缺乏公平和缺少交互性會引起終端用戶價值損失。各種基金會和組織有助于創造標準，因為，嚴格來說，標準是需要長期不斷更新變化的。這并不意味著標準不能從不周全的計劃開始，也不意味著標準不能在必要的時候從計劃不周過渡到正式，更不意味著一個一開始不周全的標準不會成功。這僅僅是我的拙見...

來自：http://www.infoq.com/cn/news/2017/02/microservices-design-observe