PHP 微办事集群搭建 - Hyperf

微效劳的概念由 Martin Fowler 于2014年3月提出：

微效劳架构是一种架构模式，它倡导将简单利用程序划分成一组小的效劳，效劳之间彼此调和、互相配合，为会员供给终究价值。每个效劳运转在其独立的进程中，效劳和效劳之间采纳轻量级的通讯机制彼此沟通。每个效劳都环绕着详细的业务停止构建，并且能够被独立的摆设到生产环境、类生产环境等。别的，应尽量幸免统一的、集中的效劳治理机制，对详细的一个效劳而言，应按照业务上下文，选中适宜的说话、工具对其停止构建。

下图是一个电商系统的微效劳架构图：

微效劳架构与单体利用比拟，具有以下长处：

1、每个效劳都比力简便，只关注于一个业务功效；

2、微效劳架构方式是松耦合的，每个效劳可以独立测试、摆设、升级、公布；

3、每个微效劳可由不一样团队独立开发，可以各自选中最好及最适宜的不一样的编程说话与工具；

4、每个效劳可以按照需要停止水平扩展，提高系统并发能力。

没有银弹，微效劳架构在带来诸多长处的同时，也会有如下缺陷：

1、微效劳架构提高了系统的复杂度，增添了运维开销及成本。如单体利用大概只需摆设至一小片利用效劳集群，而微效劳架构大概变成需要构建/测试/摆设/运转数十个独立的效劳，并大概需要支撑多种说话和环境；

2、作为一种分布式系统，微效劳架构引入了其他若干问题，例如新闻序列化、网络延迟、异步机制、容错处置、效劳雪崩等；

3、效劳治理的复杂性，如效劳的注册、发明、落级、熔断等问题；

4、效劳与效劳之间存在彼此调取的状况，为排查系统故障带来宏大挑衅。

可以说，正是传统利用架构的系统变得日益臃肿，面临难以保护、扩展的问题，同时容器化技术（Docker）的蓬勃开展和 DevOps 思想的日渐成熟，催生了新的架构设计风格 – 微效劳架构的显现。

RPC 框架

微效劳架构中的各个效劳平常不在统一个机器上，乃至不会在统一个网络环境里，因此微效劳之间怎样调取是一个亟待解决的问题，我们平常使用 RPC 和谈来解决：

RPC（Remote Procedure Call），即长途历程调取，是一个运算机通讯和谈。该和谈同意运转于一台运算机的程序调取另一台运算机的子程序，而程序员无需额外地为这个交互作用编程。——维基百科

实现了 RPC 和谈的框架，可以让效劳方和调取方屏蔽各种底层细节，让调取方像调取当地函数一样调取远端的函数（效劳）。RPC 框架一样为效劳端和客户端供给了序列化、反序列化、连接池治理、负载平衡、故障转移、队列治理、超时治理、异步治理等本能机能。在网上寻到一个说明 RPC 框架工作道理图：

当前，按照序列化数据时采纳的技术的不一样，可分为 JSON-RPC 和 gRPC 两种：

1、JSON-RPC 是一种基于 JSON 格局的轻量级的 RPC 和谈标准，可基于 HTTP 和谈来传输，或直接基于 TCP 和谈来传输。 JSON-RPC 长处是易于使用和阅读。

2、gRPC 是一个高机能、通用的开源 RPC 框架，其由 Google 主要面向移动利用开发并基于 HTTP/2 和谈标准而设计，基于 ProtoBuf (Protocol Buffers) 序列化和谈开发，且支撑众多开发说话。 gRPC 具有低延迟、高效力、高扩展性、支撑分布式等长处。

Consul

此刻有了 RPC 框架，我们就可以只思考效劳与效劳之间的业务调取而不消思考底层传输细节。此时，假如效劳 A 想调取效劳 B 时，我们可以在效劳 A 中配置效劳 B 的 IP 地址和端口，然后剩下的传输细节就交给 RPC 框架。这在微效劳规模很小的状况下是没有问题的，但是在效劳规模很大、并且每个效劳不止摆设一个实例的状况下会面临宏大挑衅。比方，效劳 B 摆设了三个实例，这时候效劳 A 想调取效劳 B 该恳求哪个实例的 IP ？假设效劳 B 摆设的三个实例有两个都挂掉了，效劳 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-A 就可用通过这些信息来调取 S-B。

S-A 可以通过监听 Consul 来更新存入内存中的 S-B 的效劳信息。比方 S-B-1 挂了，安康检查机制就会将其标为不成用，这样的信息变更就被 S-A 监听到了，S-A 就更新本人内存中 S-B-1 的效劳信息。

可见， Consul 软件除了效劳注册和效劳发明的功效之外，还供给了安康检查和状态变动通知的功效。

Hyperf

关于 Java 开发者来说，有技术相当做熟的 Dubbo 和 Spring Cloud 微效劳框架可供选中。作为一位 PHPer，我用 Google 查了一下「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 作为效劳注册和效劳发明的组件，容器 microservice-1 和 microservice-2 离别供给了加法运算和除法运算的效劳。容器 app 作为效劳调取方，配置了 consul-server-leader 容器的 URL，通过拜访 consul-server-leader 猎取 microservice-1 和 microservice-2 效劳的 IP 地址和端口，然后 app 通过 RPC 和谈调取加法运算和除法运算的效劳猎取结果并返回给会员。

app 容器为 Web 利用，摆设了一个 Hyperf 项目并对外供给 HTTP 效劳。例如，在 App\Controller\IndexController 操纵器里有 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调取
  ];
}

在 App\JsonRpc\AdditionService 中 add 的实现：

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的具体内容，更多请关注百分百源码网其它相关文章！