karaf
这是Jamie Goodyear的客座博客文章(博客， @ icbts )。 他是Savoir Technologies的开源倡导者，Apache开发人员和计算机系统分析师； 他为全球大型组织设计，批判和支持了体系结构。 他拥有纽芬兰纪念大学的计算机科学理学学士学位。
Jamie曾在系统管理，软件质量保证和高级软件开发人员职位中工作，其业务范围从小型初创企业到国际公司。 他在Apache Karaf，ServiceMix和Felix(在Apache Karaf上的项目管理委员会成员)获得了提交者身份，并且是Apache Software Foundation的成员。 他的第一本印刷出版物是与Johan Edstrom合着的《即时OSGi入门》，Packt Publishing，然后是与Johan Edstrom和Heath Kesler一起学习Apache Karaf，Packt Publishing的。 他的第三本也是最新出版的书是《 Apache Karaf Cookbook》 ，Packt Publishing和Johan Edstrom，Heath Kesler和Achim Nierbeck。
我喜欢微服务架构。
关于构成微服务的内容有很多描述，可以按照模式描述很多规范。 简而言之，我倾向于将它们描述为应用程序可以为他人提供服务的最小工作单元。 将这些服务整合在一起，我们便能够构建更大的体系结构，这些体系结构模块化，重量轻且具有适应变化的能力。
从现代系统架构的角度来看，为小型应用程序提供完整生命周期控制的能力是我们的想法平台。 运营商只需部署所需的服务，就地更新它们，并根据需要扩展其他实例。 另一种描述方式是应用程序即服务(AaaS)。 采用特定的小型服务，例如Apache Camel路由或Apache CXF端点，并在不破坏整个应用程序的情况下对其进行调整。 Apache Karaf IS是执行微服务的平台。
为了简化微服务，Karaf提供了许多开箱即用的有用功能。
- 一组经过良好测试的库和框架，有助于为组装应用程序平台消除猜测。
- 通过各种机制(例如Apache Maven)配置库或应用程序。
- 功能描述符，允许一起部署相关服务和资源。
- 控制台和基于Web的命令可帮助您轻松进行精细的控制，并且
- 通过Pax考试简化了集成测试。
我最喜欢的微服务模式之一是将Apache Camel与Apache Karaf上的托管服务工厂(MSF)一起使用。 Camel提供了一个简单的DSL，用于将企业集成模式连接在一起，以将数据从端点A移动到端点B为例。 托管服务工厂是一种模块化模式，用于配置驱动的微服务部署–将ConfigAdmin，OSGi Service Registry和我们的应用程序代码联系在一起。
让我们仔细看一下托管服务工厂的实现。 ManagedServiceFactory负责管理实例化(configurationPid)，创建或更新实例化服务的值，最后负责在服务实例化之后进行清理。 阅读有关ManagedServiceFactory API的更多信息。
public class HelloFactory implements ManagedServiceFactory {
@Override
public String getName() { return configurationPid; }
@Override
public void updated(String pid, Dictionary dict) throws ConfigurationException {
// Create a dispatching engine for given configuration.
}
@Override
public void deleted(String pid) {
// Delete corresponding dispatch engine for given configuration.
}
//We wire in blueprint
public void init() {}
public void destroy() {}
public void setConfigurationPid(String configurationPid) {}
public void setBundleContext(BundleContext bContext) {}
public void setCamelContext(CamelContext camelContext) {}
}我们重写给定的ManageServiceFactory接口以与DispatchEngines一起使用。 DispatchEngine是一个简单的类，其中包含用于使用给定配置实例化Camel路由的代码。
public class HelloDispatcher {
public void start() {
// Create routeBuilder using configuration, add to CamelContext.
// Here ‘greeting’ and ‘name’ comes from configuration file.
from(“timer://helloTimer?fixedRate=true.=1000").
routeId("Hello " + name).
log(greeting + " " + name);
}
public void stop() {
// remove route from CamelContext.
}
}
当我们将这些类作为捆绑部署到Karaf中时，我们获得了功能特别强大的应用程序即服务。 我们为服务提供的每个配置都会实例化一个新的Camel路由器(这些配置文件非常简单地由Greeting和Name组成)。 骆驼的Karaf命令可以对这些路线进行精细控制，从而为操作员提供了简单的管理。
上面的示例的完整代码可通过github获得，并在Packt Publishing的Apache Karaf Cookbook中进行了详细探讨。
诸如上述的微服务架构为诸如驼峰路由或CXF端点之类的常见应用释放了OSGi的强大功能。 这些并不是唯一受益的应用程序。 我想分享一下我们的Karaf成功案例，其中重点介绍了Apache Karaf如何帮助将结构引入到现有的基于大规模微服务的项目中。
想象一下，有成百上千个分发包分布在数十个相互连接的项目上，这些项目实际上已部署在一个普通的OSGi内核中，并祝万事如意，以成功地正常启动。 这就是SDN和NFV的平台OpenDaylight在几个月前发现的情况。
使用Karaf Feature描述符，每个项目都能够将其依赖项，捆绑软件和其他资源组织成一致的结构。 开发了自定义命令以与其核心服务进行交互。 每个项目到项目整体的集成测试都是自动化的。 最后，所有这些项目都已集成到自己的自定义发行版中。
他们的第一个基于Karaf的版本Helium即将发布。 我们都期待着将SDN和NFV社区欢迎到Karaf。
虽然将Apache Karaf 3.0.x系列保持为我们的主要生产目标，但社区一直在忙于开发下一代Karaf容器。
4.0.x系列将通过Felix 4.4.1和Equinox 3.9.1-v20140110-1610附带OSGi Rev5支持，以及基于声明式服务而非蓝图的完全重构的内部框架。 从用户的角度来看，这些更改将产生一个更小，更高效的Karaf内核。 Karaf中将提供蓝图功能，因此您可以轻松安装基于蓝图的应用程序。 您将始终能够在Karaf中使用“蓝图”。 因此，从用户角度来看，主要区别在于，如果需要，您需要依赖Blueprint服务。
这是对Apache Karaf上的微服务架构的非常简要的概述，以及Karaf的未来方向。 我建议任何对微服务感兴趣的人访问OSGi联盟网站，并加入Apache Karaf社区。 对于那些想深入学习高级定制Karaf发行版的人，可以看看Aetos 。 Apache Karaf也是JBoss Fuse的一部分。
翻译自: https://www.javacodegeeks.com/2014/10/the-future-is-micro-service-architectures-on-apache-karaf.html
karaf