MSB Deep Dive

Editor's Notes

• #3: 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.
• #5: 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.
• #6: 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.
• #7: 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.
• #8: 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.
• #12: 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.
• #13: 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.
• #14: 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.
• #15: 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.
• #17: 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.
• #18: 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
• #19: MSB is an extendable Architecture, so more functionalities can be added on demand as plugins.
• #23: 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.