我的回答是：
"微服务可以不用服务发现和负载均衡吗？它是微服务一个核心组件。怎么能说没有关系？"
我觉得有必要来思考和总结一下服务发现技术是如何演进的。于是周末一通阅读和消化，希望能掰开揉碎在这里讲一下服务发现技术的演进历史。
催生的背景为了提升研发效能，赋能业务规模化创新。不管是一线互联网企业还是传统互联网企业，将单块架构解耦成微服务架构，已经成为企业目前数字化转型的一个大趋势。
微服务架构下的服务少则几个，几十个，多则上百个，每个服务一般都以集群HA的方式进行部署。
这个时候就出现了两个问题：
一个是服务发现，也就是服务的消费方Consumer如何找到服务的提供方Provider。
另外一个是负载均衡，服务消费方如何以负载策略去访问服务当中的服务提供方的实例。
在服务发现演进过程中，先后出现了三代服务发现解决方案。这三代的核心都是代理，只不过代理在架构中出现的位置是不同的。通过在消费方和提供方中间增加一层代理，由代理来处理服务发现和负载均衡等功能，消费方通过代理间接去访问服务实例。
该方案比较简单，在消费和提供方中间部署一层代理服务。
常用的集中制代理有硬件负载均衡器，比如F5/A10；或者软件的负载均衡器，比如Ngix，HAPROXY。也可以是软硬结合，比如前面是F5，后面是Ngix，这种方法兼顾了配置的灵活性，因为Ngix比F5更容易配置。
这种配置需要引入DNS服务域名进行配合，每个服务都要申请注册域名，并且每个域名都要在代理上配置域名和服务IP的映射关系。
DNS和代理的配置一般由运维人员手工完成。
国内外的公司采用这种方式的有ebay，携程，拍拍贷。
缺点是手工配置，效率不高也缺乏灵活性，对开发人员不友好。
第二代：客户端嵌入式代理随着微服务和云技术的兴起，企业对服务发现的效率和灵活性提出了更高的要求，于是出现了第二代方案。
该方案将服务发现和负载均衡以客户库Library的形式嵌入到应用或服务程序中。
该方案需要独立的服务注册中心配合，服务启动的时候将服务自动注册到中心，并且定期的报心跳进行保活。客户端通过服务注册中心发现服务的ip列表，通过某种负载均衡策略选择某个服务进行调用，这种对开发人员比较友好，可以做到开发自助，不需要太多的运维介入。
这种做法也是很多互联网公司的一个主流，相应的开源也很多。比如：
eureka就是一个注册中心，配套ribbon客户端代理。
dubbo和近期开源的nacos
consul+ribbon
缺点：
客户端依赖语音栈，不同的语言需要开发不同的客户端，在微服务下可能出现的多语言问题，显然开发成本太高。
另外嵌入式代理也给客户端增加了复杂性
第三代：主机独立进程方案。随着容器和云原生技术的兴起，业界开始探索第三代的解决方案。