service discovery in microservices example

What should we do when microservices start to "hide and seek"?

Imagine you build a cool microservice system. At first everything went smoothly, everyone did their job and the cooperation was pleasant. But slowly, the number of services has increased. Today, a user module will be added, and tomorrow, an order will be placed for service. Suddenly one day, a problem arose: the order service was eager to find the payment service to complete the transaction, but did not know where the other party had moved; the user service updated the address, but the inventory service foolishly continued to ship to the old place. The entire system is like a party without an address book. Everyone looks at each other and can't find anyone they want to chat with. efficiency? Forget it. Confusion and delays became the norm.

This is the awkwardness that happens when "service discovery" is missing. It's not a cool new feature, but a basic order of things. Without it, microservices are a mess and every call feels like an adventure.

What exactly does service discovery do?

Simply put, it is a "real-time address book". In a dynamic microservice environment, service instances will be created or destroyed as the load changes, and their network locations (such as IP addresses) change. The core task of the service discovery mechanism is to automatically register each newly launched service instance and allow other services to query the latest locations of these instances at any time.

It mainly takes care of two things: Registration: After a service instance is started, it actively reports to the "Service Discovery Registration Center" and says "I am here, who I am, and what I can do." Query: When service A needs to call service B, it does not hard-code an address, but asks the registration center: "Hey, what service B is available now? Give me an address." The registration center will return a currently healthy and available instance address.

This is like, you no longer need to remember the fixed workstation number of each colleague, but you have an online seating chart that is updated at any time, and it is clear at a glance who has changed seats.

Why do you have to use it? Can't you save it?

Some people may think, can't I manage the IP list manually? With few and extremely fixed services, it might hold up for a while. But once the scale goes up, manual maintenance becomes a nightmare. Think about it, every time you expand or shrink, or every failover, you have to manually update the configuration of all related services and restart them. This is not only a huge workload, but also a breeding ground for failures. A configuration delay or error can lead to cascading failures.

The benefits of service discovery are real:

• High elasticity: In case of instance failure or new addition, the system can automatically sense and adjust the traffic, and the service will not be interrupted.
• High scalability: Easily expand horizontally, new instances automatically join the cluster, and are transparent to the outside world.
• Simplify configuration: Calls between services no longer rely on hard-coded endpoints, and configuration management becomes extremely refreshing.
• load balancing: The discovery mechanism can usually be combined with load balancing to intelligently distribute requests to the busiest instances.

How does it work in the real world?

Let's look at an everyday example. Suppose you have an e-commerce application. The core services include: user service, product catalog service, order service and inventory service.

1. start up: When a new instance of the inventory service is started (for example, a server is added due to a promotion), it immediately sends a registration request to the service discovery registration center (such as common components such as Consul, Etcd or Eureka): "I am the inventory service, version v1, running at 192.168.1.10:8080."
2. Discover: At this time, the order service needs to deduct inventory to process a new order. It does not contact a fixed IP directly, but initiates a query to the same registration center: "I need an available inventory service instance."
3. routing: The registration center returns one or more currently healthy inventory service instance addresses (such as the above-mentioned 192.168.1.10:8080, and another instance 192.168.1.11:8080). The order service gets the address and initiates a call. Typically, clients will have simple load balancing built in, rotating or randomly selecting these addresses.
4. health check: The registration center will continuously and regularly perform health checks on registered instances (such as sending an HTTP request). If the inventory service instance 192.168.1.10:8080 is down and unresponsive, the registration center will remove it from the available list.
5. renew: When the order service queries again next time, it will only get the still healthy 192.168.1.11:8080 address. Faulty instances are automatically isolated without manual intervention in the entire process.

See, order is established. Each service knows how to find the other, and the system has the ability to heal and grow.

When choosing a plan, where should you focus your eyes?

After understanding the "what" and "why", the next step is naturally "how to choose". Faced with different service discovery tools or modes (client discovery vs server discovery), there are several key points worth pondering:

• Consistency guarantee: In distributed systems, data consistency is crucial. Can your service discovery registry provide strong consistency? This is important to prevent different services from getting different instance lists, causing confusion in calls. Tools based on the Raft protocol usually provide this guarantee.
• health check mechanism: Merely "registered" does not mean "available". Complete health checks (HTTP, TCP, and even custom scripts) can quickly eliminate faulty nodes, which is the cornerstone of system resilience.
• Integration with ecology: Can it be easily integrated with your existing technology stack (such as Kubernetes, Spring Cloud, etc.)? Seamless integration can reduce a lot of custom development work.
• Operation and maintenance complexity: Does it require maintaining a separate cluster, or is it a built-in capability of existing infrastructure (such as K8s)? This is directly related to the operational burden of the team.
• Performance and scale: How many service instances can it manage easily? How high is the latency of the query? Will these become bottlenecks as they scale up?

There is no one-size-fits-all solution. The key depends on your team size, technology preferences, and the urgent needs of your business scenario. Sometimes, starting simple can get you on track faster.

Back to the party where it started

In fact, technical decisions often return to the simplest original intention: Do we want to continue to waste energy in a chaotic game of "hide and seek", or are we willing to build a collaboration platform where all services can communicate smoothly and perform their duties? Service discovery is one of the cornerstones of this platform.

It’s not noisy, but it’s vital. It allows the real advantages of microservice architecture - agility, elasticity, scalability - to be unleashed, instead of being trapped in the quagmire of address configuration. When you next design or system, ask yourself: Can my services easily find each other? If you’re not sure about the answer, maybe it’s time to bring in that “real-time address book.”

After all, a good system should allow services to be like old friends, able to get together at any time, instead of always being on the road to find each other.

Established in 2005,kpowerhas been dedicated to a professional compact motion unit manufacturer, headquartered in Dongguan, Guangdong Province, China. Leveraging innovations in modular drive technology,kpowerintegrates high-performance motors, precision reducers, and multi-protocol control systems to provide efficient and customized smart drive system solutions.kpowerhas delivered professional drive system solutions to over 500 enterprise clients globally with products covering various fields such as Smart Home Systems, Automatic Electronics, Robotics, Precision Agriculture, Drones, and Industrial Automation.