point-to-point 통합에 대한 해결책으로 ESB에 대해 혼동 됨

Question

마이크로 아키텍처에 대한 책에서 아이디어를 얻지 못하고 여전히 응용 아키텍처를 공부하는 데 새로운 경험이 있습니다. 필자는 ESB (Enterprise Service Bus)에 대한 기존 아이디어와 새로운 서비스와 레거시 애플리케이션 간의 메시지 조정에 대한 역할에 대해 읽었습니다. ESB는 지점 간 통합으로 인한 문제에 대한 해결책으로 강요 받고 있습니다. 마이크로 서비스는 민첩하고 확장 가능하며 탄력적 인 앱을 만들기위한 사실상의 표준으로 새로운 회사가 채택한 접근 방식 인 것 같습니다. 그러나 point-to-point 통합을 사용하는 마이크로 서비스가 아닌가? 마이크로 서비스로 구축 된 애플리케이션의 각 노드는 다른 노드와 직접 통신합니다. 나는 연결해서는 안되는 점들을 연결하고 있다고 느낍니다. 어떤 도움을 주셔서 감사합니다. 미리 감사드립니다.

Answer 1

Microservices 반드시 엄격하게 의존하지 않는 참조 포인트 투 포인트 (point-to-point) 통합.

직접 통신과 관련된 문제는 종종 메시지 브로커를 사용하는 마이크로 서비스 아키텍처에서 관리됩니다. 비동기 적으로 통신이 가능하다면 ("불과 잊다"), 수신자가 다운되면 메시지를 보내는 응용 프로그램이 작동하지 않게됩니다. 그리고 수신 서비스가 복구 될 때 메시지가 계속 나타납니다.

마이크로 서비스가 REST를 통해 통합되는 경우 호출자는 다른 서비스가 응답하지 않는 경우 반응하는 방법을 알아야합니다. 시스템 (예 : 분산 트랜잭션)에 데이터를 저장하는 경우 털이 발생하기 때문에 데이터 검색 API에만 REST를 사용하고 싶습니다. 그리고 메시지의 결과로 모든 것을 저장하십시오.

메시징보다 ESB가 더 중요하다는 점에 유의해야합니다. See more on that in the answer here.

Answer 2

ESB는 애플리케이션 상호 운용성 및 추적 성을 보장하기 위해 많은 회사에서 구현 된 솔루션입니다. 그러나 이들은 수평 적으로 확장 할 수없는 무거운 솔루션입니다. 일반적으로 ESB는 액티브 - 액티브 또는 액티브 - 패시브의 두 노드 구성을 채택합니다.

반면에 ESB의 서비스는 일반적으로 개별적으로 배포되지 않지만 배포 패키지에서는 다른 서비스와 함께 배포되므로 배달 관리 및 테스트가 더욱 복잡해집니다.

마이크로 서비스는 개별적으로 개발 및 배포되도록 설계되었으므로 클라우드 인프라 내에서 쉽게 수평 적으로 확장하여 인스턴스 수를 동적으로 늘릴 수 있습니다.

일부 오래된 인프라에서는 연결을 해결하는 일부 미들웨어가 여전히 필요할 수 있지만 웹 서비스에 의한 오늘날의 통신은 사실상 일반적이기 때문에 응용 프로그램 간의 상호 운용성은 현재 배경으로 이동했습니다.

Answer 3

두 가지 방법 모두 독점적 일 필요는 없습니다. 마이크로 서비스는 직접 http 채널 대신 메시징 미들웨어 (kafka, AMQP, Akka actors, JMS ...)를 사용하여 통신 할 수 있습니다. 제약 조건 (주로 일관성)과 배포 정책에 따라 다릅니다.

각각의 선택은 자신의 강점과 약점을 가지고, 내가 개인적으로 각 상황에 따라 둘 다 사용 및 선택에 불과 하나의 접근 방식에 자신을 제한하지 않도록 조언

Microservices: REST vs Messaging 및 https://capgemini.github.io/architecture/is-rest-best-microservices/이

Answer 4

마이크로 서비스는 ESB를 대체하지 않습니다.

마이크로 서비스 은 API를 포함하여 백엔드 시스템을 개발하기위한 개념입니다.마이크로 서비스 접근법의 반대는 단일체입니다. API가 소비 시스템에 의해 직접 소비된다면 우리는 점대 점 (스파게티) 통합을하게됩니다. 소비자가 API 게이트웨이라고하는 미들웨어를 사용하는 경우 ESB와 마찬가지로 중앙 집중식 가시성, 보안 및 추적 기능을 제공 할 수 있습니다. API 게이트웨이는 ESB보다 간단하므로 수평 확장에 더 적합합니다. API 게이트웨이에는 추가 비즈니스/통합 논리가 포함되어서는 안됩니다.

ESB은 프록시 (프록시 역할을 함)와 동일하지만 비즈니스 로직을 포함하고 하나 이상의 고급 기능에 여러 서비스를 구성 할 수 있습니다. ESB는 종종 오버 헤드가 크고 부가가치가 낮은 부담스러운 솔루션으로 성장하여 미움을 받았습니다.

결론

ESB는 microservices 아키텍처와 함께 사용할 수 있습니다

은 간단한 ESB를 유지 많은 기업이 있고 그렇게 API 게이트웨이라는 거의 동일합니다.

내 의견

API 게이트웨이는 새로운 기능을 소개하고 ESB 가까이오고, 더 복잡지고있다.