Microservice Powered Orchestration
2 likes1,948 views
Microservice Powered Orchestration discusses using a microservice architecture and microservice bus (MSB) solution for ONAP orchestration. Some key points: - Microservices allow ONAP components to scale independently and integrate diverse seed codes, improving reliability and scalability. - MSB provides service registration, discovery, and routing to address challenges of direct client-microservice communication and dynamic service endpoints. - MSB features include high availability, separated gateways, extensibility through plugins, service health monitoring, and acting as a single entry point for ONAP. - MSB could fit into ONAP by handling service discovery and routing between components, and providing a reverse proxy for web applications
Microservice Powered Orchestration
- 1. Microservice Powered Orchestration Huabing Zhao ZTE, System Engineer, Network Management & Service, OPEN-O Common Service PTL zhao.huabing@zte.com.cn Zhaoxing Meng ZTE, NFV&SDN Architect, Network Management & Service, OPEN-O Common Service PTL zhaoxing.meng1@zte.com.cn
- 2. Agenda • Why Microservice at OPEN-O • Challenges of Microservice • MSB(Microservice Bus) Solution • What can MSB bring to ONAP 2
- 3. Monolith vs Microservice 3 Monolith Microservices Scaling Monolith Scaling Microservices Process Machine The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. -Martin Fowler No performance issue here
- 4. 4 Why chose Microservice Architecture? How to make orchestration reliable and scalable? OPEN-O is a large, complex software system Each component may have different resource requirement Each component may have different working load How to integrate existing seed codes in different technical stack? We didn’t start from scratch A dozen of existing seed codes repos Ambitious release plan How to build an OPEN community? We have various members and we are expecting more joining in Each organization has its own tech Stack
- 5. 5 Ambitions Sun Release Plan We had made an ambitions plan for SUN Release
- 6. 6 SDN Driver VNFM Drivers VIM Drivers ACCESS/WAN SDN Controller Drivers NFV SDN Controller Drivers Orchestrator Service Model Designer Portal GUI Portal … Test & Lab (for feature) GS-O Service Decomposer Service Lifecycle Mgr. Service Parser Abstract NBI SDN-O SDN Res. Mgr. Abstract NBI Abstract SBI NFV-O NFV Res. Mgr. NFV Monitor NS Lifecycle Mgr. Abstract NBI Abstract SBI VPN SDN Lifecycle Mgr. Traffic Optimize VAS Mgr. … SDN Monitor O-Common External System Register Template Mgr. Analytics Policy Inventory … Common Service HA Log Driver Mgr. … Micro-Service Bus Protocol Stack Auth. EMS/NMS Driver Parser NFV Driver Workflow Engine Catalog VIM Drivers Challenge of Integration We get bigger challenge for ONAP integration
- 7. 7 Build an Open Community Build an open community so that everyone can enjoy the party Microservice Platform VendorOperator Partner Individual Developers Portal Global Service-O Common Service Test & Lab Orchestrator Common SDN-O NFV-O Driver Driver Driver Driver Driver Legacy System Partner App SDN Controller VNFM VIM VNF
- 8. Challenges of Microservice Architecture Microservice Architecture comes at a price: Complexity How do the clients application access the back end services? How do the client or another service - discover the location of a service instance?
- 9. Direct Client-to-Microservice Communication？ ❑ Add complexity to client codes ❑ Nightmare for firewall configuration ❑ Coupling of client and individual services ❑ Cross-domain issue for web app This approach has some problems:
- 10. 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
- 11. 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
- 12. 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
- 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. MSB Features-High Availability 15 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
- 16. MSB Features-Separated gateway for External and Internal Routing 16 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
- 17. 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 17 MSB Authentication API Monitoring Logging Other Plugin
- 18. MSB Features-Service API Portal 18
- 19. MSB Features-Service Healthy Monitoring 19
- 21. How MSB may fit into 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
- 22. How MSB may fit into ONAP(reverse proxy for web app) 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