[[315389]]

【51CTO.com快譯】Gartner研究主管Raj Bala說過，無服務器產品最出色的地方之一就是讓你可以“前所未有地混合搭配前編程語言和框架。”這意味著，比如使用函數即服務(無服務器)平臺，你就可以編寫調用Python庫的Java應用程序。

確實很酷。

但是這也可能意味著意大利面條式代碼(即非結構化、難以維護的代碼)迎來新時代。就因為你告別整體式代碼，并不意味著不會換成“對部署、通信、監控等方面有影響的分布式系統問題”。與更傳統的軟件開發一樣，開發易于維護的微服務需要一種慎重周到的方法。

傳播微服務之愛

Bala指出，無服務器和“單一用途微服務”的主要好處之一是，“可以使用合適的工具來完成合適的工作，而不是局限于一種語言、一種框架甚至一種數據庫。”這極大地解放了開發人員，因為現在他們可以編寫與短暫的無服務器函數綁定的微服務，而不是編寫面對尖峰式工作負載、利用率可能低下的整體式應用程序。系統處于空閑狀態時，它會關閉，不花費任何費用。大家共贏。

這還可以使代碼維護起來更簡單。若是整體式應用程序，由于對所有依賴項很難做到面面俱到，更新代碼可能是一大負擔。正如Ophir Gross指出，“意大利面條式代碼處處要檢查，以查看所使用的接口版本，并確保執行正確的代碼。由于代碼更改影響開發階段中很難預測的方面的功能，因此這種代碼常常雜亂無章，通常導致維護工作量加大。”

相比之下，若是基于微服務的方法，微服務中的代碼僅限于業務的一項功能，因此更易于理解。團隊可以使用自己喜歡的實現技術和框架，彼此獨立地運作。

然而，微服務不是沒有自己的風險。具有諷刺意味的是，其中一個風險可能正是開發人員積極接受微服務以逃避的意大利面條式代碼。

分布式意大利面條式代碼

除了其他復雜因素外(調試更復雜、API逐漸變化帶來的難題以及確保服務使用的API及時更新等)，微服務的一個問題是開發人員可能使用他們以類似于當初處理整體式應用程序的方式來構建系統。

人們常常不知道微服務其實需要獨立。比如說，你常?？吹絼摻ǜ鞣N各樣的服務，但是共享一個數據庫。另一個問題是，人們以過去在整體式架構中習慣的方式來編程，這使得服務之間(通過網絡)之間的同步調用鏈變得太長。也沒有注意彼此使用的各種服務可能引起的意大利面條式結構。

設計微服務的關鍵是正確“定義它們的邊界以及它們如何聯系。松散耦合的服務在一個地方含有相關行為，而對系統中與之協作的其余部分了解甚少。”松散耦合至關重要。你希望服務與數量有限的端點進行異步聯系，并且沒有共享數據庫。

當然，這無法消除“意大利面條式代碼2.0”的可能性。強大功能和便利性可能導致開發人員針對無服務器函數創建各種各樣的API調用，局面可能很快變得一團糟。不過，確保服務的松散耦合有所幫助。

原文標題：How to avoid turning microservices into distributed spaghetti code，作者：Matt Asay

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】