服务治理的不归路 - 1

Posted 2021-04-25 五行代码

　　大概两年多前就接触到swoole这个扩展，发现用它可以做很多原来用php做不到的事情，于是基于它，折腾着写了个及时数据服务，但未有机会真正应用，出生以后就没上过战场，现在还安静的躺在硬盘里吃灰。

　　然后又断断续续的用nodejs去实现聊天室服务，用swoole又去重新实现一遍，总之还是折腾，该长草的还是继续长草。

  　　但也因为折腾，看到了相关联的很多知识点，也萌生了很多想法。有些轮子会直接拿来用，而有些场景，就是很想要自己去造个轮子出来。坚定的认为适合的才是最好的，这大概是一个野生程序员比较倔的想法，科班生莫笑。

　　那实际应用中有哪些场景是可以去改善的呢？应该多了去。

　　长得帅的人有偶像包袱，长了年岁的项目有历史包袱，对于一些陈年代码，很多人报着敬畏之心，说白了就是不敢动，就怕牵一发而动全身。但是随着项目越发变大，潜在的问题就会随着浮出水面。有没有能够不动历史项目的办法，或者最小限度的动呢，这么说来，曲线救国是一个比较好的办法。

        这样，就引出了服务治理，以前的项目可能比较简单，当有多个业务交叉的时候，通常都是各自给个API调用，这种方式也是最普及的了。但是呢，这种方式也有缺点，就是非长连接，有DNS的开销，并且握手握到你酸，也无法支持服务端主动推送。

　　而服务化治理是个很大的话题，如果像我之前的想法一样，总是想把一个东西做完美了再去应用，那肯定遥遥无期的了，于是想，退而求其次，我先把远程调用先给实现了再说吧。

　　大概整理了一下思路，目前要做的，就是先把服务端与客户端给实现了，然后如何更加方便的让消费方无感知的调用，就像本地调用一样，且无需常规的文档支撑，是我下一步想要做的。

大概的方向是这样的：

目前的项目结构挺简单，只有一个server跟client。如下：

基于swoole实现的服务端其实也不难，寥寥几行代码就可以开启一个服务了，处理接收请求实体也可以很简单，这里我先用了call_user_func_array去实现，但其实也可以利用php的反射机制。总之，代码虽简单，但能够实现效果，就不应该被嘲笑。

客户端使用php的魔术方法__call, 将调用的方法与参数发送到服务端。

服务端与客户端就是这样连接起来工作的，那要如何开启服务呢，并如何实际调用呢。在要提供服务的项目中，使用composer将依赖包安装进来：

将所要提供调用的类注册到服务中

消费方只要继承客户端工具，便可直接调用。

这是一个比较粗糙的过程，实际中如果还要消费方去这样使用，无疑还是有沟通成本的，所以接下来要处理的点，就是服务注册与服务发现。还有刚才说过的，无需常规的文档支撑。