如何避免將微服務變成分布式意大利面條式代碼？

譯文
作者：布加迪編譯 2020-02-19 08:00:00

開發(fā)

架構

分布式 用無服務器構建系統(tǒng)很方便，這會導致開發(fā)人員重新使用整體式架構那可怕的意大利面條式代碼（spaghetti code）。

成都創(chuàng)新互聯(lián)主營港北網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,app軟件開發(fā),港北h5成都微信小程序搭建,港北網(wǎng)站營銷推廣歡迎港北等地區(qū)企業(yè)咨詢

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

確實很酷。

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

傳播微服務之愛

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

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

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

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

分布式意大利面條式代碼

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

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

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

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

網(wǎng)頁標題：如何避免將微服務變成分布式意大利面條式代碼？
URL分享：http://www.dlmjj.cn/article/djjessd.html