Index-
- Overview
- Creating micro-services
- Locating micro-services
- Micro-service Communication
- Data Handling
Unit 1: Overview
Background :
Cloud application has several (can discuss separately) advantages . to use those advantages we are moving towards the CLOUD-NATIVE application.
Cloud native applications are composed of smaller, independent, self-contained pieces that are called micro-services.
Opposite of CLOUD-NATIVE application is distributed computing which has some 8 fallacies(0-latency,bandwidth is infinite etc) as mentioned in 1994
Salient features
- language agnostic
- should have different phases- deploy and run
- HTTP/REST communication are synchronous in nature and asynchronisation communication adds to loose coupling between services
- Language agnostic(free/doubter) comes to forefront ,with standards like AMQP(Advance Messaging Queue Protocol),Message Queuing Telemetry Transport(MQTT) eding out Language specific mechanism like JMS(Java Messaging Service).
- A saying goes: be liberal in what you accept and be conservative in what you send. that is if you are defining 4 enumeration possibly generated in API request then if in case the 5th one comes up it should log the error and must not fail the application.
Unit 2: Creating micro-service in java
DEFINITION:
Each micro-service should handle a single complete business function.
API-DESIGN
Two strategies: Top-Down and Bottom-Up approach
Mostly used is Top-Down where we first declare the API and then write the corresponding service-code/business code.
SOME NAMING CONVENTION FOR API -DESIGN
- Use noun and plural instead of verb
PRACTICES FOR MAINTAINING OF CHANGE IN API:
- maintain different versions OR,
- pass new version in header
Unit 3 : Locating services
Micro-services are designed to be easily scaled . the scaling is done horizontally by scaling individual services.
With multiple-instances of micro-services you need a method to locate the micro-services and load-balancing over different instances of service you are calling.
Following topics involved:
- Service registry – consul, zookeeper ,Eureka etc.
- Service Invocation -Client-side (sidecar or client Library) or server-side(server proxy)
- API gateway
1.Service registry
Service registry is a persistent store that holds all available instances and route on which they can be reached on.
Four reasons why a MICRO-SERVICE must communicate with service-registry:
- .Registration – After service deployed. it MUST register with service-registry.
- Heart beat – The micro services must send regular heartbeats to show that it is ready to receive requests.
- Service discovery – In-order to communicate with other services, micro-service must call service-registry to get the list of available instances.
- De-registration – when service is down it must be removed from service-registry
Example :
service-registry: consul, Eureka etc.
service-registry are registered by registrar(some service registers have internal to them).
Which Service-Registry to choose:-
Consistency vs Availability:
Most service registries provide partition tolerance and either consistency or availability.A service registry cannot provide all three(tolerance,Consistency, Availability) at same time because of CAP theorem.
(Banking/Finance related service) choose Consistency
Speed(Media Entertainment) choose Availability
For example, Eureka provides availability and both Consul and Apache Zookeeper provide consistency
2.Service Invocation
When a service needs to communicate with another service, it uses the information stored in the service registry. Actual call to micro-service are made either from client-side or from server-side.
Server-Side micro-service calls:
Server-side communication with the micro-service is performed by using a SERVICE PROXY.
SERVICE PROXY is either part of service-registry or a separate service.
micro-services that wants to communicate make a call to WELL KNOWN End points of service proxy .which is responsible for interacting with service registry and forwarding the request.
Load balancing is handled completely on server side.
Disadvantage of Server-Side micro-service calls :
Number of hops is increased.
Advantage:
Testing is easy and proxy can we mocked and tested.
Client-Side micro-service calls:
There is two parts in this process- getting instance(s) of micro-service from service registry and then it makes request to those services.
the micro-service location can be cached on client side to avoid extra path travel in a timeout manner so that if service is down calls don’t fail.
the Request is handled in one of following two ways:
1.Client-library
2.Sidecar
Client Library
It is part of micro-service itself what
it isolates the logic of remote communication. instead of making new we can use 3rd party provided library(Eureka).Other
libraries, such as Netflix Ribbon, provide client-side load balancing.
Sidecar
It is deployed with micro service but runs as a separate process(may be like a config-project corresponding to main project )
A good middle ground between the service proxy and a client library is a sidecar.
Sidecars maintain the service registration with the service registry, and usually also perform
client-side load balancing for outbound calls to other micro-services.
Because sidecars run in their own process, they are independent of language.
Netflix Prana is an open source sidecar that provides the capabilities of the Java based
Ribbon and Eureka client libraries to non-Java applications.
3.API gateway
All requests from external client comes to API-gateway endpoints and then the calls redirected to specific micro service.
UNIT 4: Micro-service communication
Following Topics involved :
- Synchronous vs Asynchronous communicate
- Fault tolerance (resilience)
Synchronous vs Asynchronous communicate
Synchronous communication is a request that requires a response, whether that be immediately or after some
amount of time. Asynchronous communication is a message where no response is required.
Previous Understanding:
Synchronous communication – one message delivered at a time,and other have to wait until previous once release the resource(thread).
Async support for JAX-RS
Although JAX-RS requests will always be synchronous (you always require a response), you can take advantage of asynchronous programming models. The asynchronous support in JAX-RS 2.0 allows threads to perform other requests while waiting for the HTTP response.
Another option is using reactive libraries like RxJava1. RxJava is a Java implementation of ReactiveX2, a library that is designed to aggregate and filter responses from multiple parallel outbound requests.
Asynchronous messaging (EVENTS)
A request from an external client generally must go through several micro-services before returning a response. If each of these calls is made synchronously, then the total time for the call holds up other requests. The more complex the micro service system and the more interactions between micro-services required per external request, the bigger the resultant latency in your system.
If the requests made in the process can be replaced with asynchronous events, then you should implement the event instead.
The microservices pattern requires each microservice to own its own data. This requirement means when a request comes in, there might be several services that need to update their databases. Services should advertise data changes by using EVENTS that other interested parties can subscribe to.
To coordinate the messaging of your application, you can use any one of the available message brokers and matching client libraries. Some examples that integrate with Java are the AMQP broker6 with the RabibitMQ Java client7, Apache Kafka8, and MQTT9, which is aimed at the Internet of Things space.
In brief:
for better throughput or better response time for ALL THREADS we go by Async Communication.
Internal messaging in Micro-service component
Events can be used within a single microservice.
Using internal events can increase the speed of your response to synchronous requests because you do not have to wait for other synchronous requests to complete before returning a response.
TTake advantage of the Java EE specification support for events. Internal asynchronous events
can be done by using Contexts and Dependency Injection (CDI)1.
Possible Application/Conclusion :
To attain responsiveness from the collective APIs introduce MessageBroker(ACtiveMQ,Kafka) .and increase the no. of threads consumers to more than 1. ,because when all the thread will be added to queue and only 1 thread is picked at a time then rest have to wait. But the incoming Thread don’t have to wait it is put in queue.
It is Kind of partial-utilization of Async feature.(because it says 2 things – the new incoming thread should not have to wait for previous one and already placed should be responding – in this case the new incomming don’t have to wait they are put in queue but collective responsiveness is lacking).
When to use Async and Sync ?
Example : 1.GameOn!
Suppose a user is authenticated to play the game.he sends the request to update room(to accommodate new player) to a service say-mapService. the user is expecting a response whether the request is updated or not.
In this case the Synchronous communication (REST) should be used.
Now the DB has been updated for mapService other micro-services needs to be updated of this change this require no response so it can be done by Event(Asynchronous communication).
In Brief:
Async offer fast processing but synchronous is easy and simple to implement.
Example : 2.On-line retail store.
suppose a user is authenticated and places the Order . the order request to a service needs to respond whether it is successful or not so it’s is synchronous and then the other services which subscriber to this event (like inventory management or the sipping details)will need to update it’s db they don’t require the responding back so these are should be Asynchronous communication.
Fault tolerance
A strong case of micro-service architecture is fault-tolerance and resilience.
Resilient to change:
Consumer OF API:
As a Consumer of API you should Accept unknown attributes
Do not issue an exception if you receive an unexpected variable. If the response contains the information you need, it does not matter what else is provided alongside.
But validate the request against the variables or attributes that you need
Do not validate against variables just because they are provided. If you are not using them
as part of your request, do not rely on them being there.
- Accept unknown attributes as part of the request
- Only return attributes that are relevant for the API being invoked
Timeout:
The request must have a timeout. Because we expect services to come and go, we should not be waiting indefinitely for a response.
The asynchronous support in JAX-RS 2.0 has a setTimeout function on the AsynResponse object (see “Synchronous messaging (REST)” on page 34). Tools like Failsafe and Netflix Hystrix have built-in support for timeouts.
CIRCUIT-BREAKERS:
If every-time the timeout issue is occurring then it is not a good way to error out each time, we can give fullback after a limited no. of APIs fail .
The circuit breaker makes a note every time a specific request fails or produces a timeout. If this count reaches a certain level, it prevents further calls from occurring, instead of returning an error instantly
It also incorporates a mechanism for retrying the call, either after a certain amount of time or in reaction to an event.
BulkHeads:
If a compartment of ship fails.it should not sink the whole ship. At each step you should think of removing the dependency.
UNIT 5: HANDLING DATA
Techglot 