微服務架構如何影響軟件開發文化？技术頭條網

微服務，並不僅僅是一種代碼構造方式。

微服務概念一出現就引發了熱烈討論，很多文章都喜歡將其與整體式架構比較，乃至來自大型企業的用例等。然而，在說起微服務時，開發人員關注的往往是這場革命的技術意義，而非其象徵的文化顛覆。雖然技術元素也很重要，但其中蘊含的文化變革更加值得重視。

我很幸運能夠在 2014 年左右快速融入這場潮流，我也清楚地記得當時能夠將陳舊的整體式應用遷移至新的、酷炫無比的微服務架構是多麼令人興奮。和很多朋友一樣，我剛開始也只關注技術方面的影響——畢竟，當時正是革命性技術快速湧現的時期（例如，Docker 那時剛剛出現）。

然而，經過幾年發展，儘管在技術層面發生了諸多變化，但我認為微服務對組織中軟件開發方式產生的最大影響主要體現在代碼歸屬權以及團隊的職能定位上。

功能團隊

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

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

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

代碼所有權

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

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

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