마이크로 서비스 - Microservices

SOA ( Service-Oriented Architecture ) 구조 스타일 의 변형 인 마이크로 서비스 아키텍처 는 애플리케이션을 느슨하게 결합 된 서비스 모음으로 정렬 합니다. 마이크로 서비스 아키텍처에서 서비스는 세분화되고 프로토콜은 경량입니다.

소개

마이크로 서비스에 대한 단일 정의는 없습니다. 업계에서는 시간이 지남에 따라 합의 관점이 발전했습니다. 자주 인용되는 몇 가지 정의 특성은 다음과 같습니다.

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

  • 지속적 배포 소프트웨어 개발 프로세스에 자신을 맡깁니다 . 응용 프로그램의 작은 부분을 변경하려면 하나 또는 적은 수의 서비스 만 재 구축하고 재배포하면됩니다. [9]
  • 세분화 된 인터페이스 (독립적으로 배포 가능한 서비스에 대한), 비즈니스 중심 개발 (예 : 도메인 중심 설계 ) 과 같은 원칙을 준수 합니다. [10]

클라우드 네이티브 애플리케이션 , 서버리스 컴퓨팅 및 경량 컨테이너 배포를 사용하는 애플리케이션 에 마이크로 서비스 아키텍처를 채택하는 것이 일반적입니다 . Fowler에 따르면 서비스의 수가 많기 때문에 (모 놀리 식 애플리케이션 구현과 비교할 때) 이러한 애플리케이션을 효과적으로 개발, 유지 관리 및 운영하려면 분산 형 지속적 전달 및 전체적인 서비스 모니터링이 포함 된 DevOps 가 필요합니다. [11]이 접근 방식을 따르는 결과 (및 근거)는 개별 마이크로 서비스를 개별적으로 확장 할 수 있다는 것입니다. 모 놀리 식 접근 방식에서는 이러한 기능 중 하나에 만 리소스 제약이 있더라도 세 가지 기능을 지원하는 애플리케이션을 전체적으로 확장해야합니다. [12] microservices와 자원 제약 기능을 지원 만 microservice 따라서 자원 및 비용 최적화 이점을 제공 밖으로 확장 할 필요가있다. [13]

역사

2005 년 초에 Peter Rodgers 는 Web Services Edge 컨퍼런스에서 발표하는 동안 "마이크로 웹 서비스 " 라는 용어를 도입했습니다 . 그는 "REST-services"와 컨퍼런스 프레젠테이션의 슬라이드 # 4에서 " 소프트웨어 구성 요소 는 마이크로 웹 서비스" 라고 주장한 SOAP SOA 아키텍처의 과대 선전과 전통적인 사고에 반하여 " 소프트웨어 구성 요소 는 마이크로 웹 서비스"에 대해 논의 합니다. [14] 그는 계속해서 "마이크로 서비스는 Unix와 유사한 파이프 라인을 사용하여 구성됩니다 ( 웹은 Unix = 진정한 느슨한 결합을 만납니다 ). 서비스는 서비스를 호출 할 수 있습니다 (+ 다중 언어 런타임). 복잡한 서비스 어셈블리는 추상화됩니다. 간단한 URI 뒤에인터페이스. 모든 세분성에 상관없이 모든 서비스가 노출 될 수 있습니다. "그는 잘 설계된 마이크로 서비스 플랫폼이" 및 REST 서비스 의 기본 아키텍처 원칙을 Unix와 유사한 스케줄링 및 파이프 라인과 함께 적용하여 급진적 인 유연성과 서비스 단순성을 향상시키는 방법을 설명했습니다. 지향 아키텍처. [15]

Rodgers의 작업은 1999 년 Hewlett Packard Labs 의 Dexter 연구 프로젝트에서 시작되었습니다 . 그의 목표는 코드를 덜 깨뜨리고 대규모의 복잡한 소프트웨어 시스템을 강력 하게 변경하는 것이 었습니다. [16] 결국 개발되었다 연구의 경로 자원 지향 컴퓨팅 (ROC), 일반화 계산 추상화 된 REST 특수 서브 세트이다.

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

2011 년 5 월 베니스 근처에서 개최 된 소프트웨어 아키텍트 워크숍에서는 참가자들이 최근에 많은 사람들이 탐색 한 공통 아키텍처 스타일로 본 것을 설명하기 위해 "마이크로 서비스"라는 용어를 사용했습니다. [22] 2012 년 5 월 같은 그룹은 가장 적절한 이름으로 "마이크로 서비스"를 결정했습니다. James Lewis는 2012 년 3 월 Micro services의 Kraków에서 33rd Degree-Java, the Unix Way, [23] 에서 Fred George [24] 와 거의 같은시기 에 이러한 아이디어 중 일부를 사례 연구로 발표 했습니다 . Adrian Cockcroft , Netflix의 클라우드 시스템 전 이사, [25]Joe Walnes, Dan North, Evan Bottcher, Graham Tackley 등이 기사에서 언급 한 다른 많은 사람들과 마찬가지로이 접근 방식을 "미세한 SOA"라고 설명하고 웹 규모에서 스타일을 개척했습니다. [26]

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

2020 년 2 월 클라우드 마이크로 서비스 시장 조사 보고서는 글로벌 마이크로 서비스 아키텍처 시장 규모가 2019 년부터 2026 년까지 연평균 21.37 % 증가하고 2026 년에는 31 억 달러에이를 것이라고 예측했습니다. [28]

서비스 세분성

마이크로 서비스 아키텍처를 정의하는 주요 단계는 개별 마이크로 서비스의 크기를 파악하는 것입니다. 정답은 비즈니스 및 조직의 상황에 따라 다르기 때문에 이에 대한 합의 나 리트머스 테스트는 없습니다. [29] 예를 들어, 아마존은 고명 사용하는 서비스 지향 아키텍처 (1) 3 ~ 10 엔지니어의 팀 : 서비스가 종종 1 매핑합니다. [30]

서비스를 너무 작게 만드는 것은 나쁜 습관으로 간주됩니다. 런타임 오버 헤드와 운영 복잡성이 접근 방식의 이점을 압도 할 수 있기 때문입니다. 일이 너무 세분화되면 함수를 라이브러리로 패키징하고 함수를 다른 마이크로 서비스로 이동하는 것과 같은 대체 접근 방식을 고려해야합니다. [4]

경우 도메인 기반 설계 시스템이 구축되고있는 도메인을 모델링에 사용되는, 다음 microservice가 집계 한 작게 또는 경계 상황에 큰로서 수 있습니다. [31]

혜택

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

  • 모듈성 :이를 통해 애플리케이션을 더 쉽게 이해하고, 개발하고, 테스트하고, 아키텍처 침식에 대한 탄력성을 높일 수 있습니다. [5] 이러한 이점은 모 놀리 식 아키텍처의 복잡성과 비교하여 종종 논증됩니다. [32]
  • 확장 성 : 마이크로 서비스는 서로 독립적으로 구현되고 배포되기 때문에, 즉 독립적 인 프로세스 내에서 실행되므로 독립적으로 모니터링하고 확장 할 수 있습니다. [33]
  • 이기종 및 레거시 시스템의 통합 : 마이크로 서비스는 기존 모 놀리 식 소프트웨어 애플리케이션을 현대화하기위한 실행 가능한 수단으로 간주됩니다. [34] [35] 이 경험을 성공적으로 교체 한 여러 회사의 보고서 (의 일부) microservices에 의해 기존의 소프트웨어, 또는 그렇게하는 과정에 있습니다. [36] 에 대한 프로세스 소프트웨어 현대화 레거시 애플리케이션의 증분 방식을 사용하여 이루어진다. [37]
  • 분산 개발 : 소규모 자율 팀이 각자의 서비스를 독립적 으로 개발, 배포 및 확장 수 있도록하여 개발병렬화 합니다. [38] 또한 연속적으로 출현하는 개별 서비스의 아키텍처있게 리팩토링 . [39] Microservice 기반 아키텍쳐는 용이 지속적인 통합 , 연속 전달 및 배포. [40]

비판과 우려

마이크로 서비스 접근 방식은 다음과 같은 여러 문제에 대해 비판을받습니다.

  • 서비스는 정보 장벽을 형성합니다. [41]
  • 네트워크를 통한 서비스 간 호출모 놀리 식 서비스 프로세스 내의 프로세스 호출 보다 네트워크 대기 시간 및 메시지 처리 시간 측면에서 비용이 더 높습니다 . [1]
  • 테스트배포 는 더 복잡합니다. [42] [43]
  • 서비스간에 책임을 이동하는 것은 더 어렵습니다. [5] 다른 팀 간의 커뮤니케이션, 다른 언어로 기능을 다시 작성하거나 다른 인프라에 맞추는 것이 포함될 수 있습니다. [1] 그러나 마이크로 서비스는 나머지 애플리케이션과 독립적으로 배포 할 수 있지만 모놀리스 작업을 수행하는 팀은 함께 배포하기 위해 동기화해야합니다. [44]
  • 서비스 크기를 기본 구조화 메커니즘으로 보는 것은 내부 모듈화의 대안이 더 단순한 설계로 이어질 수있을 때 너무 많은 서비스로 이어질 수 있습니다. [45] 이 구성 요소의 응용 프로그램과 상호 의존성의 전반적인 구조를 이해하는 도움이 응용 프로그램의 사용을 필요로한다. [46]
  • 2 단계 커밋은 마이크로 서비스 기반 아키텍처에서 반 패턴으로 간주됩니다. 이로 인해 트랜잭션 내 모든 참여자가 더 긴밀하게 결합됩니다. 그러나이 기술이 부족하면 데이터 일관성을 유지하기 위해 모든 트랜잭션 참여자가 구현해야하는 어색한 춤이 발생합니다. [47]
  • 다양한 도구와 기술로 구축 된 많은 서비스의 개발 및 지원이 더 어렵습니다. 이는 엔지니어가 프로젝트간에 자주 이동하는 경우 특히 문제가됩니다. [48]
  • 일반적으로 마이크로 서비스 (HTTP)와 함께 사용되는 프로토콜은 공용 서비스 용으로 설계되었으므로 완벽하게 신뢰할 수 있어야하는 내부 마이크로 서비스 작업에는 적합하지 않습니다. [49]
  • 마이크로 서비스에만 국한되지는 않지만 분해 방법론은 종종 기능 분해를 사용하는데, 이는 요구 사항의 변경을 처리하지 않는 동시에 서비스의 복잡성을 추가합니다. [50]
  • 서비스 만 있기 때문에 마이크로 서비스의 개념 자체가 오해의 소지가 있습니다. 서비스가 마이크로 서비스로 시작되거나 중지되는시기에 대한 명확한 정의는 없습니다. [51]

인지 부하

이 아키텍처는 네트워크 지연 , 메시지 형식 설계, [52] 백업 / 가용성 / 일관성 (BAC), [53] 로드 밸런싱내결함성같은 처리해야 할 추가적인 복잡성과 새로운 문제를 도입 합니다 . [43] 이러한 문제는 모두 대규모로 해결한다. 모 놀리 식 애플리케이션 의 복잡성은 일련의 마이크로 서비스 애플리케이션으로 다시 구현되는 경우 사라지지 않습니다. 복잡성 중 일부는 운영 복잡성으로 변환됩니다. [54]복잡성이 드러나는 다른 곳은 증가 된 네트워크 트래픽과 그로 인한 성능 저하입니다. 또한 여러 마이크로 서비스로 구성된 애플리케이션은 해당 생태계 에 액세스하기위한 더 많은 수의 인터페이스 포인트를 가지 므로 아키텍처의 복잡성이 증가합니다. [55] (예컨대 다양한 조직 원리 HATEOAS 통해 캡처 된 인터페이스 및 데이터 모델 문서 자신감 등) 추가적인 복잡성의 영향을 줄이기 위해 적용되었다.

기술

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

이클립스 재단은 이클립스 마이크로 프로파일을 microservices 개발을위한 사양을 발표했다. [57]

서비스 메시

서비스 메시에서 각 서비스 인스턴스는 서비스 프록시, 사이드카 프록시 또는 사이드카라고하는 역방향 프록시 서버의 인스턴스와 쌍을 이룹니다. 서비스 인스턴스와 사이드카 프록시는 컨테이너를 공유하고 컨테이너는 Kubernetes , Nomad , Docker Swarm 또는 DC / OS 와 같은 컨테이너 오케스트레이션 도구로 관리됩니다 . 서비스 프록시는 다른 서비스 인스턴스와의 통신을 담당하며 서비스 (인스턴스) 검색,로드 밸런싱, 인증 및 권한 부여, 보안 통신 등과 같은 기능을 지원할 수 있습니다.

서비스 메시에서 서비스 인스턴스와 사이드카 프록시는 데이터 관리뿐만 아니라 요청 처리 및 응답도 포함하는 데이터 플레인을 구성한다고합니다. 서비스 메시에는 사이드카 프록시에 의해 조정되는 서비스 간의 상호 작용을 관리하기위한 제어 플레인도 포함됩니다. 서비스 메쉬 아키텍처에 대한 몇 가지 옵션이 있습니다 : 오픈 서비스 메쉬 , Istio (구글, IBM 간의 공동 프로젝트 및 Lyft), Linkerd (A CNCF의 주도로 프로젝트 뜨는 [58] ), 영사 (A HashiCorp의 제품) 및 많은 다른 사람은 서비스 메쉬 풍경 . 서비스 메시 관리 플레인 Meshery, 서비스 메시 배포 전반에 걸쳐 수명주기, 구성 및 성능 관리를 제공합니다.

플랫폼 비교

마이크로 서비스 아키텍처를 구현하는 것은 매우 어렵습니다. 모든 마이크로 서비스 아키텍처가 해결해야하는 많은 문제 (아래 표 참조)가 있습니다. 넷플릭스 는 내부 애플리케이션을 지원하기 위해 마이크로 서비스 프레임 워크를 개발 한 다음 그 프레임 워크의 많은 부분 을 오픈 소스 화했습니다 [59] . 이러한 도구의 대부분은 Spring Framework 를 통해 대중화 되었습니다. Spring Cloud [60] 프로젝트 의 우산 아래 Spring 기반 도구로 다시 구현되었습니다 . 아래 표는 Kubernetes 생태계의 구현 기능과 Spring Cloud 세계의 동등한 기능을 비교 한 것입니다. [61] Spring Cloud 생태계의 한 가지 주목할만한 측면은 모두 Java 기반 기술인 반면 Kubernetes는 다중 언어 런타임 플랫폼이라는 것입니다.

마이크로 서비스 우려 스프링 클라우드 및 넷플릭스 OSS Kubernetes
구성 관리 : 마이크로 서비스 애플리케이션의 구성은 코드에서 외부화되어야하며 간단한 서비스 호출을 통해 검색 할 수 있어야합니다. Spring Config Server, Netflix Archaius는 모두 구성을위한 Git 저장소 기반 위치를 지원합니다. Archaius는 구성 데이터 입력을 지원합니다. Kubernetes ConfigMaps는 서비스를 통해 etcd에 저장된 구성을 노출합니다. Kubernetes Secrets는 민감한 구성 정보 (예 : 비밀번호, 인증서 등)의 서비스 기반 보안 배포 및 사용을 지원합니다.
서비스 검색 : 마이크로 서비스 도메인 내에서 작업 할 수있는 서비스 인스턴스 목록을 유지합니다. Spring Cloud Eureka를 사용하면 클라이언트가 여기에 등록하고 등록 된 클라이언트와 하트 비트를 유지하며 서비스 이름으로 서비스를 조회하는 클라이언트의 호스트 이름에 서비스 이름을 매핑 할 수 있습니다. Kubernetes Services는 클러스터 내에서 내부적으로 사용 가능한 서비스 인스턴스의 배포 시간 등록을 제공합니다. Ingress는 서비스가 클러스터 외부의 클라이언트에 노출 될 수있는 메커니즘입니다.
로드 밸런싱 : 분산 시스템 확장의 핵심은 하나 이상의 구성 요소 인스턴스를 실행할 수 있다는 것입니다. 그런 다음로드 밸런서를 통해 해당 인스턴스에로드를 분산해야합니다. Spring Cloud Ribbon은 서비스 클라이언트가 서비스 인스턴스간에 부하를 분산 할 수있는 기능을 제공합니다. Kubernetes Service는 서비스 인스턴스에서 서비스 부하를 분산 할 수있는 기능을 제공합니다. 이것은 리본이 제공하는 것과 동일하지 않습니다.
API 게이트웨이 : 마이크로 서비스에서 제공하는 API의 세분성은 종종 서비스 클라이언트에 필요한 것과 다릅니다. API 게이트웨이는 파사드를 구현하고 프록시, 프로토콜 번역 및 기타 관리 기능과 같은 추가 서비스를 제공합니다. Spring Cloud Zuul은 구성 기반 API 파사드를 제공합니다. Kubernetes Service 및 Ingress 리소스, Istio, Ambassador는 남북 (데이터 센터 안팎으로의 트래픽)과 동서 (데이터 센터 또는 클라우드 또는 지역 간 트래픽) API 게이트웨이 기능을 모두 제공하는 솔루션입니다.
보안 문제 : 많은 보안 문제가 API 게이트웨이 구현으로 푸시됩니다. 분산 마이크로 서비스 애플리케이션을 사용하면 보안 휠을 재발 명하지 않고 모든 서비스가 공유하는 구성 요소에서 정책 정의 및 구현을 허용하는 것이 좋습니다. Spring Cloud Security는 Spring Cloud Zuul을 통해 많은 보안 문제를 해결합니다. Kubernetes 에코 시스템은 API 게이트웨이 메커니즘을 통해 보안을 제공 할 수있는 Istio와 같은 서비스 메시를 제공합니다.
중앙 집중식 로깅 : 중앙 집중식 로그 수집 및 분석 인프라를 통해 과다한 서비스를 관리하는 것이 중요합니다.이 중 많은 서비스는 분산 방식으로 운영됩니다. ELK 스택 ( Elasticsearch , LogStash, 키바 ) EFK 스택 ( Elasticsearch , Fluentd , Kibana )
중앙 집중식 메트릭 : 개별 서비스 및 전체 시스템의 상태와 성능을 모니터링 할 수있는 중앙 집중식 영역은 적절한 운영에 필수적입니다. 봄 구경꾼 및 아틀라스 힙 스터, 프로 메테우스, 그라 파나
분산 추적 : 프로세스 별 로깅 및 메트릭 모니터링은 그 자리를 차지하지만 트랜잭션이 분산 시스템에 전파 될 때 사용하는 복잡한 경로를 재구성 할 수 없습니다. 분산 추적은 마이크로 서비스 플랫폼의 필수 도구입니다. 봄 구름 탐정 호 쿠라, 예거
복원력 및 내결함성 : 분산 시스템은 장애에 대해 자동 라우팅이 가능해야하며 최적의 응답을 제공 할 서비스 인스턴스로 요청을 라우팅 할 수 있어야합니다. 스프링 Hystrix, 터빈 및 리본 상태 확인, 서비스 메시 (예 : Istio) [62]
자동 확장 및 자동 복구 : 분산 시스템은 수평 확장을 통해 더 높은 부하에 대응합니다. 플랫폼은 이러한 조건을 감지하고 자동으로 대응해야합니다. 또한 시스템은 오류를 감지하고 운영자 입력없이 자동 재시작을 시도해야합니다. - 상태 확인,자가 치유 및 자동 확장
패키징, 배포 및 예약 : 대규모 시스템에는 강력한 패키지 관리가 필요하며 배포 시스템은 롤링 또는 청록색 배포를 관리하고 필요한 경우 롤백을 관리해야합니다. 스케줄러는 현재 조건을 기반으로 새로운 서비스 집합을 배포 할 수있는 특정 실행 노드를 결정하는 데 도움이됩니다. Spring Boot, Apache Maven. Spring Cloud 시스템에는 진정한 스케줄러가 없습니다. Docker, Rkt, Kubernetes 스케줄러 및 배포, Helm [63]
작업 관리 : 개별 사용자 요청에서 연결이 끊긴 예약 된 계산. 스프링 배치 Kubernetes 작업 및 예약 된 작업
싱글 톤 애플리케이션 : 전체 시스템 내에서 해당 서비스의 유일한 인스턴스로 실행되도록 특정 서비스를 제한합니다. 스프링 클라우드 클러스터 Kubernetes 포드

또한보십시오

References

  1. ^ a b c d Martin Fowler. "Microservices". Archived from the original on 14 February 2018.
  2. ^ Newman, Sam (2015-02-20). Building Microservices. O'Reilly Media. ISBN 978-1491950357.
  3. ^ Wolff, Eberhard (2016-10-12). Microservices: Flexible Software Architectures. ISBN 978-0134602417.
  4. ^ 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.
  5. ^ a b c d Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  6. ^ a b Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016
  7. ^ "Backends For Frontends Pattern". Microsoft Azure Cloud Design Patterns. Microsoft.
  8. ^ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
  9. ^ Designing microservices: Continuous integration Microsoft Retrieved 9 January 2018
  10. ^ Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. ISBN 978-0-596-52955-0.
  11. ^ Martin Fowler. "Microservice Prerequisites".
  12. ^ Richardson, Chris (November 2018). Microservice Patterns. Chapter 1, section 1.4.1 Scale cube and microservices: Manning Publications. ISBN 9781617294549.CS1 maint: location (link)
  13. ^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). "Developing Self-Adaptive Microservice Systems: Challenges and Directions". arXiv:1910.07660 [cs.SE].
  14. ^ 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.
  15. ^ 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.
  16. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architecture and Design of an XML Application Platform". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  17. ^ Löwy, Juval (2007). Programming WCF Services, 1st ed. O’Reilly Media. pp. 543–553. ISBN 978-0-596-52699-3.
  18. ^ Juval Löwy "Every Class a WCF Service". (Channel9, ARCast.TV, October 2007).
  19. ^ Juval Löwy "Every Class As a Service" (Microsoft TechEd Conference, May 2009), SOA206. Archived from the original on 2010.
  20. ^ Löwy, Juval (2007). Programming WCF Services, 1st ed. O’Reilly Media. pp. 48–51. ISBN 978-0-596-52699-3.
  21. ^ Löwy, Juval (2010). Programming WCF Services, 3rd ed. O’Reilly Media. pp. 74–75. ISBN 978-0-596-80548-7.
  22. ^ 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.
  23. ^ James Lewis. "Micro services - Java, the Unix Way".
  24. ^ Fred George (2013-03-20). "MicroService Architecture: A Personal Journey of Discovery".
  25. ^ Farrow, Rik (2012). "Netflix heads into the clouds" (PDF).
  26. ^ James Lewis and Martin Fowler. "Microservices".
  27. ^ "Continuous Deployment: Strategies". javacodegeeks.com. Retrieved 28 December 2016.
  28. ^ 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.
  29. ^ O. Zimmermann, Domain-Specific Service Decomposition with Microservice API Patterns, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  30. ^ "Amazon SOA mandate".
  31. ^ Vaughn, Vernon (2016). Domain-Driven Design Distilled. Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  32. ^ Yousif, Mazin (2016). "Microservices". IEEE Cloud Computing. 3 (5): 4–5. doi:10.1109/MCC.2016.101.
  33. ^ 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.
  34. ^ Newman, Sam (2015). Building Microservices. O’Reilly. ISBN 978-1491950357.
  35. Wolff, Eberhard (2016). 마이크로 서비스 : 유연한 소프트웨어 아키텍처 . 애디슨 웨슬리. ISBN 978-0134602417.
  36. Knoche, Holger; Hasselbring, Wilhelm (2019). "마이크로 서비스 채택의 동인 및 장벽 – 독일 전문가를 대상으로 한 설문 조사" . 엔터프라이즈 모델링 및 정보 시스템 아키텍처 . DOI : 10.18417 / emisa.14.1을 .
  37. ^ 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.
  38. ^ Richardson, Chris. "Microservice architecture pattern". microservices.io. Retrieved 2017-03-19.
  39. ^ Chen, Lianping; Ali Babar, Muhammad (2014). Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45. Archived from the original|archive-url= requires |url= (help) on 2014-07-30.
  40. ^ 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.
  41. ^ Stenberg, Jan (11 August 2014). "Experiences from Failing with Microservices".
  42. ^ Calandra, Mariano. "Why unit testing is not enough when it comes to microservices".
  43. ^ a b "Developing Microservices for PaaS with Spring and Cloud Foundry".
  44. ^ 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.
  45. ^ Tilkov, Stefan (17 November 2014). "How small should your microservice be?". Innoq. Retrieved 4 January 2017.
  46. ^ 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.
  47. ^ Richardson, Chris (November 2018). Microservice Patterns. Chapter 4. Managing transactions with sagas: Manning Publications. ISBN 978-1-61729454-9.CS1 maint: location (link)
  48. ^ https://www.youtube.com/watch?v=X0tjziAQfNQ
  49. ^ Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  50. ^ Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  51. ^ Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  52. ^ 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.
  53. ^ 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.
  54. ^ Fowler, Martin. "Microservice Trade-Offs".
  55. ^ "BRASS Building Resource Adaptive Software Systems". U.S. Government. DARPA. April 7, 2015. "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented application programming interfaces (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with".
  56. ^ Wolff, Eberhard (2018-04-15). Microservices - A Practical Guide. ISBN 978-1717075901.
  57. ^ Swart, Stephanie (14 December 2016). "Eclipse MicroProfile". projects.eclipse.org.
  58. ^ "What's a service mesh?". Buoyant. Buoyant. 2017-04-25. Retrieved 5 December 2018.
  59. ^ Netflix OSS, Git Hub
  60. ^ Cloud, Spring
  61. ^ "Spring Cloud for Microservices Compared to Kubernetes", Developers, Red hat, 2016-12-09
  62. ^ Managing microservices with the Istio service mesh, Kubernetes, May 2017
  63. ^ The Kubernetes Package Manager, Helm

Further reading