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

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.

主站蜘蛛池模板: 年辖:市辖区| 赣榆县| 天长市| 灵山县| 云和县| 安国市| 忻城县| 吴江市| 三江| 汉寿县| 丹江口市| 江都市| 喀什市| 临清市| 剑河县| 寻乌县| 元阳县| 镇雄县| 名山县| 靖西县| 会理县| 巴林左旗| 泾源县| 贵南县| 灵寿县| 赤峰市| 德庆县| 客服| 岳阳市| 安西县| 西城区| 灵寿县| 丹东市| 新绛县| 潜江市| 洪湖市| 秀山| 吴堡县| 万州区| 辽宁省| 鞍山市|