마이크로서비스의 설계 원칙

지속되는 무언가 구축: 기술이 겉모습을 넘어서는 경우

그 느낌을 기억하시나요? 프로젝트를 시작합니다. 어쩌면 맞춤형 자동화 장비일 수도 있고 프로토타입을 위한 새로운 제어 시스템일 수도 있습니다. 처음에는 모든 것이 맞습니다. 코드는 깔끔하고 서버는 웅웅거립니다. 그런 다음 기능을 추가합니다. 그리고 또 다른. 한때 단순했던 그 설정이 갑자기 전선이 엉킨 둥지처럼 느껴집니다. 한쪽 구석에 단 하나의 결함이 있으면 모든 것이 더듬거리게 됩니다. 익숙한 것 같나요?

그것은 전형적인 성장통입니다. 한때 아늑한 집이었던 모놀리식 아키텍처는 제약이 됩니다. 업데이트가 무섭습니다. 스케일링은 무차별적인 악몽입니다. 나쁜 코드에 관한 것이 아닙니다. 한계에 부딪힌 디자인에 관한 것입니다.

그렇다면 탈출 경로는 무엇입니까? 최근에는 모두가 마이크로서비스에 대해 이야기하고 있습니다. 그러나 그것은 마법의 유행어라기보다는 사고의 근본적인 변화에 가깝습니다. 하나의 거대하고 상호 연결된 프로그램 대신 더 작고 독립적인 서비스 집단을 구축합니다. 각각은 사용자 인증, 데이터 처리, 모터 명령 라우팅 등 특정 작업을 처리하며 깨끗하고 간단한 API를 통해 서로 통신합니다.

고성능 모듈형 로봇처럼 생각해보세요. 용접을 다 하지 않으시나서보 기구s와 컨트롤러를 단일 블록으로 통합합니다. 팔 움직임을 위한 전용 모듈, 센서 처리를 위한 모듈, 궤적 계획을 위한 세 번째 모듈이 있습니다. 그리퍼에 업그레이드가 필요한 경우 해당 모듈만 교체하면 됩니다. 나머지 시스템은 계속 작동합니다. 이것이 바로 마이크로서비스 사고방식입니다.

왜 매듭을 풀어야 하는가?

현실이 되자. 시스템의 핵심 철학을 재배선하는 것은 주말 프로젝트가 아닙니다. 노력이 필요합니다. 그렇다면 왜 할까요? 이점은 단지 이론적인 것이 아닙니다. 그들은 일상적인 일에서 느껴집니다.

첫째, 탄력성이 있습니다. 모놀리식 시스템에서는 부 라이브러리의 오류로 인해 전체 애플리케이션이 중단될 수 있습니다. 마이크로서비스를 사용하면 오류가 격리됩니다. 로깅을 관리하는 서비스에 문제가 발생하는 경우 실시간 모터 제어를 처리하는 서비스가 중단 없이 계속 실행될 수 있습니다. 시스템 성능이 심각하게 저하되지 않고 정상적으로 저하됩니다.

그런 다음 의미있는 스케일링이 있습니다. 이미지 처리 워크로드에는 더 많은 성능이 필요하지만 사용자 데이터베이스에는 필요하지 않습니까? 마이크로서비스를 사용하면 필요한 것만 확장할 수 있습니다. 성능과 비용 모두 효율적입니다. 더 이상 모든 작은 문제에 더 큰 서버를 투입할 필요가 없습니다.

마지막으로 속도와 자율성에 관한 것입니다. 팀은 대규모의 동기화된 릴리스를 기다리지 않고도 서비스를 개발, 테스트 및 배포할 수 있습니다. 병행개발입니다. 혁신은 더 이상 교통 체증이 되지 않습니다.

좋아요, 확신해요. 새로운 혼란을 일으키지 않고 어떻게 시작하나요?

마이크로서비스를 채택하는 것은 단순히 기존 코드를 잘라내는 것이 아닙니다. 이는 새로운 디자인 원칙에 관한 것입니다. 이것이 잘못되면 하나의 단일체 골칫거리를 분산 골칫거리로 바꾸게 될 것입니다. 여기에 실용적인 내용, 실제 지침이 있습니다.

1. 단일 책임 원칙은 귀하의 법칙입니다. 이것이 핵심입니다. 각 서비스는 한 가지 일을 수행해야 하며, 그 일을 매우 잘 수행해야 합니다. 귀하와의 커뮤니케이션을 관리하는 것입니까?kpower 서보 기구컨트롤러? 그것이 바로 우주입니다. 운동학적 사슬을 계산하는 것인가요? 그것은 별개의 세계입니다. 처음부터 명확한 경계를 설정하면 새로운 "마이크로" 서비스가 천천히 "미니 모놀리스"로 다시 변하는 것을 방지할 수 있습니다.

2. 긴밀한 결합이 아닌 스마트 계약(API)을 설계하십시오. 서비스는 API를 통해 통신합니다. 이를 잘 정의된 계약이나 핸드셰이크 프로토콜로 생각하세요. 다른 서비스가 내부적으로 작동하는 방식이 아니라 안정적이고 버전이 관리되어야 하며 필요한 것에 초점을 맞춰야 합니다. 이 느슨한 결합을 통해 유지 관리를 위해 전체 시스템을 끌지 않고도 서비스를 자유롭게 업데이트하거나 다시 작성할 수 있습니다.

3. 분산형 데이터 관리를 수용합니다. 이것은 종종 직관에 반하는 느낌을 줍니다. 각 서비스는 전용 데이터베이스를 소유하고 관리해야 합니다. 사용자 프로필 서비스는 사용자 데이터를 소유합니다. 주문 처리 서비스는 자체 트랜잭션 로그를 소유합니다. 그들은 서로의 데이터베이스에 직접 접근하지 않습니다. API를 통해 질문합니다. 이렇게 하면 단일 공유 데이터베이스가 병목 현상을 일으키고 모든 것의 실패 지점이 되는 악몽을 피할 수 있습니다.

4. 첫날부터 실패에 대비하세요. 분산된 세계에서는 모든 것이 실패할 것입니다. 네트워크가 깜박입니다. 서비스 시간이 초과되었습니다. 그래서 당신은 그것을 위해 디자인합니다. 회로 차단기(실패한 서비스 호출을 중지하기 위해), 지수 백오프를 사용한 재시도 및 우아한 대체와 같은 패턴을 구현합니다. 시스템은 순진하게 낙관적이지 않고 회의적이고 회복력이 있어야 합니다.

5. 관찰 가능성은 선택 사항이 아닙니다. 수십 개의 서비스가 있는 경우 기존 디버깅이 필요하지 않습니다. 로그를 확인하고, 서비스 전반에 걸쳐 흐르는 요청을 추적하고(분산 추적), 상태 지표를 모니터링하려면 중앙 위치가 필요합니다. 볼 수 없으면 관리할 수 없습니다. 이 인프라는 서비스 자체만큼 중요합니다.

방정식의 인간적 측면

기술 다이어그램에서 길을 잃기 쉽습니다. 그러나 마이크로서비스로의 전환은 팀 전환이기도 합니다. API 계약, 독립적 소유권, 시스템 수준 사고를 중시하는 문화가 필요합니다. 보상은? 팀은 마찰을 줄이고 더 빠르게 움직입니다. 시스템은 만지기 두려운 깨지기 쉬운 유물이 아니라 유연하고 적응 가능한 자산이 됩니다.

이는 오늘만 효과가 있는 것이 아니라 내일의 야망에 따라 진화하고 성장할 수 있는 무언가를 구축하는 것입니다. 당신은 당신의 아키텍처와 싸우는 것을 멈추고 그것이 당신에게 힘을 실어주기 시작합니다. 변화만이 변함없는 세상에서 이는 단지 기술적인 이점이 아니라 지속적인 이점입니다.

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