많은 입력 데이터가 필요할 때 마이크로 서비스 아키텍처에서 규칙 엔진을 맞추는 방법은 무엇입니까?


12

현재 상황

우리는 마이크로 서비스 아키텍처에서 온라인 쇼핑 웹 애플리케이션을 구현하고 현재 유지하고 있습니다.

요구 사항 중 하나는 비즈니스가 고객의 경험과 최종 주문을 사용자 정의하기 위해 고객이 장바구니에 추가하는 내용에 대한 규칙을 적용 할 수 있어야한다는 것입니다. 분명히 비즈니스 규칙 엔진을 설치해야했으며이를 위해 특정 "마이크로 서비스"를 구현했습니다 (여전히 호출 할 수있는 경우).

1 년 동안이 규칙 엔진은 점점 더 복잡 해져서 더 많은 데이터 (예 : 카트 내용뿐만 아니라 사용자 정보, 역할, 기존 서비스, 일부 청구 정보 등)가 필요합니다. 그 규칙을 계산하십시오.

현재 shopping-cart마이크로 서비스는이 모든 데이터를 다른 마이크로 서비스에서 수집하고 있습니다. 이 데이터의 일부가에 의해 사용 되더라도 shopping-cart대부분 규칙 엔진에 피드를 제공하는 데 주로 사용됩니다.

새로운 요구 사항

이제 유사한 요구 사항에 대해 규칙 엔진을 재사용하기 위해 다른 애플리케이션 / 마이크로 서비스가 필요합니다. 따라서 현재 상황에서는 동일한 종류의 데이터를 전송하고 동일한 마이크로 서비스를 호출하며 규칙 엔진을 호출 할 수 있도록 거의 동일한 리소스를 구축해야합니다.

계속해서 몇 가지 문제에 직면 할 것입니다.

  • 규칙 엔진을 호출하는 모든 사람은 데이터가 필요하지 않더라도 데이터 가져 오기를 다시 구현해야합니다.
  • 규칙 엔진에 대한 요청은 복잡합니다.
  • 이 방향으로 계속 진행하면서 많은 요청에 대해 네트워크 전체에서이 데이터를 전송해야합니다 (룰 엔진을 호출하는 μs A 호출 μs B를 생각하지만 A에는 이미 규칙 엔진에 필요한 일부 데이터가 있음).
  • shopping-cart 모든 데이터 페치로 인해 커졌습니다.
  • 아마 많은 사람들을 잊었을 것입니다…

이러한 문제를 피하려면 어떻게해야합니까?

이상적으로는 규칙 엔진에 더 많은 복잡성을 추가하지 않아도됩니다. 또한 병목 현상이 발생하지 않는지 확인해야합니다. 예를 들어 일부 데이터의 가져 오기 속도가 다소 느리므로 (10 초 이상) shopping-cart규칙을 호출하기 전에 데이터가있을 가능성이 높은 프리 페치를 구현 했습니다. 적절한 사용자 환경을 유지하십시오.

몇 가지 아이디어

  1. 규칙 엔진이 필요한 데이터를 가져 오도록합니다. 이것은 (단일 책임의 원칙을 위반, 그것을 더 복잡성을 추가합니다 ... 더 );
  2. 데이터를 가져 오기 위해 규칙 엔진 전에 프록시 μs를 구현하십시오.
  3. 규칙 엔진이 필요한 모든 데이터를 한 번에 가져 오기 위해 호출하는 "데이터 페처"μs를 구현하십시오 (복합 조회).

이 질문을 요약 해 보겠습니다. 상점에 대해 여러 마이크로 서비스가 구현되어 있습니다. 그들 중 하나는 쇼핑 카트 입니다. 카트 엔진에 규칙 엔진 (홈 브루 또는 일부 제품)이 포함되어 있습니까? 사용자가 장바구니에 품목을 추가하면 규칙 엔진이 비즈니스 로직의 일부로 시작하여 장바구니를 수정합니다 (예 : 할인 또는 번들 제품). 이제 또 다른 microservice 또한 규칙을 사용하고자 할 수 있습니다 오른쪽 유사한 입력 데이터에 기반을? 입력 데이터는 다른 마이크로 서비스에서 제공됩니다. 데이터 반입이 왜 그렇게 복잡한가?
Andy

3
이러한 문제를 피하는 가장 좋은 방법은 규칙 엔진을 제거하는 것입니다.
whatsisname

@Andy 규칙 엔진은 별도의 마이크로 서비스입니다. API는 약간 맞춤화 shopping-cart되었지만 다른 마이크로 서비스의 요구에 맞게 쉽게 조정할 수 있습니다 (여전히 사용자, 제품 및 주문과 관련이 있습니다). 보시다시피 , 특히 비즈니스가 적용 할 술어를 선택할 수 있으므로 동일한 입력 데이터 필요합니다. 카트 데이터 자체를 제외한 다른 마이크로 서비스에서 모든 데이터를 제공합니다. 데이터를 가져 오는 것은 그 자체로 는 복잡하지 않지만 ~ 10 개의 다른 마이크로 서비스를 호출하고 규칙 엔진에 의해 예상되는 구조를 유지해야 할 때 복잡해집니다.
Didier L

@whatsisname 나는 일반적으로 규칙 엔진을 사용하는 것에 대한 열렬한 팬이 아니지만 현재 우리는 그것을 처리해야하며 비즈니스는 매일 구성을 변경하고 있습니다. 이를 제거하더라도 동일한 입력 데이터를 요구하는 동일한 작업을 수행 할 수있는 구성 가능한 일부 구성 요소가 여전히 필요합니다. 다른 이름을 가진 규칙 엔진 일뿐 아니라 여전히 동일한 문제에 직면하게됩니다.
Didier L

답변:


8

잠깐 동안 물러서서이 길이의 답을 쓰기 전에 출발지를 평가 해 봅시다. 당신은 :

  • 큰 모놀리스 (규칙 엔진)
  • 대량으로 전송되는 대량의 모듈화되지 않은 데이터
  • 규칙 엔진에서 데이터를 가져 오기가 어렵습니다.
  • 규칙 엔진을 제거 할 수 없습니다

좋아, 이것은 마이크로 서비스에는 그리 좋지 않습니다. 즉각적인 눈부신 문제는 마이크로 서비스가 무엇인지 오해하는 것 같습니다.

규칙 엔진을 호출하는 모든 사람은 데이터가 필요하지 않더라도 데이터 가져 오기를 다시 구현해야합니다.

마이크로 서비스가 사용하고 공통적 인 API 또는 통신 방법을 정의해야합니다. 이것은 모두 가져올 수있는 라이브러리 일 수 있습니다. 메시지 프로토콜을 정의하고있을 수 있습니다. 기존 도구를 사용 중일 수 있습니다 ( 마이크로 서비스 메시지 버스 를 좋은 출발점으로 찾으십시오 ).

서비스 간 통신 문제는 "해결 된"문제가 아니라이 시점에서 "자신의 롤"문제도 아닙니다. 기존 툴링과 전략이 많으면 인생을 훨씬 편하게 만들 수 있습니다.

무엇을 하든지 단일 시스템을 선택하고 이를 사용하도록 통신 API를 조정하십시오. 서비스가 상호 작용할 수있는 정의 된 방법이 없다면 마이크로 서비스와 모 놀리 식 서비스의 모든 단점을 가지게되며 어느 쪽의 장점도 갖지 못할 것입니다.

대부분의 문제는 이것에서 비롯됩니다.

규칙 엔진에 대한 요청은 복잡합니다.

덜 복잡하게 만드십시오.

덜 복잡하게 만드는 방법을 찾으십시오. 진심으로. 일반적인 데이터 모델은 단일 규칙 엔진을 더 작은 규칙 엔진으로 나눕니다. 규칙 엔진이 더 잘 작동하도록하십시오. "질문에 모든 것을 방해하고 계속 복잡하게 만드는"접근 방식을 사용하지 마십시오. 현재하고있는 일과 이유를 심각하게 살펴보십시오.

데이터에 대한 일종의 프로토콜을 정의하십시오. 내 생각 에 너희들은 정의 된 API 계획이 없으며 (위에 따라) 필요할 때마다 임시로 REST 호출을 작성하기 시작했다. 무언가가 업데이트 될 때마다 모든 마이크로 서비스를 유지 관리해야하므로 점점 복잡해집니다.

더 좋은 것은 온라인 쇼핑 도구를 구현 한 최초의 회사 가 아닙니다 . 다른 회사를 조사하십시오.

이제 뭐...

그 후, 당신은 적어도 가장 큰 문제 중 일부를 심사숙고했습니다.

다음 문제는 규칙 엔진에 관한이 질문입니다. 나는 이것이 합리적으로 비 국가적이어서 당신이 그것을 확장 할 수 있기를 바랍니다. 그렇다면, 차선책이지만 최소한 영광의 불꽃으로 죽거나 미친 해결 방법을 세우지 않을 것입니다.

규칙 엔진을 상태 비 저장 상태로 유지하려고합니다. 데이터 만 처리하도록하십시오. 병목 현상이 발견되면 프록시 /로드 밸런서 뒤에 여러 개를 실행할 수 있도록 만드십시오. 이상적이지는 않지만 여전히 실행 가능합니다.

마이크로 서비스 중 하나를 실제로 규칙 엔진에 배치해야하는지 고려하여 시간을 보내십시오. "마이크로 서비스 아키텍처"를 달성하기 위해 시스템 오버 헤드를 크게 늘리는 경우이를 계획하는 데 더 많은 시간을 소비해야합니다.

또는 규칙 엔진을 여러 조각으로 나눌 수 있습니까? 규칙 엔진 전용 서비스를 만드는 것만으로도 이익을 얻을 수 있습니다.

또한 병목 현상이 발생하지 않는지 확인해야합니다. 예를 들어 일부 데이터의 가져 오기 속도가 느립니다 (10 초 이상).

위의 문제를 해결 한 후이 문제가 있다고 가정하면이 문제가 발생하는 이유를 심각하게 조사해야합니다. 당신은 악몽이 펼쳐지지만 왜 (10 초? 쇼핑 포털 데이터 를 보내 려면? 냉소적이라고 부르지 만 조금 어색해 보입니다) 첫 번째 장소.

"데이터 가져 오기"라는 문구를 반복해서 사용했습니다. 이 데이터가 데이터베이스에 있습니까? 그렇지 않은 경우이 작업을 고려하십시오. 데이터를 "수동으로"가져 오는 데 너무 많은 시간을 소비하는 경우 실제 데이터베이스를 사용하는 것이 좋습니다.

가져올 데이터 (이것이 무엇인지에 따라 여러 번 언급 했음), 몇 가지 규칙 엔진 및 클라이언트에 대한 데이터베이스를 사용하여 디자인 할 수 있습니다.

마지막으로, API 및 서비스의 올바른 버전을 사용해야합니다. 부 릴리스는 이전 버전과의 호환성을 손상시키지 않아야합니다. 모든 서비스가 동시에 작동하도록 자신을 발견하면 마이크로 서비스 아키텍처가없고 분산 된 모 놀리 식 아키텍처입니다.

그리고 궁극적으로 마이크로 서비스는 모든 솔루션에 적합한 것은 아닙니다. 거룩한 모든 것을 위해 새로운 엉덩이 일이기 때문에하지 마십시오.


귀하의 답변에 감사드립니다, @enderland. 실제로 마이크로 서비스 아키텍처는 여전히 우리에게 비교적 새로운 것이기 때문에이 질문입니다. 이 규칙 엔진은 우리를 여기로 인도하기 위해 약간 유기적으로 발전해 왔으므로 이제는이를 해결하기위한 운전 지침이 필요합니다. (아쉽게도) 완전히 상태 비 저장이므로 입력으로 사용되는 데이터의 양입니다. 그리고 이것을 재사용 가능한 구성 요소로 만들기 위해 먼저 다루고 싶은 것입니다. 그러나 사용 가능한 술어 수를 줄이지 않고 입력 데이터의 양을 줄이는 방법은 무엇입니까? 데이터를 자체적으로 가져올 수있는 API가 필요하다고 생각하지만 올바르게 아키텍처하는 방법은 무엇입니까?
Didier L

성능 문제와 관련하여 실제로 백엔드로 구현 된 느린 JMS 및 SOAP 서비스를 호출하는 마이크로 서비스에서 발생합니다. 그들은 자체 데이터베이스를 가지고 있지만 성능이 실제로 첫 번째 목표 는 아닙니다 (로드를 처리하는 한). 그리고 데이터 복제 및 유지 관리를 고려할 수있는 데이터가 너무 많습니다 (일부 경우는 해당). 우리가 할 수있는 최선의 방법은 캐싱과 프리 페치입니다.
Didier L

" 규칙 엔진 몇 개 "를 언급 할 때 , 1 가지 유형의 입력으로 술어 만 평가하는 특수 규칙 엔진을 의미한다는 것을 알고 있습니까? 필요한 데이터를 가져 오거나 미리 가져와야한다고 제안 하시겠습니까? 술어의 조합을 조정하려면 구성 요소가 필요합니다. 이 오케스트레이션으로 인해 너무 많은 네트워크 오버 헤드가 발생하지 않도록주의하십시오.
Didier L

1

규칙 엔진과 해당 입력 및 출력에 대한 정보가 많으므로 귀하의 제안은 아니오라고 생각합니다. 2는 올바른 길을 가고 있습니다.

규칙 엔진의 현재 소비자는 필요한 정보를 수집하는 프로세스를보다 특수한 목적의 구성 요소로 아웃소싱 할 수 있습니다.

예 : 현재 규칙 엔진을 사용하여 장바구니 내용에 적용 할 할인을 계산하고 있습니다. 이전 구매, 지리 및 현재 제안이 여기에 포함됩니다.

새로운 요구 사항은 다가오는 스페셜 및 이전 구매를 기반으로 이전 고객에게 제공하는 이메일에 동일한 정보를 많이 사용하는 것입니다. 이전 구매, 현재 및 향후 제공이 여기에 포함됩니다.

이를 위해 두 가지 별도의 서비스가 있습니다. 그들은 각각 무거운 짐을 들어 규칙 엔진 서비스에 의존 할 것입니다. 그들 각각은 규칙 엔진에 대한 요청에 필요한 데이터를 수집합니다.

규칙 엔진은 규칙을 적용하고 소비자는 규칙 엔진이 특정 컨텍스트에 필요한 정확한 데이터에 대해 걱정할 필요가 없으며 이러한 새로운 중개 서비스는 한 가지 작업 만 수행합니다. 컨텍스트를 구성하고 요청을 규칙 엔진에 전달 수정되지 않은 응답을 반환합니다.


0

결정에 필요한 데이터 집계는 규칙 엔진 외부에서 수행해야합니다. 이는 가능한 한 상태 비 저장 서비스로 가장 잘 설계 되었기 때문입니다. 데이터 페치에는 반드시 비동기 처리 및 상태 유지가 필요합니다. 가져 오기가 의사 결정 서비스 앞에있는 프록시, 호출자 또는 비즈니스 프로세스에 의해 수행되는지는 중요하지 않습니다.

구현을위한 실질적인 문제로 IBM Operational Decision Manager가 도커 컨테이너 내에서 제품 사용을 문서화하고 이미 지원하고 있음을 언급 할 것 입니다. 다른 제품도이 지원을 제공하고 주류가 될 것입니다.


0

내 생각으로는 고객이 데이터를 구매하고 캐시를 시작하자마자 데이터 검색 서비스에 대한 비동기 호출을 설정하여 모든 필수 데이터를 프리 페치하는 것이 도움이 될 것입니다. 따라서 규칙 서비스를 호출해야 할 때 데이터가 이미 있습니다. 그리고 세션 동안 다른 서비스에도 계속 사용할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.