summer项目开发六:服务开发

服务注册中心开发花了1周左右,期间改了几个版本,优化重构了下core代码。大致能完成之前设计的功能,当然还有很多不足和值得优化的地方,不过先完成大致框架和功能,等整个流程跑顺了,再来优化细节。

注册中心提供了服务注册,通知更新,服务列表查询,那么一个服务要想调用其他服务接口或被人家调用,就需要完成相应的功能。

功能需求

  1. 把自己注册到服务中心
  2. 接受更改通知
  3. 拉取服务列表更新本地。
  4. 开发友好,拉取编辑器提示文件(待实践)

设计

  1. 注册及拉去服务应该是自动的,开发者不用去关心实现细节。
  2. 服务应该保持足够小的粒度
  3. 提供一些常用服务,尝试建立服务市场,比如需要开发个邮件服务,应该一行命令在服务市场拉去一个服务,简单配置几下,就可有一个发送邮件的服务,其他服务可以直接调用即可,又比如 短信/oss/微信接口/支付/订单/物流/验证码等等。 想象一下,如果公司让你开发一个系统,包含几十项功能,你慢慢开发得多久?其他系统拷贝过来得怎么改? 基于微服务的,只用调用接口即可,想想是不是很开心?当然,这只是我一个设想。
  4. 关于服务开发的所需的组件:开发一个接口或者服务也好,免不了要用很多组件,比如db,router,cache,log,auth,config等等。大部分框架都是一把梭,都要自己开发。当然,有些组件是他框架所依赖或者完成某项功能所必须的。 反正我的原则就是symfony和zend有的库,绝不再重复写, 之前写manager和注册中心的时候,大量使用了symfony和zend的库,节约了大量的时间,而且我也没有时间和精力维护那么庞大的一个框架,人家更新了,你直接update不就好了,站在巨人肩膀更省力。所以需要开发的时候尽量注意控制自己开发的组件依赖,尽量让开发者自己选择需要用什么组件和方式,更愉快的开发。

开发

要遵循前面设计的思路和原则,看起来简单,实则很头痛。既要对系统少侵入,又要实现功能。额,其实还没有很好的思路和解决办法。估计又得折腾1周甚至几周了。。。慢慢来吧,待续。。。。


---2019年7月10日更新-----

目前处理了api注册问题。现在需要处理rpc接口问题。把一个服务提供2种接口,api对外rest格式,rpc内部调用接口。
根据在某些群里收集的意见和建议,rpc调用模式暂定为:
服务端

namespace app\rcp;
class User
{
    public function search(){}
}

上报(api)服务 path=> '/user' ,
rpc目录下的都默认上报 public方法作为对外暴露的接口

客户端
``
SRPC::
``

标签: 无

发表评论: