PHP 마이크로서비스 클러스터 구축 - Hyperf

마이크로서비스 아키텍처

마이크로서비스의 개념은 2014년 3월 Martin Fowler가 제안했습니다.

마이크로서비스 아키텍처는 단일 애플리케이션을 작은 서비스 집합으로 나누고 서비스가 서로 상호 작용하는 것을 옹호하는 아키텍처 패턴입니다. 사용자에게 궁극적인 가치를 제공하기 위해 서로 협력합니다. 각 서비스는 자체적인 독립적인 프로세스에서 실행되며 서비스는 경량 통신 메커니즘을 사용하여 서로 통신합니다. 각 서비스는 특정 비즈니스를 중심으로 구축되었으며 프로덕션 환경, 프로덕션과 유사한 환경 등에 독립적으로 배포될 수 있습니다. 또한, 특정 서비스의 경우 비즈니스 상황에 따라 적절한 언어와 도구를 선택하여 통합되고 중앙 집중화된 서비스 관리 메커니즘을 최대한 피해야 합니다.

다음 그림은 전자상거래 시스템의 마이크로서비스 아키텍처 다이어그램입니다.

단일 애플리케이션에 비해 마이크로서비스 아키텍처는 다음과 같은 장점이 있습니다.

1. 각 서비스는 상대적으로 간단하며 하나의 비즈니스에만 집중합니다.

2. 마이크로서비스 아키텍처는 느슨하게 결합되어 있으며 각 서비스는 독립적으로 테스트, 배포, 업그레이드 및 출시될 수 있습니다.

3. 각 마이크로서비스는 서로 다른 팀에서 독립적으로 개발할 수 있습니다. 가장 적합한 것. 다양한 프로그래밍 언어 및 도구

4. 각 서비스는 시스템 동시성을 향상시키기 위해 필요에 따라 수평으로 확장될 수 있습니다.

만약의 묘책은 없습니다. 마이크로서비스 아키텍처는 많은 이점을 제공하지만 다음과 같은 단점도 있습니다.

1. 마이크로서비스 아키텍처는 시스템의 복잡성을 증가시키고 운영 및 유지 관리 오버헤드와 비용을 증가시킵니다. 예를 들어, 단일 애플리케이션은 소규모 애플리케이션 서비스 클러스터에만 배포하면 되는 반면, 마이크로서비스 아키텍처는 수십 개의 독립적인 서비스를 구축/테스트/배포/실행해야 할 수 있으며 여러 언어와 환경을 지원해야 할 수 있습니다.

2 분산 시스템으로서 마이크로서비스 아키텍처는 메시지 직렬화, 네트워크 지연, 비동기 메커니즘, 내결함성 처리, 서비스 사태 등과 같은 여러 가지 다른 문제를 발생시킵니다.

3. 등록, 검색, 성능 저하, 회로 차단기 등의 문제

4. 서비스 간에 상호 호출이 발생하므로 시스템 오류를 해결하는 데 큰 어려움이 따릅니다.

기존 애플리케이션 아키텍처의 시스템이 점점 더 비대해지고 유지 및 확장이 어려운 문제에 직면하고 있다고 할 수 있습니다. 동시에 컨테이너화 기술(Docker)의 급속한 발전과 성숙도도 높아지고 있습니다. DevOps 아이디어로 인해 새로운 아키텍처 디자인 스타일이 탄생했습니다. 즉, 마이크로서비스 아키텍처의 출현입니다.

RPC 프레임워크

마이크로서비스 아키텍처의 다양한 서비스는 일반적으로 동일한 머신에 있지 않거나 심지어 동일한 네트워크 환경에도 없습니다. 따라서 마이크로서비스 간 호출 방법은 일반적으로 RPC를 사용하여 해결해야 할 시급한 문제입니다. 해결해야 할 프로토콜:

RPC(Remote Procedure Call)는 원격 프로시저 호출을 의미하는 컴퓨터 통신 프로토콜입니다. 이 프로토콜을 사용하면 프로그래머가 상호 작용을 추가로 프로그래밍할 필요 없이 한 컴퓨터에서 실행되는 프로그램이 다른 컴퓨터의 서브루틴을 호출할 수 있습니다. ——Wikipedia

는 서버와 호출자가 다양한 기본 세부 정보를 보호할 수 있도록 하는 RPC 프로토콜의 프레임워크를 구현하여 호출자가 로컬 함수를 호출하는 것처럼 원격 함수(서비스)를 호출할 수 있도록 합니다. RPC 프레임워크는 일반적으로 서버와 클라이언트에 대한 직렬화, 역직렬화, 연결 풀 관리, 로드 밸런싱, 장애 조치, 대기열 관리, 시간 초과 관리, 비동기 관리 및 기타 기능을 제공합니다. 인터넷에서 RPC 프레임워크의 작동 원리를 설명하는 다이어그램을 찾았습니다.

현재 데이터 직렬화에 사용되는 다양한 기술에 따라 JSON-RPC와 gRPC의 두 가지 유형으로 나눌 수 있습니다.

1 JSON-RPC는 JSON 형식을 기반으로 하는 경량 RPC 프로토콜 표준으로, HTTP 프로토콜을 기반으로 전송하거나 TCP 프로토콜을 기반으로 직접 전송할 수 있습니다. JSON-RPC의 장점은 사용과 읽기가 쉽다는 것입니다.

2. gRPC는 Google에서 주로 모바일 애플리케이션 개발을 위해 설계한 고성능 범용 오픈 소스 RPC 프레임워크로, ProtoBuf(프로토콜 버퍼)를 기반으로 개발되었습니다. 직렬화 프로토콜이며 다양한 개발 언어를 지원합니다. gRPC는 낮은 지연 시간, 높은 효율성, 높은 확장성, 배포 지원 등의 장점을 가지고 있습니다.

Consul

이제 RPC 프레임워크를 사용하면 기본 전송 세부 사항을 고려하지 않고 서비스 간 비즈니스 호출만 고려할 수 있습니다. 이때 서비스 A가 서비스 B를 호출하려면 서비스 A에서 서비스 B의 IP 주소와 포트를 구성하고 나머지 전송 세부 사항은 RPC 프레임워크에 맡길 수 있습니다. 마이크로서비스 규모가 작을 때는 문제가 되지 않지만, 서비스 규모가 크고 각 서비스의 인스턴스가 두 개 이상 배포되면 큰 문제에 직면하게 됩니다. 예를 들어 서비스 B에는 세 개의 인스턴스가 배포되어 있습니다. 서비스 A가 서비스 B를 호출하려는 경우 어떤 인스턴스 IP를 요청해야 합니까? 서비스 B가 배포한 인스턴스 3개 중 2개가 다운된 경우 서비스 A는 여전히 중단된 인스턴스를 요청할 수 있으며 서비스를 사용할 수 없게 됩니다. IP 주소와 포트를 구성 파일에 쓰는 것은 매우 유연하지 않습니다. 마이크로서비스 아키텍처는 고가용성과 동적 확장을 보장해야 하는 경우가 많습니다.

따라서 서비스 정보를 동적으로 변경하고 사용 가능한 서비스의 IP 주소와 포트를 찾을 수 있는 서비스 등록 및 서비스 검색 도구가 필요합니다. 현재 시장에는 Consul, ZooKeeper, Etcd, Doozerd 등과 같은 많은 서비스 검색 도구가 있습니다. 이 기사에서는 주로 Consul 소프트웨어를 예로 들어 보겠습니다.

Consul은 다중 데이터 센터, 분산형 고가용성 서비스 검색 및 구성 공유를 지원하는 서비스 소프트웨어입니다. HashiCorp에서 Go 언어로 개발되었으며 Mozilla Public License 2.0 계약을 기반으로 하는 오픈 소스입니다. Consul은 상태 확인을 지원하고 HTTP, gRPC 및 DNS 프로토콜이 API를 호출하여 키-값 쌍을 저장하도록 허용합니다.

다음은 서비스 등록 및 서비스 검색 도구 도입 후의 아키텍처 다이어그램입니다.

이 아키텍처에서:

먼저 S-B 인스턴스가 시작된 후 자체 서비스 정보(주로 IP 주소 및 서비스의 포트 번호) )가 Consul에 등록됩니다.

Consul은 등록된 모든 서비스에 대해 상태 점검을 수행하여 사용 가능한 서비스 인스턴스와 그렇지 않은 서비스 인스턴스를 결정합니다.

S-A가 시작된 후 Consul에 액세스하여 모든 정상 S-B 인스턴스의 IP 및 포트를 얻을 수 있으며 이 정보를 자체 메모리에 저장하여 S-B를 호출할 수 있습니다.

S-A는 Consul의 말을 듣고 메모리에 저장된 S-B의 서비스 정보를 업데이트할 수 있습니다. 예를 들어 S-B-1이 전화를 끊으면 상태 확인 메커니즘은 해당 정보 변경 사항을 S-A에서 모니터링하고 S-A는 자체 메모리에서 S-B-1의 서비스 정보를 업데이트합니다.

Consul 소프트웨어는 서비스 등록 및 서비스 검색 기능 외에도 상태 확인 및 상태 변경 알림 기능도 제공하는 것을 볼 수 있습니다.

Hyperf

Java 개발자의 경우 선택할 수 있는 매우 성숙한 Dubbo 및 Spring Cloud 마이크로서비스 프레임워크가 있습니다. PHPer로서 구글을 이용해 "PHP + 마이크로서비스"를 확인해 본 결과 유용한 관련 콘텐츠가 거의 없고 실질적인 참고 가치도 없어 한없이 실망했습니다. . . 다행스럽게도 일부 전문가들은 Swoole 확장을 기반으로 하는 고성능 및 유연성이 뛰어난 PHP 코루틴 프레임워크 Hyperf를 구현하고 마이크로서비스 아키텍처의 관련 구성 요소를 제공했습니다.

Hyperf는 Swoole 4.3+를 기반으로 하는 고성능, 유연성이 뛰어난 PHP 코루틴 프레임워크입니다. 내장형 코루틴 서버와 일반적으로 사용되는 많은 구성 요소가 있으며, PHP 기반의 기존 프레임워크에 비해 성능이 질적으로 향상되었습니다. -FPM은 매우 높은 성능을 제공하는 동시에 매우 유연한 확장성을 유지합니다. 표준 구성 요소는 PSR 표준을 기반으로 구현되며 강력한 종속성 주입 설계를 기반으로 하여 대부분의 구성 요소 또는 클래스를 교체할 수 있습니다. 그리고 재사용이 가능합니다.

그래서 마이크로서비스 아키텍처와 관련된 기본 지식을 배운 후 Hyperf 프레임워크를 사용하여 PHP 기반 마이크로서비스 클러스터를 구축했습니다. 프로젝트 소스 코드 주소는 https://github.com/Jochen-z/p입니다. .. 프로젝트는 Dokcer를 사용하여 구축되었습니다. docker-compose.yml 코드는 다음과 같습니다:

version: "3"
services:
  consul-server-leader:
    image: consul:latest
    container_name: consul-server-leader
    command: "agent -server -bootstrap -ui -node=consul-server-leader -client=0.0.0.0"
    environment:
      - CONSUL_BIND_INTERFACE=eth0
    ports:
      - "8500:8500"
    networks:
      - microservice
  microservice-1:
    build:
      context: .
    container_name: "microservice-1"
    command: "php bin/hyperf.php start"
    depends_on:
      - "consul-server-leader"
    volumes:
      - ./www/microservice-1:/var/www
    networks:
      - microservice
    tty: true
  microservice-2:
    build:
      context: .
    container_name: "microservice-2"
    command: "php bin/hyperf.php start"
    depends_on:
      - "consul-server-leader"
    volumes:
      - ./www/microservice-2:/var/www
    networks:
      - microservice
    tty: true
  app:
    build:
      context: .
    container_name: "app"
    command: "php bin/hyperf.php start"
    depends_on:
      - "microservice-1"
    volumes:
      - ./www/web:/var/www
    ports:
      - "9501:9501"
    networks:
      - microservice
    tty: true
networks:
  microservice:
    driver: bridge
volumes:
  microservice:
    driver: local

Consul 컨테이너 consul-server-leader는 여기서 서비스 등록 및 서비스 검색의 구성 요소로 시작됩니다. 추가 작업과 나누기 작업을 각각 제공합니다. 서비스 호출자로서 컨테이너 앱은 consul-server-leader 컨테이너의 URL을 구성하고 consul-server-leader에 액세스하여 microservice-1 및 microservice-2 서비스의 IP 주소와 포트를 얻은 다음 앱이 추가를 호출합니다. 컴퓨팅 서비스는 RPC 프로토콜을 통해 결과를 얻어 사용자에게 반환합니다.

앱 컨테이너는 Hyperf 프로젝트를 배포하고 외부 세계에 HTTP 서비스를 제공하는 웹 애플리케이션입니다. 예를 들어 AppControllerIndexController 컨트롤러에는 add 메서드가 있습니다.

public function add(AdditionService $addition)
{
  $a = (int)$this->request->input('a', 1); # 接受前端用户参数
  $b = (int)$this->request->input('b', 2);
  return [
    'a' => $a,
    'b' => $b,
    'add' => $addition->add($a, $b) # RPC调用
  ];
}

AppJsonRpcAdditionService에 추가 구현:

class AdditionService extends AbstractServiceClient
{
    /**
     * 定义对应服务提供者的服务名称
     * @var string
     */
    protected $serviceName = 'AdditionService';
    /**
     * 定义对应服务提供者的服务协议
     * @var string
     */
    protected $protocol = 'jsonrpc-http';
    public function add(int $a, int $b): int
    {
        return $this->__request(__FUNCTION__, compact('a', 'b'));
    }
}

AbstractServiceClient를 상속하여 마이크로서비스 클라이언트 요청 클래스를 생성합니다. Hyperf는 하단에 Consul 및 서비스 공급자와의 연결을 구현하는 데 도움이 됩니다. 사용자 상호 작용에 대한 자세한 내용을 보려면 AdditionService 클래스의 add 메서드만 있으면 microservice-1 및 microservice-2에서 제공하는 서비스를 원격으로 호출할 수 있습니다.

이제 PHP 마이크로서비스 클러스터 구축이 완료되었습니다!

위 내용은 PHP 마이크로서비스 클러스터 구축 - Hyperf의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!