微服务架构不是银弹，在微服务架构中，我们将面临很多新的问题，这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同，三种主要的服务注册与发现和负载均衡方案。
1.微服务架构下服务注册与发现机制
随着微服务架构深入人心，越来越多的企业将微服务架构付诸实践。相比于传统的单体应用架构，微服务架构有着得天独厚的优势;在传统的单体应用架构下，因为功能集中，代码中心化，一个发布包部署发布在一个进程的应用程序中，单体应用架构已经无法满足企业业务快速变化的需求。
一方面，代码维护困难，扩展性较差，灵活性较低，另一方面，系统的修改成本，维护成本在增加以及构建时间，发布周期很长。而微服务架构，因为服务之间独立部署，每个服务在开发，测试，部署的时候，无论是开发周期还是难易程度，都比单块应用要好。
然而，微服务架构不是银弹， 在微服务架构中，会面临很多新的问题，微服务架构由一组小的服务组成，服务之间采用轻量级的通讯机制进行沟通，微服务之间调用关系是一个网状结构，一个微服务在调用另一个微服务的时候，无法知道另一个微服务的具体地址;由于每个服务属于”微”服务，每个服务生命周期不长，每个服务可能随时被关闭、重启、替换;在随着访问量增加的时候，微服务需要扩容，访问量减少时，微服务需要缩容;这样就导致每个微服务的地址在动态变化，这时候必然引入一个服务注册发现问题，也就是说客户端在调用的时候，需要知道服务端的地址，服务端在提供服务的时候，需要注册通告自己的地址，供客户端调用;同时服务端一般存在多个实例来提供服务，这就要求需要引入负载均衡的能力，随着负载均衡位置的不同，主要的服务注册与发现和负载均衡方案有三种。
2.常见的服务注册与发现的方案
1).集中式负载均衡方案
集中式负载均衡也叫服务端负载均衡，如图1所示，负载均衡器在一台单独的主机上，可以采用软负载，如nginx，apache等，也可以采用硬负载，如F5等，它负责多实例服务的负载均衡，客户端直接通过域名访问负载均衡器，DNS服务器将域名解析到负载均衡器IP上：
该方案实现较为简单，仍是业界的主流，可以充分利用负载均衡器的能力，根据不同的负载策略将请求分发到后面的服务实例上;同时，该方案缺点也很明显，负载均衡器存在单点问题，所有的流量都需要通过负载均衡器，如果负载均衡器存在问题，则直接导致服务不能正常提供服务;中间经过负载均衡器做代理，性能也有一定损耗。
2).客户端负载均衡方案
客户端负载针对服务端负载的缺点，做了一定的改进，如图2所示，负载能力由客户端进程提供，服务端实例注册自己的地址到注册中心，客户端从注册中心订阅服务提供者的地址，获取地址后，根据负载均衡实现策略进行服务路由：
该方案在解决了服务端负载的单点问题，每个客户端都实现了自己的负载功能，负载能力和客户端进程在一起，和客户端的生命周期一致，如果负载均衡进程down了，则客户端也down了，而且只影响本身客户端，不会影响其他客户端;同时，该方案也有一定的缺点，负载要求每个客户端自己实现，如果不同的技术栈，每个客户端则需要使用不同的语言实现自己的负载能力，技术难度较大;业界的motan，dubbo采用此方案做服务注册与发现。
3).客户端主机独立负载均衡方案
第三种方案综合了前2个方案的优缺点，如图3所示，服务发现和负载的能力从客户端进程移出，客户端进程和负载均衡进程是2个独立的进程，在同一个主机上;服务实例还是在启动的时候注册自己的地址到注册中心，客户端直接发送请求给本机的负载均衡器。
该方案是一个典型的分布式方案，没有单点问题，如果一个主机的负载均衡器出问题，只影响一个节点调用，不影响其他的节点，负载均衡器本身负载也较小，性能损耗较低;同时也不需要多种语言实现自己的负载能力，负载能力是公用的;但是该方案部署复杂，维护困难，出了异常之后，调试负载，定位问题都比较麻烦。