You are viewing an old version of this page. View the current version.
Adeptia Connect (AC) is an enterprise-class application that is designed for reliable, scalable, and secure operations in mission-critical use cases. Large organizations such as many Fortune 500 companies rely on Adeptia Connect to handle important data exchanges with external customers and partners as well as within internal systems and applications.
Adeptia Connect version 4.0 is a cloud-native application with microservice architecture. It uses Docker to containerize different microservices and uses Kubernetes for container orchestration and management. The application provides the following advantages:
- It can run as a cloud-native application.
- High scalability. Different microservices can be scaled as per need.
- High availability.
- Automated deployment and upgrade through CD pipeline.
- Centralized monitoring and logging.
The Application Architecture diagram for Adeptia Connect is shown below.
Microservice to Register and enforce licensing
Microservice to serve as a single entry point for all the REST and SOAP API calls.
Microservice for log cleanup and archival.
Adeptia Connect has two ways to communicate over the public internet using REST over https and SOAP (Refer to blue arrows in the diagram).
Browser client : User will access Adeptia Connect using web GUI in Browser. Any user request from this UI is routed via webapp-gateway to portal microservice and web-runner microservice. This is a synchronous communication REST over https.
API Client: A user can access API published on Adeptia Connect using API client. The request is routed via api-gateway to rest-api or soap-api microservice depending on API using REST (HTTPS) or SOAP protocol.
The inter-service communication happen in two ways Synchronous using REST over https (Refer green arrows in diagram) and Asynchronous way via using RabbitMQ Message broker.
- Synchronous using REST over https (Refer green arrows in diagram): There are two type of request where this is being used
- web-runner micro-service : All the GUI actions are API calls to web-runner micro-service which further do the inter service communication with all the micro-services connected using green arrow to execute the GUI actions.
- API Microservice: rest-api and soap-api micro-services call runtime micro-service to execute the process flow published as API or Transaction published as web hook.
- Asynchronous way via using RabbitMQ Message broker: There are three type of communication happens using this method (Refer orange arrow in diagram)
- Queue Transaction and Trigger Transaction: As listener and event micro-services find new data to processed, they create a Job in RabbitMQ. Runtime service is listening on this queue and trigger Process flow or Transaction Execution.
- Maintenance Tasks: Any update in the application settings raises an event in the dedicated maintenance queue in RabbitMQ. All the microservices are the consumer of this maintenance queue and gets notified when the application setting is updated. This ensures automatically reloading of the application settings in the corresponding microservice.
There are two types of data in Adeptia Connect that require persistence(Refer dotted arrow in diagram).
- Shared volume using PV/PVC
- Metadata files and dependencies
- Repository for persistent storage of run-time temporary files and archiving
- Backend Database – Stores all metadata related to users, transactions, configurations, partners.
- Log Database – Stores all run time execution details, log information, and audit trails.
Individual micro-service in AC 4.0 are scalable and can scale up or down based on their respective scalability criteria and threshold.
- Runtime micro-service is scalable based on number of the messages in the RabbitMQ queue. If the number of messages in the queue exceeds the threshold (default 5) then new runtime pod is spin-up by the autoscaler. This threshold value can be configured in the values.yaml by changing the environment variable MAX_QUEUE
All other Microservices are scalable based on the CPU and Memory utilization percentage . Autoscaler will spin-up a new pod if the CPU or Memory utilization of pod increases the threshold value. This threshold value can be configured in values.yaml by changing the targetCPUUtilizationPercentage and targetMemoryUtilizationPercentage under autoscaling section of the micro-service.listener and license micro-service will have only 1 replica set (single instance).
An application that is architected, built, and run to be perfectly scalable in every way still faces scalability challenges if its dependencies cannot scale with it. Ensuring that all dependencies will scale with a microservice’s expected growth is essential for building production-ready services.
As you scale microservices in the Adeptia application, you need to ensure that the underlying database is scalable and performant. With an increase in the number of microservices and the incoming requests, the interaction with the database increases. Therefore, the database shall be able to handle the surge in the requests by allowing more concurrent active connections and be able to return the result promptly.
Similarly, with an increase in the number of microservices, the application interaction with the shared volume provisioned in the Kubernetes cluster through PV/PVC increases. As you scale the microservices in the Adeptia application, you need to ensure that the shared volume(PV/PVC) is sized to a correct value and configured for high performance for I/O intensive workloads.
Circuit breaker prevents the cascading effect of a malfunctioned micro-service to other healthy microservices and provides fault-tolerance capability to the application architecture.
AC4 supports circuit breaking from the following three components of Adeptia Connect microservices architecture:
How it works
With the help of the circuit breaker the Webapp Gateway/API Gateway/RabbitMQ is able to make or break the communication with a failed microservice. To determine whether a microservice is up or not, the Webapp Gateway/API Gateway/RabbitMQ allows twenty consecutive requests to the microservice – if the response to all the twenty requests fails, it instructs the circuit breaker to open the circuit and thereby break the communication.
After the circuit remains open for sixty seconds, the Webapp Gateway/API Gateway/RabbitMQ once again allows a few requests (in this case, five) to check whether the faulty microservice has started responding or not. In such a condition the circuit breaker is said to be in half-open state.
- If the microservice responds to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to close the circuit and thereby start the communication.
- If the microservice doesn’t respond to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to keep the circuit open and thereby break the communication for the next sixty seconds.
This cycle continues until the microservice starts responding to the requests.
- No labels