《SpringBoot揭秘：快速建構微服務體系》—第1章1.2節微服務因何而生

本節書摘來自華章出版社《springboot揭秘：快速建構微服務體系》一書中的第1章，第1.2節微服務因何而生，作者王福強，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

1.2　微服務因何而生

微服務的概念我們應該大體了解了，那麼微服務又是怎麼來的？原來将很多功能打包為一個很大的服務單元進行傳遞的做法不能滿足需求嗎？

實際上，并非原來“大一統”（monolith）的服務化實踐不能滿足要求，也不是不好，隻是，它有自己存在的合理場景。對于monolith服務來說，如果團隊不大，軟體複雜度不高，那麼，使用monolith的形式進行服務化治理是比較合适的，而且，這種方式對運維和各種基礎設施的要求也不高。

但是，随着軟體系統的複雜度持續飙升，軟體傳遞的效率要求更高，投入的人力以及各項資源越來越多，基于monolith的服務化思路就開始“捉襟見肘”。

在開發階段，如果我們遵循monolith的服務化理念，通常會将所有功能的實作都統一歸到一個開發項目下，但随着功能的膨脹，這些功能一定會分發給不同的研發人員進行開發，造成的後果就是，大家在送出代碼的時候頻繁沖突并需要解決這些沖突，單一的開發項目成為了開發期間所有人的工作瓶頸。

為了減輕這種苦惱，我們自然會将項目按照要開發的功能拆分為不同的項目，進而負責不同功能的研發人員就可以在自己的代碼項目上進行開發，進而解決了大家無法在開發階段并行開發的苦惱。

到了軟體傳遞階段，如果我們遵循monolith的服務化理念，那麼，我們一定是将所有這些開發階段并行開發的項目集合到一起進行傳遞，這就涉及服務化早期實踐中比較有名的“火車模型”，即傳遞的服務就像一輛火車，而這個服務相關的所有功能對應的項目成果，就是要裝上火車車廂的一件件貨物，傳遞的列車隻有等到所有項目都開發測試完成後才可以裝車出發，完成整個服務的傳遞。很顯然，隻要有一個車廂沒有準備好貨物（即功能項目未開發測試完成），火車就不能發車，服務就不能傳遞，這大大降低了服務的傳遞效率。如果每個功能項目可以各自獨立傳遞，那麼就不需要都等同一輛火車，各自出發就可以了。順着這個思路，自然而然地，大家逐漸各自獨立，每一個功能或者少數相近的功能作為單一項目開發完成後将作為一個獨立的服務單元進行傳遞，進而在服務傳遞階段，大家也能夠并行不悖，各自演化而不受影響。

是以，随着服務和系統的複雜度逐漸飙升，為了能夠在整個軟體的傳遞鍊路上高效擴充，将獨立的功能和服務單元進行拆分，進而形成一個一個的微服務是自然而然發生的事情。這就像打不同的戰役一樣，在雙方兵力不多、戰場複雜度不高的情況下，monolith的統一指揮排程方式是合适的；而一旦要打大的戰役（類似于系統複雜度提升），雙方一定會投入大量的兵力（軟體研發團隊的規模增長），如果還是在狹小甚至固定的戰場上進行厮殺，顯然施展不開！是以，小戰役有小戰役的打法，大戰役有大戰役的戰法，而微服務實際上就是一種幫助擴充組織能力、提升團隊效率的應對“大戰役”的方法，它幫助我們從軟體開發到傳遞，進而到團隊群組織層面多方位進行擴充。

總的來說，一方面微服務可以幫助我們應對飙升的系統複雜度；另一個方面，微服務可以幫助我們進行更大範圍的擴充，從開發階段項目并行開發的擴充，到傳遞階段并行傳遞的擴充，再到相應的組織結構群組織能力的擴充，皆因微服務而受惠。