레벨 7 리버스 에이전트: HTTP 리버스 프록시는 최외곽에서 사용자의 HTTP 요청에 응답하고 분석 후 백엔드 웹 서비스 풀로 전달되어 로드 밸런싱, 상태 점검 등의 기능을 제공합니다.
서비스 라우터: 요청의 고유 식별자에 따라 해당 웹 서비스 풀 및 해당 하드웨어 경로에 (O( 1) 시간 복잡도) 를 신속하게 매핑하는 논리적 계층입니다. 매핑 관계가 존재하지 않거나 오류가 발견되면 적절한 오류 프롬프트가 표시됩니다. 이 계층은 사용자에게 많은 구체적인 주소 정보를 숨기므로 개발자는 서비스의 실제 내부 분포에 신경 쓸 필요가 없습니다.
웹 서비스 풀: 특성이 다른 여러 웹 서비스 풀로 구성됩니다. 각 웹 서비스 풀은 실제로 서로 다른 SLA 에 따라 다양한 수준의 서비스를 제공하는 Apache(PHP) 세트로 구성됩니다. 각 웹 서비스 프로세스는 실제로 사용자의 HTTP 요청을 처리하고, 프로세스는 HTTP 서비스 샌드박스에서 실행되며, SAE 샌드박스에서도 실행되는 PHP 구문 분석 엔진을 포함합니다. 사용자 코드는 마지막으로 인터페이스를 통해 다양한 서비스를 호출합니다.
통계 센터& 로그 센터: 사용자가 사용하는 모든 서비스에 대한 통계 및 자원 부과를 담당하고, 비정상적인 사용 여부를 확인하기 위한 분 한도를 설정합니다. 분 할당량은 자원 소비 속도를 설명합니다. 자원 소비 속도가 경보 임계값에 도달하면 SAE 알림 시스템은 사용자에게 서비스 사용에 문제가 있을 수 있으며 주의를 기울이거나 처리해야 한다는 경고를 미리 보냅니다. 할당제는 SAE 가 전체 플랫폼의 안정성을 보장하는 데 사용하는 조치 중 하나입니다. 로그 센터는 모든 사용자 서비스에 대한 로그를 수집 및 백업하고 검색 및 쿼리 서비스를 제공합니다.
다양한 분산 서비스: SAE 는 사용자가 StdLib (SAE PHP 버전으로 이해할 수 있는 STL) 를 통해 쉽게 호출할 수 있는 웹 어플리케이션 개발의 주요 측면을 포괄하는 다양한 서비스를 제공합니다. 동시에, 웹 서비스의 다양성 때문에 SAE 의 표준 서비스는 모든 시나리오의 요구를 충족시킬 수 없으므로 SAE 는 서비스 버스를 통해 타사 서비스 (예: 분사, 전체 텍스트 검색) 를 연결하고 SAE 는 타사 서비스 공급자가 개발자에게 서비스를 제공하기 위해 SAE 를 선택하는 것을 환영합니다.
실제 사용자 코드는 SAE 에서 제공하는 웹 실행 환경에서 실행됩니다. 공용 클라우드 컴퓨팅에 고유한 보안을 제공하기 위해 SAE 는 다중 계층 샌드박스를 설계하여 사용자 애플리케이션 간의 격리를 보장합니다. 다음 그림을 참조하십시오.
맨 안쪽 계층은 사용자 코드이며 대부분의 PHP 코드는 수정 없이 SAE 플랫폼에서 실행할 수 있습니다. SAE 의 플랫폼 기능을 수용하기 위해 코드의 작은 부분을 수정해야 합니다. 이는 SAE 가 보안을 위해 로컬 IO 를 비활성화했기 때문에 TmpFD 를 사용하여 로컬 임시 파일을 읽고 쓰거나 스토리지 서비스를 통해 분산 파일 저장소를 직접 읽고 쓰도록 fwrite 와 같은 함수를 수정해야 하기 때문입니다.
PHP Zend 는 표준 PHP 공식 인터프리터입니다.
SAE Zend 샌드박스는 사용자의 코드 작업을 잘 분리할 수 있는 논리적 개념입니다. 여기에는 두 가지 수준이 있습니다.
1, 표준 php.ini 를 통해 몇 가지 특수 구성 및 비활성화 기능을 설정했습니다.
2. php.ini 가 실현할 수 없는 일부 샌드박스 기능을 구현하기 위해 Zend 인터프리터 코어를 일부 개선하여 사용자 ID 로 리소스를 격리했습니다. 또한 Zend 계층에 SAE 별 서비스를 통합했습니다.
아파치는 표준 아파치 웹 서버입니다. 그러나 htaccess 를 비활성화하고 자체 대안인 AppConfig 를 제공했습니다. 사용자는-compress: if (out _ header [content-length] >; = 500) compress 는 조건부로 페이지 압축을 시작한다는 의미입니다. AppConfig 는 디렉토리 기본 페이지, 사용자 정의 오류 페이지, 압축, 페이지 리디렉션, 페이지 만료, 응답 헤더의 컨텐츠 유형 설정, 페이지 액세스 설정 등의 기능을 제공합니다. AppConfig 를 직접 구현하기로 선택한 또 다른 이유는 기존 Apache htaccess 의 효율성이 SAE 의 요구 사항을 충족하지 못하기 때문입니다. 디렉토리별로 구성 파일을 재귀적으로 통합해야 하기 때문입니다.
HTTP 서버 샌드박스는 Apache 의 안전하고 신뢰할 수 있는 운영을 위한 다양한 보호 기능을 제공합니다. 예를 들어, 한 사용자의 악의적인 접속 점유로 인해 전체 웹 서비스 예외가 발생하는 것을 방지합니다.
최외층은 표준 POSIX 환경이며, Dell 서비스는 Linux 에서 실행됩니다.
그런 다음 건축 설계의 특성에 대해 자세히 논의 할 것입니다.
측정 가능성
확장성은 분산 시스템의 두 가지 주요 목적 중 하나입니다. SAE 는 공용 클라우드 컴퓨팅으로서 서비스 확장성을 아키텍처 설계의 중요한 지표로 사용하여 사용자가 증가하고 스트레스가 증가할 때 서비스를 자동으로 확장할 수 있도록 합니다. 마찬가지로 스트레스가 줄어들면 서비스를 계약하고 자원을 절약할 수 있으며 전체 프로세스에 수작업이 필요하지 않습니다. SAE 노동력은 생산능력을 계획하고 관리하기만 하면 된다. 해외에서 공용 클라우드 컴퓨팅 아키텍처를 확장하는 두 가지 주요 방법이 있습니다.
정적 확장, 사용자 및 자원은 강력한 바인딩 관계를 가지고 있습니다. 가장 전형적인 예는 아마존의 EC2 와 Ruby 클라우드 컴퓨팅 플랫폼인 Heroku 입니다. 사용자가 신청한 자원은 사용자와 엄격한 일대일 대응 관계를 가지고 있다. 즉, 사용자 A 의 가상 시스템이 유휴 상태이더라도 사용자 A 가 리소스를 반환할 때까지 사용자 A 가 요청한 가상 시스템을 사용자 B 가 사용할 수 없습니다.
동적 확장, 사용자와 자원 간에 강한 바인딩 관계가 없습니다. 가장 전형적인 예는 Google App Engine 입니다. 사용자가 신청한 자원과 사용자 사이에는 엄격한 일대일 대응 관계가 없다. 즉, 사용자 A 의 요청을 처리하는 프로세스는 사용자 B 의 요청을 처리한 직후에 처리할 수 있습니다.
두 확장 모두 장점과 단점이 있습니다. 정적 확장의 장점은 플랫폼에 대한 좋은 격리를 제공하며, 리소스를 한 사용자에게 매핑할 수 있다는 것입니다. 단점은 자원 활용도가 낮다는 것입니다. 동적 확장의 장점은 리소스 사용률이 높기 때문에 전체 클라우드 컴퓨팅 플랫폼의 비용은 매우 낮고, 짧은 시간 내에 여러 사용자가 리소스를 사용할 수 있기 때문에 높은 격리성이 필요하다는 점입니다. 대조적으로, 보안 측면에서 동적 확장의 기술적 한계점은 정적 확장보다 높습니다.
SAE 플랫폼에서는 동적 확장과 정적 확장을 결합한 방식을 사용합니다. 웹 컴퓨팅 풀 계층에서 일반적인 동적 확장입니다. 한 사용자도 웹 서비스 프로세스를 독점하지 않지만 모든 사용자는 * * * 방식으로 웹 서비스 프로세스를 사용합니다. 캐싱을 통해 핫 사용자는 자연스럽게 캐시 계층에서 더 많은 위치를 차지합니다. SAE 의 일부 서비스에서 확장성은 RDC (관계형 데이터베이스 클러스터) 분산 데이터베이스 클러스터와 같은 정적 확장으로 나타납니다. 사용자가 MySQL 서비스를 요청하면 SLA 수준에 따라 RDC 백엔드에 사용자를 위한 마스터-슬레이브 DB 를 만듭니다. 이 DB 는 사용자가 명시적으로 삭제할 때까지 다른 사람이 사용하지 않습니다. 물론 RDC 를 사용하면 백엔드 DB 의 실제 주소를 알 필요가 없으며 RDC 의 통합 호스트 및 포트만 액세스하기만 하면 됩니다.
높은 신뢰성
HA 는 분산 시스템의 또 다른 주요 목적이며 SAE 는 서비스의 높은 신뢰성을 아키텍처 설계의 중요한 지표로 제공합니다. HA 를 구현하는 방법에는 두 가지가 있습니다. 하나는 하드웨어 보증이고, 다른 하나는 아키텍처의 중복 설계입니다.
SAE 플랫폼의 모든 서버는 시나닷컴에서 구매한 하드웨어 장비로, 국내 최고의 기계실에서 운영되며, 여러 기계실에서 재해를 방지하고, 네트워크 자원 방면에서 포털이 사용하는 대역폭 환경을 누리고 있습니다. 또한 모든 하드웨어 장비에는 신랑 내부 서비스와 동일한 오류 응답 속도를 가진 전용 운영 및 유지 관리 부서가 있습니다.
아키텍처 설계에서 SAE 는 모든 서비스에 대한 중복 설계를 통해 높은 신뢰성을 제공하는 서비스를 제공합니다. 여기서 서비스는 계산과 데이터의 두 가지 범주로 나눌 수 있습니다.
계산 프로그램의 경우 중복 설계는 프로그램이 여러 노드에서 실행됨을 의미합니다. 그러나 이로 인해 일관성 문제가 발생할 수 있습니다. 가장 중요한 문제는 선거 문제입니다. 여러 노드 중 하나의 마스터 노드를 선택하여 이를 수행하는 방법입니다. 예를 들어, SAE 의 분산 타이밍 서비스 Cron, 멀티 포인트 배포 모드, 여러 컴퓨팅 노드가 서로 격리되어 클럭 동기화 서비스를 통해 사용자가 설정한 타이밍 작업을 동시에 트리거합니다. 단 하나의 노드만 실행하면 됩니다. 이 문제를 해결하기 위해 SAE 는 선거 서비스를 제공하기 위해 분산 잠금 알고리즘을 설계했습니다. 이 알고리즘은 일정한 조건 하에서 일관성을 희생하는 대가로 Paxos 알고리즘보다 더 높은 신뢰성을 제공할 수 있습니다. 두 대의 시스템에 세 대의 시스템 장애가 발생하더라도 전체 선거 과정은 여전히 정상적이며, Paxos 알고리즘은 최대 1 대의 시스템을 용인할 수 있습니다. 20 12, 12 까지 이 알고리즘은 특허를 출원하고 있으며 SAE 에서 널리 사용되고 있습니다.
데이터 기반 서비스의 경우 SAE 는 주로 복제를 통해 서비스의 높은 신뢰성을 보장합니다. SAE 의 데이터 스토리지 서비스는 일반적으로 수동 복제와 사전 예방적 복제를 사용합니다. 예를 들어 SAE 의 MySQL 간 마스터-슬레이브 Binlog 동기화는 일반적인 수동 복제이며 TaskQueue, DeferredJob 등의 서비스도 수동 복제를 사용합니다. 사용자의 작업 설명은 기본 메모리 레벨 대기열에 기록되고, 기본 대기열은 백그라운드 스레드를 사용하여 쓰기 작업을 슬레이브 대기열에 동기화합니다. 기본 대기열에 장애가 발생하면 대기열에서 기본 대기열로 빠르게 전환됩니다. 또한 SAE 의 일부 서비스는 Cron 과 같은 HA 를 보장하기 위해 사전 예방적 복제 (이중 쓰기 복제) 를 사용합니다. 사용자가 App 의 엔지니어링 구성 파일 appconfig.yaml 을 통해 예약된 작업을 설정하면 후속 트리거를 위해 작업 정보가 여러 영구 DB 에 이중 쓰기로 기록됩니다.
또한 SAE 는 전체 아키텍처를 설계할 때 서비스 간의 "우아한 성능 저하" 를 충분히 고려하여 서비스 간의 커플링을 최소화합니다. 우리는 어떤 서비스도 다른 서비스가 믿을 만하다고 가정해서는 안 된다고 요구한다. SAE 플랫폼의 모든 서비스에는 단일 포인트 설계가 없으며, 서비스의 평균 HA 는 99.95% 입니다. 즉, 연간 평균 서비스 이용 불가 시간은 4 ~ 5 시간 사이입니다.
회로 특성
플랫폼 익스포트 IP:
220.181..129.126
220.181.129.121
220.181..136.229
220.181..136.230
Http 인터페이스는 그에 따라 설정할 IP 인증이 필요합니다.