진화를 위한 디자인

혁신적인 디자인은 지속적인 혁신의 핵심입니다.

성공적인 모든 애플리케이션은 시간에 따라 버그를 수정하거나, 새 기능을 추가하거나, 새 기술을 가져오거나, 기존 시스템의 확장성과 복원력을 개선하는 등, 지속적으로 발전합니다. 애플리케이션의 모든 부분이 밀접하게 연결되어 있으면 시스템을 변경하는 것이 매우 어려울 수 있습니다. 애플리케이션의 한 부분이 달라지면 다른 부분이 중단되거나, 이러한 변경이 전체 코드 베이스에 영향을 줄 수 있습니다.

이 문제는 모놀리식 애플리케이션으로만 제한되지 않습니다. 애플리케이션은 서비스로 분해될 수 있지만, 여전히 견고한 결합을 통해 시스템을 융통성 없는 불안정한 상태로 만듭니다. 하지만 개선될 수 있게 서비스를 디자인하면 팀은 혁신을 통해 새 기능을 계속 제공할 수 있습니다.

마이크로 서비스는 여기에 나열된 많은 고려 사항을 해결해주므로 혁신적 디자인을 달성하는 유용한 방법이 되고 있습니다.

권장 사항

높은 응집력 및 느슨한 결합 적용. 서비스는 논리적으로 함께 속하는 기능을 제공할 경우 응집력을 갖습니다. 다른 서비스를 변경하지 않으면서 서비스를 변경할 수 있는 경우 서비스가 느슨하게 결합된 것입니다. 높은 응집력은 일반적으로 한 함수의 변경에 관련된 모든 함수가 한 서비스에 있는 다른 관련 함수의 변경이 필요하다는 것을 의미합니다. @@한 서비스를 업데이트하기 위해 다른 서비스도 통합해서 업데이트해야 할 경우 서비스가 응집력을 갖는다는 것을 의미할 수 있습니다. DDD(도메인 기반 디자인)의 목표 중 하나는 경계를 구분하는 것입니다.

도메인 지식 캡슐화. 클라이언트가 서비스를 사용하는 경우 도메인의 비즈니스 규칙 적용에 대한 책임은 클라이언트에 있지 않습니다. 대신, 서비스가 책임이 있는 모든 도메인 지식을 캡슐화해야 합니다. 그렇지 않으면, 모든 클라이언트가 비즈니스 규칙을 적용해야 하며, 결과적으로 애플리케이션의 다른 부분으로 도메인 지식이 분산됩니다.

비동기 메시징 사용 비동기 메시징은 소비자로부터 메시지 생산자를 분리하는 방법입니다. 생산자는 메시지에 응답하거나 특정 작업을 수행하는 소비자에 종속되지 않습니다. pub/sub 아키텍처를 사용하면 생산자가 메시지를 사용하는 대상을 모를 수도 있습니다. 새 서비스는 생산자를 수정하지 않고 메시지를 쉽게 사용할 수 있습니다.

도메인 지식을 게이트웨이에 구축하지 않음. 요청 라우팅, 프로토콜 변환, 부하 분산, 인증 등의 경우 마이크로 서비스 아키텍처에서 게이트웨이가 유용할 수 있습니다. 그러나 게이트웨이는 이러한 종류의 인프라 기능으로 제한해야 합니다. 과도하게 종속되는 것을 방지하려면 도메인 지식은 구현하지 않아야 합니다.

개방형 인터페이스 노출. 서비스 사이에 사용자 지정 변환 레이어를 만들지 않도록 합니다. 대신, 서비스는 잘 정의된 API 계약이 있는 API를 노출해야 합니다. 이전 버전과의 호환성을 유지하면서 API를 확장할 수 있도록 API 버전을 관리해야 합니다. 이런 방식으로 의존하는 모든 업스트림 서비스에 대한 업데이트를 통합하지 않고도 서비스를 업데이트할 수 있습니다. 공용 서비스는 HTTP를 통해 RESTful API를 노출해야 합니다. 백 엔드 서비스는 성능상의 이유로 RPC 스타일 메시징 프로토콜을 사용할 수 있습니다.

서비스 계약을 고려한 디자인 및 테스트. 서비스가 잘 정의된 API를 노출하는 경우 이러한 API를 고려해서 개발을 수행하고 테스트를 진행할 수 있습니다. 이러한 방식으로, 해당하는 모든 종속 서비스를 포함하지 않고도 개별 서비스를 개발하고 테스트할 수 있습니다. (물론 여전히 실제 서비스를 고려해서 통합 및 부하 테스트를 수행할 수 있습니다.)

추상 인프라를 도메인 논리와 분리. 도메인 논리를 메시징 또는 지속성 같은 인프라 관련 기능과 혼합하지 않도록 합니다. 이러한 기능이 혼합되면 도메인 논리를 변경하려는 경우 인프라 계층을 업데이트해야 하고, 그 반대의 경우도 마찬가지가 됩니다.

교차 적용되는 문제를 별도 서비스에 오프로드. 예를 들어, 몇 가지 서비스가 요청을 인증해야 할 경우, 이 기능을 자체 서비스로 이동할 수 있습니다. 그런 다음, 인증 서비스를 사용하는 다른 서비스를 건드리지 않으면서 해당 인증 서비스를 개선할 수 있습니다(예: 새 인증 흐름 추가).

서비스를 독립적으로 배포. DevOps 팀이 애플리케이션의 다른 서비스와는 별개로 단일 서비스를 배포할 수 있는 경우 업데이트가 더 빠르고 안전하게 발생할 수 있습니다. 버그 픽스와 새로운 기능은 좀 더 규칙적으로 롤아웃될 수 있습니다. 독립적인 업데이트를 지원하도록 애플리케이션과 릴리스 프로세스를 디자인하도록 합니다.