Docker의 컨테이너 기술을 사용하여 서비스 아키텍처 시스템 DevOps 레이아웃 - JAVA 아키텍처
- php是最好的语言원래의
- 2018-07-27 11:59:403149검색
저는 2015년부터 Docker 기반의 컨테이너 기술을 접하기 시작했습니다. 2년 넘게 Docker DevOps 실무자로서 Docker 기술 시스템의 급속한 발전도 목격했습니다. 본 글은 주로 회사에서 구축한 마이크로서비스 아키텍처의 실제 프로세스를 바탕으로 간단한 요약을 작성했습니다. 창업 초기 단계에서 서비스 아키텍처 시스템을 배치하는 방법을 탐구하고 있거나 엔터프라이즈 수준 아키텍처에 대한 사전 이해를 원하는 DevOps 학생들에게 참고가 되었으면 합니다.
Microservice and Docker
스타트업의 기술적 레이아웃과 관련하여 기본적으로 스타트업은 빠르게 온라인에 접속하고 시행착오도 빨리 거쳐야 한다는 목소리가 많습니다. 단일 애플리케이션을 사용하거나 프런트엔드와 백엔드 애플리케이션을 분리하여 빠르게 통합, 개발, 출시할 수 있습니다. 그러나 실제로 이 결과로 인한 숨겨진 비용은 더 높을 것입니다. 비즈니스가 발전하고 개발자가 많아지면 거대한 시스템의 배포 효율성과 개발 협업 효율성의 문제에 직면하게 됩니다. 그리고 서비스 분할, 데이터 읽기 및 쓰기 분리, 서브 데이터베이스와 서브 테이블 분리 등을 통해 구조를 재구성하게 된다. 게다가 이 방법을 철저하게 하려면 많은 인력과 물적 자원이 필요하게 된다. 자원.
제 개인적인 제안은 DevOps가 비즈니스의 현재 및 장기적 발전에 대한 자신의 판단과 결합되어야 하며 프로젝트 초기 단계에서 마이크로서비스 아키텍처를 사용할 수 있어 미래 세대에 도움이 될 수 있다는 것입니다.
Docker를 중심으로 한 오픈 소스 커뮤니티의 발전으로 마이크로서비스 아키텍처의 개념이 더 나은 구현 계획을 가질 수 있습니다. 그리고 각 마이크로서비스 애플리케이션 내에서 DDD(Domain-Drive Design)의 육각형 아키텍처를 서비스 내 설계에 사용할 수 있습니다. DDD에 대한 일부 개념의 경우 이전에 작성된 여러 기사인 도메인 중심 디자인 구성 - 개념 및 아키텍처, 도메인 중심 디자인 구성 - 엔터티 및 값 개체 디자인, 도메인 서비스, 도메인 이벤트를 참조할 수도 있습니다.
명확한 마이크로서비스 도메인 분할, 서비스 내 아키텍처 수준의 우아한 구현, RPC 또는 이벤트 기반을 통한 서비스 간 필요한 IPC, 모든 마이크로서비스의 요청 전달에 사용되는 API 게이트웨이 및 비차단 요청 결과 병합. 다음 글에서는 분산 환경에서 위의 특성을 지닌 Docker를 이용해 마이크로서비스 아키텍처를 빠르게 구축하는 방법을 자세히 소개하겠습니다.
서비스 검색 모델
Docker 기술을 사용하여 마이크로서비스 시스템을 구축한다면 서비스 검색은 피할 수 없는 주제입니다. 현재 주류 서비스 검색 모드에는 클라이언트 검색 모드와 서버 검색 모드의 두 가지가 있습니다.
클라이언트 검색 모드
클라이언트 검색 모드의 아키텍처 다이어그램은 다음과 같습니다.
클라이언트 검색 모드의 일반적인 구현은 Netflix 시스템 기술입니다. 클라이언트는 서비스 등록 서비스 센터에서 사용 가능한 모든 서비스 인스턴스를 쿼리합니다. 클라이언트는 로드 밸런싱 알고리즘을 사용하여 사용 가능한 여러 서비스 인스턴스 중 하나를 선택한 다음 요청합니다. 일반적인 오픈 소스 구현은 Netflix의 Eureka입니다.
Netflix-Eureka
Eureka의 클라이언트는 자체 등록 모드를 채택합니다. 클라이언트는 서비스 인스턴스의 등록 및 등록 취소 처리와 하트비트 전송을 담당해야 합니다.
SpringBoot를 사용하여 마이크로서비스를 통합할 때 SpringCloud 프로젝트와 결합하면 자동 등록이 쉽게 이루어질 수 있습니다. 서비스 인스턴스가 시작될 때 구성된 Eureka 서버에 서비스를 등록하고 정기적으로 하트비트를 보내려면 서비스 시작 클래스에 @EnableEurekaClient를 추가합니다. 클라이언트 측 로드 밸런싱은 Netflix Ribbon으로 구현됩니다. 서비스 게이트웨이는 Netflix Zuul을 사용하고 회로 차단기는 Netflix Hystrix를 사용합니다.
서비스 검색을 위한 지원 프레임워크 외에도 SpringCloud의 Netflix-Feign은 서비스에 대한 Rest 요청을 처리하기 위한 선언적 인터페이스를 제공합니다. 물론 FeignClient 외에도 Spring RestTemplate을 사용할 수도 있습니다. 프로젝트에서 @FeignClient를 사용하면 코드의 가독성이 높아지고 Rest API가 한눈에 명확해집니다.
서비스 인스턴스의 등록 관리 및 쿼리는 모두 애플리케이션 내에서 Eureka에서 제공하는 REST API 인터페이스를 호출하여 수행됩니다(물론 SpringCloud-Eureka를 사용할 때 이 부분의 코드를 작성할 필요는 없습니다). 서비스 등록 및 등록 취소는 클라이언트 자체를 통해 요청되므로 이 모델의 주요 문제점은 프로그래밍 언어별로 서로 다른 서비스가 등록되고, 개발 언어별로 서비스 검색 로직을 별도로 개발해야 한다는 것입니다. 또한 Eureka를 사용할 때 상태 확인 지원을 명시적으로 구성해야 합니다.
서버 측 검색 모드
서버 측 검색 모드의 아키텍처 다이어그램은 다음과 같습니다.
클라이언트는 로드 밸런서에 요청을 보내고 로드 밸런서는 서비스 레지스트리에 요청을 보내고 서비스 인스턴스에서 사용 가능한 서비스로 요청을 전달합니다. 서비스 인스턴스도 레지스트리에 등록 및 등록 취소됩니다. 로드 밸런싱은 Haproxy 또는 Nginx를 사용할 수 있습니다. Docker를 기반으로 하는 서버 측 검색 모드를 위한 현재 주류 솔루션은 Consul, Etcd 및 Zookeeper입니다.
Consul
Consul은 클라이언트가 서비스를 등록하고 검색할 수 있는 API를 제공합니다. 일관성은 RAFT 알고리즘을 기반으로 합니다. WAN의 Gossip 프로토콜을 통해 구성원을 관리하고 메시지를 브로드캐스트하여 데이터 센터 간 동기화를 완료하고 ACL 액세스 제어를 지원합니다. Consul은 또한 상태 확인 메커니즘을 제공하고 kv 스토리지 서비스를 지원합니다(Eureka에서는 지원되지 않음). Consul에 대한 자세한 소개는 제가 이전에 작성한 기사인 Consul 클러스터의 Docker 컨테이너 배포를 참조하세요.
Etcd
Etcd는 일관성이 뛰어나고(CAP를 충족하는 CP) 가용성이 높습니다. Etcd는 또한 KV 데이터 동기화의 강력한 일관성을 달성하기 위해 RAFT 알고리즘을 기반으로 합니다. Kubernetes는 Etcd의 KV 구조를 사용하여 모든 객체의 수명 주기를 저장합니다.
Etcd의 일부 내부 원칙에 대해서는 etcd v3 원칙 분석을 읽을 수 있습니다.
Zookeeper
ZK는 Hadoop에서 처음 사용되었으며 해당 시스템은 매우 성숙했으며 대기업에서 자주 사용됩니다. 이미 자체 ZK 클러스터가 있는 경우 ZK를 자체 서비스 등록 센터로 사용하는 것을 고려할 수 있습니다.
Zookeeper는 강력한 일관성과 고가용성을 갖춘 Etcd와 동일합니다. 합의 알고리즘은 Paxos를 기반으로 합니다. 마이크로서비스 아키텍처의 초기 단계에서는 서비스 검색을 위해 더 무거운 ZK를 사용할 필요가 없습니다.
서비스 등록
서비스 레지스트리는 서비스 검색의 중요한 구성 요소입니다. Kubernetes 및 Marathon 외에도 서비스 검색이 기본 제공 모듈입니다. 서비스는 레지스트리에 등록되어야 합니다. 위에 소개된 Eureka, consul, etcd 및 ZK는 모두 서비스 레지스트리의 예입니다.
마이크로서비스가 레지스트리에 등록되는 방법에는 자체 등록 모드와 타사 등록 모드라는 두 가지 일반적인 등록 방법이 있습니다.
자체 등록 패턴
위의 Netflix-Eureka 클라이언트는 자가 등록 패턴의 대표적인 예입니다. 즉, 각 마이크로서비스 인스턴스 자체가 서비스 등록 및 등록 취소를 담당해야 합니다. Eureka는 또한 등록 정보의 정확성을 보장하기 위해 하트비트 메커니즘을 제공합니다. 특정 하트비트 전송 간격은 마이크로서비스의 SpringBoot에서 구성할 수 있습니다.
다음과 같이 Eureka를 레지스트리로 사용하는 경우 마이크로서비스(SpringBoot 애플리케이션)가 시작될 때 서비스 등록 정보가 있습니다.
마찬가지로 애플리케이션이 비활성화되면 서비스 인스턴스가 적극적으로 로그아웃해야 합니다. 인스턴스 정보 ：
자가 등록 방법은 추가 시설이나 에이전트가 필요하지 않은 비교적 간단한 서비스 등록 방법입니다. 하지만 단점도 분명합니다. 예를 들어 Eureka는 현재 Java 클라이언트만 제공하므로 다국어 마이크로서비스 확장에는 편리하지 않습니다. 마이크로서비스는 서비스 등록 로직 자체를 관리해야 하므로 마이크로서비스 구현은 서비스 등록과 하트비트 메커니즘도 결합합니다. 언어 간 성능은 상대적으로 좋지 않습니다.
여기에서는 여러분에게 건축 학습 및 교류 그룹을 추천합니다. 커뮤니케이션 및 학습 그룹 번호: 478030634. Spring, MyBatis, Netty 소스 코드 분석, 높은 동시성 원칙, 고성능, 분산 및 마이크로서비스 아키텍처, JVM 성능 최적화, 분산 아키텍처 등 수석 설계자가 기록한 일부 비디오를 공유합니다. 건축가에게 꼭 필요한 지식 시스템이 되었습니다. 무료 학습자료도 받아보실 수 있으며, 현재 많은 혜택을 누리고 계십니다
제3자 등록 패턴
제3자 등록, 즉 서비스 전담 관리자(Registar)를 통해 서비스 등록(등록, 취소 서비스) 관리를 하러 오세요 책임을 맡다. 등록자는 오픈 소스 서비스 관리자 구현입니다. 등록자는 Etcd 및 Consul에 대한 등록 서비스 지원을 제공합니다. 프록시 서비스인 등록자는 마이크로서비스가 있는 서버 또는 가상 머신에 배포 및 실행되어야 합니다. 더 간단한 설치 방법은 Docker를 통해 컨테이너로 실행하는 것입니다.
3자 등록 모델의 아키텍처 다이어그램은 다음과 같습니다.
서비스 관리자를 추가하면 마이크로서비스 인스턴스가 더 이상 등록 센터에 직접 등록하거나 로그아웃하지 않습니다. 서비스 관리자(Registar)는 서비스 구독, 하트비트 추적, 등록 센터(영사, etcd 등)에 등록, 인스턴스 등록 취소, 하트비트 전송을 통해 사용 가능한 서비스 인스턴스를 검색합니다. 이러한 방식으로 서비스 검색 구성 요소와 마이크로서비스 아키텍처를 분리할 수 있습니다.
Registrator는 Consul 및 Consul Template과 협력하여 서비스 검색 센터를 구축합니다. 다음을 참조할 수 있습니다. 확장 가능한 아키텍처 DR CoN: Docker, Registrator, Consul, Consul Template 및 Nginx. 이 기사에서는 로드 밸런싱을 위해 Nginx를 사용하는 예를 제공합니다. 특정 구현 프로세스에서는 Haproxy 또는 다른 솔루션을 대신 사용할 수도 있습니다.
요약
위의 서비스 검색 기술 외에도 Kubernetes에는 서비스 인스턴스의 등록 및 등록 취소 처리를 담당하는 자체 서비스 검색 모듈이 함께 제공됩니다. Kubernetes는 또한 각 클러스터 노드에서 에이전트를 실행하여 서버 측 라우터 검색을 구현합니다. 오케스트레이션 기술이 k8n을 사용하는 경우 k8n의 전체 Docker 마이크로서비스 솔루션 세트를 사용할 수 있습니다. k8n에 관심이 있는 사람은 Kubernetes 아키텍처 설계 및 핵심 원칙을 읽을 수 있습니다.
실제 기술 선정에 있어서 가장 중요한 것은 사업과 시스템의 향후 발전 특성을 바탕으로 합리적인 판단을 내리는 것입니다.
CAP 이론에서. Eureka는 AP를 만족하고 Consul은 CA, ZK, Etcd는 CP를 만족합니다. Eureka와 Consul은 모두 분산 시나리오에서 가용성을 보장할 수 있습니다. Eureka 서비스를 구축하는 것은 추가적인 고가용성 서비스 등록 센터를 구축할 필요가 없기 때문에 상대적으로 더 빠릅니다. 소규모 서버 인스턴스를 사용할 경우 Eureka를 사용하면 일정 비용을 절약할 수 있습니다.
Eureka와 Consul은 모두 서비스 등록 데이터를 볼 수 있는 WebUI 구성 요소를 제공합니다. Consul은 또한 KV 스토리지를 제공하고 http 및 dns 인터페이스를 지원합니다. 스타트업이 마이크로서비스를 처음 구축하려면 이 두 가지를 권장합니다.
다중 데이터 센터 측면에서 Consul은 데이터 센터 WAN 솔루션을 제공합니다. ZK나 Etcd는 다중 데이터 센터 기능을 지원하지 않으며 추가 개발이 필요합니다.
교차 언어 측면에서 Zookeeper는 Zookeeper에서 제공하는 클라이언트 API를 사용해야 하며 교차 언어 지원이 약합니다. Etcd와 Eureka는 모두 http를 지원하며 Etcd는 grpc도 지원합니다. http 외에도 Consul은 DNS 지원도 제공합니다.
보안 측면에서 Consul과 Zookeeper는 ACL을 지원하고 Consul과 Etcd는 보안 채널 HTTPS를 지원합니다.
SpringCloud는 현재 Eureka, Consul, Etcd 및 ZK를 지원합니다.
Consul은 Docker와 마찬가지로 Go 언어로 구현됩니다. Go 언어 기반의 마이크로서비스 애플리케이션은 Consul 사용에 우선순위를 둘 수 있습니다.
서비스 간 IPC 메커니즘
마이크로서비스 아키텍처 시스템에 따른 서비스 검색 문제를 해결한 후. 서비스 간 적절한 통신 메커니즘을 선택해야 합니다. SpringBoot 애플리케이션을 사용하는 경우 HTTP 프로토콜 기반 REST API를 사용하는 것이 동기식 솔루션입니다. 또한 Restful 스타일 API는 각 마이크로서비스 애플리케이션을 보다 리소스 지향적으로 만들 수 있으며, 마이크로서비스에서는 경량 프로토콜 사용을 옹호해 왔습니다.
각 마이크로서비스가 DDD(Domain-Driven Design) 아이디어를 사용하는 경우 각 마이크로서비스는 동기식 RPC 메커니즘을 사용하지 않도록 노력해야 합니다. AMQP 또는 STOMP와 같은 비동기 메시지 기반 방법은 마이크로서비스 간의 종속성을 느슨하게 결합하는 데 좋은 선택입니다. 현재 메시지 기반 지점간 게시/구독 프레임워크에는 다양한 옵션이 있습니다. 다음은 두 IPC의 일부 솔루션에 대한 자세한 소개입니다.
동기화
동기식 요청/응답 모드 통신 방법용. Restful 스타일 Http 프로토콜을 기반으로 하는 서비스 간 통신이나 언어 간 기능이 뛰어난 Thrift 프로토콜을 선택할 수 있습니다. 순수 Java 언어 마이크로서비스를 사용하는 경우 Dubbo를 사용할 수도 있습니다. SpringBoot와 통합된 마이크로서비스 아키텍처 시스템이라면 언어 간 성능이 좋고 Spring 커뮤니티에서 더 나은 지원을 제공하는 RPC를 선택하는 것이 좋습니다.
Dubbo
Dubbo는 Alibaba에서 개발한 오픈 소스 Java 클라이언트 RPC 프레임워크입니다. Dubbo는 TCP 프로토콜의 긴 연결을 기반으로 데이터를 전송합니다. 전송 형식은 Hessian 이진 직렬화를 사용합니다. 서비스 등록센터는 Zookeeper를 통해 구현 가능합니다.
ApacheThrift
ApacheThrift는 Facebook에서 개발한 RPC 프레임워크입니다. 코드 생성 엔진은 C++, Java, Python, PHP, Ruby, Erlang, Perl 등과 같은 여러 언어로 효율적인 서비스를 생성할 수 있습니다. 전송되는 데이터는 바이너리 형식이며 해당 패킷은 Json 또는 XML 형식을 사용하는 HTTP 프로토콜보다 작습니다. 빅 데이터 시나리오에서는 높은 동시성이 더 유리합니다.
Rest
Rest는 HTTP 프로토콜을 기반으로 하며 HTTP 프로토콜 자체에는 풍부한 의미가 있습니다. Springboot가 널리 사용됨에 따라 점점 더 많은 Restful 스타일 API가 대중화되고 있습니다. REST는 HTTP 프로토콜을 기반으로 하며 대부분의 개발자는 HTTP에 익숙합니다.
여기서 또 언급할 점은 많은 기업이나 팀에서도 Springboot를 사용하고 있으며 Restful 스타일을 기반으로 한다고도 합니다. 그러나 현실은 구현이 제대로 이루어지지 않는 경우가 많습니다. 귀하의 Restful이 실제로 Restful인지 확인하려면 Restful 스타일 API의 성숙도에 대한 4단계 분석을 수행하는 이 기사를 참조하세요. Richardson 성숙도 모델은 REST의 영광을 향한 단계입니다.
Springboot를 사용하는 경우 어떤 서비스 검색 메커니즘을 사용하더라도 Spring의 RestTemplate을 사용하여 기본적인 HTTP 요청 캡슐화를 수행할 수 있습니다.
위에서 언급한 Netflix-Eureka를 사용하는 경우 Netflix-Feign을 사용할 수 있습니다. Feign은 선언적 웹 서비스 클라이언트입니다. 클라이언트 측 로드 밸런싱은 Netflix-Ribbon을 사용합니다.
Asynchronous
순수한 "이벤트 중심 아키텍처"를 제외하고 마이크로서비스 아키텍처에서 메시지 대기열을 사용하는 시나리오는 일반적으로 마이크로서비스를 분리하는 것입니다. 서비스는 어떤 서비스 인스턴스가 메시지를 사용하거나 게시하는지 알 필요가 없습니다. 자신의 도메인 내에서 로직을 처리한 다음 메시지 채널을 통해 게시하거나 관심 있는 메시지를 구독하세요. 현재 많은 오픈 소스 메시지 큐 기술이 있습니다. 예를 들어 Apache Kafka, RabbitMQ, Apache ActiveMQ 및 Alibaba의 RocketMQ는 이제 Apache 프로젝트 중 하나가 되었습니다. 메시지 대기열 모델에서 세 가지 주요 구성 요소는 다음과 같습니다.
Producer: 메시지를 생성하고 채널에 메시지를 씁니다.
메시지 브로커: 메시지 브로커는 대기열 구조에 따라 채널에 기록된 메시지를 관리합니다. 메시지 저장/전달을 담당합니다. 브로커는 일반적으로 별도로 구축하고 구성해야 하는 클러스터이며 가용성이 높아야 합니다.
소비자: 메시지 소비자입니다. 최신 메시지 대기열에서는 메시지가 한 번 이상 소비되도록 보장합니다. 따라서 사용된 메시지 대기열 기능에 따라 소비자는 멱등성이 있어야 합니다.
다른 메시지 대기열 구현에는 다른 메시지 모델이 있습니다. 각 프레임워크의 특성도 다릅니다.
RabbitMQ
RabbitMQ는 AMQP 프로토콜을 기반으로 한 오픈 소스 구현으로, 고성능과 확장성으로 유명한 Erlang으로 작성되었습니다. 현재 클라이언트는 Java, .Net/C# 및 Erlang을 지원합니다. AMQP(Advanced Message Queuing Protocol) 구성 요소 중에서 브로커에는 여러 Exchange(스위치) 구성 요소가 포함될 수 있습니다. Exchange는 다른 Exchange뿐만 아니라 여러 대기열을 바인딩할 수 있습니다. 메시지는 Exchange에 설정된 라우팅 규칙에 따라 해당 메시지 큐로 전송됩니다. 소비자는 메시지를 소비한 후 브로커와의 연결을 설정합니다. 소비된 메시지에 대한 알림을 보냅니다. 그러면 Message Queue가 메시지를 제거합니다.
Kafka
Kafka는 고성능 게시/구독 기반 교차 언어 분산 메시징 시스템입니다. Kafka의 개발 언어는 Scala입니다. 더 중요한 기능은 다음과 같습니다.
시간 복잡도가 O(1)인 빠른 메시지 지속성
서비스 간 메시지 분할 및 분산 소비 지원
온라인 수평 확장 지원;
소비 전용 및 한 번만 소비(정확히 한 번) 모드 등을 지원합니다.
단점에 대해 이야기하자면, 관리 인터페이스가 약간 쓸모가 없습니다. 오픈 소스 kafka-manager를 사용할 수 있습니다.
높은 처리량 특성으로 마이크로서비스 간의 메시지 대기열 역할 외에도 로그 수집에도 사용할 수 있습니다. 오프라인 분석, 실시간 분석을 기다립니다.
Kafka는 공식적으로 Java 버전의 클라이언트 API를 제공하며 Kafka 커뮤니티는 현재 PHP, Python, Go, C/C++, Ruby, NodeJS 등을 포함한 여러 언어를 지원합니다.
ActiveMQActiveMQ는 JMS(Java Messaging Service)를 기반으로 구현된 JMSProvider입니다. JMS는 주로 Point-to-Point와 Publish/Subscribe라는 두 가지 유형의 메시지를 제공합니다. 현재 클라이언트는 Java, C, C++, C#, Ruby, Perl, Python 및 PHP를 지원합니다. 그리고 ActiveMQ는 Stomp, AMQP, MQTT, OpenWire 등 여러 프로토콜을 지원합니다.
RocketMQ/ONSRocketMQ는 Alibaba에서 개발한 오픈 소스 고가용성 분산 메시지 대기열입니다. ONS는 상용 버전을 제공하는 고가용성 클러스터입니다. ONS는 풀/푸시를 지원합니다. 이는 활성 푸시와 수백억 개의 메시지 축적을 지원할 수 있습니다. ONS는 전역 순차 메시지를 지원하고 메시지 대기열 소비를 모니터링할 수 있는 친숙한 관리 페이지를 갖추고 있으며 여러 메시지 재전송의 수동 트리거를 지원합니다.
API 게이트웨이를 사용하여 마이크로서비스 요청 전달 및 병합 처리
이전 기사에서는 주로 마이크로서비스의 서비스 검색 및 통신 문제를 해결하는 방법을 소개했습니다. 마이크로서비스 아키텍처 시스템에서 DDD 사고를 사용하여 서비스 간에 제한된 컨텍스트를 분할하면 마이크로서비스 간의 호출이 최소화됩니다. 마이크로서비스를 분리하기 위해 API Gateway 기반의 최적화 솔루션이 있습니다.
마이크로서비스 호출 분리
예를 들어 다음은 일반적인 수요 시나리오인 "사용자 주문 목록"의 집계 페이지입니다. 기본적인 사용자 정보를 얻으려면 "사용자 서비스"를 요청하고, 주문 정보를 얻으려면 "주문 서비스"를 요청해야 하며, 주문 목록에 있는 제품 사진, 제목 및 기타 정보를 얻으려면 "제품 서비스"를 요청해야 합니다. 아래 그림과 같이:
클라이언트(예: H5, Android, iOS)가 다중 정보 집계를 해결하기 위해 다중 요청을 발행할 수 있는 경우 , 이로 인해 클라이언트의 복잡성이 증가합니다. 보다 합리적인 방법은 API 게이트웨이 레이어를 추가하는 것입니다. 마이크로서비스와 마찬가지로 API Gateway도 Docker 컨테이너에서 배포하고 실행할 수 있습니다. 이는 Springboot 애플리케이션이기도 합니다. 게이트웨이 API를 통해 전달한 후 다음과 같습니다.
요청된 모든 정보는 시스템에 들어가는 유일한 노드이기도 한 게이트웨이에 의해 집계됩니다. 게이트웨이와 모든 마이크로서비스는 물론 클라이언트에게 제공되는 것도 Restful 스타일 API입니다. 게이트웨이 계층의 도입은 정보 수집 문제를 잘 해결할 수 있습니다. 예를 들어 H5 페이지는 사용자 정보를 표시할 필요가 없으며, iOS 클라이언트는 리소스를 요청하기 위해 게이트웨이 API만 추가하면 됩니다. 마이크로서비스 계층은 표시될 필요가 없습니다.
API 게이트웨이 기능
API 게이트웨이는 요청을 병합하고 전달할 수 있을 뿐만 아니라. 또한 완전한 게이트웨이가 되려면 다른 기능도 필요합니다.
반응형 프로그래밍
Gateway는 모든 클라이언트 요청의 진입점입니다. 외관 모드와 유사합니다. 요청 성능을 향상하려면 비차단 I/O 프레임워크를 선택하는 것이 가장 좋습니다. 여러 마이크로서비스를 요청해야 하는 일부 시나리오에서는 각 마이크로서비스에 대한 요청을 반드시 동기화할 필요가 없습니다. 위에 제공된 "사용자 주문 목록" 예에서 사용자 정보를 얻는 것과 주문 목록을 얻는 것은 두 개의 독립적인 요청입니다. 주문의 제품 정보를 얻으려면 주문 정보가 반환될 때까지 기다린 다음 주문의 제품 ID 목록을 기반으로 제품 마이크로서비스를 요청해야 합니다. 전체 요청에 대한 응답 시간을 줄이기 위해서는 Gateway가 독립적인 요청을 동시에 처리할 수 있어야 합니다. 한 가지 해결책은 반응형 프로그래밍을 채택하는 것입니다.
현재 Java 기술 스택을 사용하는 Reactive 프로그래밍 방법에는 Java8의 CompletableFuture와 ReactiveX - RxJava에서 제공하는 JVM 기반 구현이 포함됩니다.
ReactiveX는 비동기 프로그래밍을 위해 관찰 가능한 데이터 스트림을 사용하는 프로그래밍 인터페이스로 관찰자 패턴, 반복자 패턴 및 함수형 프로그래밍의 본질을 결합합니다. RxJava 외에도 RxJS 및 RX.NET과 같은 다중 언어 구현도 있습니다.
Gateway의 경우 RxJava에서 제공하는 Observable은 병렬 독립 I/O 요청을 매우 잘 해결할 수 있으며, 마이크로서비스 프로젝트에서 Java8을 사용하면 팀원이 RxJava 기능을 더 빨리 배우고 흡수할 수 있습니다. Lambda 스타일을 기반으로 한 반응형 프로그래밍도 코드를 더욱 간결하게 만들 수 있습니다. RxJava에 대한 자세한 소개를 보려면 RxJava 설명서와 튜토리얼을 읽어보세요.
Reactive 프로그래밍의 Observable 모드를 통해 매우 간단하고 편리하게 이벤트 스트림과 데이터 스트림을 생성할 수 있으며, 간단한 함수를 사용하여 데이터를 결합하고 변환하는 동시에 모든 Observable을 구독할 수 있습니다. 데이터 스트림 및 작업을 수행합니다.
RxJava를 사용하여 "User Order List"의 리소스 요청 시퀀스 다이어그램:
Reactive 프로그래밍은 다양한 스레드를 더 잘 처리할 수 있습니다. 동기화 및 동시성 요청은 Observable 및 Scheduler를 통해 투명한 데이터 흐름 및 이벤트 흐름 스레드 처리를 제공합니다. 민첩한 개발 모델에서 반응형 프로그래밍은 코드를 더욱 간결하고 유지 관리하기 쉽게 만듭니다.
Authentication
Gateway는 시스템에 대한 유일한 입구입니다. 마이크로서비스 기반의 모든 인증은 Gateway를 통해 이루어질 수 있습니다. Springboot 프로젝트에서 기본 인증은 spring-boot-starter-security 및 Spring Security를 사용할 수 있습니다(Spring Security는 Spring MVC 프로젝트에도 통합될 수 있습니다).
Spring Security는 주로 AOP를 사용하여 리소스 요청을 가로채고 내부적으로 역할의 필터 체인을 유지 관리합니다. 마이크로서비스는 모두 게이트웨이를 통해 요청되기 때문에 게이트웨이 내 다양한 리소스의 역할 수준에 따라 마이크로서비스의 @Secured를 설정할 수 있습니다.
Spring Security는 기본 역할 확인 인터페이스 사양을 제공합니다. 단, 클라이언트가 요청한 Token 정보에 대한 암호화, 저장, 검증은 애플리케이션 자체에서 완료되어야 합니다. Redis는 토큰 암호화 정보를 저장하는 데 사용될 수 있습니다. 여기서 또 한 가지 언급할 점은 일부 암호화된 정보의 가변성을 보장하기 위해서는 내부 키가 유출되는 것을 방지하기 위해 처음에 토큰 모듈을 설계할 때 여러 버전 키를 지원하는 것을 고려하는 것이 가장 좋다는 것입니다(친구의 말을 들었습니다). 회사의 토큰 암호화 코드가 직원에 의해 공개되기 전). 암호화 알고리즘과 구체적인 구현에 관해서는 여기에서 자세히 설명하지 않습니다. 게이트웨이 인증이 통과된 후 구문 분석된 토큰 정보는 요청을 계속해야 하는 마이크로서비스 계층에 직접 전달될 수 있습니다.
애플리케이션에 인증이 필요한 경우(리소스 요청은 다양한 역할과 권한을 관리해야 함) 게이트웨이의 Rest API를 기반으로 하는 AOP 아이디어를 기반으로 수행할 수 있습니다. 인증과 승인을 통합적으로 관리하는 것도 Facade 모드와 유사한 Gateway API를 사용하는 이점 중 하나입니다.
로드 밸런싱
API Gateway는 Microservice와 마찬가지로 Springboot 애플리케이션이며 Rest API를 제공합니다. 따라서 Docker 컨테이너에서도 실행됩니다. 게이트웨이와 마이크로서비스 간의 서비스 검색에서는 위에서 언급한 클라이언트 검색 모드 또는 서버 검색 모드를 계속 사용할 수 있습니다.
클러스터 환경에서 API Gateway는 통합 포트를 노출할 수 있으며 해당 인스턴스는 다른 IP를 가진 서버에서 실행됩니다. 컨테이너 인프라로 Alibaba Cloud의 ECS를 사용하기 때문에 Alibaba Cloud의 로드 밸런싱 SLB는 클러스터 환경의 로드 밸런싱에도 사용되며 AliyunDNS는 도메인 이름 확인에도 사용됩니다. 다음 그림은 간단한 네트워크 요청의 다이어그램입니다.
실제로 서비스 포트와 리소스 주소가 노출되지 않도록 Nginx 서비스를 서비스 클러스터에 역방향 프록시 및 외부 로드로 배포할 수도 있습니다. 예를 들어, SLB는 요청을 Nginx 서버로 전달한 다음 Nginx를 통해 게이트웨이 포트로 전달할 수 있습니다. 자체 구축한 전산실에 구축한 클러스터라면 가용성이 높은 로드밸런싱 센터를 구축해야 한다. 머신 간 요청에 대처하려면 Consul, Consul(Consul 템플릿) + Registor + Haproxy를 서비스 검색 및 로드 밸런싱 센터로 사용하는 것이 가장 좋습니다.
Caching
일부 높은 QPS 요청의 경우 API Gateway에서 다단계 캐싱을 수행할 수 있습니다. 분산 캐시는 Redis, Memcached 등을 사용할 수 있습니다. 실시간 요구 사항이 높지 않고 변경 빈도가 낮지만 QPS가 높은 일부 페이지 수준 요청인 경우 게이트웨이 계층에서 로컬 캐싱을 수행할 수도 있습니다. 그리고 게이트웨이는 캐싱 솔루션을 더욱 유연하고 다양하게 만들 수 있습니다.
API Gateway의 오류 처리
Gateway의 구체적인 구현 과정에 있어서 오류 처리 역시 매우 중요한 일입니다. 게이트웨이 오류 처리의 경우 Hystrix를 사용하여 요청 회로 차단기를 처리할 수 있습니다. 그리고 RxJava와 함께 제공되는 onErrorReturn 콜백도 오류 정보 반환을 편리하게 처리할 수 있습니다. 회로 차단기 메커니즘의 경우 다음 측면을 처리해야 합니다.
서비스 요청의 내결함성 처리
합리적인 게이트웨이로서 데이터 흐름 및 이벤트 흐름 처리만 담당해야 하며, 비즈니스 로직을 처리하지 않습니다. 여러 마이크로서비스의 요청을 처리할 때 마이크로서비스 요청 시간이 초과되어 사용할 수 없게 될 수 있습니다. 일부 특정 시나리오에서는 부분 오류를 합리적으로 처리해야 합니다. 예를 들어, 위 예시의 "사용자 주문 목록"에서 "사용자" 마이크로서비스에 오류가 발생하더라도 "주문" 데이터 요청에 영향을 주어서는 안 됩니다. 이를 처리하는 가장 좋은 방법은 기본 아바타, 기본 사용자 닉네임을 표시하는 등 당시 잘못된 사용자 정보 요청에 기본 데이터를 반환하는 것입니다. 그러면 정상적인 주문 및 제품 정보를 요청하기 위한 올바른 데이터가 반환됩니다. "주문" 필드의 마이크로서비스가 비정상인 경우와 같이 주요 마이크로서비스 요청이 비정상인 경우 클라이언트에 오류 코드와 합당한 오류 메시지가 제공되어야 합니다. 이러한 종류의 처리는 시스템의 일부를 사용할 수 없을 때 사용자 경험을 개선하기 위해 시도할 수 있습니다. RxJava를 사용할 때 구체적인 구현 방법은 onErrorReturn을 작성하고 오류 데이터를 다양한 클라이언트 요청과 호환되도록 만드는 것입니다.
예외 캡처 및 녹음
Gateway는 주로 요청 전달 및 병합을 담당합니다. 문제를 명확하게 해결하고 특정 서비스 또는 Docker 컨테이너의 문제를 찾으려면 게이트웨이가 다양한 유형의 예외 및 비즈니스 오류를 캡처하고 기록할 수 있어야 합니다. FeignClient를 사용하여 마이크로서비스 리소스를 요청하는 경우 ErrorDecoder 인터페이스를 구현하여 응답 결과를 추가로 필터링하고 모든 요청 정보를 로그에 기록할 수 있습니다. Spring Rest 템플릿을 사용하는 경우 사용자 정의된 RestTempe를 정의하고 반환된 ResponseEntity를 구문 분석할 수 있습니다. 직렬화된 결과 객체를 반환하기 전에 오류 메시지를 기록합니다.
시간 초과 메커니즘
대부분의 게이트웨이 스레드는 IO 스레드입니다. 특정 마이크로서비스 요청이 차단되는 것을 방지하기 위해 게이트웨이에는 대기 스레드가 너무 많아 스레드 풀 및 대기열과 같은 시스템 리소스가 소모됩니다. 시간 초과 인터페이스에서 정상적인 서비스 저하가 수행될 수 있도록 시간 초과 메커니즘을 게이트웨이에 제공해야 합니다.
SpringCloud의 Feign 프로젝트에 Hystrix가 통합되었습니다. Hystrix는 타임아웃 처리를 위한 비교적 포괄적인 회로 차단기 메커니즘을 제공합니다. 기본적으로 시간 초과 메커니즘은 활성화되어 있습니다. Netflix는 타임아웃 관련 매개 변수 구성 외에도 Hytrix 기반의 Netflix-Dashboard 실시간 모니터링도 제공하며, Netflix-Turbine을 사용하여 클러스터 서비스만 추가 배포하면 됩니다. 일반적인 Hytrix 구성 항목은 Hytrix-Configuration을 참조하세요.
RxJava의 Observable 반응 프로그래밍을 사용하고 요청마다 다른 시간 제한을 설정하려는 경우 Observable의 timeout() 메서드 매개 변수에서 콜백 방법과 시간 제한 시간을 직접 설정할 수 있습니다.
재시도 메커니즘
일부 주요 비즈니스의 경우 요청 시간이 초과될 때 올바른 데이터 반환을 보장하기 위해 게이트웨이는 재시도 메커니즘을 제공해야 합니다. SpringCloudFeign을 사용하는 경우 내장된 리본은 spring.cloud.loadbalancer.retry.enabled=false를 설정하여 끌 수 있는 기본 재시도 구성을 제공합니다. 요청 시간이 초과되거나 소켓 읽기 시간이 초과되면 리본에서 제공하는 재시도 메커니즘이 트리거됩니다. 재시도를 설정하는 것 외에도 재시도 시간 임계값과 재시도 횟수를 사용자 지정할 수도 있습니다.
Feign 외에 Spring RestTemplate을 사용하는 애플리케이션의 경우, 요청을 재시도해야 하는 경우(예: 고정 형식 오류 코드 메서드를 사용하여 반환된 ResponseEntity 개체의 결과를 구문 분석하기 위해 사용자 정의된 RestTemplate을 사용할 수 있습니다. retry) 전략), Interceptor를 통해 요청 가로채기를 수행하고 콜백을 통해 여러 요청을 호출합니다.
요약
마이크로서비스 아키텍처의 경우 독립적인 API Gateway를 통해 통일된 요청 전달, 병합, 프로토콜 변환을 수행할 수 있습니다. 다양한 클라이언트의 요청 데이터에 보다 유연하게 적응할 수 있습니다. 또한 다양한 클라이언트(예: H5와 iOS의 표시 데이터가 다름) 및 다양한 버전과 호환되는 요청을 게이트웨이에서 잘 보호하여 마이크로서비스를 더욱 순수하게 만들 수 있습니다. 마이크로서비스는 내부 도메인 서비스 설계 및 이벤트 처리에만 집중하면 됩니다.
API 게이트웨이는 마이크로서비스 요청에 대해 특정 내결함성 및 서비스 저하를 수행할 수도 있습니다. 반응형 프로그래밍을 사용하여 API 게이트웨이를 구현하면 스레드 동기화 및 동시성 코드를 더 간단하고 쉽게 유지 관리할 수 있습니다. 마이크로서비스에 대한 요청은 FeignClint를 통해 통합될 수 있습니다. 코드는 또한 매우 계층적입니다. 아래 그림은 요청된 클래스 계층 구조의 예입니다.
Clint는 서비스 검색 통합(Eureka를 사용한 자체 등록), 로드 밸런싱, 요청 생성 및 ResponseEntity 객체 획득을 담당합니다.
Translator는 ResponseEntity를 Observable
개체로 변환하고 DDD의 부식 방지 계층 개념과 유사한 예외의 통합 로그 수집을 수행합니다. Adapter는 각 Translator를 호출하고 Observable 기능을 사용하여 요청된 데이터 스트림을 병합합니다. 여러 데이터 어셈블리가 있는 경우 어셈블러 계층을 추가하여 DTO 개체를 모델로 변환하는 작업을 구체적으로 처리할 수 있습니다.
Controller는 Restful 리소스 관리를 제공합니다. 각 컨트롤러는 고유한 어댑터 메서드만 요청합니다.
마이크로서비스의 지속적인 통합 배포
이전 글에서는 주로 마이크로서비스의 서비스 검색, 서비스 통신 및 API 게이트웨이를 소개했습니다. 전체 마이크로서비스 아키텍처의 모델이 처음에 표시됩니다. 실제 개발, 테스트 및 프로덕션 환경에서. Docker를 사용하여 마이크로서비스를 구현하는 경우 클러스터의 네트워크 환경은 더욱 복잡해집니다. 마이크로서비스 아키텍처 자체는 여러 컨테이너 서비스를 관리해야 하며 각 마이크로서비스를 독립적으로 배포, 확장 및 모니터링해야 함을 의미합니다. 다음에서는 Docker 마이크로서비스의 CI/CD(지속적 통합 배포)를 수행하는 방법을 계속 소개합니다.
Image Warehouse
Docker를 사용하여 마이크로서비스를 배포하려면 웹 서버에 배포하고 war 파일로 패키징하는 것과 마찬가지로 마이크로서비스를 Docker 이미지로 패키징해야 합니다. Docker 이미지가 Docker 컨테이너에서 실행된다는 것뿐입니다.
Springboot 서비스인 경우 Apache Tomcat 서버를 포함한 Springboot와 Java 런타임 라이브러리를 포함한 컴파일된 Java 애플리케이션이 Docker 이미지로 직접 패키징됩니다.
포장 및 유통(풀/푸시) 이미지를 통일적으로 관리하기 위해. 기업은 일반적으로 자체 개인 미러 데이터베이스를 구축해야 합니다. 구현도 매우 간단합니다. Docker 허브 미러 웨어하우스의 Registry2 컨테이너 버전을 서버에 직접 배포할 수 있습니다. 현재 최신 버전은 V2입니다.
코드 창고
코드 제출, 롤백 및 기타 관리도 프로젝트의 지속적인 통합의 일부입니다. 일반적으로 회사의 코드 웨어하우스를 위한 개인 저장소를 구축하는 것도 필요합니다. SVN 및 GIT와 같은 코드 버전 관리 도구를 사용할 수 있습니다.
현재 회사에서는 Gitlab을 사용하고 있으며 Git의 Docker 이미지를 통한 설치 및 배포 작업도 매우 편리합니다. 구체적인 단계는 docker gitlab install을 참조하세요. 신속한 빌드 및 패키징을 위해 Git과 Registry를 동일한 서버에 배포할 수도 있습니다.
프로젝트 구성
Springboot 프로젝트에서 빌드 도구는 Maven 또는 Gradle일 수 있습니다. Gradle은 Maven보다 유연하고 Springboot 애플리케이션 자체가 구성 해제 가능하므로 DSL 자체도 XML보다 간결하고 효율적이므로 Groovy 기반 Gradle을 사용하는 것이 더 적합합니다.
Gradle은 맞춤 작업을 지원하기 때문입니다. 따라서 마이크로서비스의 Dockerfile이 작성된 후 Gradle의 작업 스크립트를 사용하여 이를 Docker 이미지로 빌드하고 패키징할 수 있습니다.
Transmode-Gradlew 플러그인과 같이 Docker 이미지를 빌드하기 위한 오픈 소스 Gradle 도구도 있습니다. 하위 프로젝트(단일 마이크로서비스)용 Docker 이미지를 구축하는 것 외에도 원격 이미지 웨어하우스에 이미지를 동시에 업로드하는 것도 지원할 수 있습니다. 프로덕션 환경의 빌드 머신에서는 단일 명령을 통해 프로젝트 빌드, Docker 이미지 패키징, 이미지 푸시를 직접 실행할 수 있습니다.
컨테이너 오케스트레이션 기술
Docker 이미지가 빌드된 후에는 각 컨테이너가 서로 다른 마이크로서비스 인스턴스를 실행하기 때문에 서비스는 컨테이너 간에 격리되어 배포됩니다. DevOps는 오케스트레이션 기술을 통해 컨테이너 배포 및 모니터링을 경량화하여 컨테이너 관리 효율성을 향상할 수 있습니다.
현재 Ansible, Chef, Puppet과 같은 일부 일반적인 오케스트레이션 도구도 컨테이너를 오케스트레이션할 수 있습니다. 그러나 이들 중 어느 것도 컨테이너 오케스트레이션을 위해 특별히 설계된 것이 아니므로 스크립트를 직접 작성하고 이를 사용할 때 Docker 명령과 결합해야 합니다. 예를 들어, Ansible은 실제로 클러스터 컨테이너를 매우 편리하게 배포하고 관리할 수 있습니다. Ansible은 현재 팀에서 개발한 컨테이너 기술을 위한 통합 솔루션인 Ansible Container를 제공하고 있습니다.
클러스터 관리 시스템은 호스트를 리소스 풀로 사용하고 각 컨테이너의 리소스 요구 사항에 따라 컨테이너를 예약할 호스트를 결정합니다.
현재 Docker 컨테이너의 스케줄링 및 오케스트레이션과 관련된 비교적 성숙한 기술로는 Google의 Kubernetes(이하 k8s로 약칭), Docker 클러스터를 관리하기 위해 Marathon과 결합된 Mesos, Docker 버전 1.12.0 및 1.12.0에서 공식적으로 제공되는 Docker Swarm이 있습니다. 위에. 오케스트레이션 기술은 컨테이너 기술의 핵심 중 하나입니다. 팀에 적합한 컨테이너 오케스트레이션 기술을 선택하면 운영 및 유지 관리가 더욱 효율적이고 자동화될 수 있습니다.
Docker Compose
Docker Compose는 간단한 Docker 컨테이너 오케스트레이션 도구로, YAML 파일을 통해 실행해야 하는 애플리케이션을 구성한 후 compose up 명령을 통해 여러 서비스에 해당하는 컨테이너 인스턴스를 시작합니다. Compose는 Docker에 통합되어 있지 않으므로 별도로 설치해야 합니다.
Compose는 마이크로서비스 프로젝트의 지속적인 통합에 사용할 수 있지만 대규모 클러스터의 컨테이너 관리에는 적합하지 않습니다. 대규모 클러스터에서는 클러스터 리소스 관리 및 서비스 거버넌스를 위해 Compose를 Ansible과 결합할 수 있습니다.
클러스터에 서버가 많지 않은 경우 Compose를 사용할 수 있습니다. 주요 단계는 다음과 같습니다.
마이크로서비스 운영 환경과 결합하여 서비스의 Dockerfile을 정의합니다.
서비스 기반 Docker 작성 이미지, 포트, 운영 변수 등 -compose.yml 파일을 함께 배포할 수 있도록
를 실행하고 docker-compose up 명령을 실행하여 컨테이너 인스턴스를 시작하고 들어갑니다. 백그라운드 프로세스인 경우 docker-compose up-d를 사용하세요.
Docker Swarm
2016년 Docker 1.12 버전이 나온 후 새 버전의 Docker에는 Docker Swarm 모드가 포함되었습니다. 추가 플러그인 도구를 설치할 필요가 없습니다. 도커팀도 지난해부터 서비스 오케스트레이션 기술에 주목하기 시작했다는 것을 알 수 있다. 내장된 Swarm 모드를 통해 서비스 오케스트레이션 시장도 일부 선점하려는 의도다.
팀이 새 버전의 Docker를 사용하기 시작하면 클러스터형 컨테이너 예약 및 관리를 위해 Docker Swarm 모드를 선택할 수 있습니다. Swarm은 또한 롤링 업데이트, 노드 간 전송 계층 보안 암호화, 로드 밸런싱 등을 지원합니다.
DockerSwarm 사용 예시는 제가 이전에 작성한 문서인 docker-swarm을 사용하여 지속적 통합 클러스터 서비스 구축을 참조하세요.
Kubernetes
Kubernetes는 애플리케이션 배포, 유지 관리, 확장 메커니즘 및 기타 기능을 제공하는 Go 언어를 사용하여 구현된 Google의 오픈 소스 컨테이너 클러스터 관리 시스템입니다. 현재 k8s는 GCE, vShpere, CoreOS, OpenShift, Azure 및 기타 플랫폼에서 사용할 수 있습니다. 현재 중국의 Aliyun도 k8s 기반의 서비스 관리 플랫폼을 제공하고 있습니다. 물리적 머신이나 가상 머신을 기반으로 구축된 Docker 클러스터인 경우 k8s를 직접 배포하고 실행할 수도 있습니다. 마이크로서비스 클러스터 환경에서 Kubernetes는 머신 전반에 걸쳐 마이크로서비스 컨테이너 인스턴스를 쉽게 관리할 수 있습니다.
현재 k8s는 기본적으로 가장 강력한 오픈소스 서비스 거버넌스 기술 중 하나로 인식되고 있습니다. 주로 다음 기능을 제공합니다.
Docker
클러스터를 기반으로 하는 서비스 인스턴스의 자동 배포 및 복제는 클러스터에서 실행되며 롤링 업그레이드 및 스토리지 오케스트레이션은 물론 머신 간 컨테이너를 관리할 수 있습니다.
내장된 Docker 기반 서비스 검색 및 로드 밸런싱 모듈
K8s는 손상된 컨테이너를 교체하는 강력한 자가 복구 메커니즘을 제공하며(사용자나 개발팀도 인식하지 못한 채) 다음에서 사용할 수 있습니다. 언제든지 확장 및 축소. 컨테이너 관리를 더욱 유연하게 만듭니다.
k8s는 주로 다음과 같은 중요한 구성 요소를 통해 탄력적 컨테이너 클러스터의 관리를 완료합니다.
Pod는 Kubernetes의 가장 작은 관리 요소입니다. 하나 이상의 컨테이너가 Pod에서 실행됩니다. Pod의 수명 주기는 매우 짧으며 예약이 실패하거나 노드가 충돌하거나 기타 리소스가 재활용되면 종료됩니다.
Label은 Pod와 연결할 수 있는 키/값 저장 구조로 주로 Pod 및 그룹 서비스를 표시하는 데 사용됩니다. 마이크로서비스는 라벨 선택기(Selector)를 사용하여 포드를 식별합니다.
Replication Controller는 k8sMaster 노드의 핵심 구성 요소입니다. 언제든지 지정된 수의 Pod 복제본(복제본)이 Kubernetes 클러스터에서 실행되고 있는지 확인하는 데 사용됩니다. 즉, 자가 치유 메커니즘의 기능을 제공하며 축소 및 확장, 롤링 업그레이드에도 유용합니다.
서비스는 포드 그룹의 전략을 추상화한 것입니다. k8s 관리의 기본 요소 중 하나이기도 합니다. 서비스는 라벨을 통해 포드 그룹을 식별합니다. 생성되면 로컬 클러스터의 DNS도 생성됩니다(서비스에 해당하는 포드의 서비스 주소를 저장하기 위해). 따라서 클라이언트는 DNS를 요청하여 현재 사용 가능한 포드 집합의 IP 주소를 가져오도록 요청합니다. 그런 다음 요청은 각 노드에서 실행되는 kube-proxy를 통해 Pod 중 하나로 전달됩니다. 이 로드 밸런싱 계층은 투명하지만 현재 k8s 로드 밸런싱 전략은 그다지 완전하지 않으며 기본값은 무작위입니다.
요약
마이크로서비스 아키텍처 시스템에서 적합한 지속적 통합 도구는 팀의 운영 및 개발 효율성을 크게 향상시킬 수 있습니다. 현재 Jenkins와 유사하게 Docker용 지속적 통합 플러그인이 있지만 여전히 불완전한 부분이 많습니다. 따라서 Docker 컨테이너 오케스트레이션 기술을 구체적으로 다루는 Swarm, k8s, Mesos를 선택하는 것이 좋습니다. 또는 CD용 CI+k8s용 Jenkins와 같은 여러 기술을 결합할 수도 있습니다.
Swarm, k8s 및 Mesos는 각각 고유한 기능을 가지고 있으며 모두 컨테이너의 지속적인 배포, 관리 및 모니터링을 지원합니다. Mesos는 데이터센터 관리도 지원합니다. Docker Swarm 모드는 Docker Remote API의 호출 및 확장을 통해 기존 Docker API를 확장하여 컨테이너가 지정된 노드에서 실행되도록 예약할 수 있습니다. Kubernetes는 현재 시장에서 가장 큰 오케스트레이션 기술입니다. 많은 대기업도 k8s 제품군에 합류했습니다. K8s는 클러스터 애플리케이션의 확장, 유지 관리 및 관리에 더 유연하지만 로드 밸런싱 전략은 상대적으로 거칠습니다. Mesos는 일반적인 스케줄링에 더 중점을 두고 다양한 스케줄러를 제공합니다.
서비스 오케스트레이션을 위해서는 팀에 가장 적합한 것을 선택해야 합니다. 초기 머신 수가 적고 클러스터 환경이 복잡하지 않다면 지속적인 통합을 위해 Ansible+Docker Compose와 Gitlab CI를 사용할 수도 있습니다. .
서비스 클러스터 솔루션
기업이 처음부터 마이크로서비스 아키텍처를 배치하든, 기존 단일 애플리케이션 아키텍처에서 마이크로서비스로 마이그레이션하든 상관없이 Docker를 사용하여 마이크로서비스 애플리케이션을 배포하고 실행하는 연습을 할 때. 모두 복잡한 클러스터의 서비스 일정 관리, 조정, 모니터링 및 기타 문제를 처리할 수 있어야 합니다. 다음에서는 분산 서비스 클러스터에서 Docker를 보다 안전하고 효율적으로 사용하는 방법과 아키텍처 설계에서 고려해야 할 모든 측면을 주로 소개합니다.
로드 밸런싱
여기서 말하는 것은 클러스터에서의 로드 밸런싱입니다. 순수 서버 측 API인 경우에는 Gateway API의 로드 밸런싱을 의미합니다. Nginx의 로드 밸런싱. 현재 Alibaba Cloud의 로드 밸런싱 서비스 SLB를 사용하고 있습니다. 주된 이유 중 하나는 DNS 도메인 이름 서비스에 바인딩될 수 있다는 것입니다. 이제 막 사업을 시작하는 기업의 경우 웹 인터페이스를 통해 로드 밸런싱 가중치를 설정할 수 있으며, 이는 부분 릴리스, 테스트 및 검증, 상태 점검 모니터링 등에 더욱 편리합니다. 효율성과 운영 및 유지 관리 비용 절감 측면에서 더 적합한 선택입니다.
Nginx 또는 Haproxy를 사용하는 등 직접 7계층 로드 밸런싱을 구축하는 경우 로드 밸런싱을 담당하는 클러스터도 가용성이 높고 편리한 클러스터 모니터링, 블루-그린 배포 및 기타 기능을 제공하는지 확인해야 합니다. .
지속성 및 캐싱
관계형 데이터베이스(RDBMS)
마이크로서비스의 경우 사용되는 스토리지 기술은 주로 기업의 요구 사항을 기반으로 합니다. 비용 절감을 위해 일반적으로 Mysql 엔진을 선택하는 경우 InnoDB 엔진을 선택하는 것이 좋습니다(5.5 이전 버전에서는 MyISAM이 기본이었습니다). InnoDB는 동시성을 처리할 때 더 효율적이며 캐싱, 검색 및 기타 솔루션을 통해 쿼리 성능 격차를 메울 수도 있습니다. 데이터 복사 및 백업을 처리하기 위한 InnoDB의 무료 솔루션에는 binlog 및 mysqldump가 포함됩니다. 그러나 자동화된 백업 및 복구와 모니터링 가능한 데이터 센터를 달성하려면 DBA 또는 운영 및 유지 관리 팀이 여전히 필요합니다. 상대적 비용도 더 높습니다. 스타트업이라면 국내외의 비교적 대규모 클라우드 컴퓨팅 플랫폼에서 제공하는 PaaS 서비스에 의존하는 것도 고려해 볼 수 있습니다.
마이크로서비스는 일반적으로 사업분야에 따라 나누어져 있으므로 처음부터 마이크로서비스용 서브 라이브러리를 설계하는 것이 가장 좋습니다. 테이블 분할이 필요한지 여부는 각 마이크로서비스의 특정 사업 분야 및 데이터 규모의 발전을 기반으로 한 상세한 분석이 필요합니다. 다만, "주문" 등 상대적으로 핵심적인 영역에 속하는 모델의 경우 하위 테이블 필드를 미리 설계하고 예약해 두는 것이 좋습니다.
KV 모델 데이터베이스(키-값-스토어)
Redis는 오픈 소스 키-값 구조 데이터베이스입니다. 메모리 기반으로 효율적인 캐싱 성능을 갖추고 있으며 지속성도 지원합니다. Redis에는 주로 두 가지 지속성 방법이 있습니다. 하나는 지정된 시간 간격으로 데이터 세트의 특정 시점 스냅샷을 생성하고 지속성을 위해 메모리에서 디스크에 기록하는 RDB입니다. RDB 방식은 어느 정도 데이터 손실이 발생하지만 성능은 좋습니다. 다른 하나는 AOF입니다. 쓰기 메커니즘은 InnoDB의 binlog와 다소 유사합니다. AOF 파일 명령은 모두 Redis 프로토콜 형식으로 저장됩니다. 이 두 종류의 지속성은 동시에 존재할 수 있습니다. Redis가 다시 시작되면 AOF 파일이 먼저 데이터를 복원하는 데 사용됩니다. 지속성은 선택 사항이므로 Redis 지속성을 비활성화할 수도 있습니다.
실제 시나리오에서는 지속성을 유지하는 것이 좋습니다. 예를 들어 Redis를 사용하면 현재 널리 사용되는 SMS 인증 코드 확인 문제를 해결할 수 있습니다. 마이크로서비스 아키텍처 시스템에서 Redis는 일부 KV 데이터 구조 시나리오를 처리하는 데에도 사용할 수 있습니다. 경량 데이터 스토리지 솔루션은 경량 솔루션을 강조하는 마이크로서비스 아이디어에도 매우 적합합니다.
실제로 우리는 Redis를 캐시하고 유지하며 두 가지 기능을 별도의 라이브러리로 나눕니다.
통합 Springboot 프로젝트에서 spring-boot-starter-data-redis는 Redis 데이터베이스 연결 및 기본 구성은 물론 spring-data-redis가 제공하는 풍부한 데이터 API 작업을 수행하는 데 사용됩니다.
또한 높은 처리량이 필요한 애플리케이션인 경우 Memcached를 사용하여 간단한 KV 데이터 구조를 캐시하는 것을 고려할 수 있습니다. 대량의 데이터를 읽는 데 더 적합하지만 지원되는 데이터 구조 유형은 상대적으로 단일합니다.
그래프 데이터베이스(Graph Database)
소셜 관련 모델 데이터의 저장과 관련됩니다. 그래프 데이터베이스는 관계형 데이터베이스를 교차하는 데 더 효율적이고 유연한 선택입니다. 그래프 데이터베이스도 Nosql의 한 종류입니다. KV와는 다릅니다. 저장되는 데이터는 주로 데이터 노드(node), 방향 관계(Relationship), 노드와 관계에 대한 속성(Property)입니다.
Java를 마이크로서비스의 주요 개발 언어로 사용한다면 Neo4j를 선택하는 것이 가장 좋습니다. Neo4j는 ACID를 지원하는 Java 기반 그래프 데이터베이스입니다. 풍부한 JavaAPI를 제공합니다. 성능 측면에서 그래프 데이터베이스의 로컬 특성으로 인해 순회가 매우 빨라지며, 특히 대규모 심층 순회가 더욱 빨라집니다. 이는 관계형 데이터베이스의 다중 테이블 연결 범위를 벗어납니다.
아래 그림은 Neo4j의 WebUI 도구를 사용하여 표시되는 공식 시작하기 데이터 모델 예제입니다. 예제의 MATCH p=()-[r:DIRECTED]->() RETURN p LIMIT 25 문은 Neo4j - Cypher에서 제공하는 쿼리 언어입니다.
SpringData의 프로젝트인 Spring Data Neo4j를 프로젝트에서 사용할 때 통합할 수 있습니다. 그리고 SpringBootStartersspring-boot-starter-data-neo4j
문서 데이터베이스
현재 널리 사용되는 오픈 소스 문서 중심 데이터베이스는 Mongodb를 사용할 수 있습니다. Mongo는 특히 Json 데이터 구조 저장소에 대해 고가용성, 높은 확장성 및 유연한 데이터 구조 저장소를 갖추고 있습니다. 블로그나 댓글 등의 모델을 저장하는 데 더 적합합니다.
검색 기술
개발 과정에서 길고 복잡하며 유지 관리가 어려운 다중 테이블 쿼리 SQL이나 여러 테이블과 관련된 다양한 하위 쿼리 문을 작성하는 사람들을 종종 볼 수 있습니다. 특정 도메인 모델의 경우 이러한 시나리오가 많으면 검색 솔루션 추가를 고려해야 할 때입니다. 모든 것, 특히 쿼리 시나리오를 해결하기 위해 SQL을 사용하지 마십시오. 느린 쿼리문 문제는 DB를 다운시키는 경우도 있습니다. DB 모니터링 시스템이 갖춰져 있지 않으면 문제 해결이 어려울 수도 있습니다.
Elasticsearch는 Apache Lucene을 기반으로 하는 오픈소스 실시간 분산 검색 및 분석 엔진입니다. Springboot 프로젝트는 spring-boot-starter-data-elasticsearch 및 spring-data-elasticsearch와 같은 통합 방법도 제공합니다.
검색 클러스터를 구축하려면 Docker를 사용할 수 있습니다. 구체적인 구성 방법은 Docker를 사용하여 Elasticsearch 클러스터 구축을 참조하세요. Springboot 프로젝트 통합은 Springboot 마이크로서비스에 검색 서비스 통합을 참조하세요. 지금까지 최신 버전의 Spring Data Elasticsearch는 버전 2.x의 많은 문제점을 해결할 수 있는 ES 버전 5.x를 지원했습니다.
소규모 검색 클러스터인 경우 구성이 낮은 머신 3대를 사용한 후 ES Docker를 사용하여 구축할 수 있습니다. PaaS 서비스의 일부 상용 버전을 사용할 수도 있습니다. 선택 방법은 여전히 팀과 비즈니스
의 규모와 시나리오에 따라 다릅니다.
현재 ES 외에도 더 널리 사용되는 오픈소스 검색 엔진은 Solr입니다. Solr도 Lucene을 기반으로 하며 텍스트 검색에 중점을 두고 있습니다. ES의 텍스트 검색은 실제로 Solr만큼 좋지 않습니다. ES는 주로 분산 지원 지원에 중점을 두고 있으며 클러스터 상태를 유지하기 위해 내장된 서비스 검색 구성 요소인 Zen을 갖추고 있습니다(Zookeeper와 같은 도움이 필요함). 배포) 배포도 더 가볍습니다. ES는 쿼리 분석 외에도 로그 수집, 분석 및 처리를 통합할 수 있습니다.
Message Queue
이전 기사에서 언급했듯이 메시지 큐는 마이크로서비스에 대한 좋은 분리 통신 방법으로 사용될 수 있습니다. 분산 클러스터 시나리오에서는 분산 조건 하에서 최종 일관성에 대한 기술적 기본 보장도 제공할 수 있습니다. 또한 메시지 대기열을 사용하여 트래픽 중단을 처리할 수도 있습니다.
여기에서는 메시지 대기열 비교를 반복하지 않습니다. 이 회사는 현재 Alibaba Cloud의 ONS를 사용하고 있습니다. 메시지 대기열을 사용하려면 여전히 높은 가용성과 손쉬운 관리 및 모니터링이 필요하기 때문에 우리는 안전하고 안정적인 메시지 대기열 플랫폼을 선택했습니다.
보안 기술
보안은 아키텍처를 할 때 고려해야 할 기본입니다. 인터넷 환경은 복잡하며, 서비스의 보안을 보호하는 것도 사용자에 대한 기본적인 약속입니다. 보안 기술은 광범위한 주제를 다루고 있으며, 이 기사에서는 몇 가지 일반적인 문제와 일반적으로 사용되는 방법을 간략하게 소개합니다.
서비스 인스턴스 보안
분산 클러스터 자체가 서비스 인스턴스의 보안을 보장합니다. 서버나 특정 서비스 인스턴스에 문제가 있는 경우 로드 밸런싱을 통해 사용 가능한 다른 서비스 인스턴스로 요청을 전달할 수 있습니다. 그러나 많은 회사에서는 자체 컴퓨터실을 구축하며 단일 기계실로 구성되어 있습니다. 이러한 배치는 실제로 더 위험합니다. 서버의 백업 및 재해 복구가 완전히 보장될 수 없기 때문입니다. 가장 무서운 점은 데이터베이스도 같은 전산실에 있고, 메인 서버와 백업 서버가 모두 함께 있다는 점이다. 보안이 보장되지 않을 뿐만 아니라 일상적인 운영 및 유지 관리 비용도 상대적으로 높습니다. 또한 방화벽 보안 정책 구성에도 주의가 필요합니다.
가능하다면 가용성과 확장성이 뛰어나고 안정적인 IaaS 플랫폼을 사용해 보세요.
네트워크 보안
1. 네트워크 공격 방지
현재 몇 가지 주요 네트워크 공격이 있습니다.
SQL 주입: 지속성 계층 프레임워크에 따라 대응 전략이 다릅니다. JPA를 사용한다면 JPA의 사양을 따르는 한 기본적으로 걱정할 필요가 없습니다.
XSS 공격: 이스케이프 처리와 매개변수 검증을 잘 수행하세요. 자세한 내용은 XSS 예방
CSRF 공격: 토큰을 잘 수행하고 HTTP 헤더 정보 확인을 참조하세요. 자세한 내용은 CSRF 방지
DDOS 공격을 참조하세요. 대규모 트래픽 DDoS 공격의 경우 일반적으로 높은 방어 IP가 사용됩니다. 일부 클라우드 컴퓨팅 플랫폼의 고급 IP에 액세스할 수도 있습니다.
위에는 몇 가지 일반적인 공격만 나열되어 있습니다. 이에 대해 자세히 알고 싶다면 REST 보안 예방 표를 참조하세요. 네트워크 보안 분야에서는 일반적으로 스타트업에서 무시하기 쉽습니다. 운영 및 유지 관리 보안 팀이 없으면 Alibaba Cloud-Cloud Shield와 같은 제품을 사용하는 것이 가장 좋습니다. 걱정과 비용을 절약하세요.
2. 보안 프로토콜 사용
Restful API를 사용하는 마이크로서비스 통신용인지, CDN 또는 DNS 서비스를 사용하는지 말할 필요도 없습니다. HTTP 프로토콜의 경우 HTTPS를 균일하게 사용하는 것이 좋습니다. 애플리케이션의 크기에 관계없이 트래픽 하이재킹을 방지해야 합니다. 그렇지 않으면 사용자에게 매우 나쁜 경험을 선사할 것입니다.
3. 인증
API Gateway는 이미 마이크로서비스 인증을 도입했습니다. 마이크로서비스 자체 외에도 Mysql, Redis, Elasticsearch, Eureka 등과 같이 우리가 사용하는 일부 서비스도 인증을 설정하고 인트라넷을 통해 액세스를 시도해야 합니다. 외부 세계에 너무 많은 포트를 노출하지 마십시오. 마이크로서비스의 API 게이트웨이의 경우 인증 외에도 프런트 엔드에서는 Nginx 역방향 프록시를 통해 API 계층을 요청하는 것이 가장 좋습니다.
로그 수집 및 모니터링
컨테이너 기술을 기반으로 한 마이크로서비스의 모니터링 시스템은 더욱 복잡해진 네트워크와 서비스 환경에 직면해 있습니다. 로그 수집 및 모니터링을 통해 마이크로서비스를 개발자에게 덜 방해적이고 더 투명하게 만들 수 있는 방법은 많은 마이크로서비스 DevOps가 지속적으로 생각하고 실천하는 것입니다.
1. 마이크로서비스 로그 수집
마이크로서비스의 API 계층을 모니터링하려면 API 게이트웨이에서 각 마이크로서비스 수집 및 분석까지의 호출 경로를 추적해야 합니다. Rest API를 사용하는 경우 모든 요청을 수집하려면 Spring Web의 OncePerRequestFilter를 사용하여 모든 요청을 차단할 수 있습니다. 로그를 수집할 때 요청의 rt도 기록하는 것이 가장 좋습니다.
접속, 요청 및 기타 정보를 기록하는 것 외에도 API 호출에 대한 요청 추적도 필요합니다. 각 서비스와 게이트웨이의 로그만 기록해 둔다면 게이트웨이 로그에 예외가 발생하더라도 마이크로서비스의 어떤 컨테이너 인스턴스에 문제가 있는지 알 수 없다. 컨테이너 수가 일정 수준에 도달하면 모든 컨테이너와 서비스 인스턴스의 로그를 확인할 수 없다. 비교적 간단한 해결책은 컨테이너 정보가 포함된 고유하게 식별 가능한 추적 문자열을 로그 정보에 추가하는 것입니다.
로그를 수집한 후에도 분석이 필요합니다. E.L.K의 기술 시스템을 이용하시면 Elasticsearch의 실시간 분산 기능을 유연하게 활용하실 수 있습니다. Logstash는 로그를 수집 및 분석하고 데이터를 Elasticsearch에 동기화할 수 있습니다. Kibana는 Logstash와 ElasticSearch를 결합하여 로그 분석을 용이하게 하고 로그 데이터의 시각적 관리를 향상시키는 우수한 WebUI를 제공합니다.
많은 양의 데이터가 포함된 로그 수집의 경우 수집 성능을 향상시키기 위해 위에서 언급한 메시지 큐를 사용해야 합니다. 최적화된 아키텍처는 다음과 같습니다.
2. 기본 통화기록 수집 services
마이크로서비스의 모든 Rest API에 대한 로그 수집 및 분석을 통해 요청 정보를 모니터링할 수 있습니다.
서비스 내에서는 미들웨어 및 인프라 호출(Redis, Mysql, Elasticsearch 등 포함)에 대한 로그 수집 및 성능 분석도 필요합니다.
미들웨어 서비스의 로그 수집을 위해 현재 서비스에서 호출되는 캐시 및 리포지토리(검색 및 DB 포함)라는 기본 메소드에 대해 동적 프록시를 사용하여 가로채기 및 콜백 로깅 메소드를 사용할 수 있습니다. 특정 구현 방법은 바이트코드 생성 프레임워크 ASM을 사용할 수 있습니다. 메소드의 논리 주입에 대해서는 이전에 작성된 ASM(4) 문서를 참조하세요. ASM 코드가 동적으로 주입된다고 생각된다면. 유지 관리가 쉽지 않으므로 상대적으로 API 친화적인 Cglib를 사용할 수도 있습니다.
아키텍처의 5가지 요소:
마지막으로 아키텍처의 5가지 핵심 요소를 기반으로 Docker 마이크로서비스 아키텍처를 구축하는 데 사용하는 기술 시스템을 검토해 보겠습니다. #🎜🎜 #
- 고성능
메시지 큐, RxJava 비동기 동시성, 분산 캐시, 로컬 캐시, Http Etag 캐시, Elasticsearch를 사용하여 쿼리 최적화, CDN 등
- 가용성 컨테이너 서비스 클러스터, RxJava 회로 차단기 처리, 서비스 저하, 메시지 멱등성 처리, 시간 초과 메커니즘, 재시도 메커니즘, 분산된 최종 일관성 등
- Scalability 서버 클러스터 확장, 컨테이너 오케스트레이션 Kubernetes, 데이터베이스 하위 테이블, Nosql 선형 확장, 검색 클러스터 확장성 등
- 확장성 Docker 기반 마이크로서비스는 확장성을 위해 탄생했습니다!
- Security
JPA/Hibernate, SpringSecurity, 고급 IP, 로그 모니터링, HTTPS, Nginx 역방향 프록시, HTTP/2.0 등
이 글은 주로 Docker의 마이크로서비스 실행을 위한 기술 솔루션 선택 및 소개에 관한 것입니다. 다양한 비즈니스와 팀이 다양한 아키텍처 시스템과 기술 솔루션에 적합할 수 있습니다.
아마도 아키텍트가 처음부터 완전한 시스템을 구축하는 데는 그리 오랜 시간이 걸리지 않을 것입니다. 가장 중요한 것은 팀 내에서 도메인 중심 디자인을 지속적으로 홍보하는 것입니다. 그리고 팀이 클린 코드를 따르고 민첩한 개발 OvO를 수행할 수 있도록 합니다.
Microsoft 마이크로서비스 아키텍처 eShopOnContainers 분석
관련 동영상: #🎜 🎜#Geek Academy Docker 비디오 튜토리얼-무료 온라인 비디오 튜토리얼위 내용은 Docker의 컨테이너 기술을 사용하여 서비스 아키텍처 시스템 DevOps 레이아웃 - JAVA 아키텍처의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!