What the hell is vert.x? From getting started to almost giving up

Wildebeest technology

JiaoMa Tech is a good company focusing on technology

【 Technical Lecture Hall 】

What the hell is vert.x? From getting started to almost giving up

Vert. X is a lightweight, high-performance application platform based on the JVM.

Let’s start with TechEmpower’s benchmark.

• TechEmpower Framework benchmark project: Performance comparison of many Web application frameworks that perform basic tasks such as JSON serialization, database access, and server-side template composition

• Address: www.techempower.com/benchmarks

• Test environment on cloud: 4 core /14GB/ temporary storage :200GB(SSD)/ gigabit

A single SQL query ranked No1

Compound SQL query, rank No3

Select * from ‘No1’

Data updated, ranking No3

Vert.x performed well in performance benchmarks.

Postgres and vert. x can benefit performance when used together in applications.

Netty is awesome.

What is vert.x?

• Vert.x is a lightweight, high-performance application platform based on the JVM.

• Reative development suite on the JVM

• Based on fully asynchronous Java server Netty.

• Supports multiple programming languages simultaneously.

• Asynchronous lockless programming.

• Excellent distributed development support.

• https://vertx.io/

The multilingual nature of vert. x

• You can use vert. x with a variety of languages, including Java, JavaScript, Groovy, Ruby, Ceylon, Scala, and Kotlin.

• Vert.x doesn’t preach what language is best – choose your language based on the task at hand and your team’s skill set.

• We provide idiomatic apis for every language vert. x supports.

Building Reactive Micoservices in Java

Vert.x provides a complete toolkit for building reactive microservices platforms in Java.

Including Web, Data Access, Reactive, Microservices, MQTT, Authentication and Authorisation, Integration, and Event Bus Bridge, Devops, Testing, Clustering, Services, and more.

General purpose

• Vert.x is very flexible – whether it’s simple Web utilities, complex modern Web applications, HTTP/REST microservices, high-volume event processing or comprehensive back-end message bus applications, vert. x is perfect for that.

• Vert.x is used by many different companies for everything from real-time gaming to banking and everything in between.

• Vert.x is not a restrictive framework or container, nor do we tell you the right way to write your application.

advantage

• Vert.x is lightweight – vert. x core size is about 650kB.

• Vert. X soon.

• Vert.x is not an application server.

• Vert.x is modular.

• Vert.x is ideal for creating lightweight, high-performance microservices.

What is Verticle?

• Verticle is a block of code deployed and run by vert.x.

• By default a vert. x instance maintains N (by default N = number of CPU cores x 2) Event Loop threads.

• Verticle instances can be written in any vert.x supported programming language, and a simple application can contain Verticle in multiple languages.

• You can think of Verticle as an Actor in an Actor Model.

• An application is typically composed of many Verticle instances running simultaneously in the same vert. x instance.

The type of Verticle

• Stardand Verticle are the most common type of Verticle — they always run on the Event Loop thread.

• The Worker Verticle runs on threads in the Worker Pool. An instance should never be executed simultaneously by multiple threads.

• Multi-threaded Worker Verticle will also run on threads in the Worker Pool. An instance can be executed by multiple threads at the same time (note: therefore it is up to the developer to ensure thread-safety).

Standard Verticle

• When Standard Verticle is created, it is dispatched to an Event Loop thread and executes its start method in this Event Loop. When you call a method in the Core API on an Event Loop and pass it to a handler, vert. x guarantees that those handlers will be executed with the same Event Loop as when the method was called.

• All code in the Verticle instance executes in the same Event Loop (as long as you don’t create your own thread and call it!).

• That means you can write all the code in your application in a single-threaded fashion, leaving vert.x to worry about threads and scaling. You don’t have to worry about synchronized and volatile, and you can avoid the race conditions and deadlocks that are common in traditional multithreaded applications.

Worker Verticle

• Worker Verticle is similar to Standard Verticle, but instead of being executed by an Event Loop, it is executed by a thread in the Worker Pool in vert. x.

• The Worker Verticle is designed to invoke blocking code that does not block any Event loops.

• If you don’t want to run blocking code using Worker Verticle, you can also use inline blocking code directly in an Event Loop.

• If you want to deploy Verticle as a Worker Verticle, you can set it up with the setWorker method.

• The Worker Verticle instance will never be executed simultaneously by multiple threads in vert. x, but it can be executed by different threads at different times.

Multi-threaded Worker Verticle

• A multi-threaded Worker Verticle is similar to a normal Worker Verticle, but it can be executed by different threads simultaneously.

• Multi-threaded Worker Verticle is an advanced feature and will not be required by most applications. Because these Verticle are concurrent, you must be careful to use standard Java multithreading techniques to maintain Verticle state consistency.

Example for deploying Verticle

vertx.deployVerticle(“com.mycompany.MyOrderProcessorVerticle”);

vertx.deployVerticle(“verticles/myverticle.js”);

vertx.deployVerticle(“verticles/my_verticle.rb”);

Event Bus

The Event Bus is responsible for communication between Verticle.

Actor concurrency model

• In the Actor concurrency model, its hero is Actor, which is actually a kind of Worker thread that communicates with each other through messages (in vert. x, the message medium between them is the Event Bus) that are sent asynchronously and in parallel.

• The state of all actors is maintained by the Actor itself and cannot be accessed externally unless it itself exposes an interface to access its state.

• Communication between actors uses messages;

• An Actor can send messages to another Actor, or respond to messages from another Actor, while changing its own internal state.

• Actors can block themselves (that is, internal calls to code that blocks IO, but actors should not block the thread in which they run).

• The Actor model is represented by Akka/Erlang and vert. x.

CSP model

• CSP model, also known as Channel model, introduces a new mechanism between workers and workers, called Channel. Worker threads in this model publish messages and monitor each other through Channel, and workers are transparent to each other: It does not know who the message is sent to, nor which Worker sends the message it consumes.

• The Go language uses this CSP model, which is implemented using the coroutine Goroutine and the Channel.

• The Go coroutine, Goroutine, is a lightweight thread (not an operating system thread, but an operating system thread segmented for collaborative scheduling through the scheduler). It is a green thread, also known as a tasklet, which differs from the Corouting coroutine in that it starts a new tasklet when it detects a block.

• Channel: Unix-like Pipe, which is used for communication and synchronization between coroutines. Although coroutines themselves are decoued, there is still coupling between Worker and Channel.

Process, thread, coroutine

• A process is used to improve CPU utilization and reduce context switching during CPU resource scheduling. It is the smallest unit in the operating system.

• Thread is to improve the utilization of resources in the process, break through the defects of the process itself, realize concurrency in the process, it is the smallest unit in the process.

• Coroutines (also known as microthreads) go one step further to improve resource utilization within a thread, reduce the overhead of context switches, and overcome the shortcomings of the thread itself, which is the smallest unit within a thread.

Reactor Model Introduction

• The Reactor pattern, also known as the Reactor design pattern, is the “Reactor pattern” from NIO, which is designed for high concurrency processing.

• Reactor pattern is a design pattern based on event-driven model.

• The idea of overmultiplexing greatly reduces the use of thread resources.

• The main thread (IO processing unit) only listens for an event on the socket file descriptor and immediately notifies the worker thread (LOGICAL processing unit) of the event. In addition, the main thread does not do any real work, reading and writing data, accepting new connection requests, and processing client requests are all done in the worker thread.

01

Reactor Model (1)

02

Reactor Model (2)

03

Reactor Model (3)

04

Reactor Model (4)

Reactor model advantages

• Common features of most design patterns: decoupling, improved reuse, modularity, portability, event driven, fine-grained concurrency control, etc.

• More significant is the performance improvement, that is, each Client does not need to have a thread, reducing the use of threads.

Reactive Programming

• Reactive programming is a programming paradigm declarative based on data stream and Propagation of change.

• Reactive Streams is a specification created by Netflix, TypeSafe, Pivotal, and others.

A reactor in Java

• Netflix (developed RxJava, Hystrix is based on RxJava)

• TypeSafe (Scala, Akka)

• Pivatol (developed Spring, Reactor)

A common reactive programming framework

• Reactor is a Reactive programming framework based on Reactive Streams.

• Based on Reactor, WebFlux implements reactive programming framework in Web domain.

• SpringBoot2.0 is a reactive programming framework based on WebFlux.

• EasyReact client responsive framework.

• ReactiveX series, RxJava, RxJs, rx.Net, RxScala, etc

• Cycy. js and bacon.js are a reactive JavaScript framework

◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆

Wow, you’re amazing. You made it to the end

Studious program ape luck is not bad!