??關(guān)于“微服務(wù)”和“敏捷開(kāi)發(fā)”的文章網(wǎng)絡(luò)上有很多，所以這里不再重復(fù)敘述這些概念的解釋和特點(diǎn)，而是就個(gè)人實(shí)際工作中對(duì)他們的核心思想的理解及運(yùn)用分享給大家，希望能對(duì)大家有所幫助。
??當(dāng)下IT開(kāi)發(fā)領(lǐng)域，“微服務(wù)”及“敏捷開(kāi)發(fā)”越來(lái)越被各公司及團(tuán)隊(duì)重視。但是在交流中發(fā)現(xiàn)很多人對(duì)“微服務(wù)”及“敏捷開(kāi)發(fā)”存在很大的誤解，尤其在各公司的招聘崗位介紹中更能看到很多描述錯(cuò)位的地方。
??首先，微服務(wù)和敏捷開(kāi)發(fā)都是指導(dǎo)思想，是模式和方法，并不是特指某個(gè)軟件應(yīng)用、開(kāi)發(fā)語(yǔ)言、開(kāi)發(fā)框架等。并不是使用了某個(gè)軟件應(yīng)用或某個(gè)框架就算是微服務(wù)或敏捷開(kāi)發(fā)了，也不是采用微服務(wù)和敏捷開(kāi)發(fā)理論指導(dǎo)開(kāi)發(fā)工作，就必須要使用某些軟件或開(kāi)發(fā)框架才能進(jìn)行，這個(gè)是對(duì)微服務(wù)和敏捷開(kāi)發(fā)的嚴(yán)重誤解。
??其次，在實(shí)際開(kāi)發(fā)工作中，這兩個(gè)指導(dǎo)思想要緊密的聯(lián)合起來(lái)運(yùn)用，才能達(dá)到更高效的團(tuán)隊(duì)運(yùn)作，才能既快又好的進(jìn)行產(chǎn)品迭代，將這兩種指導(dǎo)思想的優(yōu)勢(shì)充分發(fā)揮出來(lái)。
??微服務(wù)是一個(gè)架構(gòu)理念，是指導(dǎo)架構(gòu)設(shè)計(jì)的一種思想模式，延伸了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）。微服務(wù)是為解決逐漸復(fù)雜的系統(tǒng)設(shè)計(jì)、開(kāi)發(fā)問(wèn)題而提出的。當(dāng)一個(gè)應(yīng)用系統(tǒng)太過(guò)復(fù)雜時(shí)，設(shè)計(jì)與開(kāi)發(fā)難度要比簡(jiǎn)單功能的系統(tǒng)大得多。其主要原因就是系統(tǒng)內(nèi)有太多的耦合。這對(duì)系統(tǒng)迭代可能是致命的。DDD理論則較好的解決了這個(gè)問(wèn)題，所以微服務(wù)把它作為了業(yè)務(wù)劃分（微服務(wù)模塊）的重要指導(dǎo)性理論依據(jù)。
微服務(wù)是將一個(gè)完整的系統(tǒng)分割成若干微小的、具備獨(dú)立性的功能單元，每個(gè)功能單元是可以具備一個(gè)實(shí)際意義的小功能集。各個(gè)功能單元之間盡量是解耦或松耦合，可以實(shí)現(xiàn)獨(dú)立開(kāi)發(fā)而不依賴(lài)其他功能單元，自成一個(gè)微小的服務(wù)應(yīng)用。這個(gè)開(kāi)發(fā)理念與N年前流行的模塊化開(kāi)發(fā)是異曲同工，也可以說(shuō)是模塊化開(kāi)發(fā)模式的延伸。但是微服務(wù)強(qiáng)調(diào)的是每個(gè)微服務(wù)模塊可以獨(dú)立工作在自己的環(huán)境或進(jìn)程中，當(dāng)然也可以與其他服務(wù)工作在同一個(gè)環(huán)境中（這里也許有人說(shuō)這樣你就不是微服務(wù)了，這也是誤解之一，繼續(xù)看！）。
??為什么要將一個(gè)系統(tǒng)拆分成若干獨(dú)立的微小服務(wù)呢，優(yōu)勢(shì)在于：
??1、每個(gè)微小服務(wù)都可以由獨(dú)立的團(tuán)隊(duì)或成員開(kāi)發(fā)，不一定非要統(tǒng)一開(kāi)發(fā)語(yǔ)言，可以各自發(fā)揮團(tuán)隊(duì)、小組、成員的開(kāi)發(fā)優(yōu)勢(shì)。
??2、每個(gè)微小服務(wù)都可以部署到一個(gè)獨(dú)立的環(huán)境中，他們之間通過(guò)輕量級(jí)的通信機(jī)制進(jìn)行交互，如果一個(gè)服務(wù)出現(xiàn)問(wèn)題，不會(huì)造成整個(gè)系統(tǒng)癱瘓。
??3、可以讓系統(tǒng)階段性上線，提前上線重點(diǎn)功能，使產(chǎn)品面世時(shí)間提前。
??4、單個(gè)服務(wù)代碼量相對(duì)很少，出現(xiàn)BUG影響的范圍相對(duì)小很多，可以快速定位BUG的位置。
??5、更易于擴(kuò)展功能，不會(huì)因?yàn)樵黾有碌墓δ芏膭?dòng)整個(gè)應(yīng)用或分析整個(gè)應(yīng)用的代碼，只需要增加微服務(wù)模塊就可以實(shí)現(xiàn)了。
??6、各個(gè)微服務(wù)模塊功能單一，這樣結(jié)構(gòu)十分清晰，使系統(tǒng)開(kāi)發(fā)的復(fù)雜性大大降低，框架流程都很容易理解。
??7、有新技術(shù)應(yīng)用可以在后續(xù)的模塊中直接使用，不用考慮之前已完成的服務(wù)。
??綜上所述，微服務(wù)在開(kāi)發(fā)時(shí)，理論上是可以各自為政的，只要完成預(yù)定的功能就可以了。這與以前常用的單體架構(gòu)的一動(dòng)則動(dòng)全身相比，優(yōu)勢(shì)十分明顯。
??要達(dá)到微服務(wù)這個(gè)效果，核心是架構(gòu)負(fù)責(zé)人能有效的把整個(gè)系統(tǒng)拆分成微服務(wù)模塊，能真正做到微服務(wù)模塊之間相互解耦。必需耦合的服務(wù)能做到盡量松耦合，否則后面的任何工作都不能順利進(jìn)行。若架構(gòu)沒(méi)有理順，使用再多的微服務(wù)工具也是無(wú)濟(jì)于事的。微服務(wù)的工具鏈?zhǔn)禽o助微服務(wù)模式落地的工具，不是必需的。前提是架構(gòu)要合理，工具才能發(fā)揮作用，如果把兩個(gè)深度耦合的服務(wù)分別放在兩個(gè)容器（如Docker）中，那么這一系列微服務(wù)的意義就不存在了。
??如果做的微服務(wù)架構(gòu)合理，即使暫時(shí)沒(méi)有容器的部署環(huán)境，那在開(kāi)發(fā)、發(fā)布、迭代過(guò)程中仍然有巨大的優(yōu)勢(shì)。僅僅是各微服務(wù)模塊沒(méi)有在獨(dú)立環(huán)境中運(yùn)行，要在部署和維護(hù)時(shí)考慮環(huán)境的影響而已，其他特點(diǎn)還是具備的。
??微服務(wù)架構(gòu)設(shè)計(jì)的著重點(diǎn)：
??1、業(yè)務(wù)功能盡量單一，每個(gè)微服務(wù)模塊只實(shí)現(xiàn)一個(gè)單一的業(yè)務(wù)邏輯，不要將可拆分的多個(gè)業(yè)務(wù)邏輯寫(xiě)在一個(gè)微服務(wù)模塊中。比如會(huì)員注冊(cè)模塊，只需要處理會(huì)員注冊(cè)的業(yè)務(wù)邏輯，其他的不要考慮進(jìn)來(lái)。
??2、通信要足夠輕量，模塊使用中，通信傳輸?shù)膬?nèi)容要盡量做到足夠輕量，序列化消耗要盡量做到最小，否則會(huì)給整個(gè)系統(tǒng)帶來(lái)很大的運(yùn)行壓力。要在一個(gè)系統(tǒng)中有統(tǒng)一標(biāo)準(zhǔn)，可以跨語(yǔ)言、跨平臺(tái)使用。使每個(gè)微服務(wù)模塊有足夠的獨(dú)立性。
??3、接口定義要具前瞻性，在一個(gè)系統(tǒng)應(yīng)用中，總會(huì)有些模塊無(wú)法徹底獨(dú)立運(yùn)行，需要另外的模塊配合才可以得到正確的結(jié)果。這種情況在設(shè)計(jì)接口的時(shí)候，要充分考慮可能存在的修改，盡量減少對(duì)相關(guān)其他微服務(wù)模塊的影響。
??4、模塊充分獨(dú)立自治，可以把一個(gè)模塊看做一個(gè)小應(yīng)用項(xiàng)目。開(kāi)發(fā)、測(cè)試、運(yùn)維都可以獨(dú)立進(jìn)行，數(shù)據(jù)庫(kù)也是獨(dú)立的，它就是一個(gè)完整的應(yīng)用。
??5、模塊劃分依據(jù)業(yè)務(wù)領(lǐng)域，而不是技術(shù)領(lǐng)域，也就是在該業(yè)務(wù)領(lǐng)域看是不是屬于一個(gè)獨(dú)立的服務(wù)模塊，而不是從技術(shù)角度看是否適合作為獨(dú)立的模塊。
??微服務(wù)也不是處處完美，也有它的弊端：
??無(wú)論當(dāng)前的系統(tǒng)復(fù)雜與否、龐大與否，都需要復(fù)雜的分布式部署。這同時(shí)也給運(yùn)維帶來(lái)了復(fù)雜性，維護(hù)量大大增加，對(duì)運(yùn)維團(tuán)隊(duì)要求提高很多。在測(cè)試階段，也會(huì)引入更復(fù)雜的問(wèn)題。很多微服務(wù)模塊運(yùn)行環(huán)境是一樣的，也會(huì)帶來(lái)大量的重復(fù)部署，代碼塊無(wú)法跨服務(wù)共用，多個(gè)微服務(wù)模塊中同樣的代碼要重復(fù)勞動(dòng)。
??敏捷開(kāi)發(fā)是以微服務(wù)架構(gòu)為基礎(chǔ)，以人為核心，指導(dǎo)我們化繁為簡(jiǎn)、迭代、循環(huán)漸進(jìn)的一種高效開(kāi)發(fā)的方法。也就是把一個(gè)大項(xiàng)目根據(jù)業(yè)務(wù)結(jié)構(gòu)和市場(chǎng)需求，拆分成多個(gè)小項(xiàng)目，并評(píng)估好開(kāi)發(fā)優(yōu)先級(jí)，然后依據(jù)優(yōu)先級(jí)或市場(chǎng)調(diào)整逐一開(kāi)發(fā)、測(cè)試、集成、部署運(yùn)行。在這個(gè)過(guò)程當(dāng)中，大項(xiàng)目已上線的部分一直是處于可運(yùn)行的狀態(tài)。敏捷開(kāi)發(fā)具備快速上線、響應(yīng)市場(chǎng)需求的商業(yè)價(jià)值。
??敏捷開(kāi)發(fā)強(qiáng)調(diào)的是敏捷，是每次迭代的輕量、高效，而不是一味的追求快速，更不是越快越好。因此它是依據(jù)良好的微服務(wù)架構(gòu)設(shè)計(jì)，良好的項(xiàng)目應(yīng)用市場(chǎng)需求順序評(píng)估，合理的人員分配及高效的溝通方式，與需求方的密切合作及快速響應(yīng)變化等最終達(dá)到理想的效果。
??深入理解一下敏捷宣言中的敏捷軟件開(kāi)發(fā)的四個(gè)核心價(jià)值：
??@個(gè)體和互動(dòng)高于流程和工具：這里強(qiáng)調(diào)了人與人直接溝通的重要性和高效性，所以有站立會(huì)議的說(shuō)法。但不要理解為完全不需要流程和工具，只是側(cè)重人與人的溝通。
??@工作的軟件高于詳盡的文檔：這里強(qiáng)調(diào)的是把更多的時(shí)間放在開(kāi)發(fā)軟件上。但不是說(shuō)文檔就一點(diǎn)也不要寫(xiě)了，關(guān)鍵性的文檔（項(xiàng)目整理流程描述及架構(gòu)圖等）還是要有的。
??@客戶(hù)合作高于合同談判：這個(gè)要區(qū)別公司屬性，外包公司團(tuán)隊(duì)和企業(yè)自有項(xiàng)目團(tuán)隊(duì)肯定會(huì)采取不同的策略。這句話(huà)應(yīng)該是講給企業(yè)自有項(xiàng)目團(tuán)隊(duì)的，為了企業(yè)合作雙方的利益，這個(gè)觀點(diǎn)是正確的。但不是說(shuō)毫無(wú)底限的向客戶(hù)妥協(xié)，而是提倡密切合作可以提前發(fā)現(xiàn)問(wèn)題，雙方都可以減少損失，實(shí)現(xiàn)共贏。
??@響應(yīng)變化高于遵循計(jì)劃：這句道出了軟件開(kāi)發(fā)不可回避的問(wèn)題，就是需求變更。站在企業(yè)整體利益的角度，需求變化是很正常的。隨著市場(chǎng)變化、時(shí)間推移，之前的需求如果不做修改可能真的就影響了產(chǎn)品的落地效果。但這也不是說(shuō)就可以任意的變來(lái)變?nèi)?，肯定也是需要有既懂業(yè)務(wù)又懂技術(shù)的人來(lái)負(fù)責(zé)全面評(píng)估，才能決定是否修改。
??Scrum（沖刺）是實(shí)現(xiàn)敏捷開(kāi)發(fā)的具體方式之一，是一種具體實(shí)施方案和流程，也稱(chēng)之為管理框架?；玖鞒倘缦拢?br>
??1、首先確定角色：敏捷大師Scrum Master（主要負(fù)責(zé)消除障礙，帶領(lǐng)團(tuán)隊(duì)運(yùn)作，敏捷教練，服務(wù)型領(lǐng)導(dǎo)）；產(chǎn)品負(fù)責(zé)人Product Owner（主要負(fù)責(zé)描繪產(chǎn)品愿景，定義優(yōu)先級(jí)）；開(kāi)發(fā)團(tuán)隊(duì)Scrum Team（主要負(fù)責(zé)實(shí)現(xiàn)產(chǎn)品）。
??2、工作任務(wù)拆分，將項(xiàng)目拆分出一個(gè)可以階段性完成的小任務(wù)，制定待辦事項(xiàng)計(jì)劃表，評(píng)估優(yōu)先級(jí)，時(shí)間周期的拆分，開(kāi)計(jì)劃會(huì)議討論確認(rèn)。
??3、細(xì)化更小的任務(wù)，人員細(xì)分。
??4、每日站立會(huì)議，匯報(bào)昨天完成了什么，承諾今天完成什么，提出遇到的問(wèn)題，并更新燃盡圖。
??5、每日集成、編譯、測(cè)試，反饋結(jié)果。
??6、一個(gè)小任務(wù)全部完成，演示會(huì)議，評(píng)審，產(chǎn)品負(fù)責(zé)人及客戶(hù)必須參加，通過(guò)則上線發(fā)布。
??7、最后開(kāi)總結(jié)會(huì)議，針對(duì)剛完成的小任務(wù)開(kāi)發(fā)過(guò)程中遇到的問(wèn)題和好的方法進(jìn)行討論，需要改進(jìn)的地方應(yīng)用到下一個(gè)小任務(wù)當(dāng)中。
??Kanban（看板）是敏捷開(kāi)發(fā)的另一種具體實(shí)現(xiàn)方式?？窗宓脑瓌t是“一件出去，一件進(jìn)來(lái)”，由WIP（正在進(jìn)行中的制品）驅(qū)動(dòng)，每個(gè)人的工作都是以制品方式在看板上標(biāo)注，上下游關(guān)系十分清楚。所以看板團(tuán)隊(duì)多久能把手頭上的事情做完就是他們的響應(yīng)時(shí)間?？窗鍒D對(duì)應(yīng)的是流程，不一定只有一個(gè)團(tuán)隊(duì)?？窗迥Ｊ?jīng)]有明確的任務(wù)時(shí)間，以任務(wù)完成為準(zhǔn)，所以看板上會(huì)看到有1一個(gè)月完成的，也有3天完成的。
??看板模式重點(diǎn)是通過(guò)制品驅(qū)動(dòng)，及時(shí)發(fā)現(xiàn)問(wèn)題，然后調(diào)整團(tuán)隊(duì)解決問(wèn)題。通過(guò)這種方式解決整個(gè)團(tuán)隊(duì)的瓶頸，達(dá)到高效的目的。
??實(shí)際應(yīng)用敏捷開(kāi)發(fā)中，Scrum和kanban兩種思想要綜合起來(lái)運(yùn)用才會(huì)更好的體現(xiàn)敏捷開(kāi)發(fā)的優(yōu)勢(shì)。在Scrum模式中，是把所有人都相對(duì)理想化了。但是規(guī)定的時(shí)間不一定100%都能完成，如果融合kanban模式，就可以適當(dāng)調(diào)整成員（或調(diào)動(dòng)資源協(xié)助），達(dá)到進(jìn)度均衡的目的，才能更有效的保障小任務(wù)的預(yù)算周期。
??通過(guò)上面的簡(jiǎn)單介紹，大家可以看到這里涉及到一個(gè)現(xiàn)在很熱門(mén)的幾個(gè)詞“持續(xù)集成、持續(xù)部署、持續(xù)交付”，因?yàn)橐粋€(gè)項(xiàng)目被拆分了若干小項(xiàng)目。逐步完成逐步發(fā)布的，那么勢(shì)必需要“持續(xù)集成、持續(xù)部署、持續(xù)交付”來(lái)支撐。這樣也就帶來(lái)的實(shí)際操作中過(guò)于復(fù)雜的問(wèn)題。因此就有了很多支撐微服務(wù)/敏捷開(kāi)發(fā)的工具鏈（如：Active Collab、Jira、GitHub、Gitlab、Jenkins、CodeShip、JUnit、CircleCi、Bamboo、PagerDuty、DynaTrace、Docker、Kubernetes(k8s)、SpringCloud等等），幫助簡(jiǎn)化整個(gè)過(guò)程的復(fù)雜程度和實(shí)現(xiàn)難度。但是工具鏈的掌握和應(yīng)用也是一個(gè)新的成本。
??最后說(shuō)一個(gè)僅代表我個(gè)人的觀點(diǎn)的建議，不是所有的公司都適合使用或全套使用微服務(wù)及敏捷開(kāi)發(fā)的。在團(tuán)隊(duì)人數(shù)不多、項(xiàng)目還在創(chuàng)業(yè)初期的話(huà)，是不適合全部采用微服務(wù)及敏捷開(kāi)發(fā)的，可以按照微服務(wù)的理念做架構(gòu)設(shè)計(jì)，但是上線不一定要各自獨(dú)立運(yùn)行，這樣將大大減少你的技術(shù)投入成本。如果就十幾人的團(tuán)隊(duì)，敏捷與否真的差別不大，把這套思想的精華運(yùn)用到管理中就可以了。至于整套工具鏈的運(yùn)用，反而會(huì)給您帶來(lái)更多的壓力。
??如果項(xiàng)目創(chuàng)業(yè)初期就開(kāi)始全套引入這些思想模式，可能沒(méi)等成員都適應(yīng)這些模式，項(xiàng)目已經(jīng)被對(duì)手先拿下了。
聯(lián)系客服
