왜 모두가 마이크로서비스를 사용하고 있나요? 정말 그렇게 유용한가요?

복잡한 로봇을 만든다고 상상해 보세요. 모든 부품이 회로 기판에 용접된 경우 소형 모터가 고장 나면 전체 기계를 분해하고 다시 시작해야 할 수도 있습니다. 이는 시간이 많이 걸리고 노동 집약적이며 온전한 다른 부품을 포함하기 쉽습니다. 하지만 각 관절과 각 센서가 독립적으로 작은 모듈로 구성된다면 어떨까요? 교체는 블록을 조립하는 것만큼 쉽습니다. 이것이 아마도 마이크로서비스 아키텍처가 많은 시스템 설계 아이디어를 조용히 변화시킨 이유일 것입니다.

무엇이 문제인가요?

과거에는 많은 소프트웨어가 커다란 철덩어리 같았습니다. 기능이 다 모여있어 한 번의 움직임이 몸 전체에 영향을 미칩니다. 작은 기능을 업데이트하고 싶으신가요? 전체 시스템을 재배포해야 합니다. 갑자기 트래픽이 늘어나나요? 실제로 자원이 필요한 부분이 있더라도 전체적으로만 확장할 수 있습니다. 기술적 선택은 말할 것도 없고, 일단 프레임워크가 선택되면 향후 몇 년 내에 "잠겨" 있을 수 있으며, 그 중 작은 부분이라도 변경하기가 어렵습니다.

이는 동일한 모터 세트와 각 관절에 동일한 컨트롤러를 갖춘 문어 모양의 로봇 팔을 갖고 있는 것과 같습니다. 보기에는 깔끔해 보이지만 손목을 더 유연하게 하고 팔꿈치를 더 튼튼하게 만들고 싶을 때, 시작할 방법이 없다는 것을 알게 됩니다.

마이크로서비스는 어떤 차이를 가져오나요?

첫 번째 매력: 독립성.

각 마이크로서비스는 기계의 독립적인 핸들과 같으며 자체 작업만 담당합니다. 사용자 관리는 로그인 확인만 담당하고 주문 서비스는 거래 프로세스만 담당합니다. 그들은 가벼운 인터페이스를 통해 서로 소통하며, 그것을 깨뜨리는 사람은 다른 사람을 끌어내리지 않고 업그레이드할 것입니다. 오늘 이 중 하나를 새로운 프로그래밍 언어로 다시 작성하시겠습니까? 평상복. 여전히 이웃에게 "인사"할 수 있는 한 다른 서비스는 전혀 변화를 느끼지 않을 것입니다.

두 번째 기능은 탄력적 확장입니다.

방문 횟수가 급증하면 전체 기계를 더 큰 기계로 교체하는 대신 압력이 높은 부품에만 "근육을 추가"합니다. 예를 들어 프로모션 시즌 동안 주문 서비스가 너무 바쁜 경우 주문 마이크로서비스를 몇 개 더 배포합니다. 사용자 초상화 모듈이 유휴 상태이면 그대로 두십시오. 리소스 활용도는 더욱 정교해지고 비용은 더 쉽게 제어할 수 있습니다.

세 번째 매력은 기술적 자유입니다.

모든 서비스가 동일한 도구로 개발되어야 한다고 규정한 사람은 없습니다. 일부는 Python의 빠른 반복에 적합하고 일부는 높은 동시성을 처리하기 위해 Java가 필요합니다. 데이터베이스는 요청 시 선택할 수도 있습니다. 이 데이터베이스는 MySQL을 사용하고, 다른 데이터베이스는 MongoDB를 사용합니다. 팀은 로봇 팔의 각 관절에 가장 적합한 모터 모델을 선택하는 것과 마찬가지로 담당 서비스에 가장 편리한 기술 스택을 선택할 수 있으며 더 이상 "모든 용도에 맞는 단일 크기"로 제한되지 않습니다.

그럼 거기에 두통이 있나요?

물론 있습니다. 서비스가 너무 많아서 조정이 어려워집니다. 과거에는 내부 기능 간에 요청이 호출되었지만 이제는 네트워크의 여러 서비스에 걸쳐 있을 수 있습니다. 이로 인해 대기 시간 문제, 네트워크 안정성 문제 및 데이터 일관성이 발생합니다. 서비스 A는 성공하지만 서비스 B는 실패합니다. 롤백하는 방법은 무엇입니까? 모니터링과 디버깅도 더욱 복잡해졌습니다. 요청이 어떤 경로를 택했는지 알기 위해서는 명확한 서비스 맵이 필요합니다.

이는 로봇 팀을 관리하는 것과 같습니다. 각 팀 구성원이 독립적으로 작업할 수 있다는 것은 좋지만, 좋은 명령 체계, 명확한 통신 프로토콜, 그리고 한 팀 구성원이 실패할 경우 전체 임무를 계속할 수 있는 메커니즘이 필요합니다.

사람들은 선택할 때 실제로 무엇에 관심을 두나요?

어떤 사람들은 다음과 같이 질문할 수 있습니다. 시스템을 마이크로서비스로 나누어야 합니까? 반드시 그런 것은 아닙니다. 귀하의 비즈니스가 단순하고 안정적이라면 전체적인 애플리케이션은 더욱 간단해질 것입니다. 마이크로서비스는 비즈니스가 변화하고, 팀 규모가 확장되고, 신속한 시행착오와 독립적 배포가 필요한 시나리오에서 널리 사용됩니다.

실제로 반영되는 것은 일종의 사고입니다. 즉, 모듈식 및 교체 가능한 구성 요소를 사용하여 유연한 시스템을 구축하는 것입니다. 기계 설계를 할 때와 마찬가지로 모든 변속기를 동일한 섀시에 용접하지 않습니다. 각 장치가 독립적으로 작동할 뿐만 아니라 공동으로 작동할 수 있도록 인터페이스를 예약하고 프로토콜을 표준화하게 됩니다.

이것이 하드웨어 설계와 이상하게 유사하다는 점은 무엇입니까?

서보나 서보 모터를 가지고 놀아본 사람들은 어느 정도 경험이 있을 것입니다. 좋은 모듈형 설계는 모든 회로를 하나의 보드에 집어넣는 것이 아니라 전원 공급 장치, 제어 및 감지가 별도의 모듈을 형성하고 명확한 인터페이스를 통해 연결할 수 있도록 합니다. 이러한 방식으로 모터 드라이브를 디버깅할 때 센서가 실수로 태워지는 일이 없습니다. 컨트롤을 업그레이드할 때 재배선 없이 코어 보드만 교체하면 됩니다.

마이크로서비스의 아이디어도 마찬가지입니다. 이는 "하드웨어" 소프트웨어입니다. 각 서비스는 명확한 기능과 명확한 입력 및 출력 핀(API)을 갖춘 회로 모듈과 같습니다. 내부 구현은 지속적으로 업그레이드되거나 교체될 수도 있습니다. 핀 정의가 변경되지 않는 한 시스템은 원활하게 발전할 수 있습니다.

그렇다면 실제로 어떤 장면에서 빛을 발하는 걸까요?

비즈니스에서 새로운 기능을 신속하게 출시해야 하고 다양한 기능의 수명 주기가 크게 다를 때 팀 규모가 커지고 여러 그룹이 독립적으로 개발, 테스트 및 온라인에 접속할 수 있기를 바랍니다. 시스템이 고르지 않은 트래픽을 처리해야 하고 일부 부분은 큰 압박을 받고 일부 부분은 유휴 상태일 때 마이크로서비스의 장점이 나타납니다.

"큰 기계"를 "소규모 팀 협업"으로 분해합니다. 각 서비스는 한 가지에 초점을 맞추고 표준화된 방식으로 통신하지만, 전체가 복잡한 목표를 달성할 수 있습니다. 이를 위해서는 앞선 디자인 사고와 우수한 인프라 지원이 필요하지만, 일단 실행되면 시스템의 적응성과 발전이 훨씬 빨라지는 경향이 있습니다.

정교한 기계 장치와 마찬가지로 진정으로 안정적이고 유연한 시스템은 많은 전용 모듈로 구성되는 경우가 많습니다. 마이크로서비스가 인기를 끄는 이유는 완벽하기 때문이 아니라, 변화 속에서도 시스템의 민첩성과 탄력성을 유지하는 방법이라는 지속적인 요구에 응답하기 때문입니다. 만능은 아니지만 소프트웨어를 하드웨어 모듈처럼 반복, 교체, 업그레이드할 수 있게 해주는 일련의 사고 도구입니다. 다음에 시스템을 설계할 때 생각해 보십시오. 시스템을 서로 협력하는 독립적인 단위 집합으로 생각한다면 새로운 가능성이 있을까요?

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