소개 : 세상에는 공짜 점심이 없습니다. 마이크로 서비스 기술은 IT 시스템을보다 민첩하고 견고하며 고성능으로 만들지 만 아키텍처 복잡성도 증가시킵니다. 개발자의 경우 마이크로 서비스 아키텍처를 더 잘 제어하려면 지속적인 통합, 서비스 검색, 애플리케이션 통신, 구성 관리 및 트래픽 보호와 같은 일련의 문제를 해결해야합니다.
머리말
대규모 분산 IT 아키텍처 분야에서 마이크로 서비스는 필수 기술입니다. 본질적으로 마이크로 서비스는 대규모 시스템을 독립적 인 수명주기를 가진 여러 애플리케이션으로 분할하고 애플리케이션 간 통신을 위해 경량 통신 메커니즘을 사용하는 아키텍처 스타일입니다. 이러한 애플리케이션은 특정 비즈니스를 중심으로 구축되며 독립적으로 배포하거나 독립적으로 반복하거나 비즈니스 부하에 따라 독립적으로 확장 할 수 있습니다.
마이크로 서비스 및 관련 기술에 대한 아이디어는 IT 아키텍처 개발에 일련의 중대한 변화를 가져 왔습니다.
손쉬운 개발 및 유지 관리 : 응용 프로그램은 특정 비즈니스 기능 집합에만 초점을 맞 춥니 다. 서비스 분할을 통해 응용 프로그램 간의 결합을 줄여 개발 및 유지 관리를 더 쉽게 할 수 있습니다.
무제한 기술 스택 : 마이크로 서비스 아키텍처에서 프로젝트 비즈니스 및 팀의 특성에 따라 합리적으로 기술 스택을 선택할 수 있습니다.
시스템 진화 속도 향상 : 각 애플리케이션을 독립적으로 업데이트 할 수 있으며 그레이 릴리스와 같은 기술적 수단을 통해 전체 시스템의 안정적인 작동을 보장 할 수 있습니다.
획기적인 성능 병목 현상 : 각 애플리케이션을 수평 적으로 독립적으로 확장 할 수 있으므로 컴퓨팅 리소스의 증가에 따라 시스템 성능이 선형 적으로 확장 될 수 있습니다.
마이크로 서비스의 과제
세상에는 공짜 점심이 없습니다. 마이크로 서비스 기술은 IT 시스템을보다 민첩하고 견고하며 고성능으로 만드는 동시에 아키텍처 복잡성을 증가시킵니다. 개발자의 경우 마이크로 서비스 아키텍처를 더 잘 제어하려면 지속적인 통합, 서비스 검색, 애플리케이션 통신, 구성 관리 및 트래픽 보호와 같은 일련의 문제를 해결해야합니다. 다행히도 이러한 일반적인 문제에 대응하여 일련의 우수한 오픈 소스 기술 구성 요소 및 도구가 업계에 등장하여 개발자가 마이크로 서비스 애플리케이션을보다 쉽게 구축 할 수 있습니다. 수년간의 개발 끝에 Spring Cloud 및 Dubbo와 같은 기술 프레임 워크는 마이크로 서비스 분야의 공통 표준으로 발전하여 마이크로 서비스의 임계 값을 크게 줄 였지만 이러한 기술 프레임 워크는 여전히 두 가지 가장 큰 문제를 해결할 방법이 없습니다. 개발자 이전에 두 가지 도전이 두 개의 큰 산이되었습니다.
과제 1 : 포괄적 인 수명주기 관리 및 서비스 거버넌스 계획이 긴급히 필요합니다.
자주 반복되는 시스템에서 각 애플리케이션은 종종 새 버전 릴리스의 필요성에 직면하게됩니다. 애플리케이션의 온라인, 오프라인, 업데이트 및 롤백 프로세스를 중앙 집중식으로 관리하고 세분화 된 그레이 스케일 릴리스 방법과 협력해야합니다. , 버전 반복이 비즈니스에 미치는 영향을 줄입니다.
간단한 마이크로 서비스 아키텍처에서 애플리케이션이 전체 링크의 진입 점에있는 경우 해당 프런트 엔드는 일반적으로 최종 사용자의 비즈니스 요청을 수락하기 위해 부하 분산 구성 요소 (위 그림의 애플리케이션 A)와 연결됩니다. 이러한 종류의 응용 프로그램이 수명주기 관리에 있으면 복잡성이 더 높아집니다. 새 버전 릴리스 프로세스에서 응용 프로그램의 균형과 안정성을 보장하기 위해 다음 단계를 거칩니다.
이 프로세스에서 트래픽의 세분화 된 제어를위한 고급 그레이 스케일 솔루션은 관련되지 않았지만 복잡성과 운영상의 어려움을 반영하는 것으로 충분합니다. 관리를 위해 간단한 릴리스 스크립트에만 의존하는 경우 효율성이 매우 낮을뿐만 아니라 한 쪽이 다른 쪽을 보지 못하게하여 시스템 안정성에 큰 위험을 초래하기 쉽습니다.
과제 2 : 완전한 수평 확장 및 축소 계획이 긴급히 필요합니다.
애플리케이션 성능에 병목 현상이 있고 성능 향상을 위해 인스턴스 수를 늘려야하는 경우 새로운 컴퓨팅 리소스를 도입해야합니다.
새로운 컴퓨팅 리소스의 출처는 어디입니까?
오프라인 IDC의 경우 컴퓨팅 자원을 미리 계획해야하며 용량 확장은 단순한 문제가 아니며 다양한 제약으로 인해 확장이 불가능할 수 있습니다. 물론 이러한 종류의 문제는 클라우드 컴퓨팅 시대에 더 이상 존재하지 않습니다. 애플리케이션의 컴퓨팅 리소스를 확장하는 것은 쉽지만 컴퓨팅 리소스만으로는 충분하지 않습니다. 애플리케이션을 배포하고 마이크로 서비스 시스템에 포함시켜야합니다.
이 프로세스에 따르면 애플리케이션 인스턴스를 확장해야하는 경우 20 분 이상 소요될 것으로 보수적으로 추정되며 구매, 시스템 초기화, 애플리케이션 배포에 모두 많은 시간이 소요됩니다. 시스템 트래픽이 갑작스럽게 증가하고 2 분 이내에 긴급 확장이 필요하다고 가정하면이 솔루션은 쓸모가 없습니다.
좋은 약 : 용기 화 기술
이 두 가지 문제를 해결하기 위해 개발자들은 다양한 솔루션을 시도했으며 지난 5 년 동안 새로운 아이디어와 기술 프레임 워크가 끊임없이 등장했습니다. 적자 생존 기간 후 Kubernetes 에코 시스템이 지원하는 Docker가 대표하는 컨테이너 기술은 업계의 주류가되었으며 클라우드 네이티브 애플리케이션을 구축하는 데 필수적인 요소입니다. 컨테이너화 관련 기술은 클라우드 컴퓨팅의 가치를 더 많은 프로그램으로 활용할 수 있으며 개발자가이 두 가지 문제를 해결하는 데 어느 정도 도움이됩니다.
애플리케이션 수명주기 관리 및 서비스 거버넌스 측면에서 Kubernetes는 비교적 완전한 구현 메커니즘을 제공합니다. 배포 리소스를 proStop 및 postStart 스크립트와 함께 구성하면 롤링 릴리스와 우아한 온라인 및 오프라인 애플리케이션을보다 쉽게 구현할 수 있습니다. 그레이 릴리스 과정에서 트래픽에 대한 세분화 된 제어를 직접 수행 할 수있는 방법은 아직 없지만 (서비스 메시 기술의 도입은이 기사의 범위를 벗어난 트래픽 제어를 향상시킬 수 있음) 간단한 릴리스 스크립트와 비교하여 도약했습니다. 승진 시키십시오.
애플리케이션의 수평 확장 및 축소 측면에서 컨테이너화 기술은 운영 체제 설치 및 시스템 수준 초기화 시간을 크게 줄일 수 있지만 가상 머신 구매 작업은 불가피하므로 시스템 트래픽이 갑작스럽게 증가합니다. 그 당시에는 여전히 빠른 수평 확장을 달성 할 방법이 없었습니다. 컴퓨팅 리소스의 일부를 예약하여 리소스 풀에 넣을 수 있습니다. 응용 프로그램을 확장해야하는 경우 리소스 풀에서 리소스를 신청합니다. 업무 부하가 감소하면 초과 컴퓨팅 리소스를 리소스 풀로 반환합니다.
이것은 실제로 좋은 생각이 아닙니다. 모든 컴퓨팅 리소스에는 비용이 필요합니다. 리소스 풀은 컴퓨팅 리소스를 빠르게 사용하는 문제를 해결할 수 있지만 막대한 낭비를 초래합니다. 또한 자원 풀을 계획하는 것은 매우 번거롭고, 풀이 클수록 낭비가 많지만 풀이 너무 작아서 확장 요구를 충족하지 못할 수 있습니다.
리소스 비용에 대한 심층 분석
일부 개발자는 현재의 비즈니스 운영이 매우 안정적이며 사용자 트래픽이 갑작스럽게 증가하지 않는다고 생각할 수 있으므로 확장 및 축소는 유사 수요이며 향후 이러한 수요는 없을 것입니다. 확장이 전혀 필요하지 않기 때문에 인터넷 서비스에 대한 오해 일 수 있습니다.
첫째, 시스템이 사람들에게 서비스를 제공하는 한 볏과 골이 있어야합니다. 7 * 24 시간 실행되는 시스템의 경우 동일한 사용자 트래픽을 영구적으로 유지하는 것은 불가능하며 28 번째 원칙은 여전히 많은 비즈니스 시스템에 적용됩니다 (사용자 트래픽의 80 %가 시간의 20 %에 집중됨). 상대적으로 균형 잡힌 사용자 트래픽이있는 시스템의 경우에도 이른 아침에는 트래픽이 저조한데, 유휴 컴퓨팅 리소스를 추가로 해제하고 리소스 활용도를 높일 수 있으면 리소스 사용 비용을 크게 줄일 수 있습니다.
또한 프로덕션 환경에 비해 개발 및 테스트 환경은 용량 확장 및 축소에 대한 요구 사항이 더 시급합니다. 마이크로 서비스 애플리케이션 세트는 여러 팀에서 개발합니다. 이상적으로는 여러 팀이 테스트 환경 세트를 공유합니다.
그러나 각 팀은 애플리케이션 반복에 대한 고유 한 리듬을 가지게되며 동시에 팀 간의 상호 영향을 피하기 위해 환경 간의 격리를 달성하기 위해 독립적 인 종단 간 테스트 환경을 갖기를 원합니다. 이 경우 여러 테스트 환경이 형성 될 수 있습니다.
애플리케이션, 팀 및 비즈니스 기능 포인트의 수가 증가함에 따라 필요한 개발 및 테스트 환경의 수가 기하 급수적으로 증가하여 막대한 리소스 낭비가 발생합니다. 테스트 환경의 컴퓨팅 리소스의 경우 리소스 사용률이 프로덕션 환경보다 훨씬 낮습니다. 때로는 단순한 기능 점 검증 일뿐입니다. 종단 간 비즈니스 기능을 실행하고 팀 간의 상호 작용을 피하기 위해 모든 마이크로 서비스 응용 프로그램을 포함하는 새로운 환경이 열립니다. 이러한 자원 낭비는 많은 회사에서 수년 동안 해결되지 않은 문제입니다.
따라서 마이크로 서비스 아키텍처는 본질적으로 탄력적 확장에 대한 수요가 강합니다. 탄력적 확장 과정에서 단일 애플리케이션의 수평 적 탄력적 확장이든 전체 환경의 시작 및 중지이든 리소스 사용률은 최종 리소스 비용에 영향을 미칩니다. 결정적인 역할을합니다. 자원 활용도를 향상시킬 수있는 방법을 생각할 수 있다면 회사의 많은 자원 비용을 절약 할 수 있습니다. 우리가 주목해야 할 점은 대부분의 마이크로 서비스 애플리케이션의 리소스 사용률이 매우 낮다는 것입니다.
간단한 통계를 만들 수 있습니다. 5 분마다 모든 서버의 CPU 사용률을 내보내고 일 차원에 따라 평균을 계산하면 시스템 전체의 리소스 사용률 데이터를 이해할 수 있습니다. 개발 및 테스트 환경의 서버 자원도 통계에 포함되면 자원 활용률이 낮아질 수 있습니다.
서버리스 탐색
낮은 리소스 사용률의 근본 원인은 서버 기반 응용 프로그램 아키텍처에서 개발자가 여러 사용자 이벤트에 응답하기 위해 빌드 된 프로그램 패키지를 서버에 배포해야하기 때문입니다. 인시던트 대응의 적시성을 보장하려면 프로그램이 서버에 오랫동안 상주 할 수 있도록 허용하고 오버로드 및 서비스 충돌을 방지하기 위해 가능한 한 보수적으로 리소스를 계획해야합니다. 이 프로세스에서는 실제 부하가 시간에 균등하게 분산되지 않아 전체 리소스 활용도가 낮아집니다.
서버리스 기술의 출현은 리소스 활용도를 개선하기위한 새로운 아이디어를 제공합니다. 서버리스는 마이크로 서비스 아키텍처를 구축하고 관리하기위한 완전한 프로세스로, 개발자는 서버 리소스없이 직접 애플리케이션을 배포 할 수 있습니다. 타사에서 완전히 관리하고 이벤트에 의해 트리거되며 상태 비 저장 컴퓨팅 컨테이너에 존재한다는 점에서 기존 아키텍처와 다릅니다. 서버리스 애플리케이션을 구축한다는 것은 개발자가 서버 리소스를 관리 및 운영하지 않고도 제품 코드에 집중할 수 있다는 것을 의미하며, 인프라 구축없이 애플리케이션을 배포 할 수 있다는 의미입니다.
서버리스 기술에는 다양한 형태가 있으며, 가장 일반적인 형태는 Alibaba Cloud의 FC (Function Compute) 제품과 같은 FaaS (Function as a Service)입니다. 기능 컴퓨팅 분야에서는 모든 애플리케이션과 컴퓨팅 리소스의 스케줄링이 특정 비즈니스 이벤트에 의해 트리거되며 비즈니스 이벤트에 해당하는 작업이 완료되면 컴퓨팅 리소스가 즉시 해제됩니다. 이 방법은 실제로 컴퓨팅 리소스의 주문형 배포를 달성하고 리소스 활용도를 크게 향상시킬 수있는 서버리스 기술의 궁극적 인 형태입니다.
다른 하나는 서버리스 컨테이너 기술입니다. 서버리스 컨테이너 인스턴스는 대소 문자 분리 환경에서 실행됩니다. 각 컴퓨팅 노드는 경량 가상화 보안 샌드 박스 기술을 통해 완전히 분리됩니다. 사용자의 경우 서버 리소스를 구매하지 않고도 컨테이너 애플리케이션을 직접 배포 할 수 있으며, 클러스터에 노드 유지 관리 및 용량 계획이 필요하지 않으며 애플리케이션에서 구성한 CPU 및 메모리 리소스의 양에 따라 필요에 따라 지불 할 수 있습니다. 마이크로 서비스 애플리케이션을 확장해야하는 경우 서버 구매 단계를 거치지 않고도 컴퓨팅 리소스를 빠르게 확보 할 수 있으므로 개발자가 컴퓨팅 비용을 줄이고 유휴 리소스의 낭비를 줄이며 갑작스러운 최대 트래픽에 원활하게 대응할 수 있습니다. Alibaba Cloud의 서버리스 Kubernetes (ASK)는 서버리스 컨테이너 기술의 대표적인 제품입니다.
개발자의 요구 사항 더 알아보기
서버리스 기술은 클라우드 컴퓨팅 및 클라우드 네이티브 애플리케이션 아키텍처의 개발 방향이지만, FaaS 또는 서버리스 Kubernetes 형태이든 마이크로 서비스 애플리케이션 개발자에게는 특정 제한이 있습니다.
모든 비즈니스가 FaaS 구축에 적합하지는 않으며, 특히 긴 링크와 명백한 업스트림 및 다운 스트림 종속성이있는 애플리케이션의 경우 FaaS를 변환 할 방법이 없습니다. 일부 비즈니스 시스템의 FaaS 변환이 가능하다고 입증 되더라도 기존 마이크로 서비스 아키텍처를 FaaS 아키텍처로 변환하려면 일정량의 작업이 필요하며 원활하게 이식 할 수 없습니다.
서버리스 Kubernetes 아키텍처는 모든 비즈니스 시나리오에 적응할 수 있지만 개발자가 완전한 Kubernetes 시스템을 구축하려면 매우 가파른 학습 곡선이있는 Kubernetes와 관련된 일련의 복잡한 개념을 마스터해야합니다. 또한 네트워크 계층 및 스토리지 계층의 적응과 결합 된 Kubernetes 생태계의 다양한 구성 요소 구성에는 매우 복잡한 작업이 수반됩니다.
이러한 제한의 이유는 간단합니다 .Spring Cloud로 대표되는 마이크로 서비스 기술 캠프에서 시스템의 구성은 버전 업데이트 든 수평 확장이든 애플리케이션을 중심으로 구축됩니다 (단일 서비스로도 이해 가능). , 응용 프로그램 자체에 대한 모든 것. 서버리스 Kubernetes 아키텍처의 핵심은 Pod로, 애플리케이션보다 시스템 하단에 더 기울어 져 있으므로 사용자는 애플리케이션의 하위 수준 리소스 관리에 더 많은 에너지를 투자해야합니다. FaaS 아키텍처의 핵심은 기능에 있습니다. 기능은 애플리케이션보다 시스템의 상위 계층에 더 치우 치므로 유연성이 떨어지고 모든 비즈니스 시나리오에 적용 할 수 없습니다.
메인 스트림 Spring Cloud 시스템 또는 Dubbo 시스템을 사용하여 마이크로 서비스 애플리케이션을 구축하는 개발자의 경우 리소스 비용을 줄이기위한 솔루션을 도입해야하는 경우 그의 마지막 호소에는 두 가지 측면이 포함되어야합니다.
(1) 재건 비용이 0이거나 0에 가까울
수 있습니까 ? (2) 모든 비즈니스 시나리오에 적용 할 수 있습니다.
애플리케이션 계층 서버리스 기술
위에서 언급 한 중요한 요구 사항을 충족 할 수있는 FaaS와 서버리스 컨테이너 사이에 기술이 있습니까? 물론 이것은 Alibaba Cloud SAE (Serverless Application Engine)로 대표되는 애플리케이션 계층 서버리스 기술입니다.
(사진 설명 : 다양한 수준의 서버리스 기술)
SAE는 서버리스 아키텍처 + 마이크로 서비스 아키텍처의 완벽한 통합을 실현합니다 .Spring Cloud 및 Dubbo와 같은 메인 스트림 마이크로 서비스 아키텍처의 경우 기본적으로 변환 비용없이 원활하게 호환 될 수 있으며 실제로 온 디맨드로 사용되며 볼륨별로 청구되므로 유휴 상태를 절약 할 수 있습니다. 컴퓨팅 리소스, IaaS 계층 운영 및 유지 관리 작업을 제거하여 개발 운영 및 유지 관리의 효율성을 효과적으로 개선합니다.
Spring Cloud 애플리케이션을 예로 들어 새 애플리케이션을 배포해야하는 경우 두 단계 만 필요합니다.
(1) SAE에이 애플리케이션에 필요한 인스턴스 수를 알려주고 각 인스턴스에 필요한 CPU / 메모리 사양을 지정합니다.
(2) 애플리케이션의 JAR 패키지 / WAR 패키지를 업로드하고 애플리케이션을 시작합니다.
이 두 단계에는 용량 평가, 서버 구매, 운영 체제 설치, 리소스 초기화 등이 포함되지 않으므로 여러 피어 투 피어 인스턴스를 포함하는 마이크로 서비스 애플리케이션을 실행할 수 있습니다. 이는 서버리스 세계에서는 더 이상 서버 리소스의 개념이 없기 때문입니다. 애플리케이션의 캐리어는 SAE에서 예약 한 샌드 박스 컨테이너입니다. 각 인스턴스는 실제로 사용 된 후에 만 사용 기간에 따라 요금이 청구됩니다.
개발자의 경우 애플리케이션이 물리적 머신, 가상 머신 또는 컨테이너에 배포되는지 여부에 대해 신경 쓸 필요가 없습니다. 기본 운영 체제의 버전을 알 필요가 없습니다. 각 애플리케이션 인스턴스가 차지하는 컴퓨팅의 양에만주의하면됩니다. 자원은 할 것입니다. 애플리케이션을 4 개 인스턴스에서 6 개 인스턴스로 확장하거나 2 개 인스턴스로 축소해야하는 경우 하나의 명령으로 완료 할 수 있으며 SLB와의 바인딩 관계도 자동으로 설정하거나 해제 할 수 있습니다. 개발자가 가져 오는 큰 가치.
마이크로 서비스 애플리케이션을 배포하기 위해 SAE를 사용하면 애플리케이션의 캐리어 만 변경되므로 기존 기술 아키텍처 및 비즈니스 기능과 100 % 호환 될 수 있으며 마이그레이션 비용은 무시할 수 있습니다.
SAE의 궁극적 인 탄력성
수동 확장 및 축소 지침 외에도 SAE는 마이크로 서비스 애플리케이션을 수평으로 유연하게 확장하고 클라우드 컴퓨팅의 탄력성을 더욱 발휘할 수있는 두 가지 자동 탄력적 메커니즘을 지원합니다.
타이밍 탄력성 메커니즘 : 발생할 것으로 예상되는 주기적 동작에 대해 타이밍 탄력성 전략을 설정할 수 있습니다. 예 : 비즈니스 피크가 매일 오전 9시에있는 경우 매일 8:30에 인스턴스 수를 늘리고 매일 9:30에 인스턴스 수를 줄일 수 있습니다.
지표 임계 값에 기반한 탄력성 메커니즘 : 예상을 초과하는 비즈니스 트래픽의 갑작스런 증가에 대해 지표 임계 값을 기반으로하는 탄력적 전략을 설정할 수 있습니다. CPU, 메모리 및 QPS와 같은 비즈니스 지표와 같은 리소스 지표에 따라 애플리케이션이 자동으로 탄력적 축소를 달성 할 수 있습니다.
다양한 탄력적 메커니즘을 통해 시스템 용량을 세분화하여 관리 할 수 있으므로 비즈니스 트래픽의 변화에 따라 리소스 사용량을 조정할 수 있으므로 리소스 활용도를 크게 높이고 리소스 비용을 줄일 수 있습니다.
컴퓨팅 리소스의 예약 및 시작 측면에서 SAE는 여러 가지 최적화를 수행했습니다. 확장 된 새 인스턴스의 경우 단 몇 초만에 가져올 수 있습니다.이 기능은 긴급하고 빠른 확장이 필요한 긴급 시나리오에 유용합니다. 대단합니다.
개발 및 테스트 환경의 경우 SAE의 메커니즘 유연성이 더욱 생생하게 반영 될 수 있습니다 .SAE의 우수한 리소스 스케줄링 기능 덕분에 클릭 한 번으로 완전한 마이크로 서비스 애플리케이션 세트를 시작하고 중지 할 수 있습니다. 단순한 새 기능 만 연기에 대해 테스트하더라도 완전하고 격리 된 테스트 환경을 시작할 수 있습니다. 새로운 환경은 몇 초 만에 구축하고 신속하게 사용할 수 있으며 테스트 후 즉시 출시 할 수 있습니다. 비용면에서 새로운 환경을 사용하는 데 실제 시간이 매우 짧기 때문에 비용이 거의 들지 않습니다. 이것은 마이크로 서비스 애플리케이션 개발에서 다중 팀 협업에 대한 큰 변화입니다.
비용 분석
SAE는 자원의 실제 사용을 통해 지불하며 비용은 두 부분으로 구성되며 각 부분은 통계 결과 및 계산 방법에 따라 정산에 사용되며 청구서는 시간 단위로 차감됩니다. 각 응용 프로그램에서 사용하는 리소스 측정 방법은 다음과 같습니다.
애플리케이션 CPU 리소스 사용량 = ∑ 인스턴스 CPU 사양 × 해당 월의 실행 시간 (분), 즉, 애플리케이션의 모든 인스턴스에 대한 CPU 사양의 합계에 월의 실행 시간을 곱한 값입니다.
애플리케이션 메모리 리소스 사용량 = ∑ 인스턴스 메모리 사양 × 월 실행 시간 (분), 즉, 애플리케이션의 모든 인스턴스 메모리 사양 합계에 월 실행 시간을 곱한 값입니다.
CPU 부품의 가격은 0.0021605 위안 / 분 / 코어이고 메모리 부품의 가격은 0.0005401 위안 / 분 / GiB입니다. SAE는 또한 컴퓨팅 리소스를 도매 방식으로 사전 구매하는 것과 동일한 선불 리소스 팩을 제공합니다. 유효 기간 내에 사용하는 한 사용 비용을 추가로 절약 할 수 있습니다. 리소스 팩이 공제되면 시스템은 종량제 방식으로 자동 변경됩니다. 방법.
실제 사례를 사용하여 SAE가 마이크로 서비스 애플리케이션이 리소스 비용을 줄이는 데 어떻게 도움이되는지 더 자세히 이해하겠습니다. 마이크로 서비스 시스템에 87 개의 애플리케이션 인스턴스가 포함되어 있다고 가정합니다. 각 시간의 일일 평균 실행 시간은 8 시간이고 인스턴스 구성은 2 코어 + 4GiB + 20G 디스크입니다.
- 연간 및 월간 구독으로 ECS를 사용하여 애플리케이션 배포 : 컴퓨팅 C5 87 개를 구입해야합니다. 단일 장치의 월별 비용은 186 위안, 총 월별 비용은 16,146 위안입니다.
- 사용량에 따라 지불하는 ECS를 사용하여 애플리케이션을 배포합니다. 단일 유닛의 가격은 시간당 0.63 위안이며, 누적 사용량은 월 20,880 시간이며 총 비용은 13,154 위안입니다.
- SAE를 사용하여 애플리케이션 배포 : 연간 리소스 팩 75,000 위안, 하루 8 시간 실행되는 87 개의 인스턴스를 구매하고, 총 월간 비용 6,250 위안에 해당하는 리소스 팩 할당량 만 사용하면됩니다.
이 비교를 통해 SAE의 유연성을 합리적으로 실행할 수있는 한 마이크로 서비스 애플리케이션의 리소스 비용을 크게 줄일 수 있다는 결론을 내릴 수 있습니다.
추가 용량
운영 및 유지 관리 워크로드를 단순화하고 리소스 비용을 줄이는 것 외에도 SAE는 마이크로 서비스 애플리케이션을위한 일련의 추가 기능을 개선합니다. 이는 애플리케이션 계층 서버리스 기술이 개발자에게 제공하는 추가 가치입니다. 이러한 개발을 최대한 많이 사용할 수 있습니다. box-to-use 기능을 사용하면 마이크로 서비스 애플리케이션을 쉽게 구축 할 수 있습니다.
완전한 애플리케이션 수명주기 관리 : 애플리케이션이 SAE에서 호스팅 된 후 업데이트, 확장, 시작 및 중지, 삭제, 애플리케이션 시작 및 중지 모니터링과 같은 애플리케이션 수명주기 관리 작업을 수행 할 수 있습니다.
즉시 사용 가능한 등록 센터 : SAE는 Nacos 등록 센터의 상업용 버전과 함께 제공되며 무료로 사용할 수 있으며 직접 구축 할 필요가 없습니다. SAE에 배포 된 응용 프로그램과 다른 응용 프로그램이 서로를 검색하도록하는 것과 같은 특별한 요구 사항이있는 경우 MSE (마이크로 서비스 엔진) 제품에서 제공하는 레지스트리 또는 자체 구축 된 레지스트리를 사용할 수도 있습니다.
즉시 사용 가능한 구성 관리 센터 : SAE는 ACM (애플리케이션 구성 관리)의 구성 관리 기능을 통합하고 ACM을 사용하여 SAE에서 애플리케이션 구성을 중앙에서 관리 할 수 있습니다.
애플리케이션 수준 트래픽 보호 : SAE는 AHAS를 통합하여 애플리케이션 수준 흐름 제어 및 성능 저하 기능을 달성하고 높은 애플리케이션 가용성을 포괄적으로 보장합니다.
모니터링 기능 : 애플리케이션이 SAE에서 호스팅 된 후에는 기본 리소스 (CPU, 메모리,로드 및 네트워크 포함)와 애플리케이션 계층에서 모니터링 기능 (JVM 분석, 인터페이스 호출 분석 등 포함)을 무료로 얻을 수 있습니다. 고급 SQL 분석, 예외 분석, 업스트림 및 다운 스트림 링크, 인터페이스 스냅 샷이 필요한 경우 Alibaba Cloud 애플리케이션 시간 모니터링 제품 (ARMS)을 통합 할 수 있습니다.
CI / CD 통합 기능 : SAE는 CloudEfficiency, CloudEfficiency 2020, Jenkins 등과 같은 제품과 심층적으로 통합되어 개발자가 구축 한 애플리케이션을 신속하게 배포 할 수 있습니다.
다국어 지원
Java 이외의 언어로 작성된 애플리케이션 또는 Spring Cloud와 같은 마이크로 서비스 프레임 워크를 사용하지 않는 Java 애플리케이션의 경우 SAE가 완벽한 지원을 제공하고 기업이 리소스 비용을 절감하도록 도울 수 있습니까?
물론 가능합니다. SAE는 컨테이너 이미지 배포 방법을 제공합니다. 즉, 어떤 프로그래밍 언어를 사용하든 최종 애플리케이션을 컨테이너 이미지로 게시 할 수있는 한 SAE에 배포 할 수 있습니다.
Java 기반 마이크로 서비스 애플리케이션, Java 시스템의 일반 애플리케이션 및 비 Java 기반 애플리케이션의 경우 서버리스 기술을 통해 시스템 리소스 활용을 제공 할 수있는 SAE의 극도의 유연성에는 근본적인 차이가 없습니다. 무료 마이크로 서비스 레지스트리와 같이 SAE에서 제공하는 부가 가치 중 일부는 Spring Cloud 또는 Dubbo 애플리케이션 만 제공 할 수 있습니다.
요약하자면
이 그림을 사용하여 서버리스 기술의 큰 가치를 검토해 보겠습니다.
일반적인 문제 :
1. 질문 : 응용 프로그램 인스턴스에 고정 된 컴퓨터 리소스가없고 고정 IP 주소도 없습니다. 문제 해결을 위해 서버에 SSH를 연결하는 방법은 무엇입니까?
답변 : 문제 해결을 위해 고정 된 컴퓨터 리소스와 고정 된 IP 주소가 필요하지 않습니다. 클라우드 컴퓨팅 시대에 SSH를 통해 컴퓨터에 로그인하여 문제를 해결하는 것은 좋은 방법이 아닙니다. 반대로 SAE는 완전한 모니터링 기능을 제공하며 클라우드 모니터링 및 ARMS와 같은 차세대 모니터링 및 진단 제품과 쉽게 통합 될 수있어 문제 해결에 더 큰 편의를 제공합니다. 물론 특정 컴퓨터에 로그인해야하는 경우에도 SSH는 계속 지원되며 SAE에서 제공하는 Webshell 도구를 사용하여이 프로세스를 단순화 할 수도 있습니다.
2. Q : 디스크는 청구 차원이 아닙니까? 애플리케이션에 대용량 디스크가 필요한 경우 어떻게합니까? 애플리케이션이 다시 시작된 후에도 플래시 드라이브의 데이터가 유지됩니까?
답변 : 마이크로 서비스 분야에서 애플리케이션은 일반적으로 상태 비 저장이며 많은 양의 로컬 데이터를 저장할 필요가 없습니다. 특별한 시나리오에서이 요구 사항 없이는 할 수없는 경우 NAS를 통합하고 중앙 집중식 스토리지를 사용할 수 있습니다.
3. Q : 애플리케이션 로그를 확인하는 방법은 무엇입니까?
답변 : SAE 콘솔 인터페이스는 파일 로그에 대한 실시간 액세스를 제공하며 이는 무료로 분산 로그 수집 플랫폼을 제공하는 것과 같습니다. 물론 애플리케이션 로그의 가치를 더욱 발전시키기 위해 Alibaba Cloud Log Service (SLS) 제품에 연결하는 것이 좋습니다.
코스 추천
더 많은 개발자가 서버리스의 이점을 누릴 수 있도록 이번에는 10 명 이상의 Alibaba 서버리스 기술 전문가를 모아 개발자가 시작하기에 가장 적합한 서버리스 공개 과정을 만들었습니다. 클라우드 컴퓨팅-서버리스의 새로운 패러다임을 수용하십시오. 무료로 과정을 배우려면 링크를 클릭하십시오 : https://developer.aliyun.com/learning/roadmap/serverless
서버리스 공식 계정 은 서버리스 기술에 대한 최신 정보를 공개하고, 서버리스 기술의 가장 완전한 콘텐츠를 수집하고, 서버리스 트렌드에주의를 기울이고, 실무에서 발생하는 혼란과 문제에 더 많은주의를 기울입니다.
원본 링크 : https://developer.aliyun.com/article/776579?
저작권 성명 : 이 기사 의 내용은 Alibaba Cloud 실명 등록 사용자가 자발적으로 기고 한 것입니다. 저작권은 원저자에게 있습니다. Alibaba Cloud 개발자 커뮤니티는 저작권을 소유하지 않으며 해당 법적 책임을지지 않습니다. 특정 규칙은 "Alibaba Cloud 개발자 커뮤니티 사용자 서비스 계약"및 "Alibaba Cloud 개발자 커뮤니티 지적 재산 보호 지침"을 참조하십시오. 이 커뮤니티에 표절이 의심되는 경우 침해 신고 양식을 작성하여 신고하세요. 확인되면 커뮤니티에서 침해 의심 콘텐츠를 즉시 삭제합니다.