-
이 시리즈의 마지막 기사는 일반 프로그래머를 위해 작성되었습니다. 관심이 없다면 이 기사의 마지막 몇 단락만 읽어도 됩니다.
코드 구조 설계를 시작하기 전에 이전에 준비한 내용을 검토해 보겠습니다. 로드 밸런싱된 WEB 서버, 마스터-슬레이브 DB 서버 및 샤딩, 캐시 및 확장 가능한 스토리지가 있습니다. 코드 구성의 모든 측면은 이러한 준비와 밀접하게 관련되어 있습니다. 하나씩, 둘씩 셋씩 나열하고, 각 항목은 쉬운 비교를 위해 "위에 언급된" 고전 문장으로 시작합니다.
서두르지 말고 고전적인 문장 패턴을 읽어보세요. 정신이 번쩍 들어서 한 문단을 삽입하겠습니다. 실제 개발에서 우리는 항상 성능과 코드 우아함 사이에서 절충안을 찾습니다. 오늘날의 컴퓨터와 언어 해석기에서는 객체 호출의 레이어 수와 객체 호출의 레이어 수, 변수를 Map으로 선언할지 HashMap으로 선언할지에 대한 질문은 항상 시스템에서 가장 느린 부분을 고려하여 해결해야 합니다. 가장 느린 부분부터. 예를 들어, 사용하는 ORM이 필요하지 않은 일을 많이 수행하는지, 데이터 호출이 반복되는지 확인하세요. 우리가 하는 일은 기본 프레임워크 API가 아닌 웹 애플리케이션 개발입니다. 읽기 쉽고 이해하기 쉬운 코드는 품질을 보장하는 데 매우 중요한 측면입니다. 다양한 방법이 있습니다... 잊어버리세요. 이 기사는 주제에서 너무 벗어났습니다. 소통하고 싶다면 내 Weibo를 팔로우하세요 : http://t.sina.com.cn/liuzhiyi .
앞서 언급한 것처럼 WEB 서버는 로드 밸런싱이 필요하고, 사진 서버는 분리되어야 합니다. 이 점에 관해서는 코드가 클라이언트 상태를 처리할 때 상태를 단일 시스템에 두지 마십시오. 예를 들어 파일 세션을 사용하지 마십시오. 가능하다면 도메인 전체의 상태 확인 방법, 정적 페이지의 상태 확인 방법, 로그인 시 점프 및 반환 매개변수 정의 등을 포함하여 처음부터 사용자 단일 지점 인증을 위한 통합 인터페이스를 개발하는 것이 가장 좋습니다. .하위 레이어에 좋은 인터페이스를 제공하고 적용 레이어를 직접 사용합니다(GAE 사용자 서비스 참조). 로그인 디자인은 모바일 장치의 특성을 고려해야 합니다. 예를 들어 컴퓨터는 플로팅 레이어 창을 사용할 수 있지만 NOKIA 자체 브라우저나 UCWEB에서는 이러한 형태의 표현을 처리할 수 없으며, 프로그램은 Ajax 요청과 URL을 통해 직접 처리할 수 있어야 합니다. . 묻다. 사진 서버가 분리되어 있으며 리소스 파일은 사진 서버에 배치하는 것이 가장 좋습니다. 즉, 웹 서버는 동적 프로그램만 제공합니다. 개발 및 테스트가 약간 복잡하기는 하지만(액세스하려면 절대 URI가 필요하기 때문에) 앞으로 페이지의 프런트 엔드를 최적화하는 것이 훨씬 쉬울 것이며 웹 서버의 IO 최적화도 훨씬 쉬워집니다. 프로그램이 리소스 파일을 참조할 때 통일된 처리 방법이 있어야 합니다. CSS/js를 파일로 결합하거나 생성된 URI 뒤에 QUERYSTRING을 자동으로 추가하는 등 많은 작업이 메서드 내에서 자동으로 완료될 수 있습니다. 캐시 서비스가 사용되는 경우 QUERYSTRING을 생성하는 것이 서버 캐시와 클라이언트 캐시를 새로 고치는 가장 간단한 방법입니다.
앞서 언급했듯이 데이터베이스는 복제되며 여러 마스터와 슬레이브가 있을 수 있으며 샤딩될 수 있습니다. 우리 프로그램에서 데이터를 처리하는 과정에서는 데이터를 추상화하여 별도의 레이어에 배치하는 것이 가장 좋습니다. M 계층 아래에 데이터 계층을 배치하는 인기 있는 MVC 모델을 예로 들어보겠습니다. 이 데이터 계층은 일반적으로 알려진 JDBC/PDO/ActiveRecord 등이 아니라 메소드만 노출하는 자체 액세스 데이터 계층입니다. 외부 세계. 데이터 액세스 세부정보를 숨깁니다. 이 데이터 레이어 내부에 보기 흉한 글쓰기를 두려워하지 마세요. 하지만 모든 데이터 저장 기능을 제공해야 합니다. 다른 수준에서 데이터베이스를 다루는 단어는 보지 마세요. 그 이유는 단일 관계형 데이터베이스의 경우 SELECT...JOIN...또는 직접 INSERT...INTO...를 수행할 수 있지만 일부 테이블을 키-값 데이터베이스에 저장할 수도 있기 때문입니다. 그 후에는 원래의 명령문과 방법을 모두 변경해야 하며, 너무 분산되어 있으면 이식하는 동안 많은 노력이 필요하거나 매우 큰 모델을 얻게 됩니다. 데이터 수준 디자인 측면에서 JOIN 쿼리를 피하면 더 많은 중복성과 캐싱을 수행할 수 있습니다. 각 데이터 유형에는 하나의 쿼리만 필요하며 이를 프로그램에 결합합니다. 보다 복잡한 데이터 조합의 경우 실시간 요구 사항이 높지 않은 경우 비동기 처리를 사용할 수 있으며 사용자는 액세스할 때 처리된 결과만 얻을 수 있습니다. 기본 키를 다룰 때 자동 증가 ID 사용을 피하고 특정 규칙에 의해 생성된 고유 값을 기본 키로 사용하는 것이 가장 간단한 샤딩 분산 전략입니다. 자동 증가 ID를 사용하더라도 자동 증가 ID 생성기를 사용하는 것이 가장 좋습니다. 그렇지 않으면 슬레이브 데이터베이스가 실수로 작성되면 기본 키가 쉽게 충돌합니다.
앞서 언급했듯이 데이터베이스 전면을 차단하는 일부 캐시가 있습니다. MySQL의 쿼리 캐시를 캐시로 취급하지 마십시오. 애플리케이션이 약간 복잡하면 QUERY CACHE가 부담이 됩니다. 캐싱은 데이터베이스 및 비즈니스와 밀접하게 통합되어 있으므로 비즈니스와 밀접하게 관련되어 있으므로 모든 경우에 적용되는 일률적인 접근 방식은 없습니다. 하지만 아직 따라야 할 몇 가지 규칙이 있습니다. 규칙 1: 프런트 엔드에 가까울수록 캐시 세분성이 커집니다. 예를 들어, 전체 페이지는 WEB의 프런트 엔드에 캐시되고, 페이지의 일부는 다음 레벨에 캐시되며, 해당 영역의 단일 레코드는 다음 레벨에 캐시됩니다. 백엔드에 가까울수록 조작성이 더 유연해지고, 가장 많이 변경되는 프런트엔드 코드를 작성하기가 더 쉽기 때문입니다. 실제로는 제품 요구 사항이 매우 빠르게 변하고 반복 주기가 점점 짧아지기 때문에 Controller와 Model을 명확하게 구분하기 어려울 때도 있습니다. Controller 수준에서는 부분적인 캐싱이 불가피하지만, 이를 보장할 필요가 있습니다. 작동 중인 캐시는 다른 데이터 요청 당사자에게 영향을 주어서는 안 됩니다. 즉, 이 캐시된 데이터가 이 컨트롤러에서만 사용되도록 보장해야 합니다. 규칙 2: 캐싱 없이는 프로그램에서 오류가 발생할 수 없습니다. 캐시 무효화로 인한 눈사태 효과를 고려하지 않으면 프로그램에 캐시가 있어야 하며 캐시가 없는 것과 동일해야 합니다. 캐시가 실패하면 팬 웨이보가 비어 있고 전체 애플리케이션이 작동하지 않습니다. 엉망. 캐싱이 필수적인 경우 오해의 소지가 있는 메시지를 제공하는 것보다 사용자에게 오류 메시지를 제공하는 것이 더 좋습니다. 규칙 3: 캐시 업데이트는 원자성 또는 스레드로부터 안전해야 합니다. 특히 수동 캐싱을 사용하는 경우 두 명의 사용자가 액세스하면 동일한 캐시가 업데이트될 가능성이 매우 높으며 일반적으로 이는 큰 문제가 아니며 캐시를 다시 구축할 수 있습니다. 만료된 후 이는 연쇄 반응의 원인 중 하나일 수 있습니다. 규칙 4: 캐싱에도 비용이 듭니다. 기술 비용뿐만 아니라 노동 시간 비용도 발생합니다. 함수가 캐싱을 사용하고 사용하지 않으면 예측 가능한 액세스 양의 차이는 작지만 캐싱을 사용하면 복잡성이 증가하므로 다음 반복에서 TODO 마크를 추가하고 캐싱 처리를 추가할 필요가 없습니다.
앞서 언급했듯이 파일 저장은 독립적이므로 모든 파일 작업은 원격 호출입니다. 파일 서버에서 매우 간단한 RESTful 인터페이스를 제공할 수도 있고, xmlrpc나 json 서비스를 제공할 수도 있습니다. WEB 서버에서 생성되고 처리되는 모든 파일은 처리를 위해 인터페이스를 통해 파일 서버에 통보됩니다. 모든 파일 저장소를 제공합니다. 이러한 이유로 많은 대형 웹사이트에 이미지를 업로드하고 기사를 저장하는 작업은 두 단계로 완료됩니다.
위의 "앞서 언급한" 내용은 실제로 수많은 사람들이 말한 것입니다. 이전 기사를 기반으로 내 자신의 말로 반복했을 뿐입니다. 실제 분석의 본질은 매우 간단합니다. 좋은 기능적 논리 레이어링 외에도 디자인도 필요합니다. 데이터베이스 스토리지, 캐싱, 대기열 및 파일 서비스와 같은 외부 리소스 호출을 위한 별도의 인터페이스 귀하의 프로그램이 Amazon EC2에서 실행되고 모든 웹 서비스를 사용하는 것으로 상상할 수 있습니다. 귀하의 대기열은 그의 SQS입니다. 스토리지는 그의 S3입니다. 유일한 차이점은 Amazon의 인터페이스는 원격 호출이고 귀하의 인터페이스는 내부 호출이라는 것입니다.
지원 서비스를 인터페이스한다는 것은 MySQL을 PostgreSQL로 교체하는 데 비즈니스 처리 프로그램을 변경할 필요가 없으며 마이그레이션 팀이 비즈니스 개발팀과 너무 많은 의사소통을 할 필요조차 없다는 것을 의미합니다. 데이터베이스를 프로그래밍하는 것보다 비즈니스 개발자의 실수로 인해 성능이 저하되지 않는다는 의미입니다.
프로그램 활용 능력에 관심이 없다면 여기를 보십시오.
제품 디자인이 완료되고 프로그램 프레임워크가 구축된 후 이 시점에서 충돌이 발생할 수 있습니다. 제품 디자이너들은 자신의 아이디어가 원하는 결과를 얻지 못한다는 불만을 끊임없이 제기하고, 프로그래머들은 제품 디자인이 비현실적이라고 불평합니다. 이러한 불만은 대부분 제품 담당자가 기술을 이해하지 못하고 기술 담당자가 제품을 이해하지 못하기 때문에 발생합니다. 넓은 의미에서 제품에는 시장 전략, 마케팅 방법, 기능적 디자인 등이 포함됩니다. 제품과 기술을 논할 때 주로 기능에 초점이 맞춰져 있지만 실제 초점은 이 기능을 구현하는 데 드는 비용과 이 기능이 제공하는 이점에 있습니다. 가져올 수 있는지, 전환이 가능한지, 고려가 가능한지. 가능하다면 분쟁을 해결하십시오. 그렇지 않다면 동전을 던져서 행운을 빌어보세요. 기능 강화로 인해 지표가 터지거나, 프로젝트 지연으로 인해 전투가 지연되는 사례가 많습니다. 급진적인 의사결정자는 이익에 초점을 맞추고, 보수적인 의사결정자는 손실에 초점을 맞추고, 현명한 의사결정자는 문제가 실제로 그렇게 심각한지 여부를 고려할 것입니다.
앞으로 무슨 일이 일어날지는 누구도 예측할 수 없습니다. 그렇지 않으면 창업의 절반은 운에 달려 있습니다. 하지만 정확하게 말할 수 있는 것은 항상 존재하며, 그 자체로 말하려면 데이터에 의존해야 합니다.
100%는 아니지만 99.9%의 웹 사이트에 액세스 통계 코드가 설치되어 있습니다. 심지어 제 http://zhiyi.us 도 예외는 아니며 Xinwen Network는 항상 과학적 의사 결정과 과학적 발전에 대해 이야기합니다. 통계를 이용하면 알 수 있는 것이 많습니다. 예를 들어, 소스-타겟 전환율을 기준으로 1인당 획득 비용이 가장 낮은 채널을 분석하고, 소스-컨텐츠 접속률을 기준으로 사용자 이탈률의 원인을 추측하고, 사용자 클릭을 기준으로 링크 위치가 합리적인지 판단할 수 있습니다. 행동. 내부 연결을 찾고, 내부 및 외부 요인을 분석하고, 해당 전략을 수립하고, 이마를 두드리는 결정을 줄이기 위해 다양한 방법으로 데이터를 결합합니다. 데이터에 의존하여 작업을 지원하는 것은 매우 전문적인 문제입니다. 심오한 수학적 모델과 복잡한 수식 계산을 이해하지는 못하지만 점차적으로 B는 A로 인해 발생하고 C는 A와 B로 인해 발생한다는 사실을 알게 되었습니다. 여전히 비교적 간단합니다. .
기사 작성자: Liu Zhiyi (재인쇄 시 출처 링크와 저자를 명시해 주세요)
기사 출처: http://zhiyi.us/