- Views: 741
- Author: JLupin
- Comments: 0
Welcome to REACTIVE MICROSERVICES
The most important change in the product is delivering reactive components (queues, channels, protocol):
- JLupin Reactive Queues (with callback) - a completely new queue implementation that enables reactive communication patterns while providing a "callback" mechanism. Thanks to the new queues, you can not only call the service asynchronously, but also ask about its result via the JLupina API or ... simply the result can be automatically returned to you once it is ready. And all these are provided also in the microservice architecture - each queue can be an independent JVM process, individually scalable and multiplied, of course according to the main postulate of the platform - without single points of failure, in the scale-out model. If you would like to know how it's designed and how it works please refer to this piece of documentation, if you are ready to use it inside your project, go to the development guide.
- JLupin Reactive Channels - a new platform component through which channel communication is implemented, which is the basis of the reactive programming. How it's working ? Microservices subscribe to the channel through which they communicate with other subscribers, each of whom is responsible for the implementation of a selected group of services (sounds familiar, yes, microservices). Each of the subscribers is not aware of the existence of the others, each of them realizes the functions entrusted to him the best he can and calls them through the channel, which are necessary for the implementation of the entire query carried out by the system. It's like a chain reaction - one query to the system triggers an "avalanche" of atomic operations whose results are returned in accordance with the reactivity paradigm - asynchronously and gradually. As in the case of reactive queues, the channels are also "microservices" and operate in a multi-node system without a single point of failure. If you would like to know how it's designed and how it works please refer to this piece of documentation, if you are ready to use it inside your project, go to the development guide.
- JLupin Reactive Protocol - new communication protocol, adapted to the dynamics of data flow and number of calls on the platform, which was additionally optimized in terms of CPU time consumption and the amount of allocated memory. All these to enjoy "reactivity" without compromise, without restrictions and to provide the best business software in industry.
On of JLupin competitive advantage is RELIABILITY, which is covered by all mechanisms that keep services up & running regardless incidents & failures in the environment. The new version provides some new features in this scope:
TRUE Zero Downtime Deployment - well... zero downtime deployment is available since JLupin 1.0 and we know that is also available in other platforms, so... what is new and how does it differ from competitors ? The word 'TRUE' is not accidental, in JLupin Platform 1.5 'TRUE' means:
- Full transparency - you don't have to implement any handlers in your application to perform graceful restart
- One instance approach - only one instance of microservice / application is enough to perform TRUE Zero ...
- Online on the edge - TRUE Zero is also TRUE for access layer where services are requested by its clients, from external balancers. Even if sessions are handled on that microserices (!).
- Custom thread pools support - we are looking at custom thread pools as well, not only the number of processed requests coming from clients. So if you create a thread pool, we will wait with the shutdown until all threads finish their job. It's really TRUE Zero...
Extended Self-healing - the new mechanisms have been implemented to ensure that everything is up and running :) To be exact:
- Process Keeper - restore the microservice state after its sudden stop outside the JLupin management tools, ex. "kill".
- Memory Process Keeper - to ensure that in case of OutOfMemoryError or StackoverFlowError the microservice will be restarted with additional resources and the necessary diagnostics data is collected. We do everything to keep availability of the services provided by the system.
- Technical Proces Keeper - restore the the technical microservice (for now it is JLupin Edge Balancer) after its sudden stop outside the JLupin management tools, ex. "kill.
The new version also efficiently deals with challenges on the edge of microservices environment. How to easily access services provided in distributed manner ? How to integrate such environment with other components like external balancers (with WAF for example) ? We have strong answer for this question:
- JLupin Edge Balancer - running as a technical microservice - a new kind of process that extends core JLupin's functionalities, automatically provides HTTP(S) access to microservices through it's context name. It also allows (what is probably much more valuable for you) to perform FULLY ONLINE restart of a SERVLET microservice (Spring Boot). It's not just another proxy or balancer... it's very smart, if you add a peer to your node, JLupin Edge Balancer will be notified and will automatically discover this peer. In that way, this node will be able to provide services located on other nodes... consequences ? Only good one :) you can access you services regardless where they have been deployed. Cloud ? serverless ? whatever, it's just very useful :) If you would like to go deeper, refer to the documentation.
As you probably know we pay a lot of our attention on each phase of software life cycle, that's why along with strong runtime capabilities we've provided management tools to cover the "OPS" part of "DEVOPS" :) Let's go deeper a little bit:
- JLupin Platform Web Console - a web console that visualizes (!) the environment: nodes, microservices and (which was the most important challenging for us) relations between them. The goal was to show everything from the node's point of view, where webcontrol has been deployed, including remote microservices located on peers. Along with the view of the environment you have control panels on the bottom to discover the overall status of the environment and perform some basic tasks. For more advanced once, including changing configuration, you have access to full featured CLI console in web terminal (on the right). Would you like to check it by yourself ? Let's start here.
Enhanced JLupin Platform CLI Console - there are plenty of new features and enhancements, including (we present the most important ones, please refer to the documentation to get more):
- Remote node management (you can interact with any node in the environment, not only the local one)
- Local and remote (HTTP) repositories of artifacts. This will help a lot in CI/CD process.
- Full control over operational status of nodes and microservices (activation / deactivation).
- Additional output formats (JSON, XML).
- Script recording with variable support.
- Lock manager to handle concurrent management process and internal operational loops. This interal mechanisms is for ensuring that every task performed by the administrator and by JLupin itself is performed in right order and safely.
Extended monitoring - in JLupin Platform 1.5 we've introduced the monitoring manager which is responsible for collecting all monitoring data in one, consistent and centrally managed data structure, accessible throu variety of channels ("in omnichannel manner" we can even say):
- HTTP Information port, by default available at 9098 providing several informational endpoints with a "special" one - BIG JSON ('/getAllEnvironmentState') which gives you ALL information about environment in one place.
- JMS Gateway, by default available at 9010 providing aggregated information through JMX MBeans.
- CLI / Web Console, where monitoring data sets are provided by specific commands ('node runtime' / 'microservice runtime')
- Event log is a great fulfillment of all monitoring mechanisms, is responsible for logging each actions performed by JLupin's internal processes (ex. proces keeper) and give full information about events in the microservices environment.
We improved also security mechanisms to help users better protect their applications. JLupin Platform often operates in the regulated environment (ex. PCI DSS) where security is important. So what has appeared in this scope?
- SSL sockets with two-way authentication mechanism to ensure the highest level of security of JLupin interfaces. Now It is available for HTTP Elastic API and turned on by default for transmission port to protect administration commands coming from management tools (CLI / Web Console, Maven Plugin).
- Named logical servers to provide security mechanism ensuring that on the specific port the exact set of services is available for remote clients. Watch our marketplace and github to get more about use cases how to practically use this feature.
That's all from news, I hope you will enjoy JLupin Platform 1.5.