知乎上看到这个问题，写了篇博客说这个 下一代微服务（ Service Mesh ）很可能是解药
This topic created in 3126 days ago, the information mentioned may be changed or developed.
 |
estApr 17, 2018
1
从渲染 html 变成 渲染 json 再变成渲染 protobuf 而已。没啥新鲜事。
迟早还会再次变成直出 html 再一次发明了改变世界。 |
 |
owenliangApr 17, 2018 via Android
2
每一年都有很多可能，然后没有卵用。
|
|
3
要得我说，Service Mesh 解决个屁的问题，只是把问题隐藏在更深、更复杂的架构里了。
monolith 大法好。剩下的 10%的 monolith 不能很好解决的问题，service mesh 解决起来也别扭。 |
1 |
ben1024Apr 17, 2018
5
服务化通过增加成本，牺牲效率，来解决业务量过大的问题。
没有对应的业务量就没有性价比 人力水平参差不齐的情况下，1 个人用 PHP 渲染前端还是比多个人交互开发快 |
 |
7
补充下，其实我就是讲
1. phper 不要担心 php 被淘汰 2. phper 在未来微服务体系中不会被边缘化 |
 |
linoderApr 17, 2018
8
服务化对应的是公司组织架构的变更 语言无关 千万不要太局限自己
|
 |
hlwjiaApr 17, 2018
9
只有做过微服务的人才知道 @est
hahaha, 还是 monolith 好；要不是有那么多客户端，我觉得前后端分离都不是太必要了。 前后端分离的好处，现在起现在了，pc web, mobile web, mobile client, 小程序 啥的都能用一套后端 |
 |
jadec0derApr 17, 2018
10
因为服务发现和别的不一样，所以赶不上微服务…这个逻辑有点跳啊，其实这算 P 大点问题，怎么绕一下不行
|
 |
FelldeadbirdApr 17, 2018
11
算我业务眼界太短了，几十个项目出来后，如果纯粹复制粘贴，问题肯定大大的。 在维护超过 3 个相似的项目时，不就应该将核心部分拆分，打造中心发布么。 我第一份工作就是这么干的。N 个项目，但产品等核心都是由内部中心系统对外发布的。
好像这么做和语言没关系啊。这是公司对于业务架构调整的必遇问题。 |
 |
wizardforcelApr 17, 2018 via Android
12
你以为微服务架构里的 web 容器就能省是么-____-
|
 |
tailfApr 17, 2018
13
服务化本身就是非 PHP 技术因为没有 PHP 的技术优势才搞出的妥协。
就像设计模式的本质就是面向对象编程模型对现实世界问题的妥协。 妥协，都是妥协。x86 计算机的性能都是 局部性+缓存 的结果，也是一种妥协。 |
|
tailfApr 17, 2018
14
看到楼上在讨论为服务，我说一个我从某个大神那儿学到的知识：
PHP 天生就是微服务。 慢慢理解吧，你会理解的。 |
 |
sampengApr 17, 2018
15
和 php 无关。。把 php 换任何一个词这个标题也成立。。。。
真的觉得微服务就是被亚马逊那套唬住了。。。。 |
 |
rrfengApr 17, 2018 via Android
17
要我说 service mesh 是很美好的，只是大多数人没有能力把它构建出来并且运行的很好。
说白了和微服务一样，是大公司的玩具，先让基础架构的人跟业务开发一样多再说。 |
 |
melonerApr 17, 2018 via Android
18
不要把注意力放在语言层面
|
 |
dlpliuApr 18, 2018
20
突然联想到，民主和专制
|
 |
lazypuApr 18, 2018
21
甚至看不懂这个问题
|
|
23
回过头来看待这个问题，servicemesh 也没有大获成功，大部分情况还是单体香
引入一个技术要解决问题，要有收益，技术收益，没收益我搞他做什么 不要拿着锤子找钉子 php 就好好干 web ，而且现在会 php 的都应该会 golang 了，很好的互补 |
Select Language