hyperf 微服务架构方案大全

---1. 服务拆分原则 大白话 什么时候该拆、怎么拆、拆多细。 拆分原则 单一职责一个服务只做一件事 业务边界按限界上下文拆参考DDD 团队边界一个团队维护一个服务 独立部署改一个服务不影响其他服务 数据隔离每个服务有自己的数据库# 电商系统拆分示例拆之前单体 一个大项目所有功能堆一起 ├── 用户模块 ├── 订单模块 ├── 商品模块 ├── 支付模块 └── 物流模块 拆之后微服务 user-service → 注册、登录、用户信息 order-service → 下单、订单状态 product-service → 商品、库存、分类 payment-service → 支付、退款 logistics-service → 发货、物流追踪 什么时候不该拆 团队只有3个人 → 别拆维护成本比收益高 业务逻辑还没稳定 → 别拆拆了还要改 两个服务频繁互相调用 → 说明拆错了应该合并 ---2. 服务间通信 REST — 最简单 大白话 HTTP 接口大家都会简单直接。 // order-service 调用 user-service class UserClient{publicfunction__construct(private ClientInterface$client){}publicfunctiongetUser(int$userId): array{$response$this-client-get(http://user-service/api/users/{$userId});returnjson_decode($response-getBody(),true);}}class OrderService{publicfunction__construct(private UserClient$userClient){}publicfunctioncreateOrder(array$data): Order{// 调用用户服务验证用户$user$this-userClient-getUser($data[user_id]);if(!$user){throw new\Exception(用户不存在);}returnOrder::create($data);}}缺点 文本传输、没有强类型约束、接口文档容易过期。 --- gRPC — 高性能强类型 大白话 用 Protobuf 定义接口自动生成代码比 REST 快3-10倍强类型不会传错字段。 // user.proto先定义接口协议 syntaxproto3;package user;serviceUserService{rpc GetUser(GetUserRequest)returns(UserResponse);rpc CreateUser(CreateUserRequest)returns(UserResponse);}message GetUserRequest{int32 user_id1;}message UserResponse{int32id1;string name2;string email3;}// 生成代码后user-service 实现服务端 class UserServiceImpl extends UserServiceBase{publicfunctionGetUser(GetUserRequest$request, array$metadata[]): UserResponse{$userUser::find($request-getUserId());$responsenew UserResponse();$response-setId($user-id);$response-setName($user-name);$response-setEmail($user-email);return$response;}}// order-service 调用客户端 class OrderService{publicfunction__construct(private UserServiceClient$userClient){}publicfunctioncreateOrder(array$data): Order{$requestnew GetUserRequest();$request-setUserId($data[user_id]);[$response,$status]$this-userClient-GetUser($request)-wait();if($status-code!STATUS_OK){throw new\Exception(获取用户失败);}returnOrder::create($data);}}// Hyperf gRPC 服务端配置 // config/autoload/server.phpreturn[servers[[namegrpc,typeServer::SERVER_HTTP2,host0.0.0.0,port9502,],],];--- 消息队列 — 异步解耦 大白话 不需要立即得到结果的操作发个消息扔队列对方慢慢处理互不等待。 // 场景下单成功后通知多个服务 // order-service发消息不等结果 class OrderService{publicfunction__construct(private ProducerInterface$producer){}publicfunctioncreateOrder(array$data): Order{$orderOrder::create($data);// 发消息不管谁处理、什么时候处理$this-producer-produce(new Message(order.created,[order_id$order-id,user_id$order-user_id,amount$order-amount,]));return$order;}}// logistics-service消费消息自己处理#[Consumer(topic: order.created, groupId: logistics)]class OrderCreatedConsumer extends AbstractConsumer{publicfunctionconsume(ConsumeMessage$message): string{$datajson_decode($message-getBody(),true);$this-logisticsService-prepareShipment($data[order_id]);returnResult::ACK;// 告诉队列处理成功}}// marketing-service同一条消息另一个消费者#[Consumer(topic: order.created, groupId: marketing)]class OrderCreatedForMarketingConsumer extends AbstractConsumer{publicfunctionconsume(ConsumeMessage$message): string{$datajson_decode($message-getBody(),true);$this-couponService-giveNextOrderCoupon($data[user_id]);returnResult::ACK;}}三种通信方式选择 需要立即拿到结果、数据量小 → REST 需要立即拿到结果、高性能 → gRPC 不需要立即结果、解耦异步 → 消息队列 ---3. API 网关 大白话 所有请求的统一入口在这里做鉴权、限流、路由、熔断后面的服务不用重复做。 客户端 ↓ API网关统一入口 ├── 路由/api/users/* → user-service ├── 鉴权验证Token ├── 限流每秒最多100次 ├── 熔断服务挂了快速失败 └── 日志记录所有请求 ↓ 各个微服务 // Hyperf 实现简单网关 // 路由转发 class GatewayController{private array$routeMap[/api/usershttp://user-service,/api/ordershttp://order-service,/api/productshttp://product-service,];publicfunctionforward(Request$request): ResponseInterface{$path$request-getUri()-getPath();$service$this-matchService($path);if(!$service){return$this-response-json([msg服务不存在],404);}$response$this-httpClient-request($request-getMethod(),$service.$path,[headers$request-getHeaders(),body$request-getBody(),]);return$this-response -withStatus($response-getStatusCode())-json(json_decode($response-getBody(),true));}}// 鉴权中间件 class GatewayAuthMiddleware implements MiddlewareInterface{// 白名单不需要登录 private array$whitelist[/api/auth/login,/api/auth/register];publicfunctionprocess(ServerRequestInterface$request, RequestHandlerInterface$handler): ResponseInterface{$path$request-getUri()-getPath();if(in_array($path,$this-whitelist)){return$handler-handle($request);// 白名单直接放行}$token$request-getHeader(Authorization)[0]??;if(!$this-validateToken($token)){return$this-response-json([msg未登录],401);}return$handler-handle($request);}}// 限流中间件 class RateLimitMiddleware implements MiddlewareInterface{publicfunctionprocess(ServerRequestInterface$request, RequestHandlerInterface$handler): ResponseInterface{$ip$request-getServerParams()[remote_addr];$keyrate_limit:{$ip};$count$this-redis-incr($key);if($count1){$this-redis-expire($key,1);//1秒窗口}if($count100){// 每秒最多100次return$this-response-json([msg请求太频繁],429);}return$handler-handle($request);}}// 熔断中间件 class CircuitBreakerMiddleware implements MiddlewareInterface{publicfunctionprocess(ServerRequestInterface$request, RequestHandlerInterface$handler): ResponseInterface{$service$this-getTargetService($request);$keycircuit:{$service};$state$this-redis-get($key);// 熔断器打开直接返回if($stateopen){return$this-response-json([msg服务暂时不可用],503);}try{$response$handler-handle($request);$this-recordSuccess($service);return$response;}catch(\Throwable$e){$this-recordFailure($service);throw$e;}}privatefunctionrecordFailure(string$service): void{$keycircuit:fail:{$service};$fails$this-redis-incr($key);$this-redis-expire($key,60);if($fails5){//60秒内失败5次打开熔断器$this-redis-setex(circuit:{$service},30,open);// 熔断30秒}}}---4. 服务注册与发现 大白话 服务启动时告诉注册中心我在这里其他服务要找它时问注册中心它在哪不用写死IP。 没有注册中心写死IP很痛苦 order-service 配置user-service192.168.1.10:8080 服务器换了 → 所有配置都要改 有注册中心动态发现 user-service 启动 → 注册到 Consul我是user-service在192.168.1.10:8080order-service 调用 → 问 Consuluser-service 在哪Consul 回答192.168.1.10:8080服务器换了 → 新服务自动注册旧服务自动摘除 // Hyperf 集成 Consul 服务注册 // config/autoload/services.phpreturn[enable[discoverytrue, // 开启服务发现registertrue, // 开启服务注册],consumers[[nameUserService, // 要调用的服务名serviceUserServiceInterface::class,protocoljsonrpc-http,load_balancerrandom, // 随机负载均衡nodes[// 兜底节点[host127.0.0.1,port9501],],],],providers[],drivers[consul[urihttp://consul:8500,timeout2,token,],],];// 服务启动自动注册调用时自动发现 class OrderService{publicfunction__construct(private UserServiceInterface$userService// 自动发现地址){}publicfunctioncreateOrder(array$data): Order{$user$this-userService-getUser($data[user_id]);// 不用关心IPreturnOrder::create($data);}}// 健康检查注册中心定期检查服务是否存活 // config/autoload/consul.phpreturn[check[httphttp://order-service/health,interval10s, // 每10秒检查一次timeout5s, // 超时5秒算失败],];// 健康检查接口 class HealthController{publicfunctioncheck(): ResponseInterface{return$this-response-json([statusok]);}}---5. 配置中心 大白话 配置不写在代码里放到一个统一的地方改配置不用重启服务所有服务实时生效。 没有配置中心痛苦 改个数据库密码 → 改10个服务的配置文件 → 重启10个服务 有配置中心爽 改个数据库密码 → 在配置中心改一次 → 所有服务自动热更新 // Hyperf 集成 Apollo 配置中心 // config/autoload/apollo.phpreturn[serverhttp://apollo:8080,appidorder-service,clusterdefault,namespaces[application, // 应用配置database, // 数据库配置redis, // Redis配置],pullTimeout10,intervalTimeout60, // 每60秒拉取一次];// 使用配置和普通配置一样用框架自动从配置中心拉 class OrderService{publicfunctiongetMaxOrderAmount(): int{// 这个值从配置中心读改了自动生效return(int)config(order.max_amount,10000);}}// 不同环境不同配置 配置中心 ├── dev开发环境 │ ├── db.host192.168.1.100 │ └── redis.host192.168.1.101 ├── staging测试环境 │ ├── db.host10.0.1.100 │ └── redis.host10.0.1.101 └── prod生产环境 ├── db.host172.16.1.100 ← 只有生产服务器能读 └── redis.host172.16.1.101 ---6. 链路追踪 大白话 一个请求经过了10个服务哪个服务慢了、哪里报错了一眼看清楚。 用户下单请求 ↓[TraceID: abc123]API网关(2ms)↓ order-service(150ms)← 慢 ├── 调用 user-service(5ms)├── 调用 product-service(8ms)├── 查数据库(120ms)← 这里慢 └── 发消息队列(3ms)↓ 返回结果 通过 TraceID abc123 可以看到整条链路 // Hyperf 集成 Zipkin/Jaeger 链路追踪 //composerrequire hyperf/tracer // config/autoload/opentracing.phpreturn[defaultenv(TRACER_DRIVER,zipkin),enable[guzzletrue, // HTTP调用自动追踪redistrue, // Redis自动追踪dbtrue, // 数据库自动追踪methodfalse,exceptiontrue,],tracer[zipkin[driverZipkinTracerFactory::class,options[endpoint_urlhttp://zipkin:9411/api/v2/spans,timeout1,],],],];// 手动添加追踪信息 class OrderService{publicfunction__construct(private TracerInterface$tracer){}publicfunctioncreateOrder(array$data): Order{$span$this-tracer-startSpan(create_order);$span-setTag(user_id,$data[user_id]);try{$orderOrder::create($data);$span-setTag(order_id,$order-id);return$order;}catch(\Throwable$e){$span-setTag(error,true);$span-log([message$e-getMessage()]);throw$e;}finally{$span-finish();}}}Zipkin/Jaeger 界面看到的 TraceID: abc123 总耗时: 150ms ├── API Gateway 2ms ✓ ├── order-service 148ms ✓ │ ├── getUser 5ms ✓ │ ├── getProduct 8ms ✓ │ ├── DB INSERT 120ms ⚠️慢查询 │ └── MQ publish 3ms ✓ ---7. 服务网格 / Istio 大白话 给每个服务旁边放一个代理小弟Sidecar所有网络流量都走这个小弟限流、熔断、追踪全由小弟处理业务代码完 全不用管。 没有服务网格 每个服务自己实现限流、熔断、追踪 → 每个服务都要写一堆基础设施代码 →10个服务写10遍 有服务网格Istio 每个服务旁边自动注入 Envoy Sidecar → 所有流量控制由 Sidecar 处理 → 业务代码只写业务逻辑# Istio 配置示例不用改业务代码# 流量路由90%流量到v110%到v2灰度发布apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: order-service spec: http: - route: - destination: host: order-service subset: v1 weight:90- destination: host: order-service subset: v2 weight:10# 10%流量给新版本---# 熔断配置apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: order-service spec: host: order-service trafficPolicy: outlierDetection: consecutiveErrors:5# 连续失败5次interval: 30s# 30秒内baseEjectionTime: 30s# 熔断30秒subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 服务网格架构[order-service]←→[Envoy Sidecar]←→ 网络[user-service]←→[Envoy Sidecar]←→ 网络[pay-service]←→[Envoy Sidecar]←→ 网络 ↑[Istio Control Plane]统一管理所有 Sidecar 限流/熔断/追踪/加密 什么时候用 Istio 服务数量10个 → 不用太重了自己在代码里处理 服务数量20个 → 考虑基础设施代码太多了 K8s 环境 → 配合使用很方便 多语言混合服务 → 必须用不然每种语言都要实现一遍 --- 整体架构图 客户端App/Web ↓ API 网关 路由/鉴权/限流/熔断 ↓ ┌──────────────────────────────────┐ │ 服务网格Istio │ │ │ │ user-service order-service │ │[Sidecar][Sidecar]│ │ │ │ product-service pay-service │ │[Sidecar][Sidecar]│ └──────────────────────────────────┘ ↓ ↓ 服务注册中心 配置中心 Consul Apollo ↓ 链路追踪 Zipkin 落地优先级建议 第一步分层架构 REST通信先跑起来 第二步加 API 网关统一入口 第三步加服务注册发现去掉写死IP 第四步加链路追踪出问题能查 第五步加配置中心配置统一管理 第六步换 gRPC性能瓶颈时 第七步上服务网格规模大了再说