最近在Netflix公司的技術博客網站上，該公司的工程經理Katharina Probst和Justin Becker合作撰寫了一篇博客，內容是關于如何在API環境中維持開發者自治的問題。這篇發布于2016年8月23日的博客帖子題目為“工程上的權衡及Netflix API的重架構”，文中探究了在API環境中使用多種團隊共享的服務時，調和開發者代碼和流程所有權中所存在的難點問題。
當前微服務正在崛起，完全自包含、自維護的軟件棧也正受到軟件工程社區的日益重視（例如使用Docker這樣基于容器的開發很受歡迎），但是這種趨勢與一些用戶的需求是相互矛盾的，因為這些用戶希望能訪問一些不同類型服務的數據，但不希望大量額外地增加自身應用的復雜度。對于圍繞著代碼復用和協作的工業標準最佳實踐而言，它們與微服務間也有著復雜的關聯性，因為它們在外部軟件的微服務中建立了內部依賴。
在這篇博客帖子中，Probst和Becker寫道：“……我們的工作就是去調和貌似沖突的工程原則，其中包括了速度及完全所有權與代碼復用最大化及合并之間的沖突”。鑒于API本身就意味著多個服務間的通信，一個棘手的問題就是如何去維持一個團隊內部所使用數據的所有權問題。如果每個微服務都具有與消費者直接通信的API，那么該微服務必須承擔其所有消費者的各種請求，對請求整體的削弱就構成了一個完全獨立且最大產出的服務。但是如果存在一個用做所有微服務緩存層的獨立API，盡管這意味著個體服務對用戶實際上如何消費自己的數據并沒有多少的控制權，但是這也使得API可以涵蓋所有可能的消費者請求。
Probst曾在QCon 2016紐約大會上報告稱，為更好地適合很多自治應用的需求，Netflix正計劃對自身API進行可能的改進。在Netflix有一個API用于提供微服務與各自API間的編排服務。在由該API承擔所有獨立微服務中一千多種不同設備的消費者請求的同時，也引入了單點故障問題。即該API的宕機將會影響到所有的消費者服務，而不是僅僅影響到一小組相關用戶。為緩解這樣的服務污染的隱患，Probst計劃在未來版本的API中采用容器技術。她在QCon大會的報告中提出：“今后，當某個腳本對一大類情況都存在問題時……當某個設備或設備腳本不可用時，將不會影響到其它的設備，也不會影響到API。”通過保留單一編排API并使用容器分隔過程實現對風險的降低，Probst得以保留與所有面向消費者微服務通信的單一API，進而形成完美的共享工具和服務的平臺。而對很多微服務而言，共享工具和服務是一個臭名昭著的痛點。
雖然Probst已經確定了使用容器去分隔腳本等在內的一些關鍵API決策，但是很明顯還存在其它的一些問題，這些問題尚未給出最優的解決方案。例如該博客帖子的一個主要話題就是，是否應該具有多個編排API，這些API賦予底層服務對編排更大的控制能力；或是讓已有的API包含更少的邏輯以成為更嚴格意義上的數據接口服務，而讓大多數的邏輯圍繞著消息而構建，并在將消息于邏輯自身服務組特定的邏輯層中提供給消費者之前，將該邏輯添加到數據層中。對于第一種方法，難點在于同時同步所有不同的編排，這構成了共享軟件跨越多個服務分組的障礙。對于第二種方法，難點是對于非真實添加的功能，即僅是在各服務間做更大程度上的區分和更細粒度的控制，如何驗證它們所導致的延遲增加。這個博客帖子最終并未給出明確的抉擇，但是暗示了未來的選擇取決于不同權衡間的妥協。考慮到隨著通用工具、庫和消費者連接性的需求增長會持續增加更多的獨立自包含服務，所以可能當前并沒有一種完美的解決方案。
查看英文原文：Netflix Attempts to Reconcile Large Scale APIs with Developer Autonomy
京公網安備 11010502049343號