티스토리 뷰
반응형
Before 마이크로서비스
마이크로서비스 전에는, 웹 애플리케이션은 monolithic architecture 형태였다. 이런 구조의 애플리케이션은 단일 소프트웨어로 산출된다.
이런 형태는 애플리케이션이 커지고 복잡해질 때 문제가 발생한다. 이런 애플리케이션은 변경이 있을 때, 애플리케이션 전체를 다시 빌드-테스트-배포 과정을 거치면서, 발생하는 비용이 증가한다.
이런 문제를 해결하기 위해 마이크로서비스가 고안되었다.
마이크로서비스의 등장
마이크로서비스는 일체형 애플리케이션을 작은 독립된 컴포넌트로 나누는 것이다. 이런 마이크로서비스는 나누어졌기 때문에 분산되었고, 독립된 컴포넌트이기 때문에 느슨한 결합을 가진다. 대형 애플리케이션에서 마이크로서비스를 사용하면 관리가 쉬워진다.
마이크로서비스는 위와 같은 구조를 가진다. 아무것도 공유하지 않는 아키텍처를 유지해야 하기 때문에, 데이터베이스의 데이터를 공유하지 않고, 각 서비스마다 데이터베이스를 가진다. 그리고 이런 구조이기 때문에, 각 서비스를 담당하는 팀마다 독립적으로 빌드-테스트-배포를 할 수 있다. 하나의 대형 서버에 배포해야 하는 일체형 애플리케이션과 달리, 마이크로 서비스는 여러 개의 작은 서버에 배포할 수 있다.
마이크로서비스 아키텍처의 특징
- 애플리케이션 로직을 책임이 명확한 작은 컴포넌트로 분해
- 컴포넌트는 독립적으로 배포
- 데이터 교환을 위해 경량 통신 프로토콜 사용
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- 확장 함수
- Python
- 코틀린
- java
- 네이버 2022 공채
- go 특징
- Kotlin In Action
- 1차 인터뷰
- 주생성자
- Basic Type
- 2차 인터뷰
- python3
- postman collection
- Squash and merge
- postman
- squash merge
- hashcode
- pm.expect
- git
- 코딩테스트
- Kotlin
- graphql
- string
- postman tests
- DGS Framework
- downTo
- solidity
- pm.test
- github
- mysql
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
글 보관함