你的业务是怎么演变为微服务的

标签：部分   又能   集中   其他   new   代理   反向   php   开发   

以前的项目譬如新闻模块和商品模块是放到一个项目（譬如tp）里开发的。对么
1、现在 商品每天访问量100万，新闻每天访问只有200 。 那么再用以前的方式部署就不行了。
2、所以要把商品模块单独拿出来，分表部署到3台机器上做负载均衡

由于拆分出来了。 所以 新闻模块 如果要在新闻页面里 显示个最热商品列表 咋办？
1、传统做，直接require news.php就行了。现在不行了
2、难道新闻模块直接 select * from product ? 耦合度也太高、太挫了

所以商品模块 就要专门放出一个 API地址 譬如叫做、 /product/fuck
这就是最早的rest api  

由于 http api可能有点慢。 于是商品模块 提供了一个基于jsonrpc的 rpc接口。 就快了 对吗？

由于 http api可能有点慢。 于是商品模块 提供了一个基于jsonrpc的 rpc接口。 就快了 对吗？

到以上为止。 还不能叫 微服务 。 只能算是 把服务分开来部署、分开来独立调用、用了 rpc技术 而已  

真正的关键在于。（我举两个最简单的点）
1、新闻模块 怎么知道 商品模块的 API 地址在哪？ 写死在程序里吗？
2、如果商品模块宕机了。 是不是新闻模块页面 也 卡死在哪？

你的业务是怎么演变为微服务的

标签：部分   又能   集中   其他   new   代理   反向   php   开发   

原文地址：https://www.cnblogs.com/zzg521/p/11774316.html