功能團(tuán)隊(duì)

雖然我們也可以在整體式架構(gòu)下建立具有跨職能特性的團(tuán)隊(duì)，但組織通常會根據(jù)具體技術(shù)功能（例如前端、后端、系統(tǒng)管理員以及數(shù)據(jù)庫開發(fā)等）進(jìn)行團(tuán)隊(duì)拆分。因此，開發(fā)人員很少能夠接觸到生產(chǎn)環(huán)境，因此幾乎不需要考慮生產(chǎn)與維護(hù)方面的問題。James Lewis 與 Martin Fowler 在最初定義微服務(wù)架構(gòu)概念的文章中就強(qiáng)調(diào)過這一點(diǎn)。

微服務(wù)支持者傾向于消除這種固有模式，而更多將團(tuán)隊(duì)視為產(chǎn)品在整個(gè)生命周期當(dāng)中的歸屬方。在這方面，比較典型的例子就是亞馬遜提出的“誰構(gòu)建、誰運(yùn)行”原則，要求開發(fā)團(tuán)隊(duì)對生產(chǎn)環(huán)境中的軟件負(fù)全部責(zé)任。

除此之外，將具有其他專業(yè)知識的人員引入團(tuán)隊(duì)（例如產(chǎn)品 / 營銷），也使團(tuán)隊(duì)獲得遠(yuǎn)超技術(shù)范疇的其他能力。團(tuán)隊(duì)將能夠監(jiān)控客戶反饋、用戶采用與商業(yè)價(jià)值，使團(tuán)隊(duì)對功能以及其中的各個(gè)層面負(fù)起完全責(zé)任。通過這樣的新模式，團(tuán)隊(duì)將能夠明確觀察到他們的決策對于產(chǎn)品以及業(yè)務(wù)本身造成的影響。

代碼所有權(quán)

在剛開始編程時(shí)，我曾投入數(shù)年時(shí)間研究游戲、桌面 /Web 應(yīng)用程序以及網(wǎng)站等小型項(xiàng)目，把頭腦中的想法轉(zhuǎn)化為代碼，給人一種莫名的愉悅感。然而，在開始從事軟件開發(fā)職業(yè)之后，我發(fā)現(xiàn)真正的工作更像是流水線上的裝配操作，而非藝術(shù)創(chuàng)作。

除了責(zé)任模糊外，在選擇技術(shù)時(shí)，代碼庫與數(shù)據(jù)存儲的集中特性同樣有很多局限。關(guān)于框架、語言、設(shè)計(jì)模式以及數(shù)據(jù)庫引擎選擇方面的決策必須符合全局要求。簡而言之，如果無法對所有要素進(jìn)行整體把控，就很難獲得理想的創(chuàng)造能力。

微服務(wù)架構(gòu)還帶來了小代碼庫概念。將原本的單一大存儲庫分散為幾十個(gè)較小的存儲庫，能夠確保特定存儲庫擁有明確的歸屬劃分。很明顯，代碼所有權(quán)并不一定意味著必須由單個(gè)團(tuán)隊(duì)或者個(gè)人負(fù)責(zé)代碼的整體維護(hù)。其他團(tuán)隊(duì)也可以根據(jù)需要提交 pull 請求（內(nèi)部源）。但是，代碼的所有者應(yīng)當(dāng)負(fù)責(zé)保障解決方案質(zhì)量，并確保所有 pull 請求都符合代碼標(biāo)準(zhǔn)以及 API 合約的要求。

總結(jié)

請別誤會，微服務(wù)也不是什么百試百靈的“銀彈”。雖然面向微服務(wù)的架構(gòu)有助于建立代碼歸屬權(quán)與功能團(tuán)隊(duì)，但對場景也有著相當(dāng)具體的要求。畢竟，這些功能在整體式代碼庫中也完全能夠?qū)崿F(xiàn)，只是需要輔以更多的組織參與投入?？偨Y(jié)來講，這場文化變革應(yīng)有怎樣的面貌、又是否適合，還得請各位開發(fā)人員自行判斷。代碼構(gòu)造方式。