Netflix 試圖通過開發者自治調和大規模 API

最近在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包含更少的邏輯以成為更嚴格意義上的資料接口服務，而讓大多數的邏輯圍繞着消息而建構，并在将消息于邏輯自身服務組特定的邏輯層中提供給消費者之前，将該邏輯添加到資料層中。對于第一種方法，難點在于同時同步所有不同的編排，這構成了共享軟體跨越多個服務分組的障礙。對于第二種方法，難點是對于非真實添加的功能，即僅是在各服務間做更大程度上的區分和更細粒度的控制，如何驗證它們所導緻的延遲增加。這個部落格文章最終并未給出明确的抉擇，但是暗示了未來的選擇取決于不同權衡間的妥協。考慮到随着通用工具、庫和消費者連接配接性的需求增長會持續增加更多的獨立自包含服務，是以可能目前并沒有一種完美的解決方案。