마이크로 서비스 아키텍처-청사진

마이크로 서비스는 내부적으로 SOA를 구현합니다. 넓은 의미에서 하나의 SOA 응용 프로그램의 하위 집합으로 간주 할 수 있습니다.

규칙 및 워크 플로

다음은 마이크로 서비스를 개발하는 동안주의해야 할 원칙입니다.

• High Cohesion− 모든 비즈니스 모델은 가능한 한 가장 작은 비즈니스 부분으로 세분화되어야합니다. 각 서비스는 하나의 비즈니스 작업 만 수행하도록 집중되어야합니다.

• Independent − 모든 서비스는 본질적으로 풀 스택이어야하며 서로 독립적이어야합니다.

• Business Domain Centric − 소프트웨어는 비즈니스 단위에 따라 모듈화되며 계층 기반이 아닙니다.

• Automation− 테스트 배포가 자동화됩니다. 최소한의 인간 상호 작용을 도입하십시오.

• Observable − 각 서비스는 본질적으로 풀 스택이며 엔터프라이즈 애플리케이션처럼 독립적으로 배포하고 관찰 할 수 있어야합니다.

팀 관리

"Two Pizza Rule"은 마이크로 서비스 개발 팀의 참석자 수를 제한하는 일종의 규칙입니다. 이 규칙에 따르면 한 응용 프로그램의 팀 구성원 수는 피자 두 개를 먹일 수있을 정도로 작아야합니다. 일반적으로 숫자는 8을 넘지 않아야합니다. 마이크로 서비스는 본질적으로 풀 스택이므로 팀도 본질적으로 풀 스택입니다. 생산성을 높이려면 해당 서비스에 필요한 모든 종류의 전문 지식을 갖춘 최대 8 명으로 구성된 팀을 구성해야합니다.

작업 관리

태스크는 소프트웨어 개발 수명주기에서 중요한 역할입니다. 대규모 애플리케이션 개발은 여러 개의 작은 작업 단위로 나눌 수 있습니다. Facebook과 같은 하나의 애플리케이션을 개발해야한다고 생각해 보겠습니다. 그러면 "로그인"기능이 전체 빌드 프로세스의 작업으로 간주 될 수 있습니다. 이러한 각 작업의 진행 상황은 고도로 숙련 된 전문가가 적절하게 모니터링해야합니다. 애자일은 우수한 작업 관리를 따라 잡기 위해 업계에서 따르는 잘 알려진 프로세스 구조입니다.