3. Problem being Solved
• How do the clients application access the back end
services?
• How do the client or another service - discover the
location of a service instance?
• How to enforce centralized authentication and
authorization?
4. Problem: How do Clients Access Back End Services?
❑ Add complexity to client codes
❑ Nightmare for firewall configuration
❑ Coupling of client and individual
services
❑ Cross-domain issue for web app
Direct Communication has problems:
5. Solution: Service Gateway
Service gateway hides the complexity
Simplify the client codes.
Reduce request roundtrips
Provide API management
Solve cross-domain issue for
web app
6. Problem: How to find the service?
In order to access a service, you need to know
the exact endpoint(IP & Port)
IP & Port
dynamically
assigned
IP & Port
dynamically
changing
How to load
balancing
Service endpoint doesn’t change a lot
Consumer can get the endpoint from configuration
files
“Traditional” application
The IP & port is dynamically allocated
IP & port changes along with the scaling/ updating/
self-healing of service instances
Microservice application
7. Solution: Service Registration & Discovery
Service Registration:
➢ Service providers register
themselves to the registry when start
up
➢ Update service information when
service instances change
Service Discovery：
➢ Service consumers query registry to
find the locations of service
➢ Two approaches: Server-side
discovery & Client-side discovery
Service
Registry
Service
Consumer
Load
Balancer
Service
Instance A
Service
Instance A
Service
Instance A
10.74.215.33:3564
10.74.215.211:1522
10.74.215.8:3281
Invoke
Load balance &
invoke
Query
Register
Server-side discovery
Service
Registry
Service
Consumer
Client
SDK
Service
Instance A
Service
Instance A
Service
Instance A
10.74.215.33:3564
10.74.215.211:1522
10.74.215.8:3281
Load balance &
invoke
Query
Register
Client-side discovery
8. MSB Solution for ONAP: Service Discovery & Routing
MSB
External
Service
gateway
Service
Discovery
Internal API Router
Other
Modules…
VF-C
Before:
……
How to call service:
After:
"apigateway": "https://apigateway.onap.org:80"
GET https://apigateway.onap.org/api/aai/v8/cloud-
infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-
region-id}
API gateway routes the request to:
GET https://c1.vm1.aai.simpledemo.openecomp.org:8443/aai/v8
/cloud-infrastructure/cloud-regions/cloud-region/{cloud-
owner}/{cloud-region-id}
Using a configuration file, we might have
problems on scaling, failover and update
MSB handles the service
discovery & routing & LB
MSB as the single
entry point
9. MSB Solution for ONAP: Reverse Proxy
Backend
Server
FronEnd
Server
Before:
The business logic(rest service) forwader must be
add to front end server
Solve the cross-domain issue cause coupling of
business logic and UI pages
Service Gateway
Backend
Server
FrontEnd
Server
Other
Services
After:
service gateway to solve cross-domain issue
Cache for static resources (page, picture)
Clearer boundary between UI and business logic
page
rest
10. Decentralized Authentication & Authorization
Login with different user and
password
•No centralized authentication
•No centralized authorization
•No centralized user management
•There are at least 13 user/password
combos that are used by the test
automation to perform anything
Add Users/Roles in different
places
User Admin
11. MSB Solution: Centralized Auth with Plugin(SSO)
MSBAPIGateway
Auth
Plugin
API
Monitor
ing
Logging
Other
Plugin
User
Admin
ONAP Services
Auth Service
Other Services
Centralized Authentication
1. User send a service request to MSB API Gateway
2. MSB API Gateway auth plugin check the auth token
2.1 If a valid token exist, MSB API Gateway forward the
request to the destination service provider
2.2 If not, MSB API Gateway forward the request to the Auth
Service, and redirect user request to login page
2.3 Auth service create a token after user login with valid
name and password, send the token back to user agent(browser)
Centralized Authorization(Assuming user already login)
1. User send a service request to MSB API Gateway
2. MSB API Gateway auth plugin send the user token and
request(Http method + Resource url) to Auth Service to
check if user has the permission to access the resource
2.1 If user has the permission, MSB API Gateway forward the
request to the destination service provider
2.2 If not, MSB return operation not allowed error to user
Centralized User, Role and Permission Management
Centralized in the Auth Service
Note: Auth Service is not in the scope of MSB
Business
requests
Management
requests
13. OPEN-O Microservice Solution: High Level Architecture
Access Service
(Server-side discovery)
Service
Provider
Instance
A
Service
Provider
Instance
B
Registration
Proxy
Service
Discovery
(DNS Server)
Service
Consumer
Listen
Register
Heartbeat
Unregister
Service
Gateway
L7 Service
Updater
Cache
Listen to service change
Query
Service Registry
Access Service
(Client-side discovery) access serviceService
Consumer
L4 Service
Updater
Update
Service Registry
Listen
to service
change
Modify
and Reload
Load Balance
Access Service
DNS Search
Request Routing
Service Discovery
Register
14. Service Discovery Client
OPEN-O Microservice Solution : MSB Components
Docker Listener
DockerProxy
Discovery
Client
Other Listeners
OtherProxy
Discovery
Client
register
Service Gateway
Service Discovery Server Cluster
Discovery
Server
Discovery
Server
Discovery
Server
Discovery
Client
Service
Management
Healthy
Check
forward registration request
forward registration request
Registration Proxy Service Discovery
Docker Cluster
register
OpenResty
L7 Service
Updater
L4 Service
Updater
Cache
Docker events
Service Gateway
query
External Systems
3-party App
UI Portal
Microservices
Service A
Service
request
forward service request
register
Healthy Check
update
Service A Service AService B Service AService B
Other Cluster(VM, Mesos, K8S, Swarm …)
Service AService A Service AService B Service AService B
Service lifecycle events
15. Service Request Sequence Diagram
Service
Register&Discovery
Service
Gateway
Auth
Plugin
Auth
Service
Service
Provider
1 Register Service
3.1 Auth3 Service Request
Service Client
3.1.1 Check Token
Check Result
Auth Result
3.2 Query Service Endpoints
Available Servie Endpoints
3.4 Service Request
3.3 Choose an Endpoint based on policy(LB
Method, Service Status, etc.)
2 Login
2.1 Login
Token
3.5 Service Request Logging
Service Response
Token
2.1.1 Login
Token
Service Response
16. MSB Features-High Availability
16
Service B
Service C
Service D
Service E
Service A
Load balancer(DNS Server/LVS etc.) in the
front end
Service gateway cluster to avoid SPOF of
service gateway
Access Layer
Service gateway as the load balancer for
services
Deploy multiple service instances to avoid
SPOF of service
Service Layer
17. MSB Features-Separated gateway for External and Internal
Routing
17
Stricter access control
Protocol translation(eg. https->http)
… Expose the services(Rest API, UI pages, etc.)which
need to be accessed by external systems
Solve the cross-domain issue for web app
Stricter access control
Adaption between external API and internal service
External service gateway
Routing and load balancing of the API calls within
the system
Less control in trusted zone
Light weight communication protocol
Internal API gateway
(router)
Registry
Can add more gateways according to
deployment scenarios
18. MSB Features-Extendability
• Extendable architecture for adding
functionality
Auth: add auth to APIs, integrated with
Openstack keystone
Driver routing: add driver specify routing logic
for devices
Logging: API calling logging
Service health monitoring
ACL,API Analytics,Transformations
Anything: new functionality can be added on
demand by plugins
18
MSB
Authentication
API Monitoring
Logging
Other Plugin
23. Quick Example
Start MSB using docker
sudo docker run -p 80:80 -d --name msb openoint/common-services-msb
Register service
curl -X POST
-H "Content-Type: application/json"
-d '{"serviceName": "weather", "version": "v1", "url": "/openoapi/weatherexample", "protocol":
"REST", "nodes": [ {"ip": "10.0.2.15","port": "9090", "ttl": 0}]}'
"http://127.0.0.1:80/openoapi/microservices/v1/services"
Make request
curl -i -X GET
http://127.0.0.1/openoapi/weather/v1/Middletown
24. MSB Resource Address Specification
Attribute Type Description
ServiceName String A unique name for the service.
For GSO, SDNO and NFVO, service name should include the project name as well as the
microservice name to ensure uniqueness, example: 'sdno-l3vpnService'
For O-Common and Common-Tosca, the project name is not necessary in the service name,
example: 'catalog’
ServicesVersion String The version of service, the version should begin with ‘v’, plus a number or major version
number period minor version number
PathInfo String Path information for the resource
Service type Type Query String
API Service Specification [host]:[port]/openoapi/[ServiceName]/[ServicesVersion]/[PathInfo] queryparam1=xxx, queryparam2=xxx
Content Service Specification [host]:[port]/openoui/[PathInfo] None
Example：
log API Service http://127.0.0.1/openoapi/log/v1/syslogs?id=101&filter=admin&count=50
UI Service http://127.0.0.1/openoui/log/index.html
Openoapi and openoui could
be modified to api and ui
26. AWS Microservice Architecture Reference1
2016.9: Microservices Architectures on Amazon Web Services
Adam Lynch – Snr. Technical Account Manager refer link
A Typical Microservice Architectu
re on AWS S3 CloudFront EC2
Application Load Balancing
Static Content Content Delivery
API Layer Application Layer
Persistency Layer API Gateway
EC2 Container Service
Auto Scaling Group DynamoDB
27. AWS Microservice Architecture Reference2
I Love APIs 2015: Microservices at Amazon
Chris Munns, Amazon – AWS Solution Architect refer link
Establishing a pattern for services and
clients It’s important that the
organization isn’t reinventing the
wheel on every new service: • How
are clients going to communicate? •
What cross service authorization
requirements are there? • How do
services prevent abuse? • How do
you quickly build clients against a
service? • How do services handle
discovery of others services and
resources?
Use an API Gateway! Internet Mobile
Apps Websites Services API Gateway
AWS Lambda functions API Gateway
Cache Endpoints on Amazon EC2 Any
other publicly accessible endpoint
Amazon CloudWatch Monitoring
Amazon CloudFront
So this is the agenda. First I will start with why we choose Microservice Architecture in OPEN-O. Then I’d like to talk about the challenges we were facing when we turn to the microservice approach. Finally How we address these challenges in OPEN-O with the help of Microservice BUS
And what’s the potential benefit MSB could bring to ONAP.
Usually there is only one service entry point for a monolith, the client can get all the data that they need from this single point. But in Microservice approach, the client needs to call a dozen of services to get the data.
The most straightforward method is that a client could make requests to each of the microservices directly.
Unfortunately, there are challenges and limitations with this option. One problem is that this add complexity to the client codes because client needs to handle the communication details of every services.
Another problem with the client directly calling the microservices is that it make the firewall configuration very hard. Each microservice would have a public endpoint. Usually you’d like to put your services behind the firewall for security reason. If you want to impose fine-grained controll, you need to set a lots of rules manually. It’s almost impossible because the ip ＆ port of service instances are dynamically allocated in most cases and may change during their service period.
Another drawback with this approach is that it makes it difficult to refactor the microservices. Over time we might want to change how the system is partitioned into services. For example, we might merge two services or split a service into two or more services. If, however, clients communicate directly with the services, then performing this kind of refactoring can be extremely difficult.
Because of these kinds of problems it rarely makes sense for clients to talk directly to microservices.
A much better way is to use what is known as an API Gateway. An API Gateway is a server that is the single entry point into the system. API gateway hides the inner system architecture from clients, which provides the following benefits:
Simplifies the client by moving logic for calling multiple services from the client to API gateway.
the API gateway enables clients to retrieve data from multiple services with a single round-trip, Reduces the number of requests/roundtrips
It might have other responsibilities such authentication, logging, rate-limiting, monitoring, caching, etc.
Services typically need to call one another. In a monolithic application, the components invoke one another through language-level method or procedure calls.
In a traditional distributed system deployment, services run at fixed, well known locations (IP address and port)，your code can read the network locations from a configuration file that is occasionally updated.
However, a modern microservice-based application typically runs in a virtualized or containerized environments, Service instances have been dynamically assigned network locations. Moreover, the set of service instances changes dynamically because of autoscaling, failures, and upgrades. So, it’s impossible anymore to use a configuration file to get the locations of your services.
To solve this problem, we should introduce a service registration & discovery mechanism. The core of this is a registry. Basically, a registry is a database of service instance and their locations. When a service instance is started, it register itself to a registry. The registry will be updated as well when service instances change in case of scaling and failover. Before a consumer make a call to the provider, it can get the location of available instances from the registry.
There are two ways to do that: Client-side discovery and server-side discovery.
client-side discovery : the consumer gets the location of a service instance directly from a Service Registry, and then call the services.
Server-side discovery: the consumer makes a request via a router (a.k.a load balancer) that runs at a well known location. The router queries a service registry, and forwards the request to an available service instance.
Services typically need to call one another. In a monolithic application, the components invoke one another through language-level method or procedure calls.
In a traditional distributed system deployment, services run at fixed, well known locations (IP address and port)，your code can read the network locations from a configuration file that is occasionally updated.
However, a modern microservice-based application typically runs in a virtualized or containerized environments, Service instances have been dynamically assigned network locations. Moreover, the set of service instances changes dynamically because of autoscaling, failures, and upgrades. So, it’s impossible anymore to use a configuration file to get the locations of your services.
So this is the agenda. First I will start with why we choose Microservice Architecture in OPEN-O. Then I’d like to talk about the challenges we were facing when we turn to the microservice approach. Finally How we address these challenges in OPEN-O with the help of Microservice BUS
And what’s the potential benefit MSB could bring to ONAP.
In OPEN-O, Common Service project provides Microservice Bus(MSB) as the solution for all those Challenges coming with the Microservice approach.
This diagram shows the high Level Architecture of msb.
First, the service instances are registered to the service Discovery. So the service consumer or the API Gateway can get the service information and location from the Dsicovery service. When the consumer access the service, the API Gagteway routes its request to a avialable service instance. Or the consumer can access the provider directly if the consumer is also a Microservice in the same system.
This Diagram gives us a closer look of Architecture of the Microservice bus and its components.
MSB has there parts: Registration Proxy, Service Discovery and Service Gateway.
The Registration proxy listens to the liefecycle events of Microservice instances. For example， we have a docker proxy which get the Notification from docker daemon [‘diːmən], so when a Microservice Container spin up， it can get the Service information from the environment variables of the container and register the service to service discovery. Besides docker proxy, we can also have other kinds of proxies, so we don’t have to add this pieces of Registration codes to the serviceitself. Of course, Microservice can register themselves by calling the rest API of service Discovery.
The Service Discovery provide registration and discovery for Microservices. It can also check the healty status of services and update its internal service registry according to the service status to make sure only provide the available service locations to the consumer.
The service Gateway get service information and locations from service Discovery and use the information to routes service reques and also handle the load balancing if multiple service instances are available.
MSB also facilitate High Availability for the whole system. There’re two layers of high Availability: Access Layer and Service Layer. In the access layer, we can put a load balancer in the front of a API gateway cluster to avoid SPOF of API gateway. In the service layer, API gateway plays the role of load balancer for multiple service instances to avoid SPOF of service.
Normally，the requests from the external systems and the communications between the services within in the application have different Requirement on security, latency, and other aspects.
So MSB can provide external API Gateway and Internal API Gateway for different use.
The External API Gateway expose the API which
Stricter access control
Only these APIs needed to be exposed can be accessed
Adaption between External API(Interface) and Internal API: Protocol Translation, Parameter Mapping,Service Composition
Internal API Gateway
Less or no access control as trusted requests
Light weight communication
MSB is an extendable Architecture, so more functionalities can be added on demand as plugins.
So this is the agenda. First I will start with why we choose Microservice Architecture in OPEN-O. Then I’d like to talk about the challenges we were facing when we turn to the microservice approach. Finally How we address these challenges in OPEN-O with the help of Microservice BUS
And what’s the potential benefit MSB could bring to ONAP.
