현재 위치 - 법률 상담 무료 플랫폼 - 컨설팅 회사 - 전자 상거래 웹 사이트의 일반적인 프레임 워크는 무엇입니까?
전자 상거래 웹 사이트의 일반적인 프레임 워크는 무엇입니까?
대형 전자 상거래 웹 사이트 아키텍처, 발췌 7. 같은 웹 사이트의 다국어를 어떻게 처리하고, 프로필로 쿠키 또는 URL 로 판단합니까? = = = = 고객은 우리 자신의 회사이므로 표준 방법을 사용할 수 있습니다.

8. 전자상거래 사이트에서 가장 흔한 것은 상품의 할인 방식과 포인트 증정이다. 여기서 그들을 어떻게 설계합니까? = = = = 성숙한 규칙 엔진을 구입하십시오.

9. 대량의 주문을 동시에 발행한다면 어떻게 주문의 유효 제출을 보장할 수 있습니까?

= = MQ 는 일반적으로 전자 상거래에 사용되며 IBM MQ 가 권장됩니다. MSMQ 를 사용할 수도 있습니다.

첫 번째 요점은 데이터베이스를 잘 설계해야 한다는 것입니다. 어떤 수준에서 어떤 테이블을 분할해야 하는지, 어떤 핵심 데이터를 중복해야 하는지 고려해야 할 수 있습니다. Mysql 인 경우 스토리지 엔진과 같은 다른 문제도 고려해야 합니다.

뉴스는 순수 정적 페이지를 생성하는 것이 분명하며 데이터베이스에 대한 압력이 훨씬 적지만 정적 페이지도 관리하기가 쉽지 않아 업데이트, 삭제, 추가는 디스크 파일을 조작해야 합니다.

캐시 계층을 사용자 정의하고 캐시 논리를 제어하기 위해 타사 캐시 모듈을 사용할 수 있습니다. 만약 당신이 사용한다면. 넷은 계층별로 캐시, 페이지 캐시, 데이터 캐시 (memcache, win 에서는 비효율적임) 를 할 수 있습니다.

전자 상거래 사이트는 트랜잭션이 엄격하고 데이터베이스 설계 시 성능이 뛰어나야 하며, 높은 동시성을 지원하는 적절한 색인이 필요합니다. 그들은 종종 제품 테이블, 사용자 테이블 등의 인덱스를 검사하고, 많은 인덱스 스캔과 테이블 스캔 (로컬이라도 가능한 한 적게) 이 있는지 확인합니다.

Mssql 문은 동시 갱신을 위해 트랜잭션이 필요하지 않은 쿼리에 with(nolock) 를 추가해야 합니다.

일부 기능 모듈은 제품 방문량과 같은 자연스러운 방식으로 개발할 수 없습니다. 자주 업데이트되는 이러한 필드는 코어 테이블에 배치할 수 없습니다. 명확한 방법은 그것들을 분리하는 것이다. 필드는 반드시 bool 유형으로 자주 설계해서는 안 된다. 이렇게 하면 향후 확장을 위한 여지를 남길 수 있다. 남녀 모두 작은 체형을 추천한다.

또 다른 하나는 제품 설계가 SEO 를 충분히 고려해야 한다는 것입니다. 웹 사이트의 디렉토리 구조는 일련의 쿼리 매개변수를 휴대하는 대신 명확하고 읽기 쉽습니다.

보안을 전체적으로 파악하려면 모든 저장 프로시저를 사용하고, 프로젝트가 온라인 상태가 되기 전에 모든 데이터베이스 저장 프로시저를 익스포트하고, exec 처럼 보이는 명령문을 찾아 sp_executesql 로 바꿔야 하는지 확인하는 것이 좋습니다.

또한 MSSQL 을 사용하는 경우 MSSQL fte 를 직접 사용하여 전체 텍스트 검색을 수행할 수 있으며 속도와 정확도는 여전히 허용됩니다. 가장 중요한 것은 유지 보수, 관리 및 개발이 간단하다는 것입니다.

할인은 텔레콤 시스템을 해본 적이 있다면 텔레콤의 1 차 및 2 차 가격 기능에 따라 처리할 수 있다.

물론 더 쉽게 설계할 수 있습니다. CDN 을 사용하여 정적 페이지를 가속화하고 넷콤과 통신 간의 액세스 속도 문제를 해결하는 것이 좋습니다.

데이터 캐시에서 memcache 를 고려하는 것이 좋습니다. Net 은 각각 표현 계층과 데이터 계층에 사용할 수 있습니다.

간단한 SQL 은 저장 프로시저 없이 실행할 수 있으며 데이터베이스 서버의 처리 시간을 차지하여 교착 상태를 초래할 수 있습니다.

Mvc 는 일부 CMS 프로젝트를 적용할 것을 권장하는데, 전자상가는 그다지 적합하지 않다. 웹 사이트에서 이스케이프를 하여 웹 사이트 표시를 더욱 우호적으로 만들 수 있습니다.

데이터베이스: 쿼리를 전송하고 데이터베이스에 압력을 줄 수 있는 분산 데이터베이스를 설정하는 것이 좋습니다.

사진은 별도의 서버에 두는 것을 고려해 볼 수 있습니다. 1. 3 계층 아키텍처

2. 자필 SQL, 자필 엔티티 (생성도 가능) 및 캐시 반사 바인딩 (캐시 데이터, 캐시 매핑 관계 아님) 을 사용하여 웹 사이트의 장기적인 발전이나 자필 바의 유연한 표현을 고려해야 합니다.

3. 이 문제는 없다. 단지 상업구동, 순쇼핑, 어떤 서클도 하지 않는다, 위키.

4. 순수함. Net MVC 는 권장하지 않습니다. Webform 은 viewstate 를 하지 않고, 서버쪽 컨트롤 (repeater 제외) 과 일부 MVC 의 사고방식을 더하면 충분하다.

5. 검색 제품 섹션을 제외하고 데이터를 캐시할 필요는 없지만, 프로그램이 여러 서버에서 신속하게 배포되는 것을 고려하기 위해 직렬화할 캐시를 구성하는 많은 구성 파일이 있습니다.

물론 왕씨는 이미 완성했습니다. Jd 를 참고하면 각 사진은 업무에 따라 몇 가지 다른 사이즈에 해당한다.

7. 경험에 따르면 전자상거래 사이트가 중국어와 영어로만 이중어를 하는 것은 믿을 수 없다. (문화 사용자 습관은 단순한 언어 전환이 아니다.) 영어를 실제로 조작하려면 버전을 다시 개발해야 한다.

8. 패턴이 없습니다.

9. 로드 밸런싱 (웹, db)+ssb 비동기 데이터 처리.

10. 비즈니스 유형 로그입니까, 예외 로그입니까? 포그라운드 주문 프로세스의 예외 로그는 필요하지 않습니다. 아무 도구나 찾아 스크립트를 기록하고 계속 실행하여 언제든지 어떤 문제라도 발견할 수 있도록 메일을 보낼 수 있도록 보장해 주세요. (존 F. 케네디, 컴퓨터명언)

1 1. endeca 와 같은 타사 검색 구성 요소를 찾습니다.

12. 로드 밸런싱은 매우 간단합니다. 처음에는 소프트웨어로 완성할 수 있다. 모든 사진은 제 3 자 cdn 에 올려져 있으며 프런트 사이트는 Ajax 를 거의 사용하지 않습니다. 사용된다면 jquery 1 은 전자 상거래 사이트 사용자의 99.5% 동작을 발견할 수 있습니다.

2. 상품 검색의 경우 데이터베이스를 사용하지 않아도 됩니다 (온라인 분사와 같은 관련 오픈 소스 플랫폼이 많이 있습니다).

3, 분산 캐시 (Memcached, Volecity), 개인 테스트 volecity 3 은 여전히 좋다.

4, 시스템 설계는 운영 가능성을 고려해야합니다. 이런 관점에서 시스템을 설계하다.

5. 전자 상거래 사이트가 자주 변하기 때문에 아키텍처 설계가 빈번한 버전 업데이트에 어떻게 적응할 수 있는지 고려해야 합니다.

좋은 싱글 사인온 시스템을 설계해야합니다.

7. SQLServer 가 필요하지 않은 것이 좋습니다.

8. 대형 전자 상거래 웹 사이트의 경우 시스템의 I/O 가 CPU 와 메모리가 아닌 결정적인 요소입니다. 1. 프로젝트 분할에 문제가 있습니까? 그림에는 물리적 계층, 데이터 액세스 인터페이스 계층, 데이터 액세스 인터페이스 계층, 비즈니스 논리 인터페이스 계층, 비즈니스 논리 및 웹 사이트 A, B, C 가 있습니다.

프로젝트 분할은 중요하지 않습니다. 코드를 쓸 때 코드를 해당 프로젝트로 합리적으로 나눌 수 있는지 여부가 중요합니다.

2. 개발 효율성의 데이터 액세스 계층 (NBear, Linq, Nh 등) 입니다. ) 또는 액세스 효율성 (SQL 등을 직접 사용하십시오. )? 먼저 개발 효율이 높은 것으로 나중에 방문량이 많을 때까지 기다렸다가 데이터 액세스 계층을 다시 쓸 수 있습니까?

개발 효율을 우선적으로 고려하다. 대량의 방문을 거쳐 나는 돈이 하드웨어에 투자될 것이라고 믿는다. 프로그램이 그리 나쁘지 않은 상황에서 하드웨어 업그레이드는 최적화 프로그램보다 훨씬 경제적입니다.

3. 이 사이트는 이미 여러 하위 사이트로 잘렸으며, 일부 컨트롤 (예: 머리글, 바닥글) 은 공유됩니다. 웹 사이트 프로젝트 간에 이러한 컨트롤을 공유하려면 어떻게 해야 합니까?

그런 다음 사용자 정의 컨트롤로 만듭니다.

4.4.ms 의 MVC 1.0 은 이미 나왔다. 프로젝트에서 사용하기에 충분히 성숙합니까? 아니면 웹 사이트 배경용 웹 폼, 프런트용 MVC 인가요?

프런트에서는 webform 과 MVC 를 추천합니다. 프런트에서 MVC 는 성능을 향상시키고 페이지 표현을 쉽게 변경할 수 있습니다. 백그라운드 인터페이스는 비교적 안정적이며 webform 을 사용하면 개발 효율성을 높일 수 있습니다.

5. 해시 테이블 같은 것을 개발하여 웹 사이트 데이터의 캐시를 유지합니까, 아니면 Memcached 를 사용합니까?

처음에는 hashtable 을 사용하는 것이 좋습니다. 간단하기 때문에 나중에 Memcached 로 업그레이드될 것입니다.

6. 축소판 처리, 일부 사이트는 사진을 업로드할 때 직접 생성되는 것 같아요. 어떤 사이트는 자신의 리소스 파일 구현이고, 현재 언어는 쿠키에 저장되어 있습니다.

8. 전자상거래 사이트에서 가장 흔한 것은 상품의 할인 방식과 포인트 증정이다. 여기서 그들을 어떻게 설계합니까?

규칙 엔진

9. 대량의 주문을 동시에 발행한다면 어떻게 주문의 유효 제출을 보장할 수 있습니까?

MQ 대기열 사용

10.log4net?

Log4net 은 프로그램 실행 로그만 기록할 수 있으며 주로 디버거에 사용됩니다. 너는 반드시 표를 만들어 시스템 업무 운영 로그를 보존해야 한다.

1 1. 전자 상거래의 전체 텍스트 검색도 골치 아픈 문제다.

Lucene, Microsoft 인덱싱 서비스, SQL 서버 전체 텍스트 검색, 많은 방안.

12. 로드 밸런싱에 좋은 문장 추천 코드가 있습니까?

문장 1 windows 2003 의 클러스터 정보를 읽을 수 있습니다. 프로젝트 구분에 문제가 있습니까? 그림은 엔티티 계층, 데이터 액세스 인터페이스 계층, 데이터 액세스 계층, 비즈니스 논리 인터페이스 계층, 비즈니스 논리, 웹 사이트 A, B, C 입니다.

현재 나도 이렇게 나누지만, 데이터 테이블 구조를 수정할 때 다른 계층의 계단식 수정을 유도하는 것이 불편하기 때문에 개발 전에 데이터베이스를 설계하는 것이 가장 좋다. (윌리엄 셰익스피어, 템플릿, 데이터베이스, 데이터베이스, 데이터베이스, 데이터베이스, 데이터베이스, 데이터베이스, 데이터베이스, 데이터베이스) 또한 사이트가 여러 사이트로 나뉘면 다른 프로젝트에서 생성된 DLL 파일은 각 사이트의 bin 폴더에 배포되고 각 업데이트는 재배포됩니다. 이것도 귀찮아요. 물론 DLL 을 GAC 에 배포하여 이 문제를 해결할 수는 있지만, 프로젝트가 변경되면 결과 DLL 을 GAC 에 다시 복사해야 효과를 볼 수 있기 때문에 로컬에서 디버깅하는 것은 불편합니다.

2. 개발 효율성의 데이터 액세스 계층 (NBear, Linq, Nh 등) 입니다. ) 또는 액세스 효율성 (SQL 등을 직접 사용하십시오. )? 먼저 개발 효율이 높은 것으로 나중에 방문량이 많을 때까지 기다렸다가 데이터 액세스 계층을 다시 쓸 수 있습니까?

나도 이 문제를 고려하고 있다. 현재 나는 아직 ORM 프레임워크를 채택하지 않고 DAL 에서 직접 DB 에 액세스한다.

3. 이 사이트는 이미 여러 하위 사이트로 잘렸으며, 일부 컨트롤 (예: 머리글, 바닥글) 은 공유됩니다. 웹 사이트 프로젝트 간에 이러한 컨트롤을 공유하려면 어떻게 해야 합니까?

컨트롤을 사용자 정의합니다.

4.4.ms 의 MVC 1.0 은 이미 나왔다. 프로젝트에서 사용하기에 충분히 성숙합니까? 아니면 웹 사이트 배경용 웹 폼, 프런트용 MVC 인가요?

나는 이 곡을 배우고 있다.

5. 해시 테이블 같은 것을 개발하여 웹 사이트 데이터의 캐시를 유지합니까, 아니면 Memcached 를 사용합니까?

이제 더 많은 데이터 캐시를 사용합니다. 그물.

6. 축소판 처리, 일부 사이트는 사진을 올릴 때 직접 생성되는 것 같아요. 어떤 사이트는?

현재 직접 코드를 작성하여 라이브러리에 보관하다.

1 1. 전자 상거래의 전체 텍스트 검색도 골치 아픈 문제다.

Lucene.net 분사를 사용하여 색인을 만든 다음 인덱스 데이터베이스에서 직접 검색하면 빠르고 정확합니다.

12. 로드 밸런싱에 좋은 문장 추천 코드가 있습니까?

잘 모르겠어요. 이런 디자인은 절대 새로운 알의 효과를 얻을 수 없다. 새 알에는 최소 수백 대의 서버가 있으며, 데이터베이스 간에 수천 개의 게시 및 가입 링크가 있습니다. 복잡한 캐시 및 로드 밸런싱 메커니즘이 있습니다. 새 알의 모든 통신은 WCF 를 기반으로 한다. 또한 이렇게 큰 웹 사이트에서는 데이터베이스가 멈추지 않으므로 읽기 및 쓰기 분리도 중요합니다. 백업을 위해 데이터베이스를 중지할 수 없기 때문입니다. 결국, 새로운 알과 같은 대형 전자 상거래 사이트를 만드는 것만으로는 충분하지 않은 것 같다.

그러나 공용 머리글 바닥글에 대해서는 사용자 정의 컨트롤로 만들지 않는 것이 좋습니다. 이렇게 유지하는 것이 불편하고 약간의 변경만으로 dll 을 석방하는 것은 번거롭다.

머리글 바닥글이 크지 않으면 js+css 를 사용하는 것이 좋습니다. 압축과 cdn 캐시까지 합치면 효율적으로 받아들일 수 있을 것이다.