이 글에서는 책임 사슬 디자인 패턴을 사용하게 된 배경과 경험을 소개하여 독자들이 이 디자인 패턴에 대한 인상을 깊게 할 수 있도록 하고, 현재 참여하고 담당하고 있는 프로젝트를 "페이스리프트"하여 영감을 얻어 디자인 패턴을 개선할 수 있도록 합니다. 뷰티 시스템의 '페이스리프트'. 작업의 모든 세부사항을 공유하세요.
1. 배경
제가 담당하고 있는 시스템에는 파티션 모듈이라는 모듈이 있는데, 이 단어를 직접 보시면 많은 분들이 헷갈리시거나 오해하실 수도 있을 것 같아요. "라우팅"이 무엇인지 간략하게 설명하겠습니다.
모든 사람이 온라인 쇼핑 경험을 갖고 있다고 생각합니다. 주문할 때마다 언제 어디서나 주문의 물류 추적 상태를 확인할 수 있습니다. 위에서 언급한 "라우팅" 개념은 주문이 A 지점에서 지점으로 운송되는 것을 의미합니다. B. 라우팅 라인, 예를 들어 주문 order1은 A에서 목적지 F로 운송되어야 합니다. A->B->D->F 또는 A->D->F에서 이동할 수 있습니다. 시스템에 구성된 경로와 해당 일치 규칙이 필터링됩니다.
오랫동안 시스템의 라우팅 구성과 규칙은 정적이었습니다(소위 정적이란 사전에 구성되어 거의 고정되어 있음을 의미함). 이 접근 방식의 단점은 명백합니다. 즉, 비용이 많이 들지 않습니다. 위에서 언급한 예에서 운송 경로를 줄이거나 직접 배송할 수 있는 기회가 분명히 있습니다(A에서 F까지의 상품은 분명히 N개의 트럭을 채울 수 있지만 경로에 따라 운송되어야 함). 시스템에 설정), 그러나 시스템에 의해 차단됩니다. 고정된 경로 규칙으로 인해 더 많은 도로만 이용할 수 있으며 이로 인해 인력 운영 및 운송 비용이 증가합니다.
이를 바탕으로 전문가는 비용을 절감하고 효율성을 높일 수 있는 비즈니스 기회를 발견했습니다. 즉, 이 라우팅 라인과 규칙을 활성화하여 시스템이 위의 상황과 보다 유연하게 호환되고 궁극적인 자원 활용을 달성할 수 있도록 하는 것입니다. 예를 들어 주문이 많은 경우 모두 A에서 목적지 F로 향합니다. 시스템의 정적 라인 구성은 A->B->D->F뿐입니다. 그러나 시스템 모니터링 및 계산 결과 A에서 F까지의 상품 양은 두 대의 트럭을 채울 수 있습니다. 그런 다음 A에서 F까지의 주문에 대해 일시적으로 새로운 경로가 생성됩니다. 동시에 상품은 A 사이트에서 수령 및 배송됩니다. 라우팅 라인 매칭을 포함하는 것은 이 임시 라우팅 시나리오와 호환되므로 사용자 습관을 바꾸지 않고도 전체 비용을 줄일 수 있으며 목적지까지의 운송 효율성도 크게 향상되었습니다.
이 전문가가 제안한 계획은 매우 훌륭했고 모든 사람들로부터 널리 인정과 칭찬을 받았습니다. 프로젝트가 수립된 후 활발한 개발 단계에 들어섰고, 저는 운이 좋게도 프로젝트의 개발과 전달을 주도하는 중요한 임무를 맡게 되었습니다. 이 프로젝트.
라우팅 회로의 변경 사항은 주문의 전체 실제 작업 프로세스뿐만 아니라 일부 구석구석 보조 쿼리, 통계 보고서 및 기타 기능을 통해 실행된다는 점을 언급할 가치가 있습니다. 관련된 시나리오가 많기 때문에 여전히 압박감이 있습니다. 꽤 높았지만, 그 기간 동안 우회를 많이 한 것은 사실이지만 결과는 좋았습니다. 나중에도 비슷한 노선 변경이 필요했지만 이러한 변화를 바탕으로 쉽게 처리할 수 있었습니다. . 이에 대해서는 글에서 나중에 다루도록 하겠습니다.
너무 많이 말하면 말도 안 되는 소리라고 느껴지시나요? 하하, 사실 좀 장황합니다. 다음으로 Menghuilu를 살펴보고 단편적이지만 성취감이 있는 전체 변신 과정을 재현해 보겠습니다.
2. 아이디어와 방법
이어지는 글에서 언급되는 파티셔닝은 라우팅을 위한 일치 규칙의 의미입니다.
먼저 실제 작업 프로세스에 대한 간단한 개략도를 살펴보겠습니다.
파티션 일치 규칙은 각 사이트의 실제 작업 프로세스에 포함되는 동시에 일부 보조 작업의 쿼리 기능이나 보고 기능에도 포함되므로 파티션 일치 규칙을 변경해야 하면 그러면 다음과 같은 어려움에 직면하게 될 것입니다
위의 문제점을 토대로 저는 이 모듈을 재구성하고 수정하기로 결정했습니다. 첫째, 이번 도전을 통해 제 자신을 향상시키고, 둘째, 향후 이 규칙을 다시 변경할 수 있는 기반도 마련하겠습니다. 위에서 언급한 문제점을 해결하려면 어떻게 해야 합니까? 이것이 내가 한 일이다
이것을 보고 어떤 사람들은 이것이 또 다른 문제를 가져올 수 있는지 묻습니다. 장면을 놓치지 않지만 코드 변경이 이루어지면 모든 장면이 적용되지만 일부 장면의 원래 장면이 변경됩니까? 여기 학생들은 정말 조심스럽게 닫히게 되면 이런 새로운 문제가 발생할 것입니다. 따라서 통합 클로저는 각 장면의 차별화된 처리를 지원하기 위해 확장 및 예비 후크를 지원해야 합니다. 예를 들어, 일반적인 시나리오 규칙은 모든 주문이 시스템에 설정된 구성의 구역화 규칙에 따라 운송된다는 것입니다. 그러나 이제 일부 판매자는 목적지까지 신속하게 배송하기 위해 일부 서비스를 열었습니다. 상인의 주문 더 이상 기존의 일반 규칙을 파티션 매칭 및 운송에 사용할 수 없습니다. 빠른 운송 목적을 달성하려면 새로운 규칙에 따라 파티션 매칭을 수행해야 합니다. 이것이 내부의 차이점입니다.
그렇다면 책임 사슬 모델은 정확히 무엇입니까?
Daniel이 제공한 정의: 여러 개체에 요청을 처리할 수 있는 기회를 제공하여 요청 발신자와 수신자 간의 결합 관계를 피합니다. 이러한 개체는 체인으로 연결되며 요청은 개체가 처리할 때까지 체인을 따라 전달됩니다.
기존 시스템의 실제 비즈니스를 기반으로 어떻게 적용하는지 이야기해 보겠습니다. 기존 파티션 매칭 규칙은 정적 파티션 매칭(예: 특정 비즈니스 지점 간, 특정 비즈니스)이라는 점을 서문의 배경에서 이미 소개했습니다. 비즈니스 포인트를 범위 영역으로 지정) 잠깐, 구체적인 비즈니스 세부 사항은 다루지 않겠습니다. 여기에 일치하는 규칙이 많이 있다는 것만 알아두세요.) 이제 역학을 지원하기 위한 새 규칙을 추가해야 합니다(이 역시 다양한 규칙입니다). 자세한 내용은 다루지 않겠습니다.) 여기에서는 각 파티션 규칙을 파티션 유형으로 정의하고, 각 파티션 유형을 파티션 노드로 정의하여 각 요청이 일치하는 라인을 찾을 수 있도록 합니다. 이 체인.
사업 내용은 상대적으로 민감한 부분이므로 기사에서는 자세히 공개하지 않으며, 이는 핵심 디자인 패턴 적용에 대한 이해에 영향을 미치지 않습니다.
정의와 위의 분석을 결합하면 실제 상황이 책임 사슬 디자인 패턴을 사용하는 데 적합한가요? 위의 문제점이 해결될 수 있고 전반적인 이점이 단점보다 크다면 적용 가능하다고 믿습니다. 첫째, 이 모델을 사용하여 변환하면 다음과 같은 이점이 있습니다.
물론 이 모델에는 몇 가지 단점도 있습니다. 책임 체인이 상대적으로 길면 각 요청이 전체 체인을 통과하므로 성능 문제가 발생할 수 있으며 동시에 이해하지 못하는 학생에게는 디버깅이 더 복잡해질 수 있습니다. 사업.
전반적으로 장점은 현재의 문제점을 해결하고 후속 확장을 용이하게 한다는 것입니다. 반면 단점 중 성능 부분은 템플릿 모드에 예약된 후크 기능을 결합하여 건너뛸 수 있습니다(현재 요청이 현재 파티션 노드에 적합하지 않은 경우). 규칙) 성능 문제의 영향을 최소화하는 동시에 개발자가 비즈니스를 이해하는 것도 필요합니다. 그래서 전반적으로 장점이 단점보다 더 많은 것 같습니다.
이상으로, 먼저 변환 전후의 파티션 모듈에 대한 간단한 비교 다이어그램을 살펴보겠습니다.
다이어그램은 매우 간단하지만 비교의 의미는 여전히 분명합니다. 변환 전: 파티션 일치와 비즈니스 처리가 함께 결합됩니다. 변환 후: 파티션 일치는 체인이며 여기에는 비즈니스 논리 처리가 없습니다. 커플링이 없는 확장도 지원됩니다. 어떤 사람들은 이것을 보고 혼란스러워할 수도 있습니다. 위에서는 동적 매칭 규칙이 하나만 추가되었다고 말하지 않았습니까? 왜 체인에 노드가 그렇게 많은데 여전히 두 개의 체인이 있습니까? 여기서 조금 설명하자면, 현재 두 체인은 수요 버전이 많이 변경되었지만 현재는 두 체인이 제공하는 소스 비즈니스 지정 시나리오가 다르기 때문에 차이가 크지 않은 것 같습니다. 기타 각자의 운영을 방해하는 이 글의 여러 곳에 소개된 노드들도 나중에 추가되었으며, 현재까지 시스템에서 사용되는 노드 규칙입니다. (이것은 글의 시작 부분에서 언급한 것입니다. 물론 나중에 규칙이 변경될 수도 있지만, 여전히 똑똑한 만큼 "예언"이 현실이 되었습니다. 결과적으로 여기서는 건설 기간을 단축하기 위한 확장 지원의 중요성을 말씀드리겠습니다.
3. 실무과정
나는 많은 독자들이 위의 내용이 성능 영향을 최대한 피하기 위해 템플릿 모드와 통합 종료 및 결합에 대해 이야기하고 있으므로 하나의 디자인 모드로는 책임 체인을 지원할 수 없다는 것을 알게 될 것이라고 믿습니다.
네 맞습니다, Smart.단일 책임 체인 디자인 패턴을 사용하는 것만으로는 위에서 언급한 효과를 얻을 수 없습니다. 여기서는 팩토리, 템플릿 및 책임 체인 패턴을 결합하는 데 사용됩니다. 체인의 빈을 얻습니다. 템플릿은 일반 메소드, 메소드 간 호출, 스위치, 사전 및 사후 처리, 차별화 및 하위 클래스 구현을 위해 예약된 기타 메소드를 설정하는 데 사용됩니다. 여기서 책임 체인은 다양한 노드를 결합하는 데 사용됩니다. 다음은 몇 가지 간단한 예입니다. 노드는 다음과 같이 클래스 다이어그램을 표시합니다.
이 부분은 결국 코딩일 뿐입니다. 위의 클래스 다이어그램은 코드에 거의 적용되는 부분이며 실제 호출에서는 특정 항목에 대한 Bean 체인을 가져오는 부분이기도 합니다. 파티션 일치.
4. 실천과정에 대한 고찰과 효과평가
변환 후의 결과는 주로 후속 확장 및 유지 관리에 반영됩니다. 기사 시작 부분에서 언급했듯이 파티션 일치 규칙이 변경되면 가장 직접적인 두 가지 문제가 건설 기간에 나타납니다. 이 블록을 처음으로 가져오는 경우 새로운 라우팅 규칙에 대한 요구 사항을 변경할 때 R&D 측면에서 전체 실제 구축 기간은 45일이며, BUG가 발생하면 테스트 기간이 보장되지 않습니다(동적 노드에 해당). 위 그림의 노드에서)
하지만 얼마 지나지 않아 매칭 규칙에 대한 새로운 요구 사항이 다시 추가되었습니다(위 노드의 카풀 노드에 해당). 유사한 요구 사항에 대해 건설 기간이 거의 절반으로 단축되었으며 최적의 45일이 27일로 단축되었습니다. 요구 사항에는 분할되지 않은 다른 모듈의 변환도 포함됩니다. 물론 첫 번째 버전의 변환은 몇 가지 완벽한 측면을 갖췄으며 이후 요구 사항에 따라 최적화되었습니다.
다음 두 가지는 건설 기간 소멸이라는 것을 실제로 구현합니다. 하나는 첫 번째 보드 구역화 규칙 요구 사항이고 다른 하나는 최근 B 네트워크 통합 요구 사항의 직접 구역화 규칙입니다.
솔직히, 데이터를 돌아보지 않았을 때는 이렇게 큰 효과를 기대하지 않았는데, 지금 돌이켜보면 디자인 패턴을 적용하면 구축 기간이 단축될 수 있다고 누가 생각이나 했겠는가. 45일 동안 1신이라니, 정말 놀랍습니다.
물론 개선되고 업그레이드될 수 있는 영역도 있습니다. 현재 책임 체인 노드의 조립은 수동으로 지정되어 자동 조립으로 변경될 수 있습니다(다른 비즈니스 시나리오의 변환에서 이미 구현했으며 여기서도 수행됩니다.) 또 다른 하나는 노드 수를 제어하는 것입니다. 노드 수가 너무 많으면 호환성 솔루션을 고려해야 할 수도 있습니다.
한 방울의 물을 뚫는 데 하루가 걸리지 않고, 3피트의 얼음을 얼리는 데도 하루가 걸리지 않는다는 말이 있듯이, 강력한 도구와 신기술을 추구하는 것은 확실히 가능하지만, 그렇지 않습니다. 일상의 작은 변화도 잊지 마세요. 짧은 시간 안에는 아무것도 보이지 않을 수도 있지만, 양적인 변화가 질적인 변화로 이어진다면 그 결과는 매우 인상적일 것이라고 믿습니다.