마이크로 서비스 및 공유 라이브러리

9

우리는 독립적 인 마이크로 서비스 (RapidMq 버스를 통해 연결된)를 기반으로 시스템을 설계하고 있습니다. 코드는 (최소한 구성 요소의 경우) python (python2 및 python3)으로 작성됩니다. 우리는 이미 마이크로 서비스로 리팩토링하고 확장하려는 일부 비즈니스 로직을 구현하는 단일 응용 프로그램을 가지고 있습니다. 나를 걱정하는 한 가지 질문은 다음과 같습니다.

다른 마이크로 서비스간에 코드를 공유하는 가장 좋은 방법은 무엇입니까? 우리는 여러 마이크로 서비스에서 사용해야하는 공통 도우미 기능 (데이터 처리, 로깅, 구성 구문 분석 등)이 있습니다.

마이크로 서비스 자체는 별도의 프로젝트 (git repositories)로 개발 될 예정입니다. 공통 라이브러리도 자체 포함 된 프로젝트로 개발할 수 있습니다. 마이크로 서비스간에 이러한 라이브러리를 어떻게 공유합니까?

몇 가지 접근 방식이 있습니다.

각 마이크로 서비스에 필요한 라이브러리 버전을 복사하고 필요에 따라 업데이트
공용 라이브러리를 내부 PyPi에 릴리스하고 해당 라이브러리를 마이크로 서비스 요구 사항의 종속성으로 나열
라이브러리 저장소를 자식 서브 모듈로 포함

진행 방법을 결정하기 전에 제안 된 접근 방식, 모범 사례, 과거 경험에 대해 조금 더 읽고 싶습니다. 당신은 어떤 제안이나 링크가 있습니까?

python microservices

— blueFast
소스

나는 잘 대답 (내 회사는 최근 비슷한 일을 시작했다)하지만, microservices 자신을 충분히 정통한 아니에요 여기 당신이 묘사하는 것은 붉은 깃발 이유에 프레젠테이션에 대한 링크이며, "분산 기둥"으로 이어질 수 있습니다 . 마이크로 서비스에는 공유 라이브러리가 필요하지 않아야합니다. 그들은 실제로 Swagger (현재 Open API ) 와 같이 잘 정의 된 API 사이에서만 통신해야합니다 .

— Captain Man

@CaptainMan : 물론입니다. 그러나이 간단한 기능을 가지고 있다고 가정 해 봅시다 fib(n)(피보나치 시리즈의 구현). 각 마이크로 서비스에서 해당 구현을 반복하고 싶지 않습니다. 이것은 utils라이브러리에 속합니다 (기능 및 버그 수정 버전). 그것은 분산 된 모놀리스가 아니라 공통 기능의 계층 일뿐입니다. 내 질문은 구현 수준 에서이 계층을 처리하는 방법입니다.

— blueFast

당사의 마이크로 서비스는 동일한 방식으로 시스템의 다른 모든 마이크로 서비스와 통신 할 수 있도록 라이브러리를 공유했습니다. 비공유 라이브러리로 어떻게 할 수 있는지 잘 모르겠습니다. 최소한 모든 사람은 XML / JSON / etc 조작 라이브러리가 필요합니다. 나는 그 프레젠테이션을 아직 보지 않았지만, 내가 생각하는 것보다 "공유 라이브러리"에 대해 더 구체적인 의미를 가지고 있었습니까?

— Ixrec

1

@ jeckyll2hide 우리는 C ++을 사용하고 있지만 이것에 대한 우리의 인프라는 두 번째 요점과 거의 같습니다. 개별 리포지토리, 모든 사람이 종속성을 선언하고 빌드시 이러한 종속성을 찾는 방법을 알고있는 표준 빌드 시스템 등

— Ixrec

1

나는 더미처럼 느낍니다. 당신은 실제로 라이브러리를 공유하는 마이크로 서비스에 관한 것이 아니라 팀의 라이브러리를 팀과 공유하는 방법에 대해 묻는 것입니다. 답변을 게시 할만큼 충분히 알고 있습니다.

— Captain Man

5

두 번째 옵션은 분명히 갈 길입니다. 공통 라이브러리를 분리하여 로컬 PyPi 서버에 설치하십시오.

라이브러리 1의 개선은 라이브러리를 사용할 수있는 다른 사람에게 전파하기가 어렵 기 때문에 옵션 1은 끔찍합니다.

옵션 3은 옵션 1과 유사합니다.

일반적인 패턴은 Jenkins를 설정하여 라이브러리 저장소의 마스터로 푸시 할 때 파이썬 빌드를 수행하고 PyPi 저장소에 자동으로 업로드하는 것입니다. 이 빌드 스크립트를 작성하면 라이브러리를 패키징하고 PyPi에 수동으로 업로드하는 것에 대해 걱정할 필요가 없습니다. 이 옵션을 사용하면 모든 라이브러리 업데이트를 즉시 사용하여 다른 마이크로 서비스로 업그레이드 할 수 있습니다.

자신의 PyPi 서버를 설정하는 것은 매우 쉽습니다. 나는 이 가이드를 좋아 한다

— 나사 돌리개
소스

1

옵션 2가 가장

— 좋다는

@ 8bittree : 예, 옵션 3은 옵션 2와 유사하지만 git 서버 ( "중앙"원격)를 패키지 배포 메커니즘으로 사용합니다. 한편으로는 git을 사용하지 않는 것 (종속성 관리)으로 사용하는 반면, 구성 요소의 수를 줄입니다 (개인 PyPi 필요 없음)

— blueFast

2

파이썬 사람은 아니지만 PyPi 서버가 가장 좋은 옵션 인 것 같습니다. 빠른 인터넷 검색은 팀의 Java jar에 대한 Nexus 리포지토리와 유사한 모양을 제공합니다.

선택한 종속성 관리 도구가 작업 (읽고 배포) 할 수있는 일종의 중앙 저장소 (사무실 / 팀)에 배포되는 한 좋은 옵션입니다.

옵션 1은 실제로 최악이며 종속성을 수동으로 처리 할 필요가 없습니다. 고통입니다. 대학에서 Maven을 알기 전에 Git이 너무 복잡하다고 생각했을 때 모든 사람의 코드 병합에서 클래스 경로 설정, 종속성 파악에 이르기까지 모든 작업을 수동으로 수행했습니다. 고통이었고, 특히 효율성이 중요한 작업 환경에서 누군가가 그 문제의 일부조차 겪지 않기를 진지하게 원하지 않을 것입니다.

옵션 3은 잘 작동하지만 로컬 PyPi에 비해 실질적인 이점은 없습니다 (설정하기가 쉽지만 실제 의존성 관리 시스템의 이점은 훨씬 낫습니다).

— 선장
소스

1

우선 모놀리스를 마이크로 서비스로 분리하는 것은 항상 어려울 것입니다. 이유에 대한 아이디어는 분산 데이터 관리-데이터베이스를 마이크로 서비스로 캡슐화를 참조하십시오 .

즉, 상대적으로 산만하게하는 방법에 대한 몇 가지 요리법이 있습니다. 그중 하나가 http://12factor.net/ 입니다. 즉, 각 라이브러리와 응용 프로그램을 독립적으로 유지 관리하고 종속성을 명시 적으로 관리해야한다고 말할 수 있습니다. 그 경로로 가면 모든 종속성을 현재 상태로 업데이트하는 간단한 명령을 사용하고 각 마이크로 서비스마다 정기적으로 실행하는 것이 좋습니다. 프로덕션 환경에서 라이브러리 버전을 잠그는 정상 릴리스 프로세스가 있어야합니다. 그러나 당신은 정말로, 정말로 , 의존성이 오래되고 어떤 것이 있는지 알지 못하는 위치에 있기를 정말로 원하지 않습니다.

또한 백업 라이브러리를 가능한 한 단단하고 집중적으로 만드는 데 집중하십시오. 쉽게 공유 할 수 있도록 핵심 라이브러리에 물건을 추가하기 시작하는 것은 당연한 일입니다. 그렇게하면 기존 스파게티의 전체 공을 공유 라이브러리로 빠르게 가져 와서 현재 가지고있는 엉망으로 효과적으로 돌아갈 수 있습니다. 따라서 다른 방법으로 과도하게 수정하는 것이 좋습니다.

— btilly
소스

0

Python 패키지 의존성 파일에서 라이브러리를 포함하는 개인 GitHub 저장소를 직접 가리켜 서버리스로 이동할 수 있어야합니다. Pipenv와 Poet은 이것을 지원합니다.

— 개 날씨
소스