flylan

> * apollo-sdk/config 1.0.5 requires guzzlehttp/guzzle ^6.5 -> found guzzlehttp/guzzle[6.5.0, ..., 6.5.x-dev] but the package is fixed to 7.3.0 (lock file version) by a partial update and that version does...

可以详细说一下你这边的问题么？namespace是怎么样的json格式？我这边需要模拟一下你的使用场景

其实正常业务使用，基本不会采用直连模式的。 常规做法是启动一个常驻的cli进程负责配置更新工作，将配置缓存到服务器本地。业务端读取本地的缓存文件，进行加载配置的。

直连模式有一个比较大的风险，一旦阿波罗配置中心挂了，就会牵连到业务系统，例如配置中心无法访问，获取配置接口返回502了，这样业务系统就读取配置异常了。甚至配置中心接口请求超时了，然后业务系统也跟着请求超时了。 php的脚本是生产周期是页面级的，无法把配置持久化在内存，只能每次脚本运行时调用接口或者读取本地配置文件加载配置，有兴趣的人可以写个pecl扩展，类似鸟哥的yaf，在php-fpm启动时，通过php-fpm与阿波罗配置中心建立连接，然后维持配置更新工作，这样脚本就可以直接调用相应的类进行读取配置了。

这个库的职责定位是lib，不是client的实现。如果需要client的实现可以看看这个仓库 https://github.com/fengzhibin/apollo-sdk-clientd 这个clientd就是基于这个库实现常驻的client，这个常驻的client负责与阿波罗配置中心保持通讯，把配置通过json格式缓存到服务器目录。业务端可以通过指定的函数获取配置

> @fengzhibin 我刚试了下，用clinet，configservice和client都部署在本地的话会报错 > > ``` > PHP Warning: Undefined property: App::$server in /home/fishwade/Projects/apollo-sdk-clientd/bin/apollo-clientd.php on line 67 > > Warning: Undefined property: App::$server in /home/fishwade/Projects/apollo-sdk-clientd/bin/apollo-clientd.php on line 67 > 【ERROR】通过curl请求时产生错误，错误信息如下：...

试试把这个http://portalIp:8070/改成http://portalIp:8070看看

哈哈，我也认为apollo server端采用java真是太重量级了，本身就是对外提供两个http接口。server端可能就是多了个分布式集群功能支持而已。

> > 哈哈，我也认为apollo server端采用java真是太重量级了，本身就是对外提供两个http接口。server端可能就是多了个分布式集群功能支持而已。 > > 主要是java性能太烂了， 服务器cpu和内存都要钱 其实apollo服务端使用java springboot开发，就像拿牛刀去给苹果削皮一样。