마이크로 서비스 아키텍처 :
내 , 마이크로 서비스 아키텍처에 대한 기본적인 이해가 있어야합니다.하지만, 기본적인 것 이상이 필요합니다. 이 블로그에서는 아키텍처 개념의 깊이를 살펴보고 UBER 사례 연구를 사용하여 구현합니다.
이 블로그에서는 다음에 대해 학습합니다.
- 마이크로 서비스 아키텍처의 정의
- 마이크로 서비스 아키텍처의 주요 개념
- 마이크로 서비스 아키텍처의 장단점
- UBER – 사례 연구
당신은 참조 할 수 있습니다 , 마이크로 서비스의 기본 사항과 이점을 이해합니다.
마이크로 서비스에 대한 정의를 제공하는 경우에만 공정 할 것입니다.
마이크로 서비스의 정의
따라서 마이크로 서비스 (마이크로 서비스 아키텍처)에 대한 적절한 정의는 없지만, 서로 다른 작업을 수행하는 개별적으로 배포 가능한 소규모 서비스로 구성된 프레임 워크라고 말할 수 있습니다.
마이크로 서비스는 완전히 독립적 인 배포 가능한 서비스로 구현할 수있는 단일 비즈니스 도메인에 초점을 맞추고이를 다른 기술 스택에 구현합니다.
그림 1 : 모 놀리 식 아키텍처와 마이크로 서비스 아키텍처의 차이점 – 마이크로 서비스 아키텍처
모 놀리 식 아키텍처와 마이크로 서비스 아키텍처의 차이점을 이해하려면 위의 다이어그램을 참조하세요.두 아키텍처의 차이점을 더 잘 이해하려면 이전 블로그를 참조하십시오.
이해를 돕기 위해 마이크로 서비스 아키텍처의 몇 가지 핵심 개념을 알려 드리겠습니다.
마이크로 서비스 아키텍처의 주요 개념
마이크로 서비스를 사용하여 자체 애플리케이션을 빌드하기 전에 애플리케이션의 범위와 기능을 명확히해야합니다.
다음은 마이크로 서비스를 논의하는 동안 따라야 할 몇 가지 지침입니다.
마이크로 서비스 설계시 지침
- 개발자는 응용 프로그램을 구축하기로 결정할 때 도메인을 분리하고 기능을 명확히해야합니다.
- 설계하는 각 마이크로 서비스는 애플리케이션의 한 서비스에만 집중해야합니다.
- 각 서비스를 개별적으로 배포 할 수있는 방식으로 애플리케이션을 설계했는지 확인하십시오.
- 마이크로 서비스 간의 통신이 상태 비 저장 서버를 통해 수행되는지 확인합니다.
- 각 서비스는 자체 마이크로 서비스가있는 더 작은 서비스로 리팩토링 될 수 있습니다.
이제 마이크로 서비스를 설계하는 동안 기본 지침을 읽었으므로 마이크로 서비스의 아키텍처를 이해해 보겠습니다.
마이크로 서비스 아키텍처는 어떻게 작동합니까?
일반적인 마이크로 서비스 아키텍처 (MSA)는 다음 구성 요소로 구성되어야합니다.
- 클라이언트
- 아이덴티티 공급자
- 게이트웨이 API
- 메시징 형식
- 데이터베이스
- 정적 콘텐츠
- 조치
- 서비스 발견
아래 다이어그램을 참조하십시오.
그림 2 : 마이크로 서비스 아키텍처 – 마이크로 서비스 아키텍처
아키텍처가 약간 복잡해 보이지만나는당신을 위해 그것을 단순화하십시오.
1. 클라이언트
석사 학위 대학원입니다
아키텍처는 검색, 빌드, 구성 등과 같은 다양한 관리 기능을 수행하려는 다양한 장치에서 다양한 유형의 클라이언트로 시작됩니다.
2. 신원 제공자
그런 다음 클라이언트의 이러한 요청은 클라이언트의 요청을 인증하고 API Gateway에 요청을 전달하는 자격 증명 공급자로 전달됩니다. 그런 다음 요청은 잘 정의 된 API 게이트웨이를 통해 내부 서비스로 전달됩니다.
3. API 게이트웨이
클라이언트가 서비스를 직접 호출하지 않기 때문에 API Gateway는 클라이언트가 요청을 적절한 마이크로 서비스로 전달하는 진입 점 역할을합니다.
API 게이트웨이 사용의 장점은 다음과 같습니다.
- 모든 서비스는 클라이언트 모르게 업데이트 될 수 있습니다.
- 서비스는 웹 친화적이지 않은 메시징 프로토콜을 사용할 수도 있습니다.
- API Gateway는 보안 제공,로드 밸런싱 등과 같은 교차 절단 기능을 수행 할 수 있습니다.
클라이언트의 요청을받은 후 내부 아키텍처는 클라이언트 요청을 처리하기 위해 메시지를 통해 서로 통신하는 마이크로 서비스로 구성됩니다.
4. 메시징 형식
통신하는 메시지에는 두 가지 유형이 있습니다.
- 동기 메시지 : 클라이언트가 서비스의 응답을 기다리는 상황에서 마이크로 서비스는 일반적으로 REST (Representational State Transfer) 상태 비 저장 클라이언트 서버에 의존하기 때문에 HTTP 프로토콜 . 이 프로토콜은 분산 환경으로 사용되며 모든 기능은 작업을 수행하기위한 리소스로 표현됩니다.
- 비동기 메시지 : 클라이언트가 서비스의 응답을 기다리지 않는 상황에서 마이크로 서비스는 일반적으로 다음과 같은 프로토콜을 사용하는 경향이 있습니다. AMQP, STOMP, MQTT . 이러한 프로토콜은 메시지의 특성이 정의되고 이러한 메시지가 구현간에 상호 운용 가능해야하기 때문에 이러한 유형의 통신에 사용됩니다.
다음으로 떠오르는 질문은 마이크로 서비스를 사용하는 애플리케이션이 데이터를 어떻게 처리합니까?
5. 데이터 처리
음, 각 마이크로 서비스는 데이터를 캡처하고 각 비즈니스 기능을 구현하기 위해 개인 데이터베이스를 소유하고 있으며, 마이크로 서비스의 데이터베이스는 서비스 API를 통해서만 업데이트됩니다. 아래 다이어그램을 참조하십시오.
그림 3 : 데이터를 처리하는 마이크로 서비스의 표현 – 마이크로 서비스 아키텍처
마이크로 서비스에서 제공하는 서비스는 다양한 기술 스택에 대한 프로세스 간 통신을 지원하는 모든 원격 서비스로 전달됩니다.
6. 정적 콘텐츠
마이크로 서비스가 자체적으로 통신 한 후에는 다음을 통해 클라이언트에 직접 전달할 수있는 클라우드 기반 저장소 서비스에 정적 콘텐츠를 배포합니다. 콘텐츠 전송 네트워크 (CDN) .
위의 구성 요소 외에도 일반적인 마이크로 서비스 아키텍처에는 몇 가지 다른 구성 요소가 있습니다.
7. 관리
이 구성 요소는 노드의 서비스 균형을 조정하고 오류를 식별합니다.
8. 서비스 발견
노드가 위치한 서비스 목록을 유지 관리하므로 마이크로 서비스 간 통신 경로를 찾는 가이드 역할을합니다.
새로운 업데이트를 받으려면 YouTube 채널을 구독하십시오 ..!
이제이 아키텍처를 사용하는시기를 더 잘 이해하기 위해이 아키텍처의 장단점을 살펴 보겠습니다.
참조에 의한 C ++ 호출
마이크로 서비스 아키텍처의 장단점
아래 표를 참조하십시오.
| 마이크로 서비스 아키텍처의 장점 | 마이크로 서비스의 단점 건축물 |
| 다양한 기술을 사용할 수있는 자유 | 문제 해결 문제 증가 |
| 각 마이크로 서비스는 단일 비즈니스 기능에 중점을 둡니다. | 원격 호출로 인한 지연 증가 |
| 개별 배치 가능 유닛 지원 | 구성 및 기타 작업에 대한 노력 증가 |
| 잦은 소프트웨어 릴리스 허용 | 거래 안전을 유지하기 어려움 |
| 각 서비스의 보안 보장 | 다양한 서비스 경계에서 데이터를 추적하기 어렵습니다. |
| 여러 서비스가 병렬로 개발 및 배포됩니다. | 서비스간에 코드를 이동하기 어려움 |
UBER의 이전 아키텍처와 현재 아키텍처를 비교하여 마이크로 서비스에 대해 더 많이 이해하겠습니다.
UBER 사례 연구
UBER의 이전 아키텍처
많은 신생 기업과 마찬가지로 UBER은 단일 도시에서 단일 서비스를 위해 구축 된 모 놀리 식 아키텍처로 여정을 시작했습니다. 그 당시에는 하나의 코드베이스가 정리 된 것처럼 보였고 UBER의 핵심 비즈니스 문제를 해결했습니다. 그러나 UBER이 전 세계적으로 확장되기 시작하면서 확장 성 및 지속적인 통합과 관련하여 다양한 문제에 직면했습니다.
그림 4 : UBER의 모 놀리 식 아키텍처 – 마이크로 서비스 아키텍처
위의 다이어그램은 UBER의 이전 아키텍처를 보여줍니다.
- 승객과 운전자가 연결하는 REST API가 있습니다.
- 세 가지 어댑터가 API와 함께 사용되어 청구, 결제, 택시 예약시 표시되는 이메일 / 메시지 전송과 같은 작업을 수행합니다.
- 모든 데이터를 저장하는 MySQL 데이터베이스.
따라서 여기에서 승객 관리, 청구, 알림 기능, 결제, 여행 관리 및 운전자 관리와 같은 모든 기능이 단일 프레임 워크 내에서 구성되었음을 알 수 있습니다.
문제 설명
UBER이 전 세계적으로 확장되기 시작하는 동안 이러한 종류의 프레임 워크는 다양한 문제를 야기했습니다. 다음은 몇 가지 주요 과제입니다.
- 단일 기능을 업데이트하려면 모든 기능을 재 구축, 배포 및 테스트해야했습니다.
- 개발자가 코드를 계속해서 변경해야했기 때문에 단일 저장소에서 버그를 수정하는 것이 매우 어려워졌습니다.
- 전 세계적으로 새로운 기능을 도입하는 동시에 기능을 확장하는 것은 함께 처리하기가 매우 어려웠습니다.
해결책
이러한 문제를 피하기 위해 UBER은 아키텍처를 변경하고 Amazon, Netflix, Twitter 및 기타 여러 회사와 같은 다른 고성장 기업을 따르기로 결정했습니다. 따라서 UBER은 모 놀리 식 아키텍처를 여러 코드베이스로 분리하여 마이크로 서비스 아키텍처를 형성하기로 결정했습니다.
UBER의 마이크로 서비스 아키텍처를 보려면 아래 다이어그램을 참조하세요.
그림 5 : UBER의 마이크로 서비스 아키텍처 – 마이크로 서비스 아키텍처
- 여기서 관찰되는 주요 변경 사항은 모든 운전자와 승객이 연결되는 API 게이트웨이의 도입입니다. API Gateway에서 승객 관리, 운전자 관리, 여행 관리 등 모든 내부 지점이 연결됩니다.
- 유닛은 별도의 기능을 수행하는 개별적으로 배치 가능한 유닛입니다.
- 예를 들어, 청구 마이크로 서비스의 내용을 변경하려는 경우 청구 마이크로 서비스 만 배포하면되고 다른 서비스는 배포 할 필요가 없습니다.
- 이제 모든 기능이 개별적으로 확장되었습니다. 즉, 각각의 기능과 모든 기능 간의 상호 의존성이 제거되었습니다.
- 예를 들어, 우리는 택시를 검색하는 사람들의 수가 실제로 택시를 예약하고 지불하는 사람들보다 상대적으로 더 많다는 것을 알고 있습니다. 이를 통해 승객 관리 마이크로 서비스에서 작업하는 프로세스 수가 결제 작업을 수행하는 프로세스 수보다 많다는 추론을 할 수 있습니다.
이것에방법, UBER는이것의모 놀리 식에서 마이크로 서비스까지의 아키텍처.
Microservice Architecture에 대한이 게시물을 즐겁게 읽으 셨기를 바랍니다.실습도 포함되는 더 많은 블로그를 만들 예정입니다.
마이크로 서비스에 대해 자세히 알아보고 싶으십니까?
마이크로 서비스를 배우고 자신의 애플리케이션을 구축하려면 다음을 확인하십시오. 강사 주도의 라이브 교육 및 실제 프로젝트 경험과 함께 제공됩니다. 이 교육은 마이크로 서비스를 심층적으로 이해하고 주제에 대한 숙달을 달성하는 데 도움이됩니다.
질문이 있으십니까? ”의 댓글 섹션에 언급하십시오. 마이크로 서비스 아키텍처 ”그러면 다시 연락 드리겠습니다.