SOA와 마이크로 서비스의 실제 차이점

기권

나는 누군가의 발가락을 밟거나 개념 애호가를 불쾌하게하지 않기를 바랍니다.

배경

명확한 답을 찾지 않고 Service Oriented Architecture와 Microservices의 실제 차이점을 찾고 있습니다.

나는 다음과 같은 것을 읽었다.

SOA의 부작용
반 패턴 인 SOA
마이크로 서비스는 SOA의 실패를 해결하기 위해왔다
ESB는 실제로 ESB가 아니며 EAI입니다.
메시지 브로커에 대한 과도한 의존
공급 업체는 SOA 개념을 남용하고 제품을 판매하려고합니다.
SOA는 통제 할 수없이 성장

그러나 여전히 서비스 지향 아키텍처 (개념)와 마이크로 서비스 (개념)의 아키텍처 차이점을 명확하게 정의하는 것은 없습니다.

내가 이해 한 바에 따르면 둘 다 가지고 있습니다.

서비스 제공자, 한 가지만 수행
이러한 서비스를 소비자에게 노출시키는 Service Gateway / ESB
ESB / Service Gateway를 통해 서비스에 액세스하는 서비스 소비자

질문

그렇다면 SOA를 마이크로 서비스로 리 라벨링하는 것 외에 다른 것이 있습니까? 마이크로 서비스가 거시적이되는 것을 제한하기위한 기술 제약입니까?

참고 : 나는 글 머리 기호로 의견이 아니라 어려운 사실만을 찾고 있습니다.

참고 문헌

최신 정보

마이크로 서비스가 변장 된 서비스 지향 아키텍처인지에 상관없이 의견이 나누어지면서 스택 오버플로 질문 에서 비슷한 논쟁이 일어났다 .

SO 질문의 결론 :

MS는 SOA 의 특별한 경우 입니다
MS는 서비스를 호스팅하는 더 작은 크기의 응용 프로그램을 승인합니다
MS는 기술에 따라 다릅니다 (개방형 프로토콜 옵션이 아닌 HTTP 사용)
MS는 기술을 사용하여 규율 (서비스 자동 배포)을 시행합니다.
MS는 ESB (악)를 고려하지만 IMHO가 ESB 유형 인 API 게이트웨이 를 사용합니다.

다음과 같은 경우 MS는 SOA라고 결론 지을 수 있습니다.

MS는 오케스트레이션 개념을 지원합니까? 하나 이상의 마스터 프로세스가 워크 플로우를 관리
MS에 메시지 브로커 계층이 있습니까? 서비스 생산자의 메시지 공간에서 서비스 소비자로 메시지 형식을 변환하는 어댑터 세트
마이크로 서비스가 모 놀리 식 엔터프라이즈 애플리케이션에서 데이터를 읽을 수 있습니까? 단일 응용 프로그램의 API 일 수 있습니까? 또는 독립적으로 작동 할 수있는 독립형 독립형 응용 프로그램이어야합니까?

마지막 질문에 대한 답변이 아니오로 밝혀지면 Microservices는 신용 카드 관리 시스템 또는 조정 시스템과 같은 복잡한 워크 플로 시스템을 처리 할 수 없습니다.

microservices enterprise-architecture soa

— 라샤드
소스

오늘날 분산 컴퓨팅의 방식은 작고 느슨하게 결합되고 분산 된 내결함성 "에이전트"또는 "모듈"로 명확하고 구체적인 책임이 있으며 단순하고 간단한 통신 프로토콜로 연결됩니다. SOA는이 모든 것과 정반대입니다. 당신은 피상적 인 유사점의 두더지를 관찰하고 차이의 산을 내려다보고 있습니다.

— Robert Harvey

SOA가 느슨하게 결합 된 작은 컴포넌트도 구현하지 않아야 하는가? 나는 SOA의 뒤쪽 끝에서, 어떤 메시지 형식, 프로토콜과 적합한 매체 액세스를 사용하여 대부분의 다른 응용 프로그램 및 기타 응용 프로그램에서 소비하는 서비스를 제공하는 서비스는 "품종의 베스트"로 설명 다기능 애플리케이션, 알고

— 을 .Rashad

방금 지적했듯이 일반적으로 그렇지 않습니다.

— Robert Harvey

Martin Fowler's Site (I think he hates it big time)바르셀로나에서 연설을했을 때의 느낌은 아닙니다. 그는 MS가 모든 사람에게 적합하지 않다는 것을 고려하지 않고 사람들이이 아키텍처로 옮긴 방식과 장단점을 알고 있습니다.

— Laiv

마이크로 서비스는 많은 마케팅입니다. 다른 점이 없다. 사람들은이 년 전에 일을하고 있었고 지금 누군가가 그것에 이름을 썼고 이제는 새로운 무언가를 썼습니다. 당신은 올바른 MS가 SOA의 (특별하지 않은) 사례입니다. 그것으로 무언가를 만들려고 노력하지 마십시오.

— Kyle Johnson

답변:

서비스 제공자, 한 가지만 수행

프로젝트의 광범위한 결과를 가져온 핵심 차이점은 마이크로 서비스를 사용하여 이러한 서비스 제공 업체가 독립적으로 배포 및 확장 가능 하다는 것입니다 .

더 민첩 할 수 있기 때문에 이것은 좋습니다. 서비스를 변경해야하는 경우에는 해당 서비스 만 변경하면됩니다. 새로운 프레임 워크 나 언어를 사용하려면 해당 서비스를 대체 할 수 있습니다. 갑자기 100 배의 용량이 필요한 경우 해당 서비스를 제공하는 일부 새 시스템을 가동하여 유입을 처리하십시오. 버전을 변경하려면 전체 앱 을 건드리지 않고 버전을 지정하십시오 . 또한 팀 간 모니터링, 계측, 분할, 더 이상 사용하지 않는 것을 쉽게 만듭니다.

그러나 다음과 같은 의미가 있습니다.

몇 가지 서비스를 배포하는 것은 수십 개의 서비스를 배포하는 것과는 다르기 때문에 릴리스 프로세스를 변경해야합니다.
한 시스템에 서비스를 배포하는 것은 수십 대의 시스템에 배포하는 것과는 다르기 때문에 릴리스 프로세스를 변경해야합니다.
이 큰 공유 DB를 배포하여 다른 모든 서비스를 중단해야하는 경우 서비스를 배포하는 것은 의미가 없으므로 데이터베이스 디자인, 사용 및 배포를 변경해야합니다.
라이브러리를 디자인하고 사용하려면이 공유 라이브러리를 업데이트해야하는 경우 서비스를 배포하는 것이 의미가 없기 때문에 변경해야합니다 (다른 모든 서비스 중단).
변화에 대한 로깅 / 인증 / 세션 관리 / 등 필요 당신은 단지 하나 개의 서비스 일 때 그것을 공유 물건에 아주 쉽기 때문입니다,하지만 당신은 제품을 구성하는 독립적 인 작은 서비스의 무리가있을 때 서로 다른 - 그리고 그들은있어 가는 로 물건을 공유하고 싶습니다. 아, 그리고 그 공유 된 모든 것들이 다른 버전에있을 가능성을 다루어야합니다.
의사 소통이 바뀌어야합니다. 몇 가지 서비스 만 있으면 통신이 자주 발생하지 않거나 느리게 발생할 수있는 회선을 따라 작업을 중단 할 수 있습니다. 마이크로 서비스를 사용하면 서로 대화를 많이 할 수 있으며 대기 시간이 길어도 문제가 해결되지 않습니다.

— 텔라 스틴
소스

이러한 모든 이유 때문에 마이크로 서비스를 전체 응용 프로그램 아키텍처가 아닌 특정 문제 (분산 컴퓨팅을 통한 확장)에 대한 특정 솔루션으로 봅니다.

— Robert Harvey

Enh, 그들은 확장 성 / 분산 컴퓨팅을 거꾸로 (복잡성과 다른 단점이있는) 응용 프로그램 아키텍처로 간주해야한다고 생각할 정도로 충분히 영향을 미쳤습니다.

— Telastyn

아키텍처 관점에서 볼 때 마이크로 서비스는 독립형 마이크로 시스템이 한 가지 일을하는 반면 SOA는 여러 서비스가 소비자에게 노출되는 모 놀리 식 애플리케이션입니까?

— A.Rashad

나는 지금 더 혼란스러워한다! 모 놀리 식 애플리케이션이 마이크로 서비스를 노출 할 수 있습니까? 아니면 독립형 마이크로 응용 프로그램이어야합니까?

— A.Rashad

DZone Microservices vs SOA 에서이 기사를 살펴보십시오 .

— Laiv

결론은 여기 SOA 와 마이크로 서비스의 분명한 차이점 은

스마트 엔드 포인트 멍청한 파이프

SOA 와는 달리 , 이는 명백한 서비스 소비자 및 생산자에 의존하여 트래픽 관리, 메시지 형식 변환 및 서비스 오케스트레이션을 외부 시스템 (예 : ESB, 서비스 오케 스트레이터, 메시지 브로커)에 위임합니다.

— 라샤드
소스