官术网_书友最值得收藏!

Reactive microservices

The reactive programming paradigm is an effective way to build scalable, fault-tolerant applications. The reactive manifesto defines basic philosophy of reactive programming.

Read more about the reactive manifesto here:
http://www.reactivemanifesto.org

By combining the reactive programming principles together with the microservices architecture, developers can build low latency high throughput scalable applications.

Microservices are typically designed around business capabilities. Ideally, well-designed microservices will exhibit minimal dependencies between microservices. However, in reality, when microservices are expected to deliver same capabilities delivered by monolithic applications, many microservices have to work in collaboration. Dividing services based on business capabilities will not solve all issues. Isolation and communication between services are also equally important. Even though microservices are often designed around business capabilities, wiring them with synchronous calls can form hard dependencies between them. As a result, organizations may not realize the full benefits of microservices. Distributed systems with strong dependencies between them have its own overheads and are hard to manage. For example, if an upgrade is required for one of the microservices, it can seriously impact other dependent services. Hence, adopting reactive style is important for successful microservices implementations.

Let's examine reactive microservices a bit more. There are four pillars when dealing with reactive programming. These attributes are resilient, responsive, message based, and elastic. Resilient and responsive are closely linked to isolation. Isolation is the foundation for both reactive programming as well as microservices. Each microservice is autonomous and is the building block of a larger system. By and large, these microservices are isolated from the rest of its functional components by drawing boundaries around business functions. By doing so, failures of one service can be well isolated from the others. In case of failures, it should not cause issues to its downstream services. Either a fallback service or a replica of the same service will takeover its responsibility temporarily. By introducing isolation, each isolated components can be scaled, managed, and monitored independently.

Even though isolation is in place, if the communication or dependencies between services are modeled as synchronous blocking RPC calls, then failures cannot be fully isolated. Hence, it is extremely important to design communications between services in a reactive style by using asynchronous non-blocking calls:

As shown in the preceding diagram, in a reactive system, each microservice will listen to an event. The service reacts upon receiving an input event. The service then starts processing the event and sends out another response event. The microservice itself is not aware of any other services running in the ecosystem. In this example, Microservice 1 does not have any knowledge of Microservice 2 and Microservice 3. Choreography can be achieved by connecting an output queue of one service to the input queue of another service, as shown in the diagram.

Based on the velocity of events, services can automatically scale up by spinning up replicas of instances. For example, in a reactive style order management system, as soon as an order is placed, the system will send out an Order Event. There could be many microservices listening to an Order Event. Upon consuming this event, they perform various things. This design also allows developers to keep adding more and more reactive routines as need arises.

The flow control or choreography in case of reactive microservices will be taken care of automatically, as shown earlier in the diagram. There is no central command and control. Instead, messages and input and output contracts of microservices itself will establish flow. Changing the message flow is easy to achieve by rewiring input and output queues.

The Promise theory proposed by Mark Burgess in 2004 has so much relevance in this situation. The Promise theory defines an autonomous collaboration model for systems or entities to interact in a distributed environment using voluntary cooperation. The theory claims that promise-based agents can reproduce the same behavior exhibited by traditional command and control systems that follows the obligation model. Reactive microservices are inline with the Promise theory, in which, each service is independent and can collaborate in a completely autonomous manner. Swarm Intelligence is one of these formal architecture mechanisms, increasingly applied in the modern artificial intelligent systems for building highly scalable intelligence routines.

A highly scalable and reliable message system is the single most important component in a reactive microservices ecosystem. QBit, Spring Reactive, RxJava, and RxJS are some of the frameworks and libraries that help you build reactive microservices. Spring 5 has inbuilt support to develop reactive web applications. Spring Cloud Streams are good choice to build truly reactive microservices using Spring Framework.

主站蜘蛛池模板: 凤阳县| 汕头市| 青川县| 林西县| 屏山县| 扶余县| 马尔康县| 大竹县| 佛教| 苏州市| 屯昌县| 中西区| 平阳县| 定陶县| 郓城县| 鸡东县| 南昌县| 康乐县| 红原县| 阳江市| 安平县| 新疆| 静海县| 保亭| 获嘉县| 称多县| 桑植县| 屏边| 耒阳市| 元谋县| 温州市| 建瓯市| 丽水市| 于都县| 荔波县| 堆龙德庆县| 伊川县| 濮阳市| 张掖市| 临潭县| 昭觉县|