在我还不知道什么叫微服务架构的时候我就使用过它。以前，我写了一些管道程序(pipeline application)，它由一些相互和队列交互的模块构成。自那之后，一批ThoughtWorks的专家也讨论过微服务。Fred George[1]，接着是James Lewis[2]还有 Martin Fowler[3] 都写博文讨论微服务，使得微服务变成了下一个时髦术语，现在每个公司都想使用一些微服务。 现在有一些关于它的标签:endorsements,likes,trainings,甚至two day conferences.关于它的事情听得越多，意识到Apach Camel越来越搭配这种风格的程序。在这篇博文中，我们可以看到Apach Camel框架可以帮助我们用几行Java代码创建微服务风格的应用程序。 微服务实践在微服务架构中没有什么新东西。很久以前就有人设计并实现了很多类似的应用。微服务只是一个新名词，它描述了一种拥有某些特点并遵从某些原则的软件体系风格。它是这样一种架构风格：一个应用或软件由多个各自独立的服务组成，服务之间以一种基于事件的轻量级协议来进行通信。在同样的方式下，TDD帮助我们创建了单一职责的类，微服务原则可以在系统级别上指导我们创建出简单的应用。 本文中，我们将不会讨论微服务的原则或者特性，也不会讨论它到底是实现SOA的一种方式还是一种全新的软件设计过程，我们只是来看一下微服务的常见的实践方式，以及Apache Camel是如何帮助我们实现微服务的。现在关于微服务还没有一个权威的定义，但是如果你看过上面提到的文章或视频，你会发现，下面这些都是微服务的很常见的实践方式: 1. 小规模. 微服务的最基本的原则指的是，每个应用程序规模很小，只专注于处理一件事，并做得非常好。从10 LOC到1000，组成程序规模的大小一直是一个有争议的话题。我个人倾向这样一个观点，程序的规模应该刚好容纳下你的脑袋。很多人的脑袋很大的，所以这还是一个有争议的话题(译者注:此处是黑色幽默，可忽略)。我认为，一旦一个程序只做一件事并做得很好，这只是一个很好的规模，不是一个纳米服务(nanoservice)。The very fundamental principle of microservices says that each application is small in size and it only does one thing and does it well. Camel程序与生俱来就是规模就小.一个同时具有错误处理和helper beans的CamleContext大约有100LOC(line of code).由于有了Camel DSLs和URIs来提取终端地址，通过HTTP或者JMS接受事件，解包并发送响应反馈也不过50行代码(LOC).这对于理解端对端来说足够规模小了，重写或丢弃这样的小规模代码也没有什么遗憾。 2. 具有事务边界。 一个由多个微服务构成的应用就形成了一个最终一致性的系统，而多个这种系统组成的大系统，其整体状态在给定时间点上都是不可知的。这就等于自己给自己设置了一个障碍，使得那些不熟悉分布式应用的团队更难于理解进而采用微服务架构。即使整个系统的状态不固定，使用事务边界来定义消息的归属也是很重要的。 在异构系统中确保事务化的操作可不是那么容易，但是Camel却具有很强的事务支持能力。Camel拥有可以参与事务的终端、事务化的路由和错误处理、幂等的消费者和补偿操作，所有这些能帮助开发者轻松的创建出具有事务化行为的服务。 3. 自我监测。 这是我最喜欢的微服务的特性之一。服务应该提供信息来描述它所依赖的各种资源的状态和它自己的状态。这都是些统计信息，比如处理一个消息的平均时间、最大最小时间，成功和失败的消息的个数，可以跟踪一个消息，内存使用率等等。 这是Camel的开箱即用的功能。每一个Camel应用都会默认搜集JMX统计信息，包括整个应用的信息、私有路由的信息、终端和消费组件的信息等。它会告诉你有多少消息成功处理了，有到少失败了，在哪儿失败的，等等。这些API不是只读性的，JMX也允许在运行期间对程序进行更新和调整，也就是说你可以使用同一套API，根据这些统计信息来相应的调整应用程序。这些统计信息也可以用其它工具来访问，比如jConsole，VisualVM，Hyperic HQ等，也可以用Jolokia通过HTTP进行访问，或者把信息提供给一个叫做Hawtio[6]的很棒的web UI组件。
图 1: Hawtio 如果开箱即用的功能不能满足你的个性化需求，也有一些扩展方式可以选择，比如nagios, jmx, amazon云监控组件和自定义事件拦截器等。 消息型应用的日志是另一个挑战，但是Camel的MDC日志结合Throughput日志器，就可以很容易的来跟踪某些信息或者获取日志信息聚合后的统计信息。 5. 为处理失败而设计。 单个微服务有可能宕机或者一段时间内无响应，但这不应该导致整个系统不可用。所以微服务应该能够容灾并在可能的时候进行恢复。 Camel也有许多有用的工具和模式来处理这些情形。Dead Letter Channel可以确保消息在传输失败的时候不会丢失，在某些错误产生时，重试策略可以借助于自定义后备方法和冲突避免策略，把一个消息进行多次发送。模式方面，比如支持断路器[7]的Load balancer(负载均衡器), 比如Failover(容灾)和其它策略，比如Throttler(节流阀)可以确保某个节点不会负载过重，还有Detour, Sampler也都是在各种出错情形下需要用到的。所以，有什么理由不用这些，而要在每个服务里重新造轮子呢? 6. 高可配置性。 对同一程序应该通过简单的配置就可以达到高可用性，应该很容易扩展来达到可靠性或提高吞吐量，或者换句话说: 通过配置就可以拥有不同程度的自由。当使用DSL创建了一个Camel应用时，我们做的全部工作就是定义消息流，配置各种终端还有配置应用的其它特性。所以说Camel应用被设计的高度可配置化。当所有这些选项都被外化到配置组件之后，就可以按照期望来配置和重新部署应用，根本无需碰触源代码。Camel是如此的可配置化，你甚至不修改任何程序代码就可以用一个终端来替换另一个(比如用JMS来替换HTTP终端)，这一点我们下面会讲到。 7. 具有智能终端。 微服务更倾向于使用REST风格的协议和轻量级消息机制，而不是使用Web Services。Camel则什么都支持。它不需要其它框架就可以支持HTTP。它有这种组件，比如异步HTTP, GAE URL获取服务, Apache HTTP Client, Jetty, Netty, Servlet, Restlet, CXF以及用多种数据格式对消息进行序列化/反序列化。关于队列方面的支持情况，有各种开箱即用的连接器，比如JMS, ActiveMQ, ZeroMQ, Amazon SQS, Amazon SNS, AMQP, Kestrel, Kafka, Stomp, 你能叫上名字的都有。 |
