当前位置: 新豪天地登录网址 > www.3559.com > 正文

阿里巴巴中间件团队在,由浅入深带你走进微服

时间:2019-08-25 09:08来源:www.3559.com
原标题:阿里巴巴中间件团队在 Service Mesh 的实践和探索 什么是微服务 首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是

原标题:阿里巴巴中间件团队在 Service Mesh 的实践和探索

什么是微服务

首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务。

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下:

www.3559.com 1

尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR,部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

当然它的缺点也十分明显,特别对于互联网公司来说:

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用,而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能,比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

比如,前面描述的系统可被分解为:

www.3559.com 2

每个业务逻辑都被分解为一个微服务,微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下,这些客户端并不能直接访问后台微服务,而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

www.3559.com 3

摘要: 所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。

微服务架构的优点

微服务架构有很多重要的优点。首先,它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变,但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平,而这通过单体代码库很难实现。因此,微服务开发的速度要快很多,更容易理解和维护。

其次,这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约,开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务,由于服务相对较小,所以这并不会对整体应用造成太大影响。

第三,微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI/CD成为可能。

最后,微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务,在EC2内存优化实例上部署内存数据库服务。

Markdown

精彩观点导读:

微服务架构的缺点和挑战

实际上并不存在silver bullets,微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似,微服务强调了服务大小,但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务,这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单,因为单体应用往往只存在一个数据库。但在微服务架构下,不同服务可能拥有不同的数据库。CAP原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可,而对微服务进行测试,需要启动它依赖的所有其他服务。这种复杂性不可低估。

微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中,若有A、B、C三个服务需要更改,A依赖B,B依赖C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C,然后更新B,最后更新A。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上,然后前端使用负载均衡即可。每个应用都有相同的基础服务地址,例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外,我们还需要服务发现机制,以便服务可以发现与其通信的其他服务的地址。因此,成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大体概括为:

  • API Gateway
  • 服务间调用
  • 服务发现
  • 服务容错
  • 服务部署
  • 数据调用

www.3559.com 4

幸运的是,出现了很多微服务框架,可以解决以上问题。

▲扫码报名活动

» 我们去探索一项技术,并不会仅仅因为其先进性,而是因为我们目前遇到了一些无法解决的问题,而这项技术正好能解决这个问题。

第一代微服务框架

Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具(包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等)。 主要项目包括:

  • Spring Cloud Config:由Git存储库支持的集中式外部配置管理。配置资源直接映射到Spring Environment,但是如果需要可以被非Spring应用程序使用。
  • Spring Cloud Netflix:与各种Netflix OSS组件(Eureka,Hystrix,Zuul,Archaius等)集成。
  • Spring Cloud Bus:用于将服务和服务实例与分布式消息传递联系起来的事件总线。用于在集群中传播状态更改。
  • Spring Cloud for Cloudfoundry:将您的应用程序与Pivotal Cloudfoundry集成。提供服务发现实现,还可以轻松实现通过SSO和OAuth 2保护资源,还可以创建Cloudfoundry服务代理。
  • Spring Cloud - Cloud Foundry Service Broker:提供构建管理一个Cloud Foundry中服务的服务代理的起点。
  • Spring Cloud Cluster:领导选举和通用状态模型(基于ZooKeeper,Redis,Hazelcast,Consul的抽象和实现)。
  • Spring Cloud Consul:结合Hashicorp Consul的服务发现和配置管理
  • Spring Cloud Security:在Zuul代理中为负载平衡的OAuth 2休眠客户端和认证头中继提供支持。
  • Spring Cloud Sleuth:适用于Spring Cloud应用程序的分布式跟踪,与Zipkin,HTrace和基于日志跟踪兼容。
  • Spring Cloud Data Flow:针对现代运行时的可组合微服务应用程序的云本地编排服务。易于使用的DSL,拖放式GUI和REST-API一起简化了基于微服务的数据管道的整体编排。
  • Spring Cloud Stream:轻量级事件驱动的微服务框架,可快速构建可连接到外部系统的应用程序。使用Apache Kafka或RabbitMQ在Spring Boot应用程序之间发送和接收消息的简单声明式模型。
  • Spring Cloud Stream Application Starters:Spring Cloud任务应用程序启动器是Spring Boot应用程序,可能是任何进程,包括不会永远运行的Spring Batch作业,并且它们在有限时间的数据处理之后结束/停止。
  • Spring Cloud ZooKeeper:ZooKeeper的服务发现和配置管理。
  • Spring Cloud for Amazon Web Services:轻松集成托管的Amazon的Web Services服务。它通过使用Spring的idioms和APIs便捷集成AWS服务,例如缓存或消息API。开发人员可以围绕托管服务,不必关心基础架构来构建应用。
  • Spring Cloud Connectors:使PaaS应用程序在各种平台上轻松连接到后端服务,如数据库和消息代理(以前称为“Spring Cloud”的项目)。
  • Spring Cloud Starters:作为基于Spring Boot的启动项目,降低依赖管理(在Angel.SR2后,不在作为独立项目)。
  • Spring Cloud CLI:插件支持基于Groovy预言快速创建Spring Cloud的组件应用。

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。其核心部分包含:

  • 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
  • 集群容错:提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
  • 自动发现:基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

www.3559.com 5

但是显而易见,无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境,它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架,缺少DevOps的整体解决方案(这正是微服务架构需要关注的)。而随之而来的便是Service Mesh的兴起。

数人云11月Meetup报名开启,看中西方大神如何论道云原生与微服务!本文作者敖小剑老师将在本次Meetup上继续分享Service Mesh相关内容,欢迎报名~

» 所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。

下一代微服务:Service Mesh?

Service Mesh又译作“服务网格”,作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh,可以将它比作是应用程序或者说微服务间的TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如Spring Cloud、OSS,现在只要交给Service Mesh就可以了。

www.3559.com,Service Mesh有如下几个特点:

  • 应用程序间通讯的中间层
  • 轻量级网络代理
  • 应用程序无感知
  • 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh的架构如下图所示:

www.3559.com 6

Service Mesh作为Sidebar运行,对应用程序来说是透明,所有应用程序间的流量都会通过它,所以对应用程序流量的控制都可以在Service Mesh中实现。

目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio,而最近Buoyant(开源Linkerd的公司)又发布了基于Kubernetes的Service Mesh开源项目Conduit。

Linkerd是开源网络代理,设计为以服务网格部署:用于管理,控制和监控应用程序内的服务与服务间通讯的专用层。

Linkerd旨在解决Twitter、Yahoo、Google和Microsoft等公司运营大型生产系统时发现的问题。根据经验,最复杂,令人惊奇和紧急行为的来源通常不是服务本身,而是服务之间的通讯。Linkerd解决了这些问题,不仅仅是控制通讯机制,而是在其上提供一个抽象层。

www.3559.com 7

它的主要特性有:

  • 负载平衡:Linkerd提供了多种负载均衡算法,它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。
  • 熔断:Linkerd包含自动熔断,将停止将流量发送到被认为不健康的实例,从而使他们有机会恢复并避免连锁反应故障。
  • 服务发现:Linkerd 与各种服务发现后端集成,通过删除特定的服务发现实现来帮助您降低代码的复杂性。
  • 动态请求路由:Linkerd 启用动态请求路由和重新路由,允许您使用最少量的配置来设置分段服务(staging service),金丝雀,蓝绿部署(blue-green deploy),跨DC故障切换和黑暗流量(dark traffic)。
  • 重试次数和截止日期:Linkerd可以在某些故障时自动重试请求,并且可以在指定的时间段之后让请求超时。
  • TLS:Linkerd可以配置为使用TLS发送和接收请求,您可以使用它来加密跨主机边界的通信,而不用修改现有的应用程序代码。
  • HTTP代理集成:Linkerd可以作为HTTP代理,几乎所有现代HTTP客户端都广泛支持,使其易于集成到现有应用程序中。
  • 透明代理:您可以在主机上使用iptables规则,设置通过Linkerd的透明代理。
  • gRPC:Linkerd支持HTTP/2和TLS,允许它路由gRPC请求,支持高级RPC机制,如双向流,流程控制和结构化数据负载。
  • 分布式跟踪:Linkerd支持分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。
  • 仪器仪表:Linkerd支持分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。

Envoy是一个面向服务架构的L7代理和通信总线而设计的,这个项目诞生是出于以下目标:

对于应用程序而言,网络应该是透明的,当发生网络和应用程序故障时,能够很容易定位出问题的根源。

Envoy可提供以下特性:

  • 外置进程架构:可与任何语言开发的应用一起工作;可快速升级。
  • 基于新C 11编码:能够提供高效的性能。
  • L3/L4过滤器:核心是一个L3/L4网络代理,能够作为一个可编程过滤器实现不同TCP代理任务,插入到主服务当中。通过编写过滤器来支持各种任务,如原始TCP代理、HTTP代理、TLS客户端证书身份验证等。
  • HTTP L7过滤器:支持一个额外的HTTP L7过滤层。HTTP过滤器作为一个插件,插入到HTTP链接管理子系统中,从而执行不同的任务,如缓冲,速率限制,路由/转发,嗅探Amazon的DynamoDB等等。
  • 支持HTTP/2:在HTTP模式下,支持HTTP/1.1、HTTP/2,并且支持HTTP/1.1、HTTP/2双向代理。这意味着HTTP/1.1和HTTP/2,在客户机和目标服务器的任何组合都可以桥接。
  • HTTP L7路由:在HTTP模式下运行时,支持根据content type、runtime values等,基于path的路由和重定向。可用于服务的前端/边缘代理。
  • 支持gRPC:gRPC是一个来自谷歌的RPC框架,使用HTTP/2作为底层的多路传输。HTTP/2承载的gRPC请求和应答,都可以使用Envoy的路由和LB能力。
  • 支持MongoDB L7:支持获取统计和连接记录等信息。
  • 支持DynamoDB L7:支持获取统计和连接等信息。
  • 服务发现:支持多种服务发现方法,包括异步DNS解析和通过REST请求服务发现服务。
  • 健康检查:含有一个健康检查子系统,可以对上游服务集群进行主动的健康检查。也支持被动健康检查。
  • 高级LB:包括自动重试、断路器,全局限速,阻隔请求,异常检测。未来还计划支持请求速率控制。
  • 前端代理:可作为前端代理,包括TLS、HTTP/1.1、HTTP/2,以及HTTP L7路由。
  • 极好的可观察性:对所有子系统,提供了可靠的统计能力。目前支持statsd以及兼容的统计库。还可以通过管理端口查看统计信息,还支持 第三方的分布式跟踪机制。
  • 动态配置:提供分层的动态配置API,用户可以使用这些API构建复杂的集中管理部署。

Istio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络,具备负载均衡、服务间认证、监控等功能,而不需要改动任何服务代码。想要为服务增加对Istio的支持,您只需要在环境中部署一个特殊的边车,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。

Istio目前仅支持在Kubernetes上的服务部署,但未来版本中将支持其他环境。

Istio提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能:

  • 流量管理:控制服务之间的流量和API调用的流向,使得调用更可靠,并使网络在恶劣情况下更加健壮。
  • 可观察性:了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。
  • 策略执行:将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
  • 服务身份和安全:为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。

Istio服务网格逻辑上分为数据面板和控制面板:

  • 数据面板由一组智能代理组成,代理部署为边车,调解和控制微服务之间所有的网络通信。
  • 控制面板负责管理和配置代理来路由流量,以及在运行时执行策略。

下图显示了构成每个面板的不同组件:

www.3559.com 8

Conduit是为Kubernetes设计的一个超轻型服务网格服务,它可透明地管理在Kubernetes上运行的服务的运行时通信,使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能,而无需更改代码。

Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板,并对外提供北向接口。

Linkerd和Envoy比较相似,都是一种面向服务通信的网络代理,均可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通信问题,使得应用对服务通信无感知,这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar,多个类似Linkerd和Envoy的proxy互相连接,就组成了service mesh。

而Istio则是站在了一个更高的角度,它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的所有网络通信,而Control Plane负责管理Data Plane Proxy:

www.3559.com 9

并且Istio天生的支持Kubernetes,这也弥合了应用调度框架与Service Mesh之间的空隙。

关于Conduit的资料较少,从官方介绍看它的定位和功能与Istio类似。

数人云之前给大家分享过敖小剑老师的《万字解读:Service Mesh服务网格新生代--Istio》,详细地阐述了发展及理念,在Qcon2017上,敖小剑老师又做了关于Service Mesh的演讲,以下是本次演讲的实录。

» 微服务本质是对服务的拆分,微服务架构符合工程领域常用的“分而治之”范式。

Kubernetes Service Mesh = 完整的微服务框架

Kubernetes已经成为了容器调度编排的事实标准,而容器正好可以作为微服务的最小工作单元,从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计,它们的出现补足了Kubernetes在微服务间服务通讯上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架,但是它们或多或少都会和具体语言或应用场景绑定,并只解决了微服务Dev层面的问题。若想解决Ops问题,它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架做结合:

www.3559.com 10

但是这种结合又由于初始设计和生态,有很多适用性问题需要解决。

Kubernetes则不同,它本身就是一个和开发语言无关的、通用的容器管理平台,它可以支持运行云原生和传统的容器化应用。并且它覆盖了微服务的Dev和Ops阶段,结合Service Mesh,它可以为用户提供完整端到端的微服务体验。

所以我认为,未来的微服务架构和技术栈可能是如下形式:

www.3559.com 11

多云平台为微服务提供了资源能力(计算、存储和网络等),容器作为最小工作单元被Kubernetes调度和编排,Service Mesh管理微服务的服务通信,最后通过API Gateway向外暴露微服务的业务接口。

我相信未来随着以Kubernetes和Service Mesh为标准的微服务框架的盛行,将大大降低微服务实施的成本,最终为微服务落地以及大规模使用提供坚实的基础和保障。

敖小剑/数人云资深架构师

十五年软件开发经验,微服务专家,专注于基础架构,Cloud Native拥护者,敏捷实践者。曾在亚信,爱立信,唯品会和ppmoney任职。

www.3559.com 12

www.3559.com 13

近日,在Aliware Open Source•成都站-Apache Dubbo 开发者沙龙上,阿里巴巴中间件高级技术专家李云(至简)向开发者们分享了阿里巴巴中间件团队在Service Mmesh领域的探索和最新实践。本文是根据至简的现场分享所整理,为大家回顾分享中的精彩内容。

Markdown

嘉宾介绍:李云(至简),阿里巴巴中间件高级技术专家,是阿里巴巴集团Service Mesh方向的重要参与者和推动者。

简单回顾一下过去三年微服务的发展历程。在过去三年当中,微服务成为我们的业界技术热点,我们看到大量的互联网公司都在做微服务架构的落地。也有很多传统企业在做互联网技术转型,基本上还是以微服务和容器为核心。

我们去探索一项技术,并不会仅仅因为其先进性,而是因为我们目前遇到了一些无法解决的问题,而这项技术正好能解决这个问题。现在,阿里巴巴整个集团业务的体量很大,在技术上会遇到很多的挑战。而正是因为这些挑战,让我们思考通过哪些新技术可以去解决这些痛点,这也是我们在Service Mesh领域进行探索和实践的出发点。首先,我们先来看看自己遇到了哪些挑战。

在这个技术转型中,我们发现有一个大的趋势,伴随着微服务的大潮,Spring Cloud微服务开发框架非常普及。而今天讲的内容在Spring Cloud之外,我们发现最近新一代的微服务开发技术正在悄然兴起,就是今天要给大家带来的Service Mesh/服务网格。

一、微服务的5大挑战

我做一个小的调查,今天在座的各位,有没有之前了解过服务网格的,请举手。(备注:调查结果,现场数百人仅有3个人举手)

第一个挑战是微服务框架自身演进困难。

既然大家都不了解,那我给大家介绍,首先,什么是Service Mesh?然后给大家讲一下Service Mesh的演进历程,以及为什么选择Service Mesh。为什么我将它称之为下一代的微服务,这是我们今天的内容。

任何软件都会有他的生命进化曲线,从最初的萌芽,进入形成期,往上发展,再进入平台期,最后进入衰亡期。当然我们希望我们的软件可以在进入平台期后,能借助某次演进进入新的发展期。从这个维度看,所有软件最重要的使命不是满足功能要求,而是演进,从而持续成长。相反,当某个软件无法演进的时候,就会意味着死亡。但软件的演进并不是一个简单的事情,以微服务框架为例,为了进一步提升双11期间整个中间件平台的稳定性,我们会修改若干个功能,并以SDK的方式去提供给业务方,但业务代码和微服务框架SDK是强耦合的,这时候需要我们推动各个业务方和我们一同去做升级。虽然我们的初衷是实现平台稳定性的提升,帮助业务更好的发展,但这时由于大家的出发点和诉求有所不同,业务方和我们一起去做升级是比较困难的。所以要发展微服务框架,首先遇到的挑战就是演进困难。

什么是Service Mesh?

我们首先可以说一下Service Mesh,确实是一个非常非常新的名词,像刚才调查的,大部分的同学都没听过。

www.3559.com 14

Markdown

我们首先说一下Service Mesh这个词,这确实是一个非常非常新的名词,像刚才调查的,大部分的同学都没听过。
这个词最早使用由开发Linkerd的Buoyant公司提出,并在内部使用。2016年9月29日第一次公开使用这个术语。2017年的时候随着Linkerd的传入,Service Mesh进入国内技术社区的视野。最早翻译为“服务啮合层”,这个词比较拗口。用了几个月之后改成了服务网格。后面我会给大家介绍为什么叫网格。

www.3559.com 15

Markdown

先看一下Service Mesh的定义,这个定义是由Linkerd的CEO William给出来的。Linkerd是业界第一个Service Mesh,也是他们创造了Service Mesh这个词汇的,所以这个定义比较官方和权威。
我们看一下中文翻译,首先服务网格是一个基础设施层,功能在于处理服务间通信,职责是负责实现请求的可靠传递。在实践中,服务网格通常实现为轻量级网络代理,通常与应用程序部署在一起,但是对应用程序透明。

这个定义直接看文字大家可能会觉得比较空洞,不太容易理解到底是什么。我们来看点具体的东西。

www.3559.com 16

Markdown

Service Mesh的部署模型,先看单个的,对于一个简单请求,作为请求发起者的客户端应用实例,会首先用简单方式将请求发送到本地的Service Mesh实例。这是两个独立进程,他们之间是远程调用。
Service Mesh会完成完整的服务间调用流程,如服务发现负载均衡,最后将请求发送给目标服务。这表现为Sidecar。

www.3559.com 17

Markdown

Sidecar这个词中文翻译为边车,或者车斗,也有一个乡土气息浓重的翻译叫做边三轮。Sidecar这个东西出现的时间挺长的,它在原有的客户端和服务端之间加多了一个代理。

www.3559.com 18

Markdown

多个服务调用的情况,在这个图上我们可以看到Service Mesh在所有的服务的下面,这一层被称之为服务间通讯专用基础设施层。Service Mesh会接管整个网络,把所有的请求在服务之间做转发。在这种情况下,我们会看到上面的服务不再负责传递请求的具体逻辑,只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来,呈现出一个抽象层。

www.3559.com 19

Markdown

如果有大量的服务,就会表现出来网格。图中左边绿色方格是应用,右边蓝色的方框是Service Mesh,蓝色之间的线条是表示服务之间的调用关系。Sidecar之间的连接就会形成一个网络,这个就是服务网格名字的由来。这个时候代理体现出来的就和前面的sidecar不一样了,形成网状。

www.3559.com 20

Markdown

再来回顾前面给出的定义,大家回头看这四个关键词。首先第一个,服务网格是抽象的,实际上是抽象出了一个基础设施层,在应用之外。其次,功能是实现请求的可靠传递。部署上体现为轻量级的网络代理。最后一个关键词是,对应用程序透明。
大家注意看,上面的图中,网络在这种情况下,可能不是特别明显。但是如果把左边的应用程序去掉,现在只呈现出来Service Mesh和他们之间的调用,这个时候关系就会特别清晰,就是一个完整的网络。这是Service Mesh定义当中一个非常重要的关键点,和Sidecar不相同的地方:不再将代理视为单独的组件,而是强调由这些代理连接而形成的网络。在Service Mesh里面非常强调代理连接组成的网络,而不像sidecar那样看待个体。

现在我们基本上把Service Mesh的定义介绍清楚了,大家应该可以大概了解什么是Service Mesh了。

www.3559.com 21

Service Mesh的演进历程

第二个部分和大家追溯一下Service Mesh的演进历程。要注意,虽然Service Mesh这个词汇直到2016年9才有,但是它表述的东西很早以前就出现了。

www.3559.com 22

Markdown

首先看“远古时代”,第一代网络计算机系统,最早的时候开发人员需要在自己的代码里处理网络通讯的细节问题,比如说数据包顺序、流量控制等等,导致网络逻辑和业务逻辑混杂在一起,这样是不行的。接下来出现了TCP/IP技术,解决了流量控制问题,从右边的图上可以看到,功能其实没发生变化:所有的功能都在,代码还是要写。但是,最重要的事情,流程控制,已经从应用程序里面抽出来了。对比左右两边的图,抽出来之后被做成了操作系统网络层的一部分,这就是TCP/IP,这样的话应用的结构就简单了。
现在写应有,就不用考虑网卡到底怎么发。在TCP/IP之后,这是完全不需要考虑的。上面说的是非常遥远的事情,大概发生在五十年前。

www.3559.com 23

Markdown

微服务时代也面临着类似的一些东西,比如说我们在做微服务的时候要处理一系列的比较基础的事情,比如说常见的服务注册、服务发现,在得到服务器实例之后做负载均衡,为了保护服务器要熔断/重试等等。这些功能所有的微服务都跑不掉,那怎么办呢?只能写代码,把所有的功能写进来。我们发现最早的微服务又和刚才一样,应用程序里面又加上了大量的非功能性的代码。为了简化开发,我们开始使用类库,比如说典型的Netflix OSS套件。在把这些事情做好以后,开发人员的编码问题就解决了:只需要写少量代码,就可以把这些功能实现。因为这个原因,最近这些年大家看到Java社区Spring Cloud的普及程度非常快,几乎成为了微服务的代名词。
到了这个地步之后,完美了吗?当然,如果真的完美了,那我今天就不会站在这里了:)

www.3559.com 24

Markdown

我们看这几个被称之为痛点的东西:内容比较多,门槛比较高。调查一下,大家学Spring Cloud,到你能熟练掌握,并且在产品当中应用,可以解决出现的问题,需要多长时间?一个星期够不够?大部分人一个星期是不够的,大部分人需要三到六个月。因为你在真实落地时会遇到各种问题,要能自己解决的话,需要的时间是比较长的。这里是Spring Cloud的常见子项目,只列出了最常见的部分,其中Spring Cloud Netflix下还有Netflix OSS套件的很多内容。要真正吃透Spring Cloud,需要把这些东西全部吃透,否则遇到问题时还会非常难受。
这么多东西,在座的各位相对来说学习能力比较强一点,可能一个月就搞定了,但是问题是你的开发团队,尤其是业务开发团队需要多久,这是一个很要命的事情:业务团队往往有很多比较初级的同事。

www.3559.com 25

Markdown

然后事情并不止这么简单,所谓雪上加霜,我们还不得不面对一堆现实。

  • 比如首先,我们的业务开发团队的强项是什么?最强的会是技术吗?不,通常来说我们的业务开发团队最强的是对业务的理解,是对整个业务体系的熟悉程度。

  • 第二个事情,业务应用的核心价值是什么?我们辛辛苦苦写了这么多的微服务,难道是为了实现微服务吗?微服务只是我们的手段,我们最终需要实现的是业务,这是我们真正的目标。

  • 第三个事情是,就微服务这个手段而言,有比学习微服务框架更艰巨的挑战。在做微服务的真正落地时,会有更深刻的理解。比如微服务的拆分,比如要设计一个良好的API,要保持稳定并且易于扩展,还有如果涉及到跨多个服务的数据一致性,大部分团队都会头疼。最后是康威定律,但凡做服务的同学最终都会遇到这个终极问题,而大多数情况下是欲哭无泪。

但是这些还没完,比你写一个新的微服务系统更痛苦的事情,是你要对旧有的系统进行微服务改造。

所有这些加在一起,还不够,还要再加一条,这条更要命:业务开发团队往往业务压力非常大,时间人力永远不足。说下月上线就是下月上线,说双十一促销就不会推到双十二。老板是不会管你有没有时间学习spring cloud的,也不会管你的业务团队能否搞得定微服务的方方面面。业务永远看的是结果。

www.3559.com 26

Markdown

第二个痛点,功能不够,这里列出了服务治理的常见功能。而Spring Cloud的治理功能是不够强大的,如果把这些功能一一应对做好,靠Spring Cloud直接提供的功能是远远不够的。很多功能都需要你在Spring Cloud的基础上自己解决。

问题是你打算投入多少时间人力资源来做这个事情。有些人说我大不了有些功能我不做了,比如灰度,直接上线好了,但是这样做代价蛮高的。

www.3559.com 27

Markdown

第三个痛点,跨语言。微服务在刚开始面世的时候,承诺了一个很重要的特性:就是不同的微服务可以采用自己最擅长最喜欢的最适合的编程语言来编写,这个承诺只能说有一半是OK的,但是另外一半是不行的,是假的。因为你实现的时候,通常来说是基于一个类库或者框架来实现的,一旦开始用具体编程语言开始编码的时候你就会发现,好像不对了。为什么?左边是我从编程语言排行列表列出来的主流编程语言,排在前面的几种,大家比较熟悉.后面还有几十种没有列出来,中间是新兴的编程语言,比较小众一点。

现在的问题在于我们到底要为多少种语言提供类库和框架。

这个问题非常尖锐,为了解决这个问题,通常只有两条路可选:

  1. 一种就是统一编程语言,全公司就用一种编程语言
  2. 另外一个选择,是有多少种编程语言就写多少个类库

我相信在座的如果有做基础架构的同学,就一定遇到过这个问题。

www.3559.com 28

Markdown

但是问题还没完,框架写好了,也有能够把各个语言都写一份。但是接下来会有第四个痛点:版本升级。
你的框架不可能一开始就完美无缺,所有功能都齐备,没有任何BUG,分发出去之后就再也不需要改动,这种理想状态不存在的。必然是1.0、2.0、3.0慢慢升级,功能逐渐增加,BUG逐渐被修复。但是分发给使用者之后,使用者会不会立马升级?实际上做不到的。

这种情况下怎么办,会出现客户端和服务器端版本不一致,就要非常小心维护兼容性,然后尽量督促你的使用者:我都是3.0了,你别用1.0了,你赶紧升级吧。但是如果如果他不升级,你就继续忍着,然后努力解决你的版本兼容性。

版本兼容性有多复杂?服务端数以百计起,客户端数以千计起,每个的版本都有可能不同。这是一个笛卡尔乘积。但是别忘了,还有一个前面说的编程语言的问题,你还得再乘个N!

设想一下框架的Java1.0客户端访问node.js的3.0的服务器端会发生什么事情,C 的2.0客户端访问golang的1.0服务器端会如何?你想把所有的兼容性测试都做一遍吗?这种情况下你的兼容性测试需要写多少个Case,这几乎是不可能的。

www.3559.com 29

Markdown

那怎么办?怎么解决这些问题,这是现实存在的问题,总是要面对的。

我们来想一想:

  • 第一个是这些问题的根源在哪里:我们做了这么多痛苦的事情,面临这么多问题,这些多艰巨的挑战,这些和服务本身有关系吗?比如写一个用户服务,对用户做CRUD操作,和刚才说的这些东西有一毛钱关系吗?发现有个地方不对,这些和服务本身没关系,而是服务间的通讯,这才是我们需要解决的问题。

  • 然后看一下我们的目标是什么。我们前面所有的努力,其实都是为了保证将客户端发出的业务请求,发去一个正确的地方。什么是正确的地方?比如说有版本上的差异,应该去2.0版本,还是去1.0版本,需要用什么样的负载均衡,要不要做灰度。最终这些考虑,都是让请求去一个你需要的正确的地方。

  • 第三个,事情的本质。整个过程当中,这个请求是从来不发生更改的。比如我们前面说的用户服务,对用户做CRUD,不管请求怎么走,业务语义不会发生变化。这是事情的本质,是不发生变化的东西。

  • 这个问题具有一个高度的普适性:所有的语言,所有的框架,所有的组织,这些问题对于任何一个微服务都是相同的。

讲到这里,大家应该有感觉了:这个问题是不是和哪个问题特别像?

www.3559.com 30

Markdown

五十年前的前辈们,他们要解决的问题是什么?为什么会出现TCP,TCP解决了什么问题?又是怎么解决的?
TCP解决的问题和这个很像,都是要将请求发去一个正确的地方。所有的网络通讯,只要用到TCP协议,这四个点都是一致的。

有了TCP之后会发生什么? 我们有了TCP之后,我们基于TCP来开发我们的应用,我们的应用需要做什么事情? 我们的应用需要关心TCP层下链路层的实现吗?不需要。同理,我们基于HTTP开发应用时,应用需要关心TCP层吗?

www.3559.com 31

Markdown

为什么我们开发微服务应用的时候就要这么关心服务的通讯层?我们把服务通讯层所有的事情学一遍,做一遍,我们做这么多是为什么?

www.3559.com 32

Markdown

这种情况下,自然产生了另外一个想法:既然我们可以把网络访问的技术栈向下移为TCP,我们是可以也有类似的,把微服务的技术栈向下移?
最理想的状态,就是我们在网络协议层中,增加一个微服务层来完成这个事情。但是因为标准问题,所以现在没有实现,暂时这个东西应该不太现实,当然也许未来可能出现微服务的网络层。

之前有一些先驱者,尝试过使用代理的方案,常见的nginx,haproxy,apache等代理。这些代码和微服务关系不大,但是提供了一个思路:在服务器端和客户端之间插入了一个东西完成功能,避免两者直接通讯。当然代理的功能非常简陋,开发者一看,想法不错,但是功能不够,怎么办?

www.3559.com 33

Markdown

这种情况下,第一代的Sidecar出现了,Sidecar扮演的角色和代理很像,但是功能就齐全很多,基本上原来微服务框架在客户端实现的功能都会对应实现。
第一代的Sidecar主要是列出来的这几家公司,其中最有名气的还是Netflix。

在这个地方我们额外提一下,注意第四个,前面三个功能都是国外的公司,但是其实Sidecar这个东西并不是只有国外的人在玩,国内也有厂商和公司在做类似的事情。比如唯品会,我当年在唯品会基础架构部工作的时候,在2015年上半年,我们的OSP服务化框架做了一个重大架构调整,加入了一个名为Local Proxy的Sidecar。注意这个时间是2015上半年,和国外差不多。相信国内肯定还有类似的产品存在,只是不为外界所知。

www.3559.com 34

Markdown

这个时期的Sidecar是有局限性的,都是为特定的基础设施而设计,通常是和当时开发Sidecar的公司自己的基础设施和框架直接绑定的,在原有体系上搭出来的。这里面会有很多限制,一个最大的麻烦是无法通用:没办法拆出来给别人用。比如Airbnb的一定要用到Zookeeper,Netflix的一定要用Eureka,唯品会的Local Proxy是绑死在Osp框架和其他基础设施上的。
之所以出现这些绑定,主要原因还是和这些Sidecar出现的动机有关。比如Netflix是为了让非JVM语言应用接入到Netflix OSS中,Soundcloud是为了让遗留的Ruby应用可以使用到JVM的基础设置。而当年我们唯品会的OSP框架,Local Proxy是为了解决非Java语言接入,还有前面提到的业务部门不愿意升级的问题。这些问题都比较令人头疼的,但是又不得不解决,因为逼的憋出来Sidecar这个一个解决方式。

因为有这样的特殊的背景和需求,所以导致第一代的Sidecar无法通用,因为它本来就是做在原有体系之上的。虽然不能单独拿出来,但是在原有体系里面还是可以很好工作的,因此也没有动力做剥离。导致虽然之前有很多公司有Sidecar这个东西,但是其实一直没怎么流传出来,因为即使出来以后别人也用不上。

这里提一个事情,在2015年年中的时候,我们当时曾经有一个想法,将Local Proxy从OSP剥离,改造为通用的Sidecar。计划支持HTTH1.1,操作Http Header就可以,Body对我们是可以视为透明的,这样就容易实现通用了。可惜因为优先级等原因未能实现,主要是有大量的其他工作比如各种业务改造,这个事情必要性不够。

所有比较遗憾,当时我们有这个想法没做实现,这是在2015年,时间点非常早的了。如果当时有实现,很可能我们就自己折腾出业界第一个Service Mesh出来了。现在想想挺遗憾的。

www.3559.com 35

Markdown

但是,不只有我们会有这想法。还有有一些人想法和我们差不多,但是比较幸运的是,他们有机会把东西做出来了。这就是第一代的Service Mesh,通用性的Sidecar。
通用型的Service Mesh的出现,左边第一个Linkerd是业界第一个Service Mesh,也就是它创造了Service Mesh这个词。时间点:2016年1月15号,0.0.7发布,这是Github上看到的最早的一个版本,其实这个版本离我们当时的有想法的时间点非常近。然后是1.0版本,2017年4月份发布,离现在六个月。所以说,Service Mesh是一个非常新的名词,大家没听过非常正常。

接下来是Envoy,2016年发布的1.0版本。

这里面要特别强调,Linkerd和Envoy都加入了CNCF,Linkerd在今年1月份,而Envoy进入的时间是9月份,离现在也才1个月。在座的各位应该都明白CNCF在Cloud Native领域是什么江湖地位吧?可以说CNCF在Cloud Native的地位,就跟二战后联合国在国际秩序中的地位一样。

之后出现了第三个Service Mesh,Nginmesh,来自于大家熟悉的Nginx,2017年9月发布了第一个版本。因为实在太新,还在刚起步,没什么可以特别介绍的。

www.3559.com 36

Markdown

我们来看一下Service Mesh和Sidecar的差异,前面两点是已经提到了:

  • 首先Service Mesh不再视为单独的组件,而是强调连接形成的网络
  • 第二Service Mesh是一个通用组件

然后要强调的是第三点,Sidecar是可选的,容许直连。通常在开发框架中,原生语言的客户端喜欢选择直连,其他语言选择走Sidecar。比如Java写的框架,Java客户端直连,Php客户端走Sidecar。但是也可以都选择走Sidecar,比如唯品会的OSP就是所有语言都走Local Proxy。在Sidecar中也是可选的。但是,Service Mesh会要求完全掌控所有流量,也就是所有的请求都必须通过Service Mesh。

www.3559.com 37

Markdown

接下来给大家介绍Istio,这个东西我给它的评价是王者风范,来自于谷歌、IBM和Lyft,是Service Mesh的集大成者。
大家看它的图标,就是一个帆船。Istio是希腊语,英文语义是”Sail”, 翻译过来是起航的意思。大家看这个名字和图标有什么联想?Google在云时代的另外一个现象级产品,K8S,Kubernete也同样起源于希腊语,船长,驾驶员或者舵手,图标是一个舵。

Istio名字和图标与K8s可以说是一脉相承的。这个东西在2017年5月份发布了0.1,就在两周前的10月4号发布了0.2。大家都熟悉软件开发,应该明白0.1/0.2在软件迭代中是什么阶段。0.1大概相当于婴儿刚刚出世,0.2还没断奶。但是,即使在这么早期的版本中,我对他的评价已经是集大成者,王者风范,为什么?

www.3559.com 38

Markdown

为什么说Istio王者风范?最重要的是他为Service Mesh带来了前所未有的控制力。以Sidecar方式部署的Service Mesh控制了服务间所有的流量,只要能够控制Service Mesh就能够控制所有的流量,也就可以控制系统中的所有请求。为此Istio带来了一个集中式的控制面板,让你实现控制。
左边是单个视图,在sidecar上增加了控制面板来控制sidecar。这个图还不是特别明显,看右边这个图,当有大量服务时,这个服务面板的感觉就更清晰一些。在整个网络里面,所有的流量都在Service Mesh的控制当中,所有的Service Mesh都在控制面板控制当中。可以通过控制面板控制整个系统,这是Istio带来的最大的革新。

www.3559.com 39

Markdown

Istio由三个公司开发,前两个比较可怕,谷歌和IBM,而且都是云平台,谷歌的云平台,IBM的云平台,尤其GCP的大名想必大家都知道。所谓出身名门,大概指的就是这个样子吧?
Istio的实力非常强,我这里给了很多的赞誉:设计理念非常新颖前卫,有创意,有魄力,有追求,有格局。Istio的团队实力也非常惊人,大家有空可以去看看istio的委员会名单感受一下。Istio也是Google的新的重量级的产品,很有可能成为下一个现象级的产品。Google现在的现象级产品是什么?K8s。而Istio很有可能成为下一个K8S级别的产品。

说到应时而生,什么是势?我们今天所在的是什么时代?是互联网技术大规模普及的时代,是微服务容器如日中天的时代,是Cloud Native大势已成的时代。也是传统企业进行互联网转型的时代,今天的企业用户都想转型,这个大势非常明显,大家都在转或者准备转,但是先天不足。什么叫先天不足?没基因,没能力,没经验,没人才,而且面临我们前面说的所有的痛点。所有说Istio现在出现,时机非常合适。别忘了Istio身后还有CNCF的背景,已经即将一统江湖的k8s。

Istio在发布之后,社区响应积极,所谓应者云集。其中作为市面上仅有的几个Service Mesh之一的Envoy,甘心为Istio做底层,而另外两个实现Linkerd/nginmesh也直接放弃和Istio的对抗,选择合作,积极和Istio做集成。社区中的一众大佬,如这里列出来的,都在第一时间响应,要和istio做集成或者基于Istio做自己的产品。为什么说是第一时间?Istio出0.1版本,他们就直接表明态度开始站队了。

www.3559.com 40

Markdown

Istio的架构,主要分为两大块。下面的数据面板,是给传统Service Mesh的,目前是Envoy,但是我们前面也提到Linkerd和Nginmesh都在和Istio做集成,指的就是替代Envoy做数据面板。
另外一大块就是上面的控制面板,这是Istio真正带来的内容。主要分成三大块,图中我列出了他们各自的职责和可以实现的功能。

因为时间有限,不在今天具体展开。

www.3559.com 41

Markdown

这里给大家留一个地址,是我之前做的一次线上分享,对Istio的详细介绍,内容比较多,大家看看仔细看看。

万字解读:Service Mesh服务网格新生代—Istio
然后我们还组织了一个service mesh的技术社区,对istio的文档进行了翻译。

Istio官方文档中文翻译

www.3559.com 42

Markdown

总结一下,Service Mesh这是一步一步过来的: 从原始的代理,到限制很多的Sidecar,再到通用性的Service Mesh,然后到加强管理功能的Istio,在未来成为下一代的微服务。
注意,离Service Mesh这个词汇出现的时间点,也才一年。

第二个挑战是微服务框架SDK多语言并行开发与维护成本高。

为何选择Service Mesh?

www.3559.com 43

Markdown

前面三个痛点都被解决了,有了Service Mesh之后这些问题都不是问题了。升级的痛点怎么解决?Service Mesh是一个独立进程,可单独升级,而应用程序不用改。

www.3559.com 44

Markdown

Service Mesh是以远程调用的方式让客户端接入,只要能发出请求,简单发给Service Mesh就可以。客户端极度简化,对于典型的Rest请求,几乎所有的语言都有完善的支持。而服务器端只要做一个事情,服务注册。这样对于多语言的支持,就变得非常舒服了。现在终于可以真正的自由选择编程语言。

www.3559.com 45

Markdown

这里有一个奇迹,鱼与熊掌兼得:同时实现降低门槛,功能增加。有些信奉质量守恒的同学会感觉不科学,注意能同时实现这两个改进的原因,是把工作量最大最辛苦的事情都交给了Service Mesh。而Service Mesh是通用的,可以反复重用的。

www.3559.com 46

Markdown

Service Mesh为业务开发团队带来的变革:降低入门门槛,提供稳定基座,帮助团队实现技术转型。最终达到的目的是,让业务开发团队从微服务实现的具体技术细节中解放出来,回归业务。

www.3559.com 47

Markdown

第二个变革,是对运维管理团队的强化,这里如果有做运维的同学,你们可以认真思考一下:如果有了Service Mesh,你们对系统的管理和控制力会有多大的?注意很多功能的实现已经不再和应用有关,都在移到Service Mesh中,而Service Mesh通常是在运维的掌控中。

www.3559.com 48

Markdown

Service Mesh对于新兴小众语言是极大的利好。对于新的语言来说,在和传统的主流编程语言竞争时,最痛苦的事情是什么?是生态,比如各种类库,各种框架。在微服务这个领域,新兴小众语言想和Java等比拼,非常的难:这是用自己的劣势对上别人的优势。而有了Service Mesh之后,小众语言就有机会避开这个弊端,再不用和Java比拼生态,而是充分发挥自己的语言特点,做自己最擅长的领域。

www.3559.com 49

Markdown

www.3559.com 50

Markdown

今天的内容基本上到这儿了,最后给两个资料,这两个文章,一个是对Service Mesh的解释,一个是详细介绍Service Mesh的由来,大家如果回去之后可以详细看一下。尤其第二个文章,我的PPT援引了里面的很多图片。英文不是特别好的同学可以看一下中文翻译版本,作者翻译质量非常高。

以前我们都是通过对技术栈的统一来提升成本优势和团队效率,大家可以用一种语言去开发和维护,避免多语言时团队的不聚焦。但在软件和开源生态演进的过程中,多语言已经成为一种流行,因为不同语言都有其自身的优势,今天大家能看到的一个现象是云原生的生态中有多种开发语言,使用频率最高的语言已经不是Java了,而是Go,是因为Go的footprint很小。再以 Dubbo为例,除了Java,我们还提供C ,Node.js的SDK,以便让更多的开发者可以加入Dubbo生态,但所有的这些,如果没有社区力量的参与,是很难维持的。

总结

www.3559.com 51

Markdown

最后,我们建立了一个Service Mesh的技术社区和微信群,供以交流学习,目前微信群已建立,社区正在筹备当中,不就将会亮相。

我们今天的内容就到这里结束,非常感谢大家!

www.3559.com 52

第三个挑战是异构服务框架难以共存完成渐进式演进。

我们结合场景来看看这个挑战。阿里巴巴收购了一些企业,被收购企业的技术栈可能和阿里巴巴不同,比如有些用的是Go语言,有些用的是PHP,这时候为了统一技术栈,我们需要对这类技术平台推倒重来,但这个过程中,我们会面临一系列问题,首当其冲的就是推倒重来会带来巨大的技术风险,其次是可能会面临技术人员大批量流失的风险,这在社会责任的层面也是很难接受。所以我们在寻求一种可能的方案,去解决这类问题。

第四个挑战是单一的语言限制了人才的多样性。

这里,我们不去争论某个编程语言的好与坏,每个语言都有其适用场景,你不能说我手里有个榔头,你面对的都是钉子。以前我们觉得统一技术栈可以集中开发力量,并且带来较高的运维便利性。但伴随着互联网带来的快节奏,以往的团队能力设置已经很难满足这类变化,对工程师个体提出了更高的要求,我们不仅仅需要是某一方面的专家,而且还需要具备多域的工作技能,DevOps和全栈工程师就是这类快节奏变化下最好的注脚。

www.3559.com 53

第五个挑战是点状的服务治理难以做到及时、有效和经济。

微服务和架构的核心是拆分,通过拆分,让每个模块可以独立运行,跟上业务的发展速度,持续推动业务的创新。但拆完后新的问题出来了,缺少横向的内容拉通所有独立的烟囱,从而在服务治理上带来极大的挑战。

二、分布式应用的4大发展趋势

1. 微服务会成为大规模分布式应用的主流架构。

任何复杂的工程问题都会归结为devide and conquer(分而治之),意思就是就是把一个复杂的问题分成两个或更多的相同或相似的子问题,再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。微服务本质是对服务的拆分,与工程领域惯用的“分而治之”的思路是一致的。

2. 微服务架构下应用的开发是多语言的。

没有一个语言是一家独大的,每种语言在特定场景下都有其自身的优势,我们希望这种优势能够将技术到产品的周期(time to market)缩短。技术的核心在于创造价值,无论是交付给客户,还是服务于整个社会。因此,微服务是需要不同语言的开发者发挥自身的优势,去进一步完善我们的微服务架构,释放技术价值。

www.3559.com 54

3. 数据安全将成为公有云分布式应用的生命线。

云原生时代,业务即便没上云,企业对自身数据的安全都是有诉求的,尤其是在金融行业,如果通过抓包就能获取一些敏感信息,这将会给企业带来巨大的风险。

4. Cloud native成为distributionless(无分布式)的主要探索路径。

分布式发展的终极形式是无分布式,在未来我们做开发,所有的代码在web上写好后,通过点击一个按钮,所有部署都会自动实现,所有的code review的工作可以在一个统一的工作台上全部实现。

www.3559.com 55

▵成都站开发者沙龙现场

5. 以更快的速度,通过构建软件去探索新业务。

工程师服务的是客户,通过技术输出来实现技术价值,以互联网的架构帮助赋能传统企业,帮助企业获得差异化竞争力。

三、什么是 Service Mesh

Service Mesh是层次化、规范化、体系化、无侵入的分布式服务治理技术平台。

层次化

分为数据面和控制面两个概念,数据面是指所有数据流动的那个层面,控制面是用来控制这个数据面的,对服务去做处理。对数据面和控制面进行分层,带来的好处是,针对一个复杂的系统进行切分,可以获得更清晰的认识,这和devide and conque是同一个理念。

规范化

是指通过标准协议完成数据平面和控制平面的连接,同时,sidecar成为所有traffic互联、互通的约束标准。

www.3559.com 56

体系化

包含两个维度,一是指observability全局考虑。目前在整个分布式治理过程中的最大挑战是:logging、metrics、tracing这三个observability领域的核心内容缺少体系性的关注。另一个是集中管理的维度,包括服务管理、限流、熔断、安全、灰度在内的服务模块都可以在获得体系化的呈现,每个服务都可以被看到,而非团队a只看限流,团队b只看logging,需要一种技术能力拉通所有的服务模块,这个体系化这个角度看,Service Mesh是一个理想的技术方案。

无侵入

是指我们希望通过无侵入,当新增一个业务的时候,不需要考虑一个SDK去初始化,而是可以通过sidecar的进程方式来解耦。

四、Service Mesh 的形态

我们从三个维度对比的来看 ServiceMesh 的形态。

图中左边是传统的微服务形态,调用者和被调用者是通过一个SDK的方式来实现共享服务的,以Dubbo为例,我们会在SDK里提供服务路由、服务发现等功能,虽然我们的开发者在做应用开发的时候并不会太关注SDK的构成,但这些功能是面临不断被变更的可能,有着比较重的逻辑。在右边Service Mesh的形态中,我们首先会对厚重的SDK进行分解,将复杂的逻辑下沉到sidecar,借助sidecar来实现服务的调用。

www.3559.com 57

虽然在Service Mesh的形态,调用路径要长于传统的形态,路径越长消耗越大,对性能影响越大。但在当前的分布式应用的治理过程中,易用性已经成为一个比性能更重要的话题。当我们给客户部署一套微服务,即便性能很强,但没有处理好易用性问题的话,这将会给技术的推广带来巨大的阻碍,不仅是会影响外部的客户,也会影响内部的用户,如何实现喝着咖啡从容应对双11,必须先解决易用性的问题。在解决易用性问题后,沿着技术的发展路径再去解决性能问题。

Service Mesh的形态中的control plan不会导致重复建设,但在shared service是有可能存在重复建设的。

五、Service Mesh 下的应用架构

无论是单体应用,还是分布式应用,都可以建立在Service Mesh上,mesh上的sidecar支撑了所有的上层应用,业务开发者无须关心底层构成,可以用Java,也可以用Go等语言完成自己的业务开发。

六、Service Mesh 的价值

  • 为单体应用向微服务架构演进提供了渐进的途径
  • 为异构(微)服务框架/平台提供了融合发展的可能

Ø 被收购子公司与母公司的业务可以融合发展

  • 加速(微)服务框架/平台自身的演进
  • 让业务开发同学聚焦于业务逻辑本身
  • 业务开发时无需关心安全、灰度、限流、熔断等通用的技术内容
  • 培育了多语言业务开发的土壤

Ø 助力人才发展中编程语言的多样性

  • 对(异构)微服务架构应用实现更为有效的全局一体化监管控

七、Dubbo Mesh 的发展思路

  • 迎合Kubernetes已成orchestrator王者的大势
  • 开源版本与阿里巴巴集团内版本统一
  • 与领域主流开源项目形成合力发展,源于开源、反哺开源

八、Dubbo Mesh 的进展

Dubbo Proxy

  • Envoy支持Dubbo协议,分两个迭代完成

迭代一:实现对Dubbo协议的解析和统计信息收集(代码已提交给社区review)

迭代二:支持服务路由(规划中)

Dubbo Control

  • 丰富Istio/Pilot-discovery

已完成与VIPServer、Diamond的对接

正规划与ZooKeeper、Nacos的对接

  • 仍在规划Istio/Mixer部分

九、成都沙龙 Q&A

Q1: 阿里巴巴是怎么从微服务过渡到sidecar模式,再过渡到Service Mesh?

整个过渡是渐进式的,我们会将控制平面的一些组件先下沉到与sidecar部署在一起,这一下沉能很好复用开源软件已有的能力而减少开发工作量。当这一步骤完成后,被下沉的控制面组件会重新拉回到上面的控制面,那时就会面临一定的服务端改造,一旦改造完成就有了一个全新、完整的Service Mesh。

Q2: Service Mesh中的服务注册发现,负载均衡,网关,熔断降级,超时,限流,消息总线,分布式配置,这些都是怎么实现的?

Dubbo Mesh在控制面会基于Istio去做,而Istio已经具备了Kubernetes下的服务注册与发现能力,我们要做的是扩充Istio的能力,让服务注册与发现能与ZooKeeper、Nacos进行对接去完成。基于开源的Envoy所实现的sidecar已实现了超时处理的功能,相应的内容可以读代码去了解。其他内容我们仍在规划中。

Q3: Dubbo Mesh目前性能怎么样? 增加一层sidecar导致Dubbo的RT有多少?

在使用iptables的情形下,一跳增加1.5毫秒,如果不采用iptables直接proxy方式的情形下应当性能更好(这一点与Lyft也邮件确认过了),我们接下来会做更多的性能测试,目前的焦点更多在于功能层面。

Q4: Dubbo Mesh是把双刃剑,经过的链路更复杂,运维和开发者问题排查有没有更有效的工具?

**

理论上,增加一跳并没有改变服务调用的拓扑结构,但确实会增加复杂度,这个应当通过设计实现去解决。好在因为是一体化的方案,所以解决这类问题时需要更具全局视野。**

www.3559.com 58

▵成都站开发者提问

Q5: Service Mesh中控制面板也用C 吗?我看主流很多实现都是Go, 我相信大佬做过技术调研,有哪些优势?

控制面是复用Istio的,是Go语言的。我们力争不重复造轮子,而是以开放的心态去共建。

Q6: Client做解码和反序列化是吧,有计划支持HTTP2协议吗?

Envoy默认就支持了,不需我们开发。这也是借力开源的收益。

Q7: Dubbo Mesh已经支持domain socket了吗?

目前不支持,这个还处于意向阶段。

作者:中间件小哥

本文为云栖社区原创内容,未经允许不得转载。返回搜狐,查看更多

责任编辑:

编辑:www.3559.com 本文来源:阿里巴巴中间件团队在,由浅入深带你走进微服

关键词: www.3559.com