이것은 지금까지 읽은 마이크로서비스 아키텍처에 대한 가장 자세한 기사일 것입니다.

이 기사에서는 마이크로서비스 아키텍처 및 관련 구성 요소를 소개하고, 마이크로서비스 아키텍처 및 이러한 구성 요소가 무엇인지, 왜 사용해야 하는지 소개합니다. 이 글에서는 마이크로서비스 아키텍처의 전체적인 그림을 간결하게 표현하는 데 중점을 두었기 때문에 컴포넌트 사용 방법 등의 세부 사항은 다루지 않겠습니다.

마이크로서비스를 이해하려면 먼저 마이크로서비스가 아닌 서비스를 이해해야 합니다. 일반적으로 마이크로서비스의 반대는 모든 기능을 독립적인 단위로 패키징하는 애플리케이션인 모놀리식 애플리케이션입니다. 모놀리식 애플리케이션에서 마이크로서비스까지, 이는 하루아침에 이루어지는 프로세스가 아니라 점진적인 진화 프로세스입니다. 이 기사에서는 이 프로세스를 설명하기 위해 온라인 슈퍼마켓 애플리케이션을 예로 들어 보겠습니다.

초기 수요

몇 년 전, Xiao Ming과 Xiao Pi는 온라인 슈퍼마켓으로 함께 사업을 시작했습니다. Xiao Ming은 프로그램 개발을 담당하고 Xiao Pi는 기타 문제를 담당합니다. 당시에는 아직 인터넷이 발달하지 않았고, 온라인 슈퍼마켓은 여전히 ​​블루오션이었습니다. 기능만 구현되면 마음대로 돈을 벌 수 있습니다. 따라서 이들의 요구 사항은 매우 간단합니다. 사용자가 제품을 검색하고 구매할 수 있는 공용 네트워크의 웹사이트만 있으면 됩니다. 또한 제품, 사용자 및 주문 데이터를 관리할 수 있는 관리 백엔드도 필요합니다.

기능 목록을 정리해보자:

• 웹사이트
• 사용자 등록 및 로그인 기능
• 제품 디스플레이
• 주문하기
• 관리 배경설명
• User Management
• Product Management
• Order Management

샤오밍은 단순한 요구사항으로 인해 왼손과 오른손을 슬로우모션으로 움직여 웹사이트를 준비하였습니다. 보안상의 이유로 관리 백엔드가 웹사이트와 같은 위치에 있지 않습니다. Xiao Ming의 오른손과 왼손이 슬로우 모션으로 재생되며 관리 웹사이트가 준비되었습니다. 전체 아키텍처 다이어그램은 다음과 같습니다.

Xiao Ming이 손을 흔들고 배포할 클라우드 서비스를 찾았고 웹사이트가 온라인 상태가 되었습니다. 온라인에 출시된 후 호평을 받으며 각종 팻하우스들의 사랑을 받았다. Xiao Ming과 Xiao Pi는 행복하게 누워서 돈을 모으기 시작했습니다.

사업이 발전하면서...

좋은 시절은 오래가지 못했습니다. 며칠 만에 다양한 온라인 슈퍼마켓이 생겨났고 이는 Xiao Ming Xiaopi에게 큰 영향을 미쳤습니다.

경쟁의 압박 속에서 Xiao Ming Xiaopi는 몇 가지 마케팅 방법을 수행하기로 결정했습니다.

• 홍보 활동을 수행합니다. 예를 들어, 설날 전 사이트 할인, 춘절 2+1 공짜, 발렌타인데이 애견밥 쿠폰 등이 있습니다.
• 채널을 확장하고 모바일 마케팅을 추가하세요. 웹사이트 외에도 모바일 APP, WeChat 애플릿 등의 개발도 필요합니다.
• 정밀 마케팅. 과거 데이터를 활용하여 사용자를 분석하고 개인화된 서비스를 제공합니다.
• ……

이러한 활동에는 프로그램 개발의 지원이 필요합니다. Xiao Ming은 동급생 Xiao Hong을 묶어 팀에 합류했습니다. Xiaohong은 데이터 분석 및 모바일 단말기 관련 개발을 담당하고 있습니다. Xiao Ming은 판촉 활동과 관련된 기능 개발을 담당하고 있습니다.

개발 작업이 상대적으로 시급했기 때문에 Xiao Ming과 Xiao Hong은 전체 시스템의 아키텍처를 신중하게 계획하지 않고 단지 머리를 쓰다듬고 프로모션 관리 및 데이터 분석을 관리 배경에 두고 WeChat과 모바일 APP를 사용하기로 결정했습니다. 별도로 지어졌습니다. 며칠 동안 밤새도록 작업한 후에는 기본적으로 새로운 기능과 새로운 응용 프로그램이 완성되었습니다. 이때의 아키텍처 다이어그램은 다음과 같습니다.

현 단계에서는 불합리한 점이 많습니다.

• 웹사이트와 모바일 애플리케이션에는 동일한 비즈니스 로직을 가진 중복 코드가 많이 있습니다.
• 데이터는 데이터베이스를 통해 공유되기도 하고, 인터페이스 호출을 통해 전송되기도 합니다. 인터페이스 호출 관계가 지저분합니다.
• 다른 애플리케이션에 인터페이스를 제공하기 위해 단일 애플리케이션은 애초에 해당 애플리케이션에 속하지 않는 많은 로직을 포함하여 점점 더 많이 변경됩니다. 애플리케이션 경계가 모호해지고 기능 속성이 혼란스러워집니다.
• 관리 백엔드는 처음에 낮은 수준의 보안으로 설계되었습니다. 데이터 분석 및 프로모션 관리 관련 기능을 추가한 후 성능 병목 현상이 나타나 다른 애플리케이션에 영향을 미쳤습니다.
• 데이터베이스 테이블 구조는 여러 애플리케이션에 종속되므로 재구성하거나 최적화할 수 없습니다.
• 모든 애플리케이션은 데이터베이스에서 작동하며 데이터베이스에 성능 병목 현상이 있습니다. 특히 데이터 분석이 실행되는 경우 데이터베이스 성능이 급격히 저하됩니다.
• 개발, 테스트, 배포 및 유지 관리가 점점 더 어려워지고 있습니다. 작은 기능만 변경되더라도 전체 애플리케이션을 함께 출시해야 합니다. 때로는 테스트되지 않은 일부 코드가 실수로 기자회견에 포함되거나, 기능을 수정한 후 또 다른 예상치 못한 오류가 발생하기도 합니다. 공개로 인해 발생할 수 있는 문제의 영향과 온라인 업무 중단의 영향을 줄이기 위해 모든 신청서는 오전 3~4시에 공개되어야 합니다. 출시 후, 애플리케이션이 정상적으로 실행되고 있는지 확인하기 위해서는 다음 날 당일 피크 사용자 시간대를 주시해야 하는데...
• 팀 내에서 밀고 당기는 현상이 발생하고 있습니다. . 일부 공용 기능을 어떤 애플리케이션을 기반으로 구축해야 하는지에 대한 긴 논쟁이 종종 있으며, 결국 그들은 단지 자신의 작업을 수행하거나 유지 관리하지 않고 임의의 장소에 배치합니다.

문제가 많지만 이번 단계의 결과는 부인할 수 없습니다. 비즈니스 변화에 따라 시스템이 빠르게 구축되었습니다. 하지만 긴급하고 무거운 작업은 사람들을 쉽게 부분적이고 단기적인 사고에 빠지게 하고 타협적인 결정을 내리게 할 수 있습니다. 이런 종류의 구조에서는 모든 사람이 자신의 작은 땅에만 집중하고 전체적이고 장기적인 설계가 부족합니다. 이대로 가면 시스템 구축은 점점 어려워지고, 심지어는 끊임없는 전복과 재구축의 악순환에 빠질 수도 있다.

변화할 시간입니다

다행히 샤오밍과 샤오홍은 추구하는 바와 이상을 지닌 좋은 젊은이들입니다. 문제를 깨달은 후 Xiao Ming과 Xiao Hong은 사소한 비즈니스 요구에서 약간의 에너지를 해방하고 전체 구조를 정리하기 시작했으며 문제를 변화시킬 준비를 했습니다.

변화를 이루려면 먼저 충분한 에너지와 자원이 필요합니다. 수요 측면(비즈니스 직원, 프로젝트 관리자, 상사 등)이 수요 진행을 추구하는 데 너무 강해서 추가 에너지와 자원을 할당할 수 없다면 아무것도 할 수 없을 수도 있습니다...

프로그래밍의 세계에서 가장 중요한 것은 추상화 능력입니다. 마이크로서비스 변환 프로세스는 실제로 추상적인 프로세스입니다. Xiao Ming과 Xiao Hong은 온라인 슈퍼마켓의 비즈니스 로직을 정리하고 일반적인 비즈니스 기능을 추상화했으며 여러 공공 서비스를 만들었습니다.

• User Service
• Commodity Service
• Promotion Service
• Order Service
• 데이터 분석 서비스

각 애플리케이션 백엔드는 이러한 서비스에서 필요한 데이터만 가져오면 되므로 대량의 중복 코드가 삭제되고 얇은 제어 계층과 프런트 엔드만 남습니다. 이 단계의 아키텍처는 다음과 같습니다.

이 단계에서는 서비스만 분리하고 데이터베이스는 여전히 공유하므로 굴뚝 시스템의 일부 단점이 여전히 존재합니다.

1. 데이터베이스가 성능 병목 현상을 일으키게 됩니다. 단일 지점 실패 위험이 있습니다.
2. 데이터 관리가 혼란스러운 경향이 있습니다. 처음에는 좋은 모듈식 설계가 있었다고 해도 시간이 지나면서 항상 한 서비스가 다른 서비스의 데이터를 데이터베이스에서 직접 가져오는 현상이 나타나게 됩니다.
3. 데이터베이스 테이블 구조는 여러 서비스에 의존할 수 있으며, 이는 전체 시스템에 영향을 미치고 조정하기 어렵습니다.

공유 데이터베이스 모델을 유지하면 전체 아키텍처가 점점 더 경직되고 마이크로서비스 아키텍처의 의미를 잃게 됩니다. 따라서 Xiao Ming과 Xiao Hong은 함께 작업하여 데이터베이스를 분할했습니다. 모든 지속성 계층은 서로 격리되어 있으며 각 서비스의 책임입니다. 또한 시스템의 실시간 성능을 향상시키기 위해 메시지 큐 메커니즘이 추가되었습니다. 아키텍처는 다음과 같습니다.

완전한 분할 후 각 서비스는 이종 기술을 사용할 수 있습니다. 예를 들어, 데이터 분석 서비스는 데이터 웨어하우스를 지속성 계층으로 사용하여 일부 통계 계산을 효율적으로 수행할 수 있습니다. 상품 서비스 및 판촉 서비스에 더 자주 액세스하므로 캐싱 메커니즘이 추가됩니다.

공개 논리를 추상화하는 또 다른 방법은 이러한 공개 논리를 공개 프레임워크 라이브러리로 만드는 것입니다. 이 방법을 사용하면 서비스 호출의 성능 손실을 줄일 수 있습니다. 그러나 이 방법은 관리 비용이 매우 높으며 모든 애플리케이션 버전의 일관성을 보장하기 어렵습니다.

데이터베이스 분할에는 데이터베이스 간 캐스케이딩의 필요성, 서비스를 통한 데이터 쿼리의 세분성 등 몇 가지 문제와 과제도 있습니다. 그러나 이러한 문제는 합리적인 설계를 통해 해결될 수 있습니다. 전반적으로 데이터베이스 분할에는 단점보다 장점이 더 많습니다.

마이크로서비스 아키텍처는 비기술적인 이점도 있습니다. 이는 전체 시스템의 업무 분담을 더욱 명확하게 하고 모든 사람이 다른 사람에게 더 나은 서비스를 제공하는 데 전념합니다. 모놀리식 애플리케이션 시대에는 공공 비즈니스 기능이 명확한 소유권을 갖고 있지 않은 경우가 많습니다. 결국 모든 사람이 자신의 작업을 수행하고 이를 다시 구현하거나 임의의 사람(보통 더 유능하거나 열정적인 사람)이 자신이 담당하는 애플리케이션을 구현합니다. 후자의 경우, 이 사람은 자신의 응용 프로그램에 대한 책임 외에도 이러한 공개 기능을 다른 사람에게 제공할 책임도 있습니다. 이 기능은 설명할 수 없을 정도로 더 유능하고 열정적이기 때문에 원래 누구에게도 책임이 없습니다. 비난(이 상황은 완곡하게 말하면 더 많은 일을 할 수 있는 사람들이라고도 합니다). 결국 아무도 공공 기능을 제공하려고 하지 않았습니다. 시간이 지남에 따라 팀 구성원은 점차 독립적이게 되었고 더 이상 전체 아키텍처 설계에 신경 쓰지 않게 되었습니다. Java Journey 공식 계정을 팔로우하여 전자책을 받아보세요.

이러한 관점에서 마이크로서비스 아키텍처를 사용하려면 조직 구조에 대한 상응하는 조정도 필요합니다. 따라서 마이크로서비스 혁신에는 관리자의 지원이 필요합니다.

변신이 완료된 후 샤오밍과 샤오홍은 각자의 역할을 명확하게 나눴습니다. 두 사람은 매우 만족했고, 모든 것이 맥스웰의 방정식처럼 아름답고 완벽했습니다.

하지만...

만약의 묘약은 없습니다

봄이 왔습니다. 모든 것이 다시 살아나고, 다시 연례 쇼핑 카니발이 열립니다. 매일 주문량이 꾸준히 증가하는 것을 보고 Xiaopi, Xiaoming, Xiaohong은 행복한 미소를 지었습니다. 불행하게도 좋은 시절은 오래가지 못했습니다. 극심한 기쁨은 갑자기 슬픔을 가져왔습니다.

과거에는 단일 애플리케이션의 경우 일반적으로 문제 해결에 로그 보기, 오류 메시지 연구 및 호출 스택이 포함되었습니다. 마이크로서비스 아키텍처에서는 전체 애플리케이션이 여러 서비스로 분산되어 오류 지점을 찾는 것이 매우 어렵습니다. Xiao Ming은 로그를 하나씩 확인하고 수동으로 각 서비스를 하나씩 호출했습니다. 10분 이상의 검색 끝에 Xiao Ming은 마침내 결함 지점을 찾아냈습니다. 프로모션 서비스가 접수된 요청 수가 많아 응답을 멈췄습니다. 다른 서비스도 프로모션 서비스를 직간접적으로 호출하기 때문에 역시 다운됩니다. 마이크로서비스 아키텍처에서는 서비스 오류로 인해 눈사태 효과가 발생하여 전체 시스템이 실패할 수 있습니다. 실제로 휴가 전에 Xiao Ming과 Xiao Hong은 요청량 평가를 실시했습니다. 예상대로 휴일 요청량을 감당할 만큼 서버 리소스가 충분하니 뭔가 문제가 있는 게 틀림없습니다. 그러나 상황은 급박했고 매 순간이 돈 낭비였기 때문에 Xiao Ming은 문제를 해결할 시간이 없었습니다. 그는 즉시 클라우드에 여러 개의 새로운 가상 머신을 생성하기로 결정한 다음 새로운 프로모션을 배포했습니다. 서비스를 하나씩 제공합니다. 몇 분 동안 작동한 후 마침내 시스템이 정상으로 돌아왔습니다. 전체 정전 기간 동안 수십만 건의 매출 손실이 있었던 것으로 추정되며, 세 사람의 심장은 피를 흘리고 있었다...

이후 Xiao Ming은 간단히 로그 분석 도구를 작성하고(볼륨이 너무 커서 텍스트 편집기로 여는 것이 거의 불가능하고 육안으로 볼 수 없음) 프로모션 서비스의 액세스 로그를 세고 오류가 발생하는 동안 제품 서비스에 코드 문제가 있는 것으로 확인되었습니다. 일부 시나리오에서는 프로모션 서비스에 대한 요청이 많이 발생합니다. 이 문제는 복잡하지 않습니다. Xiao Ming은 손가락 하나만으로 수십만 달러의 가치가 있는 이 버그를 수정했습니다.

문제는 해결되었지만 비슷한 문제가 다시 발생하지 않을 것이라고 누구도 보장할 수 없습니다. 마이크로서비스 아키텍처는 논리적 설계가 완벽해 보이지만 블록으로 지어진 화려한 궁전과 같아서 바람과 파도를 견딜 수 없습니다. 마이크로서비스 아키텍처는 오래된 문제를 해결하지만 새로운 문제도 발생시킵니다.

• 마이크로서비스 아키텍처의 전체 애플리케이션은 여러 서비스에 분산되어 있으며 오류 지점을 찾는 것이 매우 어렵습니다.
• 안정성이 감소했습니다. 서비스 수가 많아지면 하나의 서비스가 실패할 확률도 높아지고, 서비스가 실패하면 전체 시스템이 중단될 수도 있다. 실제로 액세스 볼륨이 큰 프로덕션 시나리오에서는 항상 오류가 발생합니다.
• 서비스의 수가 매우 많고 배포 및 관리 작업량이 엄청납니다.
• 개발: 지속적인 개발 속에서 다양한 서비스가 여전히 시너지 효과를 유지할 수 있도록 하는 방법입니다.
• 테스트: 서비스가 분할된 후에는 거의 모든 기능에 여러 서비스가 포함됩니다. 단일 프로그램의 원래 테스트는 서비스 간 호출 테스트가 됩니다. 테스트가 더욱 복잡해집니다.

Xiao Ming과 Xiao Hong은 경험을 통해 교훈을 얻었고 이러한 문제를 해결하기로 결심했습니다. 문제 해결에는 일반적으로 두 가지 측면이 포함됩니다. 한편으로는 결함 가능성을 줄이려고 노력하고 다른 한편으로는 결함의 영향을 줄입니다.

모니터링 - 오류 징후 발견

고동시성 분산 시나리오에서는 오류가 눈사태처럼 갑자기 발생하는 경우가 많습니다. 따라서 장애 징후를 최대한 감지할 ​​수 있도록 완벽한 모니터링 시스템을 구축해야 합니다.

마이크로서비스 아키텍처에는 많은 구성 요소가 있으며 각 구성 요소는 서로 다른 지표를 모니터링해야 합니다. 예를 들어 Redis 캐시는 일반적으로 메모리 점유 값과 네트워크 트래픽을 모니터링하고, 데이터베이스는 연결 수와 디스크 공간을 모니터링하며, 비즈니스 서비스는 동시성 수, 응답 지연, 오류율 등을 모니터링합니다. 따라서 각 구성 요소를 모니터링하기 위해 대규모의 포괄적인 모니터링 시스템을 구축하는 것은 비현실적이며 확장성이 매우 낮습니다. 일반적인 접근 방식은 각 구성 요소가 현재 상태를 보고하기 위한 인터페이스(메트릭 인터페이스)를 제공하도록 하는 것입니다. 이 인터페이스의 데이터 형식 출력은 일관되어야 합니다. 그런 다음 표시기 수집기 구성 요소를 배포하여 쿼리 서비스를 제공하는 동시에 이러한 인터페이스에서 정기적으로 구성 요소 상태를 얻고 유지 관리합니다. 마지막으로 지표 수집기에서 다양한 지표를 쿼리하거나, 모니터링 인터페이스를 그리거나, 임계값에 따라 경보를 발행하려면 UI가 필요합니다.

대부분의 구성 요소는 직접 개발할 필요가 없으며 인터넷에 오픈 소스 구성 요소가 있습니다. Xiao Ming은 RedisExporter와 MySQLExporter를 다운로드했습니다. 이 두 구성 요소는 각각 Redis 캐시와 MySQL 데이터베이스에 대한 표시기 인터페이스를 제공합니다. 마이크로서비스는 각 서비스의 비즈니스 로직을 기반으로 맞춤형 지표 인터페이스를 구현합니다. 그런 다음 Xiao Ming은 Prometheus를 지표 수집기로 사용하고 Grafana는 모니터링 인터페이스와 이메일 알림을 구성합니다. 이러한 마이크로서비스 모니터링 시스템은 다음과 같이 구축됩니다.

위치 문제 - 링크 추적

마이크로서비스 아키텍처에서 사용자의 요청에는 종종 여러 내부 서비스 호출이 포함됩니다. 문제 파악을 용이하게 하기 위해서는 각 사용자가 요청할 때 마이크로서비스 내에서 얼마나 많은 서비스 호출이 발생하는지와 호출 관계를 기록할 수 있어야 합니다. 이를 링크 추적이라고 합니다.

Istio 문서의 링크 추적 예제를 사용하여 효과를 살펴보겠습니다.

사진은 Istio 문서에서 가져온 것입니다.

사진에서 볼 수 있듯이 이는 제품 페이지 페이지. 요청 과정에서 상품페이지 서비스는 상세정보 및 리뷰 서비스의 인터페이스를 순차적으로 호출합니다. 리뷰 서비스는 응답 프로세스 중에 평점 인터페이스를 호출합니다. 전체 링크 추적 기록은 트리입니다.

링크 추적을 구현하기 위해 각 서비스 호출은 HTTP 헤더에 최소한 4개의 데이터를 기록합니다.

• traceId: TraceId는 사용자를 식별합니다. 요청된 호출 링크. 동일한 TraceId를 가진 호출은 동일한 링크에 속합니다.
• spanId: 서비스 호출을 식별하는 ID, 즉 링크 추적의 노드 ID입니다.
• parentId: 상위 노드의 범위 ID입니다.
• requestTime & responseTime: 요청 시간과 응답 시간.

이 밖에도 로그 수집 및 저장을 위한 컴포넌트와 링크 호출을 표시하기 위한 UI 컴포넌트도 호출해야 합니다.

위 내용은 최소한의 설명일 뿐입니다. 링크 추적에 대한 이론적 근거는 Google의 Dapper에서 찾을 수 있습니다.

이론적 근거를 이해한 후 Xiao Ming은 Dapper의 오픈 소스 구현인 Zipkin을 선택했습니다. 그런 다음 그의 손가락을 움직여 HTTP 요청 인터셉터를 작성하고 이러한 데이터를 생성하여 각 HTTP 요청에 대해 HEADERS에 삽입했으며 동시에 호출 로그를 Zipkin의 로그 수집기에 비동기적으로 보냈습니다. 여기서 추가적으로 언급되는 점은 HTTP 요청 인터셉터가 마이크로서비스의 코드에서 구현되거나 네트워크 프록시 구성 요소를 사용하여 구현될 수 있다는 것입니다(그러나 이 경우 각 마이크로서비스는 프록시 계층을 추가해야 합니다).

링크 추적은 문제가 있는 서비스만 찾을 수 있으며 구체적인 오류 정보는 제공할 수 없습니다. 특정 오류 정보를 찾는 기능은 로그 분석 구성 요소에서 제공되어야 합니다.

분석 문제 - 로그 분석

로그 분석 구성 요소는 마이크로서비스가 등장하기 전에 널리 사용되었어야 합니다. 단일 애플리케이션 아키텍처라도 접속 횟수가 늘어나거나 서버 규모가 커지면 로그 파일의 크기가 텍스트 편집기로 접근하기 어려울 정도로 늘어나게 된다. 여러 서버에 분산되어 있습니다. 문제를 해결하려면 각 서버에 로그인하여 로그 파일을 얻어야 하고, 원하는 로그 정보를 하나씩 검색해야 합니다(그리고 열기와 검색이 매우 느립니다).

따라서 애플리케이션 규모가 커지면 "Search Engine" 로그가 필요합니다. 원하는 로그를 정확하게 찾을 수 있도록 말이죠. 또한 데이터 소스 측에도 로그를 수집하는 구성 요소와 결과를 표시하는 UI 구성 요소가 필요합니다.

Xiao Ming은 유명한 ELK 로그 분석 구성 요소를 조사하고 사용했습니다. ELK는 Elasticsearch, Logstash 및 Kibana라는 세 가지 구성 요소의 약어입니다.

• Elasticsearch: 검색 엔진 및 로그 저장.
• Logstash: 로그 입력을 받은 로그 수집기는 로그에 대해 일부 전처리를 수행한 후 이를 Elasticsearch로 출력합니다.
• Kibana: UI 구성 요소, Elasticsearch API를 통해 데이터를 찾아 사용자에게 표시합니다.

마지막 질문은 Logstash에 로그를 보내는 방법입니다. 한 가지 해결책은 로그 출력 시 Logstash 인터페이스를 직접 호출하여 로그를 보내는 것입니다. 이런 식으로 코드를 다시 수정해야 합니다(야, 왜 "and"를 사용하는가?)... 그래서 Xiao Ming은 다른 솔루션을 선택했습니다. 로그는 여전히 파일로 출력되고 에이전트는 각 서비스에 배포되어 로그를 스캔합니다. 파일을 저장한 다음 Logstash로 출력합니다.

광고 중단: 공개 계정을 팔로우하세요: Java 학습 가이드를 통해 더 많은 기술 기사를 받아보세요.

Gateway - 권한 제어, 서비스 거버넌스

마이크로서비스로 분할된 후 수많은 서비스와 인터페이스가 등장하여 통화 관계 전체가 지저분해졌습니다. 개발 과정에서 글을 쓰고 쓰다가 특정 데이터에 대해 어떤 서비스를 호출해야 하는지 갑자기 기억이 나지 않는 경우가 많습니다. 아니면 삐뚤게 작성해서 호출하면 안되는 서비스를 호출하다가 읽기 전용 함수로 인해 데이터가 수정되는 일이...

이러한 상황에 대처하기 위해서는 마이크로서비스 호출에 체커가 필요합니다. 즉, , 게이트웨이. 호출자와 수신자 사이에 게이트웨이 계층을 추가하고 호출될 때마다 권한 확인을 수행합니다. 또한 게이트웨이는 서비스 인터페이스 문서를 제공하는 플랫폼으로도 사용될 수 있습니다.

게이트웨이를 사용할 때의 한 가지 문제는 게이트웨이를 얼마나 세분화하여 사용해야 하는지 결정하는 것입니다. 가장 대략적인 솔루션은 전체 마이크로 서비스에 대한 게이트웨이이고 마이크로 서비스 내부는 게이트웨이를 통해 마이크로 서비스에 액세스합니다. 가장 세밀한 부분은 마이크로서비스 내부이든 외부이든 모든 호출이 게이트웨이를 통과해야 한다는 것입니다. 절충안은 마이크로서비스를 사업 영역에 따라 여러 영역으로 나누어 해당 영역 내에서 직접 호출하고, 게이트웨이를 통해 호출하는 것이다.

전체 온라인 슈퍼마켓의 서비스 수가 특별히 많지 않기 때문에 Xiao Ming은 가장 대략적인 솔루션을 채택했습니다.

서비스 등록 및 검색 - 동적 확장

이전 구성 요소는 모두 다음과 같이 설계되었습니다. 실패 가능성을 줄입니다. 그러나 실패는 항상 발생하기 때문에 연구해야 할 또 다른 측면은 실패의 영향을 줄이는 방법입니다.

가장 조잡하고 가장 일반적으로 사용되는 오류 처리 전략은 중복입니다. 일반적으로 서비스는 부담을 공유하고 성능을 향상할 수 있도록 여러 인스턴스를 배포하며, 둘째, 한 인스턴스가 실패하더라도 다른 인스턴스가 계속 응답할 수 있습니다.

중복성의 한 가지 문제는 얼마나 많은 중복성이 사용됩니까? 타임라인에는 이 질문에 대한 명확한 답이 없습니다. 서비스 기능 및 기간에 따라 필요한 인스턴스 수가 다릅니다. 예를 들어 평일에는 4개의 인스턴스로 충분할 수 있지만, 프로모션 기간에는 트래픽이 크게 증가할 때 40개의 인스턴스가 필요할 수 있습니다. 따라서 중복 정도는 고정된 값이 아니며 필요에 따라 실시간으로 조정될 수 있습니다. 일반적으로 새 인스턴스를 추가하는 작업은 다음과 같습니다.

새 인스턴스 배포
새 인스턴스를 로드 밸런싱 또는 DNS에 등록
작업은 두 단계만 수행하면 됩니다. 로드밸런싱이나 DNS에 등록하세요. 작업이 수동이라면 일이 간단하지 않을 것입니다. 인스턴스 40개를 추가하고 IP 40개를 수동으로 입력해야 하는 기분을 생각해보세요...

이 문제의 해결책은 자동 서비스 등록 및 검색입니다. 먼저 등록된 모든 서비스에 대한 주소 정보를 제공하는 서비스 검색 서비스를 배포해야 합니다. DNS는 서비스 검색 서비스로도 간주될 수 있습니다. 그런 다음 각 응용 프로그램 서비스는 시작될 때 서비스 검색 서비스에 자동으로 등록됩니다. 그리고 응용 서비스가 시작된 후 각 응용 서비스의 주소 목록이 서비스 검색 서비스에서 로컬로 실시간(정기적으로) 동기화됩니다. 또한 서비스 검색 서비스는 애플리케이션 서비스의 상태를 정기적으로 확인하고 비정상 인스턴스 주소를 제거합니다. 이렇게 하면 인스턴스를 추가할 때 새 인스턴스만 배포하면 됩니다. 인스턴스가 오프라인 상태가 되면 서비스를 직접 종료할 수 있습니다. 서비스 검색에서는 서비스 인스턴스의 증가 또는 감소를 자동으로 확인합니다.

서비스 검색은 클라이언트 로드 밸런싱과 함께 사용됩니다. 애플리케이션 서비스는 서비스 주소 목록을 로컬로 동기화했기 때문에 마이크로서비스에 액세스할 때 로드 전략을 직접 결정할 수 있습니다. 서비스를 등록할 때 일부 메타데이터(서비스 버전 및 기타 정보)를 추가할 수도 있으며, 클라이언트 로드는 이러한 메타데이터를 기반으로 트래픽 제어를 수행하여 A/B 테스트 및 블루-그린 게시와 같은 기능을 구현합니다.

Zookeeper, Eureka, Consul, Etcd 등과 같이 서비스 검색을 위해 선택할 수 있는 많은 구성 요소가 있습니다. 그런데 샤오밍은 자신이 꽤 괜찮다고 생각하고 자신의 실력을 뽐내고 싶어서 Redis를 기반으로 글을 썼는데...

회로, 서비스 저하, 전류 제한

회로

서비스가 다양한 이유로 응답을 중지하면 호출자는 일반적으로 일정 시간 동안 기다렸다가 시간 초과되거나 오류 반환을 받습니다. 호출 링크가 상대적으로 길면 요청이 누적될 수 있으며 전체 링크는 많은 리소스를 차지하고 다운스트림 응답을 기다립니다. 따라서 서비스에 여러 번 액세스하는 데 실패하는 경우 회로 차단기가 끊어져 서비스가 작동이 중지된 것으로 표시하고 직접 오류를 반환해야 합니다. 연결을 다시 설정하기 전에 서비스가 정상으로 돌아올 때까지 기다리십시오. ㅋㅋㅋ 중단되지 않습니다. 예를 들어, 온라인 슈퍼마켓 주문 인터페이스에는 추천 상품에 대한 주문을 수집하는 기능이 있습니다. 추천 모듈이 다운되면 주문 기능은 일시적으로 꺼질 수 없습니다.

Current Limiting

서비스가 중단된 후 업스트림 서비스나 사용자는 일반적으로 습관적으로 액세스를 다시 시도합니다. 즉, 서비스가 정상으로 돌아오면 과도한 네트워크 트래픽과 관 속에 반복되는 윗몸 일으키기 등으로 인해 곧바로 서비스가 중단될 가능성이 높다는 뜻이다. 따라서 서비스는 트래픽을 제한하여 자체적으로 보호할 수 있어야 합니다. 현재 제한 전략이 많이 있습니다. 가장 간단한 방법은 단위 시간당 요청이 너무 많을 때 초과 요청을 삭제하는 것입니다. 또한 파티션 전류 제한도 고려할 수 있습니다. 많은 수의 요청을 생성하는 서비스의 요청만 거부합니다. 예를 들어, 제품 서비스와 주문 서비스 모두 프로모션 서비스에 액세스해야 합니다. 제품 서비스는 코드 문제로 인해 많은 요청을 시작합니다. 프로모션 서비스는 제품 서비스의 요청만 제한하고 주문 서비스의 요청은 응답합니다. 보통.

Testing

마이크로서비스 아키텍처에서 테스트는 세 가지 수준으로 나뉩니다.

1. 종단 간 테스트: 전체 시스템을 포괄하며 일반적으로 사용자 인터페이스 모델을 테스트합니다.
2. 서비스 테스트: 서비스 인터페이스를 테스트합니다.
3. 단위 테스트: 코드 단위를 테스트합니다.

세 가지 테스트의 구현 용이성은 위에서 아래로 증가하지만 테스트 효과는 감소합니다. 엔드 투 엔드 테스트는 가장 시간이 많이 걸리고 노동 집약적이지만 테스트를 통과한 후에는 시스템에 대해 가장 큰 자신감을 갖게 됩니다. 단위 테스트는 구현하기가 가장 쉽고 효율적이지만 테스트 후에 전체 시스템에 문제가 없다는 보장은 없습니다.

종단 간 테스트 구현이 어렵기 때문에 일반적으로 종단 간 테스트는 핵심 기능에 대해서만 수행됩니다. 엔드투엔드 테스트가 실패하면 이를 단위 테스트로 나누어야 합니다. 그런 다음 실패 이유를 분석한 다음 동일한 오류를 더 빨리 포착할 수 있도록 문제를 재현하기 위해 단위 테스트를 작성합니다. 미래.

서비스 테스트의 어려움은 서비스가 다른 서비스에 의존하는 경우가 많다는 것입니다. 이 문제는 Mock Server를 통해 해결할 수 있습니다.

모두가 단위 테스트에 익숙합니다. 우리는 일반적으로 모든 코드를 다루기 위해 많은 수의 단위 테스트(회귀 테스트 포함)를 작성합니다.

마이크로서비스 프레임워크

표시기 인터페이스, 링크 추적 주입, 로그 전환, 서비스 등록 검색, 라우팅 규칙 및 기타 구성 요소는 물론 회로 차단기, 전류 제한 및 기타 기능을 모두 애플리케이션 서비스에 일부 도킹 코드를 추가해야 합니다. . 각 애플리케이션 서비스를 자체적으로 구현하는 것은 매우 시간이 많이 걸리고 노동 집약적입니다. Xiao Ming은 DRY 원칙을 바탕으로 마이크로서비스 프레임워크를 개발하여 각 구성요소와 인터페이스하는 코드 및 기타 공개 코드를 프레임워크로 추출하고, 모든 애플리케이션 서비스는 이 프레임워크를 사용하여 개발됩니다.

마이크로서비스 프레임워크를 사용하면 다양한 맞춤형 기능을 구현할 수 있습니다. 프로그램 호출 스택 정보를 링크 추적에 주입하여 코드 수준 링크 추적을 달성할 수도 있습니다. 또는 스레드 풀 및 연결 풀의 상태 정보를 출력하여 서비스의 기본 상태를 실시간으로 모니터링합니다.

통합 마이크로서비스 프레임워크를 사용하는 데에는 심각한 문제가 있습니다. 프레임워크를 업데이트하는 데 드는 비용이 매우 높습니다. 프레임워크가 업그레이드될 때마다 모든 애플리케이션 서비스는 업그레이드에 협력해야 합니다. 물론, 호환성 솔루션이 일반적으로 사용되므로 모든 응용 프로그램 서비스가 업그레이드될 때까지 병렬 시간을 기다려야 합니다. 다만, 응용 서비스가 많은 경우 업그레이드 시간이 매우 길어질 수 있습니다. 그리고 업데이트가 거의 되지 않는 매우 안정적인 애플리케이션 서비스도 있으며, 담당자가 업그레이드를 거부할 수도 있습니다... 따라서 통합 마이크로서비스 프레임워크를 사용하려면 완전한 버전 관리 방법과 개발 관리 사양이 필요합니다.

다른 방법 - 서비스 메시

공통 코드를 추상화하는 또 다른 방법은 이 코드를 역방향 프록시 구성 요소로 직접 추상화하는 것입니다. 각 서비스는 이 프록시 구성 요소를 추가로 배포하며 모든 아웃바운드 및 인바운드 트래픽은 이 구성 요소를 통해 처리 및 전달됩니다. 이 구성 요소를 사이드카라고 합니다.

사이드카에는 추가 네트워크 비용이 발생하지 않습니다. 사이드카는 마이크로서비스 노드와 동일한 호스트에 배포되며 동일한 가상 네트워크 카드를 공유합니다. 따라서 사이드카와 마이크로서비스 노드 간의 통신은 실제로 메모리 복사를 통해서만 실현됩니다.

사진 출처: 패턴: 서비스 메시

사이드카는 네트워크 통신만 담당합니다. 모든 사이드카의 구성을 균일하게 관리하려면 구성 요소도 필요합니다. Service Mesh에서는 네트워크 통신을 담당하는 부분을 데이터 플레인(Data Plane), 구성 관리를 담당하는 부분을 컨트롤 플레인(Control Plane)이라고 합니다. 데이터 플레인과 컨트롤 플레인은 Service Mesh의 기본 아키텍처를 구성합니다.

사진 출처: 패턴: Service Mesh

마이크로서비스 프레임워크에 비해 Service Mesh의 장점은 코드에 침입하지 않고 업그레이드 및 유지 관리가 더 편리하다는 것입니다. 성능 문제로 종종 비판을 받습니다. 루프백 네트워크가 실제 네트워크 요청을 생성하지 않더라도 메모리 복사에 대한 추가 비용은 여전히 ​​존재합니다. 또한 일부 중앙 집중식 트래픽 처리도 성능에 영향을 미칩니다.

끝은 시작이기도 합니다

마이크로서비스는 아키텍처 진화의 끝이 아닙니다. 더 나아가 Serverless, FaaS 및 기타 방향이 있습니다. 반면, 시간이 지나면서 조화가 나누어져야 하고 모놀리식 아키텍처가 재발견되어야 한다고 노래하는 사람들도 있습니다...

어쨌든 마이크로서비스 아키텍처의 변혁은 당분간 끝났습니다. 존재. 샤오밍은 점점 부드러워지는 머리를 만족스럽게 쓰다듬으며 이번 주말에 휴식을 취하고 샤오홍을 만나 커피 한 잔을 하기로 했습니다.

위 내용은 이것은 지금까지 읽은 마이크로서비스 아키텍처에 대한 가장 자세한 기사일 것입니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!