在知道微服务架构被称为之前，我一直在使用它们。 我曾经使用过由隔离模块组成的管道应用程序，这些模块通过队列相互交互。 从那时起，许多（前）ThoughtWorks专家讨论了微服务。 首先是 Fred George， 然后是 James Lewis，最后是Martin Fowler， 写了关于微服务的博客 ，这使它成为下一个流行语，因此每个公司都希望很少有微服务。 如今有＃主题标签，认可，喜欢，培训，甚至是为期2天的会议 。 我读和听有关微服务架构的内容越多，我就越了解Apache Camel（及其周围的相关项目）如何完全适合这种应用程序样式。 在本文中，我们将了解Apache Camel框架如何帮助我们轻松地用Java创建微服务风格的应用程序。

微服务特征

微服务中没有什么新东西。 如此长时间以来，已经设计并实现了许多应用程序。 微服务只是一个新术语，描述了具有某些特征并遵循某些原则的软件系统样式。 它是一种体系结构样式，其中应用程序或软件系统由单独的独立服务组成，这些独立服务使用轻量级协议以基于事件的方式进行通信。 与TDD可以帮助我们创建分离的单一职责类一样，微服务原理也可以指导我们在系统级别创建简单的应用程序。 在这里，我们不会讨论这种架构的原理和特性，也不会争论它是在实践中实现SOA的方式还是在应用程序设计中采用全新的方法，而是探讨用于实现微服务的最常见实践以及Apache Camel如何实现帮助我们在实践中实现目标。 还没有确切的列表，但是如果您阅读或观看上面发布的视频，您会发现以下是创建微服务的非常常见的做法：

1. 体积小。 微服务的最基本原理说，每个应用程序都很小，并且只做一件事并且做得很好。 大小是可以争论的，数字从10 LOC到1000不等，但从我的角度来看，我喜欢这样的想法：它应该足够小以适合您的头部。 有些人脑袋大，所以即使是有争议的，但是我认为只要应用程序做一件事情并且做得很好，就不会被认为是nanoservices ，这是一个不错的选择。
   骆驼应用本来就很小。 带有错误处理和辅助bean路径的骆驼上下文大约为100 LOC。 借助Camel DSL和URI提取端点的能力，可以通过HTTP或JMS接收事件，将其编组，持久化并发送回一个响应，大约为50 LOC。 它足够小，可以端到端进行测试，重写甚至扔掉而不会感到re悔。
2. 有交易界限。 由多个微服务组成的应用程序构成了一个最终一致的系统系统，其中在任何给定时间都不知道整个系统的状态。 这本身给不习惯使用这种分布式应用程序的团队提供了理解和采用微服务的障碍。 即使整个系统的状态不是固定的，具有定义消息当前所属位置的事务边界也很重要。
   确保跨异构系统的交易行为并非易事，但Camel具有强大的交易能力。 Camel的端点可以参与事务，事务处理的路线和错误处理程序，幂等的使用者和补偿行为，所有这些都可以帮助开发人员轻松创建具有事务行为的服务。
3. 自我监控 。 这是我最喜欢的微服务领域之一。 服务应公开描述其所依赖的各种资源的状态以及服务本身的信息。 这些是统计信息，例如处理消息的平均，最小，最大时间，成功和失败消息的数量，能够跟踪消息等。
   有了Camel，您就可以轻松获得OOTB。 默认情况下，每个Camel应用程序都会收集整个应用程序，单个路由，端点等的JMX统计信息。它将告诉您成功完成了多少消息，失败了多少，失败的地方等等。这不是只读的API，JMX允许还可以在运行时更新和调整应用程序，因此基于这些统计信息，您可以使用相同的API来调整应用程序。 还可以使用jConsole，VisualVM，Hyperic HQ等工具访问信息，这些信息可以使用Jolokia通过HTTP公开，也可以输入到名为hawtio的出色Web UI中。

   
   如果OOTB可用的功能不符合您的自定义要求，则存在多个扩展点，例如nagios，jmx，amazon cloudwatch和新的指标组件，或者将事件通知程序用于自定义事件。
   登录消息传递应用程序是另一个挑战，但是Camel的MDC日志记录与吞吐量记录器相结合，可以轻松地跟踪单个消息或获取聚合统计信息作为日志记录输出的一部分。

4. 专为故障而设计 –每个微服务可能会停机或在一段时间内无响应，但这不会导致整个系统停机。 因此，微服务应具有容错能力，并能够在可能的情况下恢复。
   骆驼也有很多有用的工具和模式来应对这些情况。 死信通道可以确保在失败的情况下不会丢失消息，重试策略可以使用自定义退避方法和避免冲突功能，针对某些错误情况重试发送消息两次。 支持各种模式的负载均衡器， 断路器 ，故障转移和其他策略，限制某些端点不会过载的Throttler，Detour，Sampler等模式在各种故障场景中都需要。 因此，为什么不使用它们而不是在每次服务中重新发明轮子。
5. 高度可配置–应该很容易配置同一应用程序以实现高可用性，对其进行扩展以提高可靠性或吞吐量，或者换句话说：通过配置具有不同的自由度。
   使用DSL创建Camel应用程序时，我们要做的就是定义消息流并配置各种端点和应用程序的其他特征。 因此，骆驼应用程序可以通过设计进行高度配置。 使用属性组件将所有各种选项外部化后，就可以为应用程序配置不同的期望值并重新部署，而完全不必动用实际的源代码。 Camel的可配置性很强，您可以更改另一个端点（例如，用JMS替换HTTP端点），而无需更改我们接下来将介绍的应用程序代码。
6. 使用智能端点。 微服务而不是Web服务更喜欢RESTish协议和轻量级消息传递。
   骆驼偏爱任何东西。 它具有HTTP支持，没有其他框架。 它具有异步Http，GAE URL提取服务，Apache HTTP客户端，Jetty，Netty，Servlet，Restlet，CXF的组件以及用于序列化/反序列化消息的多种数据格式 。 另外，最近添加的Rest DSL使REST在Camel世界中成为头等公民，并且只需创建很多这样的服务即可。 至于排队支持，OOTB有用于JMS，ActiveMQ，ZeroMQ，Amazon SQS，Amazon SNS，AMQP，Kestrel，Kafka，Stomp的连接器。
7. 可测试的。 关于此特性没有共识。 有些人根本不支持测试，而是依赖于业务指标。 有些根本无法承担糟糕的业务指标。 我喜欢TDD，对我来说，能够独立于实际消息流测试我的业务POJO，然后通过模拟某些外部端点来分别测试该流是非常宝贵的。 骆驼测试支持可以拦截和模拟端点，模拟事件，轻松验证期望。 拥有经过良好测试的微服务以实现预期的行为是使整个系统按预期运行的唯一保证。
8. 单独配置。 微服务的最重要特征是它们与其他服务（作为独立Java应用程序）隔离运行。 骆驼可以嵌入到Spring，OSGI或Web容器中。 Camel还可以轻松地作为具有嵌入式Jetty端点的独立Java应用程序运行。 但是，要管理多个流程，所有这些流程都在没有集中式工具的情况下隔离运行，是一项艰巨的工作。 这就是Fabric8的用途。 Fabric8是由开发Camel的人开发的，并得到Red Hat JBoss的支持。 它是一个多Java应用程序供应和管理工具，可以部署和管理各种Java容器和独立进程。 要了解有关Fabric8的更多信息， 这是 Christian Posta的精彩文章。
9. 语言中立。 具有小型且独立部署的应用程序使开发人员可以为给定任务选择最合适的语言。 Camel具有XML，Java，Scala，Groovy和其他具有类似语法和功能的DSL，但是如果您不想完全将Camel用于特定的微服务，则仍然可以使用Fabric8来部署和管理以其他语言并将它们作为本机进程运行。

总结：微服务没有严格定义，这就是美。 这是一种实现SOA的轻量级样式。 Apache Camel也是如此。 它不是功能齐全的ESB，但可以作为JBoss Fuse的一部分。 它不是严格定义的规范驱动的项目，而是可以工作并且开发人员喜欢它的轻量级工具。

引用

1. 弗雷德·乔治（Fred George）的微服务架构 （视频）
2. 微服务– Java， James Lewis 的UNIX方式
3. 微服务由Martin Fowler
4. µ服务由Peter Kriens提供
5. 詹姆斯·斯特拉坎（James Strachan）的Fabric8提供微服务的简便方法 （带视频）
6. 红帽的Fabric8
7. Meet Fabric8： Christian Posta 的开源集成平台
8. James Strachan的Fabric8通过Micro Services轻松实现

翻译自: https://www.javacodegeeks.com/2014/09/apache-camel-for-micro­service-architectures.html