Service Publishing and Service Discovery is the integral part of any Microservice Architecture. So it is for Vert.x .
Publishing and Discovering Service can be done very easily with Vert.x and it also provides fault tolerance mechanism with Vert.x's own Circuit Breaker implementation or with the help of Hystrix.
Let's start with Service Publishing and Discovery first.
Vert.x does provide a variety of service types to be published, for Ex:
1) HttpEndpoint
2) EventBusService
3) MessageSource
4) JDBCDataSource
Our discussion will focus mainly on HttpEndpoint, JDBCDataSource. The Service Discovery Codebase can be accessed here.
Let's Start with Service Publishing part first. Service publishing requires two steps to be followed.
1) Creating the required Service Instance.
2) Publishing the Service with the help of a Service Discovery.
For Publishing Service we are using the Server3.groovy verticle. Please note we are publishing the service only after the Server3 verticle is being successfully deployed.
HttpEndpoint Service:
The HttpEndpoint is being created with:
JDBCDataSource Service:
Similarly, the JDBCDataSource service is created with:
The DataBase config basically consists of URL, Driver_Class, user, password and other DB specific parameters.
The error handling during publishing can be handled with the Handler provided as part of publish(.... method.
This is in short a very Basic description of the Service Publishing in Vert.x
Now, Any Service that is published is meant to be consumed.
So, let's move on to Service Discovery and subsequent Service consumption.
As said earlier, Fault Tolerance is an integral part any Microservice Architecture to isolate points of access to remote systems, services and 3rd party libraries and hence stop cascading failures and enable resilience in complex distributed systems where failure is inevitable.
With Service Discovery section Fault Tolerance is inherently related, but we will take it as a separate topic. within codebase, fault tolerance related work could be observed, I would discuss those sections again in our next post related to Circuit Breaker .
HttpEndpoint Discovery
We have defined a Handler for /dataServer2 in Server2.groovy Verticle, because this the relative URI for which HTTPEndpoint is created.
Upon invoking the this endpoint with the corresponding client the Handler will get executed which we will see very shortly.
The Discovery of any service has the following generic steps to be followed:
1) Fetch the the corresponding Record with the Service name with which it is published.
The HttpEndpoint service discovery can be found at Server3.groovy under the method invokeServer2() and this method is being invoked as part of the request handler for the URI /getServer2 i.e.
JDBCDataSource Discovery
For JDBCDataSource Service the steps to be followed for Service consumption is same as above the only difference is we use this service to fetch a JDBC connection and carry out some DataBase activities.
The HttpEndpoint service discovery can be found at Server3.groovy under the method fetchJDBC() and this method is being invoked as part of the request handler for the URI /getJDBC i.e.
In our next post we will try to discuss on Circuit Breaker. Till then Keep Coding and Keep Sharing.
Publishing and Discovering Service can be done very easily with Vert.x and it also provides fault tolerance mechanism with Vert.x's own Circuit Breaker implementation or with the help of Hystrix.
Let's start with Service Publishing and Discovery first.
Vert.x does provide a variety of service types to be published, for Ex:
1) HttpEndpoint
2) EventBusService
3) MessageSource
4) JDBCDataSource
Our discussion will focus mainly on HttpEndpoint, JDBCDataSource. The Service Discovery Codebase can be accessed here.
Let's Start with Service Publishing part first. Service publishing requires two steps to be followed.
1) Creating the required Service Instance.
2) Publishing the Service with the help of a Service Discovery.
For Publishing Service we are using the Server3.groovy verticle. Please note we are publishing the service only after the Server3 verticle is being successfully deployed.
if(!server2AsyncResult.succeeded())
server2AsyncResult.cause().printStackTrace()
else{
println "The Server 2 Deployed Successfully... \n\n So, " +
"Publishing the Service..."
publishService(startFuture,serviceDiscovery,"Server2")
publishJDBCService(startFuture,serviceDiscovery,jdbcConfig,"MY-H2-DB")
}
publishService() method publishes HttpEndpoint with the name Server2 while publishJDBCService() method publishes JDBCDataSource with the name MY-H2-DB.HttpEndpoint Service:
The HttpEndpoint is being created with:
HttpEndpoint.createRecord(....by passing service name, hostname, port and the relative URI for which the endpoint should be created.
JDBCDataSource Service:
Similarly, the JDBCDataSource service is created with:
JDBCDataSource.createRecord(....by passing the service name, DataBase Config and the DB name as the parameter.
The DataBase config basically consists of URL, Driver_Class, user, password and other DB specific parameters.
The error handling during publishing can be handled with the Handler provided as part of publish(.... method.
This is in short a very Basic description of the Service Publishing in Vert.x
Now, Any Service that is published is meant to be consumed.
So, let's move on to Service Discovery and subsequent Service consumption.
As said earlier, Fault Tolerance is an integral part any Microservice Architecture to isolate points of access to remote systems, services and 3rd party libraries and hence stop cascading failures and enable resilience in complex distributed systems where failure is inevitable.
With Service Discovery section Fault Tolerance is inherently related, but we will take it as a separate topic. within codebase, fault tolerance related work could be observed, I would discuss those sections again in our next post related to Circuit Breaker .
HttpEndpoint Discovery
We have defined a Handler for /dataServer2 in Server2.groovy Verticle, because this the relative URI for which HTTPEndpoint is created.
Upon invoking the this endpoint with the corresponding client the Handler will get executed which we will see very shortly.
The Discovery of any service has the following generic steps to be followed:
1) Fetch the the corresponding Record with the Service name with which it is published.
serviceDiscovery.getRecord(....2) Upon Successful Record fetch (as verified from the Hnadler), we get the Service Reference Type
def reference = serviceDiscovery.getReference(ar.result())3) From the Service reference we fetch the client that will be used in invoking of consuming the service.
def client = reference.get()4) Finally we consume the service and fetch the result. The Result in this case will be fetched from Handler for /dataServer2 as described above.
The HttpEndpoint service discovery can be found at Server3.groovy under the method invokeServer2() and this method is being invoked as part of the request handler for the URI /getServer2 i.e.
router.route(HttpMethod.GET,'/getServer2').handler({routingContext->
println " ***** Invoking Server2 with Service Discovery ***** "
invokeServer2(routingContext,serviceDiscovery,circuitBreaker);})
The Codebase can be accessed here.JDBCDataSource Discovery
For JDBCDataSource Service the steps to be followed for Service consumption is same as above the only difference is we use this service to fetch a JDBC connection and carry out some DataBase activities.
The HttpEndpoint service discovery can be found at Server3.groovy under the method fetchJDBC() and this method is being invoked as part of the request handler for the URI /getJDBC i.e.
router.route(HttpMethod.GET,'/getJDBC').handler({routingContext->
println " ***** Fetching JDBC with Service Discovery ***** "
fetchJDBC(routingContext,serviceDiscovery,circuitBreaker);})
This is short very Basic on Service Discovery. Please feel free to share your thoughts and feedback.In our next post we will try to discuss on Circuit Breaker. Till then Keep Coding and Keep Sharing.
No comments:
Post a Comment