微服务化三:swoft

上一篇文章已经介绍了服务发现与注册工具consul
那么有了服务发现与注册后,第二步当然是得有服务

服务

在系统规划的时候,应该清楚的定义服务类型,不是所有接口都是服务。
服务分为系统服务, 业务服务,和前端接口服务
系统服务指硬件资源:数据库,硬盘,内存等等
业务服务:后端提供业务支持的,(非特殊情况)不提供外网访问的服务
前端服务:提供给前端应用调用的服务,包括 app,移动站、小程序、pc站等等,即用户见的部分

原则:千万别为了一时爽,直接后端服务直接透到前端调用。把服务拆分并不是为了简单架构,相反他架构复杂度是增加的,但是当你的业务复杂度上升的时候,这样的架构会让你更轻松应对。

选型

java体系已经很成熟了,go学了个把月,始终感觉资源不足,很多东西要自己写,可能是才学不久不熟悉。
回到我们大php,高性能一说就2个:swoole,workman。 基于之前有用swoole的经验,更倾向于swoole, 选了下swoole的衍生项目,从sd,到有赞的zanphp,easyswoole,等等,都试用了下,总是多多少少有点别扭。 后来看了下swoft,文档还行,大致功能满足,就选它了。swoft文档地址

swoft官网文档已经比较详细了,就不赘述了,我用他主要用户后端提供rpc服务。 其中有几个概念:
rpc服务端,rpc客户端
服务端既提供服务的,客户端调用服务的,因为官网创建的demo代码服务端和客户端代码是在一起的,不太好理解,仔细看了文档和源码,加上亲自测试,明白了他的整个流程:
绘图2.png

服务端定义的接口,如果要对外提供服务,需要放到公共库,不管你是用composer管理,还是git目录,需要其他客户端能拉取
客户端有个要注意:因为每个服务端都是注册到consul的,配置完成后,他会去拉取服务,比如订单,这个时候你需要在客户端创建个订单连接池和熔断器,你每调用个服务,都需要去创建个连接池和熔断器,注意是每个!每个服务的都是独立的。名称和服务注册的名称保持一致就可以了。
然后你就可以通过Reference 去指定调用那个连接池的那个服务,这个服务是他自动从consul的服务列表发现的,前面从服务端公共接口拉下的代码可以用于ide提示。无需实现接口方法。

由于微服务化对于刚接触的人来说,概念比较多,程序运行的流程和原来不太一样,比较难以理解,只有亲手实现下如何在部署个独立服务,然后其他客户端调用,走一遍流程和看一遍还是区别很大的。

标签: 无

发表评论: