Feathers: 마이크로 서비스 : 서비스를 분할하여 앱을 리팩토링하는 권장 방법?

당신 말이 맞아요, 아직 문서가 너무 많지 않았고 우리는 그것을 추적하기 위해 조금 전에 https://github.com/feathersjs/feathers/issues/157 을 만들었습니다. 언급하신 두 가지 주제에 대한 제 생각은 다음과 같습니다.

처음에 두 개의 서비스가있는 서버가 있다고 가정 해 봅시다.

app.use('/users', memory())
  .use('/todos', memory());

사용자 서비스는 한 서버가 처리 할 수있는 것보다 많은 트래픽을 받고 있으므로 다른 앱을 만들어 다른 시스템으로 이동하려고합니다.

// server1
app.use('/users', memory());
// server2
app.use('/todos', memory());

이제 /todos 서비스가 원격 서비스와 통신하려면 Feathers를 클라이언트 로 사용하여 연결할 수 있습니다 (웹 소켓은 빠르고 양방향이므로 서버 간 통신에 사용하지 않는 이유는 무엇입니까?).

// server2
const client = require('feathers/client')
const socketClient = require('feathers-socketio/client');
const io = require('socket.io-client');

const socket = io('http://other-server.com');
const otherApp = client().configure(socketClient(socket));

app.use('/todos', memory())
 .use('/users', otherApp.service('users'));

이것은 기본적으로 웹 소켓 연결을 통해 사용자 서비스를 원격 서비스에 투명하게 전달합니다. 원래 /users 엔드 포인트를 사용하는 것은 아무것도 변경할 필요가 없습니다.

인증과 관련하여 다양한 옵션이 있습니다. 위의 시나리오에서 가장 쉬운 방법이 될 것입니다 server1 이후 다른 서버 IP 주소 만 허용 목록에 server2 여전히 클라이언트 통신의 유일한 지점입니다. 결국 server2 는 사용자 인증을 처리 한 다음 서비스 호출을 다른 서버로 전달하는 게이트웨이가 될 수 있습니다 (원본 IP 주소 확인 외에 인증에 대해 걱정할 필요가 없음).

응답 해 주셔서 감사합니다! 공식 문서 (가이드의 하위 섹션)에서이 주제를 다룰 계획입니까? 이와 관련하여 제가 기여할 수 있는지 알려주십시오.

명확히. 그리고 우리는 확실히 도움을받을 수 있습니다. 가이드에서보고 싶은 내용을 먼저 모아서 데모 애플리케이션을 만들어 보겠습니다.

💯 @daffl 이 강타합니다. 이것은 발표를하기로 약속 한만큼 다음 달에 공식적으로 다룰 계획입니다.

@daffl 백엔드 마이크로 서비스에서 feathers-client를 사용하는 방법은 socket.io가 사용되기 때문에 스트리밍 데이터를 통한 양방향 통신을 허용합니다. Feathers에는이 시나리오에 대한 의미 / API가 이미 있습니까? 마이크로 서비스가 브라우저 클라이언트가 아닌 다른 관심있는 마이크로 서비스에 대한 이벤트를 게시하는 상황을 생각하고 있습니다.

예,하지만 관심있는 다른 서비스도 웹 소켓을 사용할 수없는 이유는 무엇입니까? 우리는 다른 공급자 (예 : 다른 메시징 서비스)를 추가하려고 생각하고 있지만 지금은 웹 소켓이 충분히 빠르며 브라우저에서만 사용할 수있는 곳에 작성되지 않았습니다.

@daffl @ekryski 는 페더 애플리케이션이 배포

@daffl 나는 당신의 대답 전에 잘 이해하지 못했다고 생각합니다. 관심있는 서비스가 웹 소켓을 사용하여 생산자 서비스를 구독하는 한, 일반 이벤트 API를 사용하여 생산자에 새 이벤트를 게시하는 한이를 깃털로 구현하는 것으로 충분합니다.

@justingreenberg에 동의합니다. 해결해야 할 또 다른 문제는 책임있는 마이크로 서비스가 오프라인 (충돌, 업데이트 등)이 될 때 요청을 재생하는 것입니다. 기술적으로 이것은 메시지 큐를 사용하는 주소이기도합니다.

이것에 대한 진전이 있습니까? 나는 몇 가지 문서 / 작동 예제를보고 싶습니다. 특히 인증이 처리되는 방법과 관련하여.

@imns 우리는 이것을 위해 노력하고 있습니다. 예제 작업을 시작하고 앱을 분할했고 인증 설정 방법에 몇 가지 제한이 있음을 깨달았습니다. 그래서 우리는 현재 이것을 더 잘 지원하기 위해 인증을 리팩토링하고 있습니다. 착륙하는 데 약 일주일이 걸립니다.

오 이런, 지금 이거 너무 나쁘게 쓸 수 있어요 : D

호기심 때문에 여러 프런트 엔드에서도 작동하도록 인증을 재 작업하고 있습니까? 오늘날 많은 대형 앱이 백엔드에서 마이크로 서비스를 사용하지만 프런트 엔드 앱도 분리한다고 생각합니다.

약간의 추가 비용이 있다면이 책을 추천하는 것으로 간주 할 수 있다고 생각합니다 : https://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/ref=sr_1_1 ? ie = UTF8 & qid = 1469071253 & sr = 8-1 & keywords = 마이크로 서비스

여러분, 이것에 대한 업데이트가 있습니까? 감사합니다.

@juanpujol 최신 정보는 항상이 티켓에 있습니다. 그래도 확인해 주셔서 감사합니다.

(marcfawzi 여기)

전체 스레드를 읽지는 않았지만 서비스별로 데이터베이스를 사용할 수 있다고 가정합니다 (이 분리가있는 Micreoservices 아키텍처에서는 추상화를 유지하는 데 중요합니다. 그렇지 않으면 모든 서비스가 동일한 데이터베이스를 공유하면 사람들을 방해합니다 균일 한 서비스 API를 사용하여 서비스를 구성하는 대신 서비스 모델 (마이크로 서비스 추상화 위반)간에 관계를 정의하는 것으로부터?

그것을 막는 것은 아무것도 없습니다. 그렇게하지 않는 것은 당신에게 달려 있다고 말하고 싶습니다. ORM 수준에서 모델과 관계를 정의하는 경우에만 실제로 문제가됩니다. 다른 서비스를 호출하여 서비스 수준에서 관계를 얻는 것이 마이크로 서비스 추상화를 위반한다고 생각하지 않습니다.

네, 정확히 제가 의미 한 바입니다. 각 서비스에 자체 DB가있는 서비스 분리는 ORM 수준이 아닌 서비스 인터페이스를 통해 구성을 강제하는 확실한 방법이라고 생각하는 경향이 있습니다.

그러나 Feathers는 마이크로 서비스 프레임 워크보다 더 일반적이므로 여기에서 모두 좋습니다. 감사합니다 David! 이것은 내가 더 많이 파헤칠수록 더 좋아지고 더 좋아 보입니다! 주위에 훌륭한 일!

마이크로 서비스 환경에서 Feathers를 사용할 때 발생하는 몇 가지 문제를 해결하기 위해 여기에서 이것을 언급 할 것이라고 생각했습니다. 이것은 첫 번째 구현 일 뿐이지 만 기여할 것이 있으면 여기 https://github.com/zapur1/feathers-rabbitmq/issues/1

@ zapur1 유망 해 보입니다 ... 토론을 시작하기 위해 댓글을 게시했습니다.

https://github.com/feathersjs/feathers-sync 와 rabbitMQ, Redis 또는 MongoDB를 서비스 사이의 메시지 브로커로 사용하여 모두 동기화 상태를 유지할 수도 있습니다.

@ekryski feathers-sync 는 약간의 다른 문제를 해결합니다. 이름이 지정된 서비스 (Feathers 서비스가 아니라 마이크로 서비스 스타일 서비스) 영역 내에서 이벤트를 한 번만 수신하려면 어떻게해야합니까? 단일 API 앱에서 이벤트를 수신하는 단일 서비스의 여러 인스턴스가있는 경우 각 인스턴스는 정확히 동일한 코드의 여러 인스턴스에서 해당 이벤트가 수신 될 때 수행되는 작업을 복제 할 가능성이있는 이벤트를 수신합니다.

@ekryski 방금 repo를 다시 봤는데 zapur1 / feathers-rabbitmq가 "Caveats"에서 언급 한 정확한 문제를 해결합니다.

socketClient로 서비스 1을 서비스 2에 연결하면 서비스 2에 다중 인스턴스가 있으면 어떻게로드 밸런스를 구현할 수 있습니까?

socketClient를 통해 연결하는 별도의 서버 측 앱을 만드는 경우 설정된 제한 사항에 관계없이 서비스를 사용할 수 있도록 인증하는 가장 좋은 방법은 무엇입니까?

https://github.com/kalisio/feathers-distributed를 사용 하여 2 센트를 추가합니다. 서로 다른 서비스를 함께 사용하는 N feathers 앱을 배포하여 각 서비스를 독립적으로 개발할 수 있습니다. 내가 이해하는 한 동일한 서비스를 보유한 N feathers 앱을 배포하는 것을 목표로하는 https://github.com/feathersjs/feathers-sync 와는 다릅니다. 이 모든 것이 다음과 같은 질문을 제기합니다.

• 인증 관리
• API 게이트웨이 및 부하 분산
• 원격 후크 호출
• ...

서버 1 및 서버 2와 관련하여 제공 한 예제에서 @daffl , 서버 2에서 /users 서비스를 어떻게 보호 하시겠습니까? 서버 2에 해당 서비스를 정의했다면 특정 서비스 후크 파일에서 후크를 사용할 수 있지만 app.use('/users', otherApp.service('users')); 수행하고 있으므로 서버 2에서 해당 서비스에 대한 호출 만 수행되도록하려면 어떻게해야합니까? 사용자가 먼저 인증 된 경우?

편집하다:
Nvm, 나는 아이디어가 있다고 생각합니다. const usersService = app.service('users') 와 usersService.hooks(hooks) 와 같은 작업을 할 수 있습니다. 여기서 후크에는 엔드 포인트를 보호하는 데 필요한 인증 후크가 있습니까?

https://stackoverflow.com/questions/41076627/evaluating-featherjs-authentication-needs/41095638#41095638 에서 분산 인증을 수행하는 방법에 대해 자세히 썼습니다.

각각의 장점과 단점이있는 서비스를 분할하는 여러 가지 방법이 있습니다. Feathers에서 일반적으로 중요한 것은 세션이없고 JSON 웹 토큰 만 있다는 것입니다. JWT는 상태 비 저장이며 동일한 비밀을 공유하는 모든 서버에서 읽을 수 있으므로 중앙 세션 저장소가 없어도됩니다. 내가 생각할 수있는 두 가지 주요 옵션은 다음과 같습니다.

1. 인증을 처리하고 연결된 모든 클라이언트를 관리하는 메인 애플리케이션이 있지만 데이터베이스와 통신하는 서비스 대신 내부 네트워크의 별도의 간단한 개별 API 서버에 연결합니다. 이것은 더 쉬운 설정이고 장점은 내부 API 서버가 매우 간단 할 수 있고 인증이 전혀 필요하지 않다는 것입니다 (메인 애플리케이션이 모든 것을 수행 할 수 있고 인증 된 사용자 제한에 따라 쿼리를 작성하기 때문에). 단점은 기본 애플리케이션이 여전히 병목 상태에 있다는 것입니다 (하지만 기본적으로 내부 API에 대한 프록시 역할을하기 때문에 부하가 감소 함).

1. 모든 클라이언트는 JWT를 사용하여 필요한 모든 API 서버에 연결합니다. JWT는 별도의 인증 (또는 사용자) API에 의해 생성됩니다. 유일한 병목 현상은 공통 사용자 서비스 (항상 필요하지는 않을 수도 있음)에서 가장 최신 사용자 정보를 검색하는 것이므로 확장 성이 더 뛰어난 솔루션입니다. 단점은 클라이언트 측에서 관리하는 것이 더 복잡하고 모든 서버에서 인증 (적어도 JWT의 경우)을 구성해야한다는 것입니다. 그러나 JWT의 상태 비 저장으로 인해 공유 세션이 필요하지 않습니다.