Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Source codes are from OPEN-O and have already been used to support Microservice Architecture of OPEN-O for the vEPC and VoLTE use cases in its two successful releases.


Note and Clarification:

  • Both MSB and OOM use the term "service", but for different meanings. What "service" means in the context of MSB is a service endpoint (IP:Port) providing a business logic for the use of consumers. Service can vary from L4 to L7, for example, TCP, UDP, HTTP/S(REST), HTTP/S(UI), etc.
    OOM aims to provide lifecycle management for ONAP components, so the "service" managed by OOM are at process level, in contrast, the "service" managed by MSB are in smaller granularity, at the endpoint level. It's common that a component(process) may have multiple endpoints(services).

  • MSB provides a common infrastructure for ONAP services, no matter it's a "micro" service or a "normal" service. In this context, the term "microservice" just means that the service's scope is highly organized around one business capability so it's smaller than "normal" service. Just like micrcoservice, other services wich is "bigger" is also a process which needs to expose service endpoint to be accessed by its consumers. So both "micro" and "normal" services need the service registration/discovery/routing/load balancing mechanism provided by MSB.     

Scope:

  • Service registration
    • Registration via Restful API
    • Registration via portal
    • Registration via proxy
    • Note: Registration info is used for service request routing, the info including service name, service exposed url, version, service instance endpoint(IP:Port), service protocol, service ttl, service load balancing method, etc.
  • Service discovery - Server side discovery
    • service request routing
    • service request load balancing
  • Service discovery - Client side discovery
    • client side discovery SDK
  • Service discovery - DNS
    • Discovery and load balancing by DNS server
    • Service consumer directly talk to service provider
  • Service Health Check
    • Note: The goal of service health check of MSB is to maintain the correct health status of service at endpoint level in the service registry so the service consumer will not get a failed service provider instance, MSB doesn't try to kill and restart the onap component, which is the scope of OOM(ONAP Operations Manager)
  • Service API gateway
    • Client request routing
    • Client request load balancing
    • Transformation, such as https to http
    • Provide authentication & authorization for service request with plugin of auth service provider like AAF
      Note: MSB itself doesn't provide auth service, which is provided by a auth service provider microservice such as AAF(Authentication and Authorization Framework)
    • Service request logging
    • Service Request Rate-limiting
    • Service monitoring
    • Request result cache
    • Solve cross-domain issue for web application
    • Other functionalities with the pluggable architecture capability ...
  • Service API Portal
    • Provide a Service API Portal to expose all the ONAP Swagger format API descriptions
    • Don’t need to maintain an independent API Portal and API description documents – save money and time
    • Keep the consistency of the API document with the source code
    • Support multiple versions of APIs
    • Always get the latest API documents of the current development branch which is generated by CI/CD automatically
    • Provide self-service onboarding for developers

...