어떻게 멱등성을 통해 더욱 탄력적인 마이크로서비스를 해제합니까

개발 환경 외에 멱등어를 사용할 때, 그것은 재미있는 단어이다.사실 이것은 수학에서 온 용어다.그것은 여러 번 조작할 수 있고 매번 같은 값이 발생하는 요소를 묘사한다.예를 들어 전통적인 곱셈에서의 연산1 * 1은 항상 발생한다1.
발전 분야에서 정의는 거의 같다.
멱 등의 마이크로서비스에 대해 같은 입력을 주면 같은 출력을 만들어야 한다.또는 다시 말하면 논리가 여러 번 호출되고 부작용만 발생할 수 있다면 멱등이다.
우리는 모든 독특한 호출의 부작용을 탐구해 봅시다.

모든 유일한 호출은 부작용이 있다

위의 1 * 1를 예로 들면 저희 서비스는 두 개의 입력 n1 과 n2 을 받고 n1 * n2 으로 돌아갈 수 있습니다.

function runMultiply(n1, n2) {
  return n1 * n2;
}

이곳의 부작용은 곱셈 연산이다. 이것은 우리 서비스의 논리다.현재 상태에서 호출runMultiply할 때마다 이런 부작용이 발생한다.입력이 변하지 않더라도 n1 = 1 and n2 = 1 작업을 실행하고 값n1 * n2을 되돌려줍니다.우리의 서비스는 멱등이지만, 그것은 모든 유일한 호출에 부작용을 일으킬 수 있습니까?
우리의 최근 정의에 따르면, 아니, 아니오.이런 간단한 곱셈 서비스에 대해 말하자면, 이것은 결코 세계의 종말이 아니다.새로운 자원을 만들거나 기존 자원을 업데이트하거나 복잡한 알고리즘을 실행하지 않습니다.따라서 중복 요청의 논리 재실행에는 아무런 영향이 없다.

멱등성은 바로 한 번의 의미를 의미하는가?아니오
우리가 곱셈 예시에서 본 바와 같이, 우리는 멱등 서비스를 가질 수 있는데, 그것은 정확한 의미가 없다.서비스가 무상태일 때, 왕왕 이런 상황이 발생한다.그것들은 우리가 1 에서 본 바와 같이 일부 입력을 받아들이고 무상태 조작을 실행한다.
한 가지 예를 들자. 그것은 정확한 의미에 대한 수요를 설명한다.
만약에 우리의 마이크로서비스가 데이터베이스에서 runMultiply 기록을 만드는 것을 책임진다고 가정하자.우리 서비스의 입력은 이름, 주소, 전화번호일 수 있습니다.우리의 서비스를 처음 호출할 때, 우리는 이 이름, 주소, 전화번호 조합을 위해 새로운 Person 기록을 만들 것이다.

function createPerson(name, address, phoneNumber) {
  const person = { name: name, address: address, phoneNumber: phoneNumber };
  // insert person into database
  return person;
}

만약 우리가 이 서비스에 대해 어떠한 다른 일도 하지 않는다면, 그것은 멱등입니까?
사실은 그렇지 않다.동일한 입력 (이름, 주소, 전화번호) 을 사용하여 두 번째 호출을 하면 또 다른 새로운 Person 을 만들 수 있습니다.같은 입력으로 이 서비스를 여러 번 호출하면 중복된 인원이 생성됩니다.
멱등을 복원하는 방법은 이 값이 이미 존재하는지 확인하는 것이다Person.만약 그렇다면, 새로운 것을 만들지 말고, 이미 존재하는 사람으로 돌아가지 마세요.기존 대상이 없으면 새 대상을 만들고 성공으로 돌아갑니다.
이것은 부작용 하나만 발생할 수 있다는 것을 보증한다.이름, 주소, 전화번호의 유일한 조합은 한 명만 만들 수 있다는 얘기다.

멱등의 장점

그러면 멱은 우리를 위해 무엇을 잠금 해제해 주었을까, 그렇지 않았다면 우리는 무엇을 놓쳤을까?우리의 서비스가 멱등일 때 많은 이익을 실현할 수 있다.하지만 세 가지 관건에 주목하자.

탄력성: 우리는 모든 호출을 재방송할 수 있을 뿐만 아니라 중복 호출이 새로운 부작용을 일으키지 않도록 보장한다.이것은 모든 종류의 시스템에서 매우 크다. 왜냐하면 오류가 발생하면 간단하게 다시 호출할 수 있다는 것을 의미하기 때문이다.

병행 처리: 흔히 무시되는 장점은 우리가 여러 개의 호출을 병행 처리할 수 있다는 것이다.만약 그 중 하나가 실패한다면 상관없다. 왜냐하면 우리는 신축성이 있기 때문에 다시 시도할 수 있기 때문이다.

데이터 일치성: 매번 유일하게 호출되는 부작용만 보장함으로써 우리는 데이터의 일치성을 보장할 수 있다.이것은 우리가 불완전하게 호출된 중복 기록이나 오류 데이터가 없다는 것을 의미한다.

신축성은 이곳에서 연마하는 관건적인 우세다.실패한 호출을 다시 시도할 수 있게 함으로써 우리는 확장성과 성능의 새로운 세계를 열었다.분포식 시스템에서 수십 개의 마이크로서비스가 서로 상호작용하고 탄력성을 가지는 것은 커다란 승리이다.

결론

멱등은 듣기에 매우 복잡하고 좀 번거롭다.그것의 실현은 매우 복잡할 수 있지만, 그 핵심 사상은 건전하다.중복 호출을 처리할 수 있는 서비스를 구축하는 동시에 부작용만 발생합니다.만약 우리가 이 정의를 우리의 지침으로 기억한다면, 우리는 새로운 서비스를 실현하거나 기존 서비스를 업데이트할 때 그것을 인용할 수 있다.
마침 한 번에 고장 복구 능력을 갖춘 시스템을 구축할 수 있다는 뜻이다.이것은 단일 호출이 서비스와 클라이언트 간의 업무를 충당하기 때문이다.만약 이 호출이 새것이라면 서비스는 완전한 논리를 실행할 것이다.만약 이 호출이 새로운 것이 아니라면, 서비스는 여전히 성공할 것이지만, 두 번째 부작용은 발생하지 않을 것이다.

제 다른 항목을 보고 싶으세요?

저는 DEV 커뮤니티의 슈퍼 팬입니다.만약 어떤 문제가 있거나 재구성과 관련된 다른 생각을 이야기하고 싶거나 아래에 논평을 드리겠습니다.
블로그 외에 나는 하나 Learn AWS By Using It course 를 만들었다.본 과정에서 우리는 아마존 인터넷 서비스를 중점적으로 배우고 이를 실제적으로 이용하여 정적 사이트를 위탁 관리하고 보호하며 납품한다.이것은 간단한 문제입니다. 많은 해결 방안이 있지만 AWS에 대한 이해를 높이기에 매우 적합합니다.최근에 나는 과정에서 두 개의 새로운 추가 장과 절을 추가했는데 중점은 인프라 시설의 코드와 연속 배치이다.
나는 또 자신의 매주 시사 통신을 계획한다.Learn By Doing newsletter 매주 좋은 클라우드, 코딩, DevOps 글이 많아요.등록하여 받은 편지함에 넣습니다.