Laravel5.2 블로그 실용 동영상 튜토리얼 리소스 추천

Laravel은 간단하고 우아한 PHP 웹 개발 프레임워크(PHP 웹 프레임워크)입니다. 누들과 같은 지저분한 코드에서 벗어날 수 있으며 완벽한 네트워크 앱을 구축하는 데 도움이 될 수 있으며 모든 코드 줄은 간결하고 표현력이 뛰어납니다. 그래서 우리는 진정한 숙달 입문서인 프로젝트 실제 전투에 초점을 맞춘 Laravel5.2 실무 개발 튜토리얼 세트인 "Laravel5.2 블로그 실용 비디오 튜토리얼"을 모았습니다. 모든 사람이 Laravel 프레임워크를 더 잘 배우는 데 도움이 되기를 바랍니다.

강좌 재생 주소: http://www.php.cn/course/283.html

선생님의 강의 스타일:

강의는 친절하고 자연스러우며 가식 없고 가식적이지 않습니다. 고의적으로 과장하지 않고 설득력 있고 자세하게 이야기하면서 교사와 학생은 평등, 협력, 조화의 분위기에서 침묵의 감정 교환을 하며 지식에 대한 갈증과 탐구를 단순성과 진정성으로 통합합니다. 가르치는 상황에서 학생들은 지식을 얻습니다. 조용한 생각과 조용한 승인을 통해

이 영상에서 더 어려운 점은 HTTP 미들웨어입니다:

-- 미들웨어란?
1. 미들웨어가 필요한 이유

컴퓨터 기술은 빠르게 발전하고 있습니다. 하드웨어 기술의 관점에서 볼 때 CPU 속도는 점점 더 빨라지고 있으며, 소프트웨어 기술의 관점에서 볼 때 처리 능력은 점점 더 강력해지고 있습니다. 특히 인터넷과 WWW의 출현으로 인해 응용 프로그램의 규모가 지속적으로 확대되고 있습니다. , 이는 컴퓨터의 응용 범위를 더 넓고 더 많은 응용 프로그램으로 만듭니다. 프로그램은 네트워크 환경의 이기종 플랫폼에서 실행되어야 합니다. 이 모든 것은 차세대 소프트웨어 개발에 대한 새로운 요구를 제시합니다. 이러한 분산된 이기종 환경에는 일반적으로 여러 하드웨어 시스템 플랫폼(예: PC, 워크스테이션, 미니컴퓨터 등)이 있고 이러한 하드웨어 플랫폼에는 다양한 시스템 소프트웨어(예: 다양한 운영 체제, 데이터베이스 등)가 있습니다. 컴파일러 등)뿐만 아니라 다양한 스타일의 다양한 사용자 인터페이스도 이러한 하드웨어 시스템 플랫폼을 사용하여 연결할 수 있습니다. 이러한 시스템을 통합하고 새로운 애플리케이션을 개발하는 방법은 매우 현실적이고 어려운 문제입니다.

II 미들웨어란 무엇인가

분산된 이질성 문제를 해결하기 위해 사람들은 미들웨어라는 개념을 제안했습니다. 미들웨어는 그림 1과 같이 플랫폼(하드웨어 및 운영 체제)과 애플리케이션 사이에 위치한 범용 서비스입니다. 이러한 서비스에는 표준 프로그램 인터페이스와 프로토콜이 있습니다. 다양한 운영 체제 및 하드웨어 플랫폼의 경우 인터페이스 및 프로토콜 사양을 준수하는 여러 구현을 가질 수 있습니다.

미들웨어에 대해 엄격한 정의를 내리는 것은 어려울 수 있지만 미들웨어는 다음과 같은 특성을 가져야 합니다.

다양한 애플리케이션의 요구 사항을 충족합니다.
다양한 하드웨어 및 OS 플랫폼에서 실행됩니다.
분산 컴퓨팅을 지원하고 크로스-컴퓨팅을 제공합니다. 네트워크, 하드웨어 및 OS 플랫폼 투명성을 갖춘 애플리케이션 또는 서비스의 상호 작용
표준 프로토콜 지원
표준 인터페이스 지원

이식성을 위한 표준 인터페이스와 상호 운용성을 위한 표준 프로토콜의 중요성으로 인해 미들웨어는 많은 표준화 노력의 주요 부분이 되었습니다. 응용 프로그램 소프트웨어 개발에 있어 미들웨어는 운영 체제 및 네트워크 서비스보다 훨씬 더 중요합니다. 미들웨어가 제공하는 프로그램 인터페이스는 기본 컴퓨터 하드웨어 및 시스템 소프트웨어가 어떻게 업데이트되는지에 관계없이 비교적 안정적인 고급 응용 프로그램 환경을 정의합니다. 미들웨어는 업그레이드 및 업데이트하고 미들웨어의 외부 인터페이스 정의를 변경하지 않고 유지하며 응용 프로그램 소프트웨어는 거의 수정이 필요하지 않으므로 응용 소프트웨어 개발 및 유지 관리에 대한 회사의 상당한 투자를 보호합니다.

3. 주요 미들웨어 분류

미들웨어는 매우 넓은 범위를 포괄하며, 다양한 애플리케이션 요구에 맞게 다양하고 독특한 미들웨어 제품이 등장했습니다. 그러나 아직까지 미들웨어에 대한 정확한 정의가 없기 때문에 관점이나 수준에 따라 미들웨어의 분류가 달라질 수 있습니다. 미들웨어는 분산 환경에서 이종 운영체제와 네트워크 프로토콜을 보호해야 하기 때문에 분산 환경에서 통신 서비스를 제공할 수 있어야 합니다. 다양한 목적과 구현 메커니즘을 기반으로 플랫폼을 다음과 같은 주요 범주로 나눕니다.

원격 프로시저 호출
메시지 지향 미들웨어
객체 요청 브로커

동기화, 대기열, 구독을 포함하여 위쪽으로 다양한 형태의 통신 서비스를 제공할 수 있습니다. 출판, 방송 등 이러한 기본 통신 플랫폼 위에 다양한 프레임워크를 구축하여 트랜잭션 처리 모니터, 분산 데이터 액세스, 객체 트랜잭션 관리자 OTM 등 다양한 분야의 서비스를 애플리케이션에 제공할 수 있습니다. 플랫폼은 상위 계층 애플리케이션을 위한 이기종 플랫폼 간의 차이점을 보호하며, 플랫폼의 프레임워크는 해당 분야 애플리케이션의 시스템 구조, 표준 서비스 구성 요소 등을 정의합니다. 사용자는 관심 있는 이벤트만 프레임워크에 알리면 됩니다. , 이러한 이벤트 코드에 대한 처리를 제공합니다. 이벤트가 발생하면 프레임워크는 사용자의 코드를 호출합니다. 사용자 코드는 프레임워크를 호출할 필요가 없으며 사용자 프로그램은 프레임워크 구조, 실행 흐름, 시스템 수준 API 호출 등을 신경 쓸 필요가 없습니다. 이 모든 작업은 프레임워크에 의해 완료됩니다. 따라서 미들웨어를 기반으로 개발된 애플리케이션은 확장성이 좋고 관리가 용이하며 가용성이 높고 이식성이 뛰어납니다.

다음은 여러 주요 유형의 미들웨어에 대해 간략하게 소개합니다.

1. 원격 절차 호출

원격 절차 호출은 널리 사용되는 분산 응용 프로그램 처리 방법입니다. 응용 프로그램은 RPC를 사용하여 다른 주소 공간에 있는 프로세스를 "원격으로" 실행하고 로컬 호출을 실행하는 것과 동일한 효과를 갖습니다. 실제로 RPC 애플리케이션은 서버와 클라이언트라는 두 부분으로 나뉩니다. 서버는 하나 이상의 원격 프로시저를 제공합니다. 클라이언트는 서버에 원격 호출을 수행합니다. 서버와 클라이언트는 동일한 컴퓨터에 있을 수도 있고, 다른 컴퓨터에 있을 수도 있고, 심지어 다른 운영 체제에서 실행될 수도 있습니다. 그들은 네트워크를 통해 통신합니다. 해당 스텁 및 런타임 지원은 데이터 변환 및 통신 서비스를 제공하여 다양한 운영 체제 및 네트워크 프로토콜을 보호합니다. 여기서 RPC 통신은 동기식입니다. 스레드를 사용하여 비동기 호출을 수행할 수 있습니다.

RPC 모델에서는 클라이언트와 서버가 해당 RPC 인터페이스를 갖고 있고 RPC 실행을 지원하는 한 특정 서버에 국한되지 않고 해당 상호 운용을 완료할 수 있습니다. 따라서 RPC는 클라이언트/서버 분산 컴퓨팅을 강력하게 지원합니다. 동시에 원격 프로시저 호출 RPC는 프로세스 기반 서비스 액세스를 제공하며 클라이언트와 서버가 직접 연결되어 있으며 요청을 처리하는 중개 기관이 없으므로 일정한 제한 사항도 있습니다. 예를 들어 RPC에는 일반적으로 클라이언트가 요청할 때 서버를 찾으려면 일부 네트워크 세부 정보가 필요합니다.

2. 메시지 지향 미들웨어

MOM은 플랫폼 독립적인 데이터 교환을 위해 효율적이고 안정적인 메시지 전달 메커니즘을 사용하고 데이터 통신을 기반으로 분산 시스템을 통합하는 것을 말합니다. 메시지 전달 및 메시지 큐잉 모델을 제공함으로써 분산 환경에서 프로세스 간 통신을 확장하고 여러 통신 프로토콜, 언어, 애플리케이션, 하드웨어 및 소프트웨어 플랫폼을 지원합니다. 현재 인기 있는 MOM 미들웨어 제품으로는 IBM의 MQSeries, BEA의 MessageQ 등이 있습니다. 메시지 전달 및 대기열 기술에는 다음 세 가지

주요 기능이 있습니다.

통신 프로그램은 서로 다른 시간에 실행될 수 있습니다. 프로그램은 네트워크에서 직접 서로 대화하지 않지만 직접적인 연결이 없기 때문에 메시지를 메시지 대기열에 간접적으로 넣습니다. 프로그램 사이. 따라서 동시에 실행할 필요가 없습니다. 메시지가 적절한 큐에 배치될 때 대상 프로그램이 실행 중일 필요도 없습니다. 대상 프로그램이 실행 중이더라도 메시지를 즉시 처리할 수는 없습니다.

응용 프로그램의 구조에는 제약이 없습니다. 복잡한 응용 시나리오에서 통신 프로그램은 일대일 관계뿐만 아니라 일대다 및 다대일 방법 또는 심지어 두 가지의 조합을 가질 수도 있습니다. 위의 방법. 여러 통신 방법을 구축한다고 해서 애플리케이션의 복잡성이 증가하지는 않습니다.

프로그램은 네트워크 복잡성으로부터 격리됩니다.

프로그램은 통신을 위해 메시지를 메시지 대기열에 넣거나 메시지 대기열에서 메시지를 꺼내며, 메시지 대기열 유지, 프로그램 간의 관계 유지 등 이와 관련된 모든 활동을 수행합니다. 큐, 네트워크 다시 시작 처리 및 네트워크를 통한 메시지 이동은 MOM의 작업입니다. 프로그램은 다른 프로그램과 직접 통신하지 않으며 네트워크 통신의 복잡성을 포함하지 않습니다.

3. 객체 요청 에이전트

객체 기술과 분산 컴퓨팅 기술의 발전으로 이 둘이 결합되어 분산 객체 컴퓨팅이 형성되었으며, 이는 오늘날 소프트웨어 기술의 주류 방향으로 발전했습니다. 1990년 말에 객체 관리 그룹 OMG는 객체 관리 아키텍처 OMA(Object Management Architecture)를 처음으로 출시했습니다. 객체 요청 브로커는 이 모델의 핵심 구성 요소입니다. 그 역할은 이기종 분산 컴퓨팅 환경에서 개체 요청을 투명하게 전달하기 위한 통신 프레임워크를 제공하는 것입니다. CORBA 사양에는 ORB의 모든 표준 인터페이스가 포함되어 있습니다. 1991년에 출시된 CORBA 1.1은 인터페이스 설명 언어 OMG IDL과 특정 ORB에서 상호 운용되는 클라이언트/서버 개체를 지원하는 API를 정의했습니다. CORBA 2.0 사양은 여러 공급업체에서 제공하는 ORB 간의 상호 운용성을 설명합니다.

ORB(Object Request Broker)는 CORBA 사양의 핵심인 객체 버스로, 이기종 환경에서 객체가 투명하게 요청을 보내고 응답을 받을 수 있는 기본 메커니즘을 정의합니다. 객체 간의 관계. ORB를 사용하면 개체가 투명하게 다른 개체에 요청하거나 로컬 또는 원격 시스템에 있는 다른 개체로부터 응답을 받을 수 있습니다. ORB는 요청 호출을 가로채서 요청을 구현할 수 있는 객체 찾기, 매개변수 전송, 해당 메서드 호출, 결과 반환 등을 담당합니다. 클라이언트 객체는 서버 객체와 통신하는 메커니즘, 서버 객체를 활성화하거나 저장하는 메커니즘을 알지 못하며, 서버 객체가 어디에 있는지, 어떤 언어로 구현되는지, 어떤 운영 체제가 사용되는지 등을 알 필요도 없습니다. 개체 인터페이스의 일부가 아닌 시스템 구성 요소입니다.

클라이언트 및 서버 역할은 해당 경우에 따라 ORB의 개체가 클라이언트, 서버 또는 둘 다일 수 있음을 조정하는 데만 사용된다는 점을 지적할 가치가 있습니다. 개체가 요청을 하면 클라이언트 역할이 되고, 요청을 받으면 서버 역할이 됩니다. 대부분의 개체는 클라이언트 역할과 서버 역할을 모두 수행합니다. 또한 ORB는 객체 요청 전송과 서버 관리를 담당하므로 클라이언트와 서버 사이에 직접적인 연결이 없으므로 RPC가 지원하는 단순한 클라이언트/서버 구조에 비해 ORB는 더 복잡한 구조를 지원할 수 있습니다.

4. 트랜잭션 처리 모니터링

트랜잭션 처리 모니터는 메인프레임에 처음 등장하여 대규모 트랜잭션 처리를 지원하는 안정적인 운영 환경을 제공합니다. 분산 컴퓨팅 기술의 발전과 함께 분산 응용 시스템은 상업 활동에서 대량의 핵심 거래를 처리하는 등 대규모 거래 처리에 대한 수요를 제시했습니다. 트랜잭션 처리 모니터링은 클라이언트와 서버 사이에서 트랜잭션 관리 및 조정, 로드 밸런싱, 장애 복구 등을 수행하여 시스템의 전반적인 성능을 향상시킵니다. 트랜잭션 처리 애플리케이션을 위한 "운영 체제"로 생각할 수 있습니다. 일반적으로 트랜잭션 처리 모니터링에는 다음과 같은 기능이 있습니다.

서버 프로세스 시작, 작업 할당, 실행 모니터링 및 로드 밸런싱을 포함한 프로세스 관리.
트랜잭션 관리는 감독 하에 트랜잭션 처리의 원자성, 일관성, 독립성 및 내구성을 보장합니다.
통신 관리는 요청 응답, 세션, 큐잉, 구독 게시 및 브로드캐스트 등을 포함하여 클라이언트와 서버 간의 다양한 통신 메커니즘을 제공합니다.
거래 처리 모니터링은 비행기 티켓팅 시스템과 같이 다수의 고객에게 서비스를 제공할 수 있습니다. 서버가 필요한 리소스를 각 클라이언트에 할당하면 서버가 압도당하게 됩니다(그림 2 참조). 그러나 실제로 모든 클라이언트가 동시에 서비스를 요청할 필요는 없으며, 클라이언트가 서비스를 요청하면 빠른 응답을 받기를 원합니다. 트랜잭션 처리 모니터링은 운영 체제 위에서 일련의 서비스를 제공하고 클라이언트 요청을 관리하며 이에 대응하는 서비스 프로세스를 할당함으로써 서버가 제한된 시스템 자원으로 대규모 고객에게 효율적으로 서비스를 제공할 수 있도록 합니다.

위 내용은 Laravel5.2 블로그 실용 동영상 튜토리얼 리소스 추천의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!