关于微服务的本地开发环境大家公司里是怎么搭建的呢
一、大概架构
公司的架构是OpenResty充当api网关，然后下面很多个laravel tp项目通过http互相调用二、本地开发环境
除数据库外，每个开发人员电脑上都是通过wsl2+原生docker完整的单机部署 网关和各个服务（laravel，tp项目），以及前端项目。三、弊端
一、对本机电脑压力大，且开发起来， 如果本次实现的功能，需要别的服务配合需要到处切换到对应服务的代码目录下去用git控制代码版本（公司电脑不行了 i5-7400 16g内存 暂时不会升级电脑， 勉强够用）
二、对前端很不友好（前端人员更新的快， 且一般不熟悉linux和docker等，在各个服务间切换代码版本非常痛苦）四、提问目的
想知道一下大家公司的本地开发环境是怎样的，参考一下。有好的方式也可以分享出来我去研究研究
感谢大伙的评论和建议。公司是有单独的一台测试服务器的。现在这个场景，有点分了又没分的感觉， 由于人员配置和公司环境，导致卡在演变成微服务的路上了,每个服务都耦合了别的功能，重点服务经常交叉着开发。 ，这也是现在开发环境别扭的原因吧。
关于 LearnKu
粤公网安备 44030502004330号
高认可度评论：
感觉你们这个基础设施做的可能不够完善（开发者的设备平台不统一也是一个问题），团队应该达成共识，采用约定大于配置的方式将基础设施转变为代码来进行管理！
就像你说的，对前端不太友好，但其实如果将服务的配置和部署都做到标准化，再完善相应的文档那么，就算他刚入门应该也能够照着文档将环境搭好！
另外如果是前后端分离的项目，前端没必要再本地跑后端的服务，直接联调测试服即可！如果是前后端混合在一起的，那么后端应该尽可能的降低前端的学习成本，后端应提脚本和详细的说明文档！
例如后端的某次更改，需要更新或者安装依赖，那么应在部署文档中详细说明操作步骤！
在跨服务联调是通过切换分支来实现，这种方式确实比较传统且麻烦，可以考虑通过 CI/CD 基于分支来部署服务，具体可以参考我的这篇文章：《DevOps 之 Laravel 基于分支的多环境部署》。
公司没有多余的主机搭个服务器吗？
感觉你弄的好麻烦
我们也是多个项目比如：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 进行访问可以。