这是一个创建于 335 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前技术栈是 thinkphp8 + swoole ，现在客户有要求不准我们做单体应用，必须要做微服务开发。 对微服务的开发没什么经验，想咨询有经验的师傅指指门道，有偿 同时，我也考虑部分的服务进行外包，欢迎有经验的师傅来联系
 | 1 hahasong 2025 年 3 月 6 日 甲方想拆分到什么程度，费用什么范围，细说 |
 | 2 v1 2025 年 3 月 6 日 照样单体开发，但是加一个 init_args ，需要什么服务启动什么服务，都 php 了，还不如单体堆服务器配置 |
 | 3 sagaxu 2025 年 3 月 6 日  1 既然有此疑问，k8s 那套正规军打法就不太适合你们团队了。 若项目服务端开发人数 10 人以下，考虑极简版微服务：单体拆成 3 到 5 个小服务，以 HTTP 调用之，服务地址全用 127.0.0.1:XX 端口，本机 nginx 配置负责转发到真正的小服务的地址去，failover 和 load balace 都由 nginx 完成，那个 nginx 相当于进程外的 sidecar 。 独立部署与迭代 灵活扩展与资源优化 技术栈多样性 高容错性与可靠性 模块化与职责分离 云原生适配 微服务的大部分优点都得到了。 |
 | 4 keller 2025 年 3 月 6 日 看起来你的客户应该也不是很懂，你可以试试： 单体开发、群集部署、前端用负载均衡对不同的服务做流量转发。 |
 | 5 harryWebb 2025 年 3 月 6 日 你多搭几个服务，然后互相之前用接口传输就行了 我觉得你客户估计是脑子也不太好，php 搞啥微服务，更何况，小公司用啥微服务，有那闲工夫，不如一把梭哈 |
 | 6 yc8332 2025 年 3 月 6 日 那还不简单。。加个服务发现功能。。。把原来的各个模块单独部署就是微服务了。。。 |
 | 7 sciel 2025 年 3 月 6 日 via iPhone 搞微服务不如把你的服务层做成 无状态的 http 接口 在 k8s 里面开多个节点 推荐一个框架 goframe 这里面有 grpc 微服务开发，不过是 go 语言。 该框架的大佬之前就是搞 php 的。 可以看看 |
 | 8 chaodada 2025 年 3 月 6 日 1 用户注册登陆 127.0.0.1:8001 支付 127.0.0.1:8002 商品 127.0.0.1:8003 订单 127.0.0.1:8004 对内直接内网 http 调用接口 对外 nginx 转发 |
 | 9 yyttrr 2025 年 3 月 6 日 之前搞过一个脚本，开发时候仓库是分开的，但是部署的时候会把好几个 php 项目聚合到一个 pod 里面运行，不知道这样算不算微服务 |
 | 10 colinlikepotatos 2025 年 3 月 6 日 我现在用的 php 是这么设计的，所有功能写在一起，host1,host2,host3,host4 都是一样的程序可以实现全部功能，随机请求一个，核心数据，异步任务共享，可以根据服务器负载调用别的服务器运行，可水平扩容，集群，业务不间断，自动恢复，齐活了。你敢说他不是微服务嘛你也可以都写一起，但是调用另一个服务器的这套代码。 |
 | 11 Qjues 2025 年 3 月 6 日 微服务关键: 1. 实现服务拆分部署 2. 解决服务之间调用 大型微服务就得考虑服务治理, 异构架构等. 不过客户提这种要求得看报价, 高的话什么 k8s, prometheus, sls 等全上, 肯定拿下 |
 | 12 lasuar 2025 年 3 月 6 日 既然不熟悉，还要自己做的话，就按责任拆分服务，引入服务发现组件就行了。部署的话不要用 k8s 了，那对你们来说太重了，用 pm2 就行，也能多实例部署。 pm2 笔记： https://github.com/chaseSpace/go-practice/blob/main/markdown/use_pm2.md |
 | 13 RockyLi PRO 都已经用了 thinkphp8 这东西了还微服务啥了...说的好听.直接一把梭了就算了.... |
 | 14 BeforeTooLate 2025 年 3 月 6 日 PHP 做的话参考看看： https://hyperf.wiki/3.1/#/zh-cn/microservice 其实都微服务了建议直接换 go 吧 |
 | 15 coderzhangsan 2025 年 3 月 6 日 都用 php 了搞什么微服务，更何况最近都在拆微服务转单体，明显客户啥也不懂，跟着风就来了，就跟现在 AI 一样，很多老板都跟打了鸡血一样，all in ai 。 你随便搞搞得了，单体搞集群分布式，就跟他们说上微服务了，实在不行，就拆几个次要模块出去，http 通信，只要产品稳定能赚钱，舞台怎么装潢都不重要，关键能让甲方表演起来舒服些。 |
 | 16 shea 2025 年 3 月 6 日 我们之前是用的 hyperf 框架做的微服务 |
 | 17 sundev 2025 年 3 月 6 日 PHP 的微服务之前探索过。 目前 php 的微服务生态差 go 太远了，很多东西要自己写，不建议用 php 搞 |
 | 18 Nick66 2025 年 3 月 6 日 有微服务技术中台 3 年经验，欢迎咨询 512817655 曾就职于 KK 集团 用的的 hyperf 框架 |
 | 19 ifconfig 2025 年 3 月 6 日 |
| 20 ifconfig 2025 年 3 月 6 日 很多年前写的文章了，基于 hyperf 的，可以参考下 |
 | 21 pckillers 2025 年 3 月 6 日 都 thinkphp 了，别折腾了。 最多业务多拆分成多套系统。每套系统单独起 php 容器进 k8s 拉倒 |
 | 22 InDom 2025 年 3 月 6 日 什么都不用改, 端口同时监听多个, 但是 内部调用跳转一会用这个端口,一会用另一个端口就好了. |
 | 24 ninjashixuan 2025 年 3 月 6 日 先看看有多少预算吧，数据库起码独立分开部署好几个吧，不然硬上微服务有什么用。 |
 | 25 Alucns 2025 年 3 月 12 日 其实很简单的，我公司在运行的这套支付系统就是使用 PHP 开发，运行 3 年多，使用微服务； 架构核心就是拆分业务，如支付 API ，短信服务，任务服务，回调服务等。 各个服务之间是完全独立，各个服务之间用 RPC 接口通讯，如支付成功需要回调，通过 RPC 向回调服务请求，如果请求失败即存 Redis 队列重发等； 如回调服务可以放很多主机通过 NGINX 反向代理成一个公共接口以达到多可用。 |
Select Language