Go Reactive Systems
최근 몇 년전만 해도 응답시간 수초, 수십개의 서버, 기가단위의 데이터로 시스템이 구성되었지만 오늘날에는 모바일, 수천대의 클라우드 기반환경으로 변화하면 millisecond단위의 응답시간, 페타바이트 데이터 등의 요건으로 인해서 과거의 소프트웨어 아키텍처로는 이를 수용하기가 어려운 상태이다.
결국 우리는 Responsive, Resilient, Elastic and Message Driven 한 시스템을 원하고 이것을 Reactive Systems이라고 부른다. ( 보다 유연하고 scalabe하면서 장애도 방지하는 그런 시스템)
Reactive Systems are:
Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.
Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.
Large systems are composed of smaller ones and therefore depend on the Reactive properties of their constituents. This means that Reactive Systems apply design principles so these properties apply at all levels of scale, making them composable. The largest systems in the world rely upon architectures based on these properties and serve the needs of billions of people daily. It is time to apply these design principles consciously from the start instead of rediscovering them each time.
참고)http://www.reactivemanifesto.org/
===============================================================================================================
슬라이드쉐어에서도 공유가 되고 있으니 참고할 수 있다.
===============================================================================================================
디스크, 메모리, 서버등의 자원은 갈수록 저렴해지고 일반적이 되어가고 있으며 동시사용자는 기하급수적으로 늘어났다.
과거 중요한 서비스는 반드시 죽지 않아야 하고 고정되어 requset/response를 보장한다는 개념에서,
이제는 수백,수천개를 띄워놓고 사용자 수에 따라서 서비스량을 조정하면서도 약간의 문제는 상관하지 않고 돌아간다는 개념으로 변화하고 있다.
패러다임 변화에 따라서 어플리케이션도 변경이 되어야 한다는 내용.
이러한 내용을 반영하여 나온 것이 reactive programming으로 현재 typesafe에서 주도하고 있다.
akka,scala를 통해서 이를 구현하고 있으며 많은 IT서비스기업에서 사용하고 있다.