我们先来看下什么是服务注册与服务发现？服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去（比如: zookeeper\consul）。服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。
单机时代，传统软件大多是单体/巨石架构(Monolithic)。大家往一个代码仓库提交CODE，这会导致应用膨胀，难以理解和修改，以及扩展受限，无法按需伸缩等诸多问题。单体架构怎么解决多人合作的问题？模块化，对，按功能拆分，模块之间定义编程接口(API)，彼此关心功能而不关心实现。
近日来，和很多来自传统行业、国企、政府的客户在沟通技术细节时，发现云原生所代表的技术已经逐渐成为大家的共识，从一个虚无缥缈的概念渐渐变成这些客户的下一个技术战略。自然，应用架构就会提到微服务，以及其中最重要的分布式协作的模式——服务发现。模式（pattern）是指在特定上下文中的解决方案，很适合描述服务发现这个过程。不过相对于 2016 年，现在我们最少有十多种的方式能实现服务发现，这的确是个好时机来进行回顾和展望，最终帮助我们进行技术选型与确定演进方向。
社区版本 Dubbo 从 2.7.5 版本开始，新引入了一种基于实例（应用）粒度的服务发现机制，这是我们为 Dubbo 适配云原生基础设施的一步重要探索。版本发布到现在已有近半年时间，经过这段时间的探索与总结，我们对这套机制的可行性与稳定性有了更全面、深入的认识；同时在 Dubbo 3.0 的规划也在全面进行中，如何让应用级服务发现成为未来下一代服务框架 Dubbo 3.0 的基础服务模型，解决云原生、规模化微服务集群扩容与可伸缩性问题，也已经成为我们当前工作的重点。
关注时代Java
