위 사진은 텐센트의 그레이스케일 버전으로, 일반 사용자는 접속할 수 있고, 알리바바 클라우드 서버에 접속할 수 없으며, 핑도 정상이고 해상도 IP도 정상입니다
접근하기 어렵고, 텐센트가 그레이스케일 릴리스 방식을 선호하는 것도 보입니다...
1. 왜 그레이스케일 릴리스인가
- 인터넷 서비스는 자주 변경되며 출시 주기가 짧습니다. 속도와 품질을 결합하기는 항상 어렵습니다.
- 그레이스케일 출판은 출판 위험을 줄이고 영향 범위를 줄일 수 있습니다.
- 테스트 의존도를 줄이고 오프라인 자가 테스트를 위한 데이터 구축 비용을 절감합니다.
- 로그를 중앙에서 모니터링하고 전체를 게시하는 것이 편리합니다. 각 계층에서 부하 분산 역할을 하기 때문에 전체 통화 링크를 추적하기가 어렵습니다.
- 그레이스케일 테스트 계정을 사용하고, 테스트 계정이 통과되면 그레이스케일 실제 사용자 계정을 사용해 게시의 위험과 영향을 더욱 줄일 수 있습니다.
- 간단한 롤백.
그레이스케일 릴리스로는 해결할 수 없는 문제들
위에서 언급한 '허용 가능한 영향'은 복구 가능해야 한다는 점을 강조해야 합니다. 예를 들어, API를 일정 기간 호출할 수 없지만 복구 후에는 성공적으로 호출할 수 있습니다. 사용자 데이터(예: 제품 정보, 주문 정보 등)의 영구적인 손실이나 파괴는 용납할 수 없습니다. 따라서 인터넷 기업의 설계자는 운영 시스템 문제(예: 정기적인 사용자 데이터 백업, 작업 로그 작성 등)로 인해 사용자 데이터가 손실될 경우 수동 개입을 통해 손실된 사용자 데이터를 최근 상태(예: 1시간 전에서 1주 전)로 복구할 책임이 있습니다.
팁: 계정의 그레이스케일 정책을 먼저 테스트하여 실제 사용자의 데이터 손상이나 손실 위험을 줄이세요.
2. 어떤 효과가 예상되는가?
변경 내용과 상관없이, 특정 요청은 관찰과 검증을 위해 변경 버전(그레이스케일 버전)으로 라우팅되길 원합니다.
3. 그레이스케일 전략
사실, 요청이 우리 그레이스케일 버전(그레이스케일 기계)으로 라우팅되어야 합니다. 이는 종종 비즈니스와 밀접하게 연관되어 있습니다. 예를 들어, API의 경우 일반적으로 다음과 같은 요구사항이 있습니다:
특정 사용자(예: 테스트 계정)
특정 앱(예: 테스트 앱이나 파트너 앱)
특정 모듈과 인터페이스(일부 인터페이스만 그레이스케일이 필요하며, 이는 일반적으로 API 컨테이너를 변형한 것이고, 중요하지 않은 API는 그레이스케일 테스트에 사용됩니다). ）
특정 기기 (일부 요청 IP가 그레이스케일 기기로 전달됨)
4. 그레이스케일 스킴에 대한 논의
해결책 1: 코드 레벨은 합의된 플래그로 판단되고, 기존 플래그와 신 플래그가 동적으로 전환됩니다 - 아마존의 접근 방식
구현:
스위치를 코드에 묻고, if-else 판단을 한 뒤, 회색 스케일이 필요한 기계에서는 스위치를 켜고, 그렇지 않으면 꺼둡니다. 각 릴리스마다 두 가지 버전이 있습니다.
장점
빠른 롤백 기능이고, 시스템을 재게시하거나 재부팅할 필요가 없습니다.
결점
규정에 익숙해지세요.
분기 논리는 복잡성을 가져옵니다.
이 방법은 제가 알리바바에 있을 때 저자가 사용했는데, 상품 데이터베이스를 오라클에서 MySQL로 전환하고 상태 변수를 제어하는 방식이었습니다. 이로써 원활한 이동 효과를 달성했습니다.
옵션 2: 사전 출시 기계 - 알리바바의 관행
사실, 이것은 진정한 의미의 그레이스케일이 아닙니다. 이 사전 출시 기기는 내부 IP이고 외부 서비스가 없기 때문입니다. 검증을 위해서는 도메인 바인딩이 필요합니다. 하지만 데이터는 완전히 온라인에 있습니다. 즉, 본질적으로 그레이스케일의 특정 사용자들(그레이스케일 머신에 접근할 수 있는 사용자, 내부 테스트 사용자)을 위한 간단한 접근법입니다. 사실 API 쪽에도 유사한 접근법이 있는데, 이는 저희의 Gamma 환경이며, 외부 협력 사용자들이 테스트에 협력할 수 있도록 Gamma 머신의 도메인 이름도 제공합니다.
장점
간단합니다
결점
머신 폐기(사전 릴리스가 완료된 후 운영 환경에 투입할 수 있고, 사전 릴리스 기간 동안 nginx에서 제거할 수 있지만, 운영 및 관리 지원이 필요합니다.) ）
유연성이 부족합니다
IDL 서비스는 액세스 계층 기기에서만 사용할 수 있으며, IDL 서비스는 별도로 고려해야 합니다.
옵션 3: SET 배치
1. 군별로 분리하여 배치
예를 들어, 현재 API 컨테이너 관행에서는 배포의 세분성을 API 수준까지 도달할 수 있고, 프론트엔드는 nginx에 따라 앞으로 나아갈 수 있습니다. 예를 들면:
마이크로쇼핑 API 컨테이너: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API 컨테이너: api.yixun.com
온라인 쇼핑 API Container:api.buy.qq.com
위 내용은 대규모 비즈니스 수준에서의 고립된 배포입니다. 또한 가상 서비스 전자상거래의 API처럼 Paipai 아래에 있는 하위 비즈니스 모듈인 모듈 수준으로도 더 정교화할 수 있습니다. 하지만 위챗과 연결되어 있어 방문자 수가 크게 증가했습니다. Paipai의 다른 사업에 영향을 주지 않기 위해, 그리고 다른 사업에 영향을 받지 않도록 API는 두 대의 기기를 별도로 배포하는 것이고, nginx는 가상 API 접근을 소모하도록 설정할 수 있습니다:
가상 API 컨테이너: http://api.paipai.com/v2/virbiz
이렇게 하면 버전을 출시할 때 먼저 가장 작은 거래량을 가진 Yixun을 선택해 게시하고, 그 후 모든 다른 플랫폼을 사용하기 전에 문제가 없다는 것을 확인할 수 있습니다.
2. 사용자 격리에 따른 배포
이 방식은 오픈 플랫폼에는 적합하지 않지만, SNS와 같은 응용 시나리오에는 매우 적합합니다. 예를 들어, QQ 시스템은 사용자 번호 구간에 따라 여러 세트로 나뉘며, 각 세트에는 1억 개의 연속된 번호가 포함되어 있습니다. 최신 QQ 숫자가 10억에 가까워 있다고 가정하면, 총 10개의 집합이 있습니다(Set 1에서 Set 10까지). 이렇게 하면 매번 SETS 중 하나를 선택할 수 있고, 고급 QQ는 보통 중요한 사용자가 아니기 때문에 SET10이 먼저 공개됩니다.
장점
사업 라인 전반에 걸쳐 최소한의 영향으로 고립된 배포. 그레이스케일 퍼블리싱을 자동으로 지원합니다.
결점
그레이스케일의 세분성은 일반적으로 큰 고립된 전개 세분성에 따라 달라집니다.
중앙집중식 배포에 비해 기계 낭비가 더 큽니다.
각 사업 라인의 버전이 일관성이 없어 통합 관리에 적합하지 않을 수 있습니다.
구현 및 배포 비용이 일부 발생합니다
스킴 4: 동적 라우팅
방법: 부하 분산 동작에 영향을 주고, 그레이스케일 정책에 따라 IP와 포트를 반환할 수 있도록 유연하게 설정할 수 있는 그레이스케일 정책을 사용하세요.
백오피스 IDL이 있는 서비스 그레이스케일에 적합합니다.
장점
유연하고, 통제 가능해.
결점
현재 구성 센터와 L5 자체는 지정된 라우팅 정책을 고려하지 않으며, 확장성이 없으므로 해당 정책들 외부에서 개발되어야 합니다.
API의 메타데이터 소스는 상대적으로 분산되어 있으며, 현재 API 및 IDL 메타데이터, API 수준 및 빈도 제한이 서로 다른 데이터 소스에 분산되어 있어 이제 그레이스케일 라우팅 데이터 소스를 추가해야 합니다.
일반적으로 그레이스케일 nginx+lua를 게시하는 방법은 세 가지가 있으며, nginx는 쿠키에 따라 배포되고, nginx는 가중치에 따라 할당됩니다:
nginx+lua는 방문자의 IP 주소에 따라 구분하는데, 이는 회사가 IP 주소를 내보내기 때문에 웹사이트에 접속하는 이전 버전이나 새 버전 중 하나로 접속되기 때문이며, 이는 이 방법에 적합하지 않습니다
nginx는 가중치를 기반으로 가중치를 할당하는데, 구현이 간단하고 시도해볼 수 있습니다
nginx는 쿠키를 기준으로 분할하고, 그레이스케일은 사용자 기준으로 발행합니다
|
게시됨 2017. 3. 9. 오후 3:48:27
|
|
|
|
