4

영어로 죄송합니다 - 명확하지 않은 부분이 있으면 의견을 물어보십시오.마이크로 서비스 아키텍처로 이메일 보내기

마이크로 서비스 아키텍처에서 시스템을 구축합니다. 나는 사용자 정보가있는 하나의 서비스, "오퍼"를위한 하나의 서비스, "아이디어"를위한 하나의 서비스를 가지고 있습니다. "로그인"및 기타 작업에서 "제안"및 "아이디어"서비스가 "사용자"서비스와 comunicate (Restful API에 의해)됩니다. 그리고 나는 궁금하다 - 어떻게 이메일을 다루는가? 각 서비스는 프론트 엔드를 분리하고 일부 작업 (예 : 일부 제 3의 사람이이 제안을 작성한 사용자에게 전자 메일을 받으면 링크를 열 때 또는 일부 사용자가 관리자가 전자 메일을받을 아이디어를 작성할 때)를 보낸 후에 전자 메일을 보냅니다. 또한 각 서비스 프론트 엔드에서 관리자는 계절 통계 데이터 나 기타 정보를 사용하여 "정기"메일 링을 만들 수 있습니다. 각 서비스 이메일은 다르게 보입니다.

나는 많은 선택권이 있으며 어떤 것이 더 좋을지 모른다.

  1. 각 서비스는 자신의 별도의 이메일 전송 시스템을 가지고 있으며, 이메일 을 모든 종류의 전송 (작업 후,주기적인) 독립이 몇 가지 제안입니다.
  2. "사용자 서비스"는 "엔진"이 작업을 보내고 정기적 인 전자 메일 및 기타 서비스가 작업을 제공합니다. 내부 작업에는 작업을 제공하는 서비스에 대한 링크가 있으며 링크를 통해 전자 메일 내용 (예 :주기적인 전자 메일의 통계 데이터)이 생성됩니다. 이 솔루션은 복잡합니다 ...
  3. "사용자 서비스"는 정기적 인 전자 메일 (작업에는 전자 메일 본문을 생성하는 링크가 있습니다 ...)이 있지만 작업 후 전자 메일은 각 마이크로 서비스마다 개별적으로 전송됩니다
  4. 새 마이크로 서비스 만들기 전용 적절한 API를 사용하여 이메일을 정기적으로 보내고 ("조치 후") 물론 "제공"과 같은 각 서비스는 메일 링 작업에 링크를 (자신에게) 보내야합니다 -이 링크는 정기적 인 이메일이 전송되고이 링크의 응답이 이메일 본문으로 생성 될 때 호출됩니다 ....

어느 쪽이 더 좋을까요? 아니면 더 나은 대안이있을 수 있습니까?

답변

4

이메일을 보내는 것은 다른 서비스 (SMTP를 통해)에게 요청하는 것과 같습니다. 따라서 모든 서비스가 전자 메일을 보낼 수있는 좋은 접근 방법입니다.

물론 템플릿 렌더링, 코드 전송, 구성 등과 같은 이메일 전송을위한 일반적인 논리가 있습니다. 이 논리는 공통 코드 (dll, 패키지 등)를 통해 서비스간에 공유되어야합니다.

그래서,이 방법 :

  1. 당신은 돈 서비스간에 공유되는 이메일을 보내는 이메일을
  2. 공통 코드를 전송해야 할 경우 모든 서비스가 다른 서비스에 의존하지 않는다 ' 전용 전자 메일 전송 서비스가 필요한 경우 개발, 배포 및 네트워크 오버 헤드가 있음

이 방법의 단점은 모든 서비스가 동일한 전자 메일 공동 nfiguration (SMTP 주소, 로그인, 암호 등). 그러나 모든 서비스간에 구성을 공유하면 문제가되지 않습니다.