1. 실패는 어디에나 있다
통계적으로 말하면 대규모 실패는 피할 수 없는 사건이 됩니다.
따라서 마이크로서비스 시스템을 설계하고 구현할 때 시스템의 가용성을 최대한 보장하기 위해 가능한 많은 실패 요인만 고려하면 됩니다.
2. 기능 다운그레이드
마이크로 서비스 시스템은 함께 작동하는 여러 서비스로 구성됩니다. 서비스가 다운되면 시스템이 외부에서 어떻게 작동하는지 고려해야 합니다. 예를 들어 쇼핑몰 시스템의 장바구니 서비스가 다운됩니다. 이때 우리는 이용자가 계속해서 상품을 열람하거나 쇼핑몰 홈페이지를 "시스템 점검"으로 설정할 수 있나요? 이것은 비즈니스 컨텍스트와 결합하여 결정을 내려야 합니다.일반적으로 서비스가 중단된 후 전체 시스템을 사용할 수 없도록 설정하지 않고 적절하게 처리하며 일부 기능은 계속 사용할 수 있습니다.물론 이것은 필요합니다. 우리의 디자인에서 고려됩니다.
3. 안티프래질 접근법
- 타임아웃, 타임아웃은 간과하기 쉬운 부분인데, 다른 서비스를 호출할 때 타임아웃을 정확하게 설정하는 것이 중요합니다.
- 회로 차단기, A 서비스가 B 서비스를 호출할 때 항상 시간이 초과되거나 실패(특정 횟수에 도달)하면 회로 차단기가 열리고 후속 요청은 빠르게 실패합니다. 다운스트림 서비스가 복원되었는지 여부에 따라 올바르게 응답하면 회로 차단기가 재설정됩니다.
- 격벽 모드는 실패로부터 자신을 격리하는 방법입니다. 선박에서 격벽은 닫힐 때 선박의 나머지 부분을 보호하는 선박의 일부입니다. 소프트웨어 아키텍처 분야에는 각 서비스에 대해 서로 다른 연결 풀을 사용하는 것과 같이 사용할 수 있는 다양한 "격벽"이 있으므로 연결 풀이 소진되면 다른 서비스의 호출 요청에 영향을 주지 않고 회로 차단기 또한 일종의 격벽에 속합니다.
4. 멱등성
idempotent 작업의 경우 여러 실행의 영향은 한 번의 실행의 영향과 같습니다. 작업이 멱등적이면 부작용에 대한 두려움 없이 반복적으로 호출할 수 있습니다. Idempotent는 작업이 실행되었는지 확실하지 않고 작업을 다시 실행하려는 경우에 매우 유용합니다.
예를 들어 HTTP GET 및 PUT은 HTTP 사양에서 idempotent로 정의되어 있으므로 이러한 API를 정의할 때 사양을 엄격하게 준수해야 합니다.
5. 확장
확장의 목적은 시스템의 전반적인 성능과 안정성을 향상시키는 것입니다.
- 더 강력한 호스트 사용
- 로드 분할, 즉 호스트를 사용하여 서비스를 실행하는 경우 호스트는 일반적으로 가상 호스트를 나타냅니다.
- 하나의 바구니에 넣지 마십시오. 서비스를 분할하여 여러 가상 호스트를 실행하더라도 모두 하나의 물리적 호스트에 있으므로 여전히 많은 위험이 있습니다. 따라서 다른 데이터 센터에서 서비스를 계속 실행하십시오.
- Nginx와 같은 로드 밸런싱은 시스템 처리량과 안정성을 향상시킬 수 있습니다.
- 재설계를 위해서는 초기 시스템이 완벽하지 않고 처리할 수 있는 동시성이 제한적이므로 더 많은 부하가 예상되는 경우 재설계를 고려해야 합니다.
6. 데이터베이스 확장
- 확장된 읽기 많은 비즈니스 시나리오는 읽기 지향적이며 캐시 또는 읽기 전용 복제본을 사용하여 읽기 성능을 확장할 수 있습니다. Mysql과 Postgresql에는 이 기능이 있지만 이런 방식의 복제본 데이터는 실시간이 아닐 수 있지만 최종 일관성이 있음을 알아야 합니다.
- 확장된 쓰기는 확장된 읽기보다 어렵습니다.한 가지 방법은 mongodb와 같은 샤딩을 사용하는 것입니다.샤딩을 사용할 때의 문제점은 샤드를 추가할 때 발생할 수 있는 데이터베이스 다운타임입니다. 사전 테스트.
7. 캐싱
성능 최적화를 위해 일반적으로 사용되는 방법으로, 이전 작업의 결과를 저장함으로써 후속 요청에서 값을 다시 계산하는 데 시간과 리소스를 소비하지 않고 저장된 값을 재사용할 수 있습니다.
- 클라이언트 측 캐싱의 경우 클라이언트는 새 데이터를 요청할 시기와 여부를 결정하고 서버는 클라이언트가 결정을 내리는 데 도움이 되는 해당 프롬프트를 제공합니다.
- 프록시 서버 캐시, 클라이언트와 서버 사이에 프록시 서버를 추가합니다. 리버스 프록시와 CDN이 좋은 예입니다.
- redis 및 memcache와 같은 서버 캐시 또는 서비스 프로세스 캐시.
어떤 캐싱 방법을 선택할지는 최적화하려는 대상에 따라 달라집니다.클라이언트 측 캐싱은 네트워크 호출 수를 크게 줄일 수 있으며 다운스트림 서비스에 대한 부하를 줄이는 가장 빠른 방법 중 하나이지만 이러한 방법으로 변경하려는 경우 캐시하는 방식, 많은 수의 클라이언트에서 모든 변경을 수행하는 것은 매우 어렵습니다. 프록시 서버가 캐시하는 방식에 대해 클라이언트와 서버 모두에게 모든 것이 불투명하지만 일반적으로 기존 시스템에 캐시를 추가하는 매우 간단한 방법입니다. 서버 측 캐싱 방식의 경우 클라이언트에게 모든 것이 불투명하므로 캐시 적중률을 쉽게 추적하고 최적화할 수 있습니다.
- HTTP 캐싱, HTTP는 클라이언트 또는 서버 측에서 캐시하는 데 도움이 되는 매우 유용한 제어 수단을 제공합니다.
- 먼저 응답 헤더에 "cache-control" 지시어를 추가하여 리소스를 캐시해야 하는지 여부와 기간을 클라이언트에 알릴 수 있습니다. CSS 및 이미지와 같은 일부 표준 정적 웹 사이트 콘텐츠가 이 방법에 적합합니다.
- 응답 헤더에서 날짜와 시간을 지정하는 만료 필드를 지정할 수도 있습니다. 이 시간이 지나면 리소스가 만료되고 클라이언트가 리소스를 다시 가져옵니다. 리소스가 업데이트되는 시간을 알고 있는 경우에 적합합니다.
- Etag도 응답 헤더에 있는 필드이지만 요청 헤더와 함께 사용해야 합니다. 리소스가 변경되었는지 여부를 나타냅니다. 예를 들어 자원을 얻고자 한다면 응답으로 반환되는 Etag는 05td21d이고, 나중에 cache-control은 캐시가 만료되었다고 알려주고 서버에 다시 요청하게 되지만 이 때 추가할 수 있는 것은 "If -None-Match:05td21d" 요청 헤더에 대한 키-값 쌍, 서버는 이 필드의 값을 판단합니다. Etag가 일치하지 않으면 새 리소스 + 200OK + 새 Etag를 반환합니다. 그렇지 않으면 304 상태 코드(수정되지 않음)를 반환합니다.
- 위 필드의 기능이 중복될 수 있으니 원칙을 충분히 숙지하신 후 동시 사용 여부를 결정하시기 바랍니다.
- 쓰기 캐시
- 즉, 먼저 캐시/대기열에 쓰고 나중에 데이터베이스 또는 최종 위치에 쓰면 쓰기 성능도 향상될 수 있습니다.
- 서비스를 중단시키는 캐시 고장 방지
- 작성자가 권장하는 방법은 캐시 미스 시 오리진 서비스에 요청하는 것이 아니라 빠르게 실패하지만 캐시를 즉시 채우도록 오리진 서비스에 알리는 것입니다(비동기적으로).
- 간단하게 유지하십시오. 너무 많은 위치에서 캐싱을 사용하면 클라이언트가 오래된 데이터를 보게 될 가능성이 높으며 이로 인해 많은 문제가 발생할 수 있습니다.
8. 자동 스케일링
비즈니스의 피크 시간과 낮은 피크 시간에 따라 비즈니스 클러스터를 자동으로 확장/축소하는 것입니다.이 기능은 일반적으로 서비스 호스팅 플랫폼에서 제공합니다.두 가지 옵션이 있습니다.하나는 반응형 확장이고 다른 하나는 예측 확장입니다. 후자는 통과해야 합니다. 많은 양의 데이터가 비즈니스의 최고 피크 시간과 최저 피크 시간을 관찰합니다.
9. CAP 정리
분산 시스템에서 유명한 정리 중 하나인 C(일관성) A(가용성) P(파티션 내결함성) 이 정리는 시스템이 이러한 특성 중 최대 두 가지를 가지고 있음을 알려줍니다. 저자는 고전적인 데이터베이스 마스터-슬레이브 복사 시나리오를 사용하여 이 정리를 설명하고 여기서 결론을 직접 설명하겠습니다.
분산 시스템에는 CA 시스템이 없습니다 . 파티션 내결함성을 희생한다는 것은 배포된 것이 분산 시스템이 아닌 단일 프로세스/노드 시스템임을 의미하기 때문입니다. 따라서 우리가 최종적으로 구현하는 분산 시스템은 CP 또는 AP여야 하며 비즈니스 시나리오에 따라 어느 것을 선택해야 하는지 판단해야 합니다. 대답은 '예'입니다. 하지만 은행 잔고에 대한 오래된 데이터일 수 있습니까? 당연히 아니지.
우리 시스템 전체가 AP나 CP일 필요는 없습니다. 디렉토리 서비스는 레코드가 오래될 수 있으므로 AP일 수 있지만 사용자를 원하지 않기 때문에 통화 계정이나 포인트 서비스의 경우 CP만 사용할 수 있습니다. 나머지 10위안은 10위안 상당의 상품을 두 번 반복해서 사용합니다. 그렇다면 이 마이크로서비스 CP인가 CP인가? 사실, 우리가 한 것은 CAP 정리에 대한 장단점을 각 함수에 개별적으로 적용한 것입니다.
마지막으로 저자는 시스템 자체가 아무리 일관성이 있어도 가능한 모든 것을 알 수는 없으며, 특히 실제 세계의 기록을 보관할 때 AP 시스템이 최종 올바른 선택인 이유가 많다고 언급합니다. CP 시스템 구축의 복잡성 외에도 자체적으로 모든 문제를 해결할 수는 없습니다.
10. 서비스 디스커버리
이는 편리함을 제공합니다. 새 서비스 인스턴스가 등록/파기된 후 클라이언트는 신속하게 액세스하거나 다른 사용 가능한 인스턴스를 요청할 수 있습니다.
- DNS, 가장 쉬운 방법. DNS는 특정 웹 사이트를 여러 번 방문할 때 응답이 항상 IP가 아닌 것처럼 이름을 여러 IP와 연결합니다. DNS의 단점도 명백합니다.도메인 이름의 DNS 항목에는 TTL이 있으며 클라이언트는 항목이 이 시간 내에 유효하다고 믿습니다. 도메인 이름이 가리키는 호스트를 변경하려는 경우 TTL은 클라이언트가 제 시간에 새 호스트에 액세스할 수 없도록 하고 DNS는 항목을 여러 위치에 캐시할 수 있습니다. 지연. 이 문제를 피하는 한 가지 방법은 로드 밸런서의 IP에 도메인 이름을 지정하는 것이며 로드 밸런서는 인스턴스의 온라인/오프라인을 담당합니다. 이것은 현재 일반적으로 사용되는 Nginx 웹 사이트 구성 아키텍처와 같습니다.
- 원래 hadoop의 일부로 개발된 Zookeeper는 구성 관리, 서비스 간 데이터 동기화, 리더 선택, 메시지 큐 및 이름 지정 서비스를 포함한 많은 시나리오에서 사용되며 최소 3개의 노드를 배포해야 합니다.
- Consul은 구성 관리 및 서비스 검색도 지원합니다. Zookeeper보다 한 단계 더 나아가 이러한 시나리오에 대해 더 많은 지원을 제공합니다. 킬러 기능 중 하나는 미리 만들어진 DNS 서버를 제공한다는 것입니다.특히 지정된 이름에 대해 IP+포트를 포함하는 SRV 레코드를 제공할 수 있습니다. 즉, 시스템이 이미 DNS를 사용하고 있고 SRV 레코드를 지원하는 경우 Consul을 직접 사용하여 시작할 수 있으며 노드 상태를 확인하는 기능도 제공합니다. Consul에는 등록 서비스, 키-값 읽기 및 쓰기, 상태 확인의 Restful HTTP 인터페이스가 있습니다.
11. 문서화
- API를 설명할 수 있는 Swagger에는 API를 직접 호출할 수 있는 매우 친숙한 웹 인터페이스가 있습니다. 이를 달성하기 위해 Swagger는 해당 형식과 일치하는 보조 파일을 제공하는 서비스가 필요하며 이를 지원하기 위해 다양한 언어로 된 많은 수의 라이브러리가 있습니다.