우리는 아주 오래된 학교 접근 방식으로 돌아가서 마이크로 서비스를 만났습니까?

소프트웨어 아키텍처 및 디자인 측면에서 마이크로 서비스는 미들웨어와 어떻게 "스택"됩니까? 나는 Java에서 왔으며 API로 straight REST에서 벗어나 다른 레이어와 연결 매개 변수를 추상화하면 적어도 Java에서는 거의 오래된 학교 아이디어로 돌아 왔습니다. . JVM이 이미 가상 인 경우 가상화로 돌아 왔습니다 .

불가피한 방식으로 RESTful API를 CORBA로 추상화하는 이점을 누릴 수 있습니다. 또는보다 자바 중심적인 방식으로 JMS 또는 MDB입니다.

한때 EJB는 Java에서 큰 문제 였지만, 약간의 클러스터 효과로 인식되었지만 이제는 처음으로 돌아왔습니까?

또는 마이크로 서비스가 CORBA 또는 더 나은 MDB에없는 것을 제공합니까? 마이크로 서비스를 설명하는 (TLDR) Martin Fowler를 읽을 때, 당신이 원한다면 나쁜 문제에 대한 좋은 해결책으로 생각납니다. 또는 문제를 해결하는 수준의 복잡성을 유발하는 폐쇄적 인 접근 방식입니다. 서비스가 실제로 미세하고 많으면 각각 서비스를 운영하고 유지하는 데 1 달러의 비용이 듭니다.

또한 많은 마이크로 서비스 중 하나 의 API가 API를 변경하면 해당 서비스에 따른 모든 것이 중단됩니다. 그것은하지 않는 것 그것은 느슨하게 결합 된 것 같다 민첩의 반대. 아니면 그 말을 잘못 사용하고 있습니까?

물론,이 극단들 사이에는 불확실한 양의 선택이 있습니다.

상어 대 고릴라 ... 가자! (페단 틱의 경우, 그것은 아이러니하고, 전혀 의도 된 것이 아닙니다. 질문은 액면가로 취해 져야합니다. 질문이 개선 될 수 있다면, 그렇게하거나 의견을 말하고 고칠 것입니다. )

도커에서 실행되는 여러 마이크로 서비스가 모두 한 대의 컴퓨터에서 서로 대화하고 광기를 상상하십시오. 유지 관리 또는 관리가 어렵고 변경 사항이 연속되어 예기치 않은 오류가 발생하기 때문에 변경이 불가능합니다. 이러한 서비스가 여러 시스템에 분산되어있는 것이 어떻게 더 좋습니까? 그리고 그것들이 분산되어 있다면, 아주 오래된 학교 기술이 적어도 어느 정도 분산 컴퓨팅을 해결했을 것입니다.

수평 스케일링이 왜 그렇게 널리 보급되어 있습니까?

TL; DR. 나는 많은 마이크로 서버 맛의 Kool-Aid를 마시는 즐거움을 얻었으므로 그 이유에 대해 조금 말할 수 있습니다.

장점 :

• 서비스는 종속성이 안정적이며 시간을 내야한다는 것을 알고 있습니다.
• 새로운 버전의 롤링 배포 허용
• 상위 레이어에 영향을주지 않고 구성 요소를 되돌릴 수 있습니다.

단점 :

• 종속성의 새롭고 반짝이는 기능을 사용할 수 없습니다.
• API 이전 버전과의 호환성을 깨뜨릴 수는 없습니다.

마이크로 서비스 아키텍처가 어떻게 작동하는지 근본적으로 오해한다고 생각합니다. 실행되는 방식은 모든 마이크로 서비스 (여기서는 MS라고 함)가 모든 클라이언트가 동의하는 견고한 API를 가지고 있다는 것입니다. MS는 API가 유지되는 한 원하는대로 변경할 수 있습니다. API가 유지되는 한 MS를 폐기하고 처음부터 다시 작성할 수 있습니다.

느슨한 결합을 돕기 위해 모든 MS는 버전 n-1의 종속성에 의존합니다. 이를 통해 현재 버전의 서비스가 덜 안정적이며 조금 더 위험 해집니다. 또한 버전이 파도에 나올 수 있습니다. 처음 1 개의 서버가 업그레이드 된 다음 절반이되고 나머지는 마지막으로 업그레이드됩니다. 현재 버전에서 심각한 문제가 발생하면 다른 계층의 기능 손실없이 MS를 이전 버전으로 롤백 할 수 있습니다.

API를 변경해야하는 경우 이전 버전과 호환되는 방식으로 변경해야합니다.

우리가 발명 한 모든 소프트웨어 개발 기술은 어떻게 든 복잡성을 관리하는 것입니다. 그것들의 상당 부분은 추상화, 캡슐화 및 느슨한 결합에 관한 것입니다. 마이크로 서비스는 이러한 일을 수행하는 또 다른 방법이기 때문에 이론적으로 높은 수준의 많은 오래된 기술과 유사하지만 유용성이나 관련성이 떨어지는 것은 아닙니다.

느슨한 결합에 관해서는, 당신이 목표를 약간 이해했다고 생각합니다. 작업 A가 작업 B를 호출해야하는 경우 A와 B를 100 % 분리 할 수있는 방법이 없습니다. 절대 일어나지 않을 것입니다. 태스크 B가 태스크 C를 호출하는 경우 태스크 C가 A의 변경에 대해 걱정할 필요가 없도록해야합니다.이 세 가지 태스크가 모두 하나의 큰 얼룩으로 서로 연결되어 있고 구조체를 서로 전달하는 경우 그들 중 하나라도 변한다면 그들 모두가 바뀌어야 할 중대한 기회입니다. 그러나 세 가지 모두 마이크로 서비스 인 경우 기본적으로 A로 변경하면 B 만 업데이트된다는 보장이 보장됩니다 (A의 핵심 기능이 크게 변경되어 새로운 서비스로 만들지 않은 경우 제외). 모든 마이크로 서비스 업데이트가 이전 버전과 호환되는 방식으로 수행되는 경우 특히 그렇습니다.

민첩한 의견과 관련하여 마이크로 서비스 -y 코드가 "큰 얼룩으로 연결된"코드보다 민첩하게 더 잘 재생된다는 개인적인 경험을 통해 알 수 있습니다. 후자는 누군가가 저수준 기능의 버그를 고칠 때마다 문자 그대로 전체 R & D 부서에 "작업을 다시 연결하십시오. 그렇지 않으면 금요일에 모두 충돌합니다"라는 전자 메일을 보내야합니다. 우리는 매주 몇 가지를 얻 습니다 . 그의 코드가 마이크로 서비스에 포함되어 있다면, 새로운 버전을 배포하자마자 우리는 자동으로 수정의 혜택을 누릴 것입니다.

COBRA와 MDB에 대한 의견을 완전히 이해하지 못했습니다. 소프트웨어 아키텍처가 아니라 하나의 구성 요소 인 것 같습니다. 내가 이해하기에 그들은 마이크로 서비스의 메시징 프로토콜을 정의하고 /하거나 마이크로 서비스를 대신하는 대안이 아니라 상기 마이크로 서비스를 구현하는 잠재적 인 방법이다.

이러한 서비스가 여러 시스템에 분산되어있는 것이 어떻게 더 좋습니까?

구름 때문에.

아직 웃었습니까? 그럼에도 불구하고 많은 비즈니스에서 소프트웨어의 가장 큰 비용은 더 이상 소프트웨어가 아닙니다. 대역폭, 하드웨어, CDN 비용 등입니다. 이제 모든 사람이 모바일 장치를 사용하므로 훨씬 더 많은 트래픽이 발생합니다. 토스터가 인터넷에 연결되어 있으면 더 나빠질 수 있습니다.

따라서 기업은 이러한 비용을 관리하려고합니다. 구체적으로, 그들은 "이 문제가 발생하면 수백만의 사람들이 내 소프트웨어를 얻거나 사용하도록 서버에 미리 미리 지불하지 않고 어떻게 수백만의 사람들이 내 소프트웨어를 사용 / 사용하도록 할 수 있는가?"라는 비즈니스 문제를 처리하려고합니다. ? ".

왜 수평 스케일링이 그렇게 널리 보급되어 있습니까?

그것은 (거대한 증가하는) 비즈니스 문제에 답하기 때문입니다.

12 명의 사용자가 있으면 모든 서비스를 한 상자에 버릴 수 있습니다. 한 상자에 대해서만 지불하고 싶기 때문에 이것은 좋습니다. 또한 비즈니스 규모에 따라 다양한 서비스를 분할하기 위해 앱 변경에 대한 비용을 지불하고 싶지 않습니다. 요즘에는 고객의 폭도들이 서버에 불을 붙이기 전에 그렇게 할 시간이 없습니다.

또한 서버 할당을 저글링하여 다음을 수행 할 수 있기 때문에 좋습니다.

1. "폐기물"을 거의 남기지 않고 보유한 대부분의 서버를 사용하십시오.
2. 소프트웨어의 성능 개별 요소를 측정하십시오.
3. 릴리스로 인한 배포 / 종료 시간을 줄입니다.

매우 세부적인 배포를 통해 문제를보다 효과적으로 분리 할 수있을뿐만 아니라이 두 가지 작업을 더 쉽고 효율적으로 수행 할 수 있습니다.