微服務與敏捷開發（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等等），幫助簡化整個過程的複雜程度和實現難度。但是工具鏈的掌握和應用也是一個新的成本。
個人建議
最後說一個僅代表我個人的觀點的建議，不是所有的公司都適合使用或全套使用微服務及敏捷開發的。在團隊人數不多、項目還在創業初期的話，是不適合全部採用微服務及敏捷開發的，可以按照微服務的理念做架構設計，但是上線不一定要各自獨立運行，這樣將大大減少你的技術投入成本。如果就十幾人的團隊，敏捷與否真的差別不大，把這套思想的精華運用到管理中就可以了。至於整套工具鏈的運用，反而會給您帶來更多的壓力。
如果項目創業初期就開始全套引入這些思想模式，可能沒等成員都適應這些模式，項目已經被對手先拿下了。