microservice-architecture
마이크로서비스 아키텍처는 애플리케이션을 비즈니스 기능을 중심으로 구성되고 독립적으로 배포 가능한 느슨하게 결합된 서비스 모음으로 구조화하는 소프트웨어 개발 방식입니다.
마이크로서비스 아키텍처는 애플리케이션을 비즈니스 도메인을 중심으로 모델링된 작고 자율적인 서비스 모음으로 구조화합니다. 각 서비스는 자체적으로 포함되어 있으며 특정 기능을 담당하며, 종종 HTTP 리소스 API인 가벼운 메커니즘을 통해 다른 서비스와 통신합니다. 이는 모든 기능이 단일 애플리케이션으로 번들링되는 기존의 모놀리식 접근 방식과 대조됩니다.
이 아키텍처 스타일은 개별 서비스의 독립적인 개발, 배포 및 확장을 촉진합니다. 팀은 각 서비스에 가장 적합한 기술 스택을 선택하여 개발 주기를 단축하고 복원력을 향상시킬 수 있습니다. 초점은 시간이 지남에 따라 쉽게 변경하고 발전할 수 있으며 변화하는 비즈니스 요구에 더 큰 민첩성과 적응성을 제공하는 시스템을 구축하는 것입니다.
graph LR
Center["microservice-architecture"]:::main
Pre_computer_science["computer-science"]:::pre --> Center
click Pre_computer_science "/terms/computer-science"
Rel_api["api"]:::related -.-> Center
click Rel_api "/terms/api"
Rel_saas_software_as_a_service["saas-software-as-a-service"]:::related -.-> Center
click Rel_saas_software_as_a_service "/terms/saas-software-as-a-service"
Rel_distributed_systems["distributed-systems"]:::related -.-> Center
click Rel_distributed_systems "/terms/distributed-systems"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 지식 테스트
🧒 5살도 이해할 수 있게 설명
Instead of one giant robot doing everything, it's like having a team of smaller, specialized robots, each good at one job (like cooking or cleaning), that work together.
🤓 Expert Deep Dive
Microservice architecture represents a shift from centralized, monolithic design towards a distributed system paradigm, emphasizing organizational alignment with business capabilities (Conway's Law). Each microservice encapsulates a bounded context, exposing its functionality via well-defined APIs (often RESTful HTTP or asynchronous messaging). This decomposition facilitates independent deployment pipelines, enabling faster release cycles and enabling technology diversity (polyglot programming and persistence). Challenges inherent in this architecture include managing distributed transactions, ensuring data consistency across services (often relying on eventual consistency patterns like Saga), and handling inter-service communication latency and failures. Robust infrastructure is required, including service discovery, API gateways, load balancing, centralized logging, and distributed tracing. Architectural patterns like the Strangler Fig pattern are often used for migrating from monoliths to microservices. Trade-offs are significant: while agility, scalability, and fault isolation improve, operational overhead, complexity in debugging distributed systems, and the need for mature DevOps practices increase substantially. Security also becomes more distributed, requiring careful management of authentication and authorization across service boundaries.