표가 하나 뿐인 경우에도 페이지 매김과 필터링이 가능합니다. 맞습니까?
그래서 저는 마이크로 서비스간에 테이블을 조인하는 방법에 대해 의문이라고 생각합니다.
사람들이 마이크로 서비스를 사용하면 가능한 한 마이크로 서비스 간 테이블 조인을 피할 것이라고 생각합니다. 그들이 할 수 없다면 아마 테이블이 다른 마이크로 서비스로 분리되어서는 안됩니다.
한편, 때로는 목표를 달성하기 위해 테이블을 조인 할 필요가 없습니다. 예를 들어, 당신이 두 개의 테이블이 있다고 가정 해 봅시다 :
-- from hotel information service
create table t_hotel (
id VARCHAR(40) not null,
name varchar(50) not null,
location varchar(50) not null,
CONSTRAINT pk_hotel PRIMARY KEY (id)
);
-- from hotel comment service
create table t_hotel_comment (
id VARCHAR(40) not null,
hotel_id varchar(40) not null,
content varchar(50) not null,
CONSTRAINT pk_hotel_comment PRIMARY KEY (id)
);
지금은 호텔 목록을 보여주는 페이지를 구현하려면, 각 행은 코멘트 수를 표시합니다.
____________________________
| name | location | comments |
| foo | foooooo | 2 |
| bar | barrrrr | 3 |
----------------------------
당신은 조인 쿼리 또는 두 개의 API를 호출을 구현할 수 있습니다 : 호텔을 나열
- 전화 호텔 정보 서비스를 제공합니다.
- 각 호텔의 의견을 종합하기 위해 호텔 코멘트 서비스에 전화하십시오.
-- from hotel information service
create table t_hotel (
id VARCHAR(40) not null,
name varchar(50) not null,
location varchar(50) not null,
comments numeric not null,
CONSTRAINT pk_hotel PRIMARY KEY (id)
);
때마다, 호텔 코멘트 서비스가 의견을 받고, 그것이 HotelCommentedEvent를 게시 :
은 아마 당신은 당신이 의견을 t_hotel에서 계산 캐시 수는 N + 1의 성능 문제에 대한 우려가
HotelCommentedEvent {
"comment_id": "id",
"hotel_id": "foo",
"content": "bar"
}
그리고 호텔 정보 서비스는 캐시를이 이벤트로 업데이트합니다. 따라서 단일 테이블 쿼리를 사용하여이 기능을 구현할 수 있습니다.