마이크로서비스 아키텍처: 역량의 특징

모놀리식 시스템은 컨테이너화 및 클라우드 컴퓨팅의 현대 시대에 더 이상 실현 가능하지 않습니다. 최근 몇 년 동안 소프트웨어 시스템의 복잡성이 증가했으며 모놀리식 시스템은 만들고 유지 관리하기가 점점 더 복잡해지고 있습니다.

시스템 구성 요소는 모놀리식 시스템에서 단일 단위로 생산 및 번들됩니다. 단일 구성 요소가 변경되면 전체 시스템을 재배포해야 합니다. 이것은 확장을 더 어렵게 만들고 덜 다양하게 만듭니다. 독립적인 시스템의 상호 연결되고 상호 관련된 구조는 포괄적인 응용 프로그램을 구성할 때 개발자에게 힘든 노력이 될 수 있습니다. 영향을 받는 시스템은 또한 주요 수정을 수행하거나, 새로운 기술 스택을 채택하거나, 업그레이드 및 업데이트를 제공하는 것을 어렵게 만듭니다. 시스템 내에서 서로 통신할 수 있는 다양한 서비스로 구성된 서비스 지향 아키텍처는 애초에 모놀리식 프로그래밍에서 전환을 위한 프레임워크를 설정합니다.

마이크로서비스 아키텍처는 도메인의 다음 단계였으며 성공적인 소프트웨어 개발 전략을 수립하기 위한 보다 통합되었지만 세부적인 수단이었습니다. 소프트웨어 시스템을 독립적으로 배포할 수 있는 서비스 모음으로 구축하는 특정 기술을 설명하기 위해 지난 몇 년 동안 "마이크로서비스 아키텍처"라는 문구가 등장했습니다. 이 아키텍처 스타일에 대한 구체적인 정의는 없지만 비즈니스 기능, 자동화된 배포, 엔드포인트의 인텔리전스, 언어 및 데이터의 분산 관리와 관련된 조직을 둘러싼 몇 가지 유사한 특성이 있습니다.

시스템을 더 작고 독립적인 섹션으로 나눈 다음 함께 연결하는 소프트웨어 개발 접근 방식입니다. 자율 서비스는 한 특정 부문의 전문화된 요구를 충족시키기 위해 함께 모여 있습니다. Spotify, Amazon, PayPal, Netflix 및 Twitter는 모두 이 새로운 발견에 주목했으며 광범위하게 광고하고 있습니다.

마이크로서비스 아키텍처란 무엇입니까?

"마이크로서비스 아키텍처"라는 문구는 소프트웨어 프로그램 아키텍처에 대한 특정 접근 방식을 서로 독립적으로 배포할 수 있는 서비스 모음으로 지칭하기 위해 지난 몇 년 동안 더 유명해졌습니다. 이 아키텍처 스타일은 정확하게 정의할 수 없다는 사실에도 불구하고 다른 아키텍처 접근 방식과 특정 특성을 공유합니다. 여기에는 비즈니스 기능을 기반으로 하는 조직, 자동화된 배포, 엔드포인트의 인텔리전스, 언어 및 데이터의 분산 제어가 포함됩니다. 다시 말해서, 마이크로서비스가 독립적으로 운영할 수 있는 능력은 소프트웨어 개발 현장의 정상에 오르게 된 원동력입니다.

간단히 마이크로서비스로 더 자주 언급되는 마이크로서비스 아키텍처는 애플리케이션 소프트웨어를 개발할 때 활용되는 설계 패러다임입니다. 마이크로서비스를 사용하면 큰 애플리케이션을 여러 개의 작은 독립된 부분으로 나눌 수 있으며, 각 부분은 고유한 작업 집합을 담당합니다. 단일 사용자 요청으로 인해 마이크로 서비스를 기반으로 하는 애플리케이션이 응답을 구성하기 위해 자체 내부 마이크로 서비스를 여러 번 호출할 수 있습니다.

컨테이너는 서비스의 종속성에 대해 걱정할 필요가 없으므로 서비스 자체 개발에 집중할 수 있으므로 마이크로서비스 아키텍처의 좋은 예입니다. 컨테이너는 종종 마이크로서비스 형태의 최신 플랫폼용 클라우드 네이티브 애플리케이션을 개발하기 위해 선택되는 도구입니다. "마이크로서비스 아키텍처"라는 용어는 애플리케이션 자체가 서비스 모음으로 구성되는 애플리케이션 아키텍처 유형을 나타냅니다. 마이크로 서비스용 아키텍처 다이어그램 및 서비스를 독립적으로 구축, 배포 및 관리하기 위한 프레임워크를 제공합니다.

마이크로서비스 아키텍처 개발의 필요성 과 모놀리식 아키텍처의 한계

1. 애플리케이션 확장

성공적인 웹 규모 비즈니스는 기하급수적인 확장을 경험하기 때문에 해당 소프트웨어는 또한 뛰어난 수평 확장성을 허용해야 합니다. 경우에 따라 CPU 또는 I/O가 많은 소프트웨어의 일부만 개별적으로 확장 및 처리해야 합니다(다국어 프로그래밍으로 구현). 모놀리식 소프트웨어는 단일 엔터티로 기능하고 단일 프로그래밍 언어와 Tech Stack을 사용하여 생성됩니다. 수평적 확장을 위해서는 전체 애플리케이션을 확장해야 합니다. 모놀리식 소프트웨어는 단일 프로그래밍 언어만 지원하기 때문에 단일 모듈이라도 다른 프로그래밍 언어나 Tech Stack으로 개발하는 것은 불가능합니다.

2. 개발 속도

시장 출시 시간을 단축하기 위해 오늘날 모든 비즈니스는 빠른 기능 개발을 원합니다. 크고 복잡하며 때로는 수백만 라인의 모놀리식 애플리케이션에서 새로운 기능의 추가는 개발자에게 가해지는 막대한 인지 부하로 인해 매우 느립니다. 대규모 모놀리식 프로그램의 모듈은 밀접하게 연결되어 있어 새로운 기능을 개발하기가 더 어렵습니다. 결과적으로, 모놀리식 프로그램에 새로운 기능을 추가하는 것은 종종 느리고 비용이 많이 듭니다.

3. 개발 확장

경쟁 우위를 확보하거나 성과를 거두기 위해 기업은 더 많은 개발자를 고용하여 개발을 병렬화하려는 경우가 많습니다. 개발자는 밀접하게 연결된 대규모 모놀리식 코드 기반에서 독립적으로 작업할 수 없으며 종종 서로의 작업을 방해하지 않도록 추가적인 동기화와 경계가 필요합니다. 개발자를 추가한다고 해서 기능이 증가하는 것은 아니며 때때로 기능이 줄어들 수도 있습니다. 마찬가지로 전체 모놀리식 코드 기반을 이해하는 데 필요한 높은 인지 부하로 인해 일반적으로 신입 사원이나 최근 졸업생이 생산적인 코드의 첫 줄을 만드는 데 상당한 시간이 걸립니다. 2008년에 베를린에 기반을 둔 통신 사업체와 인터뷰를 한 적이 있는데, 기술 관리자는 회사의 C++ 코드 기반에 수백만 줄이 포함되어 있으며 새로운 엔지니어는 4~6개월 후에만 생산적인 코드를 생성할 수 있다고 의기양양한 미소를 지으며 말했습니다.

4. 출시 주기

대형 모놀리식 프로그램의 릴리스 주기는 일반적으로 6년에서 2년 반으로 지나치게 길며 크기 때문에 추가로 몇 개월에서 몇 년이 지연됩니다. 새로운 경쟁자가 출시 기간 동안 시장에 진입할 수 있기 때문에 출시 주기가 크면 기업이 경쟁에서 불리한 상황에 놓이는 경우가 많습니다.

5. 모듈화

모놀리식 아키텍처에서 모듈 간의 장벽은 일반적으로 내부 인터페이스입니다. 프로그램의 크기가 커지면 모듈 간의 분리가 무너지기 시작합니다. 결과적으로 모놀리식 아키텍처의 모듈은 느슨하게 결합되고 응집력이 높은 대신 밀접하게 연결되는 경우가 많습니다. 소프트웨어 개발을 사회에 비유하면 모놀리식 모듈화는 사회의 법과 질서를 보장할 수 없는 도덕 및 종교 원칙과 유사합니다.

6. 현대화

기존의 성공적인 앱은 다양한 이유로 현대화가 필요했습니다(예: 최신 하드웨어, 브라우저, 네트워크 대역폭, 기술 스택 또는 우수한 개발자 유치). 모놀리식 프로그램 현대화는 서비스에 영향을 미치지 않으면서 전체 애플리케이션의 빅뱅 현대화가 필요하기 때문에 비용과 시간이 많이 소요될 수 있습니다.

마이크로서비스의 유형

차등 및 통합 마이크로 서비스는 두 가지 다른 종류의 마이크로 서비스입니다.

ㅏ. 미분

이러한 형태의 아키텍처에서 아키텍처는 트랜잭션으로 분리할 수 있는 독립적인 서비스로 분해됩니다. 그 결과 단일 트랜잭션이 여러 서비스에 분산됩니다.

비. 완전한

마이크로서비스 애플리케이션은 다수의 마이크로서비스를 개별화된 사용자 경험으로 결합하도록 설계되었습니다. 이러한 프로그램은 서비스 수준 관리, 온디맨드 프로비저닝 및 동적 구성을 포함하여 몇 가지 고유한 요구 사항을 다룹니다.

마이크로서비스의 특징

1. 자율

마이크로서비스 아키텍처를 사용하면 각 서비스 구성 요소를 다른 서비스와 별도로 구축, 배포, 관리 및 확장할 수 있습니다. 서비스는 코드를 공유하거나 다른 서비스와 작업을 수행하는 방법을 공유할 필요가 없습니다. 서로 다른 부분 간의 모든 통신은 잘 정의된 API를 통해 이루어집니다.

2. 전문화

각 서비스는 다양한 기술과 문제를 기반으로 합니다. 시간이 지남에 따라 개발자가 서비스에 더 많은 코드를 추가하면 서비스가 더 작은 서비스로 분할될 수 있습니다.

3. 서비스를 통한 컴포넌트화

마이크로서비스 아키텍처는 라이브러리를 사용하지만 자체 소프트웨어를 구성하는 주요 방법은 서비스로 분해하는 것입니다. 라이브러리는 프로그램에 연결되고 메모리 내 함수 호출을 사용하여 호출되는 구성 요소인 반면 서비스는 웹 서비스 요청 또는 원격 프로시저 호출과 같은 메커니즘과 통신하는 out-of-process 구성 요소입니다. 우리는 라이브러리를 프로그램에 연결되고 메모리 내 함수 호출을 사용하여 호출되는 구성 요소로 정의합니다. (이것은 많은 OO 시스템에서 서비스 객체라고 하는 것과는 별개의 아이디어입니다. 라이브러리와 달리 서비스는 독립적으로 배포될 수 있으며 이것이 라이브러리가 아닌 구성 요소로 사용되는 주요 이유 중 하나입니다. 구성 요소 대신 서비스를 사용하는 이점은 보다 투명한 구성 요소 인터페이스를 생성한다는 것입니다. 명시적 공개 인터페이스를 설정하는 좋은 기술은 대부분의 프로그래밍 언어에 존재하지 않습니다.

문서화와 규율은 일반적으로 고객이 구성 요소의 캡슐화를 위반하는 것을 방지하는 유일한 것입니다. 명시적 원격 호출 프로토콜을 사용함으로써 서비스는 사용자가 이를 피하기 쉽게 만듭니다. 이러한 종류의 서비스를 사용하면 몇 가지 단점이 있습니다. 원격으로 호출하는 것은 동일한 프로세스 내에서 호출하는 것보다 비용이 많이 들기 때문에 원격으로 사용되는 API는 더 세밀해야 하므로 활용하기가 더 어려울 수 있습니다. 프로세스의 경계를 초월하면 행동 변화를 만들기가 더 어려워지며 구성 요소 간에 책임이 분산되는 방식을 수정해야 하는 경우 더 어려워집니다.

4. 프로젝트가 아닌 제품

우리가 접하는 대부분의 애플리케이션 개발 이니셔티브는 프로젝트라는 패러다임을 따릅니다. 이 패러다임에서 주요 목표는 완료된 것으로 간주되는 소프트웨어 조각을 넘겨주는 것입니다. 프로젝트가 끝나면 소프트웨어는 유지 관리 조직에 넘겨지고 빌드를 담당했던 팀은 해체됩니다.

마이크로서비스 지지자들은 일반적으로 팀이 전체 수명 동안 제품을 소유해야 한다는 개념에 찬성하여 이 아키텍처를 피합니다. 개발 팀이 프로덕션에서 사용되는 동안 프로그램에 대한 완전한 책임을 진다는 Amazon의 "당신이 구축하고 운영합니다"라는 개념은 이에 대한 탁월한 영감의 원천입니다. 이를 통해 개발자는 소프트웨어가 프로덕션 환경에서 작동하는 방식을 일상적으로 접하게 되며 프로그램에 대한 지원을 제공하는 부하의 일부를 떠맡아야 하기 때문에 사용자와의 커뮤니케이션이 증가합니다.

5. 분산 거버넌스

또한 마이크로서비스 개발 팀은 표준에 대한 고유한 접근 방식을 선호합니다. 그들은 성문화된 표준 세트에 의존하기보다 다른 개발자가 직면한 문제와 유사한 문제를 해결하는 데 사용할 수 있는 유용한 도구를 제공하는 것을 선호합니다. 일반적으로 이러한 도구는 구현에서 파생되고 더 큰 커뮤니티와 공유되지만 때로는 내부 오픈 소스 패러다임을 활용하는 것은 아닙니다. 이제 git 및 github가 선택되는 사실상의 버전 제어 시스템이므로 조직 내에서 오픈 소스 기술이 점점 더 널리 보급되고 있습니다.

넷플릭스는 이 원칙을 고수하는 회사의 좋은 예입니다. 가치 있고 가장 중요하게는 전투 테스트를 거친 코드를 라이브러리로 공유하면 다른 개발자가 비슷한 방식으로 유사한 문제를 처리하는 데 도움이 되며 필요한 경우 다른 방법을 선택할 수 있습니다. 공유 라이브러리는 아래에서 더 자세히 논의되는 바와 같이 데이터 저장, 프로세스 간 통신 및 인프라 자동화와 같은 일반적인 문제에 집중하는 경향이 있습니다.

마이크로서비스 커뮤니티의 경우 비용은 특히 바람직하지 않습니다.

6. 검증된 표준 및 시행 표준

마이크로서비스 팀은 비즈니스 디자인 그룹에서 부과하는 엄격하게 시행되는 표준 유형을 피하는 것을 선호하지만 HTTP, ATOM 및 기타 마이크로포맷과 같은 개방형 표준을 활용하고 옹호하기까지 하기 때문에 약간의 역설입니다.

주요 차이점은 표준이 생성되고 구현되는 방식입니다. IETF와 같은 조직에서 제어하는 ​​표준은 성공적인 오픈 소스 이니셔티브의 결과인 경우가 많은 더 큰 세계에서 여러 번 실제 구현될 때까지 표준이 되지 않습니다.

이러한 표준은 제한된 최근 프로그래밍 전문 지식이나 과도한 공급업체 영향력을 가진 사람들이 자주 생성하는 대부분의 비즈니스 표준과 다릅니다.

7. 인프라 자동화

지속적인 배포 및 배포의 결과로 더 많은 자동화가 발생하는 한 가지 부작용은 개발자와 운영 담당자를 지원하는 유용한 도구의 도입입니다. 인공물 생성, 코드베이스 유지 관리, 기본 서비스 시작 또는 표준 모니터링 및 로깅 추가를 위한 도구는 현재 비교적 널리 퍼져 있습니다. 웹에서 가장 훌륭한 예는 의심할 여지 없이 Netflix의 오픈 소스 도구 모음이지만, 특히 우리가 광범위하게 사용한 Dropwizard도 있습니다.

마이크로서비스 아키텍처의 통신 메커니즘 개요

마이크로서비스 아키텍처를 구성하는 서비스는 다양한 서버에서 실행됩니다. HTTP, AMQP 및 TCP와 같은 프로토콜은 이러한 많은 서비스 간의 통신을 용이하게 하기 위해 사용됩니다. 가장 널리 채택된 두 가지 프로토콜은 HTTP/REST 및 비동기 메시징입니다. HTTP 프로토콜은 온라인 서비스용 REST API(응용 프로그래밍 인터페이스)에서 자주 사용됩니다. 클라이언트는 GET, POST, PUT 및 DELETE(URL)와 같은 HTTP 메서드와 함께 Uniform Resource Locator를 활용하여 애플리케이션의 리소스에 액세스하고 리소스를 변경할 수 있습니다. REST API(응용 프로그래밍 인터페이스)는 응용 프로그램 기능에 대한 진입점 역할을 합니다. 클라이언트는 API에 요청을 보내 서비스에 대한 요구 사항을 전달합니다. 클라이언트는 마이크로서비스와 직접 통신하거나 API 게이트웨이를 통해 통신할 수 있습니다.

API 게이트웨이 패턴을 사용하여 서비스에 대한 모든 요청에 ​​대해 단일 진입점이 지정됩니다. API(응용 프로그래밍 인터페이스) 게이트웨이는 클라이언트로부터 요청을 받으면 해당 요청을 적절한 서비스로 보냅니다.

API 게이트웨이 패턴에는 다양한 변형이 있으며 그 중 하나는 프론트엔드 패턴의 백엔드입니다. 이 디자인은 각 클라이언트 유형에 대해 고유한 API 게이트웨이를 만듭니다(예: 모바일 클라이언트용 게이트웨이와 웹 애플리케이션용 게이트웨이).

다양한 서비스 간의 통신 수준을 낮게 유지하는 것이 좋습니다. 비동기식 통신은 통신이 필수인 상황에서는 동기식 통신보다 우수합니다. 요청을 보낸 서비스는 작업을 계속하기 전에 응답을 기다릴 필요가 없습니다.

데이터베이스에 통합될 때 메시징 대기열과 스트리밍 시스템은 비동기 통신을 활성화하는 좋은 방법입니다. 또한 이러한 시스템이 데이터 작업 및 메시지 전송을 위한 트랜잭션 의미 체계를 제공할 때 이러한 요구 사항을 모두 충족할 수 있습니다. 이 때문에 마이크로 서비스 배포가 더 쉽고 확장 가능합니다. REST API만 사용하는 경우 마이크로 서비스 간의 통신이 강제로 동기화되어 성장을 방해하는 경우가 많습니다.

마이크로 서비스 아키텍처는 무엇을 위해 사용됩니까?

마이크로서비스는 복잡한 시스템을 마이크로서비스라고 하는 세분화되고 느슨하게 결합된 소프트웨어 아티팩트의 모음으로 설계하는 것을 목표로 하는 최신 유행 아키텍처 스타일입니다. 각 마이크로 서비스는 애플리케이션 비즈니스 로직의 작은 부분 또는 단일 기능을 구현합니다. 마이크로서비스는 세분화되고 느슨하게 결합된 소프트웨어 아티팩트의 모음으로 복잡한 시스템을 설계하는 것을 목표로 하기 때문에 인기를 얻고 있습니다. 마이크로서비스는 종종 애플리케이션 개발 프로세스를 가속화하기 위해 사용됩니다.

마이크로에 대한 아이디어는 특히 해당 비즈니스가 최소 10년 동안 운영된 경우 대부분의 조직이 처음에 구축된 모놀리식 인프라에 대한 응답으로 개발되었습니다. 마이크로 서비스 아키텍처의 각 구성 요소에는 모놀리식 설계 대신 다음 기능이 포함됩니다.

• 고유한 CPU
• 자체 운영 체제 및 런타임 환경
• 대부분의 경우 전문 팀이 각 서비스를 다른 서비스와 구별할 수 있도록 작업합니다.

이 디자인으로 인해 각 서비스는 다음을 수행할 수 있습니다.

• 고유한 절차 실행
• 다른 마이크로서비스 또는 애플리케이션 전체의 통신에 의존할 필요 없이 서로 독립적으로 통신합니다.

Java 기반 마이크로서비스 아키텍처, 특히 Spring Boot를 사용하여 구축된 아키텍처가 널리 채택되고 있습니다. 또한 마이크로 서비스와 서비스 지향 아키텍처는 종종 서로 비교됩니다. 두 가지 접근 방식은 모두 큰 소프트웨어 프로그램을 보다 관리하기 쉬운 부분으로 분할하는 동일한 목표를 가지고 있지만 방법론은 다릅니다. 또한 많은 기업이 경쟁업체로부터 시스템 가용성에 미치는 영향을 최소화하면서 최대한 빨리 시스템을 조정해야 한다는 압력을 받고 있습니다. 이를 위해서는 적절한 디자인, 아키텍처 스타일 및 개발 기술이 필요합니다. 소프트웨어 엔지니어링은 이러한 요구를 부분적으로 충족할 수 있는 다양한 패러다임을 제공합니다. 이러한 패러다임은 소프트웨어 시스템을 세분화된 소프트웨어 단위로 세분화하여 모듈성, 유지보수성 및 재사용성을 개선하고 결과적으로 제품을 시장에 출시하는 데 필요한 시간을 줄입니다.

간단히 말해서 장기적으로 민첩성을 제공합니다. 마이크로서비스는 각각의 세분화되고 자율적인 라이프사이클이 있는 독립적으로 배포 가능한 다수의 서비스를 기반으로 하는 애플리케이션 생성을 허용함으로써 복잡하고 대규모의 확장성이 뛰어난 시스템에서 유지 관리를 개선할 수 있습니다. 이것은 많은 서비스를 기반으로 하는 애플리케이션 생성을 허용함으로써 달성됩니다.

마이크로서비스는 자체적으로 확장할 수 있다는 추가적인 이점이 있습니다. 대신 개별 마이크로 서비스를 확장할 수 있으므로 단일 엔터티로 확장해야 하는 단일 모놀리식 애플리케이션이 필요하지 않습니다. 확장이 필요하지 않은 애플리케이션의 다른 부분을 확장하는 대신 이러한 방식으로 수요를 충족하기 위해 추가 처리 능력이나 네트워크 대역폭이 필요한 프로그램의 기능 영역만 확장할 수 있습니다. 그 결과 필요한 하드웨어의 양이 줄어들기 때문에 비용이 절감됩니다.

다음은 마이크로서비스 아키텍처의 몇 가지 예입니다.

ㅏ. 웹사이트 이전

웹사이트 이전이 가능합니다. 예를 들어 복잡한 모놀리식 플랫폼에서 호스팅되는 웹 사이트는 클라우드 기반 및 컨테이너 기반 마이크로서비스 플랫폼으로 재배치될 수 있습니다.

비. 미디어 콘텐츠

확장 가능한 개체 저장 시스템을 사용하여 이미지 및 비디오 자산을 저장할 수 있으며 마이크로서비스 아키텍처를 사용하여 이러한 자료를 웹 또는 모바일 장치에 직접 제공할 수 있습니다.

씨. 재정 협상 및 청구

지불 처리와 주문을 별개의 서비스로 취급하는 것이 가능합니다. 이를 통해 결제 시스템에 문제가 있어도 결제가 ​​가능합니다.

디. 데이터 처리

모듈식 데이터 처리 서비스는 데이터 처리에도 활용할 수 있는 마이크로서비스 플랫폼을 사용하여 클라우드 지원을 개선할 수 있습니다.

마이크로서비스를 위한 디자인 패턴

패턴 언어는 당신의 가이드입니다!

a) 분해 패턴

• Bulkhead 는 연결 풀, 메모리 및 CPU와 같은 중요한 리소스를 각 워크로드 또는 서비스에 대해 분리합니다. 격벽을 배포하면 단일 워크로드(또는 서비스)가 모든 리소스를 사용할 수 없어 다른 리소스를 고갈시킬 수 있습니다. 이 접근 방식은 하나의 서비스로 인해 발생하는 캐스케이드 오류를 제거하여 시스템의 견고성을 향상시킵니다. 이 패턴은 배 선체의 구획된 파티션과 유사하기 때문에 벌크헤드라고 불립니다. 고객 부하 및 가용성 요구 사항에 따라 서비스 인스턴스를 개별 그룹으로 분할합니다. 이 아키텍처는 결함을 격리하는 데 도움이 되며 고장이 발생하는 동안에도 일부 사용자의 서비스 기능을 보존할 수 있습니다.
• Sidecar는 응용 프로그램의 유용한 구성 요소를 별개의 컨테이너 또는 프로세스로 설치하여 격리 및 캡슐화를 가능하게 합니다. 이 패턴을 사용하면 응용 프로그램이 서로 다른 구성 요소와 기술로 구성될 수도 있습니다. 이 패턴은 오토바이에 연결된 사이드카와 비슷하기 때문에 사이드카라고 불립니다. 디자인에서 사이드카는 상위 응용 프로그램에 연결되고 응용 프로그램에 대한 지원 기능을 제공합니다. 사이드카는 마찬가지로 상위 애플리케이션과 동일한 수명을 따르며 상위 애플리케이션과 함께 빌드되고 종료됩니다. 사이드카 패턴은 흔히 사이드킥 패턴이라고 하며 포스트에서 보여드릴 마지막 분해 패턴입니다.
• Strangler Fig 는 특정 기능을 새로운 서비스로 점진적으로 대체하여 애플리케이션의 증분 리팩토링을 지원합니다.

b) 통합 패턴

1. 연결된 마이크로서비스 패턴

단일 서비스 또는 마이크로 서비스에 대한 몇 가지 종속성이 있습니다. 예를 들어 마이크로 서비스 판매는 마이크로 서비스 제품 및 주문에 따라 다릅니다. 연결된 마이크로서비스 디자인 패턴은 요청에 대한 통합 응답을 제공하는 데 도움이 됩니다. 마이크로 서비스-1은 요청을 수신한 다음 마이크로 서비스-2와 통신합니다. 마이크로서비스-3과도 통신할 수 있습니다. 이러한 모든 서비스 호출은 동기식입니다.

2. 애그리게이터 패턴

비즈니스 활동을 여러 개의 더 작은 논리적 코드 조각으로 분리할 때 각 서비스에서 제공하는 데이터가 병합되는 방식을 고려하는 것이 중요합니다. 고객은 이에 대해 책임을 질 수 없습니다.

Aggregator 패턴은 이 문제를 해결하는 데 도움이 됩니다. 여러 소스의 데이터를 결합한 다음 최종 결과를 사용자에게 제공하는 방법을 설명합니다. 이는 두 가지 방법으로 가능합니다.

• 복합 마이크로 서비스는 필요한 모든 마이크로 서비스를 호출하고 데이터를 집계 및 변경한 다음 반환합니다.
• 요청을 여러 마이크로 서비스로 분할하는 것 외에도 API Gateway는 데이터를 소비자에게 제공하기 전에 집계할 수도 있습니다.

3. 프록시 패턴

우리는 API 게이트웨이를 통해 마이크로서비스를 제공합니다. 나는 GW가 보안 및 API 분류와 같은 API 특성을 획득하도록 허용합니다. 이 경우 API 게이트웨이는 세 가지 API 모듈로 구성됩니다.

• FTGO 모바일 클라이언트용 API를 구현하는 모바일 API
• 브라우저에서 실행되는 JavaScript 애플리케이션에 API를 구현하는 브라우저 API
• 타사 개발자용 API를 구현하는 공개 API

4. 가지 패턴

마이크로 서비스가 다른 마이크로 서비스를 포함하여 다양한 소스에서 필요한 데이터를 가져와야 할 수도 있습니다. 분기 마이크로 서비스 패턴은 Aggregator 및 Chain 디자인 패턴의 하이브리드입니다. 두 개 이상의 마이크로 서비스에서 동시 요청/응답 처리를 가능하게 하고 둘의 이점을 결합합니다. 호출되는 마이크로 서비스는 여러 다른 마이크로 서비스로 구성될 수 있습니다. Brach 패턴은 회사의 요구 사항에 따라 마이크로 서비스의 단일 체인 또는 같은 종류의 여러 체인을 호출하는 데 사용할 수도 있습니다.

마이크로서비스 아키텍처의 이점

가까운 장래에 마이크로서비스의 필요성이 극적으로 확대될 것입니다. 마이크로서비스를 사용하여 레거시 프로그램이 업데이트됩니다. 리팩토링을 통해 모놀리식 앱을 마이크로서비스로 나눌 수 있습니다. 이는 오래된 소프트웨어의 점진적인 현대화로 이어지며 마이크로서비스를 사용하여 제품을 처음부터 다시 개발하는 것보다 선호됩니다. 애플리케이션 개발은 마이크로서비스 설계에서 큰 이점을 얻을 수 있습니다. 다음은 주요 이점 중 일부입니다.

ㅏ. 우수한 생산성

애플리케이션이 더 작고 자급자족할 수 있는 섹션으로 분할되면 애플리케이션을 만들고 유지 관리하는 것이 더 쉽습니다. 요구 사항에 따라 여러 프로그래밍 언어, 기술 및 소프트웨어 환경을 사용하여 각 서비스를 독립적으로 개발, 배포 및 유지 관리할 수 있습니다. 애플리케이션의 각 모듈식 구성 요소는 코드베이스가 더 작기 때문에 여러 서비스를 릴리스, 확장, 배포 및 테스트하는 것이 더 간단하고 관련 작업을 개발 팀 간에 분할하여 동시에 실행할 수 있습니다.

비. 복원력 향상

마이크로 서비스 아키텍처의 각 마이크로 서비스는 애플리케이션의 기능을 제공하고 개별 작업을 수행하도록 설계된 단일 서비스입니다. 각 마이크로 서비스는 비즈니스 문제를 처리하기 위해 간단한 인터페이스를 사용하여 다른 서비스와 연결됩니다. 마이크로서비스 기반 설계를 구축한 후에는 성능 관련 문제를 감지하고 해결하는 전체 프로세스가 다소 간단해집니다.

또한 이러한 형태의 설계는 개별 모듈에 비해 향상된 오류 격리 메커니즘을 제공하므로 더 큰 응용 프로그램은 종종 단일 오류의 영향을 받지 않습니다. 따라서 개발자가 전체 프로그램을 다시 시작할 필요 없이 업데이트를 릴리스하거나 모듈을 교체할 수 있는 시간이 있으므로 장기적으로 향후 가동 중지 시간의 위험이 상당히 줄어듭니다.

씨. 확장된 확장성

DevOps 팀은 각 서비스가 다른 프로그래밍 언어 또는 기술을 사용하여 생성되는 경우 비호환성에 대한 걱정 없이 각 모듈에 대한 최적의 기술 스택을 선택할 수 있습니다. 개별 서비스를 독립적으로 확장할 수 있으며 시스템 다운타임이나 재배포 없이 새 구성 요소를 추가할 수 있습니다. 또한 서비스를 여러 서버로 분할하여 매우 까다로운 구성 요소의 성능 영향을 완화할 수 있습니다. 몇 초 안에 마이크로서비스는 수평적 확장을 제공할 수 있습니다.

실제로 Netflix, Spotify, Uber 및 Google과 같은 조직이 모놀리식에서 마이크로서비스 아키텍처로 전환하도록 하는 것은 높은 수평 확장입니다. 둘째, 하나의 마이크로서비스가 CPU를 많이 사용하는 경우 CPU에 최적화된 프로그래밍 언어(C/C++, Rust)로 작성될 수 있지만 다른 마이크로서비스는 인터프리터 언어(Java, PHP)로 작성될 수 있습니다.

디. 지속적 통합/지속적 제공(CI/CD)

지속적인 제공과 통합은 애자일 방법론과 DevOps 철학 모두의 기본 요소입니다. 마이크로 서비스 설계를 통해 기능 간 팀이 독립적으로 서비스를 빌드, 디버그, 테스트, 배포 및 업데이트할 수 있으므로 장기적으로 더 빠른 문제 해결 및 배포가 가능합니다.

이자형. 모듈화

마이크로서비스 아키텍처에서 마이크로서비스 간의 장벽은 교차하기 어려운 물리적(네트워크) 인터페이스로 구성됩니다. 결과적으로 잘 설계된 마이크로서비스는 일반적으로 "느슨하게 연결되고 일관성이 높은" 모듈화를 제공합니다. 소프트웨어 개발을 사회에 비유한다면 마이크로서비스 변조는 경찰/처벌이 있는 국내 및 국제법에 필적합니다. 우리가 이미 알고 있듯이 엄격한 국내 및 국제 규칙은 종종 사회 질서를 유지할 수 있습니다.

에프. 출시 일정

마이크로서비스 아키텍처의 가장 좋은 점은 각 마이크로서비스를 개별적으로 배포할 수 있다는 것입니다. 그 결과 마이크로서비스 애플리케이션의 소프트웨어 릴리스 주기가 상당히 단축되었으며 CI/CD를 사용하면 매일 많은 릴리스가 만들어질 수 있습니다.

마이크로서비스 아키텍처의 단점

ㅏ. 서비스 간 통신의 복잡성 증가

응용 프로그램이 더 작은 부분으로 분할되면 메시지를 보내고 받는 데 더 많은 시간이 걸립니다. When handling requests between the different modules, developers have to be extra careful. Different systems might talk to each other in different ways, so there might be a need for an interpreter. This can make it harder to set up the whole system all at once. One of the biggest problems with microservices is that it might be hard to switch from a monolith to microservices because it's hard to manage.

This basically means that a lot of services made by a lot of different teams are deployed in a lot of different places, making it very hard to manage them. For example, Monolithic Architecture gives the same answer whether a Web app has a few thousand lines of code or several million lines of code (Enterprise Java or Ruby on Rails or PHP). But in Microservice Architecture, there are many possible solutions depending on the applications and use cases.

So, Microservice Architecture is doomed to fail if the wrong solution is used for the wrong application size or type (like putting a child's clothes on an adult man or the other way around). Also, it's hard to design Microservices because they have a lot more moving parts than Monoliths. Most of the time, a Microservice with bad design is worse than a Monolith.

비. 복잡한 구성

Despite being isolated and self-contained, a microservice must be regularly configured, especially when it is moved from development to test to staging to production. This arrangement may be rather intricate. Moreover, if a microservice must utilize other microservices, these bindings must be defined before deployment or even during runtime.

씨. Context Boundary Translation

Despite the fact that it would be ideal if all microservices within a MOA used the same data structures and communication protocols to interact with one another, this is typically not the case.

디. More Assets in Return for More Autonomy

MOAs demand a great deal of horsepower. Remember that each MOA microservice has its own runtime environment and data storage. In some instances, even the most streamlined microservice might consume the same amount of resources as a single monolithic program.

이자형. Unfeasible for Small Applications

Larger applications can benefit from microservices design. However, implementation will likely be more time-consuming and difficult for smaller applications.

에프. Relatively Complex Deployment

The deployment might be a difficult and complicated process. During deployment, coordination between numerous services would be required. Deploying a WAR file in a container would not be as straightforward as it sounds.

g. Distributed Debugging

The difficulty of troubleshooting a MOA including hundreds of microservices communicating in concert is one of the downsides of microservices. Tracing the course of a request into and out of a MOA is challenging due to the independence of each container. The MOA is opaque if there is no effective monitoring mechanism in place. Logging the internals of a MOA offers a limited perspective, but MOA monitoring requires a comprehensive view.

시간. Contributes to Enhanced Fault Tolerance

Large applications with several services deployed have more fault tolerance in the event that any one module fails. Microservices allow applications to continue functioning even if one service fails. This is because the services are not tightly coupled.

나. Costly

An improper service partition might be expensive. For instance, if an application is improperly partitioned, the services are connected to a certain degree, and they will create numerous inter-service interactions via the network, which can degrade performance.

제이. Greater Security Risks

Lastly, because microservices will reside across several environments, computers, and API requests, they provide a greater number of entry points for an attacker to compromise the system.

케이. Communication Complexities

Microservices accomplish rigorous modularity and development independence via process/network barriers, as previously mentioned. The disadvantage is that services may only communicate over the physical network, resulting in increased network latency. Microservices may connect with one another in a variety of methods, including synchronous communication using REST, gRPC, and asynchronous communication using Message Queue and Message Broker, each of which has advantages and disadvantages.

Synchronous communication is simpler to build, but it might result in a Distributed Monolith. Asynchronous Communication via Messaging provides greater flexibility at the expense of increased implementation complexity. In Microservice Architecture, choosing the appropriate Communication channel based on the application is equally tough.

엘. 복잡한 구성

격리되고 자체 포함되어 있음에도 불구하고 마이크로 서비스는 특히 개발에서 테스트, 스테이징, 프로덕션으로 이동할 때 정기적으로 구성해야 합니다. 이 배열은 다소 복잡할 수 있습니다. 또한 마이크로 서비스가 다른 마이크로 서비스를 활용해야 하는 경우 이러한 바인딩은 배포 전이나 런타임 중에도 정의해야 합니다.

마이크로서비스 도구

1. 운영체제

응용 프로그램 개발의 가장 중요한 측면은 운영 체제가 담당하는 작업에 대한 견고한 기반을 마련하는 것입니다. Linux는 애플리케이션 개발 프로세스 전반에 걸쳐 자주 사용되는 이러한 유형의 운영 체제의 한 예입니다. Linux 컨테이너를 사용할 때 독립 실행 환경에 액세스할 수 있습니다. 이를 통해 스토리지 및 네트워킹에서 보안 및 인증에 이르기까지 광범위한 서비스를 오케스트레이션할 수 있습니다.

2. 프로그래밍 언어

Emizentech를 사용하면 이제 프로그래밍 레퍼토리를 원활하게 확장할 수 있습니다. 이 도구는 실용적이고 최신입니다. 일반적으로 모든 프로그래밍 언어와 함께 사용하도록 설계되었습니다. 또한 Erlang 가상 머신이라고도 하는 BEAM에 표시되는 바이트 코드와 호환됩니다.

3. API 관리 및 테스트 도구(API 게이트웨이)

API 구축 및 릴리스, 사용 표준 시행, 액세스 제한, 개발자 커뮤니티 육성, 사용 통계 수집 및 분석, 성능 보고는 모두 API 관리의 구성 요소입니다.

실제로 API 관리 플랫폼은 다음 요소로 구성됩니다.

• 개발자 도구
• 게이트웨이
• 보고 및 분석

4. 메시징 도구(메시징 및 이벤트 스트리밍)

통신이 이루어지기 위해서는 마이크로서비스 시스템이 독립적인 서비스를 이용해야 합니다. 이것은 메시지 대기열이 사용자에게 요구하는 것을 결정하는 기본 요소입니다. RabbitMQ와 Apache Kafka는 메시징 목적으로 사용되는 가장 널리 사용되는 두 가지 솔루션입니다.

LinkedIn은 나중에 Apache 커뮤니티에 기여한 Apache Kafka로 알려진 기술의 생성을 담당합니다.

패턴은 많은 마이크로서비스 간의 통신을 용이하게 하기 위해 RabbitMQ 도구에서 활용됩니다. 그 외에도 애플리케이션을 동시에 확장하는 프로세스를 지원합니다.

5. 툴킷

간단히 말해서 툴킷은 특정 절차의 실행 전반에 걸쳐 사용되는 도구 모음입니다. 툴킷은 많은 앱을 구성할 수 있게 해주는 마이크로서비스 아키텍처의 구성 요소입니다. 이 때문에 다양한 툴킷이 존재하며, 각 툴킷은 애플리케이션에서 뚜렷한 목적을 제공합니다. Fabric8 및 Seneca 내에서 선택할 수 있는 많은 도구.

• Fabric8은 Git의 도움으로 소프트웨어 개발자가 응용 프로그램에 대한 구성 관리 시스템을 만들 수 있도록 하는 서비스 기술로서의 플랫폼입니다.
• Node로 동작하는 Seneca는 메시지 지향 마이크로 서비스를 개발하는 과정에서 사용됩니다.

6. 아키텍처 프레임워크와 Js 툴킷

마이크로서비스는 아키텍처 스타일이므로 마이크로서비스가 사용하는 아키텍처 프레임워크에 주의를 기울여야 합니다. 이들은 가장 최근의 애플리케이션을 구성하기 위해 현재 기술과 함께 활용되는 프레임워크입니다. Goa와 Kong은 이제 가장 인기 있는 아키텍처 프레임워크입니다.

7. 오케스트레이션 도구

컨테이너와 마이크로서비스가 함께 작동하는 일반적인 방식으로 인해 컨테이너 오케스트레이션은 고려해야 할 매우 중요한 주제입니다. Conductor, Kubernetes 및 Istio는 컨테이너 오케스트레이션에 가장 자주 사용되는 세 가지 마이크로 서비스 오케스트레이션 솔루션입니다. 그러나 다른 많은 도구를 사용할 수 있습니다. Netflix가 유지 관리하는 오픈 소스 소프트웨어(OSS) 에코시스템의 일부인 지휘자는 마이크로서비스 오케스트레이션 엔진 역할을 합니다. 지휘자는 클라우드에서 실행되고 플로우 오케스트레이터라는 구현을 사용하여 마이크로 서비스를 사용하여 다양한 활동을 수행하는 프로그램입니다. 이 외에도 마이크로 서비스에서 발생하는 모든 상호 작용을 더 쉽게 관리하고 볼 수 있습니다.

8. 모니터링 도구

마이크로 서비스 애플리케이션이 구성된 후에는 이와 관련된 작업을 처리해야 합니다. 동일한 작업을 수행하려면 마이크로서비스에 대한 모니터링 도구가 필요합니다. Prometheus와 Log Stash는 가장 자주 사용되는 마이크로 서비스를 모니터링하는 두 가지 기술입니다. Logstash는 훌륭한 소프트웨어입니다. 데이터를 통합, 저장, 조작할 수 있는 플랫폼이며 오픈 소스입니다.

9. 서버리스 도구

SA 마이크로 서비스의 중요한 구성 요소는 종종 서비스로서의 기능(Function-as-a-Service)으로 알려진 서버리스 기술입니다. 물체를 가장 기본적인 구성 요소로 분해하는 프로세스의 효율성을 향상시킵니다. Claudia와 AWS Lambda는 모두 마이크로서비스 개발에 널리 사용되는 서버리스 도구의 예입니다. AWS Lambda 및 API Gateway 설치도 Claudia의 책임 중 하나입니다. 이 외에도 Claudia는 "즉시 사용 가능한" 기능을 유지하면서 오류가 발생하기 쉬운 배포 및 설정 활동을 자동화할 수 있습니다.

10. 컨테이너, 도커, 쿠버네티스

• 컨테이너: 컨테이너는 기본적으로 호스트 운영 체제(또는 커널)를 가상화하여 응용 프로그램의 요구 사항을 동일한 컴퓨터에서 실행 중인 다른 컨테이너의 요구 사항과 분리합니다.
• Docker: Docker는 dockerd라고 하는 컨테이너 런타임, BuildKit이라고 하는 컨테이너 이미지 빌더, 빌더, 컨테이너 및 엔진과 상호 작용하는 데 사용되는 명령줄 인터페이스를 포함하여 여러 부분으로 구성됩니다. (도커라고 함).
• Kubernetes 는 컴퓨터 그룹을 단일 컴퓨팅 리소스 풀로 결합하는 무료 오픈 소스 컨테이너 관리 기술입니다. 쿠버네티스는 구글에서 개발했습니다. Kubernetes를 사용하면 Docker 엔진에 의해 실행되는 컨테이너 그룹의 형태로 애플리케이션을 구성할 수 있습니다. Kubernetes는 애플리케이션이 지정한 방식으로 계속 작동하도록 합니다.

마이크로서비스 아키텍처의 일반적인 패턴

ㅏ. BFF(backend-for-frontend) 패턴

BFF는 프론트엔드와 마이크로서비스 간의 간단한 인터페이스를 제공합니다. 이상적인 시나리오에서 프런트 엔드 팀은 BFF 관리도 담당합니다. 단일 BFF는 단일 UI에만 관련됩니다. 결과적으로 프론트엔드를 단순화하고 백엔드를 통해 단일 데이터 보기를 가질 수 있습니다.

비. 엔터티 및 집계 패턴

엔티티는 ID에 따라 구별되는 것입니다. 예를 들어 전자 상거래 웹사이트에서 제품 개체는 제품 이름, 유형 및 가격으로 식별될 수 있습니다. 집계는 단일 단위로 간주되어야 하는 사물의 그룹입니다. 따라서 전자 상거래 웹 사이트의 경우 주문은 고객이 구매한 물건(엔티티)의 모음(집계)이 됩니다. 이러한 패턴은 데이터를 의미 있게 분류하는 데 사용됩니다.

씨. 서비스 검색 패턴

서비스 및 응용 프로그램의 검색을 용이하게 하는 데 중요한 역할을 합니다. 서비스 인스턴스는 서비스 장애, 확장성, 서비스 종료 및 업그레이드와 같은 원인으로 인해 마이크로 서비스 아키텍처의 컨텍스트에서 다를 수 있습니다. 이러한 패턴은 이러한 일시적인 문제를 처리하기 위한 검색 도구를 제공합니다. 상태 확인 및 서비스 실패를 트래픽 재조정 트리거로 사용하여 로드 밸런싱은 서비스 검색 기술을 사용할 수 있습니다.

디. 어댑터 마이크로서비스 패턴

어댑터 마이크로서비스 설계는 필요한 경우 RESTful 또는 경량 메시징 기술을 사용하여 구성된 비즈니스 지향 API(일반 마이크로서비스와 동일한 도메인 기반 방법론 사용)와 레거시 API 또는 클래식 WS-* 기반 SOAP 서비스 간에 조정합니다. 예를 들어 개발 팀이 애플리케이션의 데이터 소스에 대한 분산 제어가 부족한 경우 적응이 필요합니다.

이자형. 스트랭글러 애플리케이션 패턴

Strangler 패턴은 특정 기능을 새로운 서비스로 대체하여 모놀리식 애플리케이션을 마이크로 서비스로 천천히 변환하는 잘 알려진 아키텍처 패턴입니다.

마이크로서비스 아키텍처의 안티패턴

ㅏ. 응집력 혼돈

서비스는 비즈니스 기능과 명확하게 일치해야 하며 범위를 벗어나는 작업을 수행하려고 해서는 안 됩니다. 문제의 기능적 분리는 아키텍처가 관리하는 데 중요합니다. 그렇지 않으면 민첩성, 성능 및 확장성이 손상되어 전달 엔트로피 및 응집력 혼돈이 있는 긴밀하게 연결된 아키텍처가 생성됩니다.

비. 계층화된 서비스 아키텍처

가장 널리 퍼진 SOA 실수 중 하나는 서비스 재사용성을 달성하는 방법에 대한 오해였습니다. 팀은 기능적 재사용성보다는 기술적 응집성에 크게 관심을 가졌습니다.

씨. 복잡성

마이크로서비스 아키텍처를 지원하는 또 다른 중요한 요소는 조직의 성숙도입니다. 개발팀은 단순히 인프라 팀에 편도 티켓을 제출하는 것이 아니라 전체 스택인 DevOps에 대해 더 큰 책임을 지도록 개혁되어야 합니다.

디. 잘못된 버전 관리 전략

비효율적인 버전 관리 전략은 관리할 수 없는 코드와 종속성을 초래합니다. 결과적으로 마이크로서비스 아키텍처에 대한 효율적인 버전 관리 방식이 마련되어야 합니다. 가장 기본적인 접근 방식 중 하나는 API 버전을 생성하고 해당 버전을 경로 URL에 포함하는 것입니다.

이자형. 마이크로서비스 워크로드 데이터 액세스 패턴의 부적절한 설계

부적절한 마이크로서비스 워크로드 데이터 액세스 패턴: 마이크로서비스의 아키텍처는 조직의 데이터베이스에 따라 다릅니다. 마이크로서비스 전반의 데이터 액세스 패턴은 명확하게 분리되어야 합니다. 데이터가 적절하게 분할된 테이블/컬렉션에 있는 한 여러 서비스 인스턴스에서 단일 데이터베이스를 활용하는 것이 종종 허용됩니다.

에프. 의존성 장애

종속성 장애는 서비스가 제대로 작동하기 위해 특정 순서로 배포되어야 함을 인식할 때 발생하는 반패턴입니다. 관심사의 기능적 분리에 대한 통제가 없을 때 응집력 혼란이 발생할 수 있습니다.

이 안티 패턴을 피하는 좋은 방법은 API 게이트웨이를 도입하는 것입니다.

모놀리식, 마이크로서비스 및 서비스 지향 아키텍처의 차이점

마이크로서비스를 요구하는 주요 수직 시장

의료: 의료 마이크로서비스 시장은 2015년 1억 3000만 달러에서 2025년 5억 1900만 달러로 성장할 것으로 예상됩니다. 더 빠른 서비스 롤아웃, 새로운 기술의 더 빠른 수용, 더 나은 효율성에 대한 요구가 의료 산업의 발전을 주도하고 있습니다. 의료 산업은 데이터 보안 및 규정 준수 요구 사항과 구현 어려움을 극복하는 방법에 대한 해답을 찾고 있습니다.

은행, 금융 및 보험: Aspen Mesh는 금융 서비스를 위한 마이크로서비스의 세 가지 중요한 이점, 즉 고유한 ID 서비스 생성을 통한 보안 강화, 새로운 기능의 더 빠른 제공, 관리하기 쉬운 API 계층을 식별합니다.

정부: 마이크로서비스 아키텍처의 다양한 이점 외에도 정부 기업은 비즈니스 목표에 해당하는 기능을 설계할 수 있는 능력의 이점을 누릴 수 있으므로 IT 팀이 구성 요소의 요구에 따라 서비스를 구축하거나 개선할 수 있습니다.

소매: Amazon과 eBay는 접근성과 확장성이 뛰어난 서비스, 보다 효과적인 버그 및 오류 관리를 포함하여 소매 산업을 위한 마이크로서비스의 이점을 입증했습니다.

미디어 및 엔터테인먼트: 2009년 Netflix는 마이크로서비스로 마이그레이션했으며 현재 이 서비스는 500개 이상의 마이크로서비스를 사용하여 매일 20억 개의 에지 요청을 처리합니다. 이러한 변화는 속도, 확장성 및 접근성을 제공합니다.

마이크로서비스 아키텍처를 채택한 회사의 예

Amazon, Coca-Cola 및 Zalando는 IT 인프라를 마이크로서비스 아키텍처로 변경하고 있습니다. 또한 내부 조직 구조를 재편하고 기업을 시장의 최전선으로 몰아가고 있습니다. 마이크로서비스 아키텍처를 구현하는 것은 업계 최고의 지식을 얻을 때 즐겁습니다. 다음은 마이크로서비스의 가장 효과적인 사례 중 일부입니다.

#1. 우버

소유권 개념은 얽힌 모놀리식 종속성에 의해 황폐화되었습니다. 마이그레이션이 어려워졌습니다. 새로운 개발자는 모놀리스에 기여할 수 없었습니다. 작은 실수가 치명적인 결과를 낳았습니다. Uber는 클라우드 기반 서비스를 구현하기로 결정했습니다. Uber는 인보이스 발행, 승객 및 여행 관리를 포함한 여러 작업을 위한 마이크로서비스를 개발했습니다. API 게이트웨이는 서비스와 통신하는 데 사용됩니다.

또한 Uber는 마이크로서비스에 대한 전 세계 표준을 수립했습니다. 문서화, 신뢰성, 내결함성 등에 대한 정량적 기준을 제공합니다. 이러한 특성은 페이지 방문과 같은 상업적 지표를 사용하여 모니터링되었습니다. 곧 그들의 서비스는 최고 수준에 이르렀습니다.

#2. 넷플릭스

그런 다음 Netflix는 클라우드 기반 분산 데이터 인프라로 마이그레이션했습니다. AWS는 수평 확장 가능한 시스템 및 추가 서비스/기능을 제공하는 데 사용되었습니다. 2009년 넷플릭스가 이전을 시작했고 거의 3년 만에 완료되었습니다. 그런 다음 Netflix는 모든 사용자 대면 애플리케이션을 자율적 마이크로서비스로 변환했습니다. 2012년, 화장이 완료되었습니다. 2015년까지 Netflix는 모든 서비스 중단을 제거했으며 하루에 약 20억 개의 API 쿼리를 처리할 수 있었습니다. 현재 Netflix는 190개국에서 1억 3900만 명이 넘는 사용자를 보유하고 있습니다. 현재 Netflix는 약 700개의 마이크로서비스 시스템을 별도로 운영하고 있습니다.

#삼. 아마존

Amazon은 2001년에 거대한 단일체를 가지고 있었습니다. 2021년에는 거의 모든 사람이 Amazon Web Services(AWS)에 익숙합니다. Amazon Web Services(AWS)는 그 우수성으로 인해 상용 클라우드 컴퓨팅 서비스가 된 내부 솔루션입니다. 마이크로서비스는 사용자 활동, 구매 및 전체 판매 유입경로를 추적할 수 있기 때문에 전자 상거래에 탁월합니다. Amazon의 수석 제품 관리자에 따르면

그런 다음 제품 프레젠테이션 및 판매 프로세스 자체를 최적화하는 데 유용한 데이터를 생성합니다. Amazon은 마이크로서비스가 전체 조직을 변화시키는 데 중요한 역할을 한 최초의 회사 중 하나입니다. 모놀리스 설계가 정보 기술 시스템 구축의 "표준"이던 시기에 세계적인 거물은 놀라운 성공을 거두었습니다.

모든 중요한 코드 수정은 사용자에게 제공되기 몇 주 전에 배포 프로세스에서 중단되었습니다. Amazon은 프로세스를 간소화하고 기간을 줄이기 위해 마이크로서비스를 사용했습니다. 구조를 개별 앱으로 분리함으로써 개발자는 병목 현상이 발생한 위치, 속도 저하의 특성을 파악하고 구조를 서비스 지향 아키텍처로 재구축할 수 있었습니다. 각 구조에는 단일 서비스에 전념하는 소규모 팀이 있습니다.

시스템 정리로 시작된 것은 현대 건축의 주요 온라인 플레이어 중 하나의 성장으로 이어졌습니다. Amazon은 현재 만연한 AWS(Amazon Web Services)와 같은 일련의 오픈 소스 기술을 출시하여 다른 비즈니스의 길을 개척했습니다.

#4. 이베이

eBay 시스템은 약 천 개의 마이크로서비스를 지원합니다. 웹, 기본 iOS 및 Android 애플리케이션과 같은 프런트 엔드 환경은 통화를 조정하는 중개 서비스에 연결한 다음 백 엔드 서비스와 통신합니다. 각 서비스에는 자체 개발 그룹이 있습니다. 대부분의 eBay 마이크로서비스는 설계자 없이 진화했으며 시스템은 항상 아래에서 위로 설계되었습니다. eBay와 같은 대다수의 대기업은 고객 요구 사항에 따라 작동하고 물론 항상 변화하는 다중 언어 마이크로서비스 모음을 사용했습니다.

#5. 사운드클라우드

각 서비스는 독립적으로 개발 및 배포되며 JSON 또는 Thrift와 같은 경량 데이터 교환 표준을 사용하여 네트워크를 통해 다른 서비스와 연결됩니다. 전환 기간 동안 새로운 마이크로서비스는 MySQL의 관계형 모델을 변경할 수 없었고 더 나쁜 경우에는 다른 스토리지 엔진을 사용할 수 없었습니다. 스레드 기반 모델이 채팅과 같은 모델로 대체된 사용자 간 메시징과 같은 극단적인 상황의 경우 회사는 cronjob을 사용하여 별도의 데이터베이스를 동기화했습니다.

#6. 스포티 파이

Spotify는 사내 동기화 지옥을 방지하기 위해 자율 풀 스택 팀이 담당하는 마이크로 서비스 아키텍처로 설계되었습니다. Spotify는 모든 소프트웨어 개발자가 고유한 기능을 가진 폐쇄된 "영역"에서 작성하는 마이크로서비스 아키텍처를 사용합니다. 각 마이크로서비스에는 단일하고 직접적인 책임이 있으며 대부분의 경우 다른 프로세스에서 액세스할 수 없는 데이터베이스와 논리가 있습니다.

마이크로서비스는 어떤 종류의 문제를 극복하는 데 도움이 될 수 있습니까?

이것은 "마이크로서비스가 해결하는 어려움은 무엇입니까?"라는 질문에 대한 해결책입니다. 마이크로서비스 아키텍처가 극복하는 데 도움이 된 장애물을 살펴보겠습니다.

사례 1 eBay의 잔액 회복

eBay는 거의 천 개의 서비스를 활용합니다. 많은 프런트 엔드 서비스는 API 호출을 전송하는 반면 백 엔드 서비스는 관리 및 배송 관련 작업을 수행합니다. eBay는 원래 Perl 및 C++ 모놀리식 프로그램을 활용했습니다. eBay의 웹사이트는 다른 많은 인터넷 거물들을 위한 것처럼 주요 제품입니다. eBay 웹사이트에 몇 가지 증분 기능을 추가해야 할 필요성이 계속해서 증가했습니다. 또한 이러한 유형의 웹사이트는 새로운 기능이 추가되더라도 하루 24시간 액세스할 수 있어야 했습니다.

가동 중지 시간을 최소화해야 하기 때문에 eBay는 마이크로서비스 아키텍처로 전환하기로 결정했습니다. 이를 통해 사이트가 보다 안정적이고 비동기식 통합이 촉진되었습니다. 배포 유연성과 릴리스 주기 기간이 크게 개선되었습니다. 서비스가 격리되면 성능 효율성이 향상되고 수평 확장이 더 쉬워졌습니다.

사례 2 Uber와 급속한 확장

가장 인기 있는 택시 호출 서비스인 Uber는 샌프란시스코에서 통근자들에게 서비스를 제공하는 단일 패키지로 시작하여 처음 구현되었습니다. 밀접하게 연결된 이 소프트웨어는 청구, 지불 및 운전자 연결 서비스를 포함한 대부분의 비즈니스 활동을 관리할 수 있었습니다. 그러나 회사가 발전하면서 상황이 쇠퇴하기 시작했습니다. Uber는 서비스 영역을 확장하고 다른 서비스를 제공했습니다.

추가 기능이 추가됨에 따라 패키지는 더욱 응집력이 높아졌습니다. 모든 논리가 한 곳에 담겨 있었고 난관이 생기기 시작했다. 곧, 약간의 수정이라도 전체 프로그램을 재배포해야 했습니다. 지속적인 통합은 거의 즉시 주요 책임이 됩니다.

소유권 모델이 없는 것은 모노리스의 많은 상호 의존적 종속성 때문이었습니다. 따라서 이주가 어려웠습니다. 새로 고용된 개발자가 모놀리스에 기여할 수 없는 경우도 발생했습니다. 사소한 실수라도 그 결과는 심각했다. 마이크로서비스를 구현하기로 결정한 시점입니다. 그들의 움직임에는 시간이 걸렸다. 그들은 전체 서비스를 분해하고 모놀리식 애플리케이션을 Python, Node.js 및 Apache Thrift를 사용하여 구축된 마이크로 서비스 지향 아키텍처로 마이그레이션했습니다.

사례 3 Twitter의 향상된 가동 시간

트위터는 처음에 모놀리식 디자인을 활용했는데 이는 매우 의미 있는 일이었습니다. 그러나 더 많은 개인이 Twitter에 등록하면서 문제가 발생했습니다. SDLC는 빌드 시간이 길어지면서 점점 더 커지고 복잡해졌으며 때때로 용량 초과 오류 경고가 표시되면서 확장성이 크게 저하되었습니다.

Twitter는 이 문제를 해결하기 위해 아키텍처를 마이크로서비스로 변경했습니다. 각 마이크로서비스는 모듈식으로 잘 정의되고 자율적으로 생성되었습니다. 각 구성 요소를 개별적으로 테스트하고 배포할 수 있습니다. 그들은 또한 독립적으로 측정될 수 있습니다. 곧 오류 경고가 완전히 사라졌습니다.

CASE 4 KarmaWifi 및 스파게티 코드

Karma에는 사람, 가제트 및 상점이 있습니다. 모놀리식 프로그램을 사용할 수 있게 되면서 사용자 관련 코드는 결국 장치 관련 부분이 되었습니다. 또한 스토어 API는 디바이스 API를 따랐습니다. 얼마 지나지 않아 무엇이 변경되었고 누가 변경했는지 확인하기가 어려워졌습니다. 초기 목표는 모놀리스를 기능적 라이브러리로 나누는 것이었지만 새로운 소프트웨어 버전으로 확장하고 적용하는 것은 어려울 수 있다는 것이 밝혀졌습니다. 또한 시장에 출시될 미래의 혁신을 실험할 수 없습니다.

그 당시에는 마이크로서비스 기반 아키텍처를 사용하기로 결정했습니다. 필요하다고 판단되면 백엔드 애플리케이션의 일부를 개별 서비스로 분리했습니다. 부품은 처음에는 거대했지만 시간이 지남에 따라 더 작은 서비스로 분할되었습니다. 결국 모든 마이크로서비스에는 단일 작업과 걱정할 최대 크기가 있었습니다.

사례 5 Walmart의 향상된 성능

Walmart의 마이크로서비스 모험은 OneOps라는 소규모 비즈니스에서 DevOps 플랫폼을 인수하면서 시작되었습니다. 그들은 커뮤니티에 다시 기여할 수 있도록 오픈 소스 이니셔티브를 선택했습니다.

그들은 Node.js 및 Cassandra 데이터베이스와 같은 기술을 활용하여 API를 통해 동적으로 트리거될 수 있는 다양한 마이크로서비스를 만들기 시작했습니다. 목표는 Walmart의 여러 사업부에서 일하는 개발자가 앱을 소유하고 그렇게 할 수 있도록 권한을 부여하는 것을 더 간단하게 만드는 것이었습니다. 그들은 이것이 중앙 집중식 IT 그룹에 대한 의존도를 감소시킨다는 것을 발견했습니다.

궁극적으로 조직의 전자 상거래 제품의 백엔드 기능을 확장할 수 있는 개발자의 능력은 비즈니스 민첩성을 높이는 데 기여했습니다.

Android 및 iOS에서 마이크로서비스 아키텍처를 구현하는 방법은 무엇입니까?

1. 1단계: 그것이 정말로 당신의 비즈니스에 필요한 것인지 결정하십시오.
2. 2단계: 그렇다면 이미 존재하는 인프라를 살펴보십시오.
3. 3단계: 팀이 이 방법을 사용할 수 있도록 준비합니다.
4. 4단계: 모놀리식 시스템에서 마이크로서비스 시스템으로 전환하는 경우 데이터 관리자에게 정보를 잘 알고 작업을 이해하고 있는지 확인하십시오.
5. 5단계: 코딩을 위한 언어와 프레임워크를 선택합니다.
6. 6단계: 서비스, 컨테이너 및 가상 머신 템플릿을 사용하여 기본 아키텍처를 설정합니다.
7. 7단계: 아키텍처가 "모놀리스"인 경우 데이터베이스를 여러 개의 작은 데이터베이스로 분할합니다.
8. 8단계: API 게이트웨이를 제자리에 놓습니다.
9. 9단계: 추적을 추적하고 지도를 만듭니다.
10. 10단계: 자동화를 사용하여 테스트합니다.

마이크로서비스는 미래인가?

이 기사의 주요 목표는 마이크로서비스의 기본 개념과 원칙을 설명하는 것입니다. 이를 달성하기 위한 노력을 통해 우리는 마이크로서비스 아키텍처 스타일을 기업 애플리케이션에서 신중하게 검토해야 하는 필수 개념으로 간주한다는 것이 분명합니다. 최근에 우리는 이 방식을 사용하는 여러 시스템을 개발했으며 이 방법을 높이 평가하는 다른 사람들도 알고 있습니다. Amazon, Netflix, The Guardian, 영국 정부 디지털 서비스(UK Government Digital Service), realestate.com.au, Forward 및 comparethemarket.com은 어떤 형태로든 건축 스타일을 개척하고 있는 사람들입니다.

종종 아키텍처 결정의 실제 결과는 몇 년 후까지 분명하지 않습니다. 모듈화에 대한 강력한 추진력을 가진 우수한 팀은 시간이 지남에 따라 성능이 저하되는 모놀리식 디자인을 구축한 경우가 있습니다. 많은 사람들은 서비스 경계가 분명하고 수정하기 어렵기 때문에 마이크로서비스에서는 이러한 저하가 덜 가능하다고 주장합니다. 그러나 충분한 수명을 가진 충분한 수의 시스템이 확보될 때까지는 마이크로서비스 아키텍처의 성숙도를 정확하게 평가할 수 없습니다.

마이크로서비스가 천천히 발전할 것이라고 예상하는 데에는 분명히 이유가 있습니다. 모든 구성 요소화 노력의 성공은 소프트웨어가 구성 요소에 얼마나 잘 맞는지에 달려 있습니다. 구성 요소 테두리를 배치해야 하는 위치를 결정하기가 어렵습니다. 진화적 설계는 정확한 경계를 설정하는 것이 어렵다는 것과 경계를 재작업하는 것을 간단하게 만드는 것의 중요성을 인정합니다. 그러나 구성 요소가 외부 통신이 있는 서비스인 경우 리팩토링은 프로세스 내 라이브러리로 작업할 때보다 훨씬 어렵습니다.

서비스 경계를 ​​넘어 코드를 이동하는 것은 복잡하고, 모든 인터페이스 수정은 참가자 간에 조정되어야 하고, 추가 호환성 계층을 설정해야 하며, 테스트는 복잡합니다. 구성 요소가 깔끔하게 구성되지 않으면 구성 요소 내에서 구성 요소 간의 링크로 복잡성을 이동하는 것입니다. 이것은 복잡성을 이동시킬 뿐만 아니라 덜 명확하고 관리하기 더 어려운 위치로 이동시킵니다. 작고 간단한 구성 요소의 내부를 조사할 때 서비스 간의 복잡한 연결을 간과하고 사물이 실제보다 낫다는 결론을 내리기 쉽습니다.

마지막으로 고려해야 할 팀 역량이 있습니다. 숙련된 팀은 새로운 관행을 수용할 가능성이 더 큽니다. 그러나 고도로 숙련된 팀에서 더 성공적인 접근 방식이 덜 숙련된 팀에서 항상 효과가 있는 것은 아닙니다. 우리는 무능한 팀이 조잡한 모놀리식 구조를 구성하는 몇 가지 예를 보았지만 이러한 유형의 혼란이 마이크로서비스에 발생할 때 어떤 일이 발생하는지 결정하는 데 시간이 걸릴 것입니다. 형편없는 팀은 항상 나쁜 시스템을 만들어 냅니다. 이 상황에서 마이크로서비스가 상황을 개선하거나 악화시킨다고 말하기는 어렵습니다.

 그래서 우리는 조심스럽게 낙관적으로 이 글을 씁니다. 우리는 마이크로서비스가 여기에 있다고 믿습니다!

EmizenTech를 선택하는 이유

Emizentech는 귀하의 애플리케이션을 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 마이그레이션하는 데 도움을 드릴 수 있습니다. 당사는 귀사의 기업 애플리케이션을 유지 관리하고 확장하기 쉽게 만들 수 있도록 도와드릴 수 있습니다. 비즈니스 성장 및 발전을 원하고 새로운 방법을 찾고 있다면 에미젠텍이 올바른 방법으로 도움을 주면서 동시에 장기적인 성장을 보장할 수 있습니다. 또한 당사 웹 사이트를 방문하여 마이크로서비스에 대해 자세히 알아보고 귀사가 마이크로서비스에 대한 준비가 되었는지 확인하고 이 아키텍처를 구현하는 방법에 대해 이야기할 수 있습니다. 응용 프로그램을 한 가지만 수행하고 인터페이스가 잘 정의된 모듈로 분해하는 데 중점을 둔 소프트웨어를 만드는 방법입니다.

당사 서비스의 특징은 다음과 같습니다.

• 애플리케이션 장애를 방지하는 도메인 기반 아키텍처
• 높은 수준의 확장성 보장
• 분산 데이터베이스 설계
• 단순한 장애 격리를 가능하게 하고,
• DevOps 문화를 사용하여 지속적 전달을 가능하게 합니다.

마무리 생각

다음 단계를 수행하십시오!

이 블로그에서 우리는 마이크로서비스 아키텍처의 여러 측면과 그것이 제시하는 가능성을 조사하기 위해 노력했습니다. 마이크로서비스라고 하는 아키텍처 접근 방식을 사용할 때 애플리케이션 시스템의 기능은 여러 개의 더 작은 기능 단위로 나눌 수 있습니다. 서비스의 구현 및 관리는 서로 별도로 처리됩니다. 모놀리식 시스템이 마이크로서비스 아키텍처를 사용하여 더 작은 조각으로 분할되면 개별 구성 요소의 수가 급격히 증가합니다.

따라서 이들 사이에 존재하는 종속성을 효율적으로 관리하는 것이 필요합니다. 모놀리식 소프트웨어 아키텍처와 비교할 때 마이크로서비스 아키텍처를 만들고 실행하는 것은 많은 도전과제를 제시하고 패러다임 전환을 요구하는 것이 사실입니다. 비슷한 맥락에서 마이크로서비스 아키텍처는 모든 종류의 시스템에서 발생하는 복잡성 문제를 해결할 수 있는 마법의 총알이 아닙니다.

모든 것을 고려할 때 마이크로서비스 아키텍처는 현대 소프트웨어 개발에 매우 ​​유용하고 편리한 도구라고 생각합니다. 마이크로서비스 아키텍처는 복잡성을 효과적으로 처리하고 시장에서 경쟁 우위를 유지하는 유일한 방법이기 때문에 일반적으로 복잡한 소프트웨어를 생성하는 주요 기업을 위한 유일한 실행 가능한 전략입니다. 마이크로서비스 아키텍처는 대기업뿐만 아니라 중소기업에서도 장기적인 이점을 제공할 수 있는 지속 가능한 소프트웨어 개발에 활용되어야 합니다.

Spotify, Netflix, LinkedIn, Amazon, Google과 같은 마이크로서비스 아키텍처의 얼리 어답터는 마이크로서비스 아키텍처를 채택한 결과 경쟁업체보다 큰 경쟁 우위를 확보할 수 있었습니다. 아키텍처 모델의 개발과 검토는 모두 이러한 노력을 지원하기 위한 실행 가능한 옵션입니다. 이 방법은 기업이 치열한 경쟁의 새로운 시대에 들어서고 있는 지금 특히 중요한 손익에 부정적인 영향을 주지 않으면서 일을 단순화하고 개발자의 삶을 더 단순하게 만들 것을 약속합니다.

대다수의 기업은 비용 효율성 향상에 관심을 갖고 있으며 이러한 배경에서 서버리스 아키텍처는 향후 몇 년 동안 더 큰 인기를 얻을 것으로 예상됩니다. 세계의 미래에 마이크로서비스의 잠재적인 범위는 다소 유망한 것으로 보입니다.

마이크로서비스가 비즈니스를 발전시키는 데 도움이 될 수 있습니까? 구속력 없는 상담을 원하시면 언제든지 연락주세요!

읽어 주셔서 감사합니다!

마이크로서비스 아키텍처에 대해 자주 묻는 질문