服务注册中心开发花了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::
``