머리말
이제 점점 더 많은 회사들이 Spring Cloud를 수용하고 있습니다. Spring Boot는 차세대 웹 프레임 워크이며 Spring Cloud는 최신의 가장 인기있는 마이크로 서비스의 리더입니다. 거절해야 할 이유는 무엇입니까? Java의 많은 학생들도 Spring Cloud를 적극적으로 배우기 시작했습니다. 실제로 여기에는 또 다른 문제가 있습니다. 모두가 Eureka, Ribbon, Hystrix, Zuul, Feign 등을 배웠지 만 여전히 실제 프로젝트에 적용하기가 어렵습니다.
마이크로 서비스의 어려움은 서비스 분할에 있습니다. 프레임 워크는 단지 도구 일 뿐이며 많은 사람들이 그것을 사용할 것입니다. 서비스 분할과 서비스 간의 관계는 분할 중에 고려해야 할 사항입니다.
오늘 반 친구가 다음 두 가지 질문에 대해 저에게 이메일을 보냈습니다.
다음은 내 자신의 경험을 기반으로 한 몇 가지 답변입니다.
첫 번째 질문의 API와 관련하여 각 마이크로 서비스의 컨트롤러가 있습니까?
우리가 API라고 부르는 것은 실제로 인터페이스이며, 대부분은 컨트롤러에 주석이 달린 메소드 인 Spring MVC를 사용하여 개발됩니다. 주석은 우리가 자주 사용하는 것입니다.
첫 번째 질문과 관련하여 다른 마이크로 서비스의 컨트롤러를 캡슐화하려면 통합 프로젝트가 필요합니까?
실제로 고정 패턴이 없습니다. 이 중 대부분은 API 게이트웨이를 통해 비즈니스 서비스로 직접 전달됩니다.
Yuantiandi와 같은 블로그 웹 사이트의 비즈니스 범주를 예로 들어보십시오.
비즈니스 기능이 있습니다. 특정 블로그 게시물을 보면 반환 해야하는 정보는 다음과 같습니다.
이 시점에서 기사를 보는 인터페이스에는 실제로 데이터의 세 부분, 기사 자체의 정보, 댓글 정보 및 저자의 정보가 포함됩니다.
3 가지 서비스, 사용자 서비스, 블로그 서비스 및 의견 서비스가 있습니다.
따라서 문제는 이전에 여러 서비스 간의 상호 작용을 포함한다는 것입니다. 사실, 위의 반 친구와 같은 질문이 나에게 물었다. 통합 프로젝트가 필요하고 다른 서비스를 조립해야합니까? 서로 부를 수 있습니까?
이것을 구현하는 두 가지 방법을 권장합니다.
1. API 게이트웨이는 블로그 서비스로 직접 전달됩니다.
API는 블로그 게시물 정보를 얻기위한 인터페이스입니다. 본체는 블로그 서비스 여야합니다. 블로그 서비스에는 블로그 게시물 정보에 대한 인터페이스가 있습니다. 인터페이스에서는 사용자 서비스에서 제공하는 사용자 정보 인터페이스를 호출하고 댓글 서비스에서 블로그 게시물 댓글 정보도 호출합니다. 의사 코드를 보자.
@getMapping ( "/blog/detail/{id}") public bloginfo blogInfo (@pathvariable ( "id") long id) {// 블로그 정보 블로그 = blogservice.getByid (id); // 사용자 정보 가져 오기 userInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // 댓글 정보 정보 주석은 camilInfo = commentFeignClient.getCommentInfo (id); 반품 모든 정보를 조립하고 반환합니다. }2. 집계 서비스 계층을 추가하십시오
컬렉션 서비스 계층은 위의 급우입니다. 조립 서비스를 수행하기 위해 통일 된 프로젝트가 필요합니까? 즉, 블로그 서비스는 여전히 기본 블로그 정보를 제공하며 별도의 비즈니스 집계 서비스가 추가 되어이 정보를 조립하고 발신자에게 균일하게 반환합니다. 의사 코드는 다음과 같습니다.
@getMapping ( "/blog/detail/{id}") public bloginfo blogInfo (@pathvariable ( "id") long id) {// 블로그 정보 블로그 = blogfeignclient.getByid (id); // 사용자 정보 가져 오기 userInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // 댓글 정보 정보 주석은 camilInfo = commentFeignClient.getCommentInfo (id); 반품 모든 정보를 조립하고 반환합니다. }데이터를 원격으로라고하며, 물론 여기에서 병렬로 호출 할 수 있습니다. 또 다른 방법은 API 게이트웨이에서 집계 작업을 수행하는 것입니다. 이 솔루션도 실현 가능합니다. 나는 게이트웨이에서 그것을하지 않는 것이 좋습니다. API 게이트웨이는 가능한 한 간단하고 전진합니다. 집계 서비스 계층을 추가하는 것이 좋습니다.
서비스 거버넌스가 Dubbo로 구축되면 집계 서비스 계층도 더 나은 방법입니다. Dubbo Service Aggregation은 외부 통화에 HTTP 인터페이스를 제공합니다.
3. 발신자는 스스로 다양한 데이터를 얻습니다
또 다른 방법은 블로그 인터페이스, 댓글 인터페이스 및 사용자 인터페이스 자체를 호출하는 것입니다. 이러한 방식으로 인터페이스는 자체 데이터에주의를 기울이고 어셈블리 문제를 사용자에게 전달하면됩니다. 이것은 일반적으로 덜 사용됩니다. 한 번에 데이터를 발신자에게 반환하고 특히 모바일 터미널에서 반복적으로 호출하는 것이 가장 좋습니다.
요약
데이터를 조립하는 방법에 대해서는 직접 데이터를 결정해야합니다. 해당 비즈니스 서비스에 어셈블리를 배치하거나 집계 서비스를 추가하여 별도로 조립하거나 클라이언트가 자체적으로 조립할 수 있습니다.
서비스는 분명히 서로 호출 될 수 있습니다. 그들이 서로 부를 수 없다면, 그들을 분리하는 요점은 무엇입니까? Feign을 사용하여 서비스 인터페이스를 호출하면 서비스 간의 통화로 취급하십시오.
좋아, 위는이 기사의 전체 내용입니다. 이 기사의 내용에 모든 사람의 연구 나 작업에 대한 특정 참조 가치가 있기를 바랍니다. 궁금한 점이 있으면 의사 소통을 위해 메시지를 남길 수 있습니다. Wulin.com을 지원 해주셔서 감사합니다.