자율 마이크로 서비스, 이벤트 대기열 및 서비스 검색

나는 최근에 마이크로 서비스에 대해 많은 것을 읽었으며 여기까지 내가 얻은 결론 중 일부가 있습니다 (어쨌든 틀렸다면 정정하십시오).

1. 마이크로 서비스 아키텍처는 도메인 중심 디자인과 잘 어울립니다. 일반적으로 하나의 MS는 하나의 경계 컨텍스트를 나타냅니다.
2. 마이크로 서비스 A 가 마이크로 서비스 B에 상주하는 기능을 필요로 하는 경우 , 내 모델이 잘못되었을 수 있으며 A 와 B 는 실제로 하나의 마이크로 서비스 / BC 여야합니다.
3. 마이크로 서비스 (직접 HTTP 요청) 간의 동기 통신이 잘못되어 마이크로 서비스의 목적을 무시하고 구성 요소간에 커플 링이 발생합니다.
4. 서비스 간의 비동기 통신이 바람직합니다. 서비스는 이벤트를 메시지 큐에 게시해야하므로 다른 서비스는 해당 이벤트의 일부를 구독하고 처리하거나 컨텍스트를 사용하여 필요한 일부 데이터를 복제 할 수 있습니다. 이런 식으로, 서비스는 다른 서비스가 다운 된 경우에도 요청을 처리 할 수 ​​있으며 동기 통신에서는 그렇지 않습니다.
5. 마이크로 서비스 A가 이벤트를 공개 하면 마이크로 서비스 B 가 해당 이벤트를 구독하고 결과로 새 이벤트를 생성하는 경우 마이크로 서비스 A 는 새로 작성된 이벤트를 처리 하는 것이 아니어야합니다. 원인은 순환 종속성입니다. 이 경우 세 번째 마이크로 서비스를 도입하거나 A 와 B 를 AB 마이크로 서비스 에 결합해야 합니다.
6. 마이크로 서비스 는 실제로 잘못된 용어입니다. 우리는 작은 맥락을 위해 노력해야하지만, 반드시 그런 것은 아닙니다. 용어는 "마이크로 서비스"가 아니라 " 직업 서비스를 수행하기에 충분히 큰 "이어야합니다 .
7. 마이크로 서비스를 사용하면 전체 시스템을 망칠 염려없이 새로운 기능을보다 쉽게 ​​도입 할 수 있습니다. 새로운 서비스를 도입하거나 기존 서비스 중 하나를 리팩토링하여 수행 할 수 있습니다.
8. 각 마이크로 서비스에는 자체 데이터 스토리지가 있어야합니다. 이 아키텍처에서는 데이터 복제 / 복제가 바람직합니다.

이 아키텍처에 대한 이해를 확인하는 것 외에, 질문의 다른 부분은 주로 서비스 검색과 관련이 있습니다. 서비스가 비동기식으로 통신하고 Amazon SQS와 같은 중앙 이벤트 큐를 사용하는 경우 서비스 검색이 아키텍처와 같은 위치에 있지 않습니까?

서비스는 시스템의 다른 서비스에 대한 지식이 없어야합니다. 그들은 게시하거나 구독해야하는 상황과 이벤트 만 알고 있습니까?

당신의 결론은 대부분 설립 된 것으로 보이며 마이크로 서비스로가는 길을 아주 훌륭하게 요약합니다.

그러나 2, 5 및 8을 완전히 지원하지는 않습니다.

• 2) 단순한 종속성이 자동으로 합병으로 이어지지 않아야합니다. 이러한 종속 통화의 빈도와 다른 서비스의 통화 빈도도 고려해야합니다.

  따라서 마이크로 서비스 A가 마이크로 서비스 B의 기능을 매우 자주 요구하고 다른 마이크로 서비스가 마이크로 서비스 B를 거의 필요로하지 않는다면, 예상되는 구조에 도전하여 두 마이크로 서비스를 그룹화하는 것이 더 적합한 지 묻어 야합니다.

• 5) 물론 메시지 처리에서 끝없는 사이클링을 피해야합니다.

  그러나 중개자를 추가해도 막을 수는 없습니다. A는 B가 처리 한 메시지를 시작하는 C가 처리 한 메시지를 시작할 수 있습니다.

  마이크로 서비스 수준을 고려해야 만 문제를 평가할 수 없습니다. 문제는 실제로 메시지 유형과 내용이 사이클로 이어질 수있는 내용에 관한 것입니다. 따라서 서비스 전체의 메시지 배포 및 처리를 모델링하는 그래프는 전체적으로 분석해야합니다 (사실 복잡 할 수 있으므로 이러한주기를 감지하여 중단시키는 모니터링 마이크로 서비스를 상상할 수 있습니다).

• 8) 예, 각 마이크로 서비스에는 전용 스토리지 / 데이터베이스가 있어야합니다.

  서비스를 독립적으로 만들려면 최소한의 복제가 필요합니다. 그러나 지금까지는 복제가 바람직하다는 것을 알지 못했습니다. 복제 프로세스를 통한 숨겨진 결합을 피하기 위해 최소로 유지해야합니다.

  마이크로 서비스는 느슨한 결합에 관한 것입니다. 때로는 데이터를 복제하는 대신 다른 마이크로 서비스를 호출하여 관련 데이터를 검색함으로써보다 효과적으로 달성 할 수 있습니다.

마지막으로 두 번의 번호가없는 확인은 너무 넓어서 여기에 제대로 대답 할 수 없습니다. 나는 당신의 제안이 좋은 출발점이라고 생각하지만 그것은 실제로 건축 요구 사항과 제약 조건에 달려 있다고 생각합니다.

마이크로 서비스는 서로 다른 기능 도메인을 분리하는 것입니다. 각 서비스는 다른 기술 스택을 사용하여 다른 팀에 의해 다른 속도로 개발 될 수 있습니다. 이것은 조직의 유연성을 만듭니다. 절충은 운영상의 복잡성으로, 각 추가 서비스는 운영 환경에서 관리해야 할 항목을 하나 더 만듭니다. 따라서 모놀리스와 마이크로 서비스의 근본적인 균형은 의존성을 피하는 것이 아니라 모든 것이 한 번에 모두 배송되어야하는 잠금 단계 개발 및 배포를 피하는 것이 아니라 더 자주 배송해야하는 비용으로 더 움직이는 부분.

서비스는 시스템의 다른 서비스에 대한 지식이 없어야합니다. 그들은 게시하거나 구독해야하는 상황과 이벤트 만 알고 있습니까?

의존성 회피 문제는 청어입니다. 제품 조각 간에는 항상 종속성이 있으며 별도의 서비스 또는 동일한 코드의 일부인지에 따라 종속성이 손상 될 수 있다는 사실이 변경되지 않습니다. 키 서버가 다운되어 운영 수준에서 중단 될 수 있으며 운영 중복성 및 페일 오버 방식을 통해 관리 할 수 ​​있습니다. 부품이 호환되지 않는 방식으로 변경되어 통합 테스트를 통해 감지하기 때문에 통합 수준에서 파손될 수도 있습니다. 서비스간에 코드를 섞어도 종속성이 손상 될 수있는 문제는 해결되지 않습니다. 종속성의 상실을 피하기위한 솔루션은 운영 중복성 및 통합 테스트이며 서비스 크기와는 무관합니다.

서비스가 비동기식으로 통신하고 Amazon SQS와 같은 중앙 이벤트 큐를 사용하는 경우 서비스 검색이 아키텍처와 같은 위치에 있지 않습니까?

이 질문에 대답하려면 먼저이 질문에 대답하십시오. 왜 비동기 적으로 통신하고 싶습니까? 별도의 구성 요소를 독립적으로 개발할 수 있습니까? 연중 무휴 시스템의 운영 가용성을 향상 시키는가? 후자라고 가정하고 큐를 사용하여 로컬 데이터베이스에 데이터를 복제한다고 가정 해 봅시다. 이제 데이터가 오래되었습니다. 어느 시점에서 너무 오래됩니다. 어떻게 대처할 수 있습니까? 또한 다른 런타임 구성 요소 인 대기열의 운영 가용성을 어떻게 보장합니까? 그리고 로컬 데이터베이스의 가용성을 어떻게 보장합니까? 하나의 데이터베이스 클러스터를 관리하는 대신 이제 여러 개의 클러스터가 있습니다. 운영팀이이 작업을 처리 할 수 ​​있습니까? 그리고 단순한 모놀리스를 구축하면 매월 더 많은 기능과 몇 시간의 가동 중지 시간으로 사용자가 더 행복 할 수 있을까요?

내 요점을 본 것 같아 시스템 설계는 옳고 그른 것이 아니라 다양한 트레이드 오프 중에서 선택하는 것입니다. 당신이 옳은 상황에서만 그것을 볼 수 있다면 틀린 모든 것이 옳고 그 반대 일 수도 있습니다. 귀하의 상황은 고유 그래서 우리는 당신에게 줄 수있는 동안 대답을, 그것은되지 않습니다 대답. 청중이 누구인지, 필요가 무엇인지, 올바른 디자인이 드러날 것임을 기억하십시오.

1. 마이크로 서비스 아키텍처는 도메인 중심 디자인과 잘 어울립니다. 일반적으로 하나의 MS는 하나의 경계 컨텍스트를 나타냅니다.

동의하지 않는다. DDD는 매우 OO 인 경향이 있습니다. 주문이 배달됩니까? 마이크로 서비스에는 DeliveryService.Deliver (order)가있는 반면 Order.Deliver ()

2. 마이크로 서비스 A가 마이크로 서비스 B에 상주하는 기능을 필요로하는 경우, 제 모델은 잘못된 것일 수 있으며 A와 B는 실제로 하나의 마이크로 서비스 / BC 여야합니다.

동의하지 않으면 마이크로 서비스를 소중하게 유지해야합니다. 더 작게 나누세요!

3. 마이크로 서비스 (직접 HTTP 요청) 간의 동기 통신이 잘못되어 마이크로 서비스의 목적을 무시하고 구성 요소간에 커플 링이 발생합니다.

동의하지 않는다. 서비스는 전화를 건 사람을 신경 쓰지 않아야하며 발신자는 논리가 마이크로 서비스에서 구현되는 것을 신경 쓰지 않아야합니다.

4. 서비스 간의 비동기 통신이 바람직합니다. 서비스는 이벤트를 메시지 큐에 게시해야하므로 다른 서비스는 해당 이벤트의 일부를 구독하고 처리하거나 컨텍스트를 사용하여 필요한 일부 데이터를 복제 할 수 있습니다. 이런 식으로, 서비스는 다른 서비스가 다운 된 경우에도 요청을 처리 할 수 ​​있으며 동기 통신에서는 그렇지 않습니다.

대기열이 좋습니다. 그러나 당신의 추론은 잘못되었습니다. 동기화 응답과 비동기의 유일한 차이점은 동기화 응답을 기다리는 것입니다. 대기열과 여러 작업자없이 RPC 스타일 호출을 구현할 수 있습니다.

5. 마이크로 서비스 A가 이벤트를 공개하면 마이크로 서비스 B가 해당 이벤트를 구독하고 결과로 새 이벤트를 생성하는 경우 마이크로 서비스 A는 새로 작성된 이벤트를 처리하는 것이 아니어야합니다. 원인은 순환 종속성입니다. 이 경우 세 번째 마이크로 서비스를 도입하거나 A와 B를 AB 마이크로 서비스에 결합해야합니다.

동의하지 않는다. 마이크로 서비스가 연결되어 있지 않기 때문에 순환 종속성이 아닙니다. 또한 당신은 센드 이메일을 보내기 위해 SendEmail, EmailFailed, SendAgain은 3 개의 마이크로 서비스가 필요하지 않습니다.

6. 마이크로 서비스는 실제로 잘못된 용어입니다. 우리는 작은 맥락을 위해 노력해야하지만, 반드시 그런 것은 아닙니다. 용어는 "마이크로 서비스"가 아니라 "작업 서비스를 수행하기에 충분히 큰"이어야합니다.

동의하지 않는다. 나노 서비스를 확인하십시오.

7. 마이크로 서비스를 사용하면 전체 시스템을 망칠 염려없이 새로운 기능을보다 쉽게 ​​도입 할 수 있습니다. 새로운 서비스를 도입하거나 기존 서비스 중 하나를 리팩토링하여 수행 할 수 있습니다.

동의하지 않는다. 그렇습니다. 디커플링이 가능하지만, 마이크로 서비스 오케스트레이션은 모놀리스 프로젝트만큼이나 어려울 수 있습니다.

8. 각 마이크로 서비스에는 자체 데이터 스토리지가 있어야합니다. 이 아키텍처에서는 데이터 복제 / 복제가 바람직합니다.

동의하지 않는다. 스토리지를 공유해서는 안되지만 마이크로 서비스는 가능한 경우 상태 비 저장 상태를 유지해야합니다. 기내가 아닌 한 데이터를 복제하지 마십시오

당신의 결론은 훌륭한 규칙이지만 보편적 인 것은 아닙니다. 그린 필드 프로젝트에서도 이러한 규칙을 어기는 것이 가장 좋은 방법입니다. 동기 통신이 가장 좋은 옵션 인 경우도 있습니다. 동기 통신으로 결합 된 경우에도 두 서비스를 하나로 병합하는 것은 좋지 않은 경우가 있습니다.

그리고 다른 질문으로, 대기열 기반 통신에는 서비스 검색이 필요하지 않습니다.

음, 당신은 객체 지향 프로그래밍에 대해서만 이야기하고 있습니다. 또는 최소한 원래 생각했던 것 : 메시지를 사용하여 서로 통신하는 독립적 인 실행 코드 조각.

Alan Kay는 세포가 상대적으로 서로 독립적이며 다른 세포의 외부 인터페이스에 연결되는 메시지를 통해 통신하는 생물학적 시스템을 모델로 한 OOP를 고안했습니다.

그렇다면 모든 개체가 동일한 컴퓨터에서 실행되고 있지 않다고 왜 OOP로 생각하지 않습니까? 이다 아무것도 경우 더 많은 객체 지향 가 동일한 응용 프로그램의 동일한 컴퓨터 및 부품에있어 것보다 모든 개체가 같은 응용 프로그램에있는 경우 때문에는, 다음 개발자들은 모든 클래스에 의해 공유 전역 변수를 사용하여 OOP를 깨고 각 파일에 동일한 헤더 포함 등 모든 객체가 동일한 항목에 의존하는 경우 서로 완전히 독립된 것처럼 캡슐화되지 않으며 캡슐화는 OOP의 핵심입니다.

예를 들어, 다른 답변에서 언급 된 모든 내용은 OOP에 대한 교과서입니다.

Bounded Context 및 Core Domain과 같은 중요한 개념에 대해 잘못 이해하는 경우가 많으므로 조금 더 자세히 설명하고 싶습니다.

하위 도메인을 비즈니스 기능으로 생각하면 수익성이 매우 높습니다. 비즈니스 기능은 조직이하는 일입니다. 비즈니스 기능 중 하나입니다. 우리의 목표는 비즈니스 -IT 연계 이기 때문에 기술 서비스와 1 : 1 관계 를 갖기를 바랍니다 .

이 과정은 다음과 같습니다. 먼저 더 높은 수준의 비즈니스 기능을 정의합니다. 명사와 동사 (또는 일부 파생 형태)의 형태를 취해야합니다. 일반적으로 10 개 미만의 비즈니스 기능이 있습니다. 그런 다음 중첩 된 기능을 식별하여 더 깊습니다. 그리고 분할 할 것이 없을 때까지. 이 접근 방식을 사용하게 된 기능은 조직이 작동하는 실제 방법을 실제 도메인에 반영합니다. 이러한 기능은 본질적으로 느슨하게 결합되므로 기술 서비스를이 기능에 매핑하면 자율적이고 이벤트 중심이됩니다. 이 프로세스를 비즈니스 기능 매핑 이라고 하지만 서비스를 찾는 다른 방법이 있습니다. 그 중 가장 눈에 띄는 것은 Value-Chain Analysis 입니다.

이 방법을 사용하여 서비스 경계를 ​​식별 하는 예 는 다음과 같습니다 .