图解分布式系统服务注册与发现原理
在微服务架构或分布式环境下，服务注册与发现技术不可或缺，这也是程序员进阶之路必须要掌握的核心技术之一。
一.引入服务注册与发现组件的原因
先来看一个问题，假如现在我们要做一个商城项目，作为架构师的你应该怎样设计系统的架构？你心里肯定在想：这还不容易直接照搬淘宝的架构不就行了。但在现实的创业环境中一个项目可能是九死一生，如果一开始投入巨大的人力和财力，一旦项目失败损失就很大。
作为一位有经验的架构师需要结合公司财力、人力投入预算等现状选择最适合眼下的架构才是王道。大型网站都是从小型网站发展而来，架构也是一样。
任何一个大型网站的架构都不是从一开始就一层不变的，而是随着用户量和数据量的不断增加不断迭代演进的结果。
在架构不断迭代演进的过程中我们会遇到很多问题，技术发展的本质就是不断发现问题再解决问题，解决问题又发现问题。
1、单体架构
在系统建立之初可能不会有特别多的用户，将所有的业务打成一个应用包放在tomcat容器中运行，与数据库共用一台服务器，这种架构一般称之为单体架构。
单体架构-应用和数据库共同部署
在初期这种架构的效率非常高，根据用户的反馈可以快速迭代上线。但是随着用户量增加，一台服务的内存和CPU吃紧，很容易造成瓶颈，新的问题来了怎么解决呢？
2、应用与数据分离
随着用户请求量增加，一台服务器的内存和CPU持续飙升，用户请求响应时间变慢。这时候可以考虑将应用与数据库拆开，各自使用一台服务
器，你看问题又解决了吧。
分布式和微服务的关系单体架构-应用和数据库分离
突然有一天扫地阿姨不小心碰了电线，其中一台服务器掉电了，用户所有的请求都报错，随之而来的是一系列。
3、集部署
单实例很容易造成单点问题，比如遇到服务器故障或者服务能力瓶颈，
那怎么办？聪明的你肯定想到了，用集呀。
应用集部署
集部署是指将应用部署在多个服务器或者虚机上，用户通过服务均衡随机访问其中的一个实例，从而使多个实例的流量均衡，如果一个实例出现故障可以将其下线，其他实例不受影响仍然可以对外提供服务。
随着用户数量快速增加，老板决定增加投入扩大团队规模。开发团队壮大后效率并没有得到显著的提高，以前小团队可以一周迭代上线一次，现在至少需要两到三周时间。
业务逻辑越来越复杂，代码间耦合很严重，修改一行代码可能引入几个线上问题。架构师意识到需要进行架构重构。
4、微服务架构
当单体架构演进到一定阶段后开发测试的复杂性都会成本增加，团队规模的扩大也会使得各自工作耦合性更严重，牵一发而动全身就是这种场
景。
单体架构遇到瓶颈了，微服务架构就横空出世了。微服务就是将之前的单体服务按照业务维度进行拆
分，拆分粒度可大可小，拆分时机可以分节奏进行。最佳实践是先将一些独立的功能从单体中剥离出来抽成一个或多个微服务，这样可以保障业务的连续性和稳定性。
微服务架构
如上图将一个商用应用拆分为六个独立微服务。六个微服务可以使用Docker容器化进行多实例部署。
架构演化到这里遇到了一个难题，如果要查询用户所有的订单，用户服务可能会依赖订单服务，用户服务如何与订单服务交互呢？订单服务有多个实例该访问哪一个？
通常有几种解决办法：
（1）服务地址硬编码
服务的地址写死在数据库或者配置文件，通过访问DNS域名进行寻址路由。