单体架构的 PHP 程序如何转型？

你们要换成 Java 的话，估计人员得是 PHP 的四倍左右。。。

创业小公司或许没必要上java，甚至或许没必要提前太多考虑架构问题

像你们这种，从单体框架迁移到微服务框架的情况。其实也没有很难，第一步就是先把服务独立出来，比如按照你们的 模块 来说 电商 租赁 考试平台 erp 管理

• 基础服务组

用户服务、 订单服务、 支付服务、

• 电商组

• 租赁组

• 考试平台组

• ERP 组

• 管理中台

上述四个组，都可以先单独使用一个服务来处理，如果某个组内容特别多，则可以进一步拆分，比如

• 电商组

店铺服务 商品服务 等

当然，微服务化肯定不是一蹴而就的，先将基础服务，一个一个做出来，然后再改造原来的 Laravel 项目，进行 RPC 通信，一步一步的把 Laravel 项目搬空即可。

可以考虑模块插件化，可以参考下：github.com/jianyan74/rageframe3

1.先拆功能模块 2.确定服务边界 3.使用hyperf 4.今天疯狂星期四，V我29.9

考试平台是自己开发的吗？

微服务的目的是解耦单个项目中各模块之间的逻辑体系，写代码更顺畅。

你将几个毫不相干的项目强行合并在一块，为了微服务而微服务最后的结果注定是失败。

当然如果楼主是为了KPI为了简历好看点也是可以理解的。

换Java，你现在的开发人员最少要多几倍

分布式为什么 不试试 yaf ，独立出不同的项目 其他项目 调用一下 封装一下方法，不一样处理吗？

微服务架构对技术团队的要求会高，Go或Java搭建基础服务，逐步迁移，Go是一个不错的选择

把不同的模板,分成不同的laravel项目 项目之间,通过 http 去调用 不同的项目,使用相同的配置,同一个数据库 不一定要走微服务

mark

电商 租赁 考试平台 erp 管理，如果模块之间没太多关系，每个模块一个laravel项目，打通用户授权就可以了，项目之间也可以通过http接口调用。 集群是你一个服务器扛不住访问时候的方案，和项目开发有啥关系？ 4个人上来就springcloud、微服务，你不是要坑死自己就是要坑死公司

• segmentfault.com/a/119000003992854... 这篇文章，对于理解微服务应该有很大的帮助【防喷】

小公司不要盲目迷信微服务

我们前单位原来单体架构，1台服务器跑得好好的，2个php，1个前端。

后来公司领导觉得微服务、中台很牛逼，就招人用Java重构，

用微服务重构后，现在用了几十台服务器，

技术团队也变成了6个Java，2个前端，1个运维，1个DBA，一个高级架构师。

老板最近想裁员…发现离不开这个团队了

四个人，要是4个都没这方面经验，你要是听他们的，搞不死你。
到时候结果就是，

新需求接不过来

老需求迁不过来

这群人动动嘴巴真厉害。

上面

加入新的模块很难维护,

不敢说百分百，很大部分可能单体服务写的就很混乱，难维护？拆开赶鸭子上架一样混乱，还到处bug。
还不如花点时间研究一下先把目前单体服务好好理理。

单体架构真的不行了吗？必须使用微服务了吗？如果不是必须的，建议还是从当前进行优化来搞定。而不是一味的靠新功能来解决老问题。如果是想折腾，当我没说

我的建议是，先想办法把电商 租赁 考试平台 erp 这些独立成单独的项目。公共用到的东西，比如用户登陆授权，看使用什么方式共享比较好。我比较建议使用http协议交互。 你这种都不能说是单体项目，应该说是多个项目强行柔和在一起的怪物。只需要把各个项目独立开来就好，不用做太复杂的改动。

后续关注下，能加个微信吗？

大佬，我想问个问题，考试系统提交的时候比方说交卷的时候有100道题目，这个是做循环100次吗来判断对错？

多人开发可以考虑 Porto模式的github.com/apiato/apiato

用go 的一些微服务框架也很方便，前提是要理清业务模块，规划好，开干

如果招java进来信不信一年以后你们自己就被挤掉了

这几个项目看起来没啥大关联，直接分开不是更好吗？再加个SSO，不是舒舒服服嘛

百分之90的问题，单体架构也能解决。如果是想提高并发，还不如迁移到单体swoole项目。微服务是不建议的，单体swoole已经足够满足大部分并发需求了。