现在 web 服务都走服务化， PHP 只能作为纯前端， phper 的道路应何去何从？

[wwek]

知乎上看到这个问题，写了篇博客说这个 下一代微服务（ Service Mesh ）很可能是解药

https://www.iamle.com/archives/2422.html

[est]

从渲染 html 变成 渲染 json 再变成渲染 protobuf 而已。没啥新鲜事。

迟早还会再次变成直出 html 再一次发明了改变世界。

[owenliang]

每一年都有很多可能，然后没有卵用。

[est]

要得我说，Service Mesh 解决个屁的问题，只是把问题隐藏在更深、更复杂的架构里了。

monolith 大法好。剩下的 10%的 monolith 不能很好解决的问题，service mesh 解决起来也别扭。

[wwek]

@est 看问题看得透彻

[ben1024]

服务化通过增加成本，牺牲效率，来解决业务量过大的问题。

没有对应的业务量就没有性价比

人力水平参差不齐的情况下，1 个人用 PHP 渲染前端还是比多个人交互开发快

[wwek]

@ben1024 同意~
如果是 php 体系， 项目到了十几个， 里面有很多共同依赖调用
开发人员到了 10 几个这个问题就来了

[wwek]

补充下，其实我就是讲
1. phper 不要担心 php 被淘汰
2. phper 在未来微服务体系中不会被边缘化

[linoder]

服务化对应的是公司组织架构的变更 语言无关 千万不要太局限自己

[hlwjia]

只有做过微服务的人才知道 @est

hahaha, 还是 monolith 好；要不是有那么多客户端，我觉得前后端分离都不是太必要了。

前后端分离的好处，现在起现在了，pc web, mobile web, mobile client, 小程序 啥的都能用一套后端

[jadec0der]

因为服务发现和别的不一样，所以赶不上微服务…这个逻辑有点跳啊，其实这算 P 大点问题，怎么绕一下不行

[Felldeadbird]

算我业务眼界太短了，几十个项目出来后，如果纯粹复制粘贴，问题肯定大大的。 在维护超过 3 个相似的项目时，不就应该将核心部分拆分，打造中心发布么。 我第一份工作就是这么干的。N 个项目，但产品等核心都是由内部中心系统对外发布的。
好像这么做和语言没关系啊。这是公司对于业务架构调整的必遇问题。

[wizardforcel]

你以为微服务架构里的 web 容器就能省是么-____-

[tailf]

服务化本身就是非 PHP 技术因为没有 PHP 的技术优势才搞出的妥协。

就像设计模式的本质就是面向对象编程模型对现实世界问题的妥协。

妥协，都是妥协。x86 计算机的性能都是 局部性+缓存 的结果，也是一种妥协。

[tailf]

看到楼上在讨论为服务，我说一个我从某个大神那儿学到的知识：

PHP 天生就是微服务。


慢慢理解吧，你会理解的。

[sampeng]

和 php 无关。。把 php 换任何一个词这个标题也成立。。。。

真的觉得微服务就是被亚马逊那套唬住了。。。。

[nuxt]

@tailf

[rrfeng]

要我说 service mesh 是很美好的，只是大多数人没有能力把它构建出来并且运行的很好。
说白了和微服务一样，是大公司的玩具，先让基础架构的人跟业务开发一样多再说。

[meloner]

不要把注意力放在语言层面

[fyxtc]

@meloner 确实，重要的是领域知识

[dlpliu]

突然联想到，民主和专制

[linxl]

甚至看不懂这个问题

[tailf]

@nuxt 一个 Google 到的文不对题的搜索结果能说明什么？迁移到 go 需要大牛支撑，因为坑多。好了我不做过多评价了，您可以选择相信您看到的信息嘛。

[wwek]

回过头来看待这个问题，servicemesh 也没有大获成功，大部分情况还是单体香
引入一个技术要解决问题，要有收益，技术收益，没收益我搞他做什么

不要拿着锤子找钉子
php 就好好干 web ，而且现在会 php 的都应该会 golang 了，很好的互补