66c1281301
Cleaning out a lot of old junk from the code, and one thing lead to another...
* Build is improved, now constructing docker images with 'jib'. Clean build went from 3 minutes to 50 seconds.
* The ProcessService's spawning is smarter. Will now just spawn a java process instead of relying on the application plugin's generated outputs.
* Project is migrated to GraalVM
* gRPC clients are re-written with a neat fluent/functional style. e.g.
```channelPool.call(grpcStub::method)
.async(executor) // <-- optional
.run(argument);
```
This change is primarily to allow handling ManagedChannel errors, but it turned out to be a pretty clean API overall.
* For now the project is all in on zookeeper
* Service discovery is now based on APIs and not services. Theoretically means we could ship the same code either a monolith or a service mesh.
* To this end, began modularizing a few of the APIs so that they aren't strongly "living" in a service. WIP!
Missing is documentation and testing, and some more breaking apart of code.
|
||
|---|---|---|
| .. | ||
| src | ||
| build.gradle | ||
| readme.md | ||
Service Discovery
Contains classes for helping services discover each other, and managing connections between them.
Service Registry
The service registry is a class that keeps track of the services that are currently running, and their connection information.
There are two implementations:
-
A simple implementation that effectively hard-codes the services. This is sufficient when running in docker, although loses some smart features. It is fundamentally incompatible with running the system bare-metal, and does not permit multiple instances of a service to run.
-
A more advanced implementation that is based on Zookeeper, which is a distributed coordination service. This implementation lets services register themselves and announce their liveness, and then discover each other. It supports multiple instances of a service running, and supports running the system bare-metal, where it will assign ports to the services from a range.
To be discoverable, the caller must first register their services:
// Register one or more services
registry.registerService(ApiSchema.GRPC,
ServiceId.Test,
nodeId,
instanceUUID, //must be unique to the runtime
"127.0.0.1"); // bind-address
// (+ any other services)
Then, the caller must announce their instance. Before this is done, the service is not discoverable.
registry.announceInstance(ServiceId.Test,
nodeId,
instanceUUID);
All of this is done automatically by the Service base class
in the service module.
To discover a service, the caller can query the registry:
Set<InstanceAddress<?>> endpoints = registry.getEndpoints(ApiSchema.GRPC, ServiceId.Test, nodeId);
for (var endpoint : endpoints) {
System.out.println(endpoint.getHost() + ":" + endpoint.getPort());
}
It's also possible to subscribe to changes in the registry, so that
the caller can be notified when a service comes or goes, with registry.registerMonitor().
Central Classes
gRPC Channel Pool
From the GrpcChannelPoolFactory, two types of channel pools can be created that are aware of the service registry:
- GrpcMultiNodeChannelPool - This pool permits 1-n style communication with partitioned services
- GrpcSingleNodeChannelPool - This pool permits 1-1 style communication with non-partitioned services. if multiple instances are running, it will use one of them and fall back to another if the first is not available.
The pools manage the lifecycle of the gRPC channels, and will permit the caller to access Stub interfaces for the services.