consul配置中心_配置中心config

微服务框架之Spring Cloud

[Dubbo]()

在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：

consul配置中心_配置中心config

consul配置中心_配置中心config

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

Spring 在企业级生产环境中， docker 容器往往需要结合 kubernetes 或者 docker swarm 容器编排工具一起使用。Cloud 所提供的核心功能包含：

Spring Cloud架构图

Spring Cloud子项目

Spring Cloud 旗下的子项目大致可以分为两类：

1. Spring Cloud 与 Spring Boot

Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。

2. Spring Cloud 与服务治理( Eureka )

服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。

Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。

在 Eureka 的实现中，之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个存活，也可以正常地治理服务。即使所有服务注册都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

3. Spring Cloud 与客户端负载均衡( Ribbon )

Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。

4. Spring Cloud 与微服务容错、降级( Hystrix )

为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。

Hystrix 是根据“断路器”模式而创建。当 Hystrix 到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而 Hystrix 的仪表盘项目（ Dashboard ）可以各个服务调用所消耗的时间、请求数、等，通过这种近乎实时的和告警，可以及时发现系统中潜在问题并进行处理。

5. Spring Cloud 与服务( Zuul )

Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务功能，提供对请求的路由和过滤两个功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 进行整合，自动从 Eureka 中获取所有注册的服务并进行路由映射，实现 API 服务自动配置。

6. Spring Cloud 与消息中间件( Stream )

Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。

Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的、消息总线，用于服务集群中状态变化的传播。

比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。

7. Spring Cloud 与分布式配置中心( Config )

针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言等特性。

在 Config 子项目中将微服务应用分为两种角色：配置（ Config ）和配置客户端（ Config ）。使用配置集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

8. Spring Cloud 与微服务链路( Sleuth )

Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路。

Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

9. Spring Cloud 与微服务安全( Security )

Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。

10. Spring Cloud 的其他子项目

Consul和ZooKeeper的区别

Consul是一个在国外流行的服务发现和配置共享的服务软件。本文翻译自Consul的文档，文中重点讲述：在与主流同类软件ZooKeeper、Doozerd以及Etcd比较时，Consul的优势所在。

ZooKeeper、Doozerd、Etcd在架构上都非常相似，它们都有服务（server node），而这些服务的作都要求达到的仲裁数（通常，的仲裁数遵循的是简单多数原则）。此外，它们都是强一致性的，并且提供各种原语。通 过应用程序内部的客户端lib库，这些原语可以用来构建复杂的分布式系统。

Consul在一个单一的数据中心内部使用服务。在每个数据中心中，为了Consule能够运行，并且保持强一致性，Consul服务端需要仲裁。然而，Consul原生支持多数据中心，就像一个丰富gossip系统连接和客户端一样。

当提供K/V存储的时候，这些系统具有大致相同的语义，读取是强一致性的，并且在面对网络分区的时候，为了保持一致性，读取的可用性是可以牺牲的。然而，当系统应用于复杂情况时，这种异会变得更加明显。

这些系统提供的语义对开发人员构建服务发现系统很有吸引力，但更重要的是，强调开发人员要构建这些特性。ZooKeeper只提供一个原始的 K/V值存储，并要求开发人员构建他们自己的系统来提供服务发现功能。相反的Marathon为运行中的应用提供了灵活的重启策略。当应用只有一个实例在运行，这时候重启的话，默认情况下Marathon会新起一个实例，在新实例重启完成之后，才会停掉原有实例，从而实现平滑的重启，满足应用无缝滚动发布的要求。是，Consul提供了一个坚固的框架，这不仅仅是为了提供服务发现功能，也 是为了减少推测工作和开发工作量。客户端只需简单地完成服务注册工作，然后使用一个DNS接口或者HTTP接口就可以执行工作了，而其他系统则需要你定制 自己的解决方案。

一个令人信服的服务发现框架必须包含健康检测功能，并且考虑失败的可能性。要是失败或者服务故障了，即使开发人员知道A提供Foo服务也 是没用的。Nie系统利用的是心跳、周期性更新和TTLs，这些系统不仅需要工作量与数量成线性关系，并且对的固定数量提出了要求。此外， 故障检测窗口的存活时间至少要和TTL一样长。

ZooKeeper提供了临时，这些临时就是K/V条目，当客户端断开连接时，这些条目会被删除。虽然这些临时比一个心跳系统更高 级，但仍存在固有的扩展性问题，并且会增加客户端的复杂性。与ZooKeeper端连接时，客户端必须保持活跃，并且去做持续性连接。此 外，ZooKeeper还需要胖客户端，而胖客户端是很难编写，并且胖客户端会经常导致调试质询。

Consul使用一个完全不同的架构进行健康检测。Consul客户端可以运行在集群中的每一个上，而不是拥有，这些Consul客户端属于一个gossip pool，gossip pool提供了一些功能，包括分布式健康检测。gossip协议提供了一个高效的故障检测工具，这个故障检测工具可以应用到任意规模的集群，而不仅仅是作 用于特定的组。同时，这个故障检测工具也支持在本地进行多种健康检测。与此相反，ZooKeeper的临时只是一个非常原始的活跃度检测。因为 有ETCD_AUTHORITY=10.10.195.193:2379了Consul，客户端可以检测web是否正在返回200状态码，内存利用率是否达到临界点，是否有足够的数据存储盘等。此 外，ZooKeeper会暴露系统的复杂性给客户端，为了避免ZooKeeper出现的这种情况，Consul只提供一个简单HTTP接口。

Consul为服务发现、健康检测、K/V存储和多数据中心提供了的支持。为了支持任意存储，而不仅仅是简单的K/V存储，其他系统都要求工 具和lib库要率先建立。然而，通过使用客户端，Consul提供了一个简单的API，这个API的开发只需要瘦客户端就可以了， 而且，通过使用配置文件和DNS接口，开发人员可以建立完整的服务发现解决方案，最终，达到避免开发API的目的。

docker mesos在生产环境的实践

如下：

我们是一家做生鲜电商的公司，从系统搭建初期，我们就采用微服务的架构，基于DevOps体系来不断提高我们的交付的质量和效率， 随着业务和团队规模的发展，服务逐渐进行拆分，服务之间的交互越来越复杂，目前整个微服务已经近几十个应用模块， 整体架构上包括负载均衡、API、基于Dubbo的微服务模块、缓存、队列、数据库等，目前整个集群的资源利用率也没有一个合理的规划评估，虚拟机上部署多个应用服务隔离性也存在问题，考虑到越来越多门店以及第三方流量的接入，需要考虑系统的快速的伸缩能力，而基于统一资源管理的Docker容器技术在这些方面有一些天然的优势，并且和微服务架构、DevOps体系完美衔接。

对于有状态的数据库，缓存等还是用物理机（虚拟机），来的应用集群用的是虚拟机，Docker容器集群需要和它们打通，做服务和数据的访问交互。那么只需要在物理机（虚拟机）上把当前加入容器网络集群即可：

逻辑架构

部署架构

在发布流程中，在发布上线之前的环节是预发布，预发布环境验证完成后进行打包，生成Docker镜像和基于虚拟机部署的应用部署包，push到各自对应的仓库中，并打Tag。

生产环境发布过程中，同时发布到Mesos集群和原有的虚拟机集群上，两套集群网络是打通的。

网络架构

在网络架构选型时，会考虑一下几个原则：

docker bridge使用默认的docker0网桥，容器有的网络命名空间，跨主机的容器通信需要做端口NAT映射；Host的方式采用和宿主机一样的网络命名空间，网络无法做隔离，等等这些方式有非常多的端口争用限制，效率也较低。

Docker Overlay的方式，可以解决跨主机的通信，现有二层或三层网络之上再构建起来一个的网络，这个网络通常会有自己的IP地址空间、交换或者路由的实现。

Docker在libnetwork团队提供了multi-host网络功能，能完成Overlay网络，主要有隧道和路由两种方式， 隧道原理是对基础的网络协议进行封包，代表是Flannel。

另外一种是在宿主机中实现路由配置实现跨宿主机的容器之间的通信，比如Calico。

Calico是基于大三层的BGP协议路由方案，没有使用封包的隧道，没有NAT，性能的损耗很小，支持安全隔离防护，支持很细致的ACL控制，对混合云亲和度比较高。经过综合对比考虑，我们采用calico来实现跨宿主机的网络通讯。

安装好ETCD集群，通过负载均衡VIP方式（LVS+keepalived）来访问ETCD集群。

export ETCD_AUTHORITY

构建Calico网络集群，增加当前到集群中，Calico 启动后会查询 Etcd，和其他 Calico 使用 BGP 协议建立连接。

./calicoctl node –libnetwork –ip=10.10.3.210

增加可用的地址池ip pool

./calicoctl pool add 10.4.10.0/24 –nat-outgoing

./calicoctl pool show

创建网络，通过Calico IPAM插件（Driver（包括IPAM）负责一个Network的管理，包括资源分配和回收），-d指定驱动类型为Calico，创建一个online_net的driver为Calico的网络：

docker network create -d calico –ipam-driver calico –subnet=10.4.10.0/24 online_net

启动容器，网络指定刚才创建的online_net，容器启动时，劫持相关 Docker API，进行网络初始化。 查询 Etcd 自动分配一个可用 IP，创建一对v接口用于容器和主机间通讯，设置好容器内的 IP 后，打开 IP 转发，在主机路由表添加指向此接口的路由，宿主机10.10.3.210的路由表：

容器包发送包的路由过程如上图，宿主机10.10.3.210上的容器IP 10.4.10.64通过路由表发送数据包给另外一个宿主机10.10.50.145的容器10.4.10.55。

export ETCD_AUTHORITY

./calicoctl node –ip=10.10.16.201

服务自注册和发现

API提供统一的API访问入口，分为两层，层提供统一的路由、流控、安全鉴权、WAF、灰度功能发布等功能，第二层是Web应用层，通过调用Dubbo服务来实现服务的编排，对外提供的编排服务功能，屏蔽业务服务接口的变更；为了能够快速无缝的实现web层快速接入和扩容，我们用Consul作为服务注册中心实现Web服务的自动注册和发现。

对于Web服务注册，我们自己实现了Register，调用Consul的API进行注册，并通过TTL机制，定期进行心跳汇报应用的 健康 状态。

对于Web服务的发现，我们基于Netflix Zuul进行了扩展和改造，路由方面整合Consul的发现机制，并增加了基于域名进行路由的方式，对路由的配置功能进行了增强，实现配置的动态reload功能。API启动定时任务，通过Consul API获取Web服务实例的 健康 状态，更新本地的路由缓存，实现动态路由功能。

平台的微服务框架是基于Dubbo RPC实现的，而Dubbo依赖ZooKeeper做服务的发现和注册。

Consul在Mesos Docker集群的部署方案 ：

不建议把Consul Agent都和Container应用打包成一个镜像，因此Consul Agent部署在每个Mesos Sle宿主机上，那么Container如何获取宿主机的IP地址来进行服务的注册和注销，容器启动过程中，默认情况下，会把当前宿主机IP作为环境变量传递到Container中，这样容器应用的Register模块就可以获取Consul的IP，调用Consul的API进行服务的注册和卸载。

在日常应用发布中，需要保障发布过程对在线业务没有影响，做到无缝滚动的发布，那么在停止应用时应通知到路由，进行流量切换。

docker stop命令在执行的时候，会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。这样我们可以让程序在接收到SIGTERM信号后，有一定的时间处理、保存程序执行现场，优雅的退出程序，我们在应用的启动脚本中实现一段脚本来实现信号的接受和处理， 接收到信号后，找到应用的PID，做应用进程的平滑kill。

应用的无缝滚动发布、宕机恢复

当然，可以通过Marathon提供的参数来设置自己想要的重启策略：

“upgradeStrategy”:{ “minimumHealthCapacity”: N1, “maximumOverCapacity”: N2 }

如何判断新的实例是否启动完成可以提供服务，或者当前容器的应用实例是否 健康 ，是否实例已经不可用了需要恢复，Marathon提供了healthchecks 健康 监测模块

"healthChecks": [{

"protocol": "COMMAND",

"command":{

"value":"sh /data/soft/healthcheck.sh app 10.10.195.193"

},

"gracePeriodSeconds": 90,

"intervalSeconds": 60,

"maxConsecutiveFailures": 3

}]

healthcheck.sh通过负载均衡调用HealthMonitor来获取应用实例的状态， HealthMonitor是我们的 健康 检查中心，可以获取应用实例的整个拓扑信息。

容器、日志

对于容器的，由于我们是采用Mesos Docker的容器资源管理的架构，因此采用mesos-exporter+Promeus+Grafana的方案，mesos-exporter的特点是可以采集 task 的数据，可以从task的角度来了解资源的使用情况，而不是一个一个没有关联关系的容器。mesos-exporter导出Mesos集群的数据到Promeus，Promeus是一套报警、时序数据库组合，提供了非常强大存储和度的查询，数据的展现统一采用Grafana。

Spring Boot集成Eureka

microserv- 2:

在应用启动类上添加@EnableEureka注解，声明为Eureka

宿主机10.10.50.145的路由表：

配置文件application.yml中添加以下内容：

启动应用，访问

添加如下依赖：

在配置文件application.yml中添加如下配置：

也可使用@EnableEureka注解替代@EnableDiscovery，EnableEureka只支持Eureka，而EnableDiscovery是一个高度的抽象还支持Zookeeper和Consul

只需修改Eureka 端口号启动多个实例，然后将eureka.client.servUrl.defaultZone地址相互配置为其他地址即可。而客户端无需配置多个defaultZone，只需配置一个，Eureka 集群之间会相互同步

dubbo version: 2.6.0, current host: 192.168.245.1

5.1 使用远程配置中心去读取配置

在Dubbo的配置文件中，可以通过 dubbo.protocol.host 属性来设置当前主机的IP地址。可以在 dubbo.properties 或者 dubbo.xml 中进行配置。具体作步骤如下：

在配置文件中加入如下配置：

dubbo.protocol.hostlog.Println(string(data))=your_ip_address

将 your_ip_address 替换为当前主机的IP地址。

保存配置文件并重新启动Dubbo服务。

这样就可以将Dubbo服务绑定到指定的IP地址上，供客户端调用。

Golang项目部署3，容器部署

经过调研和对比，最终我们采用Mesos作为底层资源的管理和调度，Marathon作为Docker执行的框架，配合ZooKeeper、Consul、Nginx作为服务注册发现。目前已经有部分的核心业务已经平稳的运行在基于Docker容器的Mesos资源管理平台上。

容器部署即使用 docker 化部署 golang 应用程序，这是在云服务时代的部署方式，也是最的部署方式。

跨平台交叉编译是 golang container_name:"microserv-1"的特点之一，可以非常方便地编译出我们需要的目标平台的版本，而且是静态编译，非常容易地解决了运行依赖问题。

使用以下指令可以静态编译 Linux 平台 amd64 架构的可执行文件：

生成的 main 便是我们静态编译的，可部署于 Linux amd64 上的可执行文件。

我们需要将该可执行文件 main 编译生成 docker 镜像，以便于分发及部署。 Golang 的运行环境使用 alpine 基础系统镜像，编译出的容器镜像约为 20MB 左右。

一个参考的 Dockerfile 文件如下：

其中，我们的基础镜像使用了 loads/alpine:3.8 ，国内的用户使用该基础镜像，基础镜像的 Dockerfile 地址： ，仓库地址：

随后使用 " docker build -t main . " 指令编译生成名为 main 的 docker 镜像。

需要注意的是，在某些项目的架构设计中， 静态文件 和 配置文件 可能不会随着镜像进行编译发布，而是分开进行管理和发布。

例如，使用 MVVM 模式的项目中(例如使用 vue 框架)，往往是前后端非常的，因此在镜像中往往并不会包含 public 目录。而使用了 配置管理中心 (例如使用 consul / etcd / zookeeper )的项目中，也往往并不需要 config 目录。

因此对于以上示例的 Dockerfile 的使用，仅作参考，根据实际情况请进行必要的调整。

使用以下指令可直接运行刚才编译成的镜像：

容器的分发可以使用 docker 的平台： ，国内也可以考虑使用阿里云： 。

容器编排涉及到的内容比较多，感兴趣的同学可以参考以下资料：

tectia client 配置文件路径

1. 相对路径

go run 或者 go build后在配置目录的相对路径上执行

设当前目录如下:

├─config

│ │ main.go

│ │

│ └─file // 配置文件目录

│ config.ini

│也就是说无论你是go run或者build后的执行程序,都应该在你执行目录下

有该配置文件路径如file/config.ini

否则就会发生以下错误, 无法读取配置文件

panic: Error:can not read file "./file/config.ini"

//- microserv 测试代码

func runOrBuildLoadConfig(){

// 使用库 go get

c, err := fconf.NewFileConf(" ./file/config.ini")

if err != nil {

panic(err)

}fmt.Println(c.Int("server.port"))

}2. 路径

使用路径读取配置文件

如果配置文件动态的话, 具体怎么传入 配置文件路径

使用flag包, go run或者build的执行程序 带上 -config=xxxxx路径

通过配置set/export环境变量, os.Getenv()获取该变量名称对应的值(即路径)

// 测试代码

func useAbsPathLoadConfig(){

// 这是直接硬编码的路径

ff,err := os.OpenFile("D:/GoWorkspace/src/Examples/config/file/config.ini",os.O_RDWR,666)

if err != nil {

panic(err)

}var buf [100]byte

ff.Read(buf[:])

log.Println(string(buf[:]))

}3. 网络GET, ftp等

3.1 通过网络去获取配置文件

e.g

func useNetworkLoadConfig(){

// ... 具体不实现

}4. 嵌入到应用程序中

go-bindata 把配置文件打包进去

1. go get -u ...

2. 然后在当前目录执行go install ../..安装到GOPATH/bin目录

3. 使用 go-bindata --prefix=file file/... 将file"timeoutSeconds": 50,目录下的文件嵌入,会生成bindata.go

4. go run main.go bindata.go 或者 build成可执行文件执行

// 测试代码

func useBindataLoadConfig(){

data, err := Asset("config.ini")

if err != nil {

panic(err)

}// 输出 也可以拿来解析

5. 远程配置中心

通过key/value的方式存储在redis的配置, 配置过多可以使用pipe方式到导入

使用etcd / consul 之类的KV Store 进行动态配置

php如何搭建微服务

depends_on:

Hyperf （学习：PHP视频教程）

对于 Ja 开发者来说，有技术相当成熟的微服务框架可供选择：

[Spring Cloud]()作为一名 PHPer，我用 Google 查了一下「PHP + 微服务」，发现有用的相关内容少之又少 ，没有什么实质性的参考价值，无限惆怅。

幸好，有大神在基于 Swoole 扩展的基础上，实现了高性能、高灵活性的 PHP 协程框架 [Hyperf]() ，并提供了微服务架构的相关组件。

Hyperf 是基于 `Swoole 4.3+` 实现的高性能、高灵活性的 PHP 协程框架，内置协程及大量常用的组件，性能较传统基于 `PHP-FPM` 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均基于 [PSR 标准]() 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是 `可替换` 与 `可复用` 的。

于是，我在学习了微服务架构相关的基础知识之后，使用 Hyperf 框架构建了一个基于 PHP 的微服务集群，这是项目源码地址：

Dokcer 搭建，`docker-come.yml` 代码如下：

version:"3"

servs:

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= 0

ports:

- "8500:8500"

networks:

microserv- 1:

build:

context:.

command:"php bin/hyperf.php start"

- "consul-server-leader"

volumes:

- ./www/microserv- 1:/var/www

networks:

tty:true

build:

context:.

container_name:"microserv-2"

command:"php bin/hyperf.php start"

- "consul-server-leader"

volumes:

- ./www/microserv- 2:/var/www

networks:

tty:true

build:

context:.

container_name:"app"

command:"php bin/hyperf.php start"

- "microserv-1"

volumes:

- ./www/ web:/var/www

ports:

- "9501:9501"

networks:

tty:true

networks:

microservapp::

driver:bridge

volumes:

microserv:

driver:local这里启动了一个 Consul 容器 `consul-server-leader` 作为服务注册和服务发现的组件，容器 `microserv-1` 和 `microserv-2` 分别提供了加法运算和除法运算的服务。

容器 `app` 作为服务调用方，配置了 `consul-server-leader` 容器的 URL，通过访问 `consul-server-leader` 获取 `microserv-1` 和 `microserv-2` 服务的 IP 地址和端口，然后 `app` 通过 RPC 协议调用加法运算和除法运算的服务获取结果并返回给用户。

`app` 容器为 Web 应用，部署了一个 Hyperf 项目并对外提供 HTTP 服务。

例如，在 `AppControllerIndexController` 里有 `add` 方法：

publicfunctionadd(AdditionServ $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调用

];

}在 `AppJsonRpcAdditionServ` 中 `add` 的实现：

classAdditionServextendsAbstractServ

{/

定义对应服务提供者的服务名称

@varstring

/

protected$servName = 'AdditionServ';

/

定义对应服务提供者的服务协议

@varstring

/

protected$protocol = 'jsonrpc-';

publicfunctionadd(int $a, int $b): int

{return$this->__request( __FUNCTION__, compact( 'a', 'b'));

}}继承了 `AbstractServ` 即可创建一个微服务客户端请求类，Hyperf 在底层帮我们实现了与 Consul 和服务提供者交互的细节，我们只要 `AdditionServ` 类里的 `add` 方法即可远程调用 `microserv-1` 和 `microserv-2` 提供的服务。

至此，PHP 微服务集群搭建就完成了！