이벤트 기반 마이크로서비스?

Google Apigee API 관리 제품의 제품 이사인 Vikas Anand 가 최근 2022년 EDA Summit에서 " 통합 API 및 이벤트 전략에 대한 사례" 프레젠테이션을 했을 때 저는 발표된 내용의 번쩍이는 오류에 다시 한 번 충격을 받았습니다. , 많은 이점을 제공하지만 관리해야 하는 복잡성도 가져옵니다. 이벤트 기반 아키텍처 라는 솔루션을 제공하여 기본적으로 이를 더 잘 관리할 수 있습니다 . 이것은 이 문제에 대한 솔루션, 마이크로 서비스 및 대규모 솔루션을 생성하여 애플리케이션의 종속성과 복잡성을 줄이는 기능을 제공하는 동시에 점점 더 많은 마이크로 서비스를 생성할 수 있습니다."

그것이 무엇을 의미하는지 진정으로 알지 못하지만, 그럼에도 불구하고 관련 슬라이드에서 오류가 분명했습니다.

여기에서 Vikas는 마이크로서비스가 항상 워크로드에 대해 서로 경쟁하면서 항상 "경쟁 소비자"로 배포된다는 사실을 잊어버리기로 결정한 것 같습니다. 그러나 Vikas의 바닐라-EDA 슬라이드를 주의 깊게 살펴보면 이 필수 세부 사항은 어디에도 없으며 지원되지도 않습니다. 대신 단일 "이벤트 채널"이 표시되고 "다중 구독자가 구독합니다."라는 메시지가 표시됩니다. 이는 여러 마이크로 서비스를 의미합니다. 이것이 그가 EDA 접근 방식이 "점점 더 많은 마이크로 서비스 생성을 허용한다"고 주장하는 이유입니다.

설명되지 않은 것은 이 다이어그램에 표시된 3개의 마이크로서비스 각각(3개의 "경쟁 소비자" 각각)이 정확히 동일한 채널에서 정확히 동일한 이벤트를 수신할 때 모두 정확히 동일한 작업을 수행하지 않는 이유입니다. 모두 구독했습니다. 실제로, 어떤 이벤트라도 위의 예에서 동일한 작업이 3번 수행되도록 하는 것이 분명합니다. 이는 경쟁 소비자의 개념이 전혀 없습니다.

그럼에도 불구하고 Vikas는 " 이벤트 기반 마이크로서비스 "가 그럼에도 불구하고 미래 라고 알려줍니다 . "이는 마이크로서비스의 이 문제에 대한 솔루션과 대규모 솔루션을 생성하여 애플리케이션의 종속성과 복잡성을 줄이는 기능을 제공합니다." Vikas는 이러한 복잡성을 단순히 무시함으로써 "응용 프로그램의 복잡성"을 줄이는 것을 제안하는 것 같습니다. 대신 이러한 복잡성에 대해 진지하게 생각해야 한다면 마이크로서비스는 오늘날의 기술을 사용하여 "이벤트 중심"이 될 수 없으며 오직 "이벤트 중심" 만이라는 점을 이해해야 합니다.(예: 이벤트 브로커 및 공개적으로 액세스할 수 있는 주제가 아닌 대상 특정 메시지 대기열과 함께 메시지 브로커 사용). 이것이 바로 제가 2020년 중반에 EDA 커뮤니티가 새로운 개념인 macroservices 의 소유권을 가져야 한다고 제안한 이유 입니다.

오늘날의 마이크로 서비스 와 달리 매크로 서비스는 "경쟁 소비자"를 나타내지 않기 때문에 "이벤트 기반"일 수 있습니다. 대신, 그들의 워크로드는사용 가능한 "작업 프로세스"가 있는 즉시 개별 매크로 서비스 작업을 시작 하는 단일 데이터베이스가 있는 단일 "소프트웨어 구성 요소"에 의해 관리됩니다(서버가 올바르게 크기). 그런 m acro서비스 접근 방식은 오늘날 많은 개발자들이 전환하고 있는 접근 방식인 초고성능 Node.js 이벤트 루프와 유사합니다. 이것은 마이크로서비스 환경의 복잡성과 비용의 아주 작은 부분만을 요구하는 접근 방식입니다. 아마도 Uber가 2020년 4월에 마이크로서비스를 공개적으로 포기하기 시작한 이유일 것입니다(@GergelyOrosz의 트윗 참조).

사실 Vikas의 "이벤트 기반 마이크로서비스"라는 용감한 새로운 세계에는 두 번째 번쩍이는 오류가 있습니다. 바로 오늘날 경쟁하는 소비자 제약으로 인해 마이크로서비스 엔드포인트가 동기식으로 트리거됩니다. 반면에 이벤트는 항상 비동기식으로 전달됩니다. 브로커는 특정 순서 없이 모든 주제 구독자에게 실제로 새 이벤트를 전달할 수 있기 전에 먼저 주제 구독자가 있는지 확인해야 합니다.

논의된 생략의 엄청난 양에도 불구하고 Google-bashing의 인상을 주지 않기 위해 EDA Summit 후원자인 Solace의 CTO가 발표한 프레젠테이션에서 정확히 동일한 오류를 보았다는 점을 언급하고 싶습니다. Shawn McAllister는 "Powering Your Real-Time, Event-Driven Enterprise with PubSub+ Platform " 프레젠테이션에서 말했습니다.소매 부문도 "이벤트 기반 마이크로서비스"로 이동하고 있다는 사실과 "이벤트 기반 마이크로서비스"가 완벽한 조화와 협력으로 나란히 작동한다는 인상을 받는 다음 슬라이드를 제공합니다. , 동시에 완전히 서로 독립적입니다. 경쟁하는 마이크로서비스는 "이벤트 메시"에서 동일한 주제를 구독하기만 하면 됩니다. 그러면 이러한 각 자율 이벤트 소비자는 어떤 이벤트가 이미 처리되었거나 아직 처리되지 않았는지 어떻게든 알 수 있습니다. – 비동기적으로 – 경쟁 소비자 동료에 의해.

단순히 Google과 Solace에 "이벤트 기반 마이크로서비스" 프레젠테이션이 단순히 계산되지 않는다는 점을 지적하는 것보다 실제로 약간의 도움을 제공하는 것이 상대적으로 쉽습니다. 경쟁 소비자인 마이크로서비스는 동일한 채널에 가입할 수 없습니다. /주제는 작업 부하에 대한 것입니다. 대신, 각각은 전용 메시지 대기열에 따라 정확히 고유한 전용 주제가 필요합니다.메시지 브로커와 비슷하지만 큰 변형이 있습니다. 각 마이크로서비스가 가용성을 게시하는 전용 주제가 필요합니다. 오늘날 메시지 브로커(일반적으로 하위 시스템에 워크로드를 분산 최적의 라운드 로빈 기반). "마이크로서비스" 또는 기타 가능한 작업자가 온라인 상태가 되면 워크로드 디스패처에 가용성을 게시하기만 하면 됩니다. 새 작업이 표시되면 Node.js 이벤트 루프와 마찬가지로 워크로드 디스패처는 "작업자 가용성" 주제에 게시된 이벤트를 순차적으로 사용하기만 하면 됩니다. 최신 Worker.Available이벤트 에 지명되었습니다 .

운영 체제 개발자들이 수십 년 동안 거의 동일한 접근 방식을 사용해 왔다는 점에는 의심의 여지가 없지만(모든 커널이 작업 프로세스의 새로운 가용성을 분명히 인식해야 한다는 점을 감안할 때) 이러한 브로커 중심의 경우 혁명적이라고 생각할 수 있습니다. 접근 방식은 "작업자 가용성" 주제에 가용성을 게시하는 작업자가 이전의 작업 프로세스와 달리 더 이상 동일한 하드웨어에서 실행할 필요가 없다는 것입니다. 실제로 사용률이 낮은 PC, 랩톱, 휴대폰, TV 및 냉장고 CPU 간에 가정의 작업량이 병렬로 공유되는 것을 상상하는 것은 매우 쉽습니다.

출처 : https://dzone.com/articles/event-driven-microservices-1