마이크로 서비스 란 무엇입니까? 다음 소프트웨어 아키텍처

거의 모든 컴퓨터 시스템은 공유 리소스를 사용하여 여러 작업을 수행하며 컴퓨터 프로그래밍의 질문 중 하나는 이러한 작업을 수행하는 코드 비트가 서로 얼마나 밀접하게 연결되어야 하는가입니다. 점점 인기 대답은 microservice의 개념 - 다른 microservices와 상호 작용이 더 큰 시스템을 만들 수 있다는 기능의 작은, 이산 덩어리.

이러한 개별 구성 요소를 갖는 기본 아이디어는 새로운 것은 아니지만 마이크로 서비스가 구현되는 방식은 최신 클라우드 기반 애플리케이션 모두를위한 자연스러운 기반이됩니다. 마이크로 서비스는 또한 새로운 기능을 신속하고 지속적으로 출시하도록 장려하는 devops 철학과 일치합니다.

마이크로 서비스 란 무엇입니까?

마이크로 서비스의 "마이크로"는 이것이 소규모 애플리케이션임을 의미합니다. 그것은 때때로 사실이지만, 그것들에 대해 생각하는 더 좋은 방법은 그것들이 하나의 특정한 일을하거나 특정한 문제를 해결하는 데 필요한만큼만 커야한다는 것입니다. 그 문제는 기술적 인 것이 아니라 개념적이어야합니다. 마이크로 소프트가 말했듯이 "마이크로 서비스는 데이터 액세스 나 메시징과 같은 수평 적 계층이 아닌 비즈니스 기능을 중심으로 설계되어야합니다." 그들은 비교적 안정적인 API를 통해 다른 마이크로 서비스 및 외부 사용자와 통신하여 더 큰 애플리케이션을 만듭니다.

따라서 개별 마이크로 서비스의 내부 기능은 시스템의 나머지 부분에 영향을주지 않고 조정하거나 근본적으로 업그레이드 할 수 있습니다. 이는 devops 상점이 운영하려는 방식과 관련이 있습니다. 더 큰 애플리케이션의 특정 기능이 개별적으로 독립적으로 작동하는 코드 조각으로 분할되면 CI / CD의 devops mantra (지속적 통합 및 지속적 전달)를 수행하는 것이 더 쉽습니다. . 또한 잘 정의 된 API를 사용하면 마이크로 서비스를 쉽게 자동으로 테스트 할 수 있습니다.

마이크로 서비스 아키텍처와 모 놀리 식 아키텍처

"마이크로 서비스 아키텍처"측면에서 마이크로 서비스에 대해 자주 듣게 될 것 입니다. 이 문구는 마이크로 서비스 자체뿐만 아니라 관리 및 서비스 검색을위한 구성 요소뿐만 아니라 마이크로 서비스와 외부 세계 간의 통신을 처리하는 API 게이트웨이를 포함합니다.

"모 놀리 식 애플리케이션"은 마이크로 서비스와 반대입니다. 모든 코드가 하나의 큰 바이너리 실행 파일에있는 응용 프로그램의 복고 이름입니다. TechTarget이 설명했듯이 모 놀리 식 애플리케이션은 확장하기가 더 어렵고 개선하기도 더 어렵습니다. 그러나 하나의 응집력있는 애플리케이션으로 구축 되었기 때문에 마이크로 서비스 아키텍처만큼 많은 관리가 필요하지 않습니다.

제한된 개념 : 마이크로 서비스를 정의하는 방법

마이크로 서비스가 특정 작업을 수행해야한다는 이전 명령으로 잠시 백업 해 보겠습니다. 말하기는 쉽지만 실제로는 기능이 종종 얽혀 있고 그리기 분할이보기보다 어렵습니다. 도메인 분석 및 도메인 기반 설계는 큰 그림 작업을 마이크로 서비스가 해결할 수있는 개별 문제로 구분하는 데 도움이되는 이론적 접근 방식입니다. 이 과정에서, 마이크로 소프트의 블로그 게시물의 조명 시리즈에 설명, 당신이 당신의 비즈니스 도메인의 추상적 인 모델을 만들고, 그 과정에서 경계 상황을 발견 , 어떤 그룹 함께이 기능이 특정의 방식으로 세계와 상호 작용합니다.

예를 들어 배송에 대한 하나의 제한된 컨텍스트와 계정에 대한 다른 컨텍스트가있을 수 있습니다. 물론 실제 물리적 객체는 가격과 이동해야하는 장소를 모두 가질 수 있지만 경계가있는 컨텍스트는 애플리케이션이 해당 객체에 대해 생각하고 상호 작용하는 특정 방식을 나타냅니다. 일부 제한된 컨텍스트는 둘 이상의 마이크로 서비스를 포함 할 수 있지만 각 마이크로 서비스는 완전히 단일 경계 컨텍스트 내에 존재해야합니다.

마이크로 서비스 대 서비스 지향 아키텍처 대 웹 서비스

이 시점에서 한동안 업계에 종사해 온 IT 전문가라면이 중 상당수가 익숙하다고 생각할 수 있습니다. 작은 개별 프로그램이 함께 작동한다는 아이디어는 SOA (서비스 지향 아키텍처)와 웹 서비스 , 2000 년대 웹 2.0 시대의 두 가지 유행어를 떠올리게 할 수 있습니다 . 어떤 의미에서 진정으로 새로운 것은 없지만 이러한 개념과 마이크로 서비스 사이에는 중요한 차이가 있습니다. Datamation은 차이점을 잘 분석했지만 다음은 짧은 버전입니다.

  • 서비스 지향 아키텍처에서 개별 구성 요소는 상대적으로 밀접하게 결합되어 있으며 종종 스토리지와 같은 자산을 공유하며 엔터프라이즈 스토리지 버스라는 특수 소프트웨어를 통해 통신 합니다. 마이크로 서비스는 더 독립적이고 더 적은 리소스를 공유하며 더 가벼운 프로토콜을 통해 통신합니다. 마이크로 서비스는 SOA 환경에서 발생했으며 때때로 일종의 SOA 또는 개념의 후속으로 간주된다는 점은 주목할 가치가 있습니다.
  • 웹 서비스는 다른 응용 프로그램이 웹을 통해 액세스 할 수있는 공개적인 기능 집합입니다. 가장 널리 사용되는 예는 레스토랑의 웹 사이트에 삽입하여 고객에게 길 찾기를 제공 할 수있는 Google지도입니다. 이것은 마이크로 서비스 아키텍처에서 볼 수있는 것보다 훨씬 느슨한 연결입니다.

마이크로 서비스 통신

마이크로 서비스 아키텍처에 대해 자주들을 수있는 캐치 프레이즈는 "스마트 엔드 포인트 및 덤 파이프"를 특징으로해야한다는 것입니다. 즉, 마이크로 서비스는 복잡하고 긴밀한 통합보다는 기본적이고 잘 확립 된 통신 방법을 사용하는 것을 목표로해야합니다. 언급했듯이 이것은 마이크로 서비스와 SOA를 구별하는 또 다른 요소입니다.

일반적으로, microservices 사이의 통신은 비동기해야한다 , 코드 스레드가 응답을 기다리고 차단되지 의미에서. (AMQP (Advanced Message Queuing Protocol)와 같은 비동기 프로토콜도 마이크로 서비스 아키텍처에서 일반적이지만 HTTP와 같은 동기식 통신 프로토콜을 사용하는 것은 여전히 ​​괜찮습니다.) 이러한 종류의 느슨한 결합은 실패시 마이크로 서비스 아키텍처를보다 유연하게 만듭니다. 네트워크의 개별 구성 요소 또는 일부의 주요 이점입니다.

마이크로 서비스, Java, Spring Boot 및 Spring Cloud

마이크로 서비스의 첫 번째 작업 중 일부는 Java 커뮤니티에서 발생했습니다. Martin Fowler는 초기 지지자였습니다. 폴란드에서 개최 된 2012 년 Java 컨퍼런스에서는 "마이크로 서비스-Java, Unix 방식"이라는 주제에 대한 가장 중요한 초기 프레젠테이션 중 하나를 선보였습니다. 1970 년대 최초의 Unix 애플리케이션 개발을 이끈 원칙을 적용 할 것을 권장했습니다 ( "Write 한 가지 일을 잘하는 프로그램. 함께 작동하는 프로그램을 작성하라.”) 자바 개발에.

이 역사의 결과로 마이크로 서비스를 구축 할 수있는 많은 Java 프레임 워크가 있습니다. 가장 인기있는 것 중 하나는 마이크로 서비스를 위해 특별히 설계된 Spring Boot입니다. Boot는 Spring Cloud에 의해 확장되며, 이름에서 알 수 있듯이 이러한 서비스를 클라우드에 배포 할 수도 있습니다. Spring의 개발자 인 Pivotal Software는 이러한 프레임 워크를 사용하여 마이크로 서비스 개발을 시작하는 방법에 대한 좋은 자습서를 가지고 있습니다.

마이크로 서비스 및 컨테이너 : Docker, Kubernetes 등

마이크로 서비스를 주류로 끌어들이는 데 가장 멀리 떨어진 기본 기술은 컨테이너 입니다.  컨테이너는 VM 인스턴스와 유사하지만 전체 자체 포함 OS를 포함하는 대신 호스트 운영체제의 커널을 사용하지만 코드가 자체 포함 된 내부에서 실행되도록 유지하는 격리 된 사용자 공간입니다. 컨테이너는 VM 인스턴스보다 훨씬 작으며 로컬 또는 클라우드에서 신속하게 배포 할 수 있으며 수요 및 사용 가능한 리소스에 맞게 회전 또는 축소 할 수 있습니다.

마이크로 서비스에 대한 컨테이너의 매력은 분명해야합니다. 각 개별 마이크로 서비스는 자체 컨테이너에서 실행될 수 있으므로 서비스 관리의 오버 헤드를 크게 줄일 수 있습니다. 대부분의 컨테이너 구현에는 컨테이너 기반 애플리케이션의 배포, 관리, 확장, 네트워킹 및 가용성을 자동화하는 보완 오케스트레이션 도구가 있습니다. DevOps 철학을 가능하게하는 것은 작고 빌드하기 쉬운 마이크로 서비스와 배포하기 쉬운 컨테이너의 조합입니다. 컨테이너 개념의 여러 구현이 있지만 가장 인기있는 것은 Docker이며 일반적으로 오케스트레이션 플랫폼으로 Kubernetes와 쌍을 이룹니다.

Spring은 인기가 있지만 Java 플랫폼과 연결되어 있습니다. 반면 컨테이너 기반 시스템은 다국어입니다. OS가 지원하는 모든 프로그래밍 언어는 컨테이너에서 실행될 수 있으므로 프로그래머에게 더 많은 유연성을 제공합니다. 실제로 마이크로 서비스의 큰 장점은 각 개별 서비스를 가장 의미가 있거나 개발자가 가장 편한 언어로 작성할 수 있다는 것입니다. 실제로 서비스는 API가 안정적으로 유지되는 한 시스템 전체에 영향을주지 않고 새로운 언어로 완전히 재 구축 될 수 있습니다. DZone에는 마이크로 서비스를위한 Spring Cloud와 Kubernetes의 장단점을 논의하는 기사가 있습니다. 

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

마이크로 서비스를 개발하는 데 어떤 언어를 사용하든 다른 개발자가 이전에 겪은 문제에 직면하게됩니다. 디자인 패턴은 컴퓨터 과학에서 반복되는 문제에 대한 공식화되고 추상적 인 솔루션이며, 그중 다수는 특별히 마이크로 서비스를위한 것입니다. Devopedia에는 ​​다음과 같은 훌륭한 목록이 있습니다.

  • Service Registry : 클라이언트를 사용 가능한 마이크로 서비스 인스턴스에 연결
  • 회로 차단기 : 실패한 서비스가 반복적으로 호출되는 것을 방지합니다.
  • 폴백 : 실패한 서비스에 대한 대안 제공
  • 사이드카 : 로깅, 서비스 동기화 또는 모니터링과 같은 보조 서비스를 기본 컨테이너에 제공합니다.
  • 어댑터 : 기본 컨테이너와 외부 세계 간의 인터페이스를 표준화 또는 정규화합니다.
  • Ambassador : 로컬 호스트 연결을 외부 연결로 프록시하는 것과 같이 주 컨테이너를 외부 세계에 연결합니다.

마이크로 서비스와 클라우드 : AWS와 Azure

위에서 언급했듯이 컨테이너 사용의 장점 중 하나는 유연한 컴퓨팅 리소스를 사용할 수있는 클라우드에 쉽게 배포 할 수있어 애플리케이션의 효율성을 극대화 할 수 있다는 것입니다. 상상할 수 있듯이 주요 퍼블릭 클라우드 공급 업체는 모두 해당 플랫폼을 사용하여 마이크로 서비스 기반 앱을 실행하기를 원합니다. 자세한 내용은 Amazon, Microsoft 및 Google의 리소스를 확인하십시오.