저는 웹 엔지니어로서 성능과 아키텍처에 가장 중점을 두고 있습니다. 다행히 이번에 sd2.0 컨퍼런스에 참여하여 동료들과 폭넓게 소통할 수 있었습니다. 친구들과 공유한 이 글은 이번 컨퍼런스에 참여하고 다른 사람들과 소통한 경험입니다.
건축 디자인에 대한 몇 가지 생각:
1. 절대로 지나친 디자인을 하지 마세요: 절대로 지나친 디자인을 하지 마세요
자주 언급되는 주제이지만, 아키텍처에서 전혀 사용되지 않거나 결국 버려지는 기능이 얼마나 많은지 생각해 보면 그 중요성을 처음 아키텍처 디자인에 참여하게 되면 종종 이해할 수 있습니다. Huayi의 아키텍처는 확장성이 뛰어나고 모든 요구에 적응할 수 있는 점진적인 아키텍처를 디자인하는 경향이 있습니다. 다음주에 변경될 예정이므로 최대한 빠르게 변경사항에 대응해야 합니다.
eBay 엔지니어들은 자신들의 아키텍처 설계가 시스템의 성장을 결코 충족할 수 없었기 때문에 시스템이 항상 뒤집어지고 다시 만들어졌다고 말했습니다. eBay 설계자의 능력에는 문제가 없습니다. 그들이 설계하는 아키텍처는 항상 이전 버전의 병목 현상을 기반으로 구축되어 새로운 아키텍처가 획기적인 발전을 가져올 것이라고 기대합니다. 짧은 시간 안에 새로운 요구에 압도되어 새로운 아키텍처를 사용해야 했습니다.
웹 개발은 매우 민첩한 프로세스이므로 사용자의 요구 사항은 끊임없이 변합니다. 여러 측면에서 소프트웨어 개발에 비해 하나의 아키텍처를 사용하여 향후 모든 디자인을 계획하는 것은 비현실적입니다.
2. 웹 아키텍처 라이프사이클: 웹 아키텍처의 라이프사이클
과도한 디자인을 제거하고 어느 정도의 예측을 보장해야 하는데, 다음 웹 아키텍처 라이프사이클이 어떻게 균형을 찾을 수 있기를 바랍니다.
설계된 아키텍처는 단순히 하드웨어 용량을 늘려 1~10배의 성장을 감당할 수 있어야 합니다. 5~10배의 성장 기간 동안 다음 10배를 견딜 수 있도록 다음 버전의 아키텍처 설계를 시작하세요. 두 배의 성장
구글이 장악할 수 있는 이유는 전적으로 검색 기술과 정렬 기술이 뛰어나기 때문만은 아니다. 사실 바이두나 야후를 포함해 현재 사용되는 기술은 비슷하지만, 구글은 내부에 수만 대의 서버를 추가하면 이를 달성할 수 있다. 충분한 시스템 용량은 실제로 복제하기 어렵습니다.
3. 캐시: 캐시
공간은 시간과 교환됩니다. 캐시는 항상 컴퓨터 설계에서 최우선 순위입니다. CPU에서 IO까지 캐시는 어디에서나 볼 수 있습니다. 웹 아키텍처 디자인은 캐시를 합리적으로 설계하는 방법에 대해 설명합니다. jbosscache Taobao의 창립자는 이렇게 말했습니다. 사실 웹 캐시와 엔터프라이즈급 캐시의 디자인은 논리에 중점을 두는 반면 웹 캐시는 간단하고 빠릅니다. .
캐싱으로 인해 발생하는 문제는 무엇입니까? 데이터가 여러 프로세스에 분산되어 있기 때문에 클러스터를 추가하면 복잡성이 더욱 증가합니다. 전략은 종종 비즈니스와 연결되어야 합니까?
Laoqian은 유연한 삽입 요구 사항을 충족할 뿐만 아니라 빠른 읽기를 가능하게 하는 Sohu가 디자인한 게시물에 대한 링크된 목록 캐시를 설계했습니다. 일부 다른 대규모 커뮤니티에서는 게시물 목록을 최적화하기 위해 유사한 구조를 사용하는 경우도 많습니다. 도구
링크: 건축 디자인에 관한 Qian Hongwu의 비디오 http://211.100.26.82/CSDN_Live/140/qhw.flv
캐시의 일반적인 전략은 시간이 많이 걸리는 디스크 대신 메모리에 데이터를 보관하는 것입니다. 이런 관점에서 MySQL이 제공하는 힙 엔진(저장 방식)도 생각해 볼 만한 방식인데, 이 저장 방식은 데이터를 메모리에 저장하면서도 SQL의 강력한 쿼리 기능을 그대로 유지할 수 있다.
여기서는 읽기 캐싱에 대해서만 이야기했습니다. 실제로 콘텐츠 지향 커뮤니티에서는 거의 사용되지 않는 쓰기 캐시도 있습니다. 이러한 커뮤니티가 해결해야 할 주요 문제는 읽기 문제이지만 처리 용량이 낮은 경우입니다. 요청 용량보다 단일 요청이 캐시되어 블록을 형성한 다음 일괄 처리될 때, 대화형 커뮤니티 디자인에서 이러한 캐시를 쉽게 찾을 수 있습니다.
넷째, 핵심 모듈은 직접 개발해야 합니다. DIY 핵심 모듈
우리는 이를 깊이 인식하고 있으며, 일부 오픈 소스 모듈을 사용하는 경향이 있다고 언급했습니다. 방문 횟수가 특정 수준에 도달하면 이러한 모듈에는 종종 이런 저런 문제가 발생합니다. 물론 오픈 소스 모듈에 대한 익숙하지 않은 문제라고 생각할 수도 있지만, 어쨌든 핵심에 문제가 있으면 문제가 발생합니다. 코드를 완전히 이해하지 못하는 것은 매우 무섭습니다.
5. 합리적인 데이터 저장: 합리적인 데이터 저장
반드시 데이터베이스를 사용해야 하는 것은 아닙니다. Lei Ming은 검색에 반드시 데이터베이스가 필요하지 않다고 말합니다. 그렇다면 단순히 데이터베이스를 사용하면 안되는 이유는 무엇입니까? 교체해?
우선, 데이터베이스가 파일에서도 작동한다는 점을 인정해야 합니다. 주로 다음 기능을 사용하려면 데이터베이스가 필요합니다. 하나는 데이터 저장이고 다른 하나는 데이터 검색입니다. 관계형 데이터베이스에서는 실제로 데이터베이스의 복잡한 검색 기능에 매우 관심이 있습니다. 자세히 읽을 필요는 없고 그냥 훑어보세요)
Creativity의 countNum을 a로, User_info를 b로, class를 c로, class2를 d로 c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(Reviewid=a.Id인 검토에서 count(Id) 선택)를 선택합니다. 여기서 a.user_id=b.id 및 a.Creativity_Class=c.Id 및 a.Creativity_Class_2=d.Id
a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)를 Creativity에서 countNum으로, User_info를 b로 선택합니다. ,c로 클래스, d로 클래스2, e로 검토(a.user_id=b.id 및 a.Creativity_Class=c.Id 및 a.Creativity_Class_2=d.Id 및 a.Id=e.Reviewid 그룹 a.Id … ………………………….