微服務與敏捷開發（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等等），幫助簡化整個程序的復雜程度和實作難度，但是工具鏈的掌握和應用也是一個新的成本，

個人建議

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

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

標籤：其他

上一篇：人群流量監控，安全管理升級

下一篇：多級快取的分層架構