目前技术栈是 thinkphp8 + swoole ，现在客户有要求不准我们做单体应用，必须要做微服务开发。
对微服务的开发没什么经验，想咨询有经验的师傅指指门道，有偿
同时，我也考虑部分的服务进行外包，欢迎有经验的师傅来联系

甲方想拆分到什么程度，费用什么范围，细说

照样单体开发，但是加一个 init_args ，需要什么服务启动什么服务，都 php 了，还不如单体堆服务器配置

既然有此疑问，k8s 那套正规军打法就不太适合你们团队了。

若项目服务端开发人数 10 人以下，考虑极简版微服务：单体拆成 3 到 5 个小服务，以 HTTP 调用之，服务地址全用 127.0.0.1:XX 端口，本机 nginx 配置负责转发到真正的小服务的地址去，failover 和 load balace 都由 nginx 完成，那个 nginx 相当于进程外的 sidecar 。

独立部署与迭代 ✅
灵活扩展与资源优化 ✅
技术栈多样性 ✅
高容错性与可靠性 ✅
模块化与职责分离 ✅
云原生适配 ❌

微服务的大部分优点都得到了。

看起来你的客户应该也不是很懂，你可以试试：
单体开发、群集部署、前端用负载均衡对不同的服务做流量转发。

你多搭几个服务，然后互相之前用接口传输就行了

我觉得你客户估计是脑子也不太好，php 搞啥微服务，更何况，小公司用啥微服务，有那闲工夫，不如一把梭哈

那还不简单。。加个服务发现功能。。。把原来的各个模块单独部署就是微服务了。。。

搞微服务不如把你的服务层做成 无状态的 http 接口 在 k8s 里面开多个节点

推荐一个框架 goframe 这里面有 grpc 微服务开发，不过是 go 语言。 该框架的大佬之前就是搞 php 的。 可以看看

用户注册登陆 127.0.0.1:8001
支付 127.0.0.1:8002
商品 127.0.0.1:8003
订单 127.0.0.1:8004
对内直接内网 http 调用接口
对外 nginx 转发

之前搞过一个脚本，开发时候仓库是分开的，但是部署的时候会把好几个 php 项目聚合到一个 pod 里面运行，不知道这样算不算微服务

我现在用的 php 是这么设计的，所有功能写在一起，host1,host2,host3,host4 都是一样的程序可以实现全部功能，随机请求一个，核心数据，异步任务共享，可以根据服务器负载调用别的服务器运行，可水平扩容，集群，业务不间断，自动恢复，齐活了。你敢说他不是微服务嘛😏你也可以都写一起，但是调用另一个服务器的这套代码。

微服务关键:

1. 实现服务拆分部署

2. 解决服务之间调用
   大型微服务就得考虑服务治理, 异构架构等. 不过客户提这种要求得看报价, 高的话什么 k8s, prometheus, sls 等全上, 肯定拿下

   既然不熟悉，还要自己做的话，就按责任拆分服务，引入服务发现组件就行了。部署的话不要用 k8s 了，那对你们来说太重了，用 pm2 就行，也能多实例部署。

pm2 笔记： github.com/chaseSpace/go-practice/blob/main/markdown/use_pm2.md

都已经用了 thinkphp8 这东西了还微服务啥了...说的好听.直接一把梭了就算了....

PHP 做的话参考看看： hyperf.wiki/3.1/＃/zh-cn/microservice
其实都微服务了建议直接换 go 吧

都用 php 了搞什么微服务，更何况最近都在拆微服务转单体，明显客户啥也不懂，跟着风就来了，就跟现在 AI 一样，很多老板都跟打了鸡血一样，all in ai 。

你随便搞搞得了，单体搞集群分布式，就跟他们说上微服务了，实在不行，就拆几个次要模块出去，http 通信，只要产品稳定能赚钱，舞台怎么装潢都不重要，关键能让甲方表演起来舒服些。

我们之前是用的 hyperf 框架做的微服务

PHP 的微服务之前探索过。
目前 php 的微服务生态差 go 太远了，很多东西要自己写，不建议用 php 搞

有微服务技术中台 3 年经验，欢迎咨询 512817655 曾就职于 KK 集团 用的的 hyperf 框架

zhuanlan.zhihu.com/p/125709905

很多年前写的文章了，基于 hyperf 的，可以参考下

都 thinkphp 了，别折腾了。 最多业务多拆分成多套系统。每套系统单独起 php 容器进 k8s 拉倒

什么都不用改, 端口同时监听多个, 但是 内部调用跳转一会用这个端口,一会用另一个端口就好了.

都微服务了谁还绑死在一个语言上啊。

先看看有多少预算吧，数据库起码独立分开部署好几个吧，不然硬上微服务有什么用。