마이크로 서비스

Microservices

SOA(서비스 지향 아키텍처) 구조 스타일의 변형인 마이크로 서비스 아키텍처는 느슨하게 결합된 서비스의 집합으로 애플리케이션을 정렬합니다.마이크로 서비스 아키텍처에서는 서비스가 세분화되고 프로토콜이 경량화됩니다.목표는 팀이 다른 팀으로부터 독립적으로 서비스를 제공할 수 있도록 하는 것입니다.서비스 개발자는 서비스 사용자에 대해 신경 쓸 필요가 없기 때문에 서비스 [1][clarification needed]개발자는 서비스 사용자에게 변경을 강요하지 않기 때문에 느슨한 결합을 통해 모든 유형의 의존관계와 그 주변의 복잡성을 줄일 수 있습니다.따라서 소프트웨어를 개발하는 조직은 소프트웨어를 빠르게 확장할 수 있을 뿐만 아니라 기성 서비스를 더욱 쉽게 사용할 수 있습니다.통신 요건이 감소합니다.이러한 이익은 디커플링을 유지하는 데 비용이 듭니다.인터페이스는 신중하게 설계하여 퍼블릭 API로 취급해야 합니다.사용되는 기술 중 하나는 코드의 기존 사용자를 방해하지 않도록 동일한 서비스 상에 여러 개의 인터페이스를 배치하거나 동일한 서비스의 여러 버전을 배치하는 것입니다.

서론

마이크로 서비스에 대한 단일 정의는 없습니다.업계의 컨센서스 뷰는 시간이 지남에 따라 발전해 왔습니다.자주 인용되는 정의적 특성에는 다음과 같은 것이 있습니다.

  • 마이크로 서비스 아키텍처의 서비스는 HTTP와 [2][3][4]같은 기술에 구애받지 않는 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스인 경우가 많습니다.
  • 서비스는 비즈니스 [5]기능을 중심으로 구성되어 있습니다.
  • 서비스는 [6]가장 적합한 프로그래밍 언어, 데이터베이스, 하드웨어 및 소프트웨어 환경을 사용하여 구현할 수 있습니다.
  • 서비스는 크기가 작고 메시징이 가능하며 컨텍스트에 따라 제한되며 자율적으로 개발되며 독립적으로 도입 [7][6]가능하며 분산되며 자동화된 프로세스를 [7]통해 구축 및 출시됩니다.

마이크로 서비스는 단일 애플리케이션(예: 웹 컨트롤러 또는 백엔드-프런트 엔드)[8] 내의 레이어가 아닙니다.오히려 명확한 인터페이스를 갖춘 자체 비즈니스 기능이며, 자체 내부 구성요소를 통해 계층형 아키텍처를 구현할 수 있습니다.전략적 관점에서 보면 마이크로 서비스 아키텍처는 기본적으로 "한 가지 일을 잘하라"[9]는 Unix의 철학을 따릅니다.Martin Fowler는 마이크로 서비스 기반 아키텍처를 다음과 같은 [2]속성을 가진 것으로 설명합니다.

  • 지속적인 전송 소프트웨어 개발 프로세스에 적합합니다.애플리케이션의 일부를 변경하는 경우, 1개 또는 소수의 [10]서비스만 재구축 및 재배포하면 됩니다.
  • 세분화된 인터페이스(독립적으로 도입 가능한 서비스), 비즈니스 중심 개발(예: 도메인 중심 설계)[11] 등의 원칙을 준수합니다.

마이크로 서비스 아키텍처는 클라우드 네이티브 애플리케이션, 서버리스 컴퓨팅 및 경량 컨테이너 배치를 사용하는 애플리케이션에 채택되는 것이 일반적입니다.Fowler에 따르면 (단일화된 애플리케이션 구현에 비해) 서비스의 수가 많기 때문에 이러한 [12]애플리케이션을 효과적으로 개발, 유지 및 운용하기 위해서는 분산형 연속 전달 및 전체적인 서비스 모니터링 기능을 갖춘 DevOps가 필요합니다.이 접근방식을 따른 결과(및 그 근거)는 개별 마이크로 서비스를 개별적으로 확장할 수 있다는 것입니다.일원적 접근법에서는 이들 기능 중 하나만 리소스 [13]제약이 있더라도 3가지 기능을 지원하는 애플리케이션을 전체적으로 확장해야 합니다.마이크로 서비스에서는 리소스 제약이 있는 기능을 지원하는 마이크로 서비스만 스케일아웃하면 되므로 리소스 및 비용 최적화 [14]이점을 얻을 수 있습니다.

역사

마이크로 서비스라는 용어의 기원에 대해서는 수많은 주장이 있다.2004년 ThinkWorks 부사장으로 재직하면서 Fred George는 Jeff [15]Bay의 이름을 딴 "Baysean Principle"이라고 불리는 것에 기초한 프로토타입 건축에 종사하기 시작했습니다.

2005년 초에 Peter Rodgers는 Web Services Edge 컨퍼런스의 프레젠테이션에서 "Micro-Web-Services"라는 용어를 도입했습니다.기존의 사고와 SOAP SOA 아키텍처의 과대 광고 곡선의 정점에 있는 그는 "REST-services"를 주장했고 컨퍼런스 프레젠테이션의 슬라이드 #4에서는 "소프트웨어 구성요소는 마이크로 웹 서비스"[16]에 대해 논의했습니다.그는 이어 "마이크로 서비스는 Unix와 유사한 파이프라인을 사용하여 구성됩니다(Web은 Unix = 진정한 loose-diag).서비스는 서비스를 호출할 수 있습니다(+복수 언어 런타임).복잡한 서비스 어셈블리는 단순한 URI 인터페이스 뒤에 추상화됩니다.어떤 서비스든 세부적으로 노출될 수 있습니다."그는 잘 설계된 마이크로 서비스 플랫폼이 Unix와 같은 스케줄링 및 파이프라인과 함께 웹 및 REST 서비스의 기본 아키텍처 원칙을 적용하여 서비스 지향 [17]아키텍처에서 근본적인 유연성과 향상된 단순성을 제공하는 방법에 대해 설명했습니다.

Rodgers의 작업은 1999년 Hewlett Packard Labs의 Dexter 연구 프로젝트에서 시작되었습니다.이 프로젝트의 목적은 코드를 덜 취약하게 만들고 대규모로 복잡한 소프트웨어 시스템을 변화에 [18]견딜 수 있도록 하는 것이었습니다.궁극적으로 이러한 연구 경로는 REST가 특별한 서브셋인 일반화된 계산 추상화인 리소스 지향 컴퓨팅(ROC)의 개발로 이어졌습니다.

2007년, Juval Löwy는 집필과[19] 연설에서[20][21] 모든 클래스가 서비스인 시스템을 구축할 것을 요구했습니다.Löwy는 이를 위해 이러한 세분화된 서비스 사용을 지원할 수 있는 기술을 사용해야 한다는 것을 깨달았고, 이를 위해 Windows Communication Foundation(WCF)[22][23]을 확장하여 모든 클래스를 수강하고 기존의 클래스 프로그래밍 모델을 유지하면서 서비스로 취급했습니다.

2005년에 Alistair Cockburn은 마이크로 서비스와 함께 사용되는 소프트웨어 설계 패턴인 육각형 아키텍처(소프트웨어)에 대해 썼다.이 패턴은 마이크로 서비스를 다른 서비스와 완전히 독립적으로 배치 및 실행하는 데 필요한 보조 서비스와 비즈니스 로직을 계층별로 분리하기 때문에 마이크로 서비스 설계를 가능하게 합니다.

2011년 5월에 베니스 근교에서 개최된 소프트웨어 아키텍트 워크숍에서는, 「마이크로 서비스」라고 하는 용어를 사용해 참가자의 대부분이 최근 탐구해 [24]온 일반적인 건축 스타일을 설명했습니다.2012년 5월, 동그룹은 「마이크로 서비스」를 가장 적절한 명칭으로 결정했다.James Lewis는 2012년 3월 크라쿠프의 33학번 Microservices - Java, Unix [25]Way에서 Fred George와 같은 시기에[26] 이러한 아이디어의 일부를 사례 연구로 발표했습니다.Netflix의 [27]클라우드 시스템 담당 이사였던 Adrian Cockcroft는 이 접근 방식을 "세밀한 SOA"라고 표현했으며, 이 기사에서 언급한 다른 많은 사람들(Joe Walnes, Dan North, Evan Bottcher 및 Graham Tackley)[28]과 마찬가지로 웹 스케일에서 이 방식을 개척했습니다.

마이크로서비스는 유연하고 독립적으로 전개 가능한 소프트웨어 시스템을 [5]구축하는 데 사용되는 서비스 지향 아키텍처(SOA)의 구현 접근방식의 전문화입니다.마이크로 서비스 접근 방식은 DevOps 도입 이후 처음으로 SOA를 실현한 것으로, 지속적으로 배치된 [29]시스템을 구축하는 데 있어 점점 더 인기를 얻고 있습니다.

2020년 2월 Cloud Microservices Market Research Report는 전 세계 마이크로 서비스 아키텍처 시장 규모가 2019년부터 2026년까지 21.37%의 CAGR로 성장하고 2026년에는 [30]31억 달러에 이를 것으로 예측했습니다.

서비스의 세분화

마이크로 서비스 아키텍처를 정의하는 중요한 단계는 개별 마이크로 서비스의 규모를 파악하는 것입니다.이에 대한 합의나 테스트는 없습니다. 정답은 비즈니스 [31]및 조직 상황에 따라 다르기 때문입니다.예를 들어, Amazon은 서비스 지향 아키텍처를 사용합니다.이 아키텍처에서는 서비스가 3~10명의 [32]엔지니어 팀과 1:1로 매핑되는 경우가 많습니다.일반적으로 이 용어는 특정 백엔드 시스템을 호출하거나 특정 유형의 계산을 수행하는 등 단일 태스크 전용 서비스를 원자 서비스라고 부릅니다.마찬가지로 출력을 통합하기 위해 이러한 원자 서비스를 호출하는 서비스를 복합 서비스라고 합니다.

서비스를 너무 작게 하는 것은 잘못된 관행으로 간주됩니다.그러면 런타임 오버헤드와 운영 복잡성으로 인해 접근 방식의 이점을 압도할 수 있기 때문입니다.상황이 너무 세분화된 경우, 기능을 라이브러리로 패키징하거나 기능을 다른 마이크로 [5]서비스로 이동하는 등의 대체 접근법을 고려해야 합니다.

시스템이 구축되는 도메인을 모델링하기 위해 도메인 중심 설계를 사용하는 경우 마이크로 서비스는 Aggregate만큼 작거나 제한된 컨텍스트만큼 [33]커질 수 있습니다.

마이크로 서비스 논의의 세분화에는 스펙트럼이 있습니다.한쪽 끝에는 많은 책임이 없는 빈혈 서비스가 있고 다른 한쪽 끝에는 시스템의 큰 모듈인 모듈러 모노리스(Modular Monolith)가 있습니다.

혜택들

애플리케이션을 다른 소규모 서비스로 분해하는 이점은 다음과 같습니다.

  • 모듈러형:따라서 애플리케이션을 보다 쉽게 이해하고, 개발하고, 테스트하고, 아키텍처 [6]침식에 대한 복원력을 높일 수 있습니다.이러한 이점은 종종 단일 아키텍처의 [34]복잡성과 비교됩니다.
  • 확장성:마이크로 서비스는 서로 독립적으로 구현 및 배치되므로, 즉 독립 프로세스 내에서 실행되므로 독립적으로 [35]모니터링 및 확장할 수 있습니다.
  • 이기종 시스템과 레거시 시스템의 통합: 마이크로 서비스는 기존의 일원화된 소프트웨어 애플리케이션을 [36][37]현대화하기 위한 실행 가능한 수단으로 간주되고 있습니다.기존 소프트웨어를 마이크로 서비스로 성공적으로 교체했거나 [38]현재 교체 중인 여러 회사의 경험 보고서가 있습니다.레거시 애플리케이션의 소프트웨어 현대화 프로세스는 증분 [39]접근방식을 사용하여 수행됩니다.
  • 분산 개발: 소규모 자율 팀이 각각의 서비스를 독립적으로 [40]개발, 도입 및 확장할 수 있도록 함으로써 개발을 병행합니다.또한 지속적인 리팩터링을 [41]통해 개별 서비스의 아키텍처가 등장할 수 있습니다.마이크로 서비스 기반 아키텍처는 지속적인 통합, 지속적인 제공 및 [42]도입을 지원합니다.

비판과 우려

마이크로 서비스 접근법은 다음과 같은 여러 가지 문제로 인해 비판을 받을 수 있습니다.

  • 서비스는 정보 [43]장벽을 형성합니다.
  • 네트워크를 통한 서비스 간 콜은 단일 서비스 [2]프로세스 내의 처리 중인 콜보다 네트워크 지연 및 메시지 처리 시간 측면에서 비용이 높습니다.
  • 테스트와 도입은 더 [44][45]복잡합니다.
  • 서비스 간에 책임을 옮기는 것은 더 어렵습니다.[6]여기에는 다른 팀 간의 커뮤니케이션, 다른 언어로 기능 재작성 또는 다른 인프라스트럭처에 [2]적응하는 작업이 수반될 수 있습니다.다만, 마이크로 서비스는 애플리케이션의 나머지 부분과는 독립적으로 도입할 수 있습니다만, 모노리스에 임하고 있는 팀은 함께 [39]도입하기 위해서 동기화할 필요가 있습니다.
  • 서비스 크기를 주요 구조화 메커니즘으로 간주하면 내부 모듈화의 대안이 더 단순한 [46]설계로 이어질 수 있는 경우 너무 많은 서비스가 발생할 수 있습니다.이를 위해서는 애플리케이션의 전체적인 아키텍처와 [47]컴포넌트 간의 상호의존성을 이해해야 합니다.
  • 2단계 커밋은 마이크로 서비스 기반 아키텍처에서 안티 패턴으로 간주됩니다.이것에 의해, 트랜잭션내의 모든 참가자가 보다 밀접하게 결합됩니다.그러나 이 기술이 부족하기 때문에 데이터의 [48]일관성을 유지하기 위해 모든 거래 참가자가 수행해야 하는 어색한 춤이 발생합니다.
  • 다양한 툴과 테크놀로지를 사용하여 구축되어 있는 경우, 많은 서비스의 개발과 지원은 더욱 어려워집니다.특히 엔지니어가 프로젝트 [49]간에 빈번하게 이동하는 경우에는 더욱 문제가 됩니다.
  • 일반적으로 마이크로 서비스(HTTP)와 함께 사용되는 프로토콜은 공공 서비스용으로 설계되었으며, 따라서 종종 흠잡을 데 없이 [50]신뢰성이 있어야 하는 내부 마이크로 서비스에는 적합하지 않습니다.
  • 분해 방법론에서는 마이크로서비스에 고유하지 않지만 기능 분해를 사용하는 경우가 많습니다.이 방법론에서는 서비스의 [50]복잡성이 증가하면서도 요구사항의 변경은 처리하지 않습니다.
  • 서비스만 있기 때문에 마이크로 서비스의 개념 자체가 오해를 불러일으킬 수 있습니다.서비스가 마이크로 [50]서비스가 언제 시작되거나 중지되는지에 대한 건전한 정의는 없습니다.
  • 데이터 집약동작하는 시스템의 전체 뷰를 확보하려면 마이크로 서비스 저장소에서 데이터 세트를 추출하여 단일 스키마로 집약해야 합니다.예를 들어 단일 마이크로 서비스 저장소를 사용하여 불가능한 운영 보고서를 생성할 수 있습니다.

인지 부하

이 아키텍처에서는 네트워크 레이텐시, 메시지 형식 설계,[51] 백업/Availability/Consistency(BAC),[52] 로드밸런싱 및 [45]폴트 톨러런스 등의 복잡성과 대처해야 할 새로운 문제가 발생합니다.이 모든 문제들은 규모에 맞게 다루어져야 한다.일원화된 애플리케이션을 마이크로 서비스 세트로 재실장해도 복잡성은 사라지지 않습니다.복잡성의 일부는 운용의 [53]복잡성으로 변환됩니다.그 외의 복잡성 자체는 네트워크트래픽의 증가와 퍼포먼스의 저하로 나타납니다.또한 임의의 수의 마이크로 서비스로 구성된 애플리케이션은 각각의 에코시스템에 액세스하기 위한 다수의 인터페이스 포인트를 가지므로 아키텍처의 [54]복잡성이 증가합니다.이러한 추가 복잡성의 영향을 줄이기 위해 다양한 구성 원칙(HATEOAS, Swagger를 통해 캡처한 인터페이스 및 데이터 모델 문서 등)이 적용되었습니다.

테크놀로지

컴퓨터 마이크로 서비스는 다른 프로그래밍 언어로 구현될 수 있으며 다른 인프라를 사용할 수 있습니다.따라서 가장 중요한 테크놀로지는 마이크로 서비스가 서로 통신하는 방식(동기식, 비동기식, UI 통합)과 통신에 사용되는 프로토콜(RESTFUL HTTP, 메시징, GraphQL 등)입니다.전통적인 시스템에서는 프로그래밍 언어와 같은 대부분의 기술 선택은 시스템 전체에 영향을 미칩니다.따라서 기술을 선택하는 방법은 상당히 다릅니다.[55]

Eclipse Foundation은 마이크로 서비스 개발 사양인 Eclipse [56][57]MicroProfile을 발표했습니다.

서비스 메쉬

다음 항목도 참조하십시오.서비스 메쉬

서비스 메쉬에서 각 서비스인스턴스는 서비스 프록시, 사이드카 프록시 또는 사이드카라고 불리는 리버스 프록시 서버의 인스턴스와 쌍을 이룹니다.서비스 인스턴스와 사이드카 프록시는 컨테이너를 공유하며 컨테이너는 Kubernetes, Nomad, Docker Swarm 또는 DC/OS와 같은 컨테이너 조정 도구로 관리됩니다.서비스 프록시는 다른 서비스인스턴스와의 통신을 담당하며 서비스(인스턴스) 디스커버리, 로드밸런싱, 인증 및 인가, 안전한 통신 등의 기능을 지원할 수 있습니다.

서비스 메쉬에서 서비스인스턴스와 그 사이드카 프록시는 데이터 관리뿐만 아니라 요구 처리 및 응답을 포함하는 데이터 플레인을 구성하는 것으로 알려져 있다.서비스 메쉬에는 사이드카 [citation needed]프록시에 의해 매개되는 서비스 간의 상호작용을 관리하기 위한 제어 플레인도 포함됩니다.

플랫폼 비교

마이크로 서비스 아키텍처를 구현하는 것은 매우 어렵습니다.마이크로 서비스 아키텍처에서 해결해야 할 많은 우려 사항(아래 표 참조)이 있습니다.Netflix는 내부 애플리케이션을 지원하는 마이크로 서비스 프레임워크를 개발하여 그 프레임워크의 많은 부분을 오픈[58] 소싱했습니다.이러한 툴의 대부분은 Spring Framework를 통해 보급되어 Spring[59] Cloud 프로젝트의 산하에 Spring 기반 툴로 재실장되었습니다.아래 표는 Kubernetes 생태계의 구현 기능과 Spring Cloud [60]환경의 구현 기능을 비교한 것입니다.Spring Cloud 생태계에서 주목할 점은 Kubernetes가 폴리글로트 런타임 플랫폼인 반면 모두 Java 기반 기술이라는 것입니다.

마이크로 서비스 관련 문제 봄 클라우드 및 Netflix OSS 쿠베르네테스
구성 관리: 마이크로 서비스 애플리케이션 설정은 코드에서 외부화되어 단순한 서비스 호출을 통해 검색할 수 있어야 합니다. Spring Config Server, Netflix Archaius 모두 Git 저장소 기반 구성 위치를 지원합니다.Archaius는 구성의 데이터 입력을 지원합니다. Kubernetes ConfigMaps는 etcd에 저장된 설정을 서비스를 통해 공개합니다.Kubernetes Secrets는 기밀 설정 정보(패스워드, 증명서 등)의 서비스 기반의 안전한 도입 및 사용을 지원합니다.
서비스 디스커버리: 마이크로 서비스 도메인 내에서 작업할 수 있는 서비스인스턴스 목록을 유지합니다. Spring Cloud Eureka를 통해 클라이언트는 등록하고 등록된 클라이언트와의 하트비트를 유지하며 서비스 이름을 서비스 이름으로 조회하는 클라이언트의 호스트 이름에 매핑할 수 있습니다. Kubernetes Services는 클러스터 내에서 내부적으로 사용 가능한 서비스 인스턴스의 배포 시간 등록을 제공합니다.입력은 서비스가 클러스터 외부의 클라이언트에 노출될 수 있는 메커니즘입니다.
로드 밸런싱:분산 시스템을 확장하기 위해서는 컴포넌트의 여러 인스턴스를 실행할 수 있어야 합니다.그런 다음 로드 밸런서를 통해 이러한 인스턴스 간에 부하를 분산해야 합니다. Spring Cloud Ribbon은 서비스 클라이언트가 서비스 인스턴스 간에 로드 밸런싱을 수행할 수 있는 기능을 제공합니다. Kubernetes 서비스는 서비스 인스턴스 간에 서비스를 로드밸런싱할 수 있는 기능을 제공합니다.이것은 리본이 제공하는 것과 동등하지 않습니다.
API 게이트웨이:마이크로서비스가 제공하는 API의 세밀도는 서비스 클라이언트에 필요한 것과 다른 경우가 많습니다.API 게이트웨이는 패드를 구현하고 프록시, 프로토콜 변환 및 기타 관리 기능과 같은 추가 서비스를 제공합니다. Spring Cloud Zuul은 구성 기반 API 패시드를 제공합니다. Kubernetes Service 및 Ingress 리소스, Istio, Ambassador는 동서(데이터 센터 또는 클라우드 또는 지역 간 트래픽) API 게이트웨이 기능을 모두 제공하는 솔루션입니다.Zuul은 Kubernetes와 함께 구현할 수도 있으며 개별 서비스 수준에서 구성을 제공합니다.
보안상의 우려 사항:많은 보안 문제가 API 게이트웨이의 구현에 밀려 있습니다.분산형 마이크로 서비스 애플리케이션에서는 보안 휠을 재창조하지 않고 모든 서비스가 공유하는 컴포넌트에서 정책을 정의하고 구현할 수 있도록 하는 것이 좋습니다. Spring Cloud Security는 Spring Cloud Zuul을 통해 많은 보안 문제를 해결합니다. Kubernetes 생태계는 Istio와 같은 서비스 메쉬를 제공하며, 이는 API 게이트웨이 메커니즘을 통해 보안을 제공할 수 있습니다.
중앙 집중식 로깅:로그 수집 및 분석 인프라스트럭처를 일원화하여 대량의 서비스를 관리하는 것이 중요합니다.이러한 서비스의 대부분은 분산 운용되고 있습니다. ELK 스택(Elastic Search, LogStash, Kibana) EFK 스택(Elasticsearch, Fluentd, Kibana)
일원화된 지표:개별 서비스 및 시스템 전체의 상태와 퍼포먼스를 감시할 수 있는 일원화된 영역은 적절한 운용에 불가결합니다. Spring Spector & Atlas 히프스터, 프로메테우스, 그라파나
분산 트레이스: 프로세스별 로깅과 메트릭 감시는 적절하지만 트랜잭션이 분산 시스템에 전파될 때 통과하는 복잡한 경로를 재구성할 수 없습니다.분산 트레이스는 마이크로 서비스 플랫폼에 필수적인 도구입니다. 봄구름 진눈깨비 호쿨라, 예거
내장해성과 폴트 톨러런스:분산형 시스템은 장애를 회피하는 자동 라우팅이 가능하고 최적의 응답을 제공하는 서비스 인스턴스에 요청을 라우팅할 수 있어야 합니다. 스프링 히스트릭스, 터빈 및 리본 헬스 체크, 서비스 메시(예:ISTIO)[61]
자동 측정 및 자가 복구:분산형 시스템은 수평으로 확장하여 높은 부하에 대응합니다.플랫폼은 이러한 조건을 검출하여 자동으로 대응해야 합니다.게다가 시스템은 장애를 검출해, 오퍼레이터의 입력 없이 자동 재기동을 시도할 필요가 있습니다. - 헬스 체크, 셀프 힐링 및 자동 스케일링
패키징, 도입 및 스케줄링: 대규모 시스템에서는 견고한 패키지 관리가 필요합니다.또, 롤백 또는 청록색의 도입을 관리하기 위한 도입 시스템, 및 필요에 따라서 롤백을 관리할 필요가 있습니다.스케줄러는 현재 상황에 따라 새로운 서비스 세트를 도입할 수 있는 특정 실행 노드를 결정하는 데 도움이 됩니다. 스프링 부츠, 아파치 메이븐Spring Cloud 시스템에는 진정한 스케줄러가 없습니다. 도커, Rkt, Kubernetes 스케줄러 및 도입, 헬름[62]
작업 관리: 스케줄된 계산과 개별 사용자 요청의 연결이 끊어졌습니다. 스프링 배치 Kubernetes 작업과 스케줄링된 작업
싱글톤 어플리케이션: 특정 서비스가 시스템 전체에서 해당 서비스의 유일한 인스턴스로 실행되도록 제한합니다. 스프링 클라우드 클러스터 쿠베르네테스 포드

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Microservice architectures: more than the sum of their parts?". IONOS Digitalguide. Retrieved 2022-03-29.
  2. ^ a b c d Martin Fowler. "Microservices". Archived from the original on 14 February 2018.
  3. ^ Newman, Sam (2015-02-20). Building Microservices. O'Reilly Media. ISBN 978-1491950357.
  4. ^ Wolff, Eberhard (2016-10-12). Microservices: Flexible Software Architectures. ISBN 978-0134602417.
  5. ^ a b c Pautasso, Cesare (2017). "Microservices in Practice, Part 1: Reality Check and Service Design". IEEE Software. 34 (1): 91–98. doi:10.1109/MS.2017.24. S2CID 5635705.
  6. ^ a b c d Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  7. ^ a b Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture:원칙, 관행 및 문화 조정, O'Reilly 2016
  8. ^ "Backends For Frontends Pattern". Microsoft Azure Cloud Design Patterns. Microsoft.
  9. ^ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
  10. ^ 마이크로 서비스 설계: 지속적인 통합 Microsoft Retrieved 2018년 1월 9일
  11. ^ 조수티스, 노스캐롤라이나 (2007년SOA를 도입하고 있습니다.세바스토폴, 캘리포니아, 미국: 오라일리.ISBN 978-0-596-52955-0.
  12. ^ Martin Fowler. "Microservice Prerequisites".
  13. ^ Richardson, Chris (November 2018). "1.4.1 Scale cube and microservices". Microservice Patterns. Manning Publications. ISBN 9781617294549.
  14. ^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). "Developing Self-Adaptive Microservice Systems: Challenges and Directions". IEEE Software. 38 (2): 70–79. arXiv:1910.07660. doi:10.1109/MS.2019.2955937. S2CID 204744007.
  15. ^ "That Tech Show: The Grandfather of Microservices, Fred George".
  16. ^ Rodgers, Peter. "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity Web Services Edge 2005 East: CS-3". CloudComputingExpo 2005. SYS-CON TV. Archived from the original on 20 May 2018. Retrieved 3 July 2017.
  17. ^ Rodgers, Peter. "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity". CloudComputingExpo. SYS-CON Media. Archived from the original on 20 May 2018. Retrieved 19 August 2015.
  18. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architecture and Design of an XML Application Platform". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  19. ^ Löwy, Juval (2007). Programming WCF Services, 1st ed. O’Reilly Media. pp. 543–553. ISBN 978-0-596-52699-3.
  20. ^ Juval Löwy "모든 클래스 a WCF 서비스" (채널 9, ARCast).TV, 2007년 10월.
  21. ^ Juval Löwy "서비스로서의 모든 클래스"(Microsoft TechEd Conference, 2009년 5월), SOA206. 2010년 원본에서 아카이브.
  22. ^ Löwy, Juval (2007). Programming WCF Services, 1st ed. O’Reilly Media. pp. 48–51. ISBN 978-0-596-52699-3.
  23. ^ Löwy, Juval (2010). Programming WCF Services, 3rd ed. O’Reilly Media. pp. 74–75. ISBN 978-0-596-80548-7.
  24. ^ Dragoni, Nicola; Giallorenzo, Saverio; Lafuente, Alberto Lluch; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: yesterday, today, and tomorrow". Present and Ulterior Software Engineering: 195–216. arXiv:1606.04036. doi:10.1007/978-3-319-67425-4_12. ISBN 978-3-319-67424-7. S2CID 14612986.
  25. ^ James Lewis. "Micro services - Java, the Unix Way".
  26. ^ Fred George (2013-03-20). "MicroService Architecture: A Personal Journey of Discovery".
  27. ^ Farrow, Rik (2012). "Netflix heads into the clouds" (PDF).
  28. ^ James Lewis and Martin Fowler. "Microservices".
  29. ^ "Continuous Deployment: Strategies". javacodegeeks.com. 10 December 2014. Retrieved 28 December 2016.
  30. ^ Research, Verified Market. "Cloud Microservices Market 2020 Trends, Market Share, Industry Size, Opportunities, Analysis and Forecast by 2026 – Instant Tech Market News". Retrieved 2020-02-18.
  31. ^ O. Zimmerman, Microservice API 패턴을 사용한 도메인별 서비스 분해, Microservices 2019, https://ww.conf-micro.services/2019/slides/keynotes/Zimmerman.pdf
  32. ^ "Amazon SOA mandate". 13 October 2011.
  33. ^ Vaughn, Vernon (2016). Domain-Driven Design Distilled. Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  34. ^ Yousif, Mazin (2016). "Microservices". IEEE Cloud Computing. 3 (5): 4–5. doi:10.1109/MCC.2016.101.
  35. ^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: How to make your application scale" (PDF). International Andrei Ershov Memorial Conference on Perspectives of System Informatics. Lecture Notes in Computer Science. 10742: 95–104. arXiv:1702.07149. Bibcode:2017arXiv170207149D. doi:10.1007/978-3-319-74313-4_8. ISBN 978-3-319-74312-7. S2CID 1643730.
  36. ^ Newman, Sam (2015). Building Microservices. O'Reilly. ISBN 978-1491950357.
  37. ^ Wolff, Eberhard (2016). Microservices: Flexible Software Architecture. Addison Wesley. ISBN 978-0134602417.
  38. ^ Knoche, Holger; Hasselbring, Wilhelm (2019). "Drivers and Barriers for Microservice Adoption – A Survey among Professionals in Germany". Enterprise Modelling and Information Systems Architectures. 14: 1:1–35–1:1–35. doi:10.18417/emisa.14.1.
  39. ^ a b Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). "Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages". Proceedings of the XP2017 Scientific Workshops. doi:10.1145/3120459.3120483. S2CID 28134110.
  40. ^ Richardson, Chris. "Microservice architecture pattern". microservices.io. Retrieved 2017-03-19.
  41. ^ Chen, Lianping; Ali Babar, Muhammad (2014). "Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development". Proceedings Working IEEE/IFIP Conference on Software Architecture 2014 WICSA 2014. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45.
  42. ^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (May 2016). "Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture" (PDF). IEEE Software. 33 (3): 42–52. doi:10.1109/ms.2016.64. hdl:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  43. ^ Stenberg, Jan (11 August 2014). "Experiences from Failing with Microservices".
  44. ^ Calandra, Mariano (7 April 2021). "Why unit testing is not enough when it comes to microservices".
  45. ^ a b "Developing Microservices for PaaS with Spring and Cloud Foundry".
  46. ^ Tilkov, Stefan (17 November 2014). "How small should your microservice be?". Innoq. Retrieved 4 January 2017.
  47. ^ Lanza, Michele; Ducasse, Stéphane (2002). "Understanding Software Evolution using a Combination of Software Visualization and Software Metrics" (PDF). In Proceedings of LMO 2002 (Langages et Modèles à Objets): 135–149.
  48. ^ Richardson, Chris (November 2018). Microservice Patterns. Chapter 4. Managing transactions with sagas: Manning Publications. ISBN 978-1-61729454-9.{{cite book}}: CS1 유지보수: 위치(링크)
  49. ^ "- YouTube". YouTube.
  50. ^ a b c Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  51. ^ Pautasso, Cesare (2017). "Microservices in Practice, Part 2: Service Integration and Sustainability". IEEE Software. 34 (2): 97–104. doi:10.1109/MS.2017.56. S2CID 30256045.
  52. ^ Pautasso, Cesare (2018). "Consistent Disaster Recovery for Microservices: the BAC Theorem". IEEE Cloud Computing. 5 (1): 49–59. doi:10.1109/MCC.2018.011791714. S2CID 4560021.
  53. ^ Fowler, Martin. "Microservice Trade-Offs".
  54. ^ "BRASS 건축 자원 적응 소프트웨어 시스템".미국 정부.DARPA는. 4월 7일 2015년."접근에 대한 시스템 요소이고 인터페이스 사이에 고객들과 그들의 응용 프로그램, 하지만, 중재를 통해 번호의 종종 관련이 없는 메커니즘을 포함한 비공식적으로 문서화된 응용 프로그래밍 인터페이스(API), 특이한 외국인 기능 인터페이스, 복잡한 ill-understood 모델 정의, 또는 특별 데이터 포맷.이러한 메커니즘은 보통 구성요소 자체의 의미론에 대한 부분적이고 불완전한 이해만을 제공합니다.이러한 복잡성이 존재하는 상황에서, 일반적으로 애플리케이션이 상호작용하는 생태계의 예상되는 동작에 대해 많은 가정을 수립하는 것은 놀라운 일이 아닙니다."
  55. ^ Wolff, Eberhard (2018-04-15). Microservices - A Practical Guide. ISBN 978-1717075901.
  56. ^ Swart, Stephanie (14 December 2016). "Eclipse MicroProfile". projects.eclipse.org.
  57. ^ "MicroProfile". MicroProfile. Retrieved 2021-04-11.{{cite web}}: CS1 maint :url-status (링크)
  58. ^ Netflix OSS, Git Hub
  59. ^ Cloud, Spring
  60. ^ "Spring Cloud for Microservices Compared to Kubernetes", Developers, Red hat, 2016-12-09
  61. ^ Managing microservices with the Istio service mesh, Kubernetes, May 2017
  62. ^ The Kubernetes Package Manager, Helm

추가 정보

  • 마이크로 서비스에 관한 특별 테마호, IEEE 소프트웨어 35(3), 2018년 5월/6월, https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8354413
  • I. Nadareishvili et al., Microservices Architecture – Alignment Principle, Practices and Culture, O'Reilly, 2016, ISBN 978-1-491-95979-4
  • S. Newman, Building Microservices – 미세 시스템 설계, O'Reilly, 2015 ISBN 978-1491950357
  • Wijesuriya, Viraj Brian(2016-08-29) 마이크로 서비스 아키텍처, 강의 노트 - 스리랑카 콜롬보 컴퓨터 대학
  • Christudas Binildas (2019년 6월 27일).실용적인 마이크로 서비스 아키텍처 패턴:Spring Boot 및 Spring Cloud를 갖춘 이벤트 기반 Java 마이크로 서비스.아프레스ISBN 978-1484245002.