1. 我有点搞不明白 PHP 搞微服务的意义，兴许是我做的项目，以单体架构居多，养成了经验惯性。
2. 多人协作开发，最好要有本地局域网测试环境，前端只需要对接本地局域网测试环境即可 (点对点对接当然也可以配置对应开发者域名 HOST 或 IP 访问)，对应开发的流程应该是后端开发完毕后，自测没问题推到本地测试环境，接口文档丢给前端，剩下就是开发联调。
3. 既然是微服务，肯定是不同的模块是由不同的人或团队专向负责，所以需要其他服务时，应该由其对应的开发人员负责；如果一个人要负责这么多微服务模块，那架构设计对开发人员来说就是灾难，一个服务就启动一个 docker，这样的设计就应该调整。

公司没有多余的主机搭个服务器吗？

感觉你弄的好麻烦
我们也是多个项目比如：A 项目请求 B 项目，我都是 B 项目本地开发自测完成扔到测试环境，然后使用 A 项目直接请求 B 测试环境的项目。
数据库和 redis 啥的都是连接测试环境的。

这么复杂的调用链路，不是应该搭建一个开发环境？

感觉你们这个基础设施做的可能不够完善（开发者的设备平台不统一也是一个问题），团队应该达成共识，采用约定大于配置的方式将基础设施转变为代码来进行管理！

就像你说的，对前端不太友好，但其实如果将服务的配置和部署都做到标准化，再完善相应的文档那么，就算他刚入门应该也能够照着文档将环境搭好！

另外如果是前后端分离的项目，前端没必要再本地跑后端的服务，直接联调测试服即可！如果是前后端混合在一起的，那么后端应该尽可能的降低前端的学习成本，后端应提脚本和详细的说明文档！

例如后端的某次更改，需要更新或者安装依赖，那么应在部署文档中详细说明操作步骤！

在跨服务联调是通过切换分支来实现，这种方式确实比较传统且麻烦，可以考虑通过 CI/CD 基于分支来部署服务，具体可以参考我的这篇文章：《DevOps 之 Laravel 基于分支的多环境部署》。

这是微服务架构吗

感觉不太像

一般比较复杂的服务，我觉得不应该本地部署。建议你们公司买个服务器放在公司，或者好点的主机（比如内存 128G 的），然后服务搭建最好是配置化脚本化。

开发最好是远程开发，这样子你的开发环境脱离了设备限制，就算公司服务器 gg 了，由于是部署是脚本化配置化，搞个低配的云服务也是很方便。

之前我制定的开发环境方案是全部 docker 化，除非有特定需求。这样子方便环境部署配置化。前端原本是本机开发，后面发现多 node 版本，然后也 docker 化，恰巧 vscode 也在推 remote develop，所以也远程开发

最后就是虚拟网络搭建，毕竟是有内外网区分，很多网络应该都是内网访问即可，所以方便管理最好使用虚拟网络，比如 openv-pn 之类的来拉平网络

除非是自己维护多个服务，不然不考虑本地部署。例如其他业务线、项目组维护的代码，可能根本就不提供源码给你。即使有代码有文档，部署和维护也是问题，很多时候不是一句 docker-compose up 就能跑起来的。

所有我都是自己实现 mock server 解决本地开发的问题。只实现需要的 API 即可，可以模拟各种响应的场景，实现并不复杂。而且 mock server 可以用在测试里使用，方便 CI。

集成测试通常就需要独立的部署环境，和生产环境相似各个，项目主自行维护，只要提供 API endpoint 进行访问可以。