현재 상황
우리는 마이크로 서비스 아키텍처에서 온라인 쇼핑 웹 애플리케이션을 구현하고 현재 유지하고 있습니다.
요구 사항 중 하나는 비즈니스가 고객의 경험과 최종 주문을 사용자 정의하기 위해 고객이 장바구니에 추가하는 내용에 대한 규칙을 적용 할 수 있어야한다는 것입니다. 분명히 비즈니스 규칙 엔진을 설치해야했으며이를 위해 특정 “마이크로 서비스”를 구현했습니다 (여전히 호출 할 수있는 경우).
1 년 동안이 규칙 엔진은 점점 더 복잡 해져서 더 많은 데이터 (예 : 카트 내용뿐만 아니라 사용자 정보, 역할, 기존 서비스, 일부 청구 정보 등)가 필요합니다. 그 규칙을 계산하십시오.
현재 shopping-cart마이크로 서비스는이 모든 데이터를 다른 마이크로 서비스에서 수집하고 있습니다. 이 데이터의 일부가에 의해 사용 되더라도 shopping-cart대부분 규칙 엔진에 피드를 제공하는 데 주로 사용됩니다.
새로운 요구 사항
이제 유사한 요구 사항에 대해 규칙 엔진을 재사용하기 위해 다른 애플리케이션 / 마이크로 서비스가 필요합니다. 따라서 현재 상황에서는 동일한 종류의 데이터를 전송하고 동일한 마이크로 서비스를 호출하며 규칙 엔진을 호출 할 수 있도록 거의 동일한 리소스를 구축해야합니다.
계속해서 몇 가지 문제에 직면 할 것입니다.
- 규칙 엔진을 호출하는 모든 사람은 데이터가 필요하지 않더라도 데이터 가져 오기를 다시 구현해야합니다.
- 규칙 엔진에 대한 요청은 복잡합니다.
- 이 방향으로 계속 진행하면서 많은 요청에 대해 네트워크 전체에서이 데이터를 전송해야합니다 (룰 엔진을 호출하는 μs A 호출 μs B를 생각하지만 A에는 이미 규칙 엔진에 필요한 일부 데이터가 있음).
shopping-cart모든 데이터 페치로 인해 커졌습니다.- 아마 많은 사람들을 잊었을 것입니다…
이러한 문제를 피하려면 어떻게해야합니까?
이상적으로는 규칙 엔진에 더 많은 복잡성을 추가하지 않아도됩니다. 또한 병목 현상이 발생하지 않는지 확인해야합니다. 예를 들어 일부 데이터의 가져 오기 속도가 다소 느리므로 (10 초 이상) shopping-cart규칙을 호출하기 전에 데이터가있을 가능성이 높은 프리 페치를 구현 했습니다. 적절한 사용자 환경을 유지하십시오.
몇 가지 아이디어
- 규칙 엔진이 필요한 데이터를 가져 오도록합니다. 이것은 (단일 책임의 원칙을 위반, 그것을 더 복잡성을 추가합니다 … 더 );
- 데이터를 가져 오기 위해 규칙 엔진 전에 프록시 μs를 구현하십시오.
- 규칙 엔진이 필요한 모든 데이터를 한 번에 가져 오기 위해 호출하는 “데이터 페처”μs를 구현하십시오 (복합 조회).
답변
잠깐 동안 물러서서이 길이의 답을 쓰기 전에 출발지를 평가 해 봅시다. 당신은 :
- 큰 모놀리스 (규칙 엔진)
- 대량으로 전송되는 대량의 모듈화되지 않은 데이터
- 규칙 엔진에서 데이터를 가져 오기가 어렵습니다.
- 규칙 엔진을 제거 할 수 없습니다
좋아, 이것은 마이크로 서비스에는 그리 좋지 않습니다. 즉각적인 눈부신 문제는 마이크로 서비스가 무엇인지 오해하는 것 같습니다.
규칙 엔진을 호출하는 모든 사람은 데이터가 필요하지 않더라도 데이터 가져 오기를 다시 구현해야합니다.
마이크로 서비스가 사용하고 공통적 인 API 또는 통신 방법을 정의해야합니다. 이것은 모두 가져올 수있는 라이브러리 일 수 있습니다. 메시지 프로토콜을 정의하고있을 수 있습니다. 기존 도구를 사용 중일 수 있습니다 ( 마이크로 서비스 메시지 버스 를 좋은 출발점으로 찾으십시오 ).
서비스 간 통신 문제는 “해결 된”문제가 아니라이 시점에서 “자신의 롤”문제도 아닙니다. 기존 툴링과 전략이 많으면 인생을 훨씬 편하게 만들 수 있습니다.
무엇을 하든지 단일 시스템을 선택하고 이를 사용하도록 통신 API를 조정하십시오. 서비스가 상호 작용할 수있는 정의 된 방법이 없다면 마이크로 서비스와 모 놀리 식 서비스의 모든 단점을 가지게되며 어느 쪽의 장점도 갖지 못할 것입니다.
대부분의 문제는 이것에서 비롯됩니다.
규칙 엔진에 대한 요청은 복잡합니다.
덜 복잡하게 만드십시오.
덜 복잡하게 만드는 방법을 찾으십시오. 진심으로. 일반적인 데이터 모델은 단일 규칙 엔진을 더 작은 규칙 엔진으로 나눕니다. 규칙 엔진이 더 잘 작동하도록하십시오. “질문에 모든 것을 방해하고 계속 복잡하게 만드는”접근 방식을 사용하지 마십시오. 현재하고있는 일과 이유를 심각하게 살펴보십시오.
데이터에 대한 일종의 프로토콜을 정의하십시오. 내 생각 에 너희들은 정의 된 API 계획이 없으며 (위에 따라) 필요할 때마다 임시로 REST 호출을 작성하기 시작했다. 무언가가 업데이트 될 때마다 모든 마이크로 서비스를 유지 관리해야하므로 점점 복잡해집니다.
더 좋은 것은 온라인 쇼핑 도구를 구현 한 최초의 회사 가 아닙니다 . 다른 회사를 조사하십시오.
이제 뭐…
그 후, 당신은 적어도 가장 큰 문제 중 일부를 심사숙고했습니다.
다음 문제는 규칙 엔진에 관한이 질문입니다. 나는 이것이 합리적으로 비 국가적이어서 당신이 그것을 확장 할 수 있기를 바랍니다. 그렇다면, 차선책이지만 최소한 영광의 불꽃으로 죽거나 미친 해결 방법을 세우지 않을 것입니다.
규칙 엔진을 상태 비 저장 상태로 유지하려고합니다. 데이터 만 처리하도록하십시오. 병목 현상이 발견되면 프록시 /로드 밸런서 뒤에 여러 개를 실행할 수 있도록 만드십시오. 이상적이지는 않지만 여전히 실행 가능합니다.
마이크로 서비스 중 하나를 실제로 규칙 엔진에 배치해야하는지 고려하여 시간을 보내십시오. “마이크로 서비스 아키텍처”를 달성하기 위해 시스템 오버 헤드를 크게 늘리는 경우이를 계획하는 데 더 많은 시간을 소비해야합니다.
또는 규칙 엔진을 여러 조각으로 나눌 수 있습니까? 규칙 엔진 전용 서비스를 만드는 것만으로도 이익을 얻을 수 있습니다.
또한 병목 현상이 발생하지 않는지 확인해야합니다. 예를 들어 일부 데이터의 가져 오기 속도가 느립니다 (10 초 이상).
위의 문제를 해결 한 후이 문제가 있다고 가정하면이 문제가 발생하는 이유를 심각하게 조사해야합니다. 당신은 악몽이 펼쳐지지만 왜 (10 초? 쇼핑 포털 데이터 를 보내 려면? 냉소적이라고 부르지 만 조금 어색해 보입니다) 첫 번째 장소.
“데이터 가져 오기”라는 문구를 반복해서 사용했습니다. 이 데이터가 데이터베이스에 있습니까? 그렇지 않은 경우이 작업을 고려하십시오. 데이터를 “수동으로”가져 오는 데 너무 많은 시간을 소비하는 경우 실제 데이터베이스를 사용하는 것이 좋습니다.
가져올 데이터 (이것이 무엇인지에 따라 여러 번 언급 했음), 몇 가지 규칙 엔진 및 클라이언트에 대한 데이터베이스를 사용하여 디자인 할 수 있습니다.
마지막으로, API 및 서비스의 올바른 버전을 사용해야합니다. 부 릴리스는 이전 버전과의 호환성을 손상시키지 않아야합니다. 모든 서비스가 동시에 작동하도록 자신을 발견하면 마이크로 서비스 아키텍처가없고 분산 된 모 놀리 식 아키텍처입니다.
그리고 궁극적으로 마이크로 서비스는 모든 솔루션에 적합한 것은 아닙니다. 거룩한 모든 것을 위해 새로운 엉덩이 일이기 때문에하지 마십시오.
답변
규칙 엔진과 해당 입력 및 출력에 대한 정보가 많으므로 귀하의 제안은 아니오라고 생각합니다. 2는 올바른 길을 가고 있습니다.
규칙 엔진의 현재 소비자는 필요한 정보를 수집하는 프로세스를보다 특수한 목적의 구성 요소로 아웃소싱 할 수 있습니다.
예 : 현재 규칙 엔진을 사용하여 장바구니 내용에 적용 할 할인을 계산하고 있습니다. 이전 구매, 지리 및 현재 제안이 여기에 포함됩니다.
새로운 요구 사항은 다가오는 스페셜 및 이전 구매를 기반으로 이전 고객에게 제공하는 이메일에 동일한 정보를 많이 사용하는 것입니다. 이전 구매, 현재 및 향후 제공이 여기에 포함됩니다.
이를 위해 두 가지 별도의 서비스가 있습니다. 그들은 각각 무거운 짐을 들어 규칙 엔진 서비스에 의존 할 것입니다. 그들 각각은 규칙 엔진에 대한 요청에 필요한 데이터를 수집합니다.
규칙 엔진은 규칙을 적용하고 소비자는 규칙 엔진이 특정 컨텍스트에 필요한 정확한 데이터에 대해 걱정할 필요가 없으며 이러한 새로운 중개 서비스는 한 가지 작업 만 수행합니다. 컨텍스트를 구성하고 요청을 규칙 엔진에 전달 수정되지 않은 응답을 반환합니다.
답변
결정에 필요한 데이터 집계는 규칙 엔진 외부에서 수행해야합니다. 이는 가능한 한 상태 비 저장 서비스로 가장 잘 설계 되었기 때문입니다. 데이터 페치에는 반드시 비동기 처리 및 상태 유지가 필요합니다. 가져 오기가 의사 결정 서비스 앞에있는 프록시, 호출자 또는 비즈니스 프로세스에 의해 수행되는지는 중요하지 않습니다.
구현을위한 실질적인 문제로 IBM Operational Decision Manager가 도커 컨테이너 내에서 제품 사용을 문서화하고 이미 지원하고 있음을 언급 할 것 입니다. 다른 제품도이 지원을 제공하고 주류가 될 것입니다.
답변
내 생각으로는 고객이 데이터를 구매하고 캐시를 시작하자마자 데이터 검색 서비스에 대한 비동기 호출을 설정하여 모든 필수 데이터를 프리 페치하는 것이 도움이 될 것입니다. 따라서 규칙 서비스를 호출해야 할 때 데이터가 이미 있습니다. 그리고 세션 동안 다른 서비스에도 계속 사용할 수 있습니다.