江西正东建设工程有限公司网站,电商网站设计页面设计,关键词查询网,一个网站需要哪些技术转载自 我为啥不看好ServiceMesh
前言
今年#xff0c;ServiceMesh(服务网格)概念在社区里头非常火#xff0c;有人提出2018年是ServiceMesh年#xff0c;还有人提出ServiceMesh是下一代的微服务架构基础。作为架构师#xff0c;如果你现在还不了解ServiceMesh的话…转载自 我为啥不看好ServiceMesh
前言
今年ServiceMesh(服务网格)概念在社区里头非常火有人提出2018年是ServiceMesh年还有人提出ServiceMesh是下一代的微服务架构基础。作为架构师如果你现在还不了解ServiceMesh的话是否感觉有点落伍了
那么到底什么是ServiceMesh它诞生的背景是什么它解决什么问题企业是否适合引入ServiceMesh根据近年在一线互联网企业的实践和思考从个人视角出发我为大家一一解答这些问题。
微服务架构的核心技术问题
在业务规模化和研发效能提升等因素的驱动下从单块应用向微服务架构的转型(如下图所示)已经成为很多企业(尤其是互联网企业)数字化转型的趋势。 在微服务模式下企业内部服务少则几个到几十个多则上百个每个服务一般都以集群方式部署这时自然产生两个问题(如下图所示) 一、服务发现服务的消费方(Consumer)如何发现服务的提供方(Provider)
二、负载均衡服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例
作为架构师如果你理解了这两个问题可以说就理解了微服务架构在技术上的最核心问题。
三种服务发现模式
服务发现和负载均衡并不是新问题业界其实已经探索和总结出一些常用的模式这些模式的核心其实是代理(Proxy如下图所以)以及代理在架构中所处的位置 在服务消费方和服务提供方之间增加一层代理由代理负责服务发现和负载均衡功能消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同当前业界主要有三种不同的服务发现模式
模式一传统集中式代理 这是最简单和传统做法在服务消费者和生产者之间代理作为独立一层集中部署由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)或者软件负载均衡器(如Nginx)F5(4层负载)Nginx(7层负载)这种软硬结合两层代理也是业内常见做法兼顾配置的灵活性(Nginx比F5易于配置)。
这种方式通常在DNS域名服务器的配合下实现服务发现服务注册(建立服务域名和IP地址之间的映射关系)一般由运维人员在代理上手工配置服务消费方仅依赖服务域名这个域名指向代理由代理解析目标地址并做负载均衡和调用。
国外知名电商网站eBay虽然体量巨大但其内部的服务发现机制仍然是基于这种传统的集中代理模式国内公司如携程也是采用这种模式。
模式二客户端嵌入式代理 这是很多互联网公司比较流行的一种做法代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合服务启动时自动注册到注册中心并定期报心跳客户端代理则发现服务并做负载均衡。
Netflix开源的Eureka(注册中心)[附录1]和Ribbon(客户端代理)[附录2]是这种模式的典型案例国内阿里开源的Dubbo也是采用这种模式。
模式三主机独立进程代理
这种做法是上面两种模式的一个折中代理既不是独立集中部署也不嵌入在客户应用程序中而是作为独立进程部署在每一个主机上一个主机上的多个消费者应用可以共用这个代理实现服务发现和负载均衡如下图所示。这个模式一般也需要独立的服务注册中心组件配合作用同模式二。 Airbnb的SmartStack[附录3]是这种模式早期实践产品国内公司唯品会对这种模式也有探索和实践。
三种服务发现模式的比较
上面介绍的三种服务发现模式各有优劣没有绝对的好坏可以认为是三种不同的架构风格在不同的公司都有成功实践。下表总结三种服务发现模式的优劣比较业界案例和适用场景建议供架构师选型参考 服务网格ServiceMesh
所谓的ServiceMesh其实本质上就是上面提到的模式三~主机独立进程模式这个模式其实并不新鲜业界(国外的Airbnb和国内的唯品会等)早有实践那么为什么现在这个概念又流行起来了呢我认为主要原因如下 上述模式一和二有一些固有缺陷模式一相对比较重有单点问题和性能问题模式二则有客户端复杂支持多语言困难无法集中治理的问题。模式三是模式一和二的折中弥补了两者的不足它是纯分布式的没有单点问题性能也OK应用语言栈无关可以集中治理。 微服务化、多语言和容器化发展的趋势企业迫切需要一种轻量级的服务发现机制ServiceMesh正是迎合这种趋势诞生当然这还和一些大厂(如Google/IBM等)的背后推动有关。
模式三(ServiceMesh)也被形象称为边车(Sidecar)模式如下图早期有一些摩托车除了主驾驶位还带一个边车位可以额外坐一个人。在模式三中业务代码进程(相当于主驾驶)共享一个代理(相当于边车)代理除了负责服务发现和负载均衡还负责动态路由、容错限流、监控度量和安全日志等功能这些功能是具体业务无关的属于跨横切面关注点(Cross-Cutting Concerns)范畴。 在新一代的ServiceMesh架构中(下图上方)服务的消费方和提供方主机(或者容器)两边都会部署代理SideCar。ServiceMesh比较正式的术语也叫数据面板(DataPlane)与数据面板对应的还有一个独立部署的控制面板(ControlPlane)用来集中配置和管理数据面板也可以对接各种服务发现机制(如K8S服务发现)。术语数据面板和控制面板估计是偏网络SDN背景的人提出来的。 上图左下角每个主机上同时居住了业务逻辑代码(绿色表示)和代理(蓝色表示)服务之间通过代理发现和调用目标服务形成服务之间的一种网络状依赖关系控制面板则可以配置这种依赖调用关系也可以调拨路由流量。如果我们把主机和业务逻辑剥离就出现一种网格状架构(上图右下角)服务网格由此得名。 Istio[附录4]是Google/IBM等大厂支持和推进的一个ServiceMesh标准化工作组上图是Istio给出的ServiceMesh参考架构。Istio专注在控制面板的架构、功能、以及控制面板和数据面板之间API的标准化它的控制面板功能主要包括 Istio-Manager负责服务发现路由分流熔断限流等配置数据的管理和下发 Mixer负责收集代理上采集的度量数据进行集中监控 Istio-Auth负责安全控制数据的管理和下发
Envoy[附录5]是目前Istio主力支持的数据面板代理其它主流代理如nginx/kong等也正在陆续加入这个阵营。kubernetes是目前Isito主力支持的容器云环境。
我的建议
目前我本人并不特别看好ServiceMesh也不是特别建议企业在生产上试水ServiceMesh主要原因如下 ServiceMesh其实并不是什么新东西本质就是上面提到的服务发现模式三~主机独立进程模式这个模式很早就有公司在探索和实践但是一直没有普遍流行起来说明这个模式也是存在落地挑战的。从表面上看模式三是模式一和模式二的折中同时解决了模式一和模式二存在的问题但是在每个主机上独立部署一个代理进程是有很大运维管理开销的一方面是规模化部署的问题(考虑服务很多机器也很多的场景)另一方面是如何监控治理的问题代理挂了怎么办你的团队是否具备自动化运维和监控的能力另外开发人员在服务调试的时候会依赖于这个独立的代理调试排错比较麻烦这个问题怎么解决 Istio的确做了一些标准化工作但是没有什么特别的创新可是说换汤不换药就是把模式三规范化和包装了一下。透过现象看本质Google/IBM等行业大厂在背后推Isito/ServiceMesh背后有一些市场利益诉求考虑例如Google要推进它的kubernates和公有云生态。 ServiceMesh在年初声音比较大最近渐渐安静下来我听到国内只有一些大厂(华为新浪微博蚂蚁金服等)在试水实际生产级落地的案例聊聊无几。大多数企业对ServiceMesh只是观望很多架构师对ServiceMesh实际落地都存在疑虑。
所以我的个人建议对于大部分企业(一般运维和研发能力不是特别强)采用模式一~集中代理模式就足够了。这个模式比较传统不新鲜但是在很多一线企业已经切实落地我甚至认为除了一些大厂大部分中小企业的服务发现架构采用的就是集中代理。我本人经历过三家互联网公司大的有eBay中等有携程小的有拍拍贷都是采用集中式代理模式而且玩得都很好。我的架构理念很简单对于生产级应用不追新老实采用大部分企业落地过的方案。
模式一的最大好处是集中治理应用不侵入语言栈无关另外因为模式一是集中部署的不像模式三是分布式部署所以模式一的运维开销也远小于模式三。对于模式一大家最大的顾虑是性能和单点问题其实性能还是OK的如果架构和容量规划合理的话实际生产中经过集中代理的性能开销一般可以控制在小于10个mseBay和携程等大流量企业的成功实践已经验证了这点。单点问题一般建议采用两层负载结构例如硬件F5软件nginx两层负载F5以主从HA部署nginx则以集群多实例部署这种架构兼顾了高可用和配置的灵活性。
另外模式一还可以和服务注册中心结合从而降低手工配置的复杂性实现DevOps研发自助部署一种方案如下图所示 服务启动时自动注册到服务注册中心并定期报心跳Proxy则定期到服务注册中心同步实例。这种方式下不需要为每个服务申请一个域名只需一个泛域名即可消费者访问服务时采用服务名泛域名即可整个服务上线流程可以做到DevOps研发自助。目前社区流行的一些开源代理如traefik[附录7]和kong[附录8]等都支持和多种服务注册中心(Consul/Eureka/Etcd/Zookeeper等)进行集成。目前这种方案在拍拍贷有初步成功实践采用kong[附录7]和自研服务注册中心Radar[附录8]同时和容器云调度平台配合实现了研发全自助式发布上线。
结论
1. 服务注册发现和负载均衡是微服务架构在技术上的根本问题解决的办法是采用代理Proxy。根据代理在架构上的位置不同服务发现代理一般有三种模式 模式一集中式代理 模式二客户端嵌入式代理 模式三主机独立进程代理 这三种模式没有绝对的好还之分只是三种不同的架构风格各有优劣和适用场景在不同企业都有成功落地案例。
2. ServiceMesh本质上就是模式三~主机独立进程代理它结合了模式一和模式二的优势但是分布式部署运维管理开销大。Istio对ServiceMesh的架构、功能和API进行了标准化。
3. ServiceMesh还在演进中生产落地仍有挑战一般企业不建议生产级使用。集中式代理最成熟对于一般中小企业建议从集中式代理开始等达到一定规模和具备一定的研发运维能力再根据需要考虑其它服务发现模式。
4. 架构师不要盲目追新在理解微服务架构原理的基础上可以学习和试点新技术但是对于生产级应用应该以成熟稳定有大规模落地案例作为选型第一准则。 附录
1、Netflix Eureka
https://github.com/netflix/eureka
2、Netflix Ribbon
https://github.com/netflix/ribbon
3、Airbnb SmartStack
https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
4、Istio
https://istio.io/
5、Envoy
https://www.envoyproxy.io/
6、Traefik
https://github.com/containous/traefik
7、Kong
https://github.com/kong/kong
8、Radar
https://github.com/ppdai-incubator/radar
