对分拆系统的思考

使用模型，对不同库的模型单独配置数据库连接后，操作和在一个库里面是一样的

如果 你直接用db就不用

rpc，或者简单点，内部api调用

这个应该是典型的 SSO 了吧。

你完全可以封装成一个 Open API ，通过浏览器 GET 异步获取（只要头像和昵称之类的基础，花销会少很多），就不会污染到用户系统。

这样大大降低系统间的耦合程度。

服务之间db隔离，需要的信息要开接口获取

不同库,同代码也可以。
config/database.php

'mysql' => [
    'database' => env('DB_DATABASE', 'forge') //官网的数据库
   ....
 ],
'shop_mysql' => [
    'database' => 'shop',  //商城的数据库
   ...
]

创建一个全局中间件

  if( 是商城)
  DB::setDefaultConnection('shop_database'); // 切换为商城的数据库

想切换其他库,如App\User

public  function setShop()
{
//  DB::connection('shop_database');
//忘记了 具体看模型吧  手打 可能有错
  $this->connection = 'shop_database';
  return $this;
}

$user = new \App\User();
$user->setShop()->find(1);

(拆库没什么意义,我之前就喜欢瞎拆库)

如果系统不大，拆分沒啥意义，反而徒增复杂度。
如果非要拆分成库的话，可以按业务拆分，一个member库，一个广告库，其他业务库…

member库放用户相关的表，基础表，详情表，登陆表等

广告库就放广告相关的业务表。

多库操作，laravel配置起来也很方便，不同表继承不同的基础model，基础model使用connection连接对应的库即可。

这个还是看业务发展情况来定，用户体量小、收益一般这种就没啥好考虑的了，先公司的考虑生存问题吧。业务量达到一定规模，用多个数据库会方便很多。大体是合理的考虑，设计理念不过度超前业务，公司不同的发展时期考虑的问题也不一样。实现的方式也有很多，模型、DB、event等等。具体怎么实现就没必要解释了，合适的阶段选用合适的东西，

最简单的方式是服务之间数据库直接互通，但是这样耦合性较强，可以考虑在用户服务中提供根据 ID list 获取 Users，然后调用方根据访问数据表里的 user_id 从Users 里获取用户信息，追加到 访问记录的查询结果里。

一般来说性能不会有太大问题，如果并发高，那就上缓存呗，其他服务直接从 redis 里获取用户信息，用户服务负责维护 Redis 里的用户信息变更。

没搞过微服务，其实我很好奇，最后数据汇集的地方都是要foreach去进行数据拼装的吗？有没有一些工具做这种事情的

你还是没搞明白拆分的目的和思路。 既然拆分就不应该存在数据库重叠的情况，用户这种公共服务也拆分出来一个用户认证服务。