功能團隊

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

微服務支持者傾向于消除這種固有模式，而更多將團隊視為產品在整個生命周期當中的歸屬方。在這方面，比較典型的例子就是亞馬遜提出的“誰構建、誰運行”原則，要求開發團隊對生產環境中的軟件負全部責任。

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

代碼所有權

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

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

微服務架構還帶來了小代碼庫概念。將原本的單一大存儲庫分散為幾十個較小的存儲庫，能夠確保特定存儲庫擁有明確的歸屬劃分。很明顯，代碼所有權并不一定意味著必須由單個團隊或者個人負責代碼的整體維護。其他團隊也可以根據需要提交 pull 請求（內部源）。但是，代碼的所有者應當負責保障解決方案質量，并確保所有 pull 請求都符合代碼標準以及 API 合約的要求。

總結

請別誤會，微服務也不是什么百試百靈的“銀彈”。雖然面向微服務的架構有助于建立代碼歸屬權與功能團隊，但對場景也有著相當具體的要求。畢竟，這些功能在整體式代碼庫中也完全能夠實現，只是需要輔以更多的組織參與投入。總結來講，這場文化變革應有怎樣的面貌、又是否適合，還得請各位開發人員自行判斷。代碼構造方式。