服务化架构中,服务注册和发现是重要的组件,微服务框架中有注册发现,比如Eureka, consul等,容器云也提供服务注册和发现,ServiceMesh、传统API Gateway产品也有注册发现,它们各适合什么场景? 如何选型?
服务注册是指服务提供者将自身信息上报至平台,服务发现是服务消费者到平台查找自己需要的服务。
1.微服务框架中,服务是由自身启动,并将信息注册到注册中心,如果不加服务注册信息,那么平台将不知道也不能控制该服务。而且微服务框架下,平台是被动的,不能实现服务资源的主动调度。
2.容器云,现在一般都是使用kubernetes做为容器的调度,服务的启动都是以pod的形式,以service向外提供服务,从平台的角度来说无需服务注册与发现。kubernetes具有强大的服务资源调度能力,所以服务的启停平台占据主动权。与微服务框架相比,服务原生的负载均衡、访问控制将被废除,而由kubernetes提供,但功能较弱。
3.ServiceMesh可以说是微服务框架的一个升级版,让服务只专注于服务自身的功能,将其内部的服务注册、负载均衡、网络等功能,全部拆出来,以依赖服务的形式存在。其实这里的服务注册与发现,与微服务框架的理念没有太大差别。
4.传统API Gateway,在微服务框架中也是经常使用的组件,主要是用来控制服务访问的,不管是内部服务间,还是向外部提供业务,主要是用来做安全控制的,当然其他功能还有很多。
这个问题有点复杂,需要分几个层次
第一是微服务层,微服务有独立的注册发现中心,独立部署,实现自治。可以和容器等没有关系。
第二是容器层,容器平台本身提供注册发现能力,比如Kubernetes, 镜像部署到容器平台之后,生成的服务会在容器平台实现自动注册,通过service访问。可以发布为clusterip, nodeport, loadbalancer, externalname等。
第三是ServiceMesh, Servicemesh提供了服务注册发现的接口,没有实现,通过adapter方式实现和kubernetes等的集成。
第四是API层,这通常是开放接口层,提供了一层稳定的可重用层,微服务或者其他内部服务,不管是否部署在容器上,都可以通过API的方式暴露服务接口,可以对内也可以对外,这层安全性要求比较高,可以使用API Gateway, API管理等工具来实现。
收起个人理解,微服务框架,比如spring cloud,dubbo,应用自己的注册和发现,更贴近于应用,他有自己的一套编程框架。而 容器云、service mesh 更贴近于基础设施,容器的承载体。
收起这是一个很大的话题,很难通过几句话讲清楚
还是应该从业务需求的角度出发,从应用架构的角度出发,看看业务应用是否适合采用微服务的技术架构
容器云和SeviceMesh都是支撑微服务的落地的;
传统的API GATEWAY,和微服务的技术架构放在一起讨论的意义不大。