마이크로 서비스 아키텍처에서 서비스가 서로 직접 대화해야합니까?

웹 응용 프로그램을 구성하는 많은 웹 서비스가 있습니다. 클라이언트는 REST API 호출을 통해 이러한 서비스에 액세스 할 수 있습니다.

이러한 서비스가 서로 직접 대화 할 수 있어야합니까? 그렇다면 마이크로 서비스 개념에 반하는 커플이되지 않습니까?

클라이언트가 웹 페이지를 클라이언트에로드하는 데 필요한 데이터를 얻기 위해 클라이언트에서 하나씩 직접 호출해야합니까?

또는 클라이언트의 요청을 처리하고 해당 요청에 대한 데이터를 가져온 다음 클라이언트로 다시 보내는 다른 레이어가 서비스 위에 있어야합니까?

당신의 서비스가이 그림처럼 보이기를 원한다면, 그렇습니다. 그것은 할 수없는 것과 같지 않지만 대부분의 경우 나쁜 결과를 초래할 것입니다. REST를 통한 통신은 서비스를 크게 분리하지 않습니다. 일부 서비스 인터페이스가 변경되면 모든 종속 서비스를 변경하고 재배치해야합니다. 또한 서비스를 재배치하는 동안 모든 종속 서비스를 내려 놓아야합니다. 이는 고 가용성 표준에 적합한 디자인으로 간주되지 않습니다.

결국, 당신은 대체 모노리스 앱보다 느리지 만 거의 모든 문제가 동일한 마이크로 서비스 애플리케이션을 갖게 될 것입니다!

@Robert Harvey에 동의하지 않습니다

그러나 실제로는 하나 이상의 마이크로 서비스 (아마도 모두)가 SQL 데이터베이스와 같은 일부 중앙 데이터 저장소와 통신합니다.

통합 데이터베이스는 잘 알려진 반 패턴

보다 나은 솔루션은 서비스 간 통신을 비 동기화하기 위해 publish-subscribe 패턴을 사용하는 것입니다.

이 커뮤니케이션 방법을 구현하는 CQRS / ES 방식을 살펴보십시오. Greg Young과 다른 사람들 은 이 주제에 대한 수많은 멋진 비디오 를 제공합니다. "CQRS / ES"키워드를 Google에 입력하십시오. 이 방식에서는 각 서비스가 동시에 게시자 및 가입자가되어 서비스를 훨씬 덜 결합시킬 수 있습니다.

다음은 주제와 관련된 논란에 빛을 비추는 마이크로 서비스에 대한 기사 시리즈입니다 . 멋진 삽화와 함께 매우 자세한 설명.

Udi Dahan이 SOA 에 대해 말한 것을 읽으면 많은 훌륭한 아이디어를 얻을 수 있습니다.

서비스는 특정 비즈니스 기능에 대한 기술 권한입니다. 모든 데이터 또는 규칙은 하나의 서비스 만 소유해야합니다.

이것이 의미하는 바는 서비스가 서로의 이벤트를 게시하고 구독하는 경우에도 모든 데이터 및 규칙에 대한 권위있는 진실 소스가 무엇인지 항상 알고 있다는 것입니다.

또한 비즈니스 기능의 렌즈에서 서비스를 볼 때 많은 사용자 인터페이스가 다양한 기능에 속하는 정보를 제공합니다. 즉, 제품 가격과 함께 제품 가격입니다. 위의 서비스 정의를 준수하기 위해 이러한 사용자 인터페이스는 실제로는 매시업이라는 것을 이해하게됩니다. 각 서비스는 UI의 조각을 통해 특정 데이터를 처리합니다.

UI 구성과 관련하여 Mauro Servienti의 UI 구성 에 관한 기사 는 좋은 출발점입니다. Udi의 비디오를 참조 하십시오 .

이러한 서비스가 서로 직접 대화 할 수 있어야합니까? 그렇다면 마이크로 서비스 개념에 반하는 커플이되지 않습니까?

두 서비스가 서로 메시지를 교환하면 몇 가지 연결이 발생합니다. 기본 답변은 다른 서비스의 API (서비스 내부가 변경 되어도 서비스가 안정적으로 유지되도록 약속하는 계약)와 연결되어 있다는 것입니다.

그 외에도 서비스 검색 과 같은 기술 은 특정 서비스 제공 업체에 대한 종속성을 완화 할 수 있으며 메시지 브로커는 생산자와 소비자를 분리 할 수 ​​있습니다 (여전히 서로의 메시지를 이해하고 메시지 브로커의 API와 상호 작용하는 방법이 필요함). ).

"직접"의 의미에 따라 다릅니다.

마이크로 서비스 아키텍처에 따르면 REST와 같은 인터페이스를 통해 자체 서버 또는 외부 서버에서 다른 마이크로 서비스를 호출하는 마이크로 서비스를 보유하는 것이 좋습니다.

좋지 않은 것은 하나의 마이크로 서비스가 직접 메소드 호출을 사용하여 다른 마이크로 서비스를 호출하는 것입니다. 그것은 두 마이크로 서비스를 동일한 단일체의 일부로 만들 것입니다.

이러한 서비스가 서로 직접 대화 할 수 있어야합니까? 그렇다면 마이크로 서비스 개념에 반하는 커플이되지 않습니까?

커플 링은 나쁜 단어가 아닙니다. 모든 어플리케이션에는 이미 어느 정도의 결합이 있습니다. 마이크로 서비스와 통신하는 응용 프로그램은 이미 마이크로 서비스 와 연결 되어 있습니다. 그렇지 않으면 작동하지 않습니다.

마이크로 서비스를 통해 실제로 추구하는 것은 느슨한 결합입니다 . 하나의 마이크로 서비스가 공개 API를 통해 또는 이벤트 버스를 사용하여 다른 마이크로 서비스를 조사하도록함으로써이를 달성 할 수 있습니다.

그러나 실제로는 하나 이상의 마이크로 서비스 (아마도 모두)가 SQL 데이터베이스와 같은 일부 중앙 데이터 저장소와 통신합니다. 목표 달성 방법에 따라 하나의 마이크로 서비스가 어떤 방식으로 데이터베이스 데이터를 변경하도록 할 수 있으며, 다른 마이크로 서비스가 변경을 가져 오기 위해 쿼리 할 수 ​​있습니다.

일반적으로 SOA와 아키텍처에 대해 말할 때 사람들은 의미와 전문 용어에 얽매이는 것 같습니다. 서비스를 "마이크로"하게 만드는 것은 무엇입니까? 궁극적으로, 사용하는 "점수 시스템"에서 서비스를 "미시적"으로 만들지 않는 것은 몇 가지 특성입니다. 대법원 판결이 부정에 대해 말한 것은 무엇입니까? "볼 때 ​​알 수 있습니다."

나는 어떤 사람들이 이것이 대답이 아니라고 말할 것이라고 확신하지만, 요점을 놓치고 있습니다. 마이크로 서비스 아키텍처는 몇 가지 문제를 피하기 위해 고안되었으며, 그 중 "꽉 조이는"문제가 있습니다. 따라서 서로에 대한 너무 많은 세부 정보에 의존하는 얽힌 마이크로 서비스를 만들면 펍 / 서브 메시지 버스를 사용하든 직접 호출을 사용하든간에 조각에서 새로운 솔루션을 작성하고 전체 시스템을 중단하지 않고 개별 조각을 재구성하는 기능 등

클라이언트가 웹 페이지를 클라이언트에로드하는 데 필요한 데이터를 얻기 위해 클라이언트에서 하나씩 직접 호출해야합니까?

때에 따라 다르지; 그러나 클라이언트에게 직접 사용할 수있는 기능을 제공하고 결과가 어떻게 구성되는지에 대한 세부 정보를 숨기거나 (캡슐화) (예 : 여러 마이크로 서비스를 통해) 제안합니다.

클라이언트가 개별 마이크로 서비스 결과를 결합하는 데 너무 많은 로직이 포함 된 경우, 일부 비즈니스 로직이 클라이언트에 우연히 발생할 수 있습니다. 또한 원하는 것보다 더 많은 내부 아키텍처를 클라이언트에 노출시켜 나중에 마이크로 서비스 리팩토링을 방해 할 수 있습니다.

즉, 마이크로 서비스의 경우, 클라이언트에게 유용한 추상화가있는 엔드 포인트를 제공하고 다른 (아마도 더 내부적 인) 마이크로 서비스의 상위 레벨 조정을 수행하는 랩퍼 마이크로 서비스를 갖는 것이 도움이되는 경우가 있습니다.

(또한 클라이언트 왕복 요금은 마이크로 서비스에서 다른 왕복 요금보다 비쌉니다.)

예를 들어 GraphQL이 취한 방향을 살펴보면 엔드 포인트에 직접 관련 쿼리를 발행하는 클라이언트를 찾을 수 있습니다.이 서비스는 micrservices 컬렉션으로 구현되거나 구현되지 않을 수 있습니다. 마이크로 서비스의 아키텍처는 GraphQL 뒤에 숨겨져 있기 때문에 아키텍처를보다 쉽게 ​​리팩터링하고 클라이언트에게 친숙하게 만들 수 있습니다. 예를 들어 https://stackoverflow.com/a/38079681/471129를 참조하십시오 .

마이크로 서비스의 주요 목적은 응용 프로그램을 느슨하게 연결하는 것입니다. 따라서 서비스는 서로를 호출 할 수 없습니다. 그렇지 않으면 묶여 있습니다. 그러나 데이터를 공유해야하는 두 가지 서비스가있는 경우 어떻게해야합니까? 답은 Message Broker입니다. 따라서 클라이언트에서 데이터를 가져 오는 서비스는 중앙 메시지 브로커와 데이터를 공유 할 수 있으며 서비스는 해당 데이터를 사용하여 데이터를 소비하고 변환하여 자체 데이터 저장소에 넣을 수 있어야합니다. Kafka Stream을 사용하면 다른 주제의 데이터를 즉석에서 조인 할 수 있으므로 Kafka를 권장합니다. 추신. 기능별로 마이크로 서비스를 분리하는 것이 좋습니다.