[by @kormanocorp] 이벤트 기반 마이크로서비스?

in hive-137029 •  2 years ago 

원본 글 보러가기 : 이벤트 기반 마이크로서비스?

작성자 : @kormanocorp 미리보기 (5 sentences)


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

그것이 무엇을 의미하는지 진정으로 알지 못하지만, 그럼에도 불구하고 관련 슬라이드에서 오류가 분명했습니다.Vikas Anand 프레젠테이션의 이벤트 중심 아키텍처 슬라이드

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

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

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


더 보기 에서 확인 하실 수 있습니다.


[광고] 개발자 커뮤니티에 참여하세요 - 개발자 커뮤니티에 참여 하면 다양한 혜택을 받을 수 있습니다. 참여방법

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!