API Gateway
JANANI VELMURUGAN
Agenda
 Monolithic Architecture
 Microservices Architecture
 Challenges & Limitations
 Solution – API Gateway
 Netflix Zuul
 Demo
Scenario
 Core services grow very quickly as well as whole system complexity
 Hundreds of services involved in rendering of one complex webpage Ex:
Amazon
Monolithic Architecture
 A mobile client retrieves this data by making a single REST call to the
application, such as:
 GET api.company.com/productdetails/productId
 A load balancer routes the request to one of several identical application
instances.
 The application then queries various database tables and return the
response to the client
Microservices Architecture
 Data displayed on the product details page is owned by multiple
microservices
 Shopping Cart Service – Number of items in the shopping cart
 Order Service – Order history
 Catalog Service – Basic product information
 such as product name, image, and price
 Review Service – Customer reviews
 Inventory Service – Low inventory warning
 Shipping Service – Shipping options, deadlines, and costs, drawn separately
from the shipping provider’s API
 Recommendation Service(s) – Suggested items
Direct Client-to-Microservice
Communication
 Client could make requests to each of the microservices directly
 Each microservice would have a public endpoint:
 https://serviceName.api.company.name
 This URL would map to the microservice’s load balancer, which distributes
requests across the available instances.
 To retrieve the product-specific page information, the mobile client would
make requests to each of the services listed in the previous slide
Challenges & Limitations
 Necessity to know all endpoints addresses
 The client in this example has to make seven separate requests
 Makes the client code much more complex
 Perform http request for each piece of information separately
 Merge the result on a client side
 Difficult to refactor the microservices
 Non web-friendly protocols
Solution – API Gateway
API Gateway
 A single entry point into the system
 Handle requests
 by routing them to the appropriate backend service or
 by invoking multiple backend services
 Aggregating the results
API Gateway – Usage
API Gateway - Usage
 Request routing
 Composition
 Protocol translation
Netflix Zuul Project
 Zuul is a gateway service that provides dynamic routing, monitoring,
resiliency, security and more.
Zuul = Spring Cloud + Netflix
Demo - DiscoveryServer
Demo - GatewayService
Demo – Hello/Goodbye Service
NOTE: To create GoodbyeService,
Replace hello with goobye
and server.port=2222
Service Status
Outcome
Properties
Zuul Filters - Types
Thank You
 https://github.com/JananiVelmurugan
 discovery-server
 gateway-service
 hello-service
 goodbye-service

02 api gateway

  • 1.
  • 2.
    Agenda  Monolithic Architecture Microservices Architecture  Challenges & Limitations  Solution – API Gateway  Netflix Zuul  Demo
  • 3.
    Scenario  Core servicesgrow very quickly as well as whole system complexity  Hundreds of services involved in rendering of one complex webpage Ex: Amazon
  • 4.
    Monolithic Architecture  Amobile client retrieves this data by making a single REST call to the application, such as:  GET api.company.com/productdetails/productId  A load balancer routes the request to one of several identical application instances.  The application then queries various database tables and return the response to the client
  • 5.
    Microservices Architecture  Datadisplayed on the product details page is owned by multiple microservices  Shopping Cart Service – Number of items in the shopping cart  Order Service – Order history  Catalog Service – Basic product information  such as product name, image, and price  Review Service – Customer reviews  Inventory Service – Low inventory warning  Shipping Service – Shipping options, deadlines, and costs, drawn separately from the shipping provider’s API  Recommendation Service(s) – Suggested items
  • 6.
    Direct Client-to-Microservice Communication  Clientcould make requests to each of the microservices directly  Each microservice would have a public endpoint:  https://serviceName.api.company.name  This URL would map to the microservice’s load balancer, which distributes requests across the available instances.  To retrieve the product-specific page information, the mobile client would make requests to each of the services listed in the previous slide
  • 7.
    Challenges & Limitations Necessity to know all endpoints addresses  The client in this example has to make seven separate requests  Makes the client code much more complex  Perform http request for each piece of information separately  Merge the result on a client side  Difficult to refactor the microservices  Non web-friendly protocols
  • 8.
  • 9.
    API Gateway  Asingle entry point into the system  Handle requests  by routing them to the appropriate backend service or  by invoking multiple backend services  Aggregating the results
  • 10.
  • 11.
    API Gateway -Usage  Request routing  Composition  Protocol translation
  • 12.
    Netflix Zuul Project Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security and more. Zuul = Spring Cloud + Netflix
  • 13.
  • 14.
  • 15.
    Demo – Hello/GoodbyeService NOTE: To create GoodbyeService, Replace hello with goobye and server.port=2222
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
    Thank You  https://github.com/JananiVelmurugan discovery-server  gateway-service  hello-service  goodbye-service