PHP microservice cluster construction - Hyperf

Microservice architecture

The concept of microservices was proposed by Martin Fowler in March 2014:

Microservice architecture is an architectural pattern that advocates A single application is divided into a set of small services, and the services coordinate and cooperate with each other to provide ultimate value to users. Each service runs in its own independent process, and services use lightweight communication mechanisms to communicate with each other. Each service is built around a specific business and can be independently deployed to production environments, production-like environments, etc. In addition, a unified and centralized service management mechanism should be avoided as much as possible. For a specific service, appropriate languages ​​and tools should be selected to build it based on the business context.

The following picture is a microservice architecture diagram of an e-commerce system:

Microservice architecture has the following advantages compared with single applications:

1. Each service is relatively simple and only focuses on one business function;

2. The microservice architecture is loosely coupled, and each service can be independently tested, deployed, upgraded, and released;

3. Each microservice can be developed independently by different teams, and each can choose the best and most appropriate programming languages ​​and tools;

4. Each service can be leveled according to needs Expand and improve system concurrency capabilities.

There is no silver bullet. While the microservice architecture brings many advantages, it also has the following disadvantages:

1. The microservice architecture increases the complexity of the system and increases the operation and maintenance overhead. and cost. For example, a single application may only need to be deployed to a small application service cluster, while a microservice architecture may require building/testing/deploying/running dozens of independent services, and may need to support multiple languages ​​and environments;

2. As a distributed system, the microservice architecture introduces several other issues, such as message serialization, network delay, asynchronous mechanism, fault tolerance processing, service avalanche, etc.;

3. Service management Complexity, such as service registration, discovery, downgrade, circuit breaker and other issues;

4. There are mutual calls between services, which brings huge challenges to troubleshooting system faults.

It can be said that it is precisely the system of traditional application architecture that has become increasingly bloated and faced problems that are difficult to maintain and expand. At the same time, the booming development of containerization technology (Docker) and the increasing maturity of DevOps ideas have given rise to new Architectural Design Style – The emergence of microservices architecture.

RPC Framework

The various services in the microservice architecture are usually not on the same machine, or even in the same network environment, so how do the microservices interact with each other? Calling is an urgent problem that needs to be solved. We usually use the RPC protocol to solve it:

RPC (Remote Procedure Call), that is, remote procedure call, is a computer communication protocol. This protocol allows a program running on one computer to call a subroutine on another computer without the programmer having to additionally program the interaction. ——Wikipedia

implements the framework of the RPC protocol, which allows the server and the caller to shield various underlying details, allowing the caller to call remote functions (services) just like calling local functions. The RPC framework generally provides serialization, deserialization, connection pool management, load balancing, failover, queue management, timeout management, asynchronous management and other functions for the server and client. I found a diagram illustrating the working principle of the RPC framework on the Internet:

#Currently, according to the different technologies used to serialize data, it can be divided into two types: JSON-RPC and gRPC:

1. JSON-RPC is a lightweight RPC protocol standard based on JSON format, which can be transmitted based on HTTP protocol or directly based on TCP protocol. The advantage of JSON-RPC is that it is easy to use and read.

2. gRPC is a high-performance, general-purpose open source RPC framework. It is designed by Google mainly for mobile application development and based on the HTTP/2 protocol standard. It is developed based on the ProtoBuf (Protocol Buffers) serialization protocol, and Supports many development languages. gRPC has the advantages of low latency, high efficiency, high scalability, and support for distribution.

Consul

Now with the RPC framework, we can only consider the business calls between services without considering the underlying transmission details. At this time, if service A wants to call service B, we can configure the IP address and port of service B in service A, and then leave the remaining transmission details to the RPC framework. This is no problem when the scale of microservices is small, but it will face huge challenges when the scale of services is large and more than one instance of each service is deployed. For example, service B has three instances deployed. At this time, service A wants to call service B. Which instance IP should it request? If two of the three instances deployed by service B are down, service A may still request the hung up instances, and the service will be unavailable. It is very inflexible to write IP addresses and ports into configuration files. Microservice architecture often needs to ensure high availability and dynamic scaling.

Therefore, we need a service registration and service discovery tool that can dynamically change service information and find the IP addresses and ports of available services. There are currently many service discovery tools on the market, such as Consul, ZooKeeper, Etcd, Doozerd, etc. This article mainly takes the Consul software as an example.

Consul is a service software that supports multi-data center, distributed high-availability service discovery and configuration sharing. It was developed by HashiCorp in Go language and is open source based on the Mozilla Public License 2.0 agreement. Consul supports health checks and allows HTTP, gRPC, and DNS protocols to call APIs to store key-value pairs.

The following is the architecture diagram after the introduction of service registration and service discovery tools:

In this architecture:

First the instance of S-B After starting, register its own service information (mainly the IP address and port number of the service) into Consul.

Consul will perform health checks on all registered services to determine which service instances are available and which are not.

After S-A starts, it can obtain the IPs and ports of all healthy S-B instances by accessing Consul, and put this information into its own memory. S-A can use this information to call S-B.

S-A can update the service information of S-B stored in the memory by listening to Consul. For example, if S-B-1 hangs up, the health check mechanism will mark it as unavailable. Such information changes will be monitored by S-A, and S-A will update the service information of S-B-1 in its own memory.

It can be seen that in addition to the functions of service registration and service discovery, Consul software also provides health check and status change notification functions.

Hyperf

For Java developers, there are quite mature Dubbo and Spring Cloud microservice frameworks to choose from. As a PHPer, I used Google to check "PHP microservices" and found that there was very little useful related content, no substantial reference value, and I was infinitely disappointed. . . Fortunately, some experts have implemented the high-performance and highly flexible PHP coroutine framework Hyperf based on the Swoole extension, and provided related components of the microservice architecture.

Hyperf is a high-performance and highly flexible PHP coroutine framework based on Swoole 4.3. It has a built-in coroutine server and a large number of commonly used components. Its performance is qualitatively improved compared to the traditional framework based on PHP-FPM, and it provides While maintaining ultra-high performance, it also maintains extremely flexible scalability. Standard components are implemented based on the PSR standard and are based on a powerful dependency injection design, which ensures that most components or classes are replaceable and reusable.

So, after learning the basic knowledge related to microservice architecture, I used the Hyperf framework to build a PHP-based microservice cluster. This is the project source code address: https://github.com/Jochen- z/p…. The project is built using Dokcer. The docker-compose.yml code is as follows:

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

Here a Consul container consul-server-leader is started as a component of service registration and service discovery. The containers microservice-1 and microservice-2 are respectively Provides addition and division operations. As the service caller, the container app configures the URL of the consul-server-leader container, obtains the IP addresses and ports of the microservice-1 and microservice-2 services by accessing consul-server-leader, and then the app calls addition and division through the RPC protocol. The computing service obtains the results and returns them to the user.

The app container is a web application that deploys a Hyperf project and provides HTTP services to the outside world. For example, there is an add method in the App\Controller\IndexController controller:

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调用
  ];
}

The implementation of add in App\JsonRpc\AdditionService:

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'));
    }
}

Inherits AbstractServiceClient to create a microservice client End request class, Hyperf helps us implement the details of interaction with Consul and service providers at the bottom level. We only need the add method in the AdditionService class to remotely call the services provided by microservice-1 and microservice-2.

At this point, the PHP microservice cluster construction is completed!

The above is the detailed content of PHP microservice cluster construction - Hyperf. For more information, please follow other related articles on the PHP Chinese website!