유한 상태기의 실제 응용

분산 시스템 아키텍처의 FSM 사용을 다루는 일련의 기사 중 첫 번째입니다.우리는 지역, 사무, 전설을 토론할 것이다.하지만 기초부터 시작하자.

유한 상태기

유한 상태기를 생각할 때 우리는 컴퓨터 과학과 관련된 실체, 수학, 도표를 상상할 수 있다.

과학 언어를 제외하고 유한상태기는 상태와 상태 사이의 전환의 최종 집합이다.실제 프로젝트와 관련이 있을 때 상태는 하나의 일치된 상태이고 이런 상태에서 모델은 할 수 있다.일반적으로 집합은 방대하지 않다. 100개의 상태를 가진 FSM은 매우 복잡한 코드를 초래할 수 있다.내 경험에 따르면 가장 간단한 모델은 세 개, 가장 복잡한 모델은 20~30개이다.
각 상태는 현재 시각 모델의 실제 상태를 나타냅니다.중요 프롬프트: 상태를 완전하게 설명해야 합니다. 즉, 상태 필드에서만 현재 모델 상태를 식별해야 합니다.상태를 식별하기 위해 추가 속성을 검사해야 한다면 FSM이 정교하지 않습니다.
변환은 모델(또는 클래스, 필드 등)의 논리로 현재 상태에 달려 있다.그래서 지금 당신의 모델이 해야 할 일은 모두 그의 현재 상태에 달려 있다. 마치 현실 세계의 일과 같다.

실제 FSM

너는 왜 우리가 이야기하는 것이 너무 과학적으로 보이고, 너의 코드를 어떤 범위 내에서 강요하는지 알고 싶을지도 모른다.비록 너는 여전히 같은 논리를 실현할 수 있지만, 어떤 이상한 도표도 필요없다.이것은 아주 좋은 문제입니다. 우리는 대답할 것입니다.
이 예를 보여 주세요.예를 들면, 우리는 수공 가구 작업장과 상점이 하나 있다.그래서 고객은 주방을 위해 특제 탁자를 주문했다.다음 단계를 완료해야 합니다.

주문서 접수;

고객에게 비용을 받는다.

작업장에서 표를 작성하도록 요구한다.

완성 후 작업대를 창고로 옮기도록 일꾼에게 요구한다.

운송회사에 표를 창고에서 고객에게 교부하도록 명령한다.

이것은 보기에는 매우 단도직입적이지만, 마귀는 세부 사항에 있다.이 작업은 오래 지속되므로 동일한 API 호출에서만 수행할 수 없습니다.일반적인 요청 처리 시간은 1초가 부족하지만 주문서를 완성하는 데 몇 주가 걸릴 수 있습니다.운동 부품의 수량과 관련이 있기 때문에 정확한 시간을 계산할 수도 없다.
따라서 주문 이행 기간에 이정표를 저장해야 합니다.저장은 데이터베이스에 저장을 의미합니다.여기서 우리가 토론한 것은 주문 모델이다.

type Order struct {
    ID       string
    ClientID string
    Detais   Details
    State    State
}

가장 간단한 주문에는 고유한 ID, 고객 ID, 주문 상세 정보(예: 배송 주소, 비용, 위치 등)가 있습니다.우리는 속성 State 을 추가했고, 그것에 대해 상세하게 토론할 것이다.

FSM 기술 사용 절차

이 프로세스에는 다음 단계(많거나 적음)가 포함됩니다.

현재 우리는 우리의 주문서를 위해 상태 목록을 준비할 수 있다.각 단계는 연관된 순서 상태를 통해 표시됩니다.

type State string

const (
    OrderCreated         State = "order_created"
    PaymentPending       State = "payment_pending"
    ManufacturingPending State = "manufacturing_pending"
    StockMovePending     State = "stock_pending"
    DispatchPending      State = "dispatch_pending"
    DeliveryPending      State = "delivery_pending"
    ConfirmationPending  State = "confirmation_pending"
    OrderConfirmed       State = "order_confirmed"
)

우리는 "order_accepted" 또는 "order_delivered" 같은 상태를 호출하지 않고 "payment_pending"와 "confirmation_pending"를 호출합니다."order_accepted"가 국가를 대표하는 것이 아니라 과거의 사건을 대표하기 때문이다.우리는 이벤트를 사용하여 상태 전환을 촉발할 수 있지만, 상태는 반드시 실제 세계의 상태를 묘사해야 한다.
주문에 성공한 후, 우리는 반드시 고객의 은행 계좌에서 비용을 받아야 한다.이것은 주문서의 현재 상태입니다. 지불을 기다리거나 "payment_pending".완성된 후, 우리는 주문서를 작업장으로 보내서 생산이 완성되기를 기다릴 것이다.이런 상황에서 국가"order_paid"도 중요하지 않을 것이다. 이것은 성공적으로 돈을 지불한 사건이지만, 국가는 목수가 이 탁자를 완성하기를 기다리고 있다.
그래서 지금 우리는 약간의 책벌레가 있어서 상태도를 그릴 수 있다.

따라서 우리는 우리의 과정을 유한상태기로 명확하게 묘사할 것이다.사실상, 이것은 파이프 모델로, 어느 단계가 어느 순서대로 운행될지 정의한다.그러나 FSM은 모든 단계에서 검증을 명확하게 정의하고 모든 단계(또는 상태)의 논리적 결합을 명확하게 할 수 있기 때문에 프로그래밍할 때 전체 서열을 기억할 필요가 없다.
이제 우리는 이 예를 깊이 있게 탐구합시다.

파이프뿐만 아니라.

현실 생활에서 일은 때때로 잘못될 수 있다.네가 소프트웨어를 개발할 때, 많은 부분이 잘못될 수 있다.다시 말하면, 너는 반드시 잘못과 실패를 처리해야 한다.
동기화 HTTP 요청을 처리할 때 오류 처리는 간단합니다.단일 데이터베이스 업무에 넣고 오류가 발생했을 때 변경 사항을 스크롤할 수 있습니다.또한 HTTP 클라이언트에게 오류를 간단하게 되돌려줄 수 있으며, 정리, 보상 등 별도의 작업을 수행할 필요가 없습니다.
그러나 우리가 여러 분포식 서비스의 장시간 또는 복잡한 조작이나 조작에 대해 이야기할 때 간단한 방법은 더 이상 효과가 없다.우리는 몇 가지 절차로 나누어야 한다. 이 절차들은 일부 하위 절차 등을 포함할 수도 있다.그러나 파이프 중간의 오류를 어떻게 처리합니까?사용자에게 오류 메시지 하나만 되돌려줄 수 없습니다. 왜냐하면 지금 약간의 혼란을 정리해야 하기 때문입니다.어디 보자.
작업장에서 많은 일들이 예상을 벗어날 수도 있다.목수는 병가를 내고 사직할 수도 있고, 희귀 목재는 품절될 수도 있고, 재료 납품이 늦어질 수도 있다.어쨌든 작업장이 이미 돈을 지불한 상황에서 주문을 완성할 수 없는 상황이 확실히 존재한다.
그래서 지금 우리는 과정 중에 오류를 처리해야 한다.다른 유형의 오류나 같은 오류가 있을 수 있지만 처리는 모델 상태에 따라 달라집니다.
상태가 "manufacturing_pending"일 때 오류가 발생하면 작업장에서 주문을 완성할 수 없으므로 환불해야 합니다.
새로운 주도 있을 거야.

const (
    RefundPending  State = "refund_pending"
    OrderCancelled State = "order_cancelled"
)

상태도는 이제 다음과 같습니다.

일관성 오류 처리

처리해야 할 오류가 많을수록 상태도는 복잡해진다.그러나 FSM 덕분에 처리 프로세스는 항상 현재 상태와 일치하며 작업은 항상 적절합니다.
오류(또는 다른 이벤트)가 발생하면 주로 모델의 현재 상태에 따라 작업이 달라집니다.다음에 전환 조건을 검사한 후에야 전환 논리를 실행합니다.따라서 실체에서 발생하는 모든 사건의 처리는 시종 그 상태와 일치할 것이다.
여러 가지 잘못을 감안하면 전체 과정이 그럴 수도 있다.

분포식 사무를 처리한 사람들에게 그것은 전설의 패턴과 유사해 보일 수도 있지만 사실은 그렇다.하지만 다음 게시물에서 더 선진적인 FSM 앱을 알려드리겠습니다.

실용적인 건의

FSM을 사용하여 상태와 그 사이의 변환을 설명합니다.이것은 서로 다른 상태의 논리를 다른 모듈로 구분하는 데 도움이 될 것이다.이 상태들을 입자의 방식으로 묘사해 보아라.만약 데이터 모델이 실제적으로 모든 상태에서 가능하다면 대량의 상태를 두려워하지 마라.도표를 그리는 것에 흥미가 있다.