微服務落地反思以及有效落地

做者簡介

顧宇

ThoughtWorks高級諮詢師

在正式開始以前，作一個調查，當你聽到微服務的時候，你是開心的仍是質疑的，仍是痛苦的？

我今天的分享是微服務落地反思以及高效落地，我提早預告一下，這是針對團隊的內容，若是你在網上看到微服務的視頻和教程，你能夠在雲上本身去實現微服務的技術。當你碰到一個團隊要落地微服務的時候，它就會有一些問題，這些內容主要是針對這部分。

一. 三個微服務案例帶來的反思

---

1.1 Java遺留系統解耦

這個服務項目是我加入ThoughtWorks 第一年，2013 年 9 月 份，當時還不知道是微服務項目，2014 年微服務的概念纔出現。當時是作Java的解耦，這是國外的客戶，作垂直搜索引擎。

這個公司選擇的時間和切入點很是好，很快就有成爲澳大利亞這個行業的第一名。他們用的老技術沒有辦法戰勝競爭對手，他們幾乎是當時每月都有新的競爭對手用更新、更快、更便宜的技術跟它競爭，因此他們當時想解耦。

如何在這個狀況下合理拆分應用？咱們一開始是用老的 spring 2.5，用的是 Java ESB 作總線，在上面掛了不少服務，老的 SOL 模型。後來，咱們用 Restful 的 API 把模型解耦，從整個的 Java 大的外包上拆下來變成獨立的服務。咱們能讓拆出來的應用作到各自的獨立部署，這是咱們當時碰到的問題。咱們當時的理解很簡單，作微服務就是作持續部署 Restful API。

我完成項目經歷了七個月時間，在這以後，咱們開始把這個經驗開始複製。

1.2 某電信運營商

---

這個項目是澳大利亞的運營商，當時的項目的問題是這樣的，當時收購了一家公司，作移動運營商，收購了作寬帶的運營商。它的用戶羣極速擴張，因此要改線上的應用。咱們當時面對的問題是如何快速穩定的部署應用、如何提升團隊的生產率，特別是自動化水平，以及如何解除流程瓶頸，跨部門協做。

當時咱們的 Ops 團隊只有4人，要提高團隊的生產率。瓶頸之外的改進都是假象，咱們作 DevOps 的諮詢和改進，咱們把開發的效率提高了 300%，其實不到 300%。對上層來講，改進的效果是同樣的，仍是一個月部署一次版本。

跟我對接的團隊是三個月部署一次版本，若是出了問題，只能等下個月。我當時想的是，即便你作了 DevOps，你仍然沒有加速。咱們當時的解決方案是把它的其中一部分跟咱們的合做方相關的部分割離出來，變成單獨的服務，咱們這部分則用咱們的方式，這樣你們就變成異步了。DevOps 作到了極致就獲得微服務。

當你有一個單體應用，不斷提高持續交付流水線的速度和質量的時候，再往下提高只能拆它去提高了。你能夠按需擴張應用，你能夠獲得更小的風險點，由於每次部署都是一個點，帶來的生產影響是很是小的。因此，我以爲 DevOps 作到極致就是獲得微服務。

1.3 某大型IT集團雲計算產品

---

這是國內的客戶，總部在深圳，作的也是雲計算產品。我作完上一個微服務項目以後發現微服務的套路，你要找到真正解決問題的瓶頸。當時的項目瓶頸是如何縮短髮布時間、如何獨立發佈、微服務遲遲落不了地。

這個項目須要八週時間才能發佈，咱們想這麼大的雲計算平臺系統要發一個整包是很困難的，因此咱們拆分出一部分。可是有一個問題，這個微服務的拆分方案遲遲落地不了。

2015 年聖誕前前一週說要作這個事情，我加入到這個項目是 2016 年 4 月 1 日前一週，我瞭解這個事情的時候，發現他們已經通過三個月左右時間，除了一堆彙報和會議紀要，以及各方諮詢師的評估方案，沒有一點是落地的。我在想，微服務經過我以前的經歷是很簡單的事情，爲何會變得這麼難落地？

你的瓶頸每每是從組織上來的，從組織結構的調整作微服務是有效的。咱們要作微服務，把系統架構畫起來，咱們來拆分、設計，作出來的效果又慢又很差，到了後面出了新問題還要修改原先的方案。

1.4 三個案例的共同點

---

• 都是開發團隊和應用在規模增加狀況下，要保持團隊的高效率部署；

• 要在團隊上實踐持續交付以及 DevOps ；

• 要讓應用程序在空間和時間上無衝突發佈；

若是你有一個單體應用，必定會建一對分支，合併的時候要處理衝突，測試完後上線還不必定可行。因此，咱們要作到這些，咱們須要作一些巨大的調整。

1.5 如何面對增加

---

這是咱們在需求和規模增加時碰到的增加模式。當你碰到 SCALE UP 的時候，資源增加就須要管理，這就帶來額外的成本。

有一個規律叫邊際收益遞減規律，因此咱們會作另一種擴張，就是 SCALE OUT，是線性擴展，可是咱們須要強而有力的制度，咱們能夠把一個團隊的成功和一個應用的成功隨着規模的增加不斷擴大，這就是作微服務的基本思想。你所面對的問題是在快速增加或規模很大的狀況下，解決時間和空間上開發和部署的衝突問題。

咱們碰到規模問題以後，有一個成本拐點。

X軸是成本，Y軸是規模，黑線是單體應用，綠色線是微服務應用。微服務應用開始是分佈式系統，開始的成本會比單體應用高一點。過一段時間，它們會走到X點，在這一點的時候，單體應用和微服務應用沒有什麼差異了。可是，應用在增加的時候，若是是單體應用，會碰到成本極限。到了成本極限的時候支撐不了規模的擴張，因此有一個增加極限，這叫X’。當應用複雜增加規模和成本到必定程度的時候，轉化成微服務應用。

事實是很是殘酷的，大部分企業不撞南頭不回頭，這是理想的。職責分離的概念很早就有了，微服務就是用新技術，新瓶裝舊酒，微服務並無帶來新的方法論上的突破。

因此，把微服務改造看做是一種投資，是對企業增加極限的投資，你得到更高的擴展能力後就得到更遠的極限，由於你能夠複製你的優點。

1.6 微服務解決的問題

---

微服務本質上在解決什麼問題？

• 處於團隊和應用處於高增加；

• 經過獨立部署和獨立發佈提高總體的交付效率；

• 解決在時間和空間將單一代碼庫的衝突訪問；

若是你在作微服務，先檢視一下本身有沒有這樣的問題。

二. 微服務落地的難點

---

咱們看看微服務落地的難點。這些是我過去參與的微服務項目中常見的問題，說難點是由於這些問題須要更多的時間去思考和討論，爲微服務的架構決策提供依據。

1. 不知道怎麼拆分；

2. 架構落地困難；

3. 管理愈來愈複雜；

4. 技術棧不知道該怎麼選；

5. 團隊不知道該怎麼組織；

6. 微服務應該怎麼管理；

2.1 技術問題 vs 非技術問題

---

微服務是技術問題仍是非技術問題？其實它兩個方面都是。《人件》這本書我很是推薦，它的序言有兩句話「軟件系統的重要問題不在於技術，而在於社會性因素。」 「若是咱們所面對的問題天生就屬於社會學範疇，再好的技術可能也提供不了什麼幫助。」

微服務是一個掩蓋在技術問題之下的管理問題，若是你的技術棧若是缺少管理，若是一開始用很好的重構方案不斷優化代碼，你後面作微服務，作單一職責是很好的，能夠一步遷移。咱們的代碼庫其實已經隔離了，合併代碼的時候合併在一塊兒，咱們有自動化測試，因此咱們一鍵切換就是把代碼庫複製一份，改成API調用，這樣能夠保證微服務上線後沒有太大的問題。

沒有意識到微服務是一個組織轉型問題。

這個圖片是來自於Netflix，Netflix在網上有本身作微服務的感覺經驗，這個圖也是從那裏來。它說微服務是一項組織變革，組織變革都是困難的。

微服務並不是一路順風的，可是管理是你看不到的，咱們要讓不少團隊看到管理問題，看見是改變的開始，能看到問題才知道怎麼去改變。

《人件》中有一個薩提亞改變模型，當你有現有架構，引入微服務後會引發混亂，介入和輔導後，進行實踐與整合，進行反饋和強化造成微服務架構。若是你作微服務作得很開心，說明到了微服務架構階段了。難點就是中間混亂的部分，並且混亂是不可逾越的過程，你碰到新的東西，你要突刺本身的新習慣，確定經歷不習慣。

2.2 怎麼纔算高效？

---

說到微服務高效落地的步驟，怎麼纔算高效？

1. 從結果出發，找最短的距離。經過原先的開發模式，分析完再落地，就離微服務愈來愈遠了，它沒有讓你變得更快，也不會變得更簡單；

2. 最難的事情最優先解決。技術的改變每每是最簡單的部分，最難的部分是技術實施的部分；

3. 低成本、低風險，絕對沒有浪費；

三. 高效落地微服務的五個步驟

---

3.1 以終爲始，組建團隊

首先不要考慮技術，首先組建微服務的團隊。若是按照傳統方式作微服務，只會重蹈覆轍。一個自治的全功能團隊是能夠獨立發佈微服務的團隊，須要1名微服務經理，解決流程依賴和干擾；2-4名開發/測試，專一於微服務開發和測試；1-2個運維，用來提供最快速的發佈和部署。若是你的組織是DevOps的分離團隊，建議有1-2個運維。

獨立的小團隊就是避免依賴，在原先的開發流程和環境裏習慣了一種開發方式，你切換另一種方式後，你總想着之前的方式開發。

可是，咱們要強調，在一個團隊裏全部東西都是團隊乾的，一方面是提高人員的能力，另外一方面是讓你們感受能夠有更多控制的東西，心情也比之前好，按正確的方式作正確的選擇。還有特事特辦，若是按照原先的方式走，效率不會提升。要把微服務放到最高優先級，要有儀式感。

這是技術上的建議——一個微服務、一個代碼庫、一條流水線。

有兩種組織，一種是鬆散的扁平化的組織，它有很強的管理規約，若是應用了一個軟件系統後，它會很快適應這個軟件系統的架構。若是是另一種，會把軟件架構改爲組織結構，這就是所謂的康威定律，即你的組織結構和系統架構基本上是等價的。

不一樣的組織，有可能系統架構改變了組織架構，有多是組織架構改變你的系統架構，若是團隊規模超過200人以上，經過技術手段改變管理組織的方式通常不會成功，除非有很強有力的領導來作這個事情。

3.2 構建微服務電梯演講

---

電梯演講來自於麥肯錫，即保持微服務的概念簡單。一開始作的時候就要變得簡單，把邊界很容易地切分開。最重要的是不要15秒，在15秒內把微服務說完。

這是咱們公司的標題——不帶手機和電腦，會議溝通效果好，因此要掛到牆上，造成儀式感，不斷造成暗示。微服務團隊的電梯演講要達成共識，而後快速地實現。

3.3 取得快速勝利

---

用最小的代價發佈第一個微服務，這會給團隊帶來很大的士氣。目標不宜過高，Showcase驅動開發，要演示什麼就開發什麼，天天都有有效的產出。第一天制定目標，明天展現這個，確保明天能展現。

什麼是用最小的代價發佈第一個微服務？最小的代價是團隊規模2-8人，時間是2-4周，選擇代價較小的技術棧。

當你作微服務上線切分的時候有一個特性開關，必定要用這個，不要用分支。並且，要強調單主幹開發，若是你用了分支，就表明有分支，你的代碼就有耦合，有耦合證實你能夠再拆，最很差的是給本身一個不作持續交付的接口。你必定要快速上線，快速部署到生產環境裏，而不是在測試環境裏自high。

3.4 代碼微微動，DevOps 先行!

---

工程師很容易看到代碼就先導代碼細節裏，這就很差弄和不能搞。當你聽到藉口的時候，就沒有到達目的地的方向。若是你的組織是Dev和Ops分離的組織，先諮詢一下Ops工程師的意見。最好是可以給微服務團隊裏面配備一名Ops工程師。若是不具有實施DevOps的條件，微服務架構就要從運維側，而不是開發側開始進行。

作DevOps就是作CLAMS。必定要有度量，沒有度量就沒有改進。自動化就是除了代碼提交和發佈，一切自動化，這是對團隊的要求，若是質量控制作得很好後，發佈也能夠自動化，中間不須要任何人作任何驗證，任何驗證均可以用自動化解決。

列了關鍵的自動化，第一是自動化測試，有功能和非功能自動化測試。

第二是自動化基礎設施管理，主要是基礎設施及代碼，基礎設施還須要人工弄的話，微服務的速度就不達標不。

第三是自動化部署，不是發佈，微服務部署到生產環境上仍是須要人爲手工的驗證步驟，由於不是很習慣，剛開始是須要這麼作的。

部署是一個技術動做，你把應用部署放到生產環境上，而發佈是一個業務動做，是肯定哪一部分用戶能夠看到你的微服務。

第四是自動化監控告警，微服務的自動化監控告警跟之前的監控告警是不同的，要提早想好怎麼埋點的問題。

用精益經過可視化來發現問題，經過看板發現各類存在的問題。這方面我很少說了，你們能夠找相關的參考資料。經過可視化來發現問題，這個問題不是架構上的問題，而是管理上的問題。在團隊裏，有了問題都是你們的，構建分享和分擔的理念，不要指責別人。

打造完整的DevOps 文化，DevOps 說是文化是有必定道理的。這有四個文化：靈活性、溝通、學習、打造氛圍。

DevOps 有幾個核心實踐，第一是持續交付，

第二是基礎設施即代碼，作資源配置和資源編排，

第三是基礎設施對微服務是透明的。

我碰到一些狀況，微服務和基礎設施代碼放到一個代碼庫裏，每一個微服務有不一樣的基礎設施需求，改動的話牽涉的動做太多，不要把整套基礎設施放到一個代碼庫裏。

3.5 持續改進，複製成功經驗

---

什麼叫知識詛咒？當你學會一個知識以後，你再沒法想象你做爲初學者的狀態。你作完微服務以後，你再去教初學者，效果不會很好。因此，在作微服務開始的時候，要作好微服務各類問題的記錄，把一部分的成功經驗交給新人，要比你找一個微服務頗有經驗的人去教新人要好得多。由於一個頗有經驗的人去教一個新人的話，他會中了知識的詛咒，他會忘了他是怎麼做爲一個初學者開始的。

複製成功經驗須要總結出來的關鍵產出，要作到微服務開發到發佈的端到端流程規範，最好是作成自動化，自動化自己就是一種管理制度。微服務開發的技術質量的規範，以及團隊中合做的堅持最佳實踐，以及一些問題的總結，要經過回顧會議進行不斷地改進。

最後，要作團隊交叉輪換，有一個微服務團隊後，中間拿掉一點人，補充新人，要適應微服務的文化。微服務自己須要比較小的團隊來簡化整個部署。

想與更多同行見面相互交流，想聆聽更多專家的技術解讀

DevOps 國際峯會正是一場頭腦風暴的盛會

讓 DevOps 回到更本質的地方，並進一步領會 DevOps 的精神