NOTE: Beginning with mu 1.5.1, Consul support has been replaced with Amazon ECS Service Discovery. A new mu extension called mu-consul is under development to provide support for Consul as a service discovery provider.
mu is a tool that makes it simple and cost-efficient for developers to use AWS as the platform for running their microservices. In this fourth post of the blog series focused on the mu tool, we will use mu to setup Consul for service discovery between multiple microservices.
Why do I need service discovery?
One of the biggest benefits of a microservices architecture is that the services can be deployed independently of one another. However, this presents a new challenge in that it becomes difficult for clients to know the list of containers to use when invoking the service. Here are three different approaches to address this challenge:
- Load balancer per microservice: Create a load balancer for every microservice and add/remove containers to the load balancer as deployments and scaling events occur. The endpoint address of the load balancer is then shared with clients through some manual process.
There are three concerns with this approach. First, the endpoint address of the load balancer must never change or else all the clients will be broken and require updates to take the new endpoint address. This can be addressed via DNS CNAME records, but still requires that the name chosen for the record must not change. Second, there is the additional cost of a load balancer for every microservice. Finally, there is additional latency introduced with adding a load balancer between each microservice invocation.
- Shared load balancer: Create a load balancer that is shared by all microservices in an environment. The load balancer must have rules for each microservice to route requests by URI patterns.
The concern with this approach is that all traffic is now flowing through a single load balancer which can become a constraint in scaling the entire system. Additionally, the load balancer becomes a shared resource amongst all the microservice teams, potentially impacting a team’s ability to operate independently of other teams.
- Client load balancer: Load balancing from within the client is an approach in which the client has an awareness of all the containers in-service for a given microservice. The client can then load balance between the containers when invoking the microservice. This approach requires a system to provide service registration and service discovery.
The benefit with this approach is there are no longer load balancers between each microservice request so all the concerns with those prior approaches are addressed. However, a new type microservice, an edge service, will need to be deployed to allow clients outside the microservice environment (that do not have access to service discovery) to invoke the service.
The preferred approach is the third approach which uses service discovery and client side load balancing within the microservice environment and edge routing with traditional load balancing for clients outside the microservice environment. This approach provides the lowest latency and most loosely coupled solution for microservice invocation.
Let mu help!
The environment that mu creates for your microservice can manage the provisioning of Consul for service discovery and registration of your microservices. Consul is a sort of phonebook for microservices. It provides APIs for services to register their endpoints and for clients to lookup the endpoints.
Let’s demonstrate this by adding an additional milkshake service to the invoke the banana service from the first post. Additionally, we will create a zuul router service to provide an edge service via Netflix’s Zuul. Zuul is a proxy service that serves as the front door for all requests from outside the microservice environment. Zuul will use Consul for service discovery to determine where best to route the incoming request. Additionally, Zuul provides an excellent location to enforce policies such as authentication, authorization or logging on all incoming requests.
Enabling Consul and Edge Router
The first thing we will want to do is set up our edge router with Zuul. This is just a matter of adding the @EnableZuulProxy and @EnableDiscoveryClient annotations to the Spring Boot application:
@SpringBootApplication @EnableDiscoveryClient @EnableZuulProxy public class ZuulRouterApplication { public static void main(String[] args) { SpringApplication.run(ZuulRouterApplication.class, args); } }
Zuul is configured via the application.yml file in src/main/resources. For each service that we want exposed via the edge router, we add URI path patterns:
spring: application: name: zuul-router zuul: routes: milkshake-service: path: /milkshakes/** stripPrefix: false banana-service: path: /bananas/** stripPrefix: false
In order to enable Consul in your environment, you need to update the environment definition in the mu.yml file. Additionally, you need to configure Spring Cloud Consul to connect to the docker host ip address for service discovery. We will also want to configure Spring Cloud to not register with Consul, since mu will already configure the Registrator agent on your ECS container instances:
environments: - name: acceptance cluster: maxSize: 5 discovery: provider: consul - name: production service: name: zuul-router port: 8080 pathPatterns: - /* environment: SPRING_CLOUD_CONSUL_HOST: 172.17.0.1 SPRING_CLOUD_CONSUL_DISCOVERY_REGISTER: 'false' pipeline: source: provider: GitHub repo: cplee/zuul-router build: image: aws/codebuild/java:openjdk-8
Create Milkshake Service
Now we can create a new service to manage the creation of milkshakes. The service looks very similar to the banana service, with the exception of declaring a Spring RestTemplate annotated with @LoadBalanced to enable client side loadbalancing via Ribbon.
@SpringBootApplication @EnableDiscoveryClient public class MilkshakeApplication { @LoadBalanced @Bean RestTemplate restTemplate(){ return new RestTemplate(); } }
Now we can use the RestTemplate to make calls directly to the banana service. Ribbon will do a lookup in Consul for a service named banana-service and replace it in the URL with one of the container’s IP and port:
@Component public class BananaProvider implements FlavorProvider { @Autowired private RestTemplate restTemplate; private List<Map<String,Object>> getAll() { ParameterizedTypeReference<List<Map<String, Object>>> typeRef = new ParameterizedTypeReference<List<Map<String, Object>>>() {}; ResponseEntity<List<Map<String, Object>>> exchange = this.restTemplate.exchange("http://banana-service/bananas",HttpMethod.GET,null, typeRef); return exchange.getBody(); }
Try it out!
After we have deployed all three services, we can use mu to confirm that all are running as expected.
~ ??? mu env show acceptance Environment: acceptance Cluster Stack: mu-cluster-dev (UPDATE_COMPLETE) VPC Stack: mu-vpc-dev (UPDATE_COMPLETE) Bastion Host: 35.164.117.25 Base URL: http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com Container Instances: +---------------------+----------+--------------+------------+-----------+--------+---------+-----------+-----------+ | EC2 INSTANCE | TYPE | AMI | AZ | CONNECTED | STATUS | # TASKS | CPU AVAIL | MEM AVAIL | +---------------------+----------+--------------+------------+-----------+--------+---------+-----------+-----------+ | i-08e3edc8c644f0534 | t2.micro | ami-62d35c02 | us-west-2b | true | ACTIVE | 3 | 604 | 139 | | i-05bc14a67e53889e1 | t2.micro | ami-62d35c02 | us-west-2a | true | ACTIVE | 3 | 604 | 139 | | i-0b56a0d9572531e9e | t2.micro | ami-62d35c02 | us-west-2c | true | ACTIVE | 3 | 604 | 139 | | i-05b2188a5c575fbeb | t2.micro | ami-62d35c02 | us-west-2b | true | ACTIVE | 1 | 624 | 739 | +---------------------+----------+--------------+------------+-----------+--------+---------+-----------+-----------+ Services: +-------------------+---------------------------+------------------+---------------------+ | SERVICE | IMAGE | STATUS | LAST UPDATE | +-------------------+---------------------------+------------------+---------------------+ | milkshake-service | milkshake-service:9e4bcd9 | CREATE_COMPLETE | 2017-05-12 11:33:05 | | zuul-router | zuul-router:3d4795c | UPDATE_COMPLETE | 2017-05-12 12:09:47 | | banana-service | banana-service:3b62124 | UPDATE_COMPLETE | 2017-05-12 11:32:55 | +-------------------+---------------------------+------------------+---------------------+
We can then use curl to get a list of all the bananas available via the banana-service:
curl -s http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/bananas | jq [ { "pickedAt": null, "peeled": null, "links": [ { "rel": "self", "href": "http://mu-cl-ecsel-144kxqmiry9wi-1411768500.us-west-2.elb.amazonaws.com/bananas/9" } ] } ]
Next we try to create a milkshake using the milkshake-service:
~ ??? curl -s -d "{}" -H "Content-Type: application/json" http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/milkshakes\?flavor\=Banana | jq { "timestamp": "2017-05-15T19:12:56.640+0000", "status": 500, "error": "Internal Server Error", "exception": "org.springframework.web.client.HttpClientErrorException", "message": "429 Not enough bananas to make the shake.", "path": "/milkshakes" }
Looks like there aren’t enough bananas to create a milkshake. Let’s create another one:
~ ??? curl -s -d "{}" -H "Content-Type: application/json" http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/bananas ~ ??? curl -s http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/bananas | jq [ { "pickedAt": null, "peeled": null, "links": [ { "rel": "self", "href": "http://mu-cl-ecsel-144kxqmiry9wi-1411768500.us-west-2.elb.amazonaws.com/bananas/9" } ] }, { "pickedAt": null, "peeled": null, "links": [ { "rel": "self", "href": "http://mu-cl-ecsel-144kxqmiry9wi-1411768500.us-west-2.elb.amazonaws.com/bananas/10" } ] } ]
Now let’s try again creating a milkshake:
~ ??? curl -s -d "{}" -H "application/json" http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/milkshakes\?flavor\=Banana | jq { "id": 3, "flavor": "Banana" }
This time it worked, and if we query the list of bananas again, we see that 2 have been deleted for the milkshake:
~ ??? curl -s http://mu-cl-EcsEl-144KXQMIRY9WI-1411768500.us-west-2.elb.amazonaws.com/bananas | jq []
Conclusion
Decomposing a monolithic application into microservices presents an interesting challenge in enabling services to invoke one another while still keeping the services loosely coupled. Using a client side load balancer like Ribbon along with a service discovery tool like Consul provide an excellent solution to this challenge. As demonstrated in this post, mu makes it simple to enable service discovery in your microservice environment to help achieve this solution. Head over to stelligent/mu on GitHub and get started!
Additional Resources
- Introducing mu: a tool for managing your microservices in AWS – Introducing the motivation for mu and demonstrating the deployment of a microservice with it.
- Service Discovery – Wiki page for using service discovery with mu.
- zuul-router – the repository for the edge router from this blog post.
- milkshake-service – the repository for the milkshake-service from this blog post.
- banana-service – the repository for the banana-service from this blog post.
- Consul – tool for providing service discovery capabilities to microservices.
Did you find this post interesting? Are you passionate about working with the latest AWS technologies? If so, Stelligent is hiring and we would love to hear from you!
|
Stelligent Amazon Pollycast
 |
