2017-03-09 4 views
0

전자 상거래 응용 프로그램을위한 마이크로 서비스 아키텍처를 실행했습니다. 각 테이블에는 기본적으로 CRUD 작업 (각 테이블의 나머지 클라이언트처럼)이있는 자체 마이크로 서비스가 있습니다. 이제 비즈니스 도메인을 중심으로 비즈니스 모델을 결합하고 모델링 한 다음, 그러한 상황에 직면 한 사람이 누구인지 파악하고 올바른 아키텍처인지 아닌지에 대해 생각하고 있습니다. 제안 사항은 매우 유용 할 것입니다. 감사합니다. .마이크로 서버 당 데이터베이스 테이블

+1

각 microservice 도움이 될 것입니다 생각하지 않습니다 . 그들은 같은 집요함을 공유해서는 안됩니다. 자세한 내용은 여기 읽기 : https://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/ref=pd_sim_14_29?ie=UTF8&dpID=5156gHBSxaL&dpSrc=sims&preST=_AC_UL160_SR122%2C160_&refRID=0081XVQGTK2AQ54GQ21P –

+0

감사 콘스탄틴 응답을 I 마이크로 서비스가 구현 및 데이터베이스를 숨겨야한다는 것에 절대적으로 동의하지만이 경우 각 테이블마다 별도의 마이크로 서비스가 있습니다. 예를 들어 테이블 A에 대해서는 B 마이크로 서비스 B에 대해 MicroserviceA가 있고 각 테이블에 대해 동일한 수의 테이블이 얼마나 많은 마이크로 서비스가 있는지를 나타냅니다. –

답변

2

다른 관련없는 것들을 혼합하고 있습니다.

(마이크로) 서비스는 특정 작업을 수행하는 논리적 엔터티입니다. 그들은 더 큰 범위의 작업을 수행하기 위해 다른 서비스와 통신합니다.

테이블/CRUD/SQL/NO-SQL은 전체 레벨이 다릅니다. 데이터가 저장되고 액세스되는 방법.

서비스가 SQL을 사용하고 테이블을 가지고 있다는 사실. 또한 각 서비스마다 별도의 테이블을 갖는 것이 좋습니다. 심지어 2 개의 서비스가 같은 테이블을 직접 사용한다면 아마도 디자인 문제를 겪고 있다고 말할 수 있습니다.

하지만 서비스를 테이블과 동일시 할 수는 없지만 개념 상 서로 다른 세계에 속합니다.

1

각 마이크로 서비스에는 다른 마이크로 서비스가 액세스 할 수없는 고유 한 SQL 테이블 집합이 있어야합니다. 그러나 SQL 테이블 당 하나의 마이크로 서비스가 있고 각 마이크로 서비스가 CRUD 작업 만 지원하는 것은 일반적으로 안티 패턴입니다. 강력한 DBMS 및 쿼리 언어를 간단한 레코드 관리자로 변환합니다. 교차 테이블 트랜잭션, 조인, 필터링, 정렬, 페이지 매김 등

1

마이크로 서비스는 모든 응용 프로그램에 대한 논리 블록으로, SQL 수준에서 그들을 결합하여 어떤 의미가 없습니다.

예를 들어 고객이 주문할 수있는 주문 서비스를 만드는 경우를 생각해 봅시다.

이제 주문에는 주문 항목도 포함될 수 있으며 고객 개체 참조가있을 수 있습니다. 이러한 모든 주문에 대해 여러 테이블을 만들 수 있습니다. 그래서 당신이 여전히 의심이 더 정확한 질문을 게시하는 경우 SQL 테이블과 함께

microservices는, 별도의 테이블 및 서비스 간 통신 네트워크 throught를 수행해야합니다 :)