- Spring 5.0 Microservices(Second Edition)
- Rajesh R V
- 755字
- 2021-07-02 19:44:59
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.
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.
- 手機安全和可信應用開發指南:TrustZone與OP-TEE技術詳解
- Android Wearable Programming
- Getting Started with ResearchKit
- Python金融數據分析
- 你必須知道的204個Visual C++開發問題
- 精通Python自動化編程
- Java網絡編程核心技術詳解(視頻微課版)
- SSM開發實戰教程(Spring+Spring MVC+MyBatis)
- 從零開始:UI圖標設計與制作(第3版)
- Building Dynamics CRM 2015 Dashboards with Power BI
- Exploring SE for Android
- OpenCV Android Programming By Example
- iOS開發項目化入門教程
- Java EE架構設計與開發實踐
- Joomla!Search Engine Optimization