서비스 아키텍처는 일련의 자율 서비스 문제를 해결하는 소프트웨어 설계 접근 방식입니다.

Analogy

서비스 아키텍처에 대한 합리적인 비유는 은행과 같은 조직입니다. 은행은 업무를 고객 서비스, IT 서비스 및 인사 관리 서비스와 같은 다양한 서비스로 나눕니다. 각 서비스는 독립적이며 서로 다른 사무실에 배포 할 수 있습니다. 각 서비스의 고객에게는 서비스에 대해 기대할 수있는 사항을 명시한 계약이 제공됩니다. 예를 들어 인적 자원 관리는 팀이 프로세스를 시작하기 위해 작성하는 양식을 사용하여 팀이 새 직원을 모집하는 데 도움이 될 수 있습니다. 회사의 서비스 구조는 은행 운영의 복잡한 문제를 작은 관리 기능 단위로 나눕니다.

서비스

서비스는 다음과 같은 소프트웨어 단위입니다. 기능을 수행합니다. 복잡한 문제를 일련의 간단한 문제로 나누는 데 사용됩니다. 서비스는 또한 별도로 배포 할 수 있도록 설계되었습니다. 이는 확장 성이 뛰어나고 복원력이 뛰어난 시스템을 구축 할 수 있다는 점에서 큰 장점입니다.

복원력

복원력은 다양한 스트레스 및 복원력을 포함하는 실제 조건에서 신뢰할 수있는 소프트웨어의 용어입니다. 실패. 서비스 아키텍처는 문제가 발생해도 계속 작동하는 시스템을 구축하는 데 유용한 기술입니다. 이는 서로 의존하지 않도록 서비스를 자율적으로 설계함으로써 수행됩니다. 그런 다음 서비스를 클라우드 인프라에 배포하고 필요에 따라 확장 및 축소 할 수 있습니다. 인스턴스가 실패하면 서비스가이를 감지하고 자동으로 감지 할 수있을만큼 스마트합니다. 작동중인 인스턴스를 찾습니다.

서비스 대 구성 요소

서비스와 구성 요소는 작업을 관리 및 재사용 가능한 청크로 분할하는 두 가지 방법입니다. 차이점은 서비스는 자체적으로 배포 될 수 있습니다. 구성 요소는 다른 것과 함께 배포되므로 자율적이지 않습니다. 서비스는 구성 요소로 구성 할 수 있습니다. 마찬가지로 구성 요소도 서비스를 사용할 수 있습니다.

SOA (Service Oriented Architecture)

서비스 지향 아키텍처는 서비스 아키텍처의 초기 용어로 채택 및 마케팅되었습니다. SOA 플랫폼과 미들웨어를 판매하는 데 사용했던 많은 대규모 IT 공급 업체. 이것은 2005 년경 대규모 정보 기술 유행으로, 소프트웨어를 구입 한 다음 SOA 패러다임에 맞게 기존 시스템을 재 설계하는 것과 관련된 많은 하향식 구현을 보았습니다. 이 활동의 대부분은 SOA의 요점을 완전히 놓쳤으며 프로젝트 실패가 일반적이었습니다. IT 전문가들이 SOA를 홍보하거나 비판하면서 혼란 스러웠습니다. 종종 가능한 한 복잡한 소리로 들리게 만들었습니다.

마이크로 서비스

모든 거대하고 넌센스 인기가 절정에 달했을 때 SOA를 둘러싼 것이 숙련 된 설계자가 핵심 아이디어를 효과적이고 가벼운 방식으로 사용하여 안정적이고 확장 가능하며 관리 가능하며 비용 효율적인 시스템과 애플리케이션을 생성하는 것을 막지는 못했습니다. 이는 서비스 설계를위한 일련의 원칙을 중심으로 구성된 마이크로 서비스로 알려진 새로운 소프트웨어 설계 문화로 발전했습니다.

예

한 통신 회사가 개별적으로 배포 가능한 일련의 서비스로 결제 시스템을 설계합니다. 각 서비스는 다른 사람이 개발, 유지 및 관리 할 수있는 별도의 제품으로 간주됩니다. 서비스는 클라우드에 배포되고 느슨하게 결합됩니다. 서비스 인스턴스가 실패하면 다른 서비스가 여전히 작동중인 인스턴스로 자동 전환됩니다. 통신 청구 문제는 매우 복잡하지만 아키텍처의 단일 서비스는 개발 및 관리 비용이 상대적으로 저렴할 정도로 복잡하지 않습니다. 서비스는 본질적으로 자체 구성됩니다. 각각은 다른 서비스에 API를 게시합니다. 각각은 다른 서비스에서 필요한 것을 알고 있으며 응답하는 서비스를 찾기 위해 실패한 인스턴스를 라우팅 할 수있을만큼 똑똑합니다. 즉, 아키텍처에는 중앙 컨트롤러 나 미들웨어가 없습니다.

개요 : 서비스 아키텍처
유형
정의	일련의 자율 서비스 문제를 해결하는 소프트웨어 설계 방식입니다.
관련 개념