마이크로서비스가 "대화"하기 시작할 때: API만으로 충분합니까?

각 모듈이 정밀한 장비처럼 작동하는 아름다운 마이크로서비스 아키텍처를 설계합니다. 그러나 어느 날 코드를 보다가 갑자기 궁금해집니다. 이 마이크로서비스가 두 개 이상의 "인터페이스"를 가질 수 있습니까? 동일한 장치에 여러 개의 플러그를 사용하는 것처럼 중복됩니까? 아니면 좀 더 유연해질까요?

"단일 API"를 사용한 심야 디버깅

기계 제어 분야에서 일하는 친구가 자신의 팀이 한때 서보 모터 시스템을 위한 마이크로서비스를 설계했는데 각 기능 모듈이 하나의 API 엔드포인트만 열었다고 말한 것을 기억합니다. 깔끔한 것 같죠? 결과는? 서보 매개변수를 조정해야 할 때마다 동일한 인터페이스에 점점 더 많은 매개변수 옵션을 채워야 합니다. 디버그 로그는 복잡해지고 버전 업데이트는 줄타기를 하는 것과 같습니다. 하나의 작은 기능을 변경하면 완전히 관련되지 않은 다른 호출에 영향을 미칠 수 있습니다.

“마치 스위스 군용칼로 섬세한 수술을 하는 것 같아요.” 그가 쓴웃음을 지으며 말했다. "도구는 다기능이지만 정밀한 제어에는 한계가 있습니다."

다중 API 설계: 복잡성을 증가시키는 것이 아니라 경계를 명확하게 하기 위한 것

마이크로서비스에 여러 API가 있다는 것은 무엇을 의미합니까? 집에 있는 사운드 시스템을 상상해 보세요. 리모컨을 사용하여 켜고 끌 수 있고, 모바일 앱을 사용하여 이퀄라이저를 조정하고, 패널 버튼을 사용하여 입력 소스를 전환할 수 있습니다. 이는 모두 동일한 장치로 연결되는 "인터페이스"이지만 각각의 책임은 분명합니다.

기술적 수준에서 이는 다음을 의미합니다.

• 기능 분리: 하나의 API는 실시간 제어 명령을 처리하고, 다른 API는 매개변수 구성을 관리하고, 세 번째 API는 상태 모니터링을 담당합니다.
• 버전 관리가 더욱 유연해졌습니다.: 전체적으로 업그레이드할 필요 없이 다양한 기능을 독립적으로 반복할 수 있습니다.
• 명확한 보안 경계: 민감한 작업과 일반 쿼리에는 인증 요구 사항이 다를 수 있습니다.

어떤 사람들은 그것을 사용합니다.kpower서보 솔루션 엔지니어들은 다음과 같이 공유했습니다. "우리는 모션 제어 마이크로서비스를 위해 3개의 API 엔드포인트를 설계했습니다. 하나는 고주파 명령 전송(낮은 대기 시간 필요)에 사용되고, 다른 하나는 배치 매개변수 구성에 사용되며(약간 높은 대기 시간은 허용되지만 안정성이 필요함) 읽기 전용 인터페이스는 모니터링에 사용됩니다. 예기치 않게 시스템 디버깅 시간이 약 40% 단축되었습니다."

이 디자인이 필요한지 어떻게 알 수 있나요?

모든 마이크로서비스에 여러 API가 필요한 것은 아닙니다. 스스로에게 몇 가지 질문을 해보세요:

• 귀하의 서비스는 동시에 매우 다양한 데이터 유형을 처리합니까? (예: 실시간 스트리밍 데이터 및 정적 구성)
• 다양한 기능에 대한 호출 빈도에 큰 차이가 있습니까?
• 작업 간에 안전 요구사항이 명확하게 등급화되어 있습니까?

하나 이상의 대답이 '예'라면 다중 API 설계를 고려해 볼 가치가 있습니다.

캐비닛의 이론부터 실제 배선까지

개념은 훌륭해 보이지만 실제로 배포할 때 주의해야 할 점은 무엇입니까? API가 여러 개 있다고 해서 엔드포인트를 마음대로 추가할 수 있다는 의미는 아닙니다. 각 인터페이스는 기계 시스템의 각 센서와 마찬가지로 명확한 "책임 범위"를 가져야 합니다. 각 인터페이스는 서로 간섭하지 않고 자체 임무를 수행합니다.

문서화가 특히 중요해집니다. 명확한 지침을 통해 진입점이 여러 개인 경우 혼란을 피할 수 있습니다. 좋은 방법은 다양한 도구에 대한 방법 가이드처럼 각 API에 대해 별도의 사용 예제를 작성하는 것입니다.

모니터링을 조정해야 합니다. 일반적인 용어로 "전체 서비스" 데이터를 보는 것이 아니라 각 API에 대한 성능 지표를 개별적으로 추적할 수 있어야 합니다. 이렇게 하면 문제를 더 빨리 찾는 데 도움이 됩니다.

계획을 선택할 때 숨겨진 고려 사항

기술 솔루션을 평가할 때 사양 외에도 쉽게 간과할 수 있는 몇 가지 세부 사항이 있습니다.

• 문서가 실제 시나리오를 다루고 있나요?? 좋은 문서에서는 매개변수 목록뿐만 아니라 "서보 과부하 보호 시나리오에서 API를 호출하는 방법"을 알려줍니다.
• 오류 메시지가 디버깅에 도움이 됩니까?? 호출 오류가 발생하면 반환되는 정보는 일반적인 "작업 실패"가 아닌 특정 문제를 가리켜야 합니다.
• 생태학적 도구가 완성되었나요?? 예를 들어, 여러 API용으로 설계된 테스트 도구 템플릿이 있습니까?

이러한 세부 사항은 실제 사용 시 얼마나 매끄러운지를 결정하는 경우가 많습니다.

시작하기 위한 실제 단계

다중 API 설계를 시도하기로 결정했다면 작은 서비스부터 시작하십시오.

1. 명확한 기능 경계가 있는 서비스 모듈을 선택하세요.
2. 최소한 두 가지의 서로 다른 통화 패턴을 식별합니다(예: 데이터 양이 적은 고주파수와 데이터 양이 많은 저주파)
3. 매개변수를 단순하게 유지하기 위해 두 개의 독립적인 API 엔드포인트를 설계합니다.
4. 배포 후 두 엔드포인트의 성능 차이를 면밀히 모니터링합니다.
5. 미리 설정된 이론이 아닌 실제 데이터를 기반으로 조정

기술적 결정에는 절대적인 정확성이 없다는 점을 기억하십시오. 중요한 것은 귀하의 디자인이 시스템과 시스템을 유지 관리하는 사람들이 보다 원활하게 작동하도록 만드는지 여부입니다. 기계 설계와 마찬가지로, 최고의 솔루션은 정밀도와 유연성 사이의 균형을 맞추는 솔루션인 경우가 많습니다.

귀하의 마이크로서비스는 다양한 방식으로 "대화"할 준비가 되어 있습니까? 아마도 이 주제는 다음 아키텍처 논의 중에 화이트보드에 언급될 가치가 있을 것입니다. 결국, 좋은 디자인은 단번에 완성되는 것이 아니라, 사람 간이든 서비스 간이든 지속적인 대화를 통해 명확해집니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.