Architecture supported in microservices

From Arawak
Jump to: navigation, search


The development of systems that provide APIs is developed with two approaches (1) Monolithic, where all the business logic is focused on a single computer system and (2) based on microservices, which are small pieces of software with business functionality clear and defined, that operate with each other to offer a general business solution.

The main advantages of microservices are the fast start-up, reducing time to market, better scalability, high resistance (resilience), easy discovery, fault tolerance, among other advantages.


The architecture of the Arawak platform distinguishes 4 fundamental groups of microservices:

Componentes-high-level


  • Business: It includes the main components for the business development of the tourism sector management. In the MVP resources can be managed. A resource should be understood as any element that you want to manage, for example: a house, a bicycle, a pool or beach, etc; associated with this resource in the business components can be locate them geographically (Location & Geo), make a reservation in calendar (Calendar & Booking), issue an assessment or criteria to evaluate an experience (Reviews) or claim ( Claim) the property or management right of that resource. Additionally, a component that will allow to program a tour using the diverse resources offered by the platform (PlayTour) will be offered for the demo.
  • Communication: In this version, it allows to guarantee communications by sending emails that are necessary for any purpose.
  • Security: Components that allow providing security to the infrastructure, registration of users / applications and allows to keep traceability of the executed actions on any of the components of the system, enabling future auditing operations.
  • Infrastructure: These are support components for vitality and internal communications between all the business components, allowing to offer an operative cloud infrastructure, easy to manage and monitor.


Microservices grouped into business components, communications and security are explained in their respective sections.

The available microservices form the basis for the construction of new top level microservices, the platform MVP includes a higher level microservice (PlayTour) that communicates with all the base level microservices.


The following figure shows two blocks: MS-X and MS-Y that illustrate microservices that can be added as part of new developments to add more complex business logic, a microservice at the PlayTour level can communicate with both its brothers and microservices of the base, although is a good practice that in the development should be avoided to convert the architecture into a "spaguetti" of calls.

Ms-view


Infrastructure components

The microservices infrastructure is designed to meet the following standards that support an architecture of this type: centralized configuration, discovery, circuit breaker, fault tolerance, event driven, load balancing, monitoring and easy access.

The previous patterns and good practices are supported by the following infrastructure tools in the way described below:

  • Spring Cloud Config: All the microservices designed and running on the platform read their operating configuration in the boot process using Spring Cloud Config technology. The configuration files are managed in a version control system (GIT) and in the Spring Cloud Config boot process these files are updated from the master branch of the configuration project. The main advantage is the versioning of the files of configuration allowing to return to previous versions if necessary, besides introducing changes easily in the microservices, without needing to change element to element the configurations.
  • Spring Cloud Eureka: Eureka is used for the discovery and easy access to microservice instances. Each microservice reading its configuration in the boot process is self-registered in Eureka with a unique identifier. This identifier facilitates access to the independent microservice where you are physically. After a service is registered the components of the platform can access their functionalities using the identifier of the service. Annex 1 illustrates the identifiers used in the architecture. Eureka is especially important for communication between microservices, monitoring and the load balancing process for instances of the same microservice that are physically separated.
  • Apache Kafka: The architecture combines synchronous and asynchronous communication, the second one is used for operations that do not require waiting for an answer, for example, sending emails. When you are about to unleash a mailing event for some microservice, for example the date of a reservation is nearing (booking) a message is published in the kafka communication broker indicating that you have to send an email with certain reservation information. This message is published for the top-level application that ordered the reservation (in this case, for example the PlayTour microservice). The microservices in charge of read this information are subscribed to a kafka topic for which the notification comes with the booking information associated with a tour. With this information an appropriate email message is created that is published in a new topic of kafka and to which the microservice for sending emails is subscribed ready to send it. The Kafka broker can be used to send / receive notifications for any purpose.
  • Netflix Zuul: The Arawak platform has a group of microservices with specific functionalities that expose various APIs and more than 50 REST endpoints. Currently there are 12 microservices, which can be in the same physical address or distributed. For client applications Zuul provides a unique access point that abstracts external systems from the actual location of the APIs offering a single point of access, while facilitating security checks and obtaining statistics.
  • Grafana/InfluxDB: Although it is not exactly an indispensable component of the microservices infrastructure, a library has been implemented to capture metrics that are stored in InfluxDB and visualized with Grafana. The metrics are defined by the developers. There are defined metrics for the counting of the reservations, the stored resources (for example: hotels, shops, museums, etc.) and others that have been defined as part of the MVP and that can be viewed through [link].


Communication flow between microservices

All communication between microservices is done through REST APIs or through Kafka messages, in both cases the format is JSON according to the contracts defined between the system components. If the communication is synchronous, the OpenFeign declarative language library is used.

The following diagram illustrates how is the flow of communication in the architecture for a business microservice (booking). This microservice is used by the top-level microservice PlayTour, which allows creating a Tour making reservations in places, at the time of the visit to a place within the tour send an email notification.

Communication between ms