使用Akka的微服务

随着移动和数据驱动的应用程序越来越占主导地位，用户要求实时访问所有地方的所有内容。 系统弹性和响应能力不再是“拥有”。 它们是必不可少的业务要求。 企业越来越需要从静态，集中式架构中进行交易，以支持灵活，分布式和弹性的系统。 但是从哪里开始以及采用哪种架构方法仍然有点模糊，并且微服务的炒作只是在软件行业探索各种架构和实现样式的过程中慢慢解决。 有很多方法可以在Java虚拟机（JVM）上或周围实现基于微服务的体系结构。

最有前途的似乎是基于“ 反应宣言”的原则。 它定义了导致大型系统的特征，这些系统由较小的系统组成，这些系统更灵活，耦合松散且可扩展。 由于它们实质上是消息驱动和分布式的，因此这些框架符合当今微服务体系结构的要求。 尽管Lagom在封闭式护栏上提供了一种自以为是的方法，该方法仅支持微服务体系结构，但是Play和Akka允许您利用反应特性来构建微服务风格的系统，但并不局限于此。

使用Akka的微服务

Akka是一个工具包和运行时，用于在JVM上构建高度并发，分布式和弹性消息驱动的应用程序。 Akka“角色”是Akka工具包中的工具之一，它使您无需考虑低级线程和锁就可以编写并发代码。 其他工具包括Akka Streams和Akka http。 虽然Akka是用Scala编写的，但也有Java API。 当人们谈论微服务时，他们专注于“微”部分，说服务应该很小。 我要强调的是，将系统拆分为服务时要考虑的重要事情是找到服务之间的正确边界，使它们与有限的上下文，业务功能和隔离需求保持一致。 结果，基于微服务的系统可以实现其可伸缩性和弹性要求，从而使其易于部署和管理。

Akka文档包含一个简单的物联网管理应用程序的详尽介绍。 它允许用户查询传感器数据。 它没有公开任何外部API来简化事情，仅专注于应用程序的设计，并使用基于actor的API将设备的数据报告给管理部分。 这是它的高级体系结构图。

演员被组织成一棵严格的树，每个孩子的生命周期与父母息息相关，父母负责决定失败孩子的命运。 您需要做的就是将包含嵌套框的体系结构图重写为树。

简而言之，每个组件都管理子组件的生命周期。 没有任何子组件可以超过父组件。 角色层次结构正是这样工作的。 此外，期望组件处理其子组件的故障。 组件的“包含”关系映射为演员的“子代”关系。 如果您查看微服务体系结构，您会期望顶级组件也是顶级参与者。 确实有可能，但不建议这样做。 由于我们不必通过外部协议将各个服务重新连接在一起，并且Akka框架还可以管理actor的生命周期，因此我们可以在actor系统中创建单个顶级actor，并将主要服务建模为该actor的子级。 actor体系结构建立在微服务体系结构应依赖的相同特征上。

您可以在官方的Akka教程中找到有关如何实现IoTSupervisor和DeviceManager类的详细信息。

演员如何交流

查看Device actor，其简单任务是收集温度测量值并根据要求将其报告回来。 当使用对象时，通常将API设计为接口，这些API基本上是抽象方法的集合，这些方法将由实际实现填充。 在参与者的世界中，接口的对应物是协议。 基于actor的应用程序中的协议是设备的消息（代码1）

public static final class ReadTemperature {
  long requestId;

  public ReadTemperature(long requestId) {
    this.requestId = requestId;
  }
}

public static final class RespondTemperature {
  long requestId;
  Optional<Double> value;

  public RespondTemperature(long requestId, Optional<Double> value) {
    this.requestId = requestId;
    this.value = value;
  }
}

我跳过了有关消息订购和传递保证的许多背景知识。 在假设消息可能会在网络中丢失的情况下设计系统是构建基于微服务的体系结构的最安全方法。 例如，可以通过在消息丢失时实现“重新发送”功能来完成此操作。 这就是消息还包含requestId的原因。 现在，查询参与者的职责是将请求与参与者匹配。 DeviceActor的第一张草图：

class Device extends AbstractActor {
// ...
Optional<Double> lastTemperatureReading = Optional.empty();

@Override
public void preStart() {
   log.info("Device actor {}-{} started", groupId, deviceId);
}

@Override
public void postStop() {
   log.info("Device actor {}-{} stopped", groupId, deviceId);
}

@Override
// react to received messages of ReadTemperature
public Receive createReceive() {
   return receiveBuilder()
          .match(ReadTemperature.class, r -> {
                       getSender().tell(new RespondTemperature(r.requestId, lastTemperatureReading), getSelf());
         }).build();
   }
}

当前温度最初设置为Optional.empty（），并在查询时简单地返回报告。 代码3显示了对该设备的简单测试。

@Test
public void testReplyWithEmptyReadingIfNoTemperatureIsKnown() {
  TestKit probe = new TestKit(system);
  ActorRef deviceActor = system.actorOf(Device.props("group", "device"));
  deviceActor.tell(new Device.ReadTemperature(42L), probe.getRef());
  Device.RespondTemperature response = probe.expectMsgClass(Device.RespondTemperature.class);
  assertEquals(42L, response.requestId);
  assertEquals(Optional.empty(), response.value);
}

（代码3：测试设备参与者）

Akka文档中包含IoT系统的完整示例。

何时不使用微服务

如果您的系统过于复杂而无法整体处理，那么微服务是正确的选择。 正如Martin Fowler在其有关“ MicroservicePremium ”的文章中所述。 重点是，甚至不要考虑使用微服务架构，除非您的系统太大，太复杂而无法作为简单的整体构建。 但是，今天的确，多核处理器，云计算和移动设备已成为常态，这意味着所有新系统从一开始就是分布式系统。 这也将导致一个完全不同且更具挑战性的世界。现在的逻辑步骤是将思维从一个系统中的对象之间的协作切换为单个缩放系统的协作。 微服务系统。

翻译自: https://www.javacodegeeks.com/2017/12/microservices-with-akka.html