Richard Nicholson谈OSGi联盟与云计算

个人简介 Paremus的CEO，同时担任OSGi的董事会的成员。

EclipseCon是在Eclipse社区中关注于分享最佳实践、深刻见解、案例研究以及创新的会议，并且在更为广阔的世界中关注软件开发。其目标在于为社区创建一个论坛，从而能够互相学习、联络共同爱好者并帮助生态系统实现繁荣发展。

   

1. 现在我正在EclipseCon 2013上，与Richard Nicholson坐在一起，他是Paremus的CEO以及OSGi的董事会成员。最近这一周，关于OSGi未来的走向以及它如何适应广泛的基础设施已经有了很多的讨论，这些基础设施由Amazon等公司来提供。OSGi该如何进化以适应存在于云环境之中？

现在我正在EclipseCon 2013上，与Richard Nicholson坐在一起，他是Paremus的CEO以及OSGi的董事会成员。最近这一周，关于OSGi未来的走向以及它如何适应广泛的基础设施已经有了很多的讨论，这些基础设施由Amazon等公司来提供。OSGi该如何进化以适应存在于云环境之中？

   

2. 那样的话，云的理念可能就会是启动一个含有标准OSGi类型容器的虚拟机镜像，然后得到需要的bundle，并在运行时将其下载和启动起来？

我认为很大程度上是这样。你的环境开始的时候只含有最小的内容，所以你的虚拟机基本上就是用来对物理资源进行划分，你会将其进行拆分，然后说“好了，小型的、中型的以及大型的VM都已近在这里了，在节点上已经运行了一个代理或框架”，这个框架可能会说“我已就绪，可能会位于特定的分组之中”，也就是David所指的生态系统或分区（zone），“小的VM，已经准备就绪了”。接下来，基本的理念在于将描述和根元素（root）注入进来，这样的话，你就会是一台分析服务器，而解析器（resolver）会说“我需要这些bundle，并会将它们拉进来、装配并创建服务，所以一切都是动态组装的，实现了按需取用”。这样做的优势在于你不会通过网络传递很大的虚拟机镜像，而只是拉入一些很小的bundle。

   

3. 这是否有助于更新应用并且保持应用的最新状态？

很大程度上是这样的，因为那样的话你只需涉及到描述，并且只需拉入进来一个bundle，修改针对于你所拥有的结构的一个bundle，这意味着在大型的云环境中，传输的负载会大幅度降低，在基础设施领域这会带来成本的节省。但更为重要的是，回到可维护性的问题上，系统很复杂，因为它们需要这么复杂，它们在做复杂的事情，尤其是在金融服务业、重工业、大数据等领域，但是你依然希望有一些方式来处理它而模块化为你提供了一种这样的机制，使其很容易管理并进行增量式地更新。所以，坦白来讲，联盟目前所做的事情更多的是增量式的，而不是大数据或云，你必须要预先规划或关注未来两年或五年内应用会是什么样子的。显然，现在要快速地做事请总是会有压力。

Alex：你提到了快速地做事情，我猜想在这种系统中你会增加敏捷性，或者说通过持续部署使速度得到了提升。

Richard Nicholson:确实是这样。所以，目前我正在编写一份白皮书讨论结构性的模块化（structural modularity）与敏捷过程之间的关系，我之所以开始做这件事是因为我发现如果不提及结构性模块化的话，很难去讨论敏捷。（这篇白皮书已经征得Richard Nicholson先生的同意，近期将会把翻译版本发布到InfoQ中文站上——译者注）这有点类似于你要将看板（Kanban）应用到汽车的前期生产之中，但是还需要工程师去锯木头并且要手工制作电缆将引擎放进去，这根本就没有意义。敏捷过程、Scrum、Kanban只有在你具备生产线能力以及持续集成时才有意义，而这两者基本上都是基于模块化的，从Scrum的角度和工作进度来看，这些用来放在一起的独特的组件可以很快地展开周期性的工作，你需要一个细粒度的东西。那么，我们所使用的模块化格式是什么呢？那就是OSGi。我感到有些意外的一点就在于，这两个领域没有紧密地结合在一起，所以这是一个尝试来促进这种交流，我们会将它的副本发送给你们并会在各种地方进行推广，以说明我们所讨论的是同一件事情，这两个元素都是你所需要的，你需要结构化的代码也需要取得进展。当前，行业内在较多地关注进展而几乎都认为“结构性模块化很难去涉及”，所以第二点就无法实现。

Alex：如果你能够通过停止VM并重新启动它来安装新软件和模块新版本的话，这是很好地，我想OSGi为这个过程带来的动态性。

Richard Nicholson:它确实是这样的。在OSGi栈中整个服务层都是以Deutsch的（分布式系统）谬论以及网络计算作为前提的，即便它们位于同一个VM中，其理念也是服务可以来去自如，我会动态地查找和重新装配，我们通过RSA实现将其进行了跨网络扩展，这样网络就是远程的，因为网络的问题，服务很可能失败或再次可用，OSGi能够理解到这一点。在某种程度上，我觉得可以将OSGi远程模型视为一些老的Java JINI领域中理念的自然延续，它们所面临的场景就是事情发生了变化或者事情的状态被破坏了，让我们构建能够应对这一点的Java系统；OSGi RSA实现考虑到了这些理念并且是以一种更为优雅的方式。

   

4. 在分布式云环境中，它们如何互相发现并进行交流？

关于OSGi以及这个规范的编写方式，有很好地一点，那就是这个栈（stack）实际上是模块化的，你可以采用一个RSA实现，它包含三个组件：发现层（discovery layer）、拓扑管理器（topology manager）以及数据分布提供者（data distribution provider），这样的实现可以用于栈中的每一层。所以，你会发现有些实现所做的事情类似于使用一个中心化的ZooKeeper。其他的会使用SLP来进行相互发现，在我们的产品Paremus中，使用了一个分布式的端对端消息协议，称之为DDS，它实际上用在了美国空军（US Air Force）的命令和控制系统之中，但是我们可以对其做出变化，这是OSGi很好的一个方面，它能够让你在基础设施层具备灵活性。另外的一个分布式提供层是可插拔的，所以如果你想在Java到Java之间通信的话，可以使用RMI实现，如果你想在网络间转移序列化数据可以使用Avro等等，你甚至可以使用像JSON-RPC这样的东西，你具备了一种架构，不过依然具有针对特定的应用使用正确工具的自由。

Alex：在本周EclipseCon上我们已经看到了一些环境，有的人使用动态化的站点，它们的网页使用websocket来与具有即时状态的事情进行通信，我们甚至看到了嵌入式的硬件，如MQTT重新使用到了传输之中。鉴于这样的一种情况，你觉得会不会能有一个仪表盘（dashboard）展现所有的云节点的位置、使用情况、发生了什么事情，并且如果它们是CPU密集型的，将会提供决策工具来指导如何进一步地使用资源。

Richard Nicholson:是的，所以联盟正在做这方面的工作，David下午将会展现这个规范的进展状况以及他们所使用的一些架构模型。业内已经有人将这些理念作为逻辑结论应用于解决方案之中，这样的话，你实际上就可以动态地部署基于OSGi的应用，也可以在节点上对其进行组装，不过要基于这些节点的负载，要考虑到协同定位（co-location）问题。比如，我需要将这个功能部署到一个节点上，这个节点有一个市场数据的线缆与其进行连接，因为没有必要将负责定价的人放在后端的办公室之中，诸如此类。同时，可以将这个功能部署到具有足够内存和最低负载的机器上等等。所以，这种高级的分布式划分方式已经存在于一些产品之中了，不过这是下一代的云产品，而不是我们之前所看到的将所有事情放在一起的虚拟机。

Alex：我想你不仅可以根据CPU的使用情况来监控系统的负载，还可以得到调用服务所消耗时间的统计数据并实时监控系统的健康状况。

是的，在我们Paremus中，就具有这种响应处理器（replication handler）理念，这样就可以添加自己的业务逻辑了，所以你可以查看队列的深度，你可以查看历史趋势，当遇到三重魔力日（triple witching，指的是股指期货、股指期权和个股期权同时到期结算——译者注）时，你知道会需要更多的资源，这样就可以基于它进行预先的扩展并且基本上会对一些高等级指标感兴趣而不仅仅是机器没有响应。我认为这是事情的发展方向，这是很好的标准化架构，允许我们构建非常复杂的、真正分布式的云类型环境。所以，我认为联盟的方向是正确的，我们在很多方向上都在同心协力地工作。

Alex：我认为这种环境扩展性很好，不管是添加新的节点还是响应外部的变化或影响，像Netflix所提出的“混乱猴子”（chaos monkey）或者发生因气候而导致的灾难等等。

Richard Nicholson:Taleb这个人曾经写过“Fooled by Randomness”以及“Black Swan”，最近出版了一本书名为“Antifragile”的书，他的写作风格很有意思，他曾经是纽约的商人，我认为从“Antifragile”中可以得到重要的信息，他认为系统分为三种类型：脆弱的（fragile），环境的任何变化都会导致损害，它们就会被破坏掉；健壮的（robust），面对环境的变化，它们能够幸存下来；或者是反脆弱的（antifragile），面临环境的变化实际上可以允许它们进行重新配置，系统可能还会得到提升，我们基于环境输入或依赖管理组装OSGi系统的方式，会引导我们达到这种反脆弱的方式，当我将一台新的机器加入到环境之中，我的应用可能就会说“有了一个更好的资源出现了，它比我现在正在运行的要好，我要重新进行部署，我要组装和使用那里的FPGA，所以我需要用到那些能够使用它的库”。同时，还会有难以预料的事情发生，假如我们失去大量的数据中心，它依然会尝试进行重新装配并保持运行。所以，我认为，我们将要面临的系统会作为PAS层的一部分，它们的行为会按照这样的方式，它们可以在任何环境中发挥作用。而在过去的十多年中，运维类的数据中心是这样的“不要碰它，它正在运行，不要管它”，时间并没有在前进而是停止了，这样就会构建出很脆弱的系统和业务。所以，我们会采用不同的方式，这种方式会打破它，让我们打破它并确保能够恢复，现在我们会再一次将其打破。

   

5. 如果有人想使用这种类型的后端系统来提供功能，比如说想要提供站点或Web应用程序，在前端会有类似于负载均衡器的东西，但是它会了解云，因此可以知道要路由到哪个元素上，这一点该如何进行映射呢？

总会有办法做到这一点的，我可以介绍一下我们是如何做的。我不知道你本周稍早的时候是否去过Neil Bartlett的讨论会，我们正在论证Nginx，它实际上是由C所编写的，但是我们对其进行了封装使其看起来像一个OSGi bundle。因此，我们做的就是我们所说的“OSGi具有很强大生命周期管理配置以及元数据集标准，让我们普遍地使用它”。我们有了这样一个bundle，当把部署它环境之中时，就会安装Nginx并启动它，我们就可以坐下来等待了，当有新的端点（endpoint）添加进来时，其余的端点会与其通过RSA进行通信，有新的端点了，Nginx配置会进行重写并且指令会通知动态重启Nginx，以应对云环境的扩张（expanding）和收缩（contracting）。

Alex：这些实际上都是在运行期通过重新配置引擎在运行中完成的，一个节点坏掉了，你必须要将其移除、进行配置后，节点会再次可用。

Richard Nicholson:是的，你可以添加一些响应式的行为，它会监控Nginx的负载并且触发扩张或伸缩后端Web服务，这样就会形成一种反馈环路。但是，我认为这种模块化所带来的动态性是未来云的发展方向、下一个阶段同时也是宏伟蓝图。

   

6. 这里很明显讨论到了基于原生C的应用，在原生领域中如果有的东西具有一组库或者一组依赖的话，这会是问题吗？

这是一个很好的问题。当然，如果要封装一个组件，或任意的制件（artifact）成为一个OSGi bundle，我们会有一组元数据，它们描述了需求和功能（requirement and capability）。这样的话，在逻辑上我们下一步要关注的事情就是使用OSGi的需求和功能元数据拉入这些库和功能。

Alex：这样的话，你就可以使用解析器（resolver）来得到所有的内容、在一个独立的运行时环境中搭建起来并让它带着这些东西运行。

Richard Nicholson:是的。重要的一点在于它是一个连贯的方式，它跨越了你所有的资产。明天还会有Simon Kaegi的一个主题，我认为他的名字是这样的，他来自IBM，他正在关注的是OSGi中的JavaScript，同样是JavaScript如何使用OSGi的服务层。这也是OSGi框架中多个事情所共同的理念，在用于其他的事物方面，OSGi规范实际上是非常通用的。只举一个方面，我们正在封装Erlang并实现一些这样的技巧，Erlang组件马上可以就绪，我们可以看到元数据、生命周期以及配置规范的适用范围远远超越了Java。

   

7. 关于其他的语言，我们在过去曾经看到过有人在C 中实现OSGi的方式，这里也可以联系到JavaScript中的模块。你认为OSGi所采用的方式是否适用于这些环境，或者它只不过是在处理依赖的时候建立一个统一的视角？

我认为刚刚所讨论的是“让我们使用全线（across the board）的元数据与生命周期”，因为这是一个很简洁的模型，可以用它做任何的事情。我们可以使用服务模型作为很多事情的一部分。实际上这种处理代码的方式，也就是将其拆分为多个单元并借助运行时容器装配在一起可以用于很多种语言之中，但是对其他的语言并不适用。我知道有一些组织已经做了C/C++实现的OSGi规范，他们所做的基本上就是安装代码bundle并复制Java中所做的事情，有一些组织在协同工作试图在联盟之下针对这个领域产生一个标准的规范。对于像Python这样的情况，这些并没有什么意义，但是元数据中的服务层就会真的有意义了，对于一些函数式语言，Scala能够很好地与OSGi协同，Haskell也会很好，彼此之间有着巨大的差异，但是元数据和服务层依然是很有意思的。所以，我认为应该鼓励在这样一个框架下有多个数据集成的分层，而不是将OSGi作为一个单独的层来解决所有的事情。

   

8. 企业级规范什么时候能出来，其发布频率如何，它最快可能什么时候发布？

你现在问我这件事，但是对这些日期我从来不太了解，要询问这些问题比较合适的人是上午还在这里的David。我觉得R6会在2014年1月份发布，所以我们此时正按照这个时间表在工作，在企业级那边，为了这个释放版本有很多规范正在进行构建之中。在核心规范方面，我实在不知道了，它在时间上往往是一致的，它们应该是在一起的，就像现在这样，但是我确实需要找一个这个领域的人来跟你谈论规范发布时间表的事情。

   

9. 我知道OSGi（联盟）的一种工作方式就是创建很多的征求评议书（requests for comment）或RFC，这是事情的起点。可能会出现的情况是他们会将其进行打包并填充到2014年1月份所发布的企业级规范之中。对此会不会有范围的概念呢，也就是以单个组件的形式来做这些事情并在稍后的步骤中有一些协同的集合而不是每年做一次，从而可以提高正在做什么的可见性并让规范尽快出来？

我认为毫无疑问是有增加可见性的强烈要求，所以最近我们开始做RFC的公开版本，在通过内部评估过程之后，这些就可以复制出去请求公开评议，针对云的RFC刚刚获得通过，希望分布式事件的部分也能如此。我认为目前，它们打包在一起并同时整体发布一部分原因是资源的问题，这样的发布过程更易于管理，如果有更多资源的话，我们就可以开始进行一些拆分并且更加渐进式地进行处理，这只是我个人的观点，我认为这是一个很好的主意，因为你可能会遇到这样的情况“现在一下子有了500个规范，对它们进行评议吧”，你也许只对其中的几个感兴趣，如果我们能够以一种密切相关的方式来进行发布的话，可能按照你所建议的方式那时就可以将相关方集中在一起了。

   

10. 那么，如果人们想了解OSGi联盟的更多信息或更多的与其产生关联，他们有什么机会吗？

有很多的事情你可以做，我们有一个社区的wiki站点，它已经建立起来了并且在缓慢地创建非常好的内容。最近，正在做的一件事就是将各种构建工具的信息添加进去，我们已经有四五个了，有两三个是与BNDTools相关的、我认为还有一个是与PDE相关的、还有Maven、Ant等等。在这里你想要使用什么就可以做什么，这就是如何使其变得更为简单的，显然这会是一件持续进行的事情，另外还会有一些样例和最佳实践会放到上面去，这是一个很好的起点。在OSGi联盟站点上有成员和其他相关的信息，如果你正在使用OSGi，那么显然我们希望你能加入进来成为支持者（supporter），这是零成本的；如果你想参与到规范制定之中，联盟会有一个加入的费用，在过去的几年里，我们对组织进行了一些修改，所以现在这个价格已经是最低了，你可以每年花费5000美元成为一个贡献组织（contributing associate），这样你就可以看到正在制定中的规范了，你可以参与到EEG以及核心团队中等等。最后，还有用户组；我们发现用户组正在快速的扩张，我知道英国的用户组是由Mike Francis担任主席，他在Paremus工作，目前有超过200人了，在适当的时候，我们会创建另外的一个用户组，这已经有一段时间了，但是我们在华盛顿特区有了一个新的用户组，在华尔街有一个正在努力进行组建，现在我们正在与巴西的JUG[Java User Group]进行交流，他们可能会对在那里建立用户组感兴趣，所以我们在那里看到了很多的活动。这能够促成与本地使用OSGi的人见面并交流观点和经验，我们努力让联盟的人参与交流，如果我们做到这一点的话，这也是一件好事，从这个角度来看，会促进参与。

Alex：看起来OSGi在应用服务器运行时环境中已经无处不在了，也是分布式系统如何工作的最大秘密之一。 : It

Richard Nicholson:我认为在很长时间之前就是这样了，超过十年了，从1998年它刚刚创建之时，我们看到过很多时尚和新颖的技术，这是一个新的很好的趋势，其背景就是OSGi在缓慢地获得增长，正如你所言，我认为在企业级领域所有的应用服务器都是基于OSGi的，在联盟中，所有主要的中间件公司都加入了进来，OSGi的采用在增长，并且我们发现它在呈加速状态。我认为这是很基础的，我觉得大多数大型的组织会学习到一些关于可维护性的事情，在Java中模块化可以实现这一点，OSGi是这一切的标准，人们会开始做出改变。我们去年在各种地方进行培训，我们Paremus在悉尼做过一个session，这是第一次在地球的另外一端南半球举行，过去两年通过这种密集的培训，我们发现有明显的改观。

Alex：非常感谢您，Richard Nicholson。

Richard Nicholson:谢谢你，Alex，乐意之至。