微服务框架 - 2020

UBmpO.png

Java社区的新方向 中也说明了一个 Java 社区的趋势,在这个过程中有很多在努力的项目和团队,我们今天就先看看有哪些新的框架。

Spring Boot/Cloud

UBOc6.png

Spring BootSpring Cloud 现阶段仍是最大的微服务框架。大多数读者对其都很熟悉,我们就以 Spring Boot 为标杆,来和其他的框架进行对比。

在最终的 雷达图 中,我们会对比这几种框架的 制品大小 启动速度 功能性 性能 这几个指标。在每个新框架内尽可能举一些比较生动的 DEMO 给大家进行参考。

Eclipse Vert.X

UBZvT.png

Vert.X 如果说起来可能比微服务还略早一些,笔者也曾经为其中文社区翻译过文档,Vert.X 社区因为觉得 Spring 还是太重量级了,对于现在的软件开发来说,我们可能需要的仅仅是一组工具,因此推出了此框架:

Eclipse Vert.x is a tool-kit for building reactive applications on the JVM.

重点也给大家标红了 tool-kitreactive 是他的最为重要的特征,除此之外

  • 轻量级:Core部分代码只有 700kb 左右
  • 快速:techempower benchmarks java 社区少数能打的、
  • 模块化: Vertx的模块化做的非常好,不像 SpringCloud属于拼凑式的模块化

Verticles

Vert.X 比较有趣的基于一种名为 Verticle 的对象进行编程,我们编写函数入口/对象 都是一种 Verticle

1
2
3
4
5
6
7
8
9
10
public class MyVerticle extends AbstractVerticle {

// Called when verticle is deployed
public void start() {
}

// Optional - called when verticle is undeployed
public void stop() {
}
}

因此在设计之处,Vertx 已经考虑到 Hotrestart,对于开发者更容易理解。Verticle 之间的通讯又有点类似于 Actor 的通讯机制,不过值得注意的,Core 部分是不提供跨主机调研的,只能在同一个 Verticle Deployment 进行通讯,因此并不是可以直接等价于 Akka

Web Server

Vert.X 更喜欢将控制权返给开发者,框架封装使用,工具展示本质。因此对于我们来说,如果需要构建一个 web server,我们应该使用如下方式。

1
2
3
4
5
6
7
8
9
10
11
HttpServer server = vertx.createHttpServer();

Router router = Router.router(vertx);

router.route().handler(routingContext -> {
HttpServerResponse response = routingContext.response();
response.putHeader("content-type", "text/plain");
response.end("Hello World from Vert.x-Web!");
});

server.requestHandler(router).listen(8080);

从短短的几行里面,我们可以发现 Vert.x 正如宣传的提供的是一系列的 Tookit 在构建的过程中推荐开发者自己亲手搭建一个系统。

UBfWe.png


不过 Vert.x 这个工具箱很强大,提供了 Web Data Access Reactive IoT Authentication and Authorisation Messaging Integration Event Bus Bridge DevOps Testing Clustering Services Standards 这么多系列的工具,总有一款适合你。

个人还是比较喜欢 Vert.X, 像 GoLanguage 也证明这种基于小工具的组合其实也是可以满足需求的,并且因为足够简单在使用的过程中也比较好去排查问题。

Quarkus

UfLlQ.png

说起 quarkus 就有点厉害了, quarkus 主打的是 GraalVM,在之前的文章中和大家讨论过在 云原生 时代内的 JVM 太过于笨重,从 JVM 尝试解决这个问题的就是 GraalVM,但是 GraalVM 并非是一个无痛的,比如反射就不能使用(需要转化),因此 GraalVM 就好比新能源汽车,我们已经不需要汽油发动机,因此也需要配套的设施来发挥,因此 Redhat 就发起了 Quarkus 项目。

UBgHy.png

A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.

云原生 是其主打特征。

Web Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
@Path("fruits")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class FruitResource {

@Inject
@ConfigProperty(name = "myapp.schema.create", defaultValue = "true")
boolean schemaCreate;

@Inject
PgPool client;

@GET
public Multi<Fruit> get() {
return Fruit.findAll(client);
}

@GET
@Path("{id}")
public Uni<Response> getSingle(@PathParam Long id) {
return Fruit.findById(client, id)
.onItem().apply(fruit -> fruit != null ? Response.ok(fruit) : Response.status(Status.NOT_FOUND))
.onItem().apply(ResponseBuilder::build);
}

@POST
public Uni<Response> create(Fruit fruit) {
return fruit.save(client)
.onItem().apply(id -> URI.create("/fruits/" + id))
.onItem().apply(uri -> Response.created(uri).build());
}
}

整体的使用上,Quarkus 是非常接近 Spring 的体验,不过整体上因为 Quarkus 更加的拥抱云原生,因此并没有在 Cloud 侧的组件做更多的时期,希望用户基于 CNCF 所提供的能力进行工作,这点可能会让开发者很不舒服。悄悄的告诉你(Quarkus底层也会依赖Vertx)

Quarkus is based on Vert.x, and almost all network-related features rely on Vert.x. While lots of reactive features from Quarkus don’t show Vert.x, it’s used underneath.

面向微服务、云原生,编译到 native 以获得超快启动时间、超低内存占用,统一命令式与反应式编程范式,这几点其实新的框架都差不多,Quarkus 更重视“把问题提前到编译期解决”。不过这件事情对于开发者来讲可能就没有什么体感了。

其实也可以理解 Quarkus 基于 Vertx 提供了更好开箱即用的体验,并且和周边生态集成的更加紧密了。

Helidon

UfPsh.png

刚刚也讲了,其实大部分的框架都比较类似了,Helidon 也是如此。提供了

  • Reactive non-blocking database client
  • Supports existing blocking JDBC drivers
  • Relational and non-relational databases
  • Metrics, tracing, health checks
  • Portability
  • Extensibility

值得一说的是对 GraalVM 也是积极支持的。Helidon 将项目分为了 SE MP,对于 SE 作为功能组件存在,MP 则是为了实现 MicroProfile

MicroProfile 说起来就比较厉害了,拉了 IBM RedHat Payara Tomitribe SouJava 下水,准备重新搞标准了 , 天下还苦 Spring 久已, Spring 的确现在看起来有些笨重。

Web Server

1
2
3
4
5
6
7
8
9
public static void main(String[] args) {
WebServer webServer = WebServer
.create(Routing.builder()
.any((req, res) -> res.send("It works!")))
.start()
.await(10, TimeUnit.SECONDS);

System.out.println("Server started at: http://localhost:" + webServer.port());
}

Helidon 应该还算是最不完善的,文档毕竟稀少,代码的话以封装 JDK & Netty 为主。

Micronaut

UfRhS.png

micronautgrails 实属亲戚关系,而 grailsspring 又经常 PY。因此我觉得 MicronautSpring 总有不可告人的秘密。

Micronaut is a modern, JVM-based, full stack Java framework designed for building modular, easily testable JVM applications with support for Java, Kotlin and the Groovy language.

Micronaut 还是有一些有趣的东西,不过和其他家也类似,IOC 是通过 annotation Processor 处理的,也就是所谓的了静态处理。

Web server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Application {

public static void main(String[] args) {
Micronaut.run(Application.class);
}
}

@MicronautTest
public class HelloControllerSpec {
@Inject
EmbeddedServer server;

@Inject
@Client("/")
HttpClient client;

@Test
void testHelloWorldResponse() {
String response = client.toBlocking()
.retrieve(HttpRequest.GET("/hello"));
assertEquals("Hello World", response); //)
}
}

Hello World 看其实和 Spring 没啥却别(更多地方看起来都没啥区别),我还倾向于 Micronaut 仅仅是 Spring 体系的一个马甲。

Lagom

UfWnW.png

Lagom 就一直属于万年老二的状态,以前和 Spring 竞争的 Play Framework,现在用 LagomSpring 竞争,因为 Lagom 的内部通讯基于 Akka Remoting Steam Driver 的机制,可是说是完全独立的一套体系。

UBaW4.png

说到 Lagom 就一定要说到 AkkaActor 这个模型说起都说好,但是实际上都没啥人用 为什么Akka(Actor模型)在中国不温不火?。绝大多数的开发者没有意识到布道师的眼中只有优点是没有缺点的。

对于 Akka 也不深入了解,这个就权当给大家一点开拓视野的资料。

体系之争

现在开源早就过了单兵作战的时代,每一个开源项目的背后企业也是我们应该考虑的。

  • Spring → Pivotal → VMware
  • Quarkus/Vert.x → Eclipse 基金会 → Red Hat 支持
  • Helidon → Oracle
  • Micronaut → Object Computing(Grails、OpenDDS) → Spring 有 PY
  • Lagom → Lightbend(Akka)

前三家都算是家大业大也不怕跑路, Micronaut 就略为弱一点, Lightbend 和其他家有所区别 Lightbend 面向 EE 因此也是为数几家可以提供 企业化 服务的体系。

雷达