기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

서비스 분할:

1. 단일 책임 원칙: 마이크로서비스 아키텍처에서 서비스는 하나의 기능이나 비즈니스 영역만 담당해야 합니다. 각 서비스는 명확한 정의와 경계를 갖고 고유한 특정 비즈니스 영역에만 집중해야 합니다.

2. 서비스 자율성: 서비스 자율성은 각 마이크로서비스가 높은 수준의 자율성을 가져야 함을 의미합니다. 즉, 각 서비스는 독립적으로 개발되고, 독립적으로 테스트되고, 독립적으로 구축되고, 독립적으로 배포되고, 독립적으로 운영될 수 있어야 합니다.

3. 단방향 의존성

마이크로서비스 간에는 단방향 종속성이 있어야 하며 순환 종속성과 양방향 종속성은 엄격히 금지됩니다.

순환 종속성: A->B->C->A

양방향 종속성: A->B,B->A

예:

1. 주문목록

2. 제품 목록

주문 서비스: 주문 ID 제공 및 주문 세부정보 얻기

상품 서비스: 상품 ID를 기준으로 상품 상세정보를 반품합니다.

주문에 따른 주문 정보를 조회할 경우 주문에 포함된 제품 ID를 기준으로 제품 세부 정보를 가져옵니다.

성취하다:

구현 아이디어: 주문 서비스 서비스는 제품 서비스 서비스에 http 요청을 보내고, 반환된 결과를 주문 결과와 병합하여 호출자에게 반환합니다.

구현방법 : Spring에서 제공하는 RestTemplate을 이용

1. RestTemplate 정의

@구성

공개 클래스 BeanConfig{
@콩

공개 RestTemplate restTemplate{

새로운 RestTemplate()을 반환합니다.

      }

}

2. 주문 컨트롤러에서 RestTemplate을 사용하세요.

RestTemplate:

나머지(답장프레젠테이션 에스테이트 티ranfer)는 계층 자원 상태 전송을 나타냅니다.

자원 : 사진, 동영상, 텍스트 등 인터넷상의 데이터는 모두 자원입니다.

프리젠테이션 레이어: 리소스의 표현 형식(예: 텍스트의 표현 형식은 txt, 그림의 표현 형식은 jpg, 일부 리소스는 json, xml, 바이너리 등으로 표현됨)

상태 전송: 네트워크를 통해 리소스에 액세스하고 리소스에 대한 작업(추가, 수정, 삭제 등)을 수행하면 리소스 상태가 변경됩니다. 간단히 말하면 REST는 클라이언트와 서버 간의 상호 작용 형태를 설명합니다. RESTful API(REST 스타일 네트워크 인터페이스)를 설계하는 방법을 사용하면 REST 자체는 실용적이지 않습니다.

편안한 스타일은 일반적으로 다음과 같은 특징을 가지고 있습니다.

1. 자원

2. 통합 인터페이스: 리소스 획득, 생성, 수정, 삭제 등의 작업을 위해 이러한 창은 http 프로토콜에서 제공하는 GET, POST, PUT 및 DELETE 메서드에 해당합니다. 즉, RESTful 스타일 인터페이스를 사용하는 경우입니다. , 인터페이스에서 해당 리소스를 찾을 수만 있을 뿐 구체적으로 어떤 작업을 수행했는지 알 수 없습니다. 구체적으로 어떤 작업이 수행되었는지 알아야 하며 http 요청 메서드 유형(예: 동일한 URL: GET/)에서 판단해야 합니다. blog/{blogId }: 블로그 쿼리 DELETE/blog/{blogId} 블로그 삭제)

RESTful API의 단점:

1. 작업 방식이 번거롭다. RESTful API는 일반적으로 GET, POST, PUT, DELETE에 따라 리소스에 대한 작업 동작을 구분한다.
HTTP 메서드는 직접 관찰할 수 없으며 패킷 캡처와 같은 도구를 통해 관찰해야 합니다. 작업이 URL에 배치되면 더 직관적입니다.
팀의 이해와 의사소통에 더 도움이 됩니다.
2. 일부 브라우저는 GET 및 POST 이외의 요청을 지원하는 데 그다지 친숙하지 않으며 추가 처리가 필요합니다.
3. 리소스에 대한 지나친 강조. 그러나 실제 비즈니스 요구 사항은 더 복잡할 수 있으며 단순히 추가, 삭제, 수정, 검색만으로는 요구 사항을 충족할 수 없습니다.
RESTful API는 개발 난이도와 비용을 증가시킵니다.

프로젝트에 문제가 있습니다
1. 원격으로 호출할 경우 해당 URL의 IP와 포트번호가 하드코딩되어 있습니다(http://127.0.0.1:9090/product/). IP를 변경할 경우 코드를 수정해야 합니다.
암호
2. 발신자가 서비스 제공자의 IP를 어떻게 신뢰하지 않을 수 있습니까?
3. 다중 머신 배포, 부담을 어떻게 분담할 것인가?
4. 원격 호출 시 잘못된 URL을 작성하기가 매우 쉽고 재사용성이 높지 않습니다. 원격 호출을 우아하게 구현하는 방법은 무엇입니까?
5. 모든 서비스에서 이 인터페이스를 호출할 수 있습니다. 위험이 있나요?