Project Name:

  • Proposed name for the project: Microservices Bus
  • Proposed name for the repository: msb.onap.org msb

Project Description:

Microservices Bus provide a reliable, resilient and scalable communication and governance infrastructure to support Microservice Architecture including service registration/discovery, service routing and load balancing, timeout and retry, requests tracing and metrics collecting, etc. It's a pluggable architecture so it can plugin service provider options like AAF to provide Authentication & Authorization for APIs. Microservices Platform also provides a service portal and service requests logging, tracing and monitoring mechanism, etc.

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:

  • We have reached consensus with OOM project that MSB and OOM manage service registry at 2 different levels, MSB at the micro/macro service endpoint level vs OOM at the micro-service/component level,  MSB will work with OOM to provide a comprehensive Service Registry function.

  • MSB provides a common infrastructure for ONAP services, no matter it's a "micro" service or a "macro" 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
  • Client SDK
    • Service registration&discover client SDK
    • Service request client SDK
  • Service Mesh
    • MSB is planning to support Service Mesh in future release

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?


    • Please Include architecture diagram if possible
    • What other ONAP projects does this project depend on?
      • Integration
      • OOM 
  • How does this align with external standards/specifications?
    • APIs/Interfaces - OpenAPI/Swagger
    • Information/data models - Swagger JSON or YAML models
  • Are there dependencies with other open source projects?
    • APIs/Interfaces - OpenResty, Consul, Redis, Istio
    • Integration Testing
    • etc.


This part was added yesterday and have not been discussed inside project yet, we will discuss it later and solve it inside project. Currently, this part is considered one of the potential seed code, but it doesn't impact the scope of this proposal.

******************************************************************************************************************************************************************************* 

DME2 ( Direct Messaging Engine )

DME2 provides encapsulated JMS via HTTP transport APIs that a Service provider instance can use to dynamically register its end point on service provider startup and to unregister its end point when it shuts down. Service endpoints are persisted on the Cloud Data Store for the purpose of endpoint dynamic discovery as the client requests are being routed.

dme2-image.png

DME2 also provides client API's to route Service requests based on data, partner or geographic affinities.The requests are effectively load balanced and client requests can failover dynamically between the service endpoints.

DME2 Key Features

DME2 provides a robust set of features for any service provider implementation to utilize for inter-process client/server communication, including:

  • Fast-failover - Queuing the requests on server implementation is disabled by default, which allows the client to fast failover if a service provider is consumed at its max capacity.
  • Dynamic Routing - The client requests will be routed to the DME2 service provider instances via routing made possible by the dynamic registration of the service provider as instances become available
  • Affinity Routing - The client requests will be routed to the service provider by means of data, partner or geographic affinity depending on the client requirements.
  • JMS API's - Provides standard JMS API implementation for destinations type as JMS Queues or Point-to-Point messaging
  • Async Request/Reply - Enables better use of resources by avoiding the traditional thread per request, thus supporting highly scalable service provider implementation

***********************************************************************************************************************************************************

MSB Use Cases:

  1. Service registration per service provider instances
    • Registration
      Service instances are registered to the registry by proxy or themselves. The visible scope should be indicated as a parameter when register. If a service is only internal visible, the service information is only pulled by the internal gateway (aka router & load balancer) and used by other components inside the system, the interal services can't be accessed by external systems or front end(web client). If a service is visible to external system, the service information is pulled by the external gateway and can be accessed by external systems and front end (web client) with auth.
               
        
    • Discovery & Service Consuming
      • For internal service consumers(Components inside ONAP system, such as A&AI, SO, Controller, etc.)
        • Client side discovery and load balancing
        • Server side discovery and load balancing
      • For external service clients(OSS, BSS, Web client, etc.), access the service via external gateway


  2. Service registration per service
    The service may have its own load balancer built inside, for example, Kubernetes can create a load balancer for a service. In such case, only need to register the service LB node to MSB, and the service request from the consumer is routed to the service LB node.
    • Registration

    • Discovery  & Service Consuming

      Note: Only show the client side discovery in this diagram for simplicity, it's also possible to use server side discovery by the internal gateway.


  3. Centralized Authentication&Authorization via MSB plugin
    MSB is a pluggable architecture, so it can provide centralized authentication & authorization for service request with plugin of auth service provider like AAF.





Resources:

  • Names and affiliations of any other contributors

    NameGerrit IDCompanyEmailTime Zone
    Jochen Kappel
    		IBMjochen.kappel@de.ibm.com
  • Project Roles (include RACI chart, if applicable)

Other Information:

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: Microservices Bus
  • JIRA project prefix: MSB

Repo name:
Lifecycle State: Incubation
Primary Contact: RamKoya, HuabingZhao, Al Hua, Sanjay Agraharam, Brijesh Khandelwal
Project Lead: Huabing Zhao zhao.huabing@zte.com.cn
mailing list tag [msb] 
Committers:

please refer to the above table

*Link to TSC approval: 
Link to approval of additional submitters:

  • No labels

46 Comments

  1. Brian Freeman

    Couple of items


    1. Basic authentication should work for secured REST API's with the ability to plugin service provider options like AAF
    2. REST uri format should allow operation with restconf interface e.g. http://<ip>:8282/rest/config/someAPI
    3. swagger.json uri should be configurable so that it works with dynamically generated swagger as on ODL bsaed controller (i.e., not a swagger.json file but a uri that may end in "/")
    4. This should fit into the DMaaP/Message Router for publish/subcribe and into DMaaP/DataRouter for large file transfer via publilsh/subcribe

    1. HuabingZhao

      Hi Brain,

      Thanks for your comments.

      1. MSB is a pluggable Architecture, so it can integrate AAF as the auth service provider to secure REST APIs.

      2. Yes, the format is configurable, so the uri format could vary according to different requirements.

      3. Yes, swagger.json uri can be configured via msb portal right now, we could lso consider adding swagger.json uir as a parameter of service registration Restful API.

      4. I think MSB provides the restful API service registration/discovery/routing/API gateway for microservice, and MSB can work together with DMaaP to provide restful/messages/file communication Infrastructure for microservices.

  2. DeWayne Filppi

    Seed code link is dead

    1. HuabingZhao

      Link updated

  3. DeWayne Filppi

    So there are two message buses in the common service arena.  Given that DMaaP is based on Kafka initially, I assume it isn't for general purpose coordination, like MSB.  Given that MSB is the backbone of the entire system, it would be good to see some mention of HA and dynamic scalability.  HA especially.

  4. Ramprasad Koya

    DeWayne, MSB is not a data or message movement bus. Its more about service registration and discovery. DMaaP is about data/message movement.

    1. DeWayne Filppi

      Probably shouldn't call it a bus then.  Microservices communicate via async message passing, and I'm trying to find a part of the architecture where that actually happens.  I'm not sure DMaaP really sees that as it's role; they seem focused on mass analytics streaming.

    2. Brian Freeman

      I think we are still missing that MSB is point to point to invoke an API vs DMaaP MR which is kafka publish/subscribe (SDC for instance publishes the Tosca models to SO, A&AI, APPC in one transaction DMaaP/MR) vs DMaaP Data router which is bulk file (1G for eample) pub/sub for bulk stats distribution - think feeding big data lakes with data as well as taps for machine learning and/or outer control loop processing. All three are needed for different purposes.

      1. Roger Maitland

        Using kafka as a messaging system for micro-service based architectures is a common pattern - see https://movio.co/en/blog/microservices-rise-kafka/ for a description of some of the advantages of decoupling the source and destinations.

        1. Brian Freeman

          I've read that article multiple time before (smile) . The use case where kafka has been a problem is resource assignment. Specifically when micro-service A (lets say Service Orchestrator) has to wait for data back from micro-service B (lets say a controller) before moving to the next step. Getting vlanIds, ip addresses, hostnames from a controller before spinning up the VM is one example of this type of flow. In this case it can be done by setting up the send and receive topis in kafka and have SO publish on the send topic and listen for a response on the receive topic but in the end that is more complex than a request/response on the same session. MSB is one way that we could put decoupling between client and server but not add the complexity of asynchronous messaging in a synchronous step.  There are situations where asynch makes more sense like configuration changes where SO shouldn't wait till the config is done since it could be a lengthy delay before the network state change has both occurred and been tested.  We generally hadle this with a 200 OK on the request and then do a later callback to SO upon completion but in this case the workflow is designed to deal with the asynch nature (i.e., the work flow doesn't have to wait for the controller before proceeding to the next step). I do appreciate that its possible to do it with Kafka but my point is that we need both a pub/sub asynchronous interface and a synchronous interface. Right now kafka does not provide a synchronous interface - applications have to build that in if they need it or change their processing to deal with asynchronous responses which really adds to the complexity of the programming paradigm. 

          1. HuabingZhao

            Agree with Brain.

            Both sync and async(pub/sub) mechanism have its own suitable scenario in the communication of microservice architecture. We use both in OPEN-O, for example, use ActiveMQ for the communication between Alarm Correlation Component(Holmes) and the event collector(Monitor) to send alarm events to Holmes for processing, use REST for the communication between GS-O and NFV-O to initiate a domain network service.

          2. Roger Maitland

            I agree that the asynchronous model might seem to be more complex than a synchronous model but I wonder if this is true when fault tolerance is taken into consideration. With a synchronous system each source will need to build timeouts and failure handlers for each destination. In an asynchronous model, a failed node can be replaced by a replicant that pulls incomplete transactions from a queue and fulfills them without involvement of the source (assuming a clustered model with shared state). Whatever the ultimate messaging solution, it's important that we architect the system to handle failure.

          3. DeWayne Filppi

            In my view synchronicity is an illusion presented by the client library.  The underlying messaging infrastructure is better left async.  Having said that, it feels like Kafka has to be unnaturally coerced into being a point to point messaging system.  But then again, I'm not even in this group.  My interest is as a consumer of microservices.

  5. Vijay Venkatesh Kumar

    MSB scopes listed here appears largely overlapping with Operation Manager. The functions - health check, registry are something required by operation manager also (to determine appropriate heal operation). Should these proposals be merged (with Operation manager) so functionality requested is not duplicated.

    1. HuabingZhao

      The listed scopes of MSB here including Service Registration/dicovery, Health Check and Service API Gateway are strongly related to each other.

      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 health check of MSB is used to maintain the correct health status of service in the service registry so the service consumer will not get a failed service provider instance, and Service API Gateway uses the Service information in the registry to route the service requests to the service provider instance.  

      So from this point, all these functionalities should better inside the MSB project to avoid unnecessary cross-projects overhead.We already have seed codes for all these components and they have well-formed APIs to talk with each other to support the whole Microservice Architecture.

      From the project description of OOM, it mainly aims to the deployment and management of the ONAP Platform. The intention of registration and health check in OOM is for the management of these components, such as report alarms when service is down and restart/scale out/scale in the components based on the check result. 

      In conclusion, the intention and focus of Registration/health check of MSB and OOM are different, so the derived APIs/Data model are also different. I would like to discuss with the OOM team to find more details and figure out if it's possible to combine them.


      1. John Ng

        Hi Huabing: for OOM's service registry/health-checking, we are proposing to the reuse the open source software Consul (https://www.consul.io/).  It essentially accomplishes the service registration, discovery and health checking functions.  Also, we see the service registration/health-checking functions as needed beyond microservices.  We need to monitor and manage the entire ONAP platform - ONAP component software, microservices, databases, and eventually the underlying connectivity across the platform - many of which will have multiple instances as we scale out and geographically distributed to achieve HA.  Onboarding of microservices is currently being performed by the DCAE controller for analytics applications and data collectors (we see analytics and collectors as our initial microservices).  We see this onboarding functionality move beyond DCAE into the overall ONAP platform as we support non-DCAE microservices.  

        1. HuabingZhao

          Hi John,

               I fully agree that "we see the service registration/health-checking functions as needed beyond microservices", and that's exactly what MSB is providing. There is no difference in the sense of service registration/health-checking/routing/load balancing for "normal" service and "micro" service.

              Actually, 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. However, according to the ONAP architecture principle, all services should evolve to become service-based with clear, concise function addressed by each service, following principles of microservices.  https://wiki.onap.org/display/DW/Draft+Architecture+Principles

              MSB already provides a common mechanism to register service instances and monitor its health/state, no matter it's a "micro" service or a "normal" service.  MSB also support different services from L4 to L7, such as TCP, UDP, HTTP/S(REST), HTTP/S(UI), etc.The information can be used by MSB for gateway, service routing and load balancing.

              Besides, I'd like to clarify that the "service" mentioned in OOM and MSB are different, the two project proposals use the same term to express different meanings, which might cause confusion.

              OOM aims to provide lifecycle management for ONAP components, while MSB facilitates the routing/LB of services which defined by a specific port. 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).

              OOM check the health of ONAP components at the process level and manage its lifecycle accordingly. MSB take care of the health of a service at endpoint level and make sure the service request from the consumer is routed to an available service endpoint.

             While OOM and MSB manage the process and service separately at different levels, these two projects do need to cooperate. As I understand it, after OOM start/stop/scale an ONAP component, it broadcasts a message for the specific ONAP component. MSB will consume that message and manage service at endpoint level for the usage of service request routing and load balancing.

  6. John Ng

    I would like to get clarification on the scope of MSB - the microservices being registered and discovered by MSB are only management-related services that exist on the ONAP platform or to be created/deployed on the platform.  VNF microservices (VNF functions developed as microservices) are NOT in scope.  Could someone provide confirmation of my understanding of the scope?  Thanks!

    1. HuabingZhao

      Hi, John,you're correct. VNFs are not in scope. 

  7. Christopher Rath

    Thanks for the updates and clarifications.  The only request I would have is that integration between MSB and OOM happen through the Common Controller Framework (soon to be renamed SDK), rather than directly in OOM.  MSB provides useful functionality that other controllers, like the DCAE controller would want to take advantage of as well.

  8. Manoj Nair

    Few queries on MSB scope.. As I understand there are two models of registration of micro services - 1) OOM assisted : where in OOM while instantiating micro services notify the MSB about the micro service registration details. 2) Self Registering : Each MSB registers on its own.

    Currently the registration data is focusing on the IP address and port number mapped to the service name, which are primarily used for REST based interactions. Is there any plan to also 1) include the capabilities exposed by each micro service end point like APIs available/implemented/exposed/restricted for the consumer 2) capability to invoke registered end points based on context, in which case MSB is capable of maintaining the context between calls 3) Support patterns like Message translation/Transformation, Content based routing, Multi cast etc ? 4) Is there any registration data persistence mechanism in place ? If I understand correctly a Redis cache is being mentioned in Open-O, is the cache persisted anywhere ? 4) MSB being a centralized component, will there be multiple instance of MSB running in an active-active mode or active-standby ? 

    1. HuabingZhao

      Hi Manoj,  these are very good questions.Please see my response inline.


       1) OOM assisted : where in OOM while instantiating micro services notify the MSB about the micro service registration details. 2) Self Registering : Each MSB registers on its own.

      Huabing: Yes, in Amsterdam release we'd like to use option 1 to minimize the impact to ONAP projects while each project can leverage MSB's capability.  You may also be aware that option 2 will have problems in container deployment because Microservice can't get the externally accessible IP address by itself.


       1) include the capabilities exposed by each micro service end point like APIs available/implemented/exposed/restricted for the consumer

      Huabing:  I think that might be the scope of API definition, we propose to use swagger for REST API definition and documentation. MSB has a portal to show and test the defined API using swagger UI, which I demonstrated in the virtual developer meeting.


      2) capability to invoke registered end points based on context, in which case MSB is capable of maintaining the context between calls

      Huabing: No, MSB treats each call individually, there is no context between calls. If a microservie is stateful, MSB can do IP Hash LB to forward the calls from one client to the same service provider instance.


      3) Support patterns like Message translation/Transformation, Content based routing, Multi cast etc ?

      Huabing: 

      Support  Message translation/Transformation:  Currently MSB support the translation between https to http. You can also plug  customized translation/transformation logic into MSB?

      Content base routing: Yes, MSB is a pluggable Architecture, so you can plug in your logic to MSB which use the content to decide the routing logic.

      Multi cast: Normally we prefer pub/sub system such as DMaaP to do Multi cast.


      4) Is there any registration data persistence mechanism in place ? If I understand correctly a Redis cache is being mentioned in Open-O, is the cache persisted anywhere ?

      Huabing: MSB leverage consul Catalog for registration data persistence. Redis is used as a local cache for API Gateway


      5) MSB being a centralized component, will there be multiple instance of MSB running in an active-active mode or active-standby ? 

      Huabing: Yes, MSB can run as a cluster to avoid SPOF and provide load balancing for incoming requests.

  9. ramki krishnan

    In a Kubernetes deployment which OOM is seriously committed to, most of the features offered by MSB would be natively supported by Kubernetes. Can you please articulate the gaps if any with a Kubernetes deployment and where MSB can help?

    Thanks,

    Ramki


    1. HuabingZhao

      Hi Ramki,

      It's a very good question.

      Firstly, MSB provide a comprehensive, end 2 end solution to support ONAP microservie architecture including service Registration/Discovery, External API Gateway, Internal API Gateway, Client SDK. Some of these important features are not natively supported by Kubernetes, such as the protocol translate/transformation, centralized auth, logging capabilities provided by API Gateway, API management capabilities provide by MSB discovery and the client SDK, etc.

      Secondly, Kubernetes is one of the deployment approach, as a platform, ONAP may need to be deployed by different tools and on different infrastructure, so we need an infrastructure dependent microservice platform to avoid binding with a specific deployment tool or infrastructure.

      Thanks,

      Huabing 

  10. Vijendra Rajput

    Hi Huabing,

    what about service logging and monitoring withing MSB. How we are doing this couldn't see any document around that.

    Thanks,

    Vijendra

    1. HuabingZhao

      Hi Vijendra,
      Currently, service logging and monitoring are not supported in Amsterdam release.

  11. Ankitkumar Patel

    For micro-services managed by OOM, the OOM-registrator registers service end-points to MSB; however, It is not clear how service discovery is supported for OOM-managed micro-services. These micro-services may interface with other internal/external micro-services/systems. Is service discovery for such micro-services be also done through OOM or these micro-services are required to implement MSB gateway API/MSB-client SDK-based approach for service discovery?

    Ankit

    1. HuabingZhao

      Hi Ankit,

      Basically, you are asking two questions:

      1. How is service discovery done by MSB?

        There're two approaches: client-discovery using JAVA SDK/RESTFul API or server-side discovery using API Gateway. More information can be found in this slide:https://wiki.onap.org/download/attachments/22250882/Microservice%20Bus%20Tutorial.pdf?version=1&modificationDate=1515983783000&api=v2

      2.  Could an external service be registered to MSB?

        The simple answer is yes. MSB doesn't actually distinguish internal/external service, any service which has an accessible endpoint can be registered to MSB and can be discovered/accessed by clients-It could be a user agent(browser) or another micro-service. It means the registered service does not necessarily need to be an "ONAP" service. 

        If the external service is deployed by k8s as well, we can leverage kube2msb for automatic registration. Otherwise, the external service can be registered to MSB via MSB registration RESTFul API.

      I have an MSB tutorial at the Virtual F2F meeting on Wednesday. We can talk there if you have more questions.


      Huabing

  12. Ankitkumar Patel

    During the service discovery phase, can MSB broadcast an API call to all the active instances of a service? This is a useful capability when multiple instances of a service are maintained in an active-active mode? 

    Ankit

    1. HuabingZhao

      MSB API Gateway can choose one active instance according to the LB method and route the API call to that instance, but will not invoke all the active instances.

      Do you have a real use case for this scenario(Get a request from the client and invoke all the service provider instances)? Pub/Sub mechanism such as DMaaP can be one option.


      1. Ankitkumar Patel

        Hi Huabing,

        In the policy system, we have PAP and PDP containers. PAP pushes policies into the PDP containers and the requirement is to have the same policies available on all the PDP containers. This requires PAP to broadcast the push policy calls to all PDP instances.

        Can one of the load-balancing policies be broadcast in MSB? How much of an effort required to enable broadcasting in MSB for R2? If it is not doable for R2, when will this capability be available?

        Ankit

        1. Srinivasa Addepalli

          Hi Ankit,

          If you need that capability, I think MUSIC would be able to help.

          Srini

          1. Ankitkumar Patel

            Thanks Srini,

            Yes, DMaaP/Music are potential options; however, opening new DMaaP/Music interfaces may require major dev/test efforts in the policy system for R2. Since broadcasting is one of the fundamental strategies for service discover and that maybe required by other ONAP systems, it would be great if MSB supports the capability in R2 if the required effort is low.

            If MSB won't support broadcasting in R2, an alternative is to use the client-side discovery mechanism to get service information and broadcast service calls directly from a client; however this approach bypasses MSB.

            Ankit

            1. Srinivasa Addepalli

              Hi Ankit,

               

              I don’t remember service mesh technologies (MSB) such as istio.io and linkerd supporting this feature.  I might have missed. If you have come across this capability in existing service mesh technologies, I am very curious to know and read more about it.

               

              Thanks

              Srini

               

        2. HuabingZhao

          Hi Ankit,

          Potentially, MSB can do that, but I‘d like to think it through before we dive into the implementation. I've got a few questions:

          • We need a mechanism to guarantee the transaction across multiple PDPs. What should MSB do if one of the calls to PDP instances fails?  Should MSB retry or rollback? 
          • How should MSB combine the result from multiple service instances and return it back to the client
          • Should MSB broadcast all request from the client, or only broadcast part of the requests?

  13. Ankitkumar Patel

    During the service discovery phase, MSB API-gateway routes and distributes client calls across the existing service instances based on certain load balancing policies/strategies. Where and how are these load balancing policies captured and can a service owner configure the policies?

    OOM also offers load balancing functionality at pod-level through K8S platform. How does MSB load balancing work in conjunction with OOM load balancing during the service discovery phase? Does MSB route client calls to a server through OOM or not?

    Ankit

  14. HuabingZhao

    LB policy can be specified when registering the services. For OOM deployment, it is in the annotation of k8s deployment config, for example:

     annotations:
        msb.onap.org/service-info: '[
        {
          "serviceName": "multicloud",
          "version": "v0",
          "url": "/api/multicloud/v0",
          "protocol": "REST",
          "port": "9001",
          "lb_policy": "ip_hash",
          "visualRange": "1"
        }
        ]

    MSB can work in bare metal, vm, container or k8s deployment. Regarding the LB in k8s deployment, MSB services can be registered at k8s service(cluster IP) level or pod level. The lb of pod level registration is handled by MSB API Gateway and the k8s service level registration is handled by k8s. You can find more detailed information at https://wiki.onap.org/display/DW/2018-02-28+Meeting+notes?preview=%2F25436830%2F25436825%2FMicroservice+Bus+Tutorial.pdf 

  15. Ankitkumar Patel

    If a client query a service from MSB (client-side discovery mechanism), are all the active instances returned to a client? If yes, is it true that a client is responsible for load-balancing of service calls? Should a client periodically query for any updates in service information to MSB?

    Ankit

    1. HuabingZhao

      There are two possible approaches here:

      • Client-side discovery using MSB JAVA SDK, the MSB JAVA SDK takes care of the LB of the service call inside the client process
      • Server-side discovery by leveraging MSB Internal API Gateway, the client simply sends the request to MSB IAG, then MSB IAG will do the service discovery and LB, the forward the request to the service provider

      More details about these two approaches can be found at page 12 to page 15: https://wiki.onap.org/display/DW/2018-02-28+Meeting+notes?preview=%2F25436830%2F25436825%2FMicroservice+Bus+Tutorial.pdf  

  16. Ankitkumar Patel

    Currently, the following fields are used to register a service in MSB;  serviceName, version, url, protocol, lb_policy, enable_ssl, and visualRange. What combination of this information uniquely identifies a service in the MSB registry?

    Ankit

    1. HuabingZhao

      Combination of ServiceName and version is the unique identifier.

  17. Ankitkumar Patel

    Does MSB support proxying through JDBC connections? If not, what other alternatives we have in ONAP to get a database discovered?

    Ankit

    1. HuabingZhao

      Yes, TCP services registration, discovery and transparently proxy can be supported by MSB. MSB also provides additional mechanism for the reliable and security of communication such as retry, circuit breaker and rate limiting. The TCP service registration and discovery are already supported in the current version. The transparent proxy of TCP is supported in the ZTE version of MSB but not in the community version right now, it can be pushed to ONAP soon if it's needed by Policy project.

  18. Manoj Nair

    HuabingZhao , 

    Does MSB support REST API Transformation .. i.e payload rewrite, URL rewrite etc ? and Filtering - i.e Filter API based on URI and payload and then create context for routing ? 

    1. Huabing Zhao

      MSB supports URL rewrite natively, payload rewrite is also possible by leveraging MSB's plugin mechanism, you can add a customized plugin to MSB API Gateway to achieve that. 

      1. Manoj Nair

        I just checked the gerrit for MSB/apigateway and could not find much logic other than extension to Openresty and Redis. Can you please let me know if there is any documentation for adding plugins. Is it the lua plugin in Openresty you are referring to ?