以前的项目譬如新闻模块和商品模块是放到一个项目（譬如tp）里开发的。对么
1、现在 商品每天访问量100万，新闻每天访问只有200 。 那么再用以前的方式部署就不行了。
2、所以要把商品模块单独拿出来，分表部署到3台机器上做负载均衡
由于拆分出来了。 所以 新闻模块 如果要在新闻页面里 显示个最热商品列表 咋办？
1、传统做，直接require news.php就行了。现在不行了
2、难道新闻模块直接 select * from product ? 耦合度也太高、太挫了
所以商品模块 就要专门放出一个 API地址 譬如叫做、 /product/fuck
这就是最早的rest api
这时 新闻模块 只要用httpclient (或curl）。 去请求商品的这个API就行了 对吗？
由于 http api可能有点慢。 于是商品模块 提供了一个基于jsonrpc的 rpc接口。 就快了 对吗？
由于 http api可能有点慢。 于是商品模块 提供了一个基于jsonrpc的 rpc接口。 就快了 对吗？
这时 新闻模块 只要用httpclient (或curl）。 去请求商品的这个API就行了 对吗？
到以上为止。 还不能叫 微服务 。 只能算是 把服务分开来部署、分开来独立调用、用了 rpc技术 而已
真正的关键在于。（我举两个最简单的点）
1、新闻模块 怎么知道 商品模块的 API 地址在哪？ 写死在程序里吗？
2、如果商品模块宕机了。 是不是新闻模块页面 也 卡死在哪？
自然而然的 你会想到一个事 “tmd服务分开了这么多。 老子需要管理这些服务。让这帮狗日的 能够稳定运行”
这就是服务治理。 你需要服务注册中心、消息总线、服务熔断降级、限流、网关等
从这里开始 你进入了 服务治理。 这才是真正的微服务的开端
一个微服务项目做得好不好 。不在于你用了多高大上的第三方
而在于如何 恰到好处（成本）的 进行服务治理
恰到好处在于 你怎么 控制成本 ，又能高性能的完成功能 。且可控
譬如刚创业，才几千用户。 你直接上k8s来治理了。那你一年就搞技术了 ，赚不到钱了
再譬如网关。 如果你只有2-3个服务，服务之间 也就一个反向代理（路由）。没有其他公共部分。 那么只要openresty（甚至nginx就行了）
如果有 譬如限流功能，需要和自己的业务权限相结合，公共部分又很多。怎么你就要用高级的网关，甚至自己定制化开发业务网关
公共部分越来越集中，各个产品线 都有统一管理需求。 此时，你就要考虑 把这些货色抽出来做中台了
穷->有点钱->有钱->拿到融资->洗钱
不同阶段，使用的技术手段是不一样的
不同阶段，使用的技术手段是不一样的
http api也属于rpc。 只不过 往往大家说的rpc都是tcp的。 而http 除了tcp还要走一层http
还有个重要原因 不是所有服务 都要对外 发布
有些服务功能 就是 给其他模块调用的 我打个比方
譬如 商品下单。流程是 订单入库->减库存->发送下单成功邮件->赠送用户积分
这里面 就只有 订单入库 是对外API（所谓对外，就是吃瓜群众需要 能够提交访问的）
其他几个功能 都是服务和服务之间暗通款曲。 所以没必要做成http api