마이크로 서비스로 전환하면 어떻게 런타임 문제가 발생합니까?

다음 주석 가는 다음과 같이 작성합니다 .

마이크로 서비스는 조직의 기능 장애를 컴파일 시간 문제에서 런타임 문제로 전환합니다.

이 주석자는 다음 과 같은 문제를 확장 합니다.

기능은 버그가 아닙니다. 런타임 문제 => 자극 문제 => 기능 장애에 대한 강력하고 빠른 피드백 책임자

이제 나는 마이크로 서비스 를 통해 그것을 얻습니다 .

• 생산량과 런타임 문제인 처리량의 지연 시간을 늘릴 수 있습니다.
• 구문 분석 오류가 발생할 수있는 코드의 "네트워크 인터페이스"수를 늘리십시오.
• 청록색 배포를 수행 할 수 있습니다. 인터페이스 불일치로 인해 지연 될 수 있습니다 (네트워크 인터페이스 참조). 그러나 청록색 배포가 작동하면 런타임 문제가 더 많습니다.

내 질문은 : 마이크로 서비스로 전환하면 런타임 문제가 발생한다는 것은 무엇을 의미합니까?

문제가 있습니다. 마이크로 서비스를 사용하자! 이제 13 개의 분산 문제가 있습니다.

시스템을 캡슐화, 응집 및 분리 된 구성 요소로 나누는 것이 좋습니다. 다른 문제를 개별적으로 해결할 수 있습니다. 그러나 모 놀리 식 배포에서는 완벽하게 수행 할 수 있습니다 ( Fowler : Microservice Premium 참조 ). 결국, 이것은 OOP가 수십 년 동안 가르쳐 온 것입니다! 구성 요소를 마이크로 서비스로 전환하기로 결정한 경우 아키텍처상의 이점이 없습니다. 기술 선택과 관련하여 약간의 유연성과 확장 성이있을 수 있습니다 (그러나 반드시 그런 것은 아닙니다!). 그러나 (a) 시스템의 분산 특성 및 (b) 구성 요소 간의 통신으로 인해 두통이 발생합니다. 마이크로 서비스를 선택한다는 것은 이러한 문제에도 불구하고 마이크로 서비스를 기꺼이 사용할 수있는 다른 문제가 있다는 것을 의미합니다.

구성 요소로 깔끔하게 분할 된 단일체를 설계 할 수없는 경우 마이크로 서비스 시스템도 설계 할 수 없습니다. 모 놀리 식 코드베이스에서 고통은 분명합니다. 이상적으로 코드는 끔찍하게 손상되면 컴파일되지 않습니다. 그러나 마이크로 서비스를 사용하면 각 서비스를 다른 언어로도 개별적으로 개발할 수 있습니다. 구성 요소를 통합 할 때까지 구성 요소의 상호 작용에 문제가 발생하지 않으며, 그 시점에서 이미 전체 아키텍처를 수정하기에는 너무 늦었습니다.

버그의 1 번 원인은 인터페이스 불일치입니다. 누락 된 매개 변수와 같은 눈에 띄는 실수가 있거나 오류 코드 확인을 잊어 버리거나 메소드를 호출하기 전에 전제 조건을 잊어 버리는 등의 미묘한 예가있을 수 있습니다. 정적 타이핑은 코드가 실행 되기 전에 IDE 및 컴파일러에서 가능한 빨리 이러한 문제를 감지 합니다. 다이나믹 시스템에는이 사치품이 없습니다. 결함이있는 코드가 실행될 때까지 폭발하지 않습니다.

마이크로 서비스에 대한 시사점은 무섭습니다. 마이크로 서비스는 본질적으로 역동적입니다. 공식적인 서비스 설명 언어로 이동하지 않으면 인터페이스 사용법의 정확성을 확인할 수 없습니다. 당신은 테스트, 테스트, 테스트해야합니다! 그러나 테스트는 비용이 많이 들고 철저하지는 않으므로 프로덕션 환경에서 여전히 문제가 발생할 수 있습니다. 그 문제는 언제 명백해 집니까? 프로덕션에서 해당 경로가 잘못된 경우에만 실행됩니다. 자극 문제가 더 빠른 피드백으로 이어질 것이라는 생각은유쾌하게 데이터 손실 가능성에 만족하지 않는 한 위험합니다.

첫 번째 트윗은 내 것이 었으므로 확장하겠습니다.

모 놀리 식 응용 프로그램을 작업하는 100 명의 개발자가 있다고 가정합니다. 서로 효과적으로 의사 소통하기에는 너무 많은 사람들이 있으므로 회사는 작은 팀으로 나누고 그들 사이에 좋은 의사 소통 패턴을 만들기 위해 열심히 노력해야합니다. 조직이 "역기능 적"일 때 팀은 서로 대화하지 않고 더 큰 목표에 부합하지 않으며 우선 순위 등에 동의하지 않으므로 결과적으로 무언가를 배송하는 데 시간이 오래 걸립니다. 소프트웨어가 생산되기 전에 기능 장애가 명백하다는 점에서 "컴파일 시간 문제"입니다. 이 프로젝트는 아마도 죽음의 행진이거나 결코 출항하지 않을 것입니다 ( "컴파일").

저는 많은 사람들이 기술 / 건축 적 이점이 아니라 조직의 기능 장애를 무시할 수 있기 때문에 마이크로 서비스에 관심을 갖고 있으며 이들로 이동하고 있다고 생각합니다. 그들은 개발자 100 명을 조율하는 대신 작은 팀이 사일로에서 일할 수 있기를 희망하며 각각 작은 마이크로 서비스에 중점을 두었습니다. 당신이 그런 역기능적인 조직에 있다면, 이것은 매우 매력적입니다. 그것은 당신이 좋아하지 않는 사람들을 피하고, 의사 소통하지 않기 위해 훨씬 더 큰 허가를줍니다.

안타깝게도 소프트웨어가 프로덕션 환경에서 실행되면 통신이 중요해지기 때문에 "런타임 문제"가됩니다. 조직의 문제 (팀과 팀의 구성 및 의사 소통 방법)는 "런타임"에 나타납니다.

내 트윗의 요점은 당신이 가진 것이 사람들의 문제라면 새로운 아키텍처는 도움이되지 않습니다. 문제의 영향을 지연시킬뿐입니다. 많은 사람들에게 마이크로 서비스의 매력은 이러한 사람들의 문제를 마술처럼 해결할 것이라는 희망이라고 생각합니다.

내 질문은 : 마이크로 서비스로 전환하면 런타임 문제가 발생한다는 것은 무엇을 의미합니까?

그것은 그 트윗이 말하는 것이 아닙니다 ! 그들은 마이크로 서비스로의 전환 에 대해 아무 말도하지 않으며 문제 를 만드는 것에 대해 아무 말도하지 않습니다 . 그들은 변화하는 문제 에 대해서만 말을합니다 .

그리고 그들은 자신의 주장에 대해 문맥 상 제한을 두었습니다. 즉, 조직이 제대로 작동하지 않는다는 것입니다.

그래서, 무엇 첫번째 트윗은 기본적으로 말하고있는 것은 두 가지이다 :

• "귀하의 조직이 현재 마이크로 서비스없이 복잡한 시스템을 엔지니어링 할 수없는 경우에는 마이크로 서비스를 사용하여 복잡한 시스템을 마술처럼 엔지니어링 할 수 없습니다."
• "컴파일 타임 중에, 즉 개발 중에 런타임에 나타나는, 즉 생산 중에 나타날 수없는 문제로 인해 발생하는 문제"(기술적으로는 테스트 중에도 나타날 수 있지만 견적은 그 자체로 제한됨 하위 표준 테스트 제도가있을 가능성이있는 기능 장애 조직에)

두 번째 트윗은 문제가 프로덕션 환경에서만 나타납니다. 즉 고객이 문제를 보는 위치가 버그가 아니라 기능이라는 사실입니다. 조직의 기능 장애에 대해 무언가를 할 수있는 장소 (예 : 높은 수준의 관리) 조직의 기능 장애는 일반적으로 높은 수준의 관리에 실패하기 때문에 불만족스러운 고객은 해당 불만족에 대해 궁극적으로 책임을지는 사람에게 크게 반영하지 않는 반면, 높은 수준의 관리 실패로 인한 낮은 코드 품질은 일반적으로 개발자에게만 반영됩니다. 그러나 잘못이 아니고 그것에 대해 무언가를 할 수 없습니다.

따라서 첫 트윗은 마이크로 서비스가 나쁜 관리로 인한 문제를 컴파일 시간에서 개발자 만 보는 런타임에서 고객이 보는 런타임으로 이동 시킨다고 말합니다. 두 번째 트윗은 그것이 좋은 일이라고 말합니다.

컴파일 타임 문제 와 달리 런타임 문제가 발생합니다.

모 놀리 식 앱은 컴파일하기 어렵고 비용이 많이 듭니다. 그러나 일단 컴파일되면 유형 시스템이이를 잡을 수 있기 때문에 구성 요소간에 멍청한 비 호환성이 존재하지 않는다는 것을 합리적으로 확신 할 수 있습니다. microservive 시스템에서 동일한 오류는 두 가지 특정 구성 요소 가 특정 방식으로 실제로 상호 작용할 때까지 표시되지 않을 수 있습니다 .

모 놀리 식 시스템과 마이크로 서비스 모두 서브 시스템 간의 인터페이스를 정의해야합니다. 인터페이스는 잘 설계되고 문서화되어 있고 가능한 한 안정적이어야합니다. 이것은 OOP와 동일합니다.

조직에서이를 수행 할 수 없으면 마이크로 서비스도 문제를 해결하지 못합니다. 마이크로 서비스에는 공용 웹 인터페이스가 있습니다. 따라서 인터페이스 디자인에 더 많은 노력을 기울여야합니다.

인터페이스가 올바르게 설계되지 않으면 두 가지 종류의 런타임 문제가 발생합니다.

1. 인터페이스가 올바르게 사용되지 않으면 컴파일 타임이 아닌 런타임시 오류가 발생합니다.
2. 웹 인터페이스 호출은 상당히 느리므로 성능 문제가 발생할 수 있습니다.

나는 런타임 문제를 일으키는 것이 책임있는 사람들에게 의사 소통하는 조직적인 문제가 아니라고 생각합니다.