Zhihu 웹사이트 구조 변경

Zhihu는 각계각층의 엘리트들을 연결하는 친절하고 합리적인 커뮤니티 분위기를 갖춘 진정한 온라인 Q&A 커뮤니티입니다. 사용자는 서로의 전문 지식, 경험 및 통찰력을 공유하여 중국 인터넷에 고품질 정보를 지속적으로 제공합니다.

아마도 많은 사람들은 Zhihu가 Baidu Tieba 및 Douban 다음으로 중국 인터넷에서 가장 큰 UGC(사용자 생성 콘텐츠) 커뮤니티라는 사실을 모르고 있을 것입니다. Zhihu는 사업을 시작한 지 3년 만에 처음부터 시작하여 현재 100개 이상의 서버를 보유하게 되었습니다. 현재 Zhihu에는 1,100만 명이 넘는 등록 사용자가 있으며 매달 8,000만 명이 넘는 사람들이 이 웹사이트를 사용하고 있습니다. 이 웹사이트는 매달 2억 2천만 개 이상의 PV를 보유하고 있으며 초당 거의 2,500건의 동적 요청을 처리하고 있습니다.

ArchSummit 베이징 2014 컨퍼런스에서 Zhihu 공동 창립자이자 CTO인 Li Shenshen은 창립 이후 3년여 만에 Zhihu의 첫 번째 포괄적인 기술 공유를 가져왔습니다.

초기 아키텍처 선택

실제로 2010년 10월 Zhihu 제품 작업을 시작했을 때 처음에는 Li Shenshen을 포함해 2명의 엔지니어만 있었습니다. 2010년 12월 출시 당시에는 4명의 엔지니어가 있었습니다.

Zhihu의 주요 개발 언어는 Python입니다. 파이썬은 간단하고 강력하기 때문에 금방 익힐 수 있고, 개발 효율도 높으며, 커뮤니티도 활발해서 팀원들도 좋아합니다.

Zhihu는 Tornado 프레임워크를 사용합니다. 비동기식을 지원하기 때문에 실시간 Comet 애플리케이션에 매우 적합하고, 간단하고 가벼우며, 학습 비용도 저렴합니다. 또한 FriendFeed의 성숙한 사례와 Facebook의 커뮤니티 지원을 갖추고 있습니다. Zhihu의 제품에는 실시간 푸시 피드 및 알림을 용이하게 하기 위해 브라우저와의 긴 연결을 설정하려는 특성이 있으므로 Tornado가 더 적합합니다.

처음에는 팀 전체의 에너지가 제품 기능 개발에 집중되었습니다. 다른 측면에서는 기본적으로 시간과 비용을 절약하기 위해 가장 간단한 방법을 사용했지만 이는 이후 단계에서도 몇 가지 문제를 일으켰습니다.

초기 아이디어는 비용을 절감하기 위해 클라우드 호스팅을 사용하는 것이었습니다. Zhihu의 첫 번째 서버는 512MB 메모리를 갖춘 Linode 호스트였습니다. 그러나 웹사이트 출시 이후 클로즈베타의 인기는 기대치를 뛰어넘었고, 많은 이용자들은 웹사이트가 매우 느리다는 반응을 보였다. 특히 국내 네트워크가 불균형하고 전국 사용자의 접속 조건이 동일하지 않기 때문에 국경 간 네트워크 지연이 예상보다 큽니다. 이 문제는 당시 도메인 이름을 등록해야 하는 필요성과 함께 Zhihu는 기계를 구입하고 컴퓨터실을 찾는 이전 경로로 돌아갔습니다.

기계를 구입하고 컴퓨터실을 찾은 후 새로운 문제에 직면했고 서비스가 자주 다운되었습니다. 당시 서비스 제공업체의 컴퓨터에는 항상 메모리 문제가 있었고 매번 다시 시작되었습니다. 마지막으로, 기계가 충돌하여 복원할 수 없는 경우가 있었습니다. 이때 Zhihu는 웹과 데이터베이스에 대한 고가용성을 만들었습니다. 창업은 그런 상황이고, 내일 아침에 일어났을 때 어떤 문제에 직면하게 될지 결코 알 수 없습니다.

이것은 웹과 데이터베이스가 모두 마스터-슬레이브인 해당 단계의 아키텍처 다이어그램입니다. 당시 이미지 서비스는 Youpaiyun에서 호스팅되었습니다. 마스터-슬레이브 외에도 더 나은 성능을 위해 읽기 및 쓰기 분리도 수행됩니다. 동기화 문제를 해결하기 위해 온라인 서비스에 대한 응답 지연을 방지하기 위해 오프라인 스크립트를 실행하는 서버가 추가되었습니다. 또한 인트라넷의 처리량 지연을 개선하기 위해 장비를 교체하여 전체 인트라넷의 처리량을 20배로 늘렸습니다.

2011년 상반기에 Zhihu는 이미 Redis에 대한 의존도가 매우 높았습니다. 초기에 대기열과 검색을 사용하는 것 외에도 나중에 캐시를 사용하는 경우 단일 머신 스토리지가 병목 현상이 발생하여 샤딩이 도입되고 일관성이 구현되었습니다.

Zhihu 팀은 도구를 믿고 도구가 효율성을 향상시킬 수 있다고 믿는 팀입니다. 도구는 실제로 프로세스입니다. 최고의 도구는 없으며 가장 적합한 도구만 있습니다. 그리고 전체 상태가 변하고 환경이 변하면서 전체 과정에서 끊임없이 변화하고 있다. Zhihu가 개발하거나 사용하는 도구로는 Profiling(기능 수준 추적 요청, 분석 및 조정), Werkzeug(편리한 디버깅을 위한 도구), Puppet(구성 관리) 및 Shipit(원클릭 온라인 또는 롤백) 등이 있습니다.

로깅 시스템

Zhihu는 원래 초대 전용 시스템이었습니다. Zhihu는 2011년 하반기에 애플리케이션 등록을 시작했습니다. 초대 코드가 없는 사용자도 일부 정보를 입력하여 Zhihu 등록을 신청할 수 있습니다. 현재 사용자 수가 새로운 수준에 도달하여 광고를 게시하는 일부 계정이 있으므로 광고를 제거해야 합니다. 로깅 시스템의 필요성이 의제에 있습니다.

이 로그 시스템은 분산 수집, 중앙 집중식 저장, 실시간, 구독 가능성 및 단순성을 지원해야 합니다. 당시 Scribe와 같은 일부 오픈소스 시스템을 조사했는데, 일반적으로 훌륭했지만 구독을 지원하지 않았습니다. Kafka는 Scala에서 개발되었지만 팀은 Scala에서 축적이 적고 비슷하고 무겁습니다. 그래서 개발팀에서는 자체적으로 로깅 시스템인 Kids(Kids Is Data Stream)를 개발하기로 결정했습니다. 이름에서 알 수 있듯이 Kids는 다양한 데이터 스트림을 집계하는 데 사용됩니다.

아이들은 Scribe의 아이디어를 활용합니다. Kdis는 각 서버에서 에이전트 또는 서버로 구성될 수 있습니다. 에이전트는 애플리케이션으로부터 메시지를 직접 수락한 후 다음 에이전트를 호출하거나 중앙 서버를 직접 호출할 수 있습니다. 로그를 구독할 때 서버나 중앙 노드의 일부 에이전트에서 로그를 얻을 수 있습니다.

구체적인 내용은 아래와 같습니다.

Zhihu는 또한 온라인 로그의 실시간 보기를 지원하는 Kids 기반의 웹 가젯(Kids Explorer)을 만들었습니다. 이는 이제 온라인 문제를 디버깅하는 데 가장 중요한 도구가 되었습니다.

Kids는 오픈 소스로 제공되어 Github에 게시되었습니다.

이벤트 중심 아키텍처

Zhihu 제품의 특성은 가장 먼저 답변을 추가한 후 후속 작업이 실제로 업데이트 알림 및 업데이트입니다. 그러나 전체 기능의 증가에 따라 인덱스 업데이트, 카운트 업데이트, 콘텐츠 검토 등의 작업이 많아지고 후속 작업도 다양해집니다. 전통적인 접근 방식을 따르면 유지 관리 논리가 점점 더 커지고 유지 관리 가능성이 매우 낮아집니다. 이 시나리오는 이벤트 중심 접근 방식에 매우 적합하므로 개발팀은 전체 아키텍처를 조정하고 이벤트 중심 아키텍처를 구축했습니다.

이때 가장 먼저 필요한 것은 다양한 이벤트를 얻을 수 있어야 하고 일관성에 대한 높은 요구 사항을 갖는 메시지 큐입니다. 이러한 요구에 부응하여 Zhihu는 Sink라는 작은 도구를 개발했습니다. 메시지를 받은 후 먼저 이를 로컬에 저장하고 유지한 다음 메시지를 배포합니다. 해당 컴퓨터가 작동을 멈추면 메시지가 손실되지 않도록 다시 시작할 때 완전히 복원할 수 있습니다. 그런 다음 Miller 개발 프레임워크를 통해 메시지를 작업 대기열에 넣습니다. Sink는 직렬 메시지 구독 서비스에 더 가깝지만 작업을 병렬로 처리해야 하므로 Beanstalkd가 편리하고 전체 주기에 걸쳐 작업을 관리합니다. 아키텍처는 아래와 같습니다.

예를 들어, 사용자가 지금 질문에 대답하면 시스템은 먼저 질문을 MySQL에 쓰고 메시지를 Sink에 넣은 다음 질문을 사용자에게 반환합니다. Sink는 Miller를 통해 Beanstalkd에 작업을 보내고 Worker는 스스로 작업을 찾아 처리할 수 있습니다.

처음 온라인에 등장했을 때는 초당 10개의 메시지가 있었고 그 다음에는 70개의 작업이 생성되었습니다. 현재 초당 100개의 이벤트와 1,500개의 작업이 생성되며 이는 현재 이벤트 기반 아키텍처에서 지원됩니다.

페이지 렌더링 최적화

Zhihu는 2013년에 매일 수백만 개의 PV를 기록했습니다. 페이지 렌더링은 실제로 계산 집약적이며 데이터를 가져와야 하기 때문에 IO 집약적이기도 합니다. 이때 개발팀은 페이지를 구성 요소화하고 데이터 수집 메커니즘을 업그레이드했습니다. Zhihu는 전체 페이지 구성 요소 트리의 구조에 따라 위에서 아래로 계층적으로 데이터를 얻습니다. 상위 계층 데이터를 얻었으면 기본적으로 여러 계층에 대해 여러 데이터를 획득할 필요가 없습니다. .

이 아이디어를 결합하여 Zhihu는 템플릿 렌더링 개발 프레임워크인 ZhihuNode를 만들었습니다.

일련의 개선을 거쳐 페이지 성능이 크게 향상되었습니다. 질문 페이지는 500ms에서 150ms로, 피드 페이지는 1초에서 600ms로 줄었습니다.

서비스 지향 아키텍처(SOA)

Zhihu의 기능이 점점 더 복잡해짐에 따라 전체 시스템도 점점 더 커지고 있습니다. Zhihu는 어떻게 서비스화를 구현하나요?

우선, 기본적인 RPC 프레임워크가 필요합니다. RPC 프레임워크도 여러 버전의 진화를 거쳤습니다.

첫 번째 버전은 직렬화를 엄격하게 정의한 모델인 Wish였습니다. 전송 계층은 직접 작성하고 TCP에서 실행되는 매우 간단한 전송 프로토콜인 STP를 사용합니다. 처음에는 서비스를 한두개만 썼기 때문에 처음에는 꽤 괜찮았습니다. 그러나 서비스 수가 증가함에 따라 몇 가지 문제가 발생하기 시작합니다. 먼저 ProtocolBuffer는 전체 라이브러리에 배치하면 매우 길고보기 흉한 일부 설명 코드를 생성합니다. 또한 엄격한 정의로 인해 사용이 불편합니다. 이때 한 엔지니어가 새로운 RPC 프레임워크인 Snow를 개발했습니다. 데이터 직렬화를 위해 간단한 JSON을 사용합니다. 그러나 느슨한 데이터 정의의 문제점은 예를 들어 서비스를 업그레이드해야 하거나 데이터 구조를 다시 작성해야 하는 경우 어떤 서비스가 사용 중인지 파악하고 알리기가 어렵고 오류가 자주 발생한다는 점입니다. 그래서 세 번째 RPC 프레임워크가 출시되었습니다. RPC 프레임워크를 작성한 엔지니어는 이전 두 프레임워크의 특성을 결합하여 첫째로 Snow를 단순하게 유지하고 둘째로 상대적으로 엄격한 직렬화 프로토콜을 요구하기를 바랐습니다. 이번 릴리스에는 Apache Avro가 도입되었습니다. 동시에 전송 계층과 직렬화 프로토콜 계층을 플러그 가능하게 만들기 위해 특수 메커니즘이 추가되었습니다. JSON 또는 Avro를 사용할 수 있으며 전송 계층은 STP 또는 바이너리 프로토콜을 사용할 수 있습니다.

그런 다음 서비스 등록 및 검색을 설정하면 서비스가 있는 시스템을 찾기 위해 서비스 이름만 정의하기만 하면 됩니다. 동시에 Zhihu는 해당 튜닝 도구도 보유하고 있으며 Zipkin을 기반으로 자체 추적 시스템을 개발했습니다.

호출 관계에 따라 Zhihu의 서비스는 집계 계층, 콘텐츠 계층 및 기본 계층의 세 가지 계층으로 나뉩니다. 속성에 따라 데이터 서비스, 논리 서비스, 채널 서비스의 세 가지 범주로 나눌 수 있습니다. 데이터 서비스는 주로 사진 서비스와 같은 특수 데이터 유형의 저장입니다. 논리 서비스는 응답 형식의 정의 및 구문 분석 등과 같이 CPU 집약적이고 계산 집약적인 작업입니다. 채널 서비스의 특징은 스토리지가 없고 싱크와 같은 전달이 더 많다는 것입니다.

이는 서비스화 도입 이후의 전반적인 아키텍처입니다.

제품 및 서비스

Zhihu 홈페이지에는 대략 4가지 기능 영역이 있습니다. 왼쪽에는 홈페이지의 약 70%를 차지하는 '최신 뉴스'가 있으며, 주로 사용자가 팔로우하는 사람들의 최신 질문과 답변을 표시합니다. 이 섹션에서 사용자는 최신 질문과 답변을 보는 것 외에도

'설정', '이슈 팔로우', '댓글 추가', '공유', '감사합니다', '수집' 등의 기능을 통해 관심 이슈에 참여할 수 있습니다. 예를 들어, "설정" 기능을 사용하여 사용자는 주제를 차단하도록 선택할 수 있습니다. 팔로우 중인 사용자가 관심을 갖는 이슈 아래에 이슈에 대한 관심을 추가하거나 댓글을 추가하는 등의 작업도 가능합니다.

홈페이지 오른쪽 상단에는 Zhihu.com의 사용자 행동 관리와 관련된 정보가 있습니다. '내 초안', '내 컬렉션', '모든 질문', '내가 팔로우하는 질문', '나에게 초대된 질문'이 있습니다. 오른쪽 중앙에는 네트워크 외부 초대 기능인 "Zhihu에 가입하도록 친구 초대"가 있습니다. 이 섹션에서 사용자는 이메일과 Sina Weibo를 통해 친구를 Zhihu 커뮤니티에 초대할 수 있습니다. 우측 중앙과 하단에는 이용자들이 관심을 갖고 있는 주제나 추천하는 섹션들이 있습니다. 주제 및 사용자 추천 측면에서 Zhihu 운영자는 한편으로는 사용자가 관심을 갖는 주제에 대한 정보를 요약할 수 있으며, 다른 한편으로는 상당히 정확한 달성을 위해 Zhihu 네트워크 사용자의 관련 행동 데이터에 대한 통계를 기록할 수 있습니다. 권장 사항 및 요약. 동시에 Zhihu.com은 오른쪽 하단의 "주제 광장" 섹션에서 모든 주제 분류 태그를 제공하여 사용자에게 검색 및 탐색 외에도 정보를 얻을 수 있는 좋은 방법을 제공한다는 점을 특히 언급할 가치가 있습니다.

Zhihu 주제 페이지는 그림 2에 표시된 것처럼 두 섹션으로 나눌 수 있습니다. 하나는 "주제 업데이트"이고 다른 하나는 "자주 방문하는 주제"입니다. 왼쪽에는 페이지의 약 70%를 차지하는 '주제 업데이트' 정보가 있습니다. 이 섹션에서 사용자는 클릭하여 관심 있는 주제 아래에 있는 질문(시간순으로 표시)을 볼 수 있으며 관심 있는 주제를 "고정"하거나 "팔로우 취소"할 수도 있습니다.

오른쪽 하단에는 '자주 방문하는 주제' 섹션이 있습니다. 이 페이지에서 사용자는 하위 주제, 팔로어 수, 역학 등 관심 있는 주제의 특정 정보에 대해 알아볼 수 있습니다.

Zhihu 알림 페이지는 그림 3과 같이 4가지 레이아웃으로 나눌 수 있습니다. 좌측의 "모든 알림"은 이용자가 관심을 갖고 있는 질문과 다른 이용자의 답변에 대한 정보(시간순으로 표시)입니다. 오른쪽에는 사용자 행동 데이터 요약, "Zhihu에 가입하도록 친구 초대", 주제 및 주제 추천 섹션 등이 홈페이지 소개와 동일하므로 여기서는 자세히 설명하지 않겠습니다.

Zhihu의 개인 홈페이지는 크게 "개인 정보", "개인 답변", "개인 홈페이지", "사용자 질문 및 답변 검색", "팔로워 및 팔로우 정보", "팔로잉 주제"의 5개 섹션으로 구성됩니다. 자세한 내용은 그림 4에 나와 있습니다.

"프로필" 섹션에서 사용자는 "세부 정보 보기"를 클릭하여 사용자의 "개인 성과"("좋아요", "감사", "컬렉션" 및 "공유" 수 포함), "전문 경험", " 주거정보', '교육경험', '기술'을 말합니다. Zhihu 사용자인 경우 "내 프로필 편집"을 클릭하여 위의 5가지 정보 측면을 완료할 수 있습니다.

왼쪽 하단에는 관련 질문에 대한 사용자의 답변 정보가 포함된 "개인 답변" 페이지가 있습니다(승인 횟수 내림차순 또는 최근부터 답변 시간 순으로 정렬). 위의 두 섹션인 "개인정보"와 "개인 답변"은 전체 포지션의 70%를 차지할 수 있습니다.

오른쪽 상단에는 Zhihu의 최신 개발, 질문, 답변, 수집 및 사용자가 제기한 로그 정보를 요약한 "개인 홈페이지" 페이지가 있습니다.

오른쪽 중앙에는 검색창이 있습니다. 사용자는 이 검색창을 통해 특정 사용자 질문과 답변을 쿼리할 수 있습니다.

우측 중앙 및 하단에는 사용자의 개인 팔로워나 팔로우한 주제에 대한 정보가 표시됩니다. 사용자는 관련 아이콘을 클릭하면 한 번의 클릭으로 특정 섹션에 연결할 수 있습니다.

Zhihu 질문 페이지 - Zhihu의 가장 중요한 페이지입니다. 여기에서 사용자는 특정 질문과 정보를 이해하고, 편집하고, 답변할 수 있습니다.

Zhihu의 페이지는 기능에 따라 대략적으로 "질문 답변", "팔로우 기능", "초대 기능", "관련 질문 링크", "공유 기능" 및 "질문 상태"의 6개 부분으로 나눌 수 있습니다.

왼쪽에는 이 섹션의 약 70%를 차지하는 "질문과 답변" 섹션이 있습니다. 이 섹션에서는 사용자가 관련 이슈에 대한 수정, 의견 작성, 보고 및 투표 관리를 할 수 있습니다. 사용자는 부적절하다고 생각되는 질문, 질문 레이블 및 질문 보충 내용을 수정할 수 있습니다. 동시에 사용자는 부적절하거나 관심 있는 내용을 발견하면 댓글을 달거나 신고할 수도 있습니다. 질문에 대한 답변 측면에서는 사용자가 자신에게 맞는 방식으로 질문에 답변할 수 있습니다

행 정렬 작업(Zhihu는 투표별 정렬, 시간별 정렬, 사용자 팔로어별 표시의 세 가지 콘텐츠 표시 방법을 제공합니다.)

또한 그림 6과 같이 각 답변의 왼쪽에는 승인과 비승인을 나타내는 두 개의 삼각형이 위와 아래에 하나씩 있다는 점을 언급할 가치가 있습니다. 사용자는 자신의 지식, 이해 또는 관심 사항을 기반으로 질문에 대한 답변을 개인화할 수 있습니다.

이 섹션의 오른쪽에는 위에서 아래로 "팔로우" 기능이 있습니다. 이 기능 섹션에서는 사용자가 문제에 주의를 기울일 수 있는데, 이는 Sina Weibo의 팔로우 기능과 약간 유사합니다. 차이점은 Zhihu의 팔로우는 주로 특정 문제에 초점을 맞추는 반면 Sina Weibo는 주로 특정 사용자에게 초점을 맞춘다는 것입니다.

오른쪽 아래에는 "질문에 답변하도록 다른 사람 초대" 섹션이 있습니다. 이는 이전에 "Zhihu 홈 페이지" 및 "Zhihu 알림" 섹션에서 소개한 기능과 동일하므로 여기서는 자세히 설명하지 않겠습니다.

더 아래에는 문제와 관련된 다양한 질문이 있습니다. 이는 대부분의 웹사이트 시스템에서 권장하는 방법이기도 합니다. 이 추천 방법은 기술과 경험 측면에서 상대적으로 성숙했지만 그 효과는 중요하지 않습니다. 질문 관련 질문 링크 측면에서 Zhihu는 주로 특정 질문의 특성을 목표로 하며 해당 알고리즘을 통해 기계 추천을 제공합니다. 이는 다양한 사용자의 취미에 대한 개인화된 추천 효과를 얻지 못합니다. 전자상거래 플랫폼은 이 기술에 더 많은 관심을 기울입니다.)

더 아래에는 질문 공유 기능이 있습니다. 사용자는 "Weibo"와 "이메일"을 통해 사이트 외부와 "사이트 내 비공개 메시지"를 통해 사이트 내에서 Zhihu 질문을 공유할 수 있습니다.

오른쪽 하단에는 문제 상태가 표시됩니다. 이 페이지에서 사용자는 해당 질문의 최근 활동이 발생한 시간, 조회 횟수, 관련 주제의 팔로어 수, 질문을 팔로우하는 사람 수를 확인할 수 있습니다.

사용자 경험

1. 정확히 말하면 Zhihu는 포럼에 가깝습니다. 사용자는 관심 있는 주제에 관해 관련 토론을 진행하고, 당신과 같은 관심사를 가진 사람들을 팔로우할 수 있습니다. 개념적 설명을 위해 온라인 백과사전은 거의 모든 질문을 다루고 있지만 확산적 사고의 통합은 Zhihu의 주요 특징입니다. Zhihu는 질문의 다양성을 넓히기 위해 Q&A 과정에서 토론을 장려합니다. 구체적이지 않은 답변을 장려하고 위키에서 답변을 참조할 수 있도록 장려하세요.

2. Zhihu에 등록된 모든 사용자는 포럼보다 더 배타적입니다. 귀하가 수행하는 모든 작업은 귀하의 개인 PR 가치에 직접적인 영향을 미칩니다. 답변 시 승인투표수 순으로 정렬되며, 승인투표수가 동일할 경우 개인 PR값 순으로 정렬되며 유효하지 않은 답변은 숨겨집니다. 이렇게 하면 꽤 많은 양의 스팸이 어느 정도 걸러집니다.

3. Zhihu는 첫째로 사용자의 준실명 신원의 신뢰성을 보장하고 둘째로 너무 많은 스팸 정보를 생성하지 않기 위해 엄격한 초대 시스템을 주장한 적이 있습니다. 준실명을 사용하면 사용자가 관심 있는 사람들에게 타겟 질문을 더 쉽게 할 수 있습니다. 이것은 한한의 중단된 "솔로 그룹", "모두가 모두에게 묻는다"에 대한 매우 흥미로운 칼럼입니다. 즉, 이것이 실제입니다. -인생 버전 Zhihu. 동시에 Zhihu의 엄격한 초대 시스템은 Zhihu에게 아무 말도하지 않고도 다른 사람을 설득 할 수있는 Keso로 대표되는 강한 엄격한 분위기를 제공했습니다.

2013년 3월부터 Zhihu는 대중에게 등록을 공개했습니다.

4. 신용 기반의 SNS 관계. 아마도 단순히 SNS와 Q&A를 통합하면 국내 Renren이 더 빠르게 발전할 수 있을 것입니다. 그러나 위에서 언급한 것처럼 엄격한 초대 시스템으로 인해 Renren이 소셜 Q&A를 출시할 경우 필연적으로 원본이 통합됩니다. 그리고 이 친구들이 모두가 귀하의 관심사에 관심을 갖고 있는 사람일 수는 없습니다. 이는 또한 대형 인터넷 기업이 Quora 형식의 Q&A에 참여할 가능성을 거의 무효화합니다.

대형 인터넷 기업은 일반적으로 폭넓은 독자층을 보유하고 있기 때문에 Quora형 질문과 답변은 단순히 인기도를 기준으로 하는 것이 아니라 생성된 엘리트 정보의 양인 정보 대비 가치 비율(가치 정보/총 정보량)을 기준으로 합니다. .

하지만 사우전드오크스가 로우키 방식으로 Jingwei.com을 개설해 수직형 SNS로서 상당수의 전문인력을 모았다. 잠재적인.

5. Quora와 비교하여 Zhihu는 파란색을 톤으로 사용합니다. Quora에 비해 Zhihu의 기능은 특정 주제에 대한 최고의 주제와 같이 여전히 개선이 필요합니다.