为什么要使用服务发现?

对于一个现代的，基于云微服务的应用来说，这却是一个很麻烦的问题。其架构如图所示：

服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变，因此，客户端代码需要使用一种更加复杂的服务发现机制。

目前有两大类服务发现模式：客户端发现和服务端发现。

我们先来来讨论一下客户端发现。

客户端发现模式

当使用客户端发现模式时，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。

下图显示的是这种模式的架构图：

服务实例的网络位置是在启动时注册到服务注册表中，并且在服务终止时从注册表中删除。服务实例注册信息一般是使用心跳机制来定期刷新的。

Netflix OSS提供了一种非常棒的客户端发现模式。Netflix Eureka是一个服务注册表，为服务实例注册管理和查询可用实例提供了REST API接口。Netflix Ribbon是一种IPC客户端，与Eureka合同工作实现对请求的负载均衡。我们会在后面详细讨论Eureka。

架构演进过程

话说天下大势，分久必合，合久必分，对于架构演进过程而言，也符合这个规律。

最早的应用程序实际上是没有任何架构的，因为那时业务比较简单，没有架构也许是合理的，如图1-3所示。

图1-3 没有架构

但随着业务不断复杂起来，我们意识到架构可以做到水平分层，比如表现层、逻辑层、数据层等，我们可在不同的层上实现每一层所关注的内容，我们称其为“关注点分离”。但此时的架构更像是一块“铁板”，每一层的无法进行分离，因此我们也将这样的架构称为“单块架构”，如图1-4所示。

图1-4 水平分层架构（单块架构）

从此架构发生了更为复杂的变化，层次结构越来越深，而且不再局限于水平方向上的分层，实际上越来越多的应用程序围绕着不同的业务需求来实现，此时出现了“垂直分层架构”，每个垂直应用中实际上都是一个独立的子系统，它们共同组成了整个应用系统。然而，这些子系统一般可以部署在不同的服务器上，这些服务器可以分布在不同的地域中，我们也称其为“分布式架构”，如图1-5所示。

图1-5 垂直分层架构（分布式架构）

业务并没有停止发展的脚步，架构的演变也是如此。分布式应用之间的调用越来越多，整个系统的复杂度急剧上升，人们希望找到一种途径来降低分布式应用之间的耦合。此时出现了面向服务架构（SOA），人们希望SOA能成为解决分布式应用系统复杂性的“银弹”，然而事实却事与愿违。应用的复杂性不仅没有得到解决，反而还让架构变得更加复杂，同时也形成了大量的SOA商业产品，这些现象让人们更加恐惧SOA，将它视为复杂和昂贵的代名词，如图1-6所示。

图1-6 面向服务架构（SOA）

随着互联网行业不断发展，用户对产品的体验要求越来越高，前端的价值逐渐被凸显出来，此时出现了“前后端分离”的趋势，前端工程师专心在界面展现与数据渲染上，后端工程师关注在业务逻辑与数据结构上，前后端只需通过REST API进行交互，工作分工更加明确，开发效率更加高效，如图1-7所示。

图1-7 前后端分离架构

似乎很长时间都未出现任何技术能与当年的SOA相提并论，除了微服务架构。微服务的概念在2014年首次被提出以来，近几年一直是应用架构领域的核心话题。但人们往往还是容易想到当年的SOA，认为微服务与SOA有着相同的目的，只是实现细节不太一样罢了，如图1-8所示。

图1-8 微服务架构

微服务与SOA到底有何区别？

我们认为，微服务是SOA的一种落地方案。

SOA是一种面向服务的架构思想，微服务也同样推崇这种思想。微服务是将一个大型的单块架构，拆分为多个细粒度服务的架构。微服务更加考验我们的是，深入理解业务并合理地对服务边界进行切分。微服务的概念相比SOA更容易落地的原因不是概念上的创新，而是技术上的突破，尤其是容器与自动化运维技术的普及与应用。

我们始终相信，微服务并不是架构发展的终点，也许是新架构时代的起点。

　微服务架构发展趋势

微服务架构所涉及的范围相当广泛，我们不妨从多个角度来推测微服务架构的发展趋势。

从微服务开发角度来看，我们认为微服务的开发框架将变得更加多样化。

开发人员可使用更加适合的开发框架来完成微服务业务实现，而不再拘泥于某一种编程语言，只需确保对外提供统一的API接口方式即可。甚至可将查询与修改操作相分离，查询操作可以用一种更加轻量级的编程语言来实现，而修改操作会涉及事务，一般需要借助开发框架的事务特性来保证。

我们坚信，微服务必将坚持走轻量级技术路线。

究竟什么是轻量级？

我们认为，轻量级必须包含三个特征：易用、快速、稳定。

我们希望微服务架构中所涉及的技术都能够快速上手，运行时不占用过多的系统资源且性能突出，而且能够长期稳定地运行。

从微服务部署角度来看，我们认为微服务的部署过程将变得更加自动化。

部署微服务不再通过手工的方式去完成，因为这样既低效又容易出错，我们更加倾向于使用软件工具将其自动完成。要实现自动化部署这个目标，我们往往无法一步到位，最合理的方式是“先让它跑起来，再让它跑得快”。也就是说，早期的自动化部署方案也许不够完备，或多或少会存在一些人工参与的情况，其实这些都再正常不过了，但我们需要不断优化，努力通过自动化技术来取代重复性的人工操作。自动化虽好，但不要为了自动化而去自动化，或许有些环节通过手工处理才是最有效的方式。

总结

以 上就是我对Java开发大型互联网微服务架构服务发现之微服务架构演进过程实践 问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：简书（666 必过）欢迎大家的加入哟！