考慮把大型項目拆解成微服務嗎？

【編者的話】本文理性的討論了拆解大型項目到微服務的過程，討論了拆解過程當中會遇到的問題和編程語言的選擇，並給出了做者本身的建議。

微服務是處理臃腫、凌亂系統的一劑良藥。然而，拆解一個大型項目爲一系列的微服務所付出的代價是值得的嗎?如今存在一些優勢和缺點，那麼微服務的哪些特色吸引了衆多公司和開發人員呢?

最多見的應用場景是將一個大型系統切換到基於微服務的基礎設施。我傾向將這個過程稱爲「分解」應用程序,由於咱們把緊耦合的代碼分解成多個小的服務。這包括了從僅添加一兩個微服務到徹底重構主要應用程序到微服務架構。

簡而言之,我相信分解一個大型系統爲微服務組合是值得的。然而,這是一個長期投資,可能須要一段時間才能獲得回報。每一個項目或公司在這一過程當中都會有不一樣的經驗和教訓。這裏有一些共同的主題，它們也是我最近在分解大型項目到微服務過程當中遇到的。
 

放慢節奏

在開發軟件的過程當中，咱們一般切分大型的任務爲小的部分，便於一步一步實施。採用微服務時，與這個過程很是類似。咱們須要分解大的項目爲一系列的微服務。不少方面，咱們像堆砌木樁同樣處理它們：咱們須要隨時間的推移而添加組成部分，將項目分解成豐富且有用的多個組成部分。

當你首次介紹微服務思想給開發團隊時，可能他們會很容易接受。微服務是開發社區中的發展趨勢，因而人們都渴望試一下。更誇張的趨勢甚至會變成「可以改變app中一個功能而不影響其餘200項功能，這不是很棒麼？」

然而,實現鬆耦合和獨立應用的過程遠不止兩週。可能須要花費數個月甚至數年來解耦合你的應用程序到不一樣的功能服務。

將項目分解做爲一項長期的任務是很是重要的。客戶和投資者並不在乎你是否將已有的功能拆分爲微服務。他們只是關心是否你在如期地產出。當已經感覺到微服務架構的威力，你和你的團隊須要推進其發展。一樣，這也是一種技術債務。

這也就是爲何須要花費時間去解體大型項目。把拆解項目做爲一個長期項目的時候，可能須要花費多年時間才能獲得相應的收益。每一部分代碼的拆分都應該做爲一個重要決定。在你拆解速度過快時，可能會產生嚴重的問題。
 

自由一般不是免費的

微服務架構能夠採用不一樣的開發語言和框架實現。微服務限制一組有限的編程語言來共享應用程序，容許開發人員使用，而且只能用這些。

對於開發者來講，這能夠引出不少很是激動人心的決定。可是，你可能但願在選擇一門新編程語言或者框架來實現微服務時有所收斂。

學習新的編程語言或者框架對於我的經驗來說是很是有幫助的。同時開發者也頗有興趣去學習。儘管我可能知足於採用某些語言和框架來創做本身的私有項目，可是，在生產環境這個場景下，多是徹底不一樣的狀況。

你和你的同事可能以爲用Rust語言寫個服務是個好主意。從紙面上來說，這個主意看上去很好。你能夠用一個很是棒的語言去實現，同時讓你的業務達到一個更好的境地。

值得注意的是，在你的團隊和同事在實現它的時候，沒有什麼是一成不變的。團隊生產是一件取決於你是否要去選擇的事情。目前，你的公司可能具有資源和技能去採用Rust來創造一個高效的微服務。可是，你的團隊是否會在Rust服務上進行持續投入？這依賴於在微服務上的投入，你可能發現本身已經徹底歸屬在微服務上了。

當你選擇一門編程語言，你實際上是在抉擇將來是否繼續投入。拋開你當前團隊的規模和狀態的狀況下，最差的狀況是你可能朝着一個使人沮喪的方向而且浪費了大量的開發資源。
 

DevOps的負擔

當你決定去拆分一個項目時，我強烈推薦增長在DevOps上的投入。微服務的顯著特色是他們在持續部署上的穩定。這裏面還有不少其餘的說法。當服務準備完畢時，微服務使你能夠快速的部署。這對於部署過程是很是好的，由於你不須要從新部署一整套應用。

這只是理論上的狀況。

事實上，建立和維護的服務越多，部署環節天然會越多。你須要可以在有限時間內有效的部署多個服務。若是隻有有限個開發人員培訓過部署方式，事情可能會失控。

這就是爲何要教會開發者具有從開發到部署代碼的能力。理想狀況是，他們能夠便捷的部署代碼並監控。他們還應該具有突發狀況下部署和掌控服務的能力。此外，開發者應該熟悉微服務及對常規生產環境故障的感知力。我經歷過許多的部署錯誤，若是開發人員熟悉這些故障，解決起來會更快。這多是幾秒鐘宕機到幾分鐘宕機的差異。

此外，這個事情的複雜度可能會由於穩定性和語言多樣性而加劇。再次重申一下，並非全部的新語言和框架在部署上像其在開發上那麼方便。明智的選擇是在承擔較小風險的同時，採用較先進的語言和框架，畢竟它們可能不是爲生產環境而準備的。
 

結束語

分解一整個項目會帶來不少可變化的部分。解決這件事情的關鍵是讓團隊提升效率，並計劃好本身的時間。他們須要時間來實現新特性和修復，同時採起有效措施拆解應用程序。

採用微服務，你能夠自由選擇編程語言或者框架。這種自由度是很是使人興奮的，可是不要陷入到追求最前沿的陷阱裏，畢竟生產環境須要的是穩定。

一樣，在分解項目過程當中，DevOps帶來了另外一種複雜性。收穫的優點沒有在每次的從新部署中發揮出來。然而，這須要更多的支持和對部署過程當中新增服務的全部權。

我很是確信分解一個大型項目到微服務的過程是值得的。然而，這是一個長期的投資，可能須要一段時間才能收到回報。

 

來源：http://www.youruncloud.com/docker/1_88.html