up:: 课程价格模块开发
说明：
我们先想象一下，我们是这个程序架构的一个设计者，最开始的时候呢，大家如果想要相互调用各自服务模块的话怎么办呢？
通过ip调用
比如说呢我这边起了一个服务，然后我把 ip 告诉你，你就把我的 ip 写到代码里，或者你可以写到配置文件中，然后你来找我调用，这样就没有问题，但是这个没有问题，仅仅是针对早期的时候，没有问题，因为你服务的比较少，大家相互之间调用也不频繁，只要通过 ip 就可以了，
不把ip写死
如果你写死的话，就有可能会导致所有依赖方他们的代码都需要去调整，这个问题就很大了，因为 ip 变化其实是常有的事情，有的时候，我们的网络环境发生变化了，或者我们整个这个服务器都出了问题或者换网卡呀等等各种各样的一些情况吧都有可能会更换 ip， 不能说是我的 ip 换了会影响到你，甚至说我的 ip 换了会影响到整个系统，这肯定是不可取的，那尤其呢，是在我们使用微服务之后，其实是非常的多，而且不仅仅是多样，服务内部的变化也是很频繁的，那有的时候我们需要动态的去给某一些服务增加一些事例，比如说最近我订单量涨了或者商品访问的特别频繁，那我们就很有可能会多开几个订单服务或者是商品服务，来提高我们的处理能力，那这个时候你不能说每增加一个订单服务，我就把所有代码去调整一遍，这样的话实在是太费劲了。我们希望的情况是说呢，如果新增的服务我们自动的就知道了，我们的订单服务呢，多了一个事例，以后的请求就可以自动的转发到这个实例上，那这个就是我们想要达到的目标。
每个服务去起一个名字，然后再把 ip 去绑定到这个名字上，那后续假设我们想要调用订单服务，我们就去问管理员订单服务最近有没有什么 ip 变化呀？我现在应该在用哪个呀？这样的话呢，他管理员就会实时的把最新的情况告诉你，也就避免了我们把 ip 写死，那其实这边所说的管理员就是我们服务的注册与发现，这也是他诞生的一个原因。
Eureka架构
