Ele.me의 아키텍처 진화와 디자인 탐구

소개	산업 모델로 빠르게 제작해 보세요. "빠름"이 최우선이며 건축 설계에 너무 많은 에너지를 쏟을 필요는 없습니다. 웹사이트가 확장기에 접어들었을 때만 웹사이트의 트래픽이 폭발할 때 이를 감당하기 위해 아키텍처에 더 많은 에너지를 투자해야 합니다. Ele.me는 설립된 지 8년이 되었으며, 현재 일일 주문량이 900만 건을 넘었습니다. 또한 웹사이트 구조도 비교적 완성도가 높습니다.

1. 웹사이트 인프라

초창기에는 SOA를 더 쉽게 확장할 수 있는 프레임워크를 사용했습니다. 우리는 SOA 프레임워크를 사용하여 두 가지 문제를 해결합니다.

1. 분업과 협업

웹사이트 초기에는 프로그래머가 1~5명 정도밖에 안 됐을 땐 모두가 똑같은 일에 바빴을 거에요. 그들은 모두 서로의 일을 이해하고 종종 "고함"을 통해 문제를 해결합니다.

하지만 사람 수가 늘어나면 이 방법은 당연히 불가능합니다. 한 사람이 코드를 업데이트한 다음 다른 사람의 코드를 다시 온라인에 올리는 것은 불가능합니다. 그러므로 우리는 분업과 협력의 문제를 고려해야 한다.

2. 빠른 확장

과거에는 주문량이 1,000~10,000까지 10배로 늘어났지만 전체 주문량이 그리 높지 않고 웹사이트에 대한 부담도 그리 크지 않습니다. 실제로 주문량이 10만에서 100만, 100만에서 200만으로 늘어나면 그 수는 10배 정도밖에 늘어나지 않을 수 있지만 이는 전체 웹사이트의 아키텍처에 있어서 엄청난 도전이다.

우리의 배경은 2014년 100만 명에서 현재 900만 명으로 성장한 것입니다. 기술 팀은 초기에 30명 이상에서 현재 900명 이상의 팀으로 성장했습니다. 현재로서는 분업과 협업이 큰 과제입니다. 서비스의 분할과 통합, 그리고 팀의 분할과 통합은 이를 지원하는 프레임워크 시스템이 필요합니다. 이는 SOA 프레임워크의 역할이기도 합니다.

현재 상황을 보세요. 가운데는 전체 아키텍처 시스템이고, 오른쪽은 기본 구성 요소나 서비스를 포함하여 서비스화와 관련된 일부 기반입니다.

먼저 언어에 대해 이야기해 보겠습니다. 우리의 원래 웹사이트는 PHP를 기반으로 하다가 천천히 변형되었습니다.

창업자들은 모두 창업을 하는 대학생들이므로 당연히 Python이 첫 번째 선택으로 좋습니다. 지금까지는 Python도 좋은 선택인데 왜 Java와 Go로 확장해야 할까요?

많은 사람들이 Python을 작성할 수 있지만 실제로 잘 할 수 있는 사람은 많지 않습니다. 사업이 성장할수록 더 많은 개발자가 필요합니다. Java의 성숙한 생태 환경과 새롭게 떠오르는 Go 생태계를 고려하여 마침내 Python, Java 및 Go가 여러 언어로 공존하는 생태계를 선택했습니다.

WebAPI는 주로 HTTPS 오프로딩, 전류 제한, 보안 확인 등 비즈니스 로직과 관련 없는 몇 가지 일반적인 작업을 수행합니다.

Service Orchestrator는 구성을 통해 내부 및 외부 네트워크의 프로토콜 변환과 서비스 집합 및 맞춤화를 구현하는 서비스 오케스트레이션 레이어입니다.

아키텍처 다이어그램의 오른쪽에는 정기적으로 작업을 실행하기 위한 작업 시스템과 같은 서비스 지향 프레임워크를 둘러싼 일부 보조 시스템이 있습니다. 우리는 거의 1,000개에 달하는 서비스를 보유하고 있습니다. 이러한 시스템을 어떻게 모니터링합니까? 그래서 모니터링 시스템이 있어야 합니다. 처음에는 사람이 30명 이상일 때는 기계로 달려가서 로그를 검색하는 것이 더 나았지만, 사람이 900명이 넘으면 모두가 기계로 가서 로그를 검색할 수는 없습니다. 로깅 시스템이 필요합니다. 여기서는 다른 시스템을 하나씩 설명하지 않습니다.

로마는 하루아침에 건설된 것이 아니며 인프라는 진화하는 과정입니다. 우리는 에너지가 제한되어 있는데, 먼저 무엇을 해야 할까요?

2. 서비스 분할

웹사이트가 커지면 원래 구조가 개발 속도를 따라갈 수 없습니다. 우리가 가장 먼저 해야 할 일은:

큰 Repo를 작은 Repo로 분할하고, 큰 서비스를 작은 서비스로 분할하고, 중앙 집중식 기본 서비스를 여러 물리적 시스템으로 분할합니다.

서비스 분할만 완료하는데 1년 이상이 소요되어 비교적 긴 과정입니다.

이 과정에서는 먼저 API에 대한 올바른 정의를 내려야 합니다. API가 온라인 상태가 되면 일부 수정 비용이 상당히 높기 때문입니다. 귀하의 API에 의존하는 사람들이 많을 것이며, 누가 귀하의 API에 의존하는지 모르는 경우가 많습니다. 이는 큰 문제입니다.

그런 다음 몇 가지 기본 서비스를 추상화합니다. 많은 원래 서비스가 실제로 원래 비즈니스 코드에 결합되어 있습니다. 예를 들어 결제 사업의 경우, 사업이 아주 단순할 때에는 긴밀하게 결합된 코드는 문제가 되지 않지만, 점점 사업이 확장되고 결제 서비스가 필요한 경우에는 사업별로(결제 기능 등) 하나씩 해야 합니까? ? 따라서 결제 서비스, SMS 서비스, 푸시 서비스 등 이러한 기본 서비스를 추출해야 합니다.

해체 서비스는 매우 간단하고 가치가 거의 없어 보이지만 이것이 바로 우리가 처음부터 해야 할 일입니다. 사실 이 기간 동안 이전 아키텍처는 모두 연기될 수 있다. 아키텍처 조정을 하지 않으면 사람이 죽지 않지만, 서비스를 해체하지 않으면 사람이 정말 죽기 때문이다.

서비스 분할은 긴 과정이겠지만 실제로는 매우 고통스러운 과정이고 지원 시스템의 많은 시스템 엔지니어링이 필요합니다.

3. 출시 시스템

출시가 가장 큰 불안정 요인입니다. 많은 회사에서는 출시 기간에 대해 엄격한 제한을 두고 있습니다. 예를 들면 다음과 같습니다.

• 일주일에 이틀만 게시할 수 있습니다.
• 주말에는 절대 포스팅하지 않습니다
• 성수기에는 포스팅을 절대 금지합니다
• 잠깐...

퍼블리싱의 가장 큰 문제점은 퍼블리싱 후 간단한 실행 가능한 롤백 작업이 없다는 점을 발견했습니다. 롤백 작업은 누가 수행합니까? 릴리스 담당자가 수행할 수 있습니까? 아니면 전담 인력이 수행해야 합니까? 출판사라면 출판사는 24시간 온라인으로 일하지 않습니다. 문제가 있어 사람을 찾을 수 없으면 어떻게 해야 합니까? 롤백을 전담하는 사람이 있고 간단하고 통일된 롤백 작업이 없다면 이 사람은 게시자의 코드를 잘 알고 있어야 하는데 이는 기본적으로 불가능합니다.

그래서 게시 시스템이 필요합니다. 게시 시스템은 통합된 롤백 작업을 정의합니다. 모든 서비스는 게시 시스템에서 정의한 롤백 작업을 따라야 합니다.

Ele.me의 퍼블리싱 시스템에 연결하는 것은 모든 사람의 필수 요구 사항입니다. 모든 시스템이 퍼블리싱 시스템에 연결되어 있어야 합니다. 퍼블리싱 시스템의 프레임워크는 매우 중요합니다. 이는 실제로 회사에 매우 중요하며 최우선 대기열에서 고려되어야 합니다.

4. 서비스 프레임워크

다음 단계는 Ele.me의 서비스 프레임워크입니다. 이는 대규모 Repo를 작은 Repo로 분할하고 대규모 서비스를 소규모 서비스로 분할하여 서비스를 가능한 한 독립적으로 만들기 위한 분산 서비스 프레임워크 세트가 필요합니다.

분산 서비스 프레임워크에는 서비스 등록, 검색, 로드 밸런싱, 라우팅, 흐름 제어, 회로 차단기, 성능 저하 및 기타 기능이 포함되어 있으며 여기서는 하나씩 설명하지 않습니다. 앞서 언급했듯이 Ele.me는 Python 및 Java를 포함한 다중 언어 생태계입니다. 우리의 서비스 지향 프레임워크도 다중 언어입니다. 이는 DAL 계층과 같은 일부 미들웨어의 후속 선택에 영향을 미칩니다.

5. DAL 데이터 액세스 계층

비즈니스 규모가 증가하면 데이터베이스에 병목 현상이 발생합니다.

초기 단계에서는 하드웨어 업그레이드를 통해 데이터베이스 성능을 향상시킬 수 있습니다. 예:

• CPU가 더 많은 머신으로 업그레이드하세요.
• 하드 드라이브를 SSD 또는 그 이상의 고급 드라이브로 변경하세요.

하지만 하드웨어 개선에는 결국 용량의 한계가 있습니다. 게다가 많은 비즈니스 파트너들이 코드 작성 시 데이터베이스를 직접 운영하는 경우가 많아 서비스가 온라인화되자마자 데이터베이스가 폭파되는 경우도 많았다. 데이터베이스가 파괴된 후에는 데이터베이스를 복원하지 않는 한 비즈니스를 복원할 수 있는 다른 기회는 없습니다.

데이터베이스에 있는 데이터가 정상이라면 해당 업체는 실제로 보상을 받을 수 있습니다. 따라서 DAL 서비스 계층을 구축할 때 가장 먼저 해야 할 일은 현재 흐름을 제한하는 것이며 다른 것들은 제쳐두어도 됩니다. 그런 다음 연결 재사용을 위해 Python 프레임워크는 다중 프로세스, 단일 스레드 및 코루틴 모델을 사용합니다.

실제로 여러 프로세스가 연결을 공유할 수 없습니다. 예: 10개의 Python 프로세스가 머신에 배포되고 각 프로세스에는 10개의 데이터베이스 연결이 있습니다. 10개의 머신으로 확장하면 1,000개의 데이터베이스 연결이 있습니다. 데이터베이스의 경우 연결은 비용이 많이 들고 DAL 계층은 연결을 재사용해야 합니다.

이 연결 재사용은 서비스 자체의 연결 재사용에 관한 것이 아니라 DAL 계층의 연결 재사용에 관한 것입니다. 즉, 서비스는 DAL 계층에 대해 1000개의 연결을 가지고 있으며 데이터베이스는 12개의 연결만 유지할 수 있습니다. 데이터베이스 요청이 트랜잭션이라는 것이 확인되면 DAL은 이 연결의 해당 관계를 유지하는 데 도움을 줍니다. 트랜잭션이 끝나면 데이터베이스 연결은 다른 사람이 사용할 수 있도록 공유 풀에 다시 저장됩니다.

그럼 연기와 융합을 해보세요. 데이터베이스가 융합 중일 수도 있습니다. 데이터베이스가 연기되면 데이터베이스가 충돌하지 않도록 일부 데이터베이스 요청을 종료합니다.

6. 서비스 거버넌스

서비스 프레임워크 다음에는 서비스 거버넌스 문제가 포함됩니다. 서비스 거버넌스는 실제로 큰 개념입니다. 첫 번째는 모니터링 포인트를 많이 묻어야 한다는 것입니다.

예를 들어 요청이 있는 경우, 요청의 성공 여부, 요청의 응답 시간은 얼마나 되는지, 모든 모니터링 지표를 모니터링 시스템에 올려 놓습니다. 우리는 많은 모니터링 표시기를 갖춘 대형 모니터링 화면을 가지고 있습니다. 이 화면을 하루 72시간 지켜보는 전담팀이 있습니다. 곡선에 변동이 있으면 이를 해결할 사람이 찾아옵니다. 다른 하나는 경보 시스템입니다. 모니터링 화면에 표시되는 내용은 항상 제한되어 있으며 매우 중요한 핵심 지표만 표시할 수 있습니다. 이때 경보 시스템이 필요합니다.

로마는 하루아침에 건설되지 않았으며 인프라는 진화하는 과정입니다. 우리의 자원과 시간은 항상 제한되어 있습니다. 건축가이자 CTO로서 이렇게 제한된 자원으로 어떻게 더 중요한 것을 생산할 수 있습니까?

우리는 많은 시스템을 구축했고 잘했다고 생각하지만 실제로는 그렇지 않습니다. 점점 더 많은 문제와 요구가 있기 때문에 우리는 석기 시대로 돌아간 것 같습니다. 아직 시스템이 부족한 것 같아요. 뭔가 하고 싶은 기능이 많아요.

예를 들어 흐름 제어 시스템의 경우 사용자가 동시성 번호를 구성해야 하는데, 이 동시성 번호는 사용자가 구성할 필요가 전혀 없나요? 서비스 자체의 상태에 따라 동시성 수를 자동으로 제어할 수 있나요?

그리고 업그레이드 방법이 있습니다. SDK 업그레이드는 매우 고통스러운 일입니다. 예를 들어 저희 서비스 프레임워크 2.0은 작년 12월에 출시되었는데 아직도 1.0을 사용하시는 분들이 계십니다. SDK의 무손실 업그레이드가 가능합니까? 업그레이드 시간과 리듬을 직접 제어할 수 있습니다.

또한 현재 모니터링은 동일한 서비스에 대한 집계만 지원하며 클러스터나 머신으로 구분되지 않습니다. 그러면 향후 지표를 클러스터와 머신으로 나눌 수 있습니까? 가장 간단한 예를 들자면, 서비스에 10개의 머신이 있는 경우 한 머신에만 문제가 있을 수 있지만 모든 표시기는 다른 9개의 머신에 고르게 분산됩니다. 전체 서비스 대기 시간이 증가하는 것을 확인할 수 있지만 시스템 하나만으로 전체 서비스 클러스터의 속도가 느려질 수도 있습니다. 하지만 아직 더 많은 차원에서 모니터링할 수는 없습니다.

지능형 알람도 있습니다. 이 알람은 빠르고 완전하며 정확해야 합니다. 이제 더 빠르고 포괄적으로 수행할 수 있는 방법은 무엇일까요? 매일 피크 시간대에는 1분마다 1,000개 이상의 알람이 전송됩니다. 1,000개의 알람이 모두 유용한가요? 경찰에 너무 많이 전화하면 경찰에 전혀 전화하지 않는 것과 같습니다. 모두가 피곤해서 시청을 중단했습니다. 이 알람을 어떻게 더 정확하게 구분할 수 있나요? 더 지능적인 링크 분석이 있습니까? 앞으로는 모니터링에 모니터링 지표를 넣지 않고 링크 분석을 넣어 문제가 어느 노드에 해당하는지 명확하게 알 수 있도록 해야겠습니다.

이 질문에는 우리 작업의 원칙이 포함됩니다. 일이 충분하다면 비오는 날에 대비하고 확실한 사전 계획을 세울 수 있어야 합니다.

위 내용은 Ele.me의 아키텍처 진화와 디자인 탐구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!