상호 신뢰 호스트 플랫폼

SOA 에는 두 가지 일반적인 거버넌스 유형이 있습니다.

그렇다면 마이크로 서비스에서 거버넌스는 무엇을 의미합니까?

마이크로서비스 아키텍처에서 서로 다른 마이크로서비스는 서로 독립적이며 서로 다른 플랫폼과 기술을 기반으로 합니다. 따라서 서비스 설계 및 개발에 대한 공통 표준을 정의할 필요가 없습니다.

마이크로 서비스 거버넌스 센터 해제는 다음과 같이 요약됩니다.

마이크로서비스 아키텍처 하에서 처리해야 할 대량의 마이크로서비스가 있다. 마이크로서비스의 빠르고 민첩한 연구와 개발로 인해 위치가 동적으로 변경될 수 있습니다. 따라서 런타임 시 서비스의 위치를 찾아야 합니다. 서비스 발견은 이 문제를 해결할 수 있습니다.

등록 센터에는 마이크로서비스에 대한 인스턴스 및 위치 정보가 있습니다. 마이크로서비스 시작 시 등록 센터에 자신의 정보를 등록하고 종료 시 로그아웃합니다. 다른 사용자는 등록 센터를 통해 사용 가능한 마이크로서비스 및 관련 정보를 찾을 수 있습니다.

사용 가능한 서비스와 해당 위치 정보를 찾으려면 서비스 검색 메커니즘이 필요합니다. 클라이언트 검색과 서버 검색의 두 가지 검색 메커니즘이 있습니다.

클라이언트 검색-클라이언트 또는 API 게이트웨이가 서비스 등록 센터 또는 서비스의 위치 정보를 쿼리합니다.

클라이언트 /API 게이트웨이는 서비스 검색 논리를 달성하기 위해 서비스 등록 구성 요소를 호출해야 합니다.

서버 검색-클라이언트 /API 게이트웨이는 알려진 위치 정보가 있는 구성 요소 (예: 로드 밸런서) 로 요청을 보냅니다. 구성 요소는 레지스트리에 액세스하고 마이크로서비스에 대한 위치 정보를 찾습니다.

Es.io/v1.1/docs/user-guide/services.html 과 같은 마이크로서비스 배포 솔루션은 서버측에서 자동 검색 메커니즘을 제공합니다.

마이크로 서비스 배포 모델도 특히 중요합니다. 다음은 핵심입니다.

Docker (Linux 에서 실행되는 오픈 소스 응용 프로그램, 개발 및 실행 지원, 컨테이너에서 응용 프로그램 실행) 는 다음과 같은 사항을 포함하여 마이크로서비스를 신속하게 배포할 수 있습니다.

Docker 컨테이너를 사용하면 기존 가상 시스템 모드에 비해 마이크로서비스를 구축, 게시 및 시작하는 속도가 매우 빨라집니다.

Kubernetes 를 통해 Docker 의 기능은 단일 Linux 호스트에서 Linux 클러스터로 확장할 수 있으며 다중 호스트 지원, 컨테이너 위치 관리, 서비스 검색 및 다중 인스턴스를 지원합니다. 마이크로 서비스 수요의 중요한 특징입니다. 따라서 Kubernetes 를 사용하여 마이크로서비스 및 컨테이너의 게시를 관리하는 것은 매우 강력한 시나리오입니다.

그림 1 1 은 소매 어플리케이션의 마이크로서비스 배포를 보여줍니다. 각 서비스는 각각 두 개의 컨테이너가 있는 별도의 컨테이너에 있습니다. Kubernetes 를 통해 컨테이너 수를 자유롭게 조정할 수 있습니다.

실제 운영 환경에서는 마이크로서비스의 보안도 중요합니다. 먼저 단일 아키텍처에서 보안이 어떻게 구현되는지 살펴보겠습니다.

일반적인 단일 응용 프로그램의 경우 보안 문제는 주로 "누가 호출합니까?", "호출해야 무엇을 할 수 있습니까?", "어떻게 처리해야 합니까?" 입니다. 서버가 요청을 받으면 일반적으로 처리 체인의 시작 부분에서 보안 구성 요소를 통해 요청된 정보를 안전하게 처리합니다.

이 처리 방법을 마이크로서비스 아키텍처에 직접 적용할 수 있습니까? 대답은' 예' 입니다. 각 마이크로서비스는 보안 구성 요소를 구현하고, 컨텐츠 센터에서 적절한 사용자 정보를 얻고, 보안 제어를 구현해야 합니다. 이것은 비교적 초급적인 치료이다. OAuth2 및 OpenID 와 같은 몇 가지 표준 API 메서드를 사용해 볼 수 있습니다. 더 자세히 살펴보기 전에 이 두 가지 보안 프로토콜과 사용 방법을 요약할 수 있습니다.

OAuth2- 액세스 승인 계약입니다. 권한이 필요한 클라이언트는 권한 부여 서비스에 액세스 토큰을 요청합니다. 액세스 토큰에는 사용자/클라이언트에 대한 정보가 없으며 인증 서버에 대한 사용자 참조 정보만 있습니다. 따라서이 "참조 토큰" 에는 보안 문제가 없습니다.

OpenID 는 OAuth 와 비슷하지만 권한 부여 서버는 액세스 토큰 외에 사용자 정보가 포함된 ID 토큰을 게시합니다. 일반적으로 JWT(JSON Web Token) 형태의 인증 서버에 의해 구현됩니다. 이렇게 하면 클라이언트와 서버 간의 상호 신뢰가 보장됩니다. JWT 토큰은 사용자의 ID 정보를 포함하는 "컨텐츠 있는 토큰" 으로 공용 환경에서 안전하지 않습니다.

이제 온라인 소매 웹 사이트에서 이러한 프로토콜을 적용하여 마이크로서비스의 보안을 보장하는 방법을 살펴보겠습니다.

그림 12 에서 볼 수 있듯이 마이크로서비스 보안을 위한 핵심 단계는 다음과 같습니다.

JWT 에는 필요한 사용자 정보가 포함되어 있습니다. 각 마이크로서비스가 JWT 를 구문 분석할 수 있다면 시스템의 각 서비스는 ID 관련 비즈니스를 처리할 수 있습니다. 각 마이크로서비스에서 JWT 를 처리하는 경량 구성 요소가 있을 수 있습니다.

마이크로서비스에서 트랜잭션을 어떻게 지원합니까? 실제로 여러 마이크로서비스에 분산 트랜잭션 지원은 매우 복잡하며, 마이크로서비스는 여러 서비스 간의 트랜잭션 작업을 최대한 피하도록 설계되었습니다.

해결책은 마이크로서비스가 완벽하게 기능적이고 책임있는 단일 원칙을 따르도록 설계되었다는 것입니다. 여러 마이크로서비스에 걸쳐 분산 트랜잭션을 지원하는 것은 마이크로서비스 아키텍처에서 좋은 설계 아이디어가 아니며, 일반적으로 마이크로서비스의 책임을 재정의해야 합니다. 일부 시나리오에서는 서비스 간 분산 트랜잭션을 지원하고 각 마이크로서비스에서 "복합 작업" 을 활용할 수 있어야 합니다.

가장 중요한 것은 단일 책임 원칙에 따라 마이크로서비스를 설계하는 것이다. 서비스가 특정 작업을 제대로 수행할 수 없는 경우 이 서비스에 문제가 있습니다. 그러면 모든 업스트림 작업은 해당 마이크로서비스에서 롤백 작업을 수행해야 합니다.

마이크로 서비스 아키텍처는 단일 설계보다 더 많은 서비스를 도입하여 각 서비스 수준에 오류가 발생할 가능성을 높입니다. 네트워크 문제 및 기본 리소스와 같은 다양한 문제로 인해 서비스가 실패할 수 있습니다. 서비스의 불가능성은 전체 어플리케이션의 붕괴에 영향을 주어서는 안 된다. 따라서 마이크로서비스 시스템은 내결함성이 있어야 하며, 자동 응답도 가능해야 하며, 클라이언트도 모르는 것이어야 합니다.

모든 서비스는 언제든지 오류가 발생할 수 있으며 모니터링 시스템은 문제를 발견하고 자동으로 복구할 수 있어야 합니다. 마이크로 서비스 환경에는 많은 일반적인 모델이 있습니다.

마이크로서비스의 요청 실패율이 어느 정도 되면 시스템의 모니터링이 회선 중단을 활성화할 수 있습니다. 정상 요청 수가 어느 정도 복원되면 회선 인터럽트 스위치를 꺼서 시스템을 정상 상태로 되돌립니다.

이 모드는 불필요한 자원 소비를 방지하며, 요청 처리 지연으로 인해 시간 초과가 발생하여 모니터링 시스템이 더욱 완벽해질 수 있습니다.

한 앱에는 렌터카가 많은 마이크로서비스가 있을 수 있으며, 단일 마이크로서비스의 고장은 전체 시스템에 영향을 미치지 않을 것이다. 방화벽 모드는 서비스의 직접 격리를 강조하며, 마이크로서비스는 다른 마이크로서비스 고장의 영향을 받지 않습니다.

시간 초과 메커니즘은 더 이상 응답이 없다고 판단될 때 마이크로서비스를 기다리는 응답을 적극적으로 포기하는 것입니다. 이 시간 초과는 구성 가능해야 합니다.

어떤 상황에서 이러한 모델을 어떻게 사용합니까? 대부분의 경우 게이트웨이에서 처리해야 합니다. 마이크로서비스를 사용할 수 없거나 응답이 없을 때 게이트웨이는 회선 중단 또는 시작 시간 초과 메커니즘을 결정할 수 있습니다. 방화벽 메커니즘도 똑같이 중요합니다. 게이트웨이는 모든 요청에 대한 유일한 포털이며, 한 마이크로서비스의 장애는 다른 마이크로서비스에 영향을 미치지 않아야 합니다. 게이트웨이는 또한 마이크로서비스 상태 및 모니터링 정보를 얻는 중심이기도 합니다.

마이크로서비스의 아키텍처와 특징, 그리고 현대 it 시스템에 어떻게 적용할 수 있는지에 대해 논의했습니다. 동시에, 우리는 마이크로서비스가 모든 문제를 해결하는 만병통치약이 아니라는 것을 깨달아야 한다. 유행을 맹목적으로 추구하는 기술 개념은 기업 it 시스템의 문제를 해결하지 못한다.

마이크로서비스는 많은 장점을 가지고 있지만 마이크로서비스만으로는 기업 IT 의 모든 문제를 해결할 수 없습니다. 예를 들어 마이크로서비스는 ESB 를 제거해야 하지만 실제 IT 시스템에서는 대량의 어플리케이션과 서비스가 마이크로서비스가 아닌 ESB 를 기반으로 합니다. 기존 시스템을 통합하려면 통합 버스가 필요합니다. 사실, 마이크로 서비스와 다른 엔터프라이즈 아키텍처가 공존합니다.