클라우드 네이티브 기술 시스템은 지저분하고 복잡해 보일 수 있지만 다른 관점에서는 "만지고 몸 전체를 움직이는 것"이라는 주요 라인을 구현합니다. 타임 라인 관점에서 볼 때 컨테이너 기술의 발전은 클라우드 네이티브 사고의 경향을 낳았고, 이는 하단의 리소스 공급 문제를 해결했습니다. 그리고 오픈 소스 Kubernetes는 컨테이너 오케스트레이션의 표준 사양이되었습니다. 쿠 버네 티스 확장 성을 기반으로 한 플랫폼이 더욱 풍부 해져 클라우드 네이티브 생태계의 가장 중요한 초석이되었습니다. 그 결과, Service Mesh 및 서버리스 기술의 핵심 아이디어는 비즈니스 측면에서 더 많은 기능을 인프라에 가라 앉히고 경량 애플리케이션 및 클라우드 마이그레이션의 가능성을 제공하는 데 더 초점을 맞추고 있습니다.
기술 요구 사항의 관점에서 마이크로 서비스 아키텍처는 단일 복잡성 문제를 해결하는 데 선호되는 방법이지만 전체 시스템의 전반적인 복잡성이 크게 증가했습니다. 컨테이너 기술과 Kubernetes는 각각 배포 및 배포를 해결했습니다. 마이크로 서비스 아키텍처 하에서 많은 수의 애플리케이션. Kubernetes는 컨테이너의 관리 및 예약뿐만 아니라 Service Mesh에 대한 더 나은 기본 지원을 제공하고 기본 인프라의 서버리스 클라우드 네이티브 화 및 미들웨어 기능의 추가 침몰을 제공합니다.
1. 용기
컨테이너는 프로세스를 독립적 인 공간으로 효과적으로 분할하여 독립된 공간 간의 자원 사용 갈등을 균형있게 조정하는 기술입니다. 본질적으로 컨테이너는 특별한 프로세스입니다. 그 핵심 기능은 프로세스의 동적 성능을 제한하고 수정하여 "경계"를 만드는 것입니다. 또한 해당 리소스 제한 기능과 미러링 기능인 All이 보여주는 "강력한 일관성"도 있습니다. 컨테이너 기술을 클라우드 네이티브를위한 가장 중요한 기본 기술 중 하나로 만듭니다.
Docker 컨테이너는 가상 머신과 유사한 격리 효과 때문에 종종 "경량"가상화 기술이라고 불리지 만 그러한 설명은 엄격하지 않습니다. 가상 머신에서 하이퍼 바이저는 가장 중요한 부분으로, 하드웨어 가상화 기능을 통해 CPU, 메모리, I / O 장치 등 다양한 유형의 하드웨어를 시뮬레이션 한 후 이러한 가상 하드웨어에 새로운 운영 체제 인 In Guest OS를 설치합니다. , 가상 운영 체제에서 실행되는 응용 프로그램 프로세스는 서로 격리됩니다.
Docker와 가상 머신의 차이점은 서로 다른 프로세스 격리 방법에 반영됩니다. Docker는 애플리케이션에 추가 네임 스페이스 매개 변수를 연결하여 프로세스 격리를 구현합니다. 호스트에서 실행중인 실제 "Docker 컨테이너"가 없습니다.이 "모호한"작업은 프로세스가 격리 된 "컨테이너"에서 실행되는 것처럼 보이므로 컨테이너가 추가 리소스 소비 및 점유를 줄이고 민첩성과 고성능 측면에서 큰 이점을 갖습니다.
또한 컨테이너의 핵심 기능에는 Cgroup 기반 리소스 제한 기능과 미러링 기능도 포함됩니다. Cgroup의 기능은 CPU, 메모리, 디스크 및 네트워크 대역폭과 같은 리소스를 포함하여 프로세스 그룹이 사용할 수있는 리소스의 상한을 제한하는 것입니다. 미러링 기능은 컨테이너 기술이 "강력한 일관성"을 보여줍니다. 즉, 모든 위치에서 다운로드 된 이미지의 내용이 완전히 일관되고 이미지 제작자의 원래 완전한 환경을 완전히 재현하여 "개발의 모든 측면을 열어줍니다." 테스트 배포 "프로세스, 컨테이너 기술을 주류 소프트웨어 릴리스 방법으로 만듭니다.
2. 총재
컨테이너 미러링이 애플리케이션 배포를위한 산업 표준이되었을 때 컨테이너 구성 및 관리 사양을 정의 할 수있는 "컨테이너 오케스트레이션"기술은 전체 컨테이너 기술 스택에서 핵심 가치 노드가되었습니다. 주요 컨테이너 오케스트레이션 도구에는 Docker의 Compose + Swarm 조합, Mesosphere의 Mesos + Marathon 조합, Google과 RedHat가 공동 주도하는 Kubernetes 프로젝트, Kubernetes 기반 OpenShift 및 Rancher 프로젝트가 포함됩니다. 결국 뛰어난 개방성, 확장 성 및 활발한 개발자 커뮤니티를 갖춘 Kubernetes 프로젝트는 컨테이너 오케스트레이션 전투에서 돋보였으며 분산 리소스 예약 및 자동화 된 운영 및 유지 관리를위한 사실상의 표준이되었습니다.
Kubernetes 프로젝트의 주요 디자인 아이디어는보다 거시적 인 관점에서 통합 된 방식으로 작업 간의 다양한 관계를 정의하고 향후 더 많은 유형의 관계를 지원할 여지를 남겨 두는 것입니다. 기능적 관점에서 Kubernetes는 사용자의 요구와 전체 시스템의 규칙에 따라 컨테이너 간의 다양한 관계, 즉 배포, 예약 및 노드 간 확장을 포함한 컨테이너 오케스트레이션을 자동으로 처리하는 데 더 효과적입니다. 클러스터. Mesos 및 Swarm과 같은 프로젝트는 특정 규칙, 즉 컨테이너 일정에 따라 실행하기에 가장 적합한 노드에 컨테이너를 배치하는 데 능숙합니다. 이것은 Kubernetes 프로젝트가 마침내 눈에 띄는 중요한 이유이기도합니다.
Kubernetes 핵심 기능 :
- 서비스 검색 및로드 밸런싱 : 컨테이너화 된 애플리케이션 간의 상호 통신을 지원하기 위해 DNS 및 여러로드 밸런싱 메커니즘과 결합 된 서비스 리소스를 통해 다양한 애플리케이션 서비스를 표시합니다.
- 스토리지 오케스트레이션 : 로컬, nfs, ceph, 퍼블릭 클라우드 블록 스토리지 등과 같은 플 런지 형태의 여러 스토리지를 지원합니다.
- 리소스 예약 : 포드 예약에 필요한 리소스 및 리소스 제한을 설정하고, 자동 애플리케이션 릴리스 및 애플리케이션 롤백을 지원하고, 애플리케이션 관련 구성을 관리합니다.
- 자동 복구 : 클러스터의 모든 호스트를 모니터링하고, 클러스터의 예외를 자동으로 검색 및 처리하고, 다시 시작해야하는 포드 노드를 교체하고, 컨테이너 클러스터가 원하는 사용자 상태에서 실행되도록합니다.
- 키 및 구성 관리 : 비밀을 통해 민감한 정보를 저장하고 configmap을 통해 애플리케이션 구성 파일을 저장하여 이미지의 구성 파일을 수정하지 않고 컨테이너 레이아웃의 유연성을 높입니다.
- 수평 확장 기능 : 노드 자동 추가 및 삭제와 같은 CPU 사용률 또는 플랫폼 수준에 따라 탄력적 인 확장을 실현합니다.
Kubernetes 프로젝트는 제어 노드 마스터와 컴퓨팅 노드 노드로 구성됩니다. 마스터는 제어 및 관리 노드로서 밀접하게 조정 된 세 가지 독립 구성 요소로 구성됩니다. kube-apiserver는 API 서비스를 담당하고 kube-scheduler는 리소스 스케줄링을 담당하며 kube-controller-manager는 컨테이너 오케스트레이션을 담당합니다. , 클러스터의 영구 데이터는 kube에서 관리합니다 .- apiserver가 처리 된 후 Pod, Service 및 기타 객체 정보와 같은 Etcd에 저장됩니다. 컴퓨팅 노드 노드는 프로젝트의 작업 부하이며 kubelet 구성 요소는 핵심 부분입니다. 포드에 해당하는 컨테이너의 생성, 시작 및 종료를 담당합니다. 동시에 클러스터 관리의 기본 기능을 실현하는 마스터 노드.
오늘날 Kubernetes 프로젝트는 컨테이너 기술의 사실상 표준 일뿐만 아니라 전체 클라우드 네이티브 시스템 개발의 초석이되어 인프라 분야에서 애플리케이션 오케스트레이션 및 관리를위한 다양한 가능성을 재정의합니다. 전체 클라우드 네이티브 에코 시스템에서 Kubernetes 프로젝트는 과거와 다음을 연결하는 역할을했습니다. 위에서 Kubernetes는 Kubernetes 자체의 기본 API에 의해 사용자에게 노출되는 모든 기능인 Service, Ingress, Pod, Deployment와 같은 인프라 기능의 형식화 된 데이터 추상화를 노출합니다. 반면에 Kubernetes는 CNI, CSI, DevicePlugin 및 CRD와 같은 인프라 기능 액세스를위한 표준 인터페이스를 제공하므로 클라우드를 기능 제공자로 사용하여 표준화 된 방식으로 Kubernetes 시스템에 기능에 액세스 할 수 있습니다. 마이크로 서비스 및 DevOps와 같은 기술 개념이 개발됨에 따라 Kubernetes의 확장성에 기반한 개방형 애플리케이션 플랫폼이 PaaS를 주류로 대체하고 클라우드의 가치가 애플리케이션 자체로 돌아가고 점점 더 많은 오픈 소스 프로젝트가 진행될 것입니다. 클라우드 네이티브, 배포 및 운영 및 유지 관리의 개념으로 개발되었으며 마침내 클라우드 서비스로 직접 진화했습니다.
3. 마이크로 서비스
마이크로 서비스는 서비스 아키텍처 진화의 산물입니다. 모 놀리 식 아키텍처, 수직 아키텍처 및 서비스 지향 아키텍처 (SOA)를 경험 한 후 MSA (마이크로 서비스 아키텍처)는 SOA 아키텍처의 분산 구현으로 간주 될 수 있습니다. 비즈니스 개발 및 수요가 계속 증가함에 따라 단일 애플리케이션 기능이 점점 더 복잡해지고 중앙 집중식 R & D, 테스트, 릴리스 및 통신 모드로 인해 애플리케이션 반복 효율성이 크게 감소했습니다.
마이크로 서비스 아키텍처는 기본적으로 더 나은 민첩성을 대가로 더 높은 운영 및 유지 관리 복잡성을 견디는 것입니다. 이의 이점은 작고 관리되고 분산되어 있지만 인프라의 수요, 비용 및 복잡성의 급증으로 이어집니다.
지금까지 Martin Fowler의 설명과 결합 된 마이크로 서비스에 대한 통합 표준 정의는 없습니다. 마이크로 서비스 아키텍처는 단일 애플리케이션을 일련의 소규모 서비스로 개발하고 자체 프로세스에서 독립적으로 실행되는 아키텍처 패턴 / 아키텍처 스타일입니다. 다음과 같은 경량 메커니즘을 사용합니다. HTTP API로 서로 통신합니다. 이러한 서비스는 특정 비즈니스를 중심으로 구축되고 완전히 자동화 된 배포 메커니즘을 통해 독립적으로 배포되며 다양한 프로그래밍 언어와 다양한 데이터 저장 기술로 작성 될 수 있으며 최소한의 중앙 집중식 관리를 유지합니다.
Dubbo와 Spring Cloud는 통합으로 이동하고 있으며 더 많은 기능이 인프라에 가라 앉을 것입니다.
- 봄 구름
Spring Cloud는 1 세대 마이크로 서비스 아키텍처의 리더로, 마이크로 서비스 아키텍처 구현을위한 원 스톱 솔루션을 제공합니다. 패밀리 스타일의 기술 스택으로서 개발자에게 분산 시스템의 공통 모델을 빠르게 구축 할 수있는 도구를 제공합니다. 구성 관리, 서비스 검색, 퓨즈, 지능형 라우팅, 마이크로 에이전트, 제어 버스, 일회성 토큰, 글로벌 잠금, 리더 선택, 분산 세션, 클러스터 상태 등이 포함됩니다.
- 더보
Alibaba가 오픈 소스로 제공하는 분산 서비스 프레임 워크 인 Dubbo는 고성능의 투명한 RPC 원격 서비스 호출 솔루션과 SOA 서비스 거버넌스 솔루션을 제공하기 위해 최선을 다하고 있습니다. 핵심 부분에는 원격 통신, 클러스터 내결함성, 자동 검색 등이 포함됩니다.
최근 몇 년 동안 Dubbo 생태계는 지속적으로 개선되었습니다 .2019 년 5 월 Dubbo-go는 공식적으로 Dubbo 공식 생태계에 가입 한 후 REST 프로토콜 및 gRPC 지원을 구현하여 Spring Cloud와 gRPC 생태계를 개방했습니다. Go 간의 상호 운용성 프로젝트와 Java & Dubbo 프로젝트가 해결되었습니다. 효과적인 솔루션입니다. 오늘, Spring Cloud Alibaba의 출현으로 인해 Dubbo는 Spring Cloud 생태계의 다양한 주변 제품을 원활하게 통합 할 것입니다.
Dubbo이든 Spring Cloud이든 특정 애플리케이션 시나리오 및 개발 환경에 다소 제한되어 있고 다용도 및 다국어 지원이 부족하며 마이크로 서비스의 개발 수준에서만 문제를 해결하고 DevOps의 전체 솔루션이 부족합니다. Service Mesh의 부상을위한 조건을 만들었습니다.
마이크로 서비스 관리 및 통신을위한 완벽한 솔루션 인 Dubbo와 Spring Cloud는 오랫동안 공존하고 병합 할 예정이지만 제공하는 기능 중 일부는 점차 인프라로 대체 될 것입니다.
- 예를 들어, kubernetes 클러스터에 배치 된 마이크로 서비스, kubernetes 서비스 등록 및 검색 기능의 사용이 더 쉬울 것입니다.
- 또 다른 예는 Istio 아키텍처의 사용이며, 트래픽 관리 및 회로 차단기와 같은 기능이 엔보이 프록시로 전송되고 점점 더 많은 기능이 애플리케이션에서 제거되고 인프라로 이동합니다.
4. 서비스 메시
서비스 메시는 일반적으로 서비스 메시로 번역됩니다. 클라우드 네이티브 애플리케이션의 복잡한 서비스 토폴로지에서 서비스 메시는 이러한 토폴로지에서 안정적인 요청 전달을 담당하는 인프라 계층입니다. Service Mesh는 요청 호출 경로에 Sidecar를 추가하고, 클라이언트가 원래 완료 한 복잡한 기능을 Sidecar에 싱크하고, 클라이언트의 단순화와 서비스 간의 통신 제어 이전을 실현합니다. 시스템, 서비스 이들 간의 호출 관계는 메시로 표현되며 서비스 그리드 이름의 출처이기도합니다.
다음 특성에서 Service Mesh의 정의를 요약하고 요약 할 수 있습니다.
- 추상화 : Service Mesh는 애플리케이션에서 통신 기능을 제거하고 별도의 통신 계층을 형성하고이를 인프라 계층에 싱크합니다.
- 기능 : Service Mesh는 기능 측면에서 기존 라이브러리 방식과 다르지 않은 안정적인 요청 전달을 실현합니다.
- 배포 : Service Mesh는 배포시 경량 네트워크 에이전트로 구현되며 사이드카 모드 및 애플리케이션 일대일로 배포되며 둘 간의 통신은 Localhost를 통해 원격으로 호출됩니다.
- 투명성 : Service Mesh의 기능 구현은 응용 프로그램과 완전히 독립적입니다. 독립적으로 업그레이드 배포, 기능 확장 및 결함 복구가 가능합니다. 응용 프로그램은 Service Mesh의 특정 구현 세부 사항에주의를 기울일 필요가 없습니다. 응용 프로그램에 투명합니다.
Service Mesh의 핵심 가치는 기능과 특성뿐만 아니라 비즈니스 로직과 비 비즈니스 로직의 분리에도 반영됩니다. 비 비즈니스 로직은 클라이언트 SDK에서 제거되고 프록시의 독립적 인 프로세스로 실행되므로 SDK에 원래 있던 다양한 기능이 컨테이너, Kubernetes 또는 VM 기반 인프라에 가라 앉아 클라우드 호스팅 및 가벼운 애플리케이션이 실현됩니다. 애플리케이션 클라우드 네이티브를 지원하기 위해 정량화합니다.
주류 Service Mesh 오픈 소스 소프트웨어에는 Linkerd, Envoy 및 Istio가 포함됩니다. Linkerd와 Envoy는 모두 Service Mesh의 핵심 개념을 직접 구현합니다. 즉, 서비스 검색, 요청 라우팅,로드 밸런싱 및 기타 기능을 실현하고 서비스 간의 통신 문제를 해결하며 애플리케이션이 서비스 통신을 인식하지 못하도록하는 기능이 비슷합니다. Istio는 더 높은 관점을 취하고 서비스 메시를 데이터 플레인과 컨트롤 플레인으로 나눕니다. 데이터 플레인은 마이크로 서비스 간의 모든 네트워크 통신을 담당하고 컨트롤 플레인은 데이터 플레인 프록시를 관리하며 Istio는 자연스럽게 Kubernetes를 지원합니다. 애플리케이션 스케줄링 프레임 워크 및 서비스 메시.
마이크로 서비스를 시작하려면 완전한 인프라 세트가 필요합니다. 컨테이너가 마이크로 서비스의 최소 작업 단위가되면 일반 컨테이너 관리 플랫폼 인 Kubernetes는 마이크로 서비스 아키텍처의 가장 큰 장점을 활용하고 차세대 클라우드 컴퓨팅으로 만들 수 있습니다. 운영 체제. Kubernetes는 클라우드 네이티브 및 기존 컨테이너화 된 애플리케이션의 실행을 지원할뿐만 아니라 개발 및 운영 단계도 지원할 수 있습니다 .Service Mesh와의 조합은 사용자에게 완전한 엔드 투 엔드 마이크로 서비스 경험을 제공 할 수 있습니다.
5. 서버리스
서버리스는 서비스 간의 동기 통신에 국한 될뿐만 아니라 네트워크 액세스를 통해 더 많은 시나리오로 확장되고 컴퓨팅, 스토리지, 데이터베이스, 미들웨어 등 서비스를 포함한 클라이언트 SDK를 통해 실현되는 Service Mesh의 애플리케이션 시나리오를 일반화합니다. 예를 들어 Ant Financial의 서버리스 방식에서 Mesh 모드는 Database Mesh (데이터베이스 액세스), Message Mesh (메시지 메커니즘) 및 Cache Mesh (캐싱)와 같은 시나리오로 확장됩니다.
현재 서버리스는 일반적으로 FaaS (서비스로서의 기능)와 BaaS (서비스로서의 백엔드)의 모음으로 간주되지만 서버리스는 특정 기술이 아닌 사용자 경험만을 정의합니다. FaaS와 BaaS는 실현할 서버리스 방법. 서버리스 기술이 계속 발전함에 따라 kubernetes 서비스를 사용하는 점점 더 많은 애플리케이션이 서버리스 애플리케이션으로 전환 될 것입니다.
6. 클라우드 네이티브 미들웨어
전통적인 미들웨어는 도시의 수도관과 유사하며 한 응용 프로그램에서 다른 응용 프로그램으로의 데이터 흐름을 촉진하고 관리하며 높은 수준의 비즈니스 결합을 가지고 있으며 사용자에게 직접적인 가치를 제공 할 수 없습니다. 클라우드 시대에 소프트웨어의 이질성과 상호 연결에 대한 수요가 크게 증가했습니다. 미들웨어에는 새로운 기능 정의, 즉 독립 기능, 낮은 결합 및 모듈 식 구성 요소가 부여되었습니다. 가용성, 높은 확장 성 및 최종 일관성.
기능 정의 관점에서 미들웨어는 소프트웨어 구성 요소와 응용 프로그램을 연결하는 컴퓨터 소프트웨어 유형입니다. 여기에는 하나 이상의 시스템에서 실행중인 여러 소프트웨어가 네트워크를 통해 상호 작용할 수 있도록 서비스 집합이 포함됩니다. 재사용 가능 소프트웨어 범주입니다. 클라우드 네이티브 미들웨어에는 API, 애플리케이션 서버, TP, RPC, MOM이 포함되며 데이터 통합 및 애플리케이션 통합 역할도 수행 할 수 있습니다. 커널과 사용자 애플리케이션 간의 모든 소프트웨어는 미들웨어로 이해할 수 있습니다.
IoT 및 클라우드 컴퓨팅 기술의 급속한 발전으로 EDA (Event Driven Architecture)는 점점 더 많은 기업에서 채택되고 있습니다. 이벤트의 추상화 및 비 동기화를 통해 비즈니스 분리를 제공하고 비즈니스 반복을 가속화 할 수 있습니다. 또한 지원을 시작하고 있습니다. 수직 산업. 패키지 애플리케이션, 개발 도구, 비즈니스 프로세스 관리 및 모니터링 분야에 적용되는 일반적인 비즈니스 크리티컬 애플리케이션 아키텍처로 전환합니다.
EDA는 종종 메시지 미들웨어를 통해 구현됩니다. 메시지 미들웨어는 플랫폼 독립적 인 데이터 교환을 위해 효율적이고 안정적인 메시지 전달 메커니즘을 사용하는 것을 목표로합니다. 메시지 전달 및 메시지 큐잉 모델을 제공하여 분산 환경에서 프로세스 간 통신을 확장 할 수 있으며이를 기반으로합니다. 데이터 통신은 분산 시스템을 통합합니다. 일반적인 메시지 미들웨어에는 ActiveMQ, RabbitMQ, RocketMQ, Kafka 등이 포함되며, 시스템 간 데이터 전송, 높은 동시성 트래픽 피크 클리핑, 비동기 데이터 처리와 같은 시나리오에 적용 할 수 있습니다.
클라우드 컴퓨팅 시대에 클라우드 공급 업체는 비즈니스에 더 가까운 패키지를 제공하고 대부분 자체 서버리스 서비스를 사용하여 이벤트로드를 실행합니다. 미들웨어 기능은 Alibaba Cloud Function Compute, Azure Function 및 AWS Lambda를 포함한 클라우드 서비스를 통해 쉽게 구현됩니다. 이벤트 처리.
앞으로 애플리케이션 미들웨어는 더 이상 기능 제공자가 아니라 기능 액세스를위한 표준 인터페이스가 될 것입니다.이 표준 인터페이스는 HTTP 및 gRPC 프로토콜을 통해 구축 될 것이며 전체 서비스 및 애플리케이션 비즈니스 로직의 액세스 계층이 분리 될 것입니다. Service Mesh의 아이디어와 일치하는 Sidecar를 통해. 또한 사이드카 모델은 모든 미들웨어 시나리오에 적용 할 수 있으므로 미들웨어 기능을 Kubernetes 기능의 일부로 "싱킹"할 수 있습니다.
7. DevOps
클라우드 네이티브 오픈 소스 생태계의 지속적인 개선과 복잡한 기능이 클라우드로 지속적으로 침몰함에 따라 소프트웨어 배포 및 운영 및 유지 관리의 기본 모델이 기본적으로 통합되었습니다. DevOps 이전에 실무자들은 소프트웨어 프로젝트 개발을 위해 워터 폴 모델 또는 애자일 개발 모델을 사용했습니다. 개발과 운영의 조합 인 DevOps는 소프트웨어 개발과 IT 팀 간의 프로세스 자동화를 실현하기위한 일련의 관행으로 정의됩니다. 이러한 관행은 팀 간의 협업 문화를 기반으로 구축되며 개발 측면과 IT 팀 간의 격차를 메 웁니다. 소프트웨어를 더 빠르고 안정적으로 빌드, 테스트 및 릴리스하기위한 정보 격차는 이제 주류 소프트웨어 개발 및 제공 모델이되었습니다.
전반적으로 DevOps에는 개발, 테스트, 운영 및 유지 관리의 세 부분이 포함됩니다. 특히 지속적인 개발, 지속적인 통합, 지속적인 테스트, 지속적인 피드백, 지속적인 모니터링, 지속적인 배포, 지속적인 운영 및 유지 관리 (통칭 DevOps 수명주기라고 함)와 같은 여러 단계로 구성됩니다.
DevOps 기능의 분리 및 통합은 정보 흐름 수준에 완전히 반영됩니다. 개발, 전달, 테스트, 테스트 피드백, 전달 및 릴리스 단계에서 다양한 정보 제공 업체와 수신자는 고품질 도구와 시스템을 사용하여 원활하고 정확한 정보 전송과 기계화 된 작업을 효율적으로 수행합니다.
위의 개발 개념에서 DevOps의 아이디어는 인프라 계층이 충분히 강하지 않고 충분히 표준화되지 않았기 때문에 비즈니스 측에 R & D, 운영 및 유지 관리 인력 및 해당 인프라를 결합 할 도구 세트가 필요하다는 사실에서 비롯됩니다. 그러나 Kubernetes와 인프라가 점점 더 복잡 해짐에 따라 클라우드 네이티브 생태계는 이에 상응하는 추상화와 계층을 만들 것입니다. 각 계층의 역할은 자체 데이터 추상화, 즉 개발 측면과 운영 및 유지 관리 측면의 초점과 만 상호 작용합니다. . 분리. 지속적으로 일반화되는 서버리스는 또한 이념적 방향과 DevOps의 일부가 될 것입니다. 기능 측면에서는 "간단한 운영 및 유지 관리", "NoOps"및 "셀프 서비스 운영 및 유지 관리 기능"이 애플리케이션 운영 및 유지 관리의 주류 방법이 될 것입니다. 애플리케이션 측에서는 애플리케이션 설명이 사용자 측에서 광범위하게 추상화되고 이벤트 기반 및 서버리스 개념이 분할되고 일반화되며 FaaS 이외의 다양한 시나리오에 적용될 수 있습니다.
관련 기사