In today's integrated world, communication is key to success. Inter service communication is plays very important part in service oriented architecture's success.
Lets try to understand importance of service discovery and service mesh in service oriented architecture.
In earlier days of monolithic architecture was the norm. Oxford's dictionary define monolith as "a large, impersonal political, corporate, or social structure regarded as indivisible and slow to change" Monolithic application has multiple modules in one package like authentication module, integration module, data access module, business rules module etc.
Lets take simple example of banking application where we have modules like Accounting module, User module etc. When one module want to integrate with other module it will make rpc call or function call, which generally don't involve any network call.
Below are some limitations of monolithic applications - Application become large and difficult to manage and upgrade
- Building monolithic app will be more due to large size and many test cases
- Monolithic application startup time can increase as well
- Monolithic application is bit difficult to scale
Micro-services world:
Splitting monolithic application in small unit of work as per business functionality will be helpful to overcome some of the limitations describe above. Microservice architecture is defined as
"microservice architecture - is an architectural style that structures an application as a collection of services that are. Highly maintainable and testable. Loosely coupled. Independently deployable. Organized around business capabilities."
If we continue with our banking example, modules can be converted to micro services which are independently scalable and deployable. Please refer below diagram. Here we have multiple instances of account service and user info service while one instance of notification service. Notification service is generic service which send SMS/email to customer about recent transactions.
In this architecture style services are tightly coupled, and they need to know IP address and port of notification service. Also it is not easy to scale notification service without changing accounting / user service. There are various solution to it like load balancer or service discovery.
Service Discovery:
Traditionally application running on physical data center, the IP address of service instances are relatively static and one application can refer to configuration to call another service but in modern time of cloud computing where services are getting IP address dynamically allocated there is a need for some registry to keep track of various service instances and their location along with service health information.
There are two main service discovery patterns: client‑side discovery and server‑side discovery.
Client Side Service Discovery:
When using client‑side service discovery, the client is responsible for determining the network locations of available service instances and load balancing requests across them. The client queries a service registry, which is a database of available service instances. In below diagram, Client first query the service registry and find out location of Account service and make a call to one of the account service based on load balance logic.
Each service instance during startup register with service registry and service registry keep track of service instance health by heartbeat mechanism.
Netflix OSS is one of the great example of the client‑side discovery pattern.
Server Side Service Discovery:
In server side service discovery client is not aware of routing of request. The client makes a request to a service via a load balancer. The load balancer queries the service registry and routes each request to an available service instance. Similar to client‑side discovery, service instances are registered and unregistered with the service registry.
AWS ELB (Elastic Load Balancer) is one of the popular implementation of server side service discovery.
Service Registry is key component of service discovery. There are various options available for service registry. Some of the popular ones are
etcd is a distributed reliable key-value store for the most critical data of a distributed system, with a focus on being Simple, Secure, Fast and Reliable
Netflix Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.
Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination. It is widely used, with high performance coordination service for distributed applications