咱們如何衡量一個微服務實施的成功

4 月在深圳的 GOPS 大會上我分享了「落地微服務的難點和如何高效落地微服務」，這是我 2017 年 4 月份開始作的項目總結，後來發表到了本身的博客和" ThoughtWorks 洞見" 上。

本次介紹的案例來自於我 2013 年剛加入 ThoughtWorks 所服務的客戶 R，到今天已經5年整了。2013年的國慶後，我加入了客戶 R 的其中一個產品團隊，這個團隊有三個項目：一個項目作平常維護工做（BAU），這是一個長期項目。一個項目開發一些新的功能。另一個項目就是將現有的 Java 遺留系統進行改造，把這個 Java 應用的一部分功能從 ESB 和內部調用的方式改爲用 Sinatra (Ruby 的一個 Restful API 框架) 作的 HTTP 外部調用。

當時我還不知道咱們作的東西就是微服務，只是以爲經過自動化測試和持續交付的方式把應用進行了低風險的解耦。下降了系統的複雜性，減小了須要維護代碼，也使得在這個代碼庫上工做的其它團隊不受阻礙。同時減小了生產環境的故障和發佈風險。

我在這個項目上工做了 8 個月，完成了「一塊功能」的拆分。當時咱們並無一個獨立的 Ops 團隊，全部的運維相關工做都是團隊內本身完成的，那時候咱們也不區分開發、測試、運維。只是不一樣的人去認領不一樣的任務，不會的就現學現用，或者請教Ops 團隊。這就是我最先接觸的 DevOps ：一個全功能的端到端產品團隊。

在 2014 年的時候咱們採用 Docker 進行部署，Docker 在當時是個很新穎的東西，因此互聯網上相關的材料並很少。因而咱們就本身寫了一些編排工具來作 Docker 的大規模部署。同一時期，咱們接觸到了契約測試，並把契約測試應用於咱們的微服務上面。並開始使用 Scala 和 Play 框架拆分另外的應用。經過契約測試，咱們會把串行的集成測試轉化爲一些單元測試。因爲契約的約束，使得集成測試降級成爲了單元測試，大大提高了測試的效率，下降了測試的成本。

你會在各類微服務的書和相關實踐中都能看到 Pact 這個工具，這是客戶 R 的另一個顧問公司開發的，也是他們定義了什麼叫契約測試。到了2014年末咱們把幾個接口拆分出來以後，我才知道這是微服務，也理解了什麼是 DevOps。

2014 年 11月份我離開了這個團隊，開始把在這個團隊上的經驗推廣給不一樣的客戶，才慢慢深刻了解了 DevOps 和微服務的概念。同時，客戶 R 也開始複製咱們以前的成功經驗，開始在整個集團內部進行了全面的微服務化改造。

2017 年 4 月份我從新回到這個客戶的項目上工做到 2018 年的 9 月份，期間和其它作微服務的團隊進行了一些訪談，能夠從比較直觀的角度來觀察這 5 年來微服務改進的效果和經驗。

本系列共計 4 篇，分別是《咱們如何衡量一個微服務實施的成功》，《成功微服務實施的組織演進》，《成功微服務實施的技術技術演進》，《微服務架構演進中的經驗和反思》。本場 Chat 是第一篇《咱們如何衡量一個微服務實施的成功》，因爲保密的緣由，具體的客戶、項目、人員名稱均爲化名。

應用系統的架構的維護成本是如何增加的

咱們採用架構的規模（能夠用功能數量或者代碼行數來衡量），以及投入的維護成本（人員、資金、時間）來構建一個座標。就能夠作出一個簡單的對比：

架構規模以及維護成本

在一開始（O點），單體應用的構建成本是相對低廉的，由於並不須要作分佈式。而一開始就作微服務的架構，勢必會由於分佈式的複雜性而產生額外的成本（O1點）。

隨着應用規模的增加，相應的規模就會有相應的維護成本。隨着這個規模的上漲，勢必會迎來一個 X 點。使得單體應用和微服務應用的維護成本一致。這也說明在這一點以前，單體應用的優點十分突出。

從架構模型上看，單體應用的規模和維護成本是指數上升的，由於規模所帶來的依賴使得風險不斷匯聚，致使交付速度下降，部署風險增大。所以，它的維護成本以指數形式增加。然而微服務應用是由多個簡單系統組合而成，它的依賴程度較低，單獨的交付效率和部署風險可控，所以，他的維護成本以對數形式增加。

因爲微服務的這種特性，當兩種應用架構的規模超過X點以後，它們的維護成本則相去甚遠，勢必會迎來一個維護成本的極限 X' 點，從而約束了應用規模的極限。

而在這個狀況下，就是大多數企業轉型微服務的驅動力：原先的應用增加模式沒法應對規模的增加。

因此，咱們能夠看到，大多數的企業是從 O 點出發，沿着紅線走到 X' 點，而後開始進行微服務的改造。以換取應用的增加規模。

而一開始作微服務架構的應用，雖然在開始的階段投入了更多的成本，但換取的是將來更大的規模。不過，從精益的角度看，這是一種浪費，除非你的目標就定位了一個大規模的應用。這在大多數應用系統最初創建的時候都是不可能預期的。

因此，一條理想的模型是從 O點出發，到達 X 點以後進行微服務改造。

然而，這根本不可能實現，緣由有兩點：

1. 人們不會同時構建兩個同樣的應用來作比較，從而找到增加極限。
2. 目前，也不會構建一個度量指標，來度量維護成本和應用規模。

因此，你所處的階段，應該是 X 到 X' 之間的某一點，你開始採用 DevOps 技術來縮短研發週期，提高交付質量，也開始度量應用的交付狀態。這就須要咱們構建一個指標來度量架構，這就是：邊際功能收益率（MSROI，Margin Scale Return on Investment ），也就是我建立一個新的功能，它在將來一段時期所消耗成本（人力、時間、資源）所帶來的回報（下降成本，下降風險，增長收益等）。若是這個收益率持續下降，且是由於成本在不斷增長，你就須要考慮是否是下降應用維護的成本了。

應用架構的局部性原理

事實上，一個正在運行的系統，維護過程會有兩個局部性原理。我把它稱爲應用系統的 DevOps 局部性原理假設，它包含 Dev 和 Ops 的兩個局部性假設。分別是：

開發局部性假設：在運行着的應用系統中，維護所作的工做是對應用系統的局部進行開發。所以，對整個開發團隊應該只產生局部性的影響。

運維局部性假設：在運行着的應用系統中，因爲局部的變動，應該只產生局部性的風險和影響。

以上兩個假設有一個約束：因爲局部性的開發致使的綜合成本。均小於替換整個系統的總體成本。

也就是說，你所構建的局部性是要小於你原先系統規模的，不然你就是實現了一個新的系統。

但咱們所經歷的事實是相反的：一個局部性的變動須要依賴不少其它的開發團隊和人員，並在應用系統中產生連鎖規模的影響。

因此，若是你的應用系統是微服務的架構，就會符合上述的微服務 DevOps 假說並經過微服務的 DevOps局部性測試：

任意應用的局部變動均產生局部性的影響。

爲了下降系統風險，咱們須要將應用的變動風險隔離出來。所以，就有了微服務架構的 DevOps 推論：

運行時的維護關注點局部性使得獨立開發的局部性成爲可能。

也就是說，在應用運行架構風險隔離的狀況下，纔可能出現獨立開發和獨立部署。而本質上，單體應用到微服務應用的轉型就是應用的內部的高風險依賴轉化爲外部的低風險依賴的過程。是內部複雜度向外部複雜度的轉換。所以，微服務架構改造所花費的成本大部分都在處理服務間的通訊。

應用系統的 DevOps 局部性原理假設的角度看，微服務本質上的目標和 DevOps 的目標是一致的。這也符合我此前作微服務的落地經驗：當應用程序的部署時間和變動風險在單一應用上作到極致以後。咱們能夠考慮對應用進行拆分以進一步實踐 DevOps。

也就是說，微服務架構是組織 DevOps 不斷深刻和優化的結果。

咱們如何衡量一個微服務的轉型效果

咱們作微服務的主要訴求就是但願系統規模在增加的同時，管理成本下降。也就是應用結構和組織結構知足上述的假設。這個管理成本包括兩個方面：

• 人員的管理成本下降。因爲經過制度構建了扁平化和全功能的團隊，組織間的溝通協調成本降低。
• 技術的管理成本下降。因爲採用了鬆耦合的架構策略，使得應用架構既穩定又靈活。能夠低成本、低風險清理技術債，修復問題。或者增長新的功能。

人員的管理成本下降

當業務擴張的時候，須要開發並維護更多的需求。所以，在時間和質量不變的狀況下，只能經過增長資源來知足需求。可是，邊際收益遞減規律告訴咱們：在其它條件不變的狀況下，任何單一要素的投入所帶來的收益是會遞減的。所以，須要增長額外的要素來得到增加和回報率，特別是調整組織的結構，下降來提高容量。

而在大型應用系統開發面前，咱們投入資源的只有人，所以咱們能夠看到。大型的項目隨着人員的增長，它所帶來的管理成本也會增長，直到增長人員不產生收益爲止。這是咱們在大型應用系統，特別是互聯網應用上看到的問題。

之前粗放式的經過把複雜問題分解，而且經過人海戰術開發需求的模式將不可持續。一方面，複雜度的提高，須要可以把問題合理拆解到合理規模的架構師，這樣的架構師得到成本較高，不管是招聘仍是培訓。另外一方面，隨着開發維護人員的增長，人員的管理會增長額外的成本。

然而，微服務的出現。改變了應用架構，並在依據康威定律的做用下，改變了組織形式。經過自組織的全功能敏捷團隊，簡化了交付的流程的溝通成本。經過採用自動化手段將最佳實踐制度化，提高了交付質量，下降了培訓的成本。經過把一個問題分解爲獨立的問題，避免界限不清帶來的額外成本。

從經濟學角度說，微服務組織結構自己包含產權制度和界定產權兩個部分。

若是你的微服務作得最夠好，根據康威定律，你的架構會和你的組織結構是一致的。若是你有了一個自治且自我成長的團隊後，經過把最佳實踐變成制度和規則充分受權，而不須要更多的請示和彙報，你的組織結構不會有一個很厚很高的層次以及對應的回報關係。而是扁平而鬆散的結構，每一個團隊按照一樣的制度獨立完成任務，不會出現組織流程上的阻塞。但可以達到一樣的質量效率。

而這樣的文化最後最後會造成一個開發軟件的文化和制度，這個制度能夠在組織內複製而且推廣延續。減小了更多的人工管理成本。

所以，微服務架構可以大幅度的下降組織的管理成本。咱們能夠看到團隊自我改進、人員能力提高，你能夠有更少的管理層，在 2018 年北京 DevOpsDays 上華爲 DevCloud 團隊的案例分享也證實了這一點。

所以，一個成功的微服務實施，咱們能夠看到如下幾點組織特徵：

• 組織結構的扁平化，更少的管理層。意味着更低的管理成本。
• 組織的彈性更好，抗風險能力更佳。任何人的離開都不會帶來很大的影響。
• 交付質量和產出高，至少天天一次的高質量發佈使得任何變動都不會出現阻塞。
• 培訓成本下降，統一了原則和文化，使得任何新人進入團隊均可以快速上手。（2個迭代就有產出）
• 沒有阻塞，團隊獨立而且實時監控組織產能狀況，能夠動態的調整資源和產量。

技術的管理成本下降

另外一個微服務成功的特徵就是技術管理成本的下降，這個有兩個方面的成本。一方面是開發成本，另外一方面是維護成本。

主要緣由是在單體應用的時代，在變動請求頻繁的狀況下，單體應用成爲了一個互斥資源。借用 DevOps 和約束理論（ToC）的話說，單體應用的代碼庫成爲了一個約束點。在這個代碼庫上的全部變動都須要精心的安排和設計，不然會帶來總體影響。架構師須要仔細研究推敲各個方面，才能夠綜合因素作下一階段的安排。這時候，咱們須要對於應用架構的變動進行「批處理」。若是一批變動太多，一個變動失敗就會致使一批失敗。所以，業界開始採用"小步快跑"的方式頻繁的發佈，減小失敗率。爲了達到這個目的，就有了「持續交付」以及 DevOps 相關的實踐。

所以，咱們須要經過必定的方法解除約束點。因爲上文提到的應用程序的 DevOps 假設及其推論。咱們能夠把應用程序拆分紅邊界清晰的不一樣部分，用不一樣的代碼庫管理，並由不一樣的團隊去維護。從而達到開發運維的局部性，用以實施持續交付。

這樣作有幾個好處：

首先，你會獲得一個清晰的架構。而咱們如今大部分系統的應用架構是混亂的，裏面存在了太多的「暗知識」。「暗知識」就是須要經過跟蹤代碼，跟蹤日誌，實際運行監測的到的不肯定的知識。如今咱們去畫一個系統的架構分層圖，你畫出來的圖跟實際系統對應程度並非很高，並且很混亂，每每出現的狀況是部署架構和邏輯架構不一致。

其次，你會獲得更快、更穩定的發佈反饋。這其實是 DevOps 帶來的好處。使得你能夠更頻繁的去部署應用，在部署和更新的時候應用更穩定，存在更少的宕機時間。在這個過程當中會發現有不少的自動化，而後隨着微服務作得愈來愈多。最大的問題就是面對微服務的管理。實際上，在外部需求功能不變的狀況下，微服務的大小決定了微服務的數量。一樣也決定了團隊的數量和管理的複雜度。因此，微服務的大小不是問題，問題是你有多少人員可以支撐這樣的複雜度。

咱們知道若是你的開發任務量在增長的時候，咱們在不增長資金投入，不增長開發時間的狀況下的狀況下能作到最好的方式就是減小知足你最終交付時間點的需求。可是到了微服務的環境下，你不須要再有這樣的到期時間點交付的任務，你發現不須要增長人一樣能夠解決這些問題。

當你發現須要管理這麼多微服務你須要額外的自動化，你的團隊裏就會自驅造成自動化的意識。

然而，自動化帶來的不只僅是效率和穩定性。

經過持續交付流水線，咱們把功能測試和非功能測試都自動化起來，而且集成到持續交付流水線裏。

這樣，咱們就把提高質量做爲一種制度貫徹下去，避免人爲質量管理帶來的疏漏和質量降低。

記住，頻繁發佈的前提是不斷提高質量。若是下降對質量的要求，持續交付就只剩頻繁發佈了。所謂「質量不能降，一降就走樣」。

有了高質量做爲發佈門禁和要求，咱們就會看到團隊會向這個標準努力並提高本身的能力。發佈的風險和帶來的影響會愈來愈小。

任何讓你缺少信心的發佈都有一個質量忙點，問題是，有多少人會願意制度化的方式去解決，而不依賴人和測試。

所以，從技術上看，咱們能夠看到一個成功的微服務實施具有如下幾點特徵：

• 不少個代碼庫，以及一一對應的流水線。
• 應用能夠隨時部署，並不須要等待。
• 大量的自動化測試。
• 更少的變動事故。
• 更低的發佈風險。
• 能夠按需擴展。
• 更多的自動化手段。

最後

當咱們知道如何度量微服務的效果以後，咱們就能夠拿這個參考來考察一下微服務的組織實踐和技術實踐是否有助於咱們達到以上的效果。接下來，咱們會經過對比該微服務化架構組織和技術的異同來講明微服務所帶來的轉變。請期待下一篇：《成功微服務實施的技術演進》