JavaRush /Java Blog /Random-KO /Java 마이크로서비스 가이드. 2부: 배포 및 테스트

Java 마이크로서비스 가이드. 2부: 배포 및 테스트

Random-KO 그룹에 게시되었습니다
Java 마이크로서비스 번역 및 적용 : 실용 가이드 . 가이드의 첫 번째 부분 에 대한 링크입니다 . Java 마이크로서비스 가이드.  2부: 배포 및 테스트 - 1모든 서버 측 Java 프로그램, 즉 모든 마이크로서비스는 확장자가 .jar 또는 .war인 파일일 뿐입니다. Java 생태계, 즉 JVM에는 한 가지 좋은 점이 있습니다. Java 코드를 한 번만 작성하면 최신 버전의 Java로 코드를 컴파일하지 않는 한 거의 모든 운영 체제에서 실행할 수 있다는 것입니다. 대상 JVM 버전 . 특히 Docker, Kubernetes 또는 (드럼 롤!) 클라우드와 같은 주제와 관련하여 이를 이해하는 것이 중요합니다. 왜? 다양한 배포 시나리오를 살펴보겠습니다.

최소한의 Java 마이크로서비스 배포 예

계속해서 은행 사례를 살펴보겠습니다. 따라서 monobank.jar 파일(모놀리스)과 새로 추출된riskengine.jar(최초의 위험 검사 마이크로서비스)이 있습니다. 또한 전 세계의 다른 모든 애플리케이션과 마찬가지로 두 애플리케이션 모두 .properties 파일이 필요하다고 가정해 보겠습니다. 우리의 경우에는 데이터베이스 URL과 자격 증명만 포함됩니다. 최소 배포는 다음과 같은 두 개의 디렉터리로 구성될 수 있습니다.

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...
두번째:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...
그러면 .properties 및 .jar 파일이 어떻게 서버에 전달됩니까?라는 질문이 남아 있습니다. 불행하게도 많은 답이 있을 수 있습니다.

빌드 도구, SSH 및 Ansible을 사용하여 Java 마이크로서비스를 배포하는 방법

지루하지만 Java 마이크로서비스 배포 방법에 대한 탁월한 조언... 실제로 시스템 관리자가 지난 20년 동안 회사에 Java 서버 프로그램을 배포한 방식과 똑같습니다. 이것은 혼합입니다:
  • 선호하는 빌드 도구(Maven, Gradle)
  • .jars를 서버에 복사하기 위한 좋은 오래된 SSH/SCP
  • 배포 스크립트 및 서버를 관리하는 Bash 스크립트
  • 또는 더 나은 방법: 일부 Ansible 스크립트.
물론 이는 "숨쉬는" 클라우드, 자동 로드 밸런싱 기능이 있는 서버 등이 필요한 혁신가에게는 적합하지 않습니다. 이것은 정말 지루한 올드 스쿨입니다. 그러나 작동합니다!

Docker를 사용하여 Java 마이크로서비스를 배포하는 방법

선택의 달콤한 고뇌로 돌아가자. 몇 년 전 Docker가 컨테이너화와 함께 등장했습니다. 사용해 본 적이 없다면 최종 사용자와 개발자를 대상으로 한 간단한 설명을 참조하세요.
  • 컨테이너(간소화)는 기존의 좋은 가상 머신과 유사하지만 "더 가볍습니다". 이 맥락에서 "더 쉽다"는 것이 무엇을 의미하는지 확실하지 않다면 Stackoverflow에서 이 답변을 확인하세요 .
  • 컨테이너는 자체적인 이동성을 보장합니다. 즉, 어디서나 작동합니다. 친숙한 것 같지 않나요?
Java 마이크로서비스 가이드.  2부: 배포 및 테스트 - 2JVM의 이식성과 이전 버전과의 호환성을 고려할 때 이 기능이 그렇게 큰 장점으로 보이지 않는다는 것은 우스운 일입니다. Raspberry Pi(또는 휴대폰)에서 JVM.zip을 다운로드하고 추출한 후 .jar 파일을 실행할 수 있습니다. 버전 비호환성이나 배포 설정이 더 복잡한 PHP나 Python과 같은 언어에서는 상황이 달라집니다. 또는 Java 애플리케이션이 설치된 다른 많은 서비스(올바른 버전 번호 포함)에 의존하는 경우(예: Postgres 데이터베이스 또는 Redis 키 값 저장소) 따라서 Java 마이크로서비스용 Docker, 더 정확하게는 Java 애플리케이션용 Docker의 주요 장점은 Testcontainers 와 같은 도구를 사용하여 균질화된 테스트 또는 통합 환경을 설정하는 기능입니다 . 복잡한 개발은 설치가 더 쉽습니다. Discourse 포럼 소프트웨어를 사용해 보세요 . 단일 Docker 이미지로 설치할 수 있으며, 여기에는 Ruby로 작성된 Discourse 소프트웨어부터 Postgres 데이터베이스, Redis 및 주방 싱크대까지 필요한 모든 것이 포함되어 있습니다. 배포가 유사하거나 작은 Oracle 데이터베이스를 실행하고 싶다면 Docker를 사용해 보세요. 요약하자면, .jar 파일만 보는 대신 이제 다음을 수행할 수 있습니다.
  • jar 파일을 Docker 이미지로 묶습니다.
  • 이 이미지를 개인 Docker 레지스트리에 푸시
  • 대상 플랫폼에서 이 이미지를 가져와서 실행하세요.
  • 또는 Docker 이미지를 프로덕션 시스템에 직접 복사하여 실행하세요.

Docker Swarm 또는 Kubernetes를 사용하여 Java 마이크로서비스를 배포하는 방법

Docker를 사용해 보기로 결정했다고 가정해 보겠습니다. Java 마이크로서비스를 배포할 때마다 .jar 파일을 번들로 묶는 Docker 이미지를 생성합니다. 이러한 Java 마이크로서비스가 두 개 있고 이러한 서비스를 여러 시스템(클러스터 내)에 배포하려고 한다고 가정해 보겠습니다. 질문이 생깁니다: 이 클러스터를 어떻게 관리할 것인가? Docker 컨테이너 실행, 성능 확인, 업데이트 배포, 시스템 확장(brrr)? 이 질문에 대한 두 가지 가능한 대답은 Docker Swarm과 Kubernetes입니다. 두 옵션 모두에 대해 자세히 설명하면 이미 긴 튜토리얼이 너무 길어질 수 있지만, 두 옵션 모두 궁극적으로 클러스터를 관리하기 위해 YAML 파일 작성( Yaml 들여쓰기에 대한 스토리 참조)에 의존한다는 점을 언급하는 것이 중요하다고 생각합니다 . 이것이 실제로 어떤 감정을 불러일으키는지 알고 싶다면 트위터 검색에 비슷한 검색어를 입력해 보세요. 따라서 Java 마이크로서비스의 배포 프로세스는 이제 다음과 같습니다.
  • Docker Swarm/Kubernetes 구성 및 관리
  • Docker의 모든 단계(위 참조)
  • 모든 것이 제대로 작동할 때까지 눈물이 나올 때까지 YAML을 작성하고 실행하세요 .

Java 마이크로서비스를 테스트하는 방법

프로덕션 환경에서 마이크로서비스를 구현하기로 결정했다고 가정해 보겠습니다. 지금 개발 중에 n-microservices 통합을 어떻게 테스트할 수 있나요? 워크플로의 일부가 아닌 전체 워크플로가 작동하는지 어떻게 확인할 수 있나요? 실제로는 다음 세 가지 방법 중 하나를 사용할 수 있습니다.
  1. 약간의 작업만 하면(Spring Boot와 같은 프레임워크를 사용하는 경우) 모든 마이크로서비스를 하나의 시작 클래스로 결합하고 단일 Wrapper.java 클래스를 사용하여 모든 마이크로서비스를 로드할 수 있습니다. 이는 머신에 메모리가 충분한지 여부에 따라 다릅니다. 모든 마이크로서비스를 실행하세요.
  2. Docker Swarm 또는 Kubernetes 설정을 로컬로 복사할 수 있습니다.
  3. 더 이상 로컬에서 통합 테스트를 실행하지 마세요. 대신 전용 DEV/TEST 환경을 배포하세요. 이는 로컬 마이크로서비스 설정의 어려움에 굴복한 꽤 많은 팀이 실제로 수행하는 작업입니다.
또한 Java 마이크로서비스 외에도 실행 중인 메시지 브로커(예: ActiveMQ 또는 RabbitMQ)나 이메일 서버 또는 Java 마이크로서비스가 서로 통신하는 데 필요한 기타 메시징 구성 요소가 필요할 수도 있습니다. 이로 인해 DevOps 측면의 복잡성이 크게 과소평가됩니다. 마이크로서비스 테스팅 라이브러리를 살펴보면 이러한 고통을 완화할 수 있습니다. 어쨌든 이러한 복잡성으로 인해 지금 당장 이야기할 마이크로서비스의 일반적인 문제가 발생하게 됩니다. 마지막 부분 에서는 Java 마이크로서비스에 대한 일반적인 질문을 다룹니다.
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION