下一个开源项目可能仅是一个接口

凡泰极客导读：

一直想写一篇关于“元框架”（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 」受权