feiandxs
2019-07-14 23:05:28 +08:00
作为公司后端主力是 PHP （其实全是 PHP，只有个别无关紧要的部分我们刚开始尝试用 Go 重写）的人有话要说。
先说观点，即便没有 Docker、不用 k8s，甚至初期没有 API 网关，都可以往微服务的方向改造。改造这事本来就是根据自己公司实际业务情况和人员以及能力配置按需调整的个事。
我也不讲那么多发展的历史，就只说适合我们公司的情况。我们的后端原先是一个大的 Laravel 的单体应用，流量也没大的多吓人（但会有突发流量暴涨情况，确实不好扩展），然后基本随着业务需求慢慢堆叠越来越多的接口就是。本身业务也不算复杂，而且后端每次新增一些接口好像也不是什么复杂的事，比前端自由组合要快多了。
这样的事干了一年后，有点吃不消了，看看路由里记录的乱七八糟，过期的，臃肿的，重复的，极其混乱。然后性能问题当时也越来越多的暴露，但改起来就是动一发牵全身，烦躁的要死。
于是试图下放业务逻辑给前端——直到这时候，我还不知道什么是微服务…… 但我有一个直觉，后端经过一定程度的改造，将各个功能模块拆分开来，既便于扩展，又方便修改，还能给前端以更灵活的组合和调用，后端也可以稍微从繁重的业务逻辑里解脱开来，不需要做那么多重复的事情，更专注于改进架构，改善性能，提高交付速度。
甚至后端和后端之间都可以用网络通信的形式来做数据交互！
到这个时候为止，我仍然不知道什么是微服务。
但接下来，我就遇到了和楼主你同样的困惑。这玩意儿，耗费这么多网络通信，那性能、速度，还有和前端突然增加的那么多交互，怎么办？感觉会立马拖累性能啊。
然后这时候，也是微服务这个概念落地越来越多并且流行起来的前几年了。然后我就知道了有这么两个概念，用于包装微服务的接口，然后根据前端需求输入前端需要的业务接口。这个部分可以传统后端做，也可以前端侵入过来自己做，就是所谓的 Node 中间层。另外一个概念很关键的，叫 API 网关……
然后就突然豁然开朗，开始往自己想要的方向改造。
但进展并不顺利——比如经过试验，确实是容器化更适合微服务，而且几乎是必走的方向，对应的整个生态已经起来了。但我们公司小，破，我能力不过关，事务繁忙，所以一直推进的很慢很慢。另外一个方面，就是服务拆分了，拆分到什么地步最合适呢？原则上是最小化不可拆分的组件方可称为微服务组件，但现实中各种业务进度东搞西搞的，仍然有各种疲于奔命的情况，改造的也是拖拖拉拉，搞的并没那么细致。
还有个问题就是各个模块拆分开来了，可原先简单直连的数据库又有了新的问题。在改造过程中，就突然发现，居然不得不使用数据库连接池了…… 这不是什么新鲜东西，但我们公司是个小作坊公司，能力各种欠缺，整个转换的过程中也各种问题，所以现在只在新项目上用，老的项目还是一个粗暴的连接，对扩展很不利……
可即便这样，我还是在这个磕磕绊绊的过程中逐渐体会到了所谓“微服务”的好处。并不是这个概念本身如何，而是它带来的一个思想，我认为它本质上还是一种分层和分块治理。并不新鲜，但新项目从设计开始我就做了日后可以拆分的准备，同时在准备周边配套设施。当业务中有喘息的时间，同时根据之前上线的业务的经验，我就会推动将部分经过实际业务验证可行的功能模块做分析并拆分，一个一个服务独立出来。虽然还是进度慢，但总的来说，真的需要随着业务做扩展和改造，都不再是一个什么复杂的事。也不需要考虑之前那样一个大的单体应用多机部署的头疼问题，基本上根据监控结果对关键模块做拓展就可以，成本低，速度快，大家也省心……
说了半天其实不算什么微服务经验，只不过是一个同样是用 PHP 作为后端主力，也碰巧同样在用 Laravel 的人的一点感想。微服务是个好东西，但要做到理论上那种难度不小，工程量也挺大，周边配套需要一大堆。但这是个收益长远的事，我现在就享受到了多个项目复用一些功能模块和服务的好处——甚至某些独立模块可以改造后对外输出，给其他公司用，还没增加多少工作量…… 但整个迁移过程还是事满多的，我个人建议根据实际业务的需求来做，并不需要上来上那么大而全的微服务，把关键的，容易拆分的，复用率高的功能先逐个慢慢独立开来，慢慢尝试。有了第一个模块，有了 API 网关，你也可以说你开始微服务了。
哦还有个好处……微服务这个状态下，如果有的时候需要第三方公司或者外包介入协作，其实会更好处理。代码独立，功能独立，约定好接口和规范就可以……特适合我这种几个人的小作坊公司。但目前为止还没找过这样的外包……因为现在经过半年的改造，对自己人来说都业务压力会变小，可以承受，似乎没必要找外包了……