关于 PHP 服务治理与微服务的一些疑问

看看 spring-cloud 技术栈好了

我觉得，首先可以先问一个问题——为什么你们要切到微服务去？

如果这个问题能回答的完整，其实已经知道大概从什么地方入手了……

这要看粒度，一个微服务至少由 2-3 人管理吧，如果你就几千行代码，拆了没意义。

@wuhang89 看了好多微服务化架构都是 java 的,痛苦就在于目前的技术栈是 PHP,用的框架是 Laravel,只能继续在 php 上搞事情...

@feiandxs sorry,补充一下,公司有几个款应用,想把共同的模块拆分出去,用户、视频、资讯、消息,服务化处理.

因为别人用微服务，所以我也要用🌸🐔

服务治理 包括注册 但不仅限于此 限流熔断降级监控日志 trace 这些都是

可以了解下 swoole RPC 远程调用
https://wiki.swoole.com/wiki/page/683.html
https://www.easyswoole.com/Cn/Components/Rpc/introduction.html

php 这种在解释器上跑的，用不到这套东西吧……

拆分微服务的理由是，单体应用里每个模块都足够复杂，按性能说，必然是单体应用性能更好。微服务是为了解决当业务太过于复杂的时候，拆成独立的小服务，就容易理解和更新。

@wuhang89 #1 我感觉这玩意就是杀鸡焉用宰牛刀，各大云服务商都有自己的 API 网关、容器服务、负载均衡、链路追踪、监控报警等解决方案，拿来用就好了，何必自己搭建和维护，除非你的业务规模真大到要自建机房了。

PHP 一般配合 service-mesh，因为现在微服务都是 JAVA 那几个框架，不好直接交互（其实也行，要看数据结构的）。

如果使用 service-mesh 原来的就不用怎么动。但如果楼主全是 PHP，就自己 swoole 搞一套吧

楼主可以看看 https://github.com/lizhichao/one 这个，
支持多种协议调用 http tcp udp ……

你们有多少人，能不能维护过来，先搞清楚为什么要切到微服务架构

@Jat001 你这种才是正路子， 直接上 k8s/istio, 自己专注业务就好了

作为公司后端主力是 PHP （其实全是 PHP，只有个别无关紧要的部分我们刚开始尝试用 Go 重写）的人有话要说。

先说观点，即便没有 Docker、不用 k8s，甚至初期没有 API 网关，都可以往微服务的方向改造。改造这事本来就是根据自己公司实际业务情况和人员以及能力配置按需调整的个事。

我也不讲那么多发展的历史，就只说适合我们公司的情况。我们的后端原先是一个大的 Laravel 的单体应用，流量也没大的多吓人（但会有突发流量暴涨情况，确实不好扩展），然后基本随着业务需求慢慢堆叠越来越多的接口就是。本身业务也不算复杂，而且后端每次新增一些接口好像也不是什么复杂的事，比前端自由组合要快多了。

这样的事干了一年后，有点吃不消了，看看路由里记录的乱七八糟，过期的，臃肿的，重复的，极其混乱。然后性能问题当时也越来越多的暴露，但改起来就是动一发牵全身，烦躁的要死。

于是试图下放业务逻辑给前端——直到这时候，我还不知道什么是微服务…… 但我有一个直觉，后端经过一定程度的改造，将各个功能模块拆分开来，既便于扩展，又方便修改，还能给前端以更灵活的组合和调用，后端也可以稍微从繁重的业务逻辑里解脱开来，不需要做那么多重复的事情，更专注于改进架构，改善性能，提高交付速度。

甚至后端和后端之间都可以用网络通信的形式来做数据交互！

到这个时候为止，我仍然不知道什么是微服务。

但接下来，我就遇到了和楼主你同样的困惑。这玩意儿，耗费这么多网络通信，那性能、速度，还有和前端突然增加的那么多交互，怎么办？感觉会立马拖累性能啊。

然后这时候，也是微服务这个概念落地越来越多并且流行起来的前几年了。然后我就知道了有这么两个概念，用于包装微服务的接口，然后根据前端需求输入前端需要的业务接口。这个部分可以传统后端做，也可以前端侵入过来自己做，就是所谓的 Node 中间层。另外一个概念很关键的，叫 API 网关……

然后就突然豁然开朗，开始往自己想要的方向改造。

但进展并不顺利——比如经过试验，确实是容器化更适合微服务，而且几乎是必走的方向，对应的整个生态已经起来了。但我们公司小，破，我能力不过关，事务繁忙，所以一直推进的很慢很慢。另外一个方面，就是服务拆分了，拆分到什么地步最合适呢？原则上是最小化不可拆分的组件方可称为微服务组件，但现实中各种业务进度东搞西搞的，仍然有各种疲于奔命的情况，改造的也是拖拖拉拉，搞的并没那么细致。

还有个问题就是各个模块拆分开来了，可原先简单直连的数据库又有了新的问题。在改造过程中，就突然发现，居然不得不使用数据库连接池了…… 这不是什么新鲜东西，但我们公司是个小作坊公司，能力各种欠缺，整个转换的过程中也各种问题，所以现在只在新项目上用，老的项目还是一个粗暴的连接，对扩展很不利……

可即便这样，我还是在这个磕磕绊绊的过程中逐渐体会到了所谓“微服务”的好处。并不是这个概念本身如何，而是它带来的一个思想，我认为它本质上还是一种分层和分块治理。并不新鲜，但新项目从设计开始我就做了日后可以拆分的准备，同时在准备周边配套设施。当业务中有喘息的时间，同时根据之前上线的业务的经验，我就会推动将部分经过实际业务验证可行的功能模块做分析并拆分，一个一个服务独立出来。虽然还是进度慢，但总的来说，真的需要随着业务做扩展和改造，都不再是一个什么复杂的事。也不需要考虑之前那样一个大的单体应用多机部署的头疼问题，基本上根据监控结果对关键模块做拓展就可以，成本低，速度快，大家也省心……

说了半天其实不算什么微服务经验，只不过是一个同样是用 PHP 作为后端主力，也碰巧同样在用 Laravel 的人的一点感想。微服务是个好东西，但要做到理论上那种难度不小，工程量也挺大，周边配套需要一大堆。但这是个收益长远的事，我现在就享受到了多个项目复用一些功能模块和服务的好处——甚至某些独立模块可以改造后对外输出，给其他公司用，还没增加多少工作量…… 但整个迁移过程还是事满多的，我个人建议根据实际业务的需求来做，并不需要上来上那么大而全的微服务，把关键的，容易拆分的，复用率高的功能先逐个慢慢独立开来，慢慢尝试。有了第一个模块，有了 API 网关，你也可以说你开始微服务了。

哦还有个好处……微服务这个状态下，如果有的时候需要第三方公司或者外包介入协作，其实会更好处理。代码独立，功能独立，约定好接口和规范就可以……特适合我这种几个人的小作坊公司。但目前为止还没找过这样的外包……因为现在经过半年的改造，对自己人来说都业务压力会变小，可以承受，似乎没必要找外包了……

我们公司是微服务架构的 PHP。
用的 easyswoole 框架，通过 tcp 进行服务通讯。
用的 aws 的服务。

我认为 PHP 容器化的最大问题有两个，一个是性能问题，一个是错误处理问题。

本地函数几毫秒处理完的问题，过一遍 rpc 协议层就无端端多了十几毫秒。PHP 又不像 node 或者 go 那样可以把 API 调用丢到后台运行，只能傻傻等待 rpc 返回再往下执行。如果一个 PHP 服务接口里面集成调用七八个微服务 API，单次请求处理耗时可以到数五六百毫秒。

错误处理的问题也是 PHP 微服务化上的拦路虎。一般 PHP 开发时，接口业务流会捕获异常然后判断，在业务处理范围内的向用户输出错误提示，不在常规业务处理范围内的记录异常日志和调用栈，向用户输出未知错误。微服务化之后，可能出现异常的情况增加了许多，包括 rpc 封装异常、内部网络异常、微服务远程异常等等。考虑内部 API 的重试，限流，熔断等机制，需要处理的异常情况更多了。而且不来则已，一来就是洪水一般，非常考验业务开发人员的心理素质。

你的理解是实现层面的。建议看看微服务的发展历史，然后尝试回答为什么要这样。

mark 一下,也想学习这方面的知识