MSB Deep Dive
Dec. 17, 2018•0 likes•988 views
Download to read offline
Report
Technology
MSB Deep Dive
Huabing ZhaoFollow
Recommended
Microservice bus tutorialHuabing Zhao
MSB to Support Carrier Grade ONAP Microservice Architecture with Service MeshHuabing Zhao
Service mesh in action with onapHuabing Zhao
Api service mesh and microservice toolingLuca Mattia Ferrari
Introduction to Istio for APIs and Microservices meetupDaniel Ciruli
Next steps on Transport SDN - OIF Panel OFC 2015Deborah Porchivina
More Related Content
What's hot
Get Your Data FlowingSolace
Enterprise service bus part 1Return on Intelligence
Introduction to ConsulViswanath J
Protecting Multi-Interfaced Mobile Web Services using Agreements Dr. Fahad Aijaz
Service Provider Architectures for Tomorrow by Chow Khay KidMyNOG
Making flow MuleGiuseppe Fiore
Similar to MSB Deep Dive
Microservice Powered OrchestrationOpen Networking Summit
Becoming a Connected Insurer With API-led ConnectivityBui Kiet
Becoming a Connected Insurer With API-led ConnectivityMuleSoft
"Fintech inside of a SaaS powered by 2000+ Microservices", Volodymyr MalykFwdays
Soa OverviewTerry Cho
apidays LIVE India - Asynchronous and Broadcasting APIs using Kafka by Rohit ...apidays
Recently uploaded
How resolve Gem dependencies in your code?Hiroshi SHIBATA
Product Research Presentation-Maidy Veloso.pptxMaidyVeloso
Solving today’s Traffic Problems with Sustainable Ride Hailing SolutionOn Demand Clone
GDSC ZHCET Google Study Jams 23.pdfAbhishekSingh313342
9C Monthly Newsletter - SEPT 2023PublishingTeam
EuroBSDCon 2023 - (auto)Installing BSD Systems - Cases using pfSense, TrueNAS...Vinícius Zavam
MSB Deep Dive
- 1. MSB(Microservice Bus) Deep Dive Huabing Zhao ZTE, System Engineer, Network Management & Service, OPEN-O Common Service PTL zhao.huabing@zte.com.cn
- 2. Agenda • Current Challenges and MSB Solutions • MSB Architecture & Features • API & Example 2
- 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
- 12. Agenda • Current Challenges and MSB Solutions • MSB Architecture & Features • API & Example 12
- 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
- 19. MSB Features-Service API Portal 19
- 20. MSB Features-Service Healthy Monitoring 20
- 22. Agenda • Current Challenges and MSB Solutions • MSB Architecture & Features • API & Example 22
- 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
Editor's Notes
- 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.