그것은 규모를 늘리는 것이 아니라 성공할 것이다

많은 사람들이 어떻게 규모를 설계하는지 알고 싶어 한다.솔직히 말하자면, 어떻게 규모 인코딩을 하는지 배우는 데는 대량의 실천이 필요하다.내가 보기에, 일단 네가 벗겨진 고통을 겪으면, 더욱 쉽게 할 수 있을 것이다.느린 코드의 쇠퇴를 본 후에 나중에 더욱 쉽게 식별할 수 있습니다.
이 글은 "It will do"코드와 "It will scale"코드 사이의 차이점을 공유하고 싶습니다.

위반 코드 찾기

우선, 나는 어떻게 이 최적화되지 않은 코드를 찾았습니까?우리는 몇 가지 일을 완성하는 데 시간이 오래 걸려서, 나는 원인을 찾아내기로 결정했다.나는 샘플 데이터를 얻어서 컨트롤러에서 Rails.logger.level = 0 내연으로 이 작업을 실행했다.이것은 내가 본 단편이다.

Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'read-only'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'basic'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'admin'  ORDER BY description ASC LIMIT 1
...
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'read-only'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'basic'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'admin'  ORDER BY description ASC LIMIT 1
...
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'read-only'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'basic'  ORDER BY description ASC LIMIT 1
Role Load (0.6ms)  SELECT  `roles`.* FROM `roles` WHERE `roles`.`description` = 'admin'  ORDER BY description ASC LIMIT 1

우리는 이 세 배역을 한 번 또 한 번 찾았다.나는 데이터를 처리해야 한다는 것을 알고 사용자의 역할을 검사해서 권한을 확인하지만, 왜 우리가 3개의 데이터베이스 요청을 보내서 이 조작을 실행해야 하는지 모르겠다.나는 마침내 MySQL 요청을 다음 코드 줄로 거슬러 올라갔습니다.Role.system_roles.include?(user.role).그곳에서 나는 본보기로 가서 이 방법이 무엇을 하는지 보았다.

def self.system_roles
  [readonly_role, default_role, admin_role]
end

이 세 캐릭터 중 하나는 각자의 방법에서 정의된다.

def self.admin_role
  find_by(:description => ADMIN_ROLE)
end

def self.default_role
  find_by(:description => DEFAULT_ROLE)
end

def self.readonly_role
  find_by(:description => READONLY_ROLE)
end

이제 이 모든 것은 완전히 일리가 있다.나는 즉시 내가 찾은 코드를 비웃었다.근데 멈췄어요.나는 이 코드가 얼마나 효과가 없는지 크게 욕하지 않고, 왜 처음에 이렇게 썼는지 이해하는 데 시간이 좀 걸렸다.

코드를 작성하면 됩니다.

사실은 첫 번째 그룹의 개인 역할 방법이 먼저 작성되었다는 것을 증명한다.전체 코드에서 단일 캐릭터에 대한 간단한 일회성 권한 검사를 위한 단독find 방법을 사용합니다.
잠시 후, 우리가 처음으로 역할 기반 접근 제어(RBAC)를 통과했을 때, 우리는 system_roles 방법을 실현했다.우리는 이 방법을 사용하여 컨트롤러 작업에서 사용자의 접근 권한을 검사합니다.컨트롤러 작업에서만 단일 검색을 수행하기 때문에 MySQL 쿼리 3 0.6ms 개는 걱정하지 않습니다.우리는 할 수 있는 코드를 썼다.
마지막으로, 우리는 Elasticsearch 집단의 데이터에 대한 접근을 제어하는 것을 포함하여 RBAC를 확장했다.Elasticsearch에 요청할 때마다 요청된 사용자의 역할 권한을 확인합니다.이것을 실현할 때, 나는 (그래, 이것은 나에게 있다!)캐릭터 모델에서 system_roles 방법을 찾아 사용합니다.당시에 나는 우리가 이 방법을 수백만 번 사용하기 시작하면 무슨 일이 일어날지 생각하지 못했다.이것은 우리가 이미 가지고 있는 간단한 방법이기 때문에 나는 내가 그것을 사용할 것이라고 생각한다.1년여 동안 효과가 좋았다.

눈금자 코드 작성

오늘날, 우리가 Elasticsearch에서 데이터를 얻었을 때, 우리는 여전히 이 코드를 사용합니다.현재를 제외하고 우리는 병행 백그라운드 작업 프로그램에서 이 코드를 수십만 번 실행한다.이 세 개의 단독 MySQL 호출을 합치면 우리의 업무에 적지 않은 시간을 증가시켰다.이 문제를 해결하기 위해 나는 system_roles 방법을 갱신하여 단일where 자구를 사용했다.

def self.system_roles
  where(:description => [ADMIN_ROLE, DEFAULT_ROLE, READONLY_ROLE])
end

우리는 지금 3개0.6ms의 MySQL 요청이 아니라 1개0.3ms의 MySQL 요청을 보내기만 하면 된다.이것은 우리의 시간을 절약할 뿐만 아니라, 우리의 데이터베이스를 위해 추가 부하도 절약했다.

제1과 학습 - 처음부터 확장할 수 있는 코드를 작성해 보세요.

코드를 작성할 때, 현재의 용례만 고려하고'가능한'코드를 작성하는 것은 매우 쉽다.코드를 작성할 때 현재 용례를 뛰어넘으려고 시도합니다.이 코드는 장래에 서로 다른 용법이 있습니까?만약 그렇다면, 그것은 실행될 수 있습니까?가능한 한 고성능 코드를 작성해 보세요. 미래의 자신이나 동료가 고마워할 것입니다.

제2과 - 무턱대고 코드를 다시 사용하지 마세요.

새로운 기능을 추가할 때, 이미 존재하는 방법이나 클래스를 가져와 사용하기 쉽다.이것에 대해 싫증을 느낀다!이 종류나 방법의 작성 목적은 당신이 그것을 사용하려고 계획한 목적과 완전히 다를 수 있습니다.원본 코드의 작성자는 사용자가 사용할 방식으로 사용하지 않을 수도 있습니다.논리적, 성능적 요구 사항을 모두 충족해야 합니다.
같은 개념도gems에 적용된다.많은 위대한 보석들이 비례에 따라 설계되지 않았다.이 점을 주의하세요.gem를 자주 사용하려면 원본 코드를 살짝 훑어보십시오.용례에 맞게 최적화되었는지 확인하십시오.내가 백엔드 스태프를 위해 플러그인을 실현하려고 시도했을 때, 나는 느린 코드를 한 번도 만난 적이 없었다.
다음 줄의 코드를 쓰려고 할 때, 이 코드가'할 수 있다'아니면'확장할 수 있다'라고 자신에게 물어봐라.