FinClip金融专业社交协同平台，下一个开源项目可能仅是一个接口

一直想写一篇关于“元框架”（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（Java 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 用例驱动和相关。还可以尝试不同的可用后端。这是一种新的有效的自由，它将激励性能和创新。

对每个人来说：可以考虑帮助完成本文中提到的那些项目，开放接口仍然是全新的事物，它们的未来取决于先驱者的成功。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。