Every application needs an administration console, and ours is no exception. In this article, we will build the AdministrationService to provide users with administration privileges to view, query, and control, various aspects of the application. Once constructed, we will exercise the service's Swagger interface and view the service's operational metrics using the AdministrationDashboard in Grafana.
During the lifetime of every user account, various events are generated and published to the application's message queue. It is advantageous to capture and persist these events to provide an audit log of an account's activity. In this article, we will build the AccountHistoryService which performs this task. In addition to capturing the account events, the service also provides a REST endpoint to query these events. After construction, we will deploy the application and exercise the generated Swagger interface. We then view the operational metrics using the AccountHistory Grafana dashboard.
For every registered user in the application, there exists a corresponding profile that contains application-specific information for that user. In this article, we construct the AccountProfileService, which is responsible for managing this data. The service provides a REST endpoint as well as a MessageQueue listener and persists the profile data in a MongoDB database. We will deploy the application and exercise its REST endpoint using the generated Swagger user interface. We wrap up by viewing the operational metrics using the AccountProfile Grafana dashboard.
"The film vault" by Sean_Marshall is licensed under CC BY-NC 2.0
In this third article discussing the AuthenticationService, we focus on the implementation of the core logic found in the AuthenticationService class and the JWTAuthorizationFilter, which intercepts service requests and verifies that each request has sufficient privileges to access the resource.
In the previous three articles, we created two services, the OutboundEmailService and the OutboundSMSService. Both of these services can be called directly via their respective REST endpoints. However, Calling these services directly can potentially cause contention when the service is under heavy load. We did, however, anticipate this situation when creating the services by including a message queue listener. In this article, we will build the NotificationService, which accepts both email and SMS/MMS message requests, and enqueues the message in the respective message queue topics. This approach reduces the concurrent load on each of the messaging services. After the NotificationService is constructed, we will exercise it using its generated Swagger interface, and view its operational metrics using the corresponding Grafana dashboard.
In this article, we will start constructing our reference implementation. We will implement our first service and set up the applications distributed logging and monitoring infrastructure. We begin by building the ConfigurationService, which externalizes and centralizes the application's configuration. While building the service, we introduce Spring Actuator, Micrometer, and Prometheus to capture and store the service's metrics and Grafana to render the application's metrics. Distributed logging is handled using a combination of Fluentd, Elasticsearch, and Kibana to capture, index, and query log data. Finally, we orchestrate our service and its supporting infrastructure with Docker-Compose.
In this article, we begin applying what we have learned from previous articles to create a Reference Architecture. The Reference Architecture outlines the infrastructure and services needed to construct the common foundations of a microservice application.
Microservices not Monoliths.
ThinkMicroservices.com is a resource for understanding Microservices.
© ThinkMicroservices.com. Sitemap.
