마이크로 서비스 대 모 놀리 식 아키텍처 [닫기]

마이크로 서비스에 대해 읽어 봤는데 약간 흥미가 있는데 흥미로운 개념 인 것 같습니다. 하지만 모 놀리 식 아키텍처보다 마이크로 서비스를 사용하는 장점과 단점은 무엇이며 그 반대의 경우도 마찬가지입니다.

마이크로 서비스가 더 적합하고 모 놀리 식 아키텍처를 사용하는 것이 더 좋은 경우.

나는 마이크로 서비스 세계에 비교적 익숙하지 않지만 가능한 한 완벽하게 귀하의 질문에 대답하려고 노력할 것입니다.

마이크로 서비스 아키텍처를 사용하면 문제의 분리 및 분리가 증가합니다. 당신은 당신의 응용 프로그램을 흩 뿌리기 때문에.

그 결과 코드베이스를 더 쉽게 관리 할 수 ​​있습니다 (각 애플리케이션은 다른 애플리케이션과 독립적으로 작동하여 실행됩니다). 따라서, 당신이이 권리를하는 경우 , 것입니다 새로운 기능을 추가하여 나중에 쉽게 응용 프로그램에. 모 놀리 식 아키텍처의 경우 애플리케이션이 크면 수행하기가 매우 어려울 수 있습니다 (언젠가는 그렇게 될 것이라고 가정 할 수 있습니다).

또한 독립적 인 마이크로 서비스를 별도로 구축하고 별도의 서버에 배포하므로 애플리케이션 배포가 더 쉽습니다 . 즉, 나머지 애플리케이션을 다시 빌드하지 않고도 원할 때마다 서비스를 빌드하고 배포 할 수 있습니다.

서로 다른 서비스가 작고 개별적으로 배포되기 때문에 애플리케이션의 특정 서비스를 확장 할 수 있다는 이점을 가지고 확장 하기가 더 쉽습니다. (모 놀리 식을 사용하면 전체 "사물"을 확장 할 수 있습니다. 과도한 부하를받는 애플리케이션).

그러나 향후 관리하기에는 너무 커질 의도가없는 애플리케이션의 경우. 모 놀리 식 아키텍처로 유지하는 것이 좋습니다. 마이크로 서비스 아키텍처에는 몇 가지 심각한 어려움이 있습니다. 마이크로 서비스를 배포하는 것이 더 쉽다고 말했지만 이것은 큰 모놀리스와 비교할 때만 사실입니다. 마이크로 서비스를 사용하면 서비스를 다른 위치의 다른 서버에 배포하는 복잡성이 추가되고이를 모두 관리 할 방법을 찾아야합니다. 마이크로 서비스를 구축하면 애플리케이션이 커지면 장기적으로 도움이되지만 소규모 애플리케이션의 경우 모 놀리 식 상태를 유지하는 것이 더 쉽습니다.

소수의 사람들이 마이크로 서비스에 대한 모든 소문에 이끌 리고 고려해야 할 절충점이 있기 때문에 이것은 매우 중요한 질문입니다. 그렇다면 (모 놀리 식 모델과 비교할 때) 마이크로 서비스의 이점과 과제는 무엇입니까?

혜택

• 배포 가능성 : 빌드 + 테스트 + 배포주기가 짧아 져 서비스의 새 버전을 배포하는 데 더 민첩합니다. 또한 서비스 별 보안, 복제, 지속성 및 모니터링 구성을 사용할 수있는 유연성도 있습니다.
• 안정성 : 마이크로 서비스 결함은 해당 마이크로 서비스와 해당 소비자에게만 영향을 미치는 반면, 모 놀리 식 모델에서는 서비스 결함이 전체 모놀리스를 중단시킬 수 있습니다.
• 가용성 : 새로운 버전의 마이크로 서비스를 출시하려면 다운 타임이 거의 필요하지 않지만, 모놀리스에서 새 버전의 서비스를 출시하려면 일반적으로 전체 모놀리스를 더 느리게 다시 시작해야합니다.
• 확장 성 : 각 마이크로 서비스는 풀, 클러스터, 그리드를 사용하여 독립적으로 확장 할 수 있습니다. 배포 특성으로 인해 마이크로 서비스는 클라우드의 탄력성에 매우 적합합니다.
• 수정 가능성 : 새로운 프레임 워크, 라이브러리, 데이터 소스 및 기타 리소스를 사용할 수있는 더 많은 유연성. 또한 마이크로 서비스는 느슨하게 결합 된 모듈 식 구성 요소이며 계약을 통해서만 액세스 할 수 있으므로 큰 진흙 덩어리로 변하는 경향이 적습니다.
• 관리 : 애플리케이션 개발 노력은 규모가 작고 독립적으로 작업하는 팀으로 나뉩니다.
• 디자인 자율성 : 팀은 각 마이크로 서비스를 설계 및 구현하기 위해 다양한 기술, 프레임 워크 및 패턴을 자유롭게 사용할 수 있으며 각 마이크로 서비스를 독립적으로 변경 및 재배포 할 수 있습니다.

도전

• 배포 가능성 : 훨씬 더 많은 배포 단위가 있으므로 배포를 감독해야 할 복잡한 작업, 스크립트, 전송 영역 및 구성 파일이 있습니다. (이러한 이유로 지속적인 배포 및 DevOps는 마이크로 서비스 프로젝트에 매우 바람직합니다.)
• 성능 : 서비스는 네트워크를 통해 통신해야 할 가능성이 더 높은 반면 모놀리스 내의 서비스는 로컬 통화의 이점을 누릴 수 있습니다. (이러한 이유로 설계는 "수다스러운"마이크로 서비스를 피해야합니다.)
• 수정 가능성 : 계약 변경은 다른 곳에 배치 된 소비자에게 영향을 미칠 가능성이 더 큰 반면, 모 놀리 식 모델에서는 소비자가 모 놀리 식 내에있을 가능성이 더 높고 서비스와 함께 롤아웃됩니다. 또한 최종 일관성 및 비동기 호출과 같은 자율성을 향상시키는 메커니즘은 마이크로 서비스에 복잡성을 추가합니다.
• 테스트 가능성 : 통합 테스트는 서로 다른 런타임 환경에서 서로 다른 마이크로 서비스에 걸쳐있을 수 있으므로 설정하고 실행하기가 더 어렵습니다.
• 관리 : 감독 할 런타임 구성 요소, 로그 파일 및 지점 간 상호 작용이 더 많기 때문에 작업 관리 노력이 증가합니다.
• 메모리 사용 : 여러 클래스와 라이브러리가 각 마이크로 서비스 번들에서 종종 복제되고 전체 메모리 공간이 증가합니다.
• 런타임 자율성 : 모 놀리 식에서 전체 비즈니스 로직이 함께 배치됩니다. 마이크로 서비스를 사용하면 논리가 마이크로 서비스에 분산됩니다. 따라서 다른 모든 것이 동일하면 마이크로 서비스가 네트워크를 통해 다른 마이크로 서비스와 상호 작용할 가능성이 더 높습니다. 상호 작용이 자율성을 감소시킵니다. 마이크로 서비스 간의 상호 작용에 데이터 변경이 포함되는 경우 트랜잭션 경계의 필요성은 자율성을 더욱 손상시킵니다. 좋은 소식은 런타임 자율성 문제를 방지하기 위해 최종 일관성, 이벤트 기반 아키텍처, CQRS, 캐시 (데이터 복제), 마이크로 서비스를 DDD 제한 컨텍스트에 맞추는 것과 같은 기술을 사용할 수 있다는 것입니다. 이러한 기술은 마이크로 서비스에 내재되어 있지는 않지만 필자가 읽은 거의 모든 저자가 제안한 것입니다.

이러한 장단점 을 이해 하면 다른 질문에 답하기 위해 알아야 할 한 가지가 더 있습니다. 마이크로 서비스 또는 모놀리스 중 어느 것이 더 낫습니까? 애플리케이션의 비 기능적 요구 사항 (품질 속성 요구 사항)을 알아야합니다. 예를 들어 성능과 확장 성이 얼마나 중요한지 이해하면 장단점을 평가하고 교육을 통해 설계 결정을 내릴 수 있습니다.

@Luxo가 자리 잡고 있습니다. 나는 약간의 변형을 제공하고 그것에 대한 조직적 관점을 가져오고 싶습니다. 마이크로 서비스는 애플리케이션을 분리 할 수있을뿐만 아니라 조직 수준에서도 도움이 될 수 있습니다. 예를 들어 조직은 여러 팀으로 나눌 수 있으며 각 팀은 팀이 제공 할 수있는 일련의 마이크로 서비스에서 개발할 수 있습니다.

예를 들어, Amazon과 같은 대형 상점에는 개인화 팀, 전자 상거래 팀, 인프라 서비스 팀 등이있을 수 있습니다. 마이크로 서비스에 들어가고 싶다면 Amazon이 그 좋은 예입니다. Jeff Bezos는 공유 기능에 대한 액세스가 필요한 경우 팀이 다른 팀의 서비스와 통신하도록 요구했습니다. 간단한 설명 은 여기 를 참조 하십시오 .

또한 Etsy와 Netflix의 엔지니어는 트위터에서 마이크로 서비스 대 모놀리스 시대에 작은 논쟁을 벌였습니다. 토론은 다소 덜 기술적이지만 몇 가지 통찰력도 제공 할 수 있습니다.