微服务下服务注册发现层次及适用场景分析 | 趋势解读

【摘要】在实际业务场景中,服务部署有不同的需求,服务的注册发现机制的实现也有不同的方式。本文尝试探讨不同层次的服务注册发现的适用场景和优缺点,理解不同方案的适用性,指导如何在实际业务中根据场景选择适合的服务部署方案。
【作者】汪照辉 王作敬中国银河证券股份有限公司 信息技术部IT研发中心
前言
在传统服务化开发、容器云平台实施和微服务开发过程中,都会遇到服务注册和发现的问题。服务注册发现组件和实现方式及实现的层次也各不相同,比如传统ESB可以使用UDDI实现注册发现;容器云平台本身实现了注册发现机制;微服务注册发现组件则很多,比如Eureka、Consul、Zookeeper等;SpringCloud、Dubbo等都有自己的实现或支持的注册发现组件;ServiceMesh服务网格也有流量代理、注册发现机制;而传统API Gateway API管理工具也有注册发现机制;怎么看待这些不同的注册发现机制和组件,特别是目前微服务部署在容器云平台,该怎么选择部署注册发现中心组件,微服务选择在哪个层次注册,分别适用于什么样的场景,这是我们今天讨论的内容。
一、 服务注册发现机制不同服务之间在需要相互调用的时候,需要知道对方的调用地址。当然我们可以直接告诉对方我的服务的地址,但不同团队开发众多的服务的情况下,是需要维护一个服务列表的,而服务总是在持续改进中,版本可能不断变化,要维护不断变化的整个服务列表,这样的效率明显比较低。特别是微服务的快速应用,需要有个第三方工具来自动化协助维护这个服务列表,这就是服务注册发现中心组件的价值。
开发的服务要让其他人知道,需要首先把这个服务注册到服务注册中心,这就需要遵循服务注册的协议和规范,像Eureka、Consul等都提供了服务自动注册机制,在服务代码中加入服务注册注解语句就可以自动实现注册。注册的服务可以通过注册中心进行查询,查看所有注册的服务,服务消费者就可以选择需要的服务进行调用。
在理解服务注册发现机制之后,我们将微服务部署于容器云时,需要考虑服务注册发现组件该如何选择如何部署?
二、 服务注册发现实现层次在容器云上部署微服务,服务的注册发现可以直接使用容器云平台自身提供的注册发现机制,或者使用服务网格机制的流量代理,或者使用独立部署于容器平台或容器云平台的注册发现中心组件,不同的方式有不同的优缺点,通常要根据实际的需要和场景选择合适的方式。
(一) 容器平台的注册发现机制容器平台调度管理框架本身提供注册发现能力,比如Kubernetes。镜像部署到容器平台之后,生成的服务会在容器平台实现自动注册,通过service访问。可以发布为Clusterip, Nodeport, Loadbalancer, External name等服务类型。通常对外服务使用Nodeport或者实现Ingress 负载均衡器方式。OpenShift基于Kubernetes之上封装了Route组件。
1.优点容器云平台注册发现机制的优点是在开发服务时不用考虑引用服务注册发现组件的包,只考虑实现自己的业务逻辑代码;或者一些根本无法修改的应用或组件可以直接部署到容器平台提供服务,比如Tomcat。这样使服务的开发和部署相对简单。
另外在多集群的情况下,服务的注册发现也不受影响,无论多集群采用主备模式或是双活模式,在一个集群出现不可用,另外一个集群的服务注册机制不受影响。
2.缺点由于容器的注册发现是内置的,和容器平台紧耦合,容器的注册发现机制和SpringCloud等的注册发现机制不一样,因此服务的可移植性会受平台限制。不过用SpringCloud等开发的微服务可以同时支持Spring微服务注册和容器平台层注册,充分利用容器和微服务层实现机制的便利性。
另外容器中注册的地址是容器地址,外部难以访问,需要通过容器平台发布为NodePort、LoadBalancer等类型的服务才能为外部访问。
(二) 独立的注册发现中心首先不管用不用容器云平台,在微服务框架中会有服务注册发现组件,比如SpringCloud中的Eureka,或者使用Consul等实现微服务的注册和查找。这些组件可以部署为独立的注册发现中心,和服务、平台是分开的。
这种独立的注册中心部署方式适合多种场景,比如以前的ESB服务,或者当前部署的微服务,或者部署在容器云平台的微服务,甚至不是微服务只要遵循注册发现机制都可以注册到独立的注册中心。注册中心组件也很多,Eureka,Consul、etcd、Zookeeper等。Eureka2.0虽然停止更新,但1.x是Netflix服务发现系统的核心部分,所以仍然是活动的项目。Consul支持多数据中心多集群部署,功能强大,也支持了和SpringCloud的集成。当选择独立的微服务注册中心时,Consul是个比较好的选项。
1.优点可以构建一个服务注册中心集群,所有的服务都可以注册到这里,不受平台限制,独立提供服务注册发现能力。另外注册发现中心通常是稳定的组件,不需要经常重启或者切换,因此比注册到容器更能提供持续稳定的服务。
2.缺点独立维护一个服务注册中心或者一个服务注册中心集群。在多集群或者多数据中心架构下,可能需要部署维护多个服务注册中心集群,以实现容灾和备份。运维工作量相对较大。
(三) ServiceMesh代理注册发现ServiceMesh提供了服务注册发现的接口,没有实现,通过adapter方式实现和Kubernetes等的集成。目前ServiceMesh实现如Istio等在性能方面还不是很完善,可能还有一段路走。
(四) API管理实现服务注册发现API管理通常包含API网关、API管理和API Portal等组件。我们之所以把API管理列出来是因为这是采用微服务和容器平台相关很重要的一个组件。它独立于容器平台,是面向内外部提供标准API的关键组件。对外提供OpenAPI,对内实现稳定的可重用的接口层,服务或微服务通过API管理注册为标准API。
SpringCloud等有Zuul,Geteway组件,但从企业级架构上来说不足以支撑服务网关的需求,比如多开发语言支持。不同框架、不同开发语言的微服务需要通过统一的网关注册提供API服务。
1.优点API管理层主要为了提供标准化的API,微服务或者其他内部服务,不管是否部署在容器上,都可以通过API管理组件暴露标准API接口,实现自助服务、访问控制、流量控制及计量计费等。
适合企业级生态化建设架构。
2.缺点API管理实现服务注册发现在原有架构下又增加一层,增加了组件和运维工作量,不适合小型项目和小的公司。
三、 层次划分和适用场景现在很多人都把容器、微服务、ServiceMesh等混在一起讨论,甚至很多人混淆概念说ServiceMesh是第二代微服务,不知道是为了宣传故意为之还是不懂装懂。这其实是我们一直不赞成的。在我们使用某种技术的时候首先必须弄明白其概念、来源和适用场景。不能眉毛胡子一把抓,不分青红皂白,拿来就用,一定要考虑清楚了,选择合适的工具,才能事半功倍。
由于应用场景多种多样,可能不是某一种方案就能完美解决所有问题的。另外也面临着持续扩展、跨集群、跨数据中心等需求。本地方案、同城方案、异地方案甚至跨国或洲际方案有不同的要求,采用不同的技术等也会使实现方案有差别,因此适合别人的不见得就适合自己,需要理论联系实际,设计出适合自己的最佳方案。
(一) 层次划分以容器平台(包括ServiceMesh)、微服务、API管理统一来考虑,注册发现基本可以划分为三个层次:容器层、独立微服务注册发现和企业级API管理层。
如果所有服务都部署于容器平台,容器层的注册发现机制是最合适的;从稳定性等角度考虑,非容器化部署目前可能是一个更好的选择;从生态系统建设角度来说,API管理是必须的。
(二) 注册发现组件适用场景1.互联网类应用快速迭代、无状态场景这种场景非常适合将服务部署于容器平台,可以利用容器平台的优点,弹性、无状态、快速启停、自动恢复等特性,直接利用容器平台服务的注册机制,没必要再部署额外的注册发现中心。
2.高稳定性应用,无频繁改动需求对于有高稳定性需求的应用,不太适合部署于容器平台,那么注册中心其实也不适合部署在容器平台,非容器化部署可能更合适些。注册中心提供持续稳定的注册发现服务。
3.跨集群注册发现方案选择多容器集群环境下,需要选择主备或者双活/多活模式,是采用全容器注册或是部署独立的注册发现中心,或者单一注册发现中心或每个集群都附属自己的注册发现中心,或者分层注册机制等。通常支持复杂的高可用部署和业务需求。
4.API Gateway层API注册机制API网关层提供API的注册,通过APIPortal提供API集市,通常适合有OpenAPI需求的场景,安全性方面要求相对比较高。当然对内也可以通过API管理工具提供API服务,特别是集团性公司的IT、数据生态体系建设。
在讨论Gateway时,很多人会把API Gateway和微服务的Gateway混为一谈。API Gateway和微服务的Gateway其实是不一样的。API Gateway提供了API的管理和注册功能,其不限于微服务;微服务Gateway实现服务访问的访问控制等机制,微服务网关用在微服务架构内部。
(三) 独立注册发现组件部署注册发现组件的部署可以容器化部署也可以非容器化部署。为了获得敏捷的环境准备,在测试环境建议可以考虑容器化部署。生产环境建议非容器化部署以获得稳定的服务能力。
1.测试环境容器化部署开发测试环境通常面临着快速变动、敏捷环境准备需求,为了测试不同的版本支持,可能需要几分钟构建一个全新的版本环境,测试完毕后可以迅速回收,用于其他版本或应用的测试。类似这样的需求容器化部署就非常简单,互不影响。在容器云平台可以提供服务注册发现中心镜像,不同租户都可以敏捷的构建自己的开发测试注册中心。
2.生产环境非容器化部署基于我们的实践和体会,对于特别是传统的企业,在生产环境追求的是稳定和安全。所以基础组件的部署建议部署于稳定的物理机或虚拟机上。容器的弹性和敏捷对于追求稳定性的企业来说反而是劣势。因此生产环境应该有别于测试环境,或者UAT环境保持和生产环境一致,区别于开发测试环境。
生产环境跨集群或跨数据中心等场景,通常需要考虑容灾和备份,因此注册和发现中心组件也需要考虑容灾和备份机制。
原题:微服务下服务注册发现层次及场景探讨如有任何问题,可点击文末阅读原文到社区原文下评论交流
资料/文章推荐:
微服务框架,容器云,ServiceMesh、传统API Gateway产品都提供注册发现,它们各适合什么场景?如何选型?
http://www.talkwithtrend.com/Question/424481
PaaS中如何实现服务注册和服务发现?如何选型?
http://www.talkwithtrend.com/Question/418313
欢迎关注社区“微服务”技术主题,将会不断更新优质资料、文章。地址:
微服务:http://www.talkwithtrend.com/Topic/95163
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点,不代表社区立场

赞 (0)

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址