下一個開源項目可能僅是一個接口

凡泰極客導讀：

一直想寫一篇關於「元框架」（Meta-framework）的文章，正好InfoQ翻譯了Eric Anderson的文章，就在此借題發揮吧。

一個合格的架構師，必定對「鬆散耦合」的設計原則有深入的認識、甚至有異常的執着。Meta-framework們，每每給咱們的架構設計幫了大忙：金融業務異常複雜嚴謹，其對應的系統的技術架構徹底是並且必須是業務領域驅動（Domain-driven）的，咱們不會一出場就進入「技術選型」（這不是架構設計，這是IT採購– 若是你的「架構師」是這個類型，我只能替你抱歉），咱們但願對複雜的金融場景進行抽象並提煉出對下層技術的完備要求，咱們一開始的時候不關注用什麼具體的底層技術去實現某個功能，咱們更關心整個邏輯架構中的模塊和組成部分有哪些、它們彼此的關係是什麼、針對一個業務場景可否邏輯上「自洽」；即使到了實施階段，咱們依然但願有足夠的靈活性去替換一些技術組件– 畢竟隨着咱們對業務領域的不斷深刻理解抽象，咱們可能會推翻以前一些決策（例如某些第三方或開源技術的「選型」）。總之，咱們會但願，金融業務纔是架構的核心，而一切第三方支撐組件都儘可能避免在關鍵路徑上– 咱們喜歡抽象，而元框架在這方面幫到了咱們，雖然它們不見得老是好使。

我的對Meta-framework的認識，應該提及源於JDBC– 不錯，它確實能夠稱得上是元框架，從關係型數據庫到NoSQL，除了提供本身的「native API」，每每都提供JDBC的Driver實現。而這又是Java SPI（Service Provider Interface）的典範實現：一方面JDBC的標準API供開發者使用，另外一方面JDBC還定義了專供「服務提供者」進行繼承、派生、實現的接口，例如你本身發明了一個新的數據庫技術，當你要向大衆提供JDBC支持的時候，你實現JDBC的SPI便可（例如JDBC裏的Driver和Connection類）。在Java裏面，採用SPI機制的元框架比比皆是 – JCE、JNDI、JBI等等。這裏不得不提，Java雖然是一門相對「古老」的語言，可是當年的JDK以及相關技術生態的設計思想，讓咱們從中吸收很多營養。

回到證券金融領域，我最想實現的「元框架」是什麼呢？無疑是交易接口 – 咱們最不但願看到的是五花八門的第三方交易系統的對接、或者對某個單一交易系統的依賴。我會設計、制定符合現代響應式編程（Reactive Programming）風格的框架來執行交易委託，我會在這個框架下暴露相應的SPI，我會用那些第三方交易系統的native接口來實現符合SPI的適配器，而後讓這些第三方交易、行情、報盤等等的功能變成可插拔的組件 – 固然，這些適配器由交易系統的廠商來實現、或者在行業社區供券商們貢獻與共享源代碼是一個更加可持續的作法（可是這就要求這個「交易元框架」成爲一個行業共建的標準）。在這樣的框架上，我安心作個人OMS（訂單管理系統）模塊、風控模塊…

凡泰極客的金融專業社交協同平臺FinChat，是Meta-framework的踐行者，咱們在實現社交圖譜的時候，須要用到圖數據庫，在數以十計的選擇中，咱們優先考慮能支持Apache TinkerPop（圖計算元框架）的產品。事實上咱們認爲這是「以客戶爲中心」的 – 例如咱們選用向上提供了TinkerPop實現、向下又支持可插拔大數據存儲的技術，這樣當你部署咱們的平臺時，你能夠重用本身現有的大數據設施例如Spark或者Flink，而不是突然發如今FinChat裏面還封閉着另一個數據庫、與外面的世界造成數據孤島。

不管是設計「元框架」仍是對其積極支持、提供實現，都不是一件容易的事情，由於這背後是誰制定框架標準、可否創建起社區讓廠商們參與貢獻的問題。顯然，在我國目前的金融業IT環境中，沒有這種「合做雙贏」的文化（或者說「美德」？）。不過這不妨礙咱們內部的架構思惟採用元框架理念去解耦外部依賴。

—— 梁啓鴻 凡泰極客 Co-Founder

咱們可能會看到有更多的開放接口和元框架，但它們也有缺點。
深度學習、無服務器功能和流處理有何共同之處？它們除了成爲計算領域的大趨勢以外，支持這些變化的開源項目正在以一種全新的、也許是獨特的方式進行構建。在每一領域中，都出現了僅限 API 專用的開源接口，這些接口必須與許多受支持的獨立後端之一一塊兒使用。這種模式可能會對業界帶來好處，由於這種模式爲開發者帶來了較少的重寫，且易於採用、性能改進和爲公司帶來盈利的承諾。我將在本文中闡述這種模式，並提供有關它的第一手資料，討論它對開源的意義，而後探討咱們應該如何培育這種模式。

一般，新的開源項目既提供了新的執行技術，也提供了用戶編程時所要用到的 API。API 的定義在必定程度上能夠視爲一種創造性活動，它從歷史上借鑑了相似的概念（如 Storm 的 spouts 和 bolts ，或 Kubernetes 的 pods）來幫助用戶快速瞭解如何使用這一新事物。API 特定於項目執行引擎：它們一塊兒構成一個單獨的總體。用戶閱讀項目文檔來安裝軟件，與接口交互，並從執行引擎中受益。

幾個重要的新項目結構不一樣。它們沒有執行引擎；相反，它們是爲幾個不一樣的執行引擎提供公共接口的元框架（metaframeworks）。Keras 是第二大流行的深度學習框架，就是這種趨勢的一個例子。正如建立者 François Chollet 最近試圖解釋的那樣，「Keras 是一個接口，而不是一個端到端的框架。」一樣的，Apache Beam，一種大型數據處理框架，也是一種自我描述的「編程模型」。這是什麼意思呢？你能用本身的編程模型來作什麼呢？答案是：真的並不能作什麼，由於這兩個項目都須要外部的後端。就拿 Beam 這種例子來講，用戶編寫的管道能夠在八個不一樣的「運行器（runner）」上執行，包括六個開源系統（其中五個來自 Apache）和三個專有的廠商系統。一樣的，Keras 也支持 TensorFlow、微軟認知工具包（Microsoft’s Cognitive Toolkit，CNTK）、Theano、Apache MxNet 等。Chollet 在 GitHub 最近的一次交流中簡要描述了這種方法：「事實上，咱們未來甚至會擴展 Keras 的多後端的方面。……Keras 是深度學習的前端，而不是 TensorFlow 的前端。」

類似之處不止於此。Beam 和 Keras 最初都是由 Google 員工在同一時間（2015 年）以及相關領域（數據處理和機器學習）建立的。然而，彷佛這兩個小組都獨立地獲得了這個模型。這到底是怎麼發生的？這對於這個模型意味着什麼呢？

Beam 的故事

2015 年，我在 Google 擔任產品經理，專一於 Cloud Dataflow（雲數據流）。Dataflow 工程團隊的傳奇地位能夠追溯到 Jeff Dean 和 Sanjay Ghemawat 於 2004 年發表的著名論文 MapReduce。與大多數項目同樣，MapReduce 定義了一種執行方法和一種編程模型來利用它。雖然執行模型仍然是批處理的最新技術，但使用編程模型的體驗並不那麼使人愉快，所以 Google 很快就開發了一個更簡單的抽象編程模型 Flume（圖 1 的第一步）同時，對低延遲處理的需求，致使了一個新的項目，該項目使用一般的執行模型和編程模型，成爲 MillWheel（即圖 1 中的第二步）。有趣的是，這些團隊圍繞着這樣的一個想法走到了一塊兒，Flume 是用於批處理的抽象編程模型，帶有一些擴展，也能夠是流的編程模型（第三步）。這一關鍵看法是 Beam 編程模型的核心，當時稱爲 Dataflow Model（數據流模型）。

從 Beam 的故事中，獲得了一套原則：

創新有兩個層次：編程模型和執行模型。過去咱們假設它們須要藕合，可是開放接口挑戰了這種假設。

經過將代碼與抽象解耦，咱們還將貢獻者社區解耦爲接口設計者和執行引擎建立者。
經過抽象和解耦（技術上和組織上），社區吸取創新的速度加快了。
在 Keras 的案例中，考慮以上這些原則。儘管 TensorFlow 很受歡迎，但用戶很快意識到它的 API 並不適合平常使用。Keras 的簡單抽象在 Theano 用戶中已經擁有強大的追隨者，所以它成爲 TensorFlow 的首選 API。從那時起，Amazon 和 Microsoft 分別推出了 MxNet 和 CNKT 做爲後端。此舉意味着，選擇獨立開放接口 Keras 的開發人員如今就能夠在全部四個主要框架上執行，而無需任何重寫代碼。各家組織都在使用全部最聰明的團隊研發的最新技術。像 PlaidML 這樣的新項目，能夠很快找到受衆；Keras 開發人員無需學習新接口就能夠輕鬆地嘗試 PlaidML。

無服務器的故事

就像 Beam 同樣，無服務器框架的開放接口的遠景也像 Beam 同樣，也是在不斷髮展的，並非當即就顯現出來。我記得在 2015 年的《Hacker News》（《黑客新聞》）看到的 JAWS（JavaScript AWS）的公告，就在那一年，Keras 和 Beam 誕生了。幾個月以後，JAWS 團隊在 Re:Invent 上展現了他們的 AWS Lambda 特定框架。它包含了 Lambda 提供的構建、工做流和最佳實現，這就是 Amazon 的功能即服務（Function as a Service，FaaS）。但 Lambda 只是幾個私有云和開源 FaaS 產品中的第一個。JAWS 框架很快就從新命名爲 Serverlessand 併爲新手提供支持。
直到 2017 年 8 月 Auste Collins 宣佈推出 Event Gateway（事件網關）時，無服務器仍然不是一個開放的 API 接口。Event Gateway 是「無服務器架構中缺失的一塊」。即便在今天，無服務器也沒有提供本身的執行環境。Gateway 指定了一個新的 FaaS API，能夠抽象並使用任何流行的執行環境。Collin 對 Event Gateway 的價值主張可借鑑 Keras 或 Beam：「用戶的任何事件均可以有來自任何其餘雲服務的多個訂閱者。Lambda 能夠與 Azure 交互，也能夠與 OpenWhisk 交互。這使得企業獲得了徹底的靈活性，……它還能夠保護你免受廠商鎖定，同時也讓你對將來可能帶來的任何其餘事物保持開放。」

驅動力

做爲風險投資者，我發現本身在問一些懷疑的問題：元框架是真正的趨勢嗎？這一趨勢的背後是什麼？爲何是如今才發生？這裏的一個關鍵因素固然是雲託管服務。
實際上，Google 內部全部的託管服務都採用了獨特的 Google 特定 API。例如，Google 的 Bigtable 是第一個 noSQL 數據庫。但因爲 Google 不肯透露細節，開源社區就想出了本身的實現方案：HBase、Cassandra 等等。將 Bigtable 做爲外部服務提供意味着要引入另外一個 API，以及一個要引導的專用 API。相反，Google Cloud Bigtable 是使用兼容 HBase 的 API 一塊兒發佈的，這意味着任何 HBase 用戶均可以採用 Google 的 Bigtable 技術，而無需更改任何代碼。提供開放接口背後的專用服務彷佛是 Google Cloud 的新興標準。

其餘雲廠商也紛紛效仿。Microsoft 在每一個轉折點都在擁抱開源和開放接口，而 Amazon 被客戶所逼，很不情願地擁抱開源和開放接口。這兩家公司最近共同推出了 Gluon，這是一個開放的 API，像 Keras 同樣，能夠在多個深度學習框架上執行。雲廠商在開放的、被普遍採用的 API 後面公開專有服務的趨勢，對用戶來講不啻爲一場勝利，用戶所以能夠免於廠商鎖定，而且能夠輕鬆採用。

展望將來

隨着雲服務的增長，複雜性和創新速度也在不斷提升，咱們有望可以看到更多開放接口和元框架的出現，但它們也有缺點。額外的抽象層引入了間接性。調試可能會變得更加困難。功能可能會滯後，或者根本不受支持；接口可能提供執行引擎共享的訪問功能，但省略了複雜或不多使用的增值功能。最後，一種新的執行方法不見得能當即適用於現有的 API。好比，PyTorch 和 Kafka Streams 最近愈來愈流行，但它們尚未符合 Keras 和 Bram 提供的開放接口。這不只給用戶帶來了困難的選擇，並且對 API 框架的概念也提出了挑戰。
綜上所述，如下是一些取得成功的建議：
對 API 開發人員來講：當你發如今 API 上話費大量時間在討論可有可無的雜事時，請考慮：
（1）它自己就是一個創新載體。
（2）與整個行業合做，把事情作好。

這就是開源社區和治理方面的關鍵所在。要在分佈式系統中達成共識是件很困難的事情，但 François Chollet、Tyler Akidau 和 Austen Collins 在他們各自的領域都作了出色的工做。例如，Clooins 一直在與 CNCF 的無服務器工做組合做，將 Cloud Events 創建爲行業標準協議。

對服務開發人員來講：最重要的是關注性能。開放接口如今是你的髮型渠道，讓你能夠專一於成爲最佳的執行框架。偉大的技術，將不會再有被那些不肯嘗試或採用的落伍者所束縛的風險。因爲轉換成本低，開發者將能夠很容易地看到改進。觀察基準測試將成爲標準作法。
對用戶來講：有關這些開放接口的社區將會變得活躍。用戶須要這些社區保持活躍，以保持 API 用例驅動和相關。還能夠嘗試不一樣的可用後端。這是一種新的有效的自由，它將激勵性能和創新。

對每一個人來講：能夠考慮幫助完成本文中提到的那些項目，開放接口仍然是全新的事物，它們的將來取決於先驅者的成功。

英文原文：
https://www.scalevp.com/blog/...

本文由微信公衆號 「 InfoQ 」受權