在微服务架构或分布式环境下服务注册与发现技术不可或缺这也是程序员进阶之路必须要掌握的核心技术之一本文通过图解的方式带领大家轻轻松松掌握。引入服务注册与发现组件的原因先来看一个问题假如现在我们要做一个商城项目作为架构师的你应该怎样设计系统的架构你心里肯定在想这还不容易直接照搬淘宝的架构不就行了。但在现实的创业环境中一个项目可能是九死一生如果一开始投入巨大的人力和财力一旦项目失败损失就很大。作为一位有经验的架构师需要结合公司财力、人力投入预算等现状选择最适合眼下的架构才是王道。大型网站都是从小型网站发展而来架构也是一样。任何一个大型网站的架构都不是从一开始就一层不变的而是随着用户量和数据量的不断增加不断迭代演进的结果。在架构不断迭代演进的过程中我们会遇到很多问题技术发展的本质就是不断发现问题再解决问题解决问题又发现问题。单体架构在系统建立之初可能不会有特别多的用户将所有的业务打成一个应用包放在tomcat容器中运行与数据库共用一台服务器这种架构一般称之为单体架构。在初期这种架构的效率非常高根据用户的反馈可以快速迭代上线。但是随着用户量增加一台服务的内存和CPU吃紧很容易造成瓶颈新的问题来了怎么解决呢应用与数据分离随着用户请求量增加一台服务器的内存和CPU持续飙升用户请求响应时间变慢。这时候可以考虑将应用与数据库拆开各自使用一台服务器你看问题又解决了吧。突然有一天扫地阿姨不小心碰了电线其中一台服务器掉电了用户所有的请求都报错随之而来的是一系列投诉电话。集群部署单实例很容易造成单点问题比如遇到服务器故障或者服务能力瓶颈那怎么办聪明的你肯定想到了用集群呀。集群部署是指将应用部署在多个服务器或者虚机上用户通过服务均衡随机访问其中的一个实例从而使多个实例的流量均衡如果一个实例出现故障可以将其下线其他实例不受影响仍然可以对外提供服务。随着用户数量快速增加老板决定增加投入扩大团队规模。开发团队壮大后效率并没有得到显著的提高以前小团队可以一周迭代上线一次现在至少需要两到三周时间。业务逻辑越来越复杂代码间耦合很严重修改一行代码可能引入几个线上问题。架构师意识到需要进行架构重构。微服务架构当单体架构演进到一定阶段后开发测试的复杂性都会成本增加团队规模的扩大也会使得各自工作耦合性更严重牵一发而动全身就是这种场景。单体架构遇到瓶颈了微服务架构就横空出世了。微服务就是将之前的单体服务按照业务维度进行拆分拆分粒度可大可小拆分时机可以分节奏进行。最佳实践是先将一些独立的功能从单体中剥离出来抽成一个或多个微服务这样可以保障业务的连续性和稳定性。如上图将一个商用应用拆分为六个独立微服务。六个微服务可以使用Docker容器化进行多实例部署。架构演化到这里遇到了一个难题如果要查询用户所有的订单用户服务可能会依赖订单服务用户服务如何与订单服务交互呢订单服务有多个实例该访问哪一个通常有几种解决办法1服务地址硬编码服务的地址写死在数据库或者配置文件通过访问DNS域名进行寻址路由。服务B的地址硬编码在数据库或者配置文件中服务A首先需要拿到服务B的地址然后通过DNS服务器解析获取其中一实例的真实地址最后可以向服务B发起请求。如果遇到大促活动需要对服务实例扩容大促完需要对服务实例进行下线运维人员要做大量的手工操作非常容易误操作。2服务动态注册与发现服务地址硬编码还有一个非常致命的问题如果一台实例挂了运维人员可能不能及时感知到导致一部分用户的请求会异常。引入服务注册与发现组件可以很好解决上面遇到的问题避免过多的人工操作。架构演进总结在单体架构中一个应用程序就是一个服务包包内的模块通过函数方法相互调用模型足够简单根本没有服务注册和发现一说。在微服务架构中会将一个应用程序拆分为多个微服务微服务会部署在不同的服务器、不同的容器、甚至多数据中心微服务间要相互调用服务注册和发现成为了一个不可或缺的组件。服务注册与发现基本原理服务注册与发现是分为注册和发现两个关键的步骤。服务注册服务进程在注册中心注册自己的元数据信息。通常包括主机和端口号有时还有身份验证信息协议版本号以及运行环境的信息。服务发现客户端服务进程向注册中心发起查询来获取服务的信息。服务发现的一个重要作用就是提供给客户端一个可用的服务列表。服务注册服务注册有两种形式客户端注册和代理注册。客户端注册客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册当服务下线时注销自己。这种方式的缺点是注册注销逻辑与服务的业务逻辑耦合在一起如果服务使用不同语言开发那需要适配多套服务注册逻辑。代理注册代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务然后代理服务负责向注册中心发起注册工作。这种方式的缺点是多引用了一个代理服务并且代理服务要保持高可用状态。服务发现服务发现也分为客户端发现和代理发现。客户端发现客户端发现是指客户端负责向注册中心查询可用服务地址获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。这种方式非常直接客户端可以控制负载均衡算法。但是缺点也很明显获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起如果服务发现或者负载平衡有变化那么所有的服务都要修改重新上线。代理发现代理发现是指新增一个路由服务负责服务发现获取可用的实例列表服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可如果发现实例不可用路由服务还可以自行重试服务消费者完全不用感知。心跳机制如果服务有多个实例其中一个实例出现宕机注册中心是可以实时感知到并且将该实例信息从列表中移出也称为摘机。如何实现摘机业界比较常用的方式是通过心跳检测的方式实现心跳检测有主动和被动两种方式。被动检测是指服务主动向注册中心发送心跳消息时间间隔可自定义比如配置5秒发送一次注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息就会将该实例从列表中移除。上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息15秒之后注册就会将实例2移除掉。主动检测是注册中心主动发起每隔几秒中会给所有列表中的服务实例发送心跳检测消息如果多个周期内未发送成功或未收到回复就会主动移除该实例。