• 마이크로서비스 아키텍처는 분산 아키텍처이므로 IPC가 중요한 역할을 합니다.

• 서비스 API의 발전 과정을 잘 관리해야 합니다. 변경한 코드가 하위 호환되면 클라이언트에 영향을 끼치지 않으므로 적용하기 쉽습니다. API 코드를 많이 뜯어고쳐야 할 경우, 클라이언트가 모두 업그레이드되기 전까지 신구 버전 둘 다 지원되어야 할 필요가 있습니다.

• IPC 기술은 무척 다양하지만 각자 일장일단이 있습니다. 동기 RPC 패턴이냐, 비동기 메시징 패턴이냐는 중요한 설계 결정입니다. 사용성은 동기 RPC 프로토콜(예: REST)이 좋지만, 서비스 가용성을 높이려면 비동기 메시징 기반으로 서비스끼리 통신하는 것이 좋습니다.

• 시스템 전체에 실패가 전파되는 현상을 방지하려면 동기 프로토콜을 쓰는 서비스 클라이언트가 부분 실패(예: 호출한 서비스가 멎거나 지연 시간이 길어지는 등)를 처리할 수 있게 설계해야 합니다. 특히 요청 시 타임아웃을 설정하여 잔존 요청 개수를 제한하고, 회로 차단기 패턴을 이용하여 실패한 서비스가 호출되지 않도록 블로킹해야 합니다.

• 동기 프로토콜을 쓰는 아키텍처는 클라이언트가 서비스 인스턴스의 네트워크 위치를 찾을 수 있게 서비스 디스커버리 장치를 달아 주어야 합니다. 가장 간단한 방법은 배포 플랫폼(서버 쪽 디스커버리 및 서드파티 등록 패턴)에 구현된 서비스 디스커버리 장치를 사용하는 것입니다. 애플리케이션 수준(클라이언트 쪽 디스커버리 및 자가 등록 패턴)에서 서비스 디스커버리를 구현하면 작업량은 더 많지만 다중 배포 플랫폼에서 서비스를 실행하는 경우에도 처리가 가능합니다.

• 메시징 기반으로 아키텍처를 설계할 때에는 하부 메시징 시스템의 세 부분을 추상한 메시지와 채널 모델을 사용하세요. 그런 다음 해당 설계를 (대부분 메시지 브로커 기반의) 특정 메시징 인프라에 매핑합니다.

• 메시징에서 관건은 DB를 원자적으로 업데이트하고 메시지를 발행하는 일입니다. 트랜잭셔널 아웃박스 패턴에 따라 일단 메시지를 DB 트랜잭션의 일부로 DB에 쓰는 것이 좋은 방법입니다. 그러고 나서 별도 프로세스가 폴링 발행기 패턴 또는 트랜잭션 로그 테일링 패턴으로 DB에서 메시지 조회 후 메시지 브로커에 발행하면 됩니다.