微服務與靈活開發（Scrum/Kanban）的核心思想之我見

  關于“微服務”和“靈活開發”的文章網絡上有很多，是以這裡不再重複叙述這些概念的解釋和特點，而是就個人實際工作中對他們的核心思想的了解及運用分享給大家，希望能對大家有所幫助。

  當下IT開發領域，“微服務”及“靈活開發”越來越被各公司及團隊重視。但是在交流中發現很多人對“微服務”及“靈活開發”存在很大的誤解，尤其在各公司的招聘崗位介紹中更能看到很多描述錯位的地方。

  首先，微服務和靈活開發都是指導思想，是模式和方法，并不是特指某個軟體應用、開發語言、開發架構等。并不是使用了某個軟體應用或某個架構就算是微服務或靈活開發了，也不是采用微服務和靈活開發理論指導開發工作，就必須要使用某些軟體或開發架構才能進行，這個是對微服務和靈活開發的嚴重誤解。

  其次，在實際開發工作中，這兩個指導思想要緊密的聯合起來運用，才能達到更高效的團隊運作，才能既快又好的進行産品疊代，将這兩種指導思想的優勢充分發揮出來。

先說一下微服務

  微服務是一個架構理念，是指導架構設計的一種思想模式，延伸了領域驅動設計（DDD）。微服務是為解決逐漸複雜的系統設計、開發問題而提出的。當一個應用系統太過複雜時，設計與開發難度要比簡單功能的系統大得多。其主要原因就是系統内有太多的耦合。這對系統疊代可能是緻命的。DDD理論則較好的解決了這個問題，是以微服務把它作為了業務劃分（微服務子產品）的重要指導性理論依據。

微服務是将一個完整的系統分割成若幹微小的、具備獨立性的功能單元，每個功能單元是可以具備一個實際意義的小功能集。各個功能單元之間盡量是解耦或松耦合，可以實作獨立開發而不依賴其他功能單元，自成一個微小的服務應用。這個開發理念與N年前流行的子產品化開發是異曲同工，也可以說是子產品化開發模式的延伸。但是微服務強調的是每個微服務子產品可以獨立工作在自己的環境或程序中，當然也可以與其他服務工作在同一個環境中（這裡也許有人說這樣你就不是微服務了，這也是誤解之一，繼續看！）。

  為什麼要将一個系統拆分成若幹獨立的微小服務呢，優勢在于：

  1、每個微小服務都可以由獨立的團隊或成員開發，不一定非要統一開發語言，可以各自發揮團隊、小組、成員的開發優勢。

  2、每個微小服務都可以部署到一個獨立的環境中，他們之間通過輕量級的通信機制進行互動，如果一個服務出現問題，不會造成整個系統癱瘓。

  3、可以讓系統階段性上線，提前上線重點功能，使産品面世時間提前。

  4、單個服務代碼量相對很少，出現BUG影響的範圍相對小很多，可以快速定位BUG的位置。

  5、更易于擴充功能，不會因為增加新的功能而改動整個應用或分析整個應用的代碼，隻需要增加微服務子產品就可以實作了。

  6、各個微服務子產品功能單一，這樣結構十厘清晰，使系統開發的複雜性大大降低，架構流程都很容易了解。

  7、有新技術應用可以在後續的子產品中直接使用，不用考慮之前已完成的服務。

  綜上所述，微服務在開發時，理論上是可以各自為政的，隻要完成預定的功能就可以了。這與以前常用的單體架構的一動則動全身相比，優勢十分明顯。

  要達到微服務這個效果，核心是架構負責人能有效的把整個系統拆分成微服務子產品，能真正做到微服務子產品之間互相解耦。必需耦合的服務能做到盡量松耦合，否則後面的任何工作都不能順利進行。若架構沒有理順，使用再多的微服務工具也是無濟于事的。微服務的工具鍊是輔助微服務模式落地的工具，不是必需的。前提是架構要合理，工具才能發揮作用，如果把兩個深度耦合的服務分别放在兩個容器（如Docker）中，那麼這一系列微服務的意義就不存在了。

  如果做的微服務架構合理，即使暫時沒有容器的部署環境，那在開發、釋出、疊代過程中仍然有巨大的優勢。僅僅是各微服務子產品沒有在獨立環境中運作，要在部署和維護時考慮環境的影響而已，其他特點還是具備的。

  微服務架構設計的着重點：

  1、業務功能盡量單一，每個微服務子產品隻實作一個單一的業務邏輯，不要将可拆分的多個業務邏輯寫在一個微服務子產品中。比如會員注冊子產品，隻需要處理會員注冊的業務邏輯，其他的不要考慮進來。

  2、通信要足夠輕量，子產品使用中，通信傳輸的内容要盡量做到足夠輕量，序列化消耗要盡量做到最小，否則會給整個系統帶來很大的運作壓力。要在一個系統中有統一标準，可以跨語言、跨平台使用。使每個微服務子產品有足夠的獨立性。

  3、接口定義要具前瞻性，在一個系統應用中，總會有些子產品無法徹底獨立運作，需要另外的子產品配合才可以得到正确的結果。這種情況在設計接口的時候，要充分考慮可能存在的修改，盡量減少對相關其他微服務子產品的影響。

  4、子產品充分獨立自治，可以把一個子產品看做一個小應用項目。開發、測試、運維都可以獨立進行，資料庫也是獨立的，它就是一個完整的應用。

  5、子產品劃分依據業務領域，而不是技術領域，也就是在該業務領域看是不是屬于一個獨立的服務子產品，而不是從技術角度看是否适合作為獨立的子產品。

  微服務也不是處處完美，也有它的弊端：

  無論目前的系統複雜與否、龐大與否，都需要複雜的分布式部署。這同時也給運維帶來了複雜性，維護量大大增加，對運維團隊要求提高很多。在測試階段，也會引入更複雜的問題。很多微服務子產品運作環境是一樣的，也會帶來大量的重複部署，代碼塊無法跨服務共用，多個微服務子產品中同樣的代碼要重複勞動。

再說一下靈活開發

  靈活開發是以微服務架構為基礎，以人為核心，指導我們化繁為簡、疊代、循環漸進的一種高效開發的方法。也就是把一個大項目根據業務結構和市場需求，拆分成多個小項目，并評估好開發優先級，然後依據優先級或市場調整逐一開發、測試、內建、部署運作。在這個過程當中，大項目已上線的部分一直是處于可運作的狀态。靈活開發具備快速上線、響應市場需求的商業價值。

  靈活開發強調的是靈活，是每次疊代的輕量、高效，而不是一味的追求快速，更不是越快越好。是以它是依據良好的微服務架構設計，良好的項目應用市場需求順序評估，合理的人員配置設定及高效的溝通方式，與需求方的密切合作及快速響應變化等最終達到理想的效果。

  深入了解一下靈活宣言中的靈活軟體開發的四個核心價值：

  @個體和互動高于流程和工具：這裡強調了人與人直接溝通的重要性和高效性，是以有站立會議的說法。但不要了解為完全不需要流程和工具，隻是側重人與人的溝通。

  @工作的軟體高于詳盡的文檔：這裡強調的是把更多的時間放在開發軟體上。但不是說文檔就一點也不要寫了，關鍵性的文檔（項目整理流程描述及架構圖等）還是要有的。

  @客戶合作高于合同談判：這個要差別公司屬性，外包公司團隊和企業自有項目團隊肯定會采取不同的政策。這句話應該是講給企業自有項目團隊的，為了企業合作雙方的利益，這個觀點是正确的。但不是說毫無底限的向客戶妥協，而是提倡密切合作可以提前發現問題，雙方都可以減少損失，實作共赢。

  @響應變化高于遵循計劃：這句道出了軟體開發不可回避的問題，就是需求變更。站在企業整體利益的角度，需求變化是很正常的。随着市場變化、時間推移，之前的需求如果不做修改可能真的就影響了産品的落地效果。但這也不是說就可以任意的變來變去，肯定也是需要有既懂業務又懂技術的人來負責全面評估，才能決定是否修改。

  Scrum（沖刺）是實作靈活開發的具體方式之一，是一種具體實施方案和流程，也稱之為管理架構。基本流程如下：

  1、首先确定角色：靈活大師Scrum Master（主要負責消除障礙，帶領團隊運作，靈活教練，服務型上司）；産品負責人Product Owner（主要負責描繪産品願景，定義優先級）；開發團隊Scrum Team（主要負責實作産品）。

  2、工作任務拆分，将項目拆分出一個可以階段性完成的小任務，制定待辦事項計劃表，評估優先級，時間周期的拆分，開計劃會議讨論确認。

  3、細化更小的任務，人員細分。

  4、每日站立會議，彙報昨天完成了什麼，承諾今天完成什麼，提出遇到的問題，并更新燃盡圖。

  5、每日內建、編譯、測試，回報結果。

  6、一個小任務全部完成，示範會議，評審，産品負責人及客戶必須參加，通過則上線釋出。

  7、最後開總結會議，針對剛完成的小任務開發過程中遇到的問題和好的方法進行讨論，需要改進的地方應用到下一個小任務當中。

  Kanban（看闆）是靈活開發的另一種具體實作方式。看闆的原則是“一件出去，一件進來”，由WIP（正在進行中的制品）驅動，每個人的工作都是以制品方式在看闆上标注，上下遊關系十厘清楚。是以看闆團隊多久能把手頭上的事情做完就是他們的響應時間。看闆圖對應的是流程，不一定隻有一個團隊。看闆模式沒有明确的任務時間，以任務完成為準，是以看闆上會看到有1一個月完成的，也有3天完成的。

  看闆模式重點是通過制品驅動，及時發現問題，然後調整團隊解決問題。通過這種方式解決整個團隊的瓶頸，達到高效的目的。

  實際應用靈活開發中，Scrum和kanban兩種思想要綜合起來運用才會更好的展現靈活開發的優勢。在Scrum模式中，是把所有人都相對理想化了。但是規定的時間不一定100%都能完成，如果融合kanban模式，就可以适當調整成員（或調動資源協助），達到進度均衡的目的，才能更有效的保障小任務的預算周期。

  通過上面的簡單介紹，大家可以看到這裡涉及到一個現在很熱門的幾個詞“持續內建、持續部署、持續傳遞”，因為一個項目被拆分了若幹小項目。逐漸完成逐漸釋出的，那麼勢必需要“持續內建、持續部署、持續傳遞”來支撐。這樣也就帶來的實際操作中過于複雜的問題。是以就有了很多支撐微服務/靈活開發的工具鍊（如：Active Collab、Jira、GitHub、Gitlab、Jenkins、CodeShip、JUnit、CircleCi、Bamboo、PagerDuty、DynaTrace、Docker、Kubernetes(k8s)、SpringCloud等等），幫助簡化整個過程的複雜程度和實作難度。但是工具鍊的掌握和應用也是一個新的成本。

個人建議

  最後說一個僅代表我個人的觀點的建議，不是所有的公司都适合使用或全套使用微服務及靈活開發的。在團隊人數不多、項目還在創業初期的話，是不适合全部采用微服務及靈活開發的，可以按照微服務的理念做架構設計，但是上線不一定要各自獨立運作，這樣将大大減少你的技術投入成本。如果就十幾人的團隊，靈活與否真的差别不大，把這套思想的精華運用到管理中就可以了。至于整套工具鍊的運用，反而會給您帶來更多的壓力。

  如果項目創業初期就開始全套引入這些思想模式，可能沒等成員都适應這些模式，項目已經被對手先拿下了。