마이크로 서비스는 서로 대화해야합니까?

Micro-Services를 사용하여 응용 프로그램을 설계하고 있으며 여러 서비스에서 데이터를 수집하는 데 사용할 수있는 최상의 메커니즘이 확실하지 않습니다.

두 가지 옵션이 있다고 생각합니다.

• 서비스가 직접 대화 할 수있는 '서비스 간'통신 메커니즘을 통합합니다. API Gateway는 개별 서비스를 호출 한 다음 통합 된 응답을 API Gateway로 반환하기 전에 다른 서비스를 호출하여 데이터를 수집합니다. 그런 다음 API는 응답을 호출자에게 반환합니다. serviceB를 호출 할 때 serviceA.IE 별도의 개인 및 주소 서비스의 응답이 필요한 경우 동기 호출이어야합니다.
• 응답을 리턴하기 전에 API 게이트웨이가 각 서비스를 직접 호출하고 API 내의 데이터를 통합하도록하십시오.

서비스가 서로 대화하게하면 커플 링이 발생할 수 있으므로 두 번째 옵션을 기대하고 있습니다.이 경우 모 놀리 식 응용 프로그램을 설계 할 수도 있습니다. 그러나이 옵션으로 내 머리 꼭대기에서 벗어날 수있는 몇 가지 심각한 단점이 있습니다.

• API가 여러 서비스에 대한 여러 호출을 실행하게하면 특히 일부 호출이 차단 될 때 API 서버의로드가 증가합니다.

• 이 방법은 API가 애플리케이션이 수행하려는 작업을 '인식'해야한다는 것을 의미합니다 (IE 로직은 서비스 호출을 처리 한 다음 데이터를 통합하기 위해 API로 프로그래밍되어야 함). 마이크로 서비스의 멍청한 '종점'역할을합니다.

이 문제에 대한 표준 접근법이 무엇인지, 누락 된 또 다른 세 번째 옵션이 있는지 알고 싶습니다.

나는 일반적으로 마이크로 서비스가 서로 동기식으로 통신하는 것을 반대 할 것을 권고합니다. 큰 문제는 커플 링입니다. 서비스 중 하나가 실패하면 두 번째 서비스가 완전히 또는 부분적으로 작동하지 않습니다.

상태 변경 작업과 읽기 작업 (CQS Command Query Separation )을 명확하게 구분 합니다. 상태 변경 작업을 위해 일종의 메시징 인프라를 사용하고 불을 피하고 잊어 버렸습니다. 쿼리의 경우 동기 요청 응답 통신을 사용하고 http API를 사용하거나 데이터 저장소로 직접 이동할 수 있습니다.

메시징을 사용하는 경우 서비스 간 이벤트 발생에 대한 publish subscribe를 볼 수도 있습니다.

고려해야 할 또 다른 요점은 내부 상태를 노출하면 판독기가 잘못된 데이터 상태 또는 잘못된 버전을 가져오고 잠재적으로 데이터를 잠글 수있는 (트랜잭션) 데이터 공유 (읽기 전용보기와 반대)입니다.

마지막으로, 서비스를 자율적으로 유지하기 위해 (적어도 논리적 수준에서) 가능한 모든 작업을 수행하십시오.

이것이 의미가 있기를 바랍니다.

해당 데이터가 필요한 이유에 따라 다릅니다. UI 인 경우 완벽하게 좋습니다. 또한, 그것이 있어야하는 방법입니다. Chris Richardson은이 개념에 대해 잘 설명 하고 있으며 Sam Newman은 Frontends for Backends 라는 매우 유사한 개념에 대한 훌륭한 기사를 가지고 있습니다.

그러나 일부 논리에 필요한 경우 서비스 경계가 잘못되었을 가능성이 있습니다.

상식은 우리 의 서비스가 소유해야한다는 몇 가지 특성 이 있습니다 . 그들은:

1. 낮은 커플 링. 서비스 A를 약간 변경하면 서비스 B에 영향을 미치지 않게됩니다.
2. 높은 응집력. 일부 기능을 구현해야하는 경우 가능한 적은 수의 서비스가 영향을 받기를 원합니다.
3. 높은 자율성. 일부 서비스가 실패하면 전체 시스템이 다운되는 것을 원하지 않습니다.
4. 정확한 입도. 네트워크가 생각보다 복잡 하기 때문에 서비스가 지나치게 대화하기를 원하지 않습니다 .
5. 서비스는 이벤트를 통해 통신해야합니다. 유지 관리 효율성이 떨어지기 때문에 서비스가 서로를 인식하기를 원하지 않습니다. 새 서비스를 추가해야하는 경우 어떻게되는지 생각해보십시오.
6. 분산 데이터. 서비스는 정보가 저장되는 방식을 공유해서는 안됩니다. 좋은 대상과 마찬가지로 데이터가 아닌 동작을 노출합니다.
7. 오케스트레이션을 통한 서비스 안무.

이를 달성하기 위해 서비스 경계를 ​​비즈니스 기능으로 취급하십시오 . 서비스 경계를 ​​식별하는 공식적인 프로세스는 다음과 같습니다.

1. 더 높은 수준의 경계를 식별하십시오. 나는 그것들을 조직이 비즈니스 목표를 달성하고 비즈니스 가치를 얻기 위해 따라야하는 단계라고 생각합니다. Porter 's Value chain을 살펴보면 기본적인 단계를 알 수 있습니다 .
2. 각 서비스 내에서 더 깊이 탐구하십시오. 자신의 책임으로 아동이 포함 된 유닛을 식별하십시오.
3. 그들이 의사 소통하는 방식을 염두에 두십시오. 올바른 서비스는 주로 이벤트를 통해 통신합니다. 조직 구조에 대해 생각하십시오. 내부의 통신은 상당히 집중적이지만 일반적으로 몇 가지 외부 이벤트가 노출됩니다.

예를 들어 이 방법을 적용하는 몇 가지 관심이있을 수 있습니다.

나는 당신의 "API 게이트웨이"에 불구하고 아마 기본적으로뿐만 아니라 두 번째 방법으로 의지 할 것입니다,하지만 난 완전히 합리적인 크리에이트 간주하는 새로운 그의 유일한 목적은 다른 마이크로 서비스에 조율 요청을했다 마이크로 서비스 및 대표 더 높은 수준의 데이터 마이크로 서비스 아키텍처에서, "기본"마이크로 서비스가 서로 직접 통신하는 것에 반대합니다.

이것을 조금 덜 주관적으로 만들기 위해 첫 번째 서비스가 두 번째의 데이터 또는 서비스를 직접 또는 간접적으로 요구하는 경우 한 서비스 가 다른 서비스에 의존 한다고 가정 해 봅시다 . 수학 용어로,이 관계 는 사전 순서가 아닌 부분 순서 가되기를 원합니다 . 다이어그램 형식으로 종속성 다이어그램을 플로팅하면 Hasse 다이어그램이 나타납니다.(지시) 사이클이 없습니다. Hasse 다이어그램에서 가장자리는 암시 적으로 아래쪽에서 높은쪽으로 향합니다. 추가 지침으로 위쪽에서 아래쪽으로 경로가 일반적으로 더 짧아지기를 원합니다. 이것은 기본적으로 사물에 더 직접 의존하고 싶다는 것을 의미합니다. 그 이유는 특정 요청에 대해 잘못 될 수있는 일의 수를 최소화하고 오버 헤드를 최소화하며 복잡성을 감소시키기 때문입니다. 따라서이 메트릭의 "이상적인"경우 Hasse 다이어그램에는 두 가지 수준 만 있습니다. 물론 캐싱, 통합,로드 밸런싱, 장애 관리와 같은 중간 서비스를 도입해야하는 이유는 많이 있습니다.

API 게이트웨이를 "스마트"하게 만드는 두 번째 관심사를 자세히 설명하기 위해 Falcor 및 Relay / GraphQL 과 같은 프레임 워크에서 현재 주목 받고있는 패턴 은 "API 게이트웨이"가 일반적으로 수행 될 수 있도록 수행 할 작업에 대한 추가 사양을 요청하는 것입니다. 무엇이 필요한지 알 GetTimeline필요 없이 해당 사양을 실행하십시오 . 대신 "사용자 서비스에서이 사용자 정보를 요청하고 포스트 서비스에서 이러한 게시물을 가져옵니다"와 같은 요청을받습니다.

마이크로 서비스가 서로를 "호출"해야 할 필요가있을 때, 마이크로 서비스가 서로를 "호출"해야 할 필요가 있기 때문에 서비스가 서로 "호출"해야 할 필요가 있다고 가정합니다. 마이크로 서비스는 적절하게 설계되었습니다.

해결하려는 문제에 대해 더 자세히 설명 할 수 있습니까? 간단한 영어로?