我们要满足实际业务的需求, 订单量太大了, 单台服务器经常支撑不了了, 于是就想到, 部署多台服务来分担压力.
就出现了上面的模型, 可是, 这个模型存在什么样的问题呢?...最初, 我们的想法也很简单
首先有一个数据库表来维护所有的服务, 并标记这些服务的启动状态
然后, 每当有一个服务启动, 那么都调用注册接口, 其实注册接口就是一个insert服务器信息到数据库的过程...还来不及发出通知
每次商品服务调用订单服务, 都要去数据库查询可用的服务列表, 这样当流量大了, 就会给数据库造成很大的压力, 而且, 每次都查数据库, 效率也不高.
注册中心宕机 了怎么办?...当商品服务和订单服务启动的时候, 需要调用注册接口, 告诉注册中心, 我上线了, 实质上这是一个insert记录的过程
3. 商品服务和订单服务有一个定时任务timetask1, 定期发送心跳....在注册中心有一个定时任务timerTask3, 如果注册中心在规定的时间内, 没有收到微服务的心跳, 那么就认为服务挂了, 将其状态设置为down, 下次拉取的时候, 这台服务器不会被拉取过去.