분산 데이터 관리-데이터베이스를 마이크로 서비스로 캡슐화 [닫기]

최근에 소프트웨어 디자인에 대한 과정을 밟았으며 서비스 구성 요소가 가능한 한 독립적 인 마이크로 서비스 하위 구성 요소로 분리되는 '마이크로 서비스'모델 사용에 대한 최근 토론 / 권장 사항이있었습니다.

언급 된 한 부분은 모든 마이크로 서비스와 통신하는 단일 데이터베이스를 갖는 매우 자주 보이는 모델을 따르는 대신 각 마이크로 서비스마다 별도의 데이터베이스를 실행하는 것입니다.

이에 대한 더 나은 단어와 자세한 설명은 여기에서 찾을 수 있습니다 : http://martinfowler.com/articles/microservices.html 분산 데이터 관리 섹션

가장 중요한 부분은 다음과 같습니다.

마이크로 서비스는 각 서비스가 자체 데이터베이스, 동일한 데이터베이스 기술의 서로 다른 인스턴스 또는 완전히 다른 데이터베이스 시스템 인 Polyglot Persistence라는 접근법을 관리하는 것을 선호합니다. 단일체에서 폴리 글 로티 지속성을 사용할 수 있지만 마이크로 서비스에서는 더 자주 나타납니다.

그림 4

나는이 개념이 마음에 들며, 무엇보다도 유지 관리 및 여러 사람들이 함께 작업하는 프로젝트를 강력하게 개선하는 것으로 볼 수 있습니다. 즉, 나는 결코 경험 소프트웨어 설계자가 아닙니다. 누구든지 그것을 구현하려고 했습니까? 어떤 이점과 장애물을 겪었습니까?

마이크로 서비스 접근법의 긍정과 부정에 대해 이야기 해 봅시다.

첫 번째 부정. 마이크로 서비스를 만들면 코드에 고유 한 복잡성이 추가됩니다. 오버 헤드를 추가하고 있습니다. 환경을 복제하기 어렵게 만듭니다 (예 : 개발자). 간헐적 인 디버깅 문제를 더욱 어렵게 만들고 있습니다.

실제 단점을 설명하겠습니다. 페이지를 생성하는 동안 호출 된 100 개의 마이크로 서비스가 있고 각각 99.9 %의 시간이 올바른 경우를 가정 해보십시오. 그러나 시간의 0.05 %가 잘못된 결과를 낳습니다. 그리고 0.05 %의 시간은 연결 요청에 TCP / IP 시간 초과가 필요하고 5 초가 걸리는 느린 연결 요청이 있습니다. 요청한 시간의 약 90.5 %가 완벽하게 작동합니다. 그러나 약 5 %의 시간 동안 잘못된 결과가 발생하고 약 5 %의 시간이 페이지가 느립니다. 재현 할 수없는 모든 실패에는 다른 원인이 있습니다.

모니터링, 재생 등을위한 툴링에 대해 많은 생각을하지 않는 한, 이것은 혼란스러워 질 것입니다. 특히 하나의 마이크로 서비스가 다른 마이크로 서비스를 호출하면 다른 마이크로 서비스는 몇 개의 계층을 호출합니다. 일단 문제가 생기면 시간이지나면서 악화 될뿐입니다.

좋습니다, 이것은 악몽처럼 들립니다 (그리고 한 회사 이상이이 길을 따라 가면서 스스로 큰 문제를 일으켰습니다). 성공은 당신이 잠재적 인 단점을 분명히 알고 있으며이를 해결하기 위해 지속적으로 노력하는 것만 가능합니다.

그렇다면 그 모 놀리 식 접근법은 어떻습니까?

모 놀리 식 애플리케이션은 마이크로 서비스만큼 모듈화하기 쉽다는 것이 밝혀졌습니다. 그리고 함수 호출은 실제로 RPC 호출보다 저렴하고 안정적입니다. 따라서 더 안정적이며 더 빠르게 실행되며 코드가 적게 든다는 점을 제외하고는 같은 것을 개발할 수 있습니다.

그렇다면 왜 회사가 마이크로 서비스 접근 방식으로 이동합니까?

대답은 확장 할 때 모 놀리 식 응용 프로그램으로 수행 할 수있는 작업에 제한이 있기 때문입니다. 사용자가 많거나 요청이 많으면 데이터베이스가 확장되지 않고 웹 서버가 코드를 메모리에 보관할 수없는 등의 시점에 도달합니다. 또한 마이크로 서비스 접근 방식을 통해 애플리케이션을 독립적으로 증분 업그레이드 할 수 있습니다. 따라서 마이크로 서비스 아키텍처는 애플리케이션을 확장하는 솔루션입니다.

필자의 개인적인 경험은 스크립팅 언어 (예 : Python)의 코드에서 최적화 된 C ++로 전환하면 일반적으로 성능과 메모리 사용 모두에서 1-2 배 정도 향상 될 수 있다는 것입니다. 다른 방식으로 분산 아키텍처를 사용하면 리소스 요구 사항이 크게 증가하지만 무한 확장 할 수 있습니다. 분산 아키텍처를 작동시킬 수는 있지만 더 어렵습니다.

따라서 개인 프로젝트를 시작하는 경우 모 놀리 식으로 진행하십시오. 잘하는 법을 배우십시오. (Google | eBay | Amazon | etc)이 있으므로 배포하지 마십시오. 분산 된 대기업에 상주하는 경우 회사의 운영 방식에주의를 기울이고 망치지 마십시오. 전환을해야한다면, 매우 잘못하기 쉬운 일을하기 때문에 조심해야합니다.

공시, 저는 모든 규모의 회사에서 약 20 년의 경험을 가지고 있습니다. 그리고 그렇습니다. 모 놀리 식 아키텍처와 분산 아키텍처가 모두 가깝고 개인적으로 보였습니다. 분산 마이크로 서비스 아키텍처는 실제로는 깨끗하고 나은 것이 아니라 필요하기 때문에해야 할 일이라는 것을 그 경험에 근거하고 있습니다.

나는 btilly의 답변에 진심으로 동의하지만 Microservices에 또 다른 긍정적 인 것을 추가하고 싶었습니다.

마이크로 서비스 세계에서 서비스는 도메인에 맞춰지고 별도의 팀이 관리합니다 (한 팀이 여러 서비스를 관리 할 수 ​​있음). 즉, 각 팀은 다른 버전과는 별도로 서비스를 완전히 분리 할 수 ​​있습니다 (올바른 버전 관리 등을 가정).

그것이 사소한 이익처럼 보일 수도 있지만, 모 놀리 식 세계에서는 그 반대를 고려하십시오. 여기에서 응용 프로그램의 한 부분을 자주 업데이트해야하는 경우 전체 프로젝트 및 작업중인 다른 팀에 영향을 미칩니다. 그런 다음 일정, 검토 등을 소개해야하며 전체 프로세스 속도가 느려집니다.

따라서 규모 요구 사항을 고려할뿐 아니라 원하는 팀 구조도 고려하십시오. 나는 Monolithic을 시작한 다음 Microservices가 도움이 될 수있는 곳을 나중에 식별 할 수있는 btilly의 권고에 동의합니다. 그러나 확장 성이 유일한 이점은 아니라는 점에 유의하십시오.

나는 상당한 양의 독립 데이터 소스가있는 곳에서 일했습니다. 그들은 그것들을 모두 단일 데이터베이스에 넣었지만 웹 서비스가 액세스 한 다른 스키마에 넣었습니다. 아이디어는 각 서비스가 업무 수행에 필요한 최소한의 데이터에만 액세스 할 수 있다는 것이 었습니다.

모 놀리 식 데이터베이스와 비교할 때 오버 헤드가 많지 않았지만 이것이 이미 분리 된 그룹에있는 데이터의 특성 때문인 것으로 생각합니다.

웹 서비스는 페이지를 생성 한 웹 서버 코드에서 호출되었으므로 마이크로 서비스 아키텍처와 매우 유사하지만 단어가 제안하고 배포하지는 않았지만 마이크로 소프트웨어 아키텍처와 비슷하지는 않습니다. 타사 서비스에서 데이터를 가져 와서 분산 데이터 서비스 인스턴스가 1 개있었습니다. 이 작업을 수행 한 회사는 규모보다 보안에 더 관심이 있었지만 이러한 서비스와 데이터 서비스는 악용 가능한 결함이 전체 시스템에 완전히 액세스 할 수 없다는 점에서보다 안전한 공격 표면을 제공했습니다.

그의 훌륭한 Objectwatch 뉴스 레터의 Roger Sessions는 그의 Software Fortresses 개념과 비슷한 내용을 설명했습니다 (불행히도 뉴스 레터는 더 이상 온라인 상태가 아니지만 책을 구입할 수 있습니다).