Service Mesh

Service Mesh

什么是服务网格?

grace_shi 发表了文章 • 0 个评论 • 292 次浏览 • 2019-06-04 22:29 • 来自相关话题

服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观 ...查看全部
服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观察性,可追溯性,身份验证和授权,以及对断路器模式【1】的支持。

服务网格是如何实现的呢?它通常会为每个服务实例提供一个称为边车(sidecar)的代理实例。这些边车会处理服务间的通信,监控和安全相关的问题, 以及任何可以从各个服务中抽象出来的东西。这样,开发人员就可以专注于服务中应用程序代码的开发,支持和维护,而运维团队可以负责维护服务网格以及运行应用程序。

Istio,由Google,IBM和Lyft支持,是目前最著名的服务网格架构。Kubernetes,最初由Google设计,是目前Istio支持的唯一容器编排框架。供应商正在寻求商业版本的Istio。如果Istio能添加到开源项目中,将会带来更大的价值。

Istio并不是唯一的选择,其他服务网格实现也在开发中。目前边车代理模式是最受欢迎的,例如Buoyant,HashiCorp,Solo.io等项目都使用了这种模式。与此同时,Netflix的技术套件使用了一种替代架构,他们使用了应用程序库(包含Ribbon,Hysterix,Eureka,Archaius)来提供服务网格功能,而Azure Service Fabric等平台在应用程序框架中嵌入了类似服务网格的功能。 服务网格包含一些专业术语来描述组件服务和功能:

  • 容器编排框架。随着越来越多的容器被添加到应用程序的基础架构中,用于监视和管理容器组的容器编排框架变得至关重要。
  • 服务和实例(Kubernetes Pod)。实例是微服务的单个运行副本。有时实例是一个容器;在Kubernetes中,一个实例由一小组相互依赖的容器(称为Pod)组成。客户端很少直接访问实例或Pod,通常他们会访问服务,服务通常是一组可扩展且具有容错性的实例或Pod(副本)。
  • 边车代理。 边车代理与单个实例或Pod一起运行。 边车代理的目的是路由或者代理从容器发出或者接收的流量。 边车与其他边车代理进行通信,编排框架会管理这些边车。许多服务网格的实现会使用边车代理来拦截和管理实例或Pod的所有进出流量。
  • 服务发现。当实例需要与不同的服务进行交互时,它需要找到 - 发现 - 其他服务的健康的,可用的实例。通常,这个实例会执行DNS查找来寻找其他服务的实例。容器编排框架保留实例列表(这些实例都可以正常接收请求),并且框架会提供DNS查询的接口。
  • 负载均衡。大多数编排框架已经提供了第4层(传输层)的负载均衡。服务网络实现了更复杂的第7层(应用层)负载均衡,具有更丰富的算法以及更强大的流量管理。同时可以通过API修改负载均衡的参数,从而可以编排蓝绿部署【2】或金丝雀部署【3】。
  • 加密。服务网格可以加密和解密请求和响应,因此每个服务不需要额外对请求进行加密,减少了负担。服务网格还可以通过优先重用现有的持久连接来提高性能,这减少新连接的创建(创建新连接十分耗费计算资源)。一般实现加密流量都是用双向TLS(mTLS),其中公钥架构(PKI,public key infrastructure)生成并分发证书和密钥,提供给边车代理使用。
  • 身份验证和授权。服务网格可以授权和验证从应用程序外部和内部发出的请求,仅向实例发送经过验证的请求。
  • 支持断路器模式【1】。服务网格可以支持断路器模式,这可以隔离不健康的实例,然后在安全的情况下逐渐将它们恢复并加入到健康的实例池中。

服务网格应用中管理实例之间的网络流量的的部分称为数据平面。另外有一个独立的控制平面负责生成和部署数据平面的配置(这个配置可以控制数据平面的行为)。控制平面通常包含(或被设计为连接到)一个API,命令行界面和用于管理App的图形用户界面。

*服务网格中的控制平面在数据平面中边车代理上分发配置*

服务网格架构的一个常见用例是在使用容器和微服务时解决非常苛刻的操作问题。微服务领域的先驱包括Lyft,Netflix和Twitter等公司,这些公司任何时间都能为全球数百万用户提供强大的服务。 (请参阅我们对Netflix面临的一些架构挑战的深入描述。)如果应用程序对这方面要求比较低,那么更简单的架构就足够了。

服务网格架构不可能解决所有应用程序操作和交付问题。架构师和开发人员可以选择多种工具,这些工具之中,有些是锤子,可以解决不同类型的问题,而另一些可能是钉子。例如,NGINX微服务参考架构包括几种不同的模型,这些模型提供了使用微服务来解决问题的一系列方法。 服务网格架构中的组成部分 - 例如:NGINX,容器,Kubernetes,以及微服务(作为架构方法),可以在非服务网格架构实现中高效地使用。例如,Istio是作为一个完整的服务网格架构开发的,但其模块化的设计意味着开发人员可以自由选择他们需要的部分组件技术。考虑到这一点,即使您不确定是否以及何时会完全实现服务网格应用程序,也值得深入了解一下服务网格概念。 

注释: 

【1】断路器模式: 一种设计模式。用以侦测错误,并避免不断地触发相同的错误(如维护时服务不可用、暂时性的系统问题或是未知的系统错误)。https://zh.wikipedia.org/wiki/斷路器設計模式 
【2】蓝绿部署(blue‑green deployment):蓝绿部署是保留老版本,同时部署新版本然后进行测试,测试通过后,将流量切换到新版本,然后老版本同时也升级到新版本。 
【3】金丝雀部署(canary deployment):又叫做灰度部署,即选择部分部署新版本,将部分流量引入到新版本,新老版本同时提供服务。等待灰度的版本测试完毕,之后全量覆盖老版本。 

原文链接:What Is a Service Mesh? 

============================================================================== 
译者介绍:Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。

Service Mesh发展趋势:云原生中流砥柱

大卫 发表了文章 • 0 个评论 • 186 次浏览 • 2019-05-28 15:32 • 来自相关话题

【编者的话】本文主要介绍了 ServiceMesh 最新的产品动态,分析其发展趋势和未来走向;结合蚂蚁的上云实践,阐述在云原生背景下 Service Mesh 的核心价值,以及对云原生落地的关键作用。 内容主要有三个部分: ...查看全部
【编者的话】本文主要介绍了 ServiceMesh 最新的产品动态,分析其发展趋势和未来走向;结合蚂蚁的上云实践,阐述在云原生背景下 Service Mesh 的核心价值,以及对云原生落地的关键作用。

内容主要有三个部分:

  1. Service Mesh 产品动态:介绍最近半年 Service Mesh 的产品动态,包括开源项目和云厂商推出的云上服务
  2. Service Mesh 发展趋势:根据最近的产品动态,总结 Service Mesh 的发展趋势,推断未来的走向
  3. Service Mesh 与云原生:结合云原生,更好的理解 Service Mesh 的价值和作用

#Service Mesh产品动态

##Istio 1.1 发布

Istio 是目前 Service Mesh 社区最引人注目的开源项目,在今年的3月份发布了期待已久的 Istio 1.1 版本,我们来看看 Istio 最近几个版本的发布情况:

* 2018年6月1日,Istio 发布了 0.8 版本,这是Istio历史上第一个LTS版本,也是Istio历史上变动最大的一个版本
* 2018年7月31日,Istio发布了1.0版本,号称 “Product Ready”
* 然后就是漫长的等待,Istio 1.0 系列以每个月一个小版本的方式一路发布了1.0.1 到 1.0.6,然后才开始 1.1.0 snapshot 1到6,再 1.1.0-rc 1到6,终于在2019年3月20日发布了 1.1 版本,号称 “Enterprise Ready”。

从 Istio 1.0 到 Istio 1.1,中间的时间跨度高达 9 个月!我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西:
1.png

图中标红的部分,涉及到 Istio 的架构调整,下面将详细介绍 Istio 1.1 版本中带来的架构变化。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
##Istio 1.1 架构变化

下图是 Istio 1.0 和 Istio 1.1 的架构图对比:
2.png

Istio 1.1 的第一个架构变化来自 Galley:在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在,只是当时 Galley 的功能非常简单,只是做配置更新之后的验证(Validation),在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后,Galley 的定位发生了巨大的变化:Galley开始分担 Pilot/Mixer 的职责。

在 Istio 1.1 版本之前的设计中,Istio的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server,以获取服务注册信息和配置信息,包括 Kubernetes 原生资源如 Service/Deployment/Pod 等,还有 Istio 的自定义资源(数量多达50多个的 CRD) 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server 产生强绑定,不仅仅代码大量冗余,而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。

为了解决这个问题,在 Istio 1.1 之后,访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件,而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。
3.png

这个工作还在进行中,目前 Istio 的CRD 已经修改为由 Galley 读取,而 Kubernetes 的原生资源(Service/Deployment/Pod 等),暂时还是由 Pilot 读取。

为了方便在各个组件中同步数据,Istio 引入了MCP(Mesh Configuration Protocol)协议。在 Istio 1.1 版本中,Pilot 通过 MCP 协议从 Galley 同步数据。MCP是受 xDS v2 协议(准确说是 aDS)的启发而制定的新协议,用于在Istio 各模块之间同步数据。

Istio 1.1 的第二个架构变化来自于 Mixer,在 Istio 1.1 版本中,推荐使用 Out-of-Process Adapter,即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter,目前所有的 Adapter 都将改为 Out-of-Process adapter。

什么是 In-Proxy Adapter?下图是 Mixer 的架构图,在 Istio 的设计中,Mixer 是一个独立进程,Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式,定义了 Adapter API,然后内建了数量非常多的各种 Adapter。这些 Adatper 的代码存放在 Mixer 代码中,运行时也在 Mixer 的进程内,因此称为 In-Process Adapter。
4.png

In-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定,包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer,任意一个 Adapter 的实现出现问题也会影响整个 Mixer,而且数量众多的 Adapter 也带来了数量众多的CRD。为此,Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。
5.png

Out-of-Process Adapter以独立进程的方式运行在 Mixer 进程之外,因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer,从而将 Mixer 从 Adaper 的实现细节中解脱出来。

但是,Out-of-Process Adapter的引入,会导致新的性能问题:原来 Mixer 和 In-Process Adapter 之间是方法调用,现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议,之前 Proxy 和 Mixer 之间的远程调用,已经造成非常大的性能瓶颈,而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次(每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用),这会让性能雪上加霜。

总结 Out-of-Process Adapter 的引入:架构更加的优雅,性能更加的糟糕。

在 Istio 1.1 为了架构而不顾性能的同时,Istio 内部也有其他的声音传出,如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法,改为将 Mixer 的功能合并到 Envoy 中,从而避免 Envoy 和 Mixer 之间远程调用的开销。关于 Mixer 的性能问题和 Mixer 合并的思路,蚂蚁金服在去年六月份开始 SOFAMesh 项目时就有清晰的认识和计划,时隔一年,终于欣喜的看到 Istio 开始正视 Mixer 的架构设计问题并回到正确的方向上。

对此有兴趣的朋友可以通过阅读下面的文章获取更详细的信息(发表于一年前,但是依然有效):

* 大规模微服务架构下的Service Mesh探索之路:第二节架构设计中的”合并部分Mixer功能”
* Service Mesh架构反思:数据平面和控制平面的界线该如何划定?
* Mixer Cache: Istio的阿克琉斯之踵?: 系列文章,有两篇
* Istio Mixer Cache工作原理与源码分析:系列文章,有四篇

目前 Mixer v2 的规划还处于 Review 状态,实现方式尚未有明确决定。如果要合并 Mixer,考虑到目前 Mixer 是基于 Golang 编写,而 Envoy 是基于 C++ ,这意味着需要用 C++重写所有的 Adapter,工作量巨大,恐怕不是短期之内能够完成的。当然也有另外一个新颖(或者说脑洞大开)的思路:引入 Web Assembly(WASM)。目前 Envoy 在进行支持 Web Assembly 的尝试,如果成功,则通过 Web Assembly 的方式来支持 Mixer Adapter 不失为一个好选择。
##其他社区产品动态

最近,CNCF 在筹建 Universal Data Plane API (UDPA/通用数据平面API)工作组,以制定数据平面的标准 API,为 L4/L7 数据平面配置提供事实上的标准。Universal Data Plane API 的创意来自 Envoy,实现为 xDS API。而目前 xDS v2 API 已经是数据平面API的事实标准,这次的 UDPA 会以xDS v2 API 为基础。工作组的初始成员来自包括 Envoy 和 gRPC 项目的代表,蚂蚁金服也在积极参与 UDPA 工作组,目前还处于非常早期的筹备阶段。

Linkerd2 在2019年4月17日发布了最新的稳定版本 Linkerd 2.3 版本。Linkerd2 是目前开源产品中唯一正面对抗 Istio 的存在,不过在国内知名度不高,使用者也很少。比较有意思的是,开发Linkerd2 的初创公司 Buoyant 最近的B轮融资来自 Google 的投资部门。
##云厂商的产品动态

随着 Service Mesh 技术的发展,和各方对 Service Mesh 前景的看好,各大主流云提供商都开始在 Service Mesh 技术上发力。

首先看 AWS,在2019年4月,AWS 宣布 App Mesh GA。App Mesh 是 AWS 推出的AWS原生服务网格,与AWS完全集成,包括:

* 网络(AWS cloud map)
* 计算(Amazon EC2 和 AWS Fargate)
* 编排工具(AWS EKS,Amazon ECS 和 EC2 上客户管理的 Kubernetes)

6.png

App Mesh 的数据平面采用 Envoy,产品非常有创意的同时支持VM和容器,支持多种产品形态,如上图所示。

Google 的打法则是围绕 Istio 。首先是在2018年底推出了 Istio on GKE,即”一键集成 Istio”,并提供遥测、日志、负载均衡、路由和 mTLS 安全能力。接着 Google 又推出 Google Cloud Service Mesh,这是 Istio 的完全托管版本,不仅仅提供 Istio 开源版本的完整特性,还集成了 Google Cloud上 的重要产品 Stackdriver 。

近期,Google 推出 Traffic Director 的 beta 测试版本,Traffic Director 是完全托管的服务网格流量控制平面,支持全局负载均衡,适用于虚拟机和容器,提供混合云和多云支持、集中式健康检查和流量控制,还有一个非常特别的特性:支持基于流量的自动伸缩。
7.png

微软则推出了 Service Fabric Mesh。Azure Service Fabric 是 Microsoft 的微服务框架,设计用于公共云,内部部署以及混合和多云架构。而 Service Fabric Mesh 是 Azure 完全托管的产品,在 2018 年 8 月推出预览版。
8.png

上周(5月21号)最新消息,微软在 kubeconf 上推出 Service Mesh Interface。SMI 是在 Kubernetes 上运行服务网格的规范,定义了由各种供应商实现的通用标准,使得最终用户的标准化和服务网格供应商的创新可以两全其美,SMI 预期将为 Service Mesh 带来了灵活性和互通性。

SMI是一个开放项目,由微软,Linkerd,HashiCorp,Solo,Kinvolk 和 Weaveworks联合启动;并得到了 Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat 和 VMware 的支持。
9.png

#Service Mesh发展趋势

在分享完最近半年 Service Mesh 产品的动态之后,我们来分析探讨 Service Mesh 的发展趋势。
##趋势 1:上云 + 托管

在微服务/容器这些年的发展历程中,我们会发现一个很有意思(甚至有些哭笑不得)的现象:
10.png


* 为了解决单体的复杂度问题,我们引入微服务架构
* 为了解决微服务架构下大量应用部署的问题,我们引入容器
* 为了解决容器的管理和调度问题,我们引入 Kubernetes
* 为了解决微服务框架的侵入性问题,我们引入 Service Mesh
* 为了让 Service Mesh 有更好的底层支撑,我们又将 Service Mesh 运行在 Kubernetes 上

在这个过程中,从单个应用(或者微服务)的角度看,的确自身的复杂度降低,在有底层系统支撑的情况下部署/维护/管理/控制/监控等也都大为简化。但是站在整个系统的角度,整体复杂度并没有消失,只是从单体分解到微服务,从应用下沉到 Service Mesh,复杂度从总量上不但没有减少,反而大为增加。

解决这个问题最好的方式就是 上云,使用 托管 版本的 Kubernetes 和 Service Mesh,从而将底层系统的复杂度交给云厂商,而客户只需要在云的基础上享受 Service Mesh 技术带来的使用便利和强大功能。

前面我们分享产品动态时,可以看到目前 Google/AWS/微软这三巨头都已经推出了各自的 Service Mesh 托管产品,而在国内,阿里云/华为云等也有类似的产品推出,我们蚂蚁金服也将在稍后在金融云上推出 SOFAMesh 的云上托管版本。在这里,我总结为一句话:

几乎所有的主要公有云提供商都在提供(或者准备提供)Service Mesh托管方案
##趋势 2:VM 和容器混用

第二个趋势就是 VM 和容器混用,即 Service Mesh 对服务的运行环境的支持,不仅支持容器(尤其指 Kubernetes),也支持虚拟机,而且支持运行在这两个环境下的服务相互访问,甚至直接在产品层面上屏蔽两者的差异。

比如 Google 的 Traffic Director 产品:
11.png

AWS 的 App Mesh产品:
12.png

都是在产品层面直接提供 VM 和容器混用的支持,不管应用是运行在 VM 上还是容器内都可以支持,而且可以方便的迁移。
##趋势 3:混合云和多云支持

混合云和多云支持最近正成为一个新的技术热点和商业模式,甚至 Google Cloud 都喊出口号,要 “All in Hybrid Cloud”!

Google Traffic Director 旗帜鲜明的表达了 Google Cloud 对混合云的重视:
13.png

下图是 Google Traffic Director 给出的一个应用改造示例:从单体结构转为微服务架构,从私有云转为公有云加私有云的混合云模式。
14.png

Service Mesh 毫无疑问是实现上述转型并提供混合云和多云支持的一个非常理想的解决方案。
##趋势 4:和 Serverless 的结合

Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术:

* Service Mesh 技术的关注点在于服务间通讯,其目标是剥离客户端 SDK,为应用减负,提供的能力主要包括安全性、路由、策略执行、流量管理等。
* Serverless 技术的关注点在于服务运维,目标是客户无需关注服务运维,提供服务实例的自动伸缩,以及按照实际使用付费。

理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方,可以结合使用。事实上目前业界也开始出现这个趋势,而融合的方式有两种:

  1. 在Serverless中引入Service Mesh:典型如 Knative 项目和 Knative 的 Google Cloud 托管版本 Google Cloud Run,通过引入对容器的支持和使用 Istio,Knative 将 Serverless 的支持扩展到 Function 之外,在极大的扩展 Serverless 适用范围的前提下,也将服务间通讯的能力引入到 Serverless。
  2. 在Service Mesh 中引入 Serverless:典型如 Google Traffic Director 产品,在提供 Service Mesh 各种能力的同时,支持按照流量自动伸缩服务的实例数量,从而融入了部分 Serverless 的特性。

对于 Serverless 和 Service Mesh 的结合,我们来展望未来形态:未来应该会出现一种新型服务模式,Serverless 和 Service Mesh 合二为一。只要将服务部署上来,就自动可以得到 Service Mesh 的服务间通讯能力和 Serverless 的无服务器运维。在蚂蚁金服,我们将这理解成为是未来云原生应用的终态之一,正在积极的探索其落地的实际方式。
15.png

##趋势 5:Mesh 模式延伸

回顾一下 Service Mesh 模式的核心,其基本原理在于将客户端 SDK 剥离,以 Proxy 独立进程运行;目标是将原来存在于 SDK 中的各种能力下沉,为应用减负,以帮助应用云原生化。

遵循这个思路,将 Service Mesh 的应用场景泛化,不局限于服务间的同步通信,就可以推广到更多的场景:特征是有网络访问,而是通过客户端 SDK 来实现。

在蚂蚁金服的实践中,我们发现 Mesh 模式不仅仅适用于服务间同步通讯,也可以延伸到以下场景:

* Database Mesh: 数据库访问
* Message Mesh:消息机制
* Cache Mesh:缓存

以上模式的产品蚂蚁金服都在探索中,相关的产品正在开发和尝试落地。社区也有一些相关的产品,比如 Database Mesh 方面张亮同学在力推的 Apache Shardingsphere 项目。

通过更多的 Mesh 模式,我们可以覆盖更多的场景,从而实现让应用在各个方面都做到减负,而不仅仅是 Service Mesh 对应的服务间通讯,从而为后续的应用云原生化奠定基础。
##趋势 6:标准化,不锁定

云原生的一个重要主张,就是希望在云上为用户提供一致的用户体验,提倡标准化,避免供应商绑定(Not Lock-In)。

从前面分享的 Service Mesh 产品动态可以看出,目前 Service Mesh 市场上出现了众多的供应商和产品:开源的,闭源的,大公司出的,小公司出的,市场繁荣的同时也带来了市场碎片化的问题——所有围绕业务应用的外围工作,比如通过 Service Mesh 对流量进行控制,配置各种安全/监控/策略等行为,以及在这些需求上建立起来的工具和生态系统,却不得不牢牢的绑死在某个具体的 Service Mesh 实现上,所谓”供应商锁定”。其根本问题在于各家实现不同,又没有统一标准。因此,要想解决上述问题,就必须釜底抽薪:解决 Service Mesh 的标准化问题。

就在最近这一个月,Service Mesh 社区出现了两个推动标准化的大事件:

  1. CNCF筹建 Universal Data Plane API (通用数据平面API)工作组,计划以 xDS v2 API 为基础制定数据平面的标准API,工作组的初始成员来自包括 Envoy 和 gRPC 项目的代表(可以理解为 Google 为首)
  2. 微软在 kubeconf 上推出 Service Mesh Interface,准备定义在 Kubernetes 上运行服务网格的规范,为 Service Mesh 带来了灵活性和互通性。SMI由微软牵头,联合 Linkerd,HashiCorp,Solo,Kinvolk 和Weaveworks。

为了方便理解这两个标准,我为大家准备了一张图:
16.png

其中,Universal Data Plane API 是数据平面的标准,控制平面通过这个 API 来控制数据平面的行为。而 Service Mesh Interface 是控制平面的标准,上层的应用/工具/生态体系通过 Service Mesh Interface 来实现跨不同的 Service Mesh 实现为最终用户提供一致性的体验。

当然这两个标准化 API 都刚刚起步,而且,标准化的工作通常不仅仅是技术问题,涉及到复杂的利益关系,具体未来走向现在难于推断,只能密切关注。
##发展趋势分析

我们总结一下上面列出的 Service Mesh 最近的6个发展趋势:
17.png

这些趋势都和云有关,核心在于让云来提供能力,包括:

* 让云承担更多职责
* 提供更高抽象
* 适用更多场景
* 减少应用负担:实现应用轻量化

最终实现让业务应用专注业务的战略目标。

对于 Service Mesh 技术未来的走向,我的看法是:Service Mesh 技术必然不是孤立的自行发展,而是在云原生的大环境下,与云原生的其他技术、理念、最佳实践一起相互影响、相互促进、相互支撑、共同发展。云原生是一个庞大的技术体系,Service Mesh 需要在这个体系中获得各种支撑和配合,才能最大限度的发挥自身的优势。
#Service Mesh与云原生

在最后一段,我们来谈谈 Service Mesh 技术和云原生的关系,也就是本次分享的标题所说的:云原生中流砥柱。

凭什么?
##什么是云原生?

在解释之前,首先问一个问题:什么是云原生?相信这个问题很多同学都问过,或者被问过,每个人心里可能都有自己的理解和表述。在今年年初,我也特意就这个问题问了自己,然后尝试着给出了一个我的答案:

云原生指 “原生为云设计”,具体说就是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。
18.png

关于云原生的理解,以及对这句话的详细阐述,这里不详细展开。
#Service Mesh的核心价值

关于 Service Mesh 的核心价值,我个人的理解,不在于 Service Mesh 提供的玲琅满目的各种功能和特性,而是:

实现业务逻辑和非业务逻辑的分离

将非业务逻辑的功能实现,从客户端 SDK 中剥离出来,放到独立的 Proxy 进程中,这是 Service Mesh 在技术实现上走出的第一步,也是至关重要的第一步:因为这一步,实现了业务逻辑和非业务逻辑的分离,而且是最彻底的物理分离,哪怕需要为此付出一次远程调用的代价。

而这一步迈出之后,前面就是海阔天空:

* 业务逻辑和非业务逻辑分离之后,我们就可以将这些非业务逻辑继续下沉
* 下沉到基础设施,基础设施可以是基于VM的,可以是基于容器和k8s的;也可以是VM和容器混合
* 基础设施也可以以云的形式提供,可以是公有云、私有云,也可以是混合云、多云;
* 可以选择云上托管,完全托管也好,部分托管也好,产品形态可以很灵活

总结说,业务逻辑和非业务逻辑的分离:

* 为下沉到基础设施提供可能
* 为上云提供可能
* 为应用轻量化提供可能

备注:这里说的上云,指的是上云原生(Cloud Native)的云,而不是上云就绪(Cloud Ready)的云。
##Mesh 化是云原生落地的关键步骤

在过去一年中,蚂蚁金服一直在努力探索云原生落地的方式,在这个过程中,我们有一些感悟,其中非常重要的一条就是:Mesh 化是云原生落地的关键步骤。
19.png

如上图所示:

* 最下方是云,基于 Kubernetes 和容器打造,提供各种基础能力,这些能力有一部分来自传统中间件的下沉
* 在云上是 Mesh 层,包含 Service Mesh 以及我们前面提到的各种扩展的 Mesh 模式,实现通信的标准化
* 在通过 Mesh 剥离非业务功能并下沉之后,应用实现了轻量化,传统的 App 和新兴的微服务都可以受益于此
* 更进一步,轻量化之后的业务应用,其工作负载在瘦身减负之后变得相当的干净,基本只剩业务逻辑,包括传统的 App,以 Container 形式运行的服务和新颖的 Function,这些负载在往 Serverless 形态转换时相对要轻松很多

配合 Serverless 技术领域最新的技术潮流和产品发展(如以 knative 项目为代表,Serverless 不再仅仅是 Function 形式,也支持 BaaS 等偏传统的工作负载),Mesh化为现有应用转型为 Serverless 模式提供助力。

在这里我们再分享一下蚂蚁金服对未来中间件产品发展的感悟,我们认为中间件的未来在于 Mesh 化,并融入基础设施,如下图所示:
20.png

左边是传统的中间件形态,在云原生时代,我们希望将非业务功能从传统中间件的富客户端中剥离出来,然后将这些能力以及这些能力背后的中间件能力,下沉到基础设施,下沉到云。而中间件产品也会融入基础设施,如图中右边所示。未来的中间件将作为基础设施和云的一部分,而 Mesh 则成为连接应用和基础设施以及其他中间件产品的桥梁。

更重要的是:业务应用因此而实现轻量化,在剥离各种非业务功能之后,业务应用就实现了只关注业务逻辑的战略目标,从而实现从传统应用到云原生应用的转型。

总结:通过 Service Mesh 技术,我们实现了业务逻辑和非业务逻辑的分离,为应用的轻量化和云原生化提供可能;并通过将非业务逻辑的各种功能下沉到基础设施和云,极大的增强了基础设施和云的能力,为云原生的落地提供了极大助力。

因此,我们认为: Service Mesh 技术将在云原生落地中扮演了非常重要的作用,不可或缺。
##Service Mesh发展展望

最后再次展望一下 Service Mesh 的未来发展。

左边是 Service Mesh 发展初期的最重要的两个原始动力:多语言支持和类库升级。关于这两点,最近这两年中介绍和推广 Service Mesh 理念和产品的同学基本都讲过,但是今天我想指出的是:这只是 Service Mesh 的起点,而远不是 Service Mesh 的终点。

Service Mesh 的未来,不会停留在仅仅满足多语言支持和类库升级,而是跟随云原生的大潮,解决各种实际需求,同时又尽量维持上层业务应用的简单直白。
21.png

在这次分享的最后,我想给大家一个留一个课外作业,有心的同学可以尝试一下:如果您想更深入的理解 Service Mesh 的价值,想对 Service Mesh 未来的发展方向有更清晰的认识,尤其是希望能通过自身的思考和感悟来理解 Service Mesh 而不是简单的被灌输(包括被我灌输),那么请尝试独立的做如下思考:

  1. 抛开左边的这两点,不要将思维局限在这个范围内
  2. 考虑云原生的大背景,结合您自身对云原生的理解,和对云的期望
  3. 针对右边的 Service Mesh 的六个趋势,忘记我前面讲述的内容,只考虑其背后的实际场景和客户需求,以及这个场景带来的业务价值,然后认真对比使用 Service Mesh 和不使用 Service Mesh 两种情况下的解决方案
  4. 请在上述思考的过程中,更多的从业务应用的角度来看待问题,假设你是那个云上的应用(还记得前面图上的小 baby 吗?),你会希望被如何对待

希望这样的思考能让您有所收获。

原文链接:https://skyao.io/talk/201905-servicemesh-development-trend/

你好,SMI:Service Mesh 互操作性说明书

YiGagyeong 发表了文章 • 0 个评论 • 264 次浏览 • 2019-05-27 23:36 • 来自相关话题

【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为 Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。 今 ...查看全部
【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为
Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。

今天,我们兴奋地发布了 `Service Mesh Interface(SMI)`,它定义了一组通用的可移植 API,为开发人员提供跨不同 Service Mesh(服务网格)技术的互操作性,其中包括 Istio,Linkerd 和 Consul Connect。SMI 是一个与微软,Linkerd,HashiCorp,Solo.io,Kinvolk 和 Weaveworks 合作开展的开放项目;同样也得到了 Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat 和 VMware 的支持。

多年来,网络架构的真言是让网络管道尽可能愚蠢,并在应用中构建智能。网络的职责是转发数据包,而任何关于加密,压缩或身份的逻辑则存在于网络端点内。互联网是以此真言为前提的,所以你会觉得它可以运转良好。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

但是,如今随着微服务、容器以及编排系统如 `Kubernetes` 的爆炸式增长,工程团队将要保障、管理和监控越来越多的网络端点。Service Mesh 技术通过使网络更加智能,来解决上述问题。Service Mesh 技术不是教授所有服务来加密会话,授权客户端,发出合理的遥测,并在应用程序版本之间无缝转换流量,而是将此逻辑推入网络,由一组单独的管理 API 控制。

这是 `cloud-native` 系统中比较流行的模式。我们发现,随着许多供应商为应用开发人员提供了令人兴奋的新选择,Service Mesh 技术也随之激增。问题是,转向 Service Mesh 的开发人员必须选择一个供应商,并直接对接其 API。他们被束缚在了某种 Service Mesh 的实现中。如果没有通用接口,开发人员就会失去可移植性以及灵活性,并且从广泛的生态系统中获益的能力也会受限。

SMI 提供了如下功能:

  • Kubernetes 网格的标准界面
  • 最常见的网格用例的基本功能集
  • 随着时间的推移灵活地支持新的网格功能
  • 为生态系统提供利用网格技术进行创新的空间
# SMI 覆盖了哪些功能我们与 HashiCorp,Buoyant,Solo.io 以及其他公司合作,为企业级客户所希冀的三大 Service Mesh 功能构建初始规范:[list=1]
  • 流量策略:应用跨服务应用身份和传输加密等策略
  • 流量遥测:捕获关键指标,如错误率和服务之间的延迟
  • 流量管理:在不同服务之间转移和加权流量

  • 这些只是我们希望通过 SMI 初步实现的功能。由于开发过程中有许多令人兴奋的网格功能,我们完全希望随着时间的推移,不断发展 SMI API,并期待通过新功能扩展当前规范。
    # SMI是如何工作的
    Service Mesh Interface 背后的观点并非新创。它追寻 Ingress,Network Policy 和 CNI 等现有 Kubernetes 资源的足迹。与 Ingress 或 Network Policy 一样,SMI 不提供具体实现。相反,SMI 规范定义了一组通用 API,允许网格提供者提供自己的最佳实现。与 SMI 集成可以通过两种方式实现,工具和网格提供者可以直接使用SMI API,也可以构建运算符将 SMI 转换为原生 API。

    SMI 是 Linkerd 迈向 Service Mesh 大众化的一大步,我们很高兴能够向更多的 Kubernetes 用户提供简洁和易用的 Linker 服务。
    > ——William Morgan,Linkerd 维护者



    对于跨技术和生态系统协作来说,接口的标准化对确保最佳用户体验至关重要。凭借这种精神,我们很高兴能与微软和其他公司合作开发 SMI 规范,并已经通过 Service Mesh Hub 和 SuperGloo 项目提供了首个参考实现。
    > ——Solo.io 创始人兼首席执行官,Idit Levine。



    # 生态系统友好
    对于 Service Mesh 等早期技术,我们必须为其生态系统创造创新空间,并探索解决客户问题的不同方法。随着 service mesh 技术的不断发展,SMI 提供的互操作性将有助于新兴工具和实用程序与现有网格供应商集成,而不是单独集成每个网格,像 flagger 和 SuperGloo 这样的工具就可以与 SMI 集成,从而获得跨网格功能。

    “Service Mesh 的兴趣和动力已达到了行业需要在一系列标准上进行协作的程度,这些标准可以帮助确保他们的成功。”VMware 服务网络首席架构师 Sushil Singh 表示,“Service Meshe 为应用程序的未来提供了丰富的基础功能。现在是制定标准 API 的最佳时机,这些 API 可以简化 Service Mesh 技术的消耗和功能,从而实现健康的生态系统。VMware 很高兴参与这项非常重要的工作。“



    客户和社区成员都在寻求一种方法来更好地标准化 Service Mesh 的配置和操作。随着 Service Mesh Interface(SMI)的出现,我们认为这是一种可以帮助我们最大化 Red Hat OpenShift 客户选择和灵活性的方法。这种灵活性使用户能够优先考虑实现细节的功能。
    > ——Brian Redbeard Harrington,Red Hat Service Mesh 首席产品经理



    原文链接:Hello Service Mesh Interface (SMI): A specification for service mesh interoperability (翻译:李加庆

    容器、微服务与服务网格

    cleverlzc 发表了文章 • 0 个评论 • 286 次浏览 • 2019-05-26 11:03 • 来自相关话题

    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给 ...查看全部
    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给出了自己的见解。

    如你所知,已经有很多关于服务网格的资料(1234),但这是另外一篇。是的!但是为什么会有这篇文章呢?因为我想给你们一些不同的视角,他们希望服务网格在10年前就已经存在,远早于Docker和Kubernetes这样的容器平台的兴起。我并不是说这个视角比其他视角更好或更差,但是由于服务网格是相当复杂的“野兽”,所以我相信多种视角有助于更好地理解它们。

    我将讨论dotCloud平台,这是一个建立在100多个微服务之上的平台,支持数千个运行在容器中的生产应用程序;我将解释在构建和运行它时所面临的挑战;以及服务网格会(或不会)提供帮助。
    # dotCloud的历史
    我已经写过关于dotCloud平台的历史和它的一些设计选择,但是我没有过多地讨论它的网络层。如果你不想深入了解我之前关于dotCloud的博客,你需要知道的是它是一个PaaS,允许客户运行各种应用程序(Java、PHP、Python等),支持广泛的数据服务(MongoDB、MySQL、Redis等)以及类似于Heroku的工作流程:你可以将代码推送到平台,平台将构建容器映像,并部署这些容器映像。

    我将告诉你流量是如何在dotCloud平台上路由的;不是因为它是特别棒或其他什么(我认为现在是比较合适的时间),但主要是因为,如果一个普通的团队需要一种在一个微服务群或一个应用程序群之间路由流量的方法,那么这种设计可以在短时间内用现在已有的工具轻松实现。因此,它将为我们提供一个很好的比较点,“如果我们破解它,我们会得到什么”和“如果我们使用现有的服务网格,我们会得到什么”,也就是老生常谈的“构建与购买”的困境。
    # 托管应用的流量路由
    部署在dotCloud上的应用程序会暴露HTTP和TCP端点。

    HTTP端点被动态地添加到Hipache负载平衡器集群的配置中。这与我们今天使用Kubernetes Ingress资源和Traefik这样的负载平衡器可以实现的功能类似。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    只要域名指向dotCloud的负载平衡器,客户端就可以使用它们的关联域名连接到HTTP端点。这里没有什么特别的。

    TCP端点与端口号相关联,然后端口号通过环境变量与该堆栈上的所有容器通信。

    客户端可以使用指定的主机名(类似于gateway-X.dotcloud.com)和端口号连接到TCP端点。

    该主机名将解析为一个“nats”服务器集群(与NATS没有任何关系),该集群将把传入的TCP连接路由到正确的容器(或者,在负载平衡服务的情况下,路由到正确的容器)。

    如果你熟悉Kubernetes,这可能会让你想起NodePort服务。

    dotCloud平台没有集群IP服务的等价物:为了简单起见,从内部和外部访问服务的方式是相同的。

    这非常简单,最初的HTTP和TCP路由网格的实现可能都是几百行Python代码,使用相当简单(我敢说,很天真)的算法,但是随着时间的推移,它们不断发展,以处理平台的增长和额外的需求。

    它不需要对现有应用程序代码进行大量重构。十二因素应用程序尤其可以直接使用通过环境变量提供的地址信息。
    # 它与现代服务网络有何不同?
    可观察性有限。对于TCP路由网格根本没有度量标准。至于HTTP路由网格,后来的版本提供了详细的HTTP度量,显示错误状态码和响应时间;但是现代服务网格的功能远远不止于此,它还提供了与度量收集系统(例如Prometheus)的集成。

    可观察性非常重要,不仅从操作角度(帮助我们解决问题),还可以提供安全的蓝/绿部署金丝雀部署等功能。

    路由效率也受到限制。在dotCloud路由网格中,所有流量都必须经过一组专用路由节点。这意味着可能跨越几个AZ(可用性区域)边界,并显著增加延迟。我记得对一些代码进行故障排除,这些代码发出100多个SQL请求来显示给定的页面,并为每个请求打开了到SQL服务器的新连接。在本地运行时,页面会立即加载,但在dotCloud上运行时,需要几秒钟,因为每个TCP连接(以及随后的SQL请求)都需要几十毫秒才能完成。在这种特定的情况下,使用持久连接起了作用。

    现代服务网络做得更好。首先,通过确保连接在源位置路由。逻辑流仍然是客户端-->网格-->服务,但是现在网格在本地运行,而不是在远程节点上运行,因此客户端-->网格连接是本地连接,因此速度非常快(微秒而不是毫秒)。

    现代服务网格还实现了更智能的负载平衡算法。通过监控后端的运行及健康状况,它们可以在更快的后端上发送更多的流量,从而提高整体性能。

    随着现代服务网络的出现,安全性也越来越强。dotCloud路由网格完全在EC2 Classic上运行,并且没有加密流量(假设如果有人设法嗅探EC2上的网络流量,那么无论如何都会遇到更大的问题)。现代服务网格可以透明地保护我们所有的通信,例如通过相互的TLS身份验证和随后的加密。
    # 平台服务的流量路由
    OK,我们已经讨论了应用程序是如何通信的,但是dotCloud平台本身呢?

    平台本身由大约100个微服务组成,负责各种功能。其中一些服务接受来自其他服务的请求,而其中一些服务是后台工作应用,它们将连接到其他服务,但不能自己接收连接。无论哪种方式,每个服务都需要知道它需要连接到的地址的端点。

    许多高级服务都可以使用上面描述的路由网格。事实上,dotCloud平台的100多个微服务中有很大一部分是作为常规应用程序部署在dotCloud平台上的。但是少数低级服务(特别是那些实现路由网格的服务)需要一些更简单的东西,需要更少的依赖关系(因为它们不能依靠自己来运行;这是一个老生常谈的“先有鸡还是先有蛋”的问题)。

    通过直接在几个关键节点上启动容器,而不是依赖于平台的构建器、调度程序和运行器服务,部署了这些底层的基本平台服务。如果你想要与现代容器平台进行比较,这就像直接在节点上运行Docker来启动我们的控制平面,而不是让Kubernetes为我们做这件事。这与kubeadmbootkube在引导自托管集群时使用的静态Pod的概念非常相似。

    这些服务以一种非常简单和粗糙的方式被公开:有一个YAML文件列出了这些服务,将它们的名称映射到它们的地址;作为其部署的一部分,这些服务的每个使用者都需要一份该YAML文件的副本。

    一方面,这是非常强大的,因为它不涉及像ZooKeeper那样维护外部键值存储(记住,etcd或Consul在那个时候不存在)。另一方面,这使得服务难以移动。每次移动服务时,它的所有消费者都需要接收更新的YAML文件(并且可能会重新启动)。不太方便!

    我们开始实现的解决方案是让每个消费者都连接到一个本地代理。使用者不需要知道服务的完整地址+端口,只需要知道它的端口号,并通过localhost进行连接。本地代理将处理该连接,并将其路由到实际后端。现在,当一个后端需要移动到另一台机器上,或按比例放大或缩小,而不是更新它的所有消费者,我们只需要更新所有这些本地代理;我们不再需要重新启动消费者。

    (还计划将流量封装在TLS连接中,并在接收端使用另一个代理来打开TLS并验证证书,而不涉及接收服务,该服务将被设置为仅在本地主机上接受连接。稍后会详细介绍。)

    这与AirBNB的SmartStack非常相似;与SmartStack实现并部署到生产环境的显著区别是,当dotCloud转向Docker时,它的新的内部路由网格被搁置了。

    我个人认为SmartStack是诸如Istio、Linkerd、Consul Connect等系统的先驱之一,因为所有这些系统都遵循这种模式:

    • 在每个节点上运行代理
    • 消费者连接到代理
    • 后端改变时,控制平面更新代理的配置
    # 今天实现一个服务网格如果我们今天必须实现类似的网格,我们可以使用类似的原则。例如,我们可以设置一个内部域名系统区域,将服务名映射到127.0.0.0/8空间中的地址。然后在集群的每个节点上运行HAProxy,接受每个服务地址(在127.0.0.0/8子网中)上的连接,并将它们转发/负载平衡到适当的后端。HAProxy配置可以由confd管理,允许在etcd或Consul中存储后端信息,并在需要时自动将更新的配置推送到HAProxy。这就是Istio的工作原理!但是有一些不同之处:
    • 它使用Envoy Proxy而不是HAProxy
    • 它使用Kubernetes API而不是etcd或Consul来存储后端配置
    • 服务在内部子网中分配地址(Kubernetes集群IP地址),而不是127.0.0.0/8
    • 它有一个额外的组件(Citadel),用于在客户机和服务器之间添加相互的TLS身份验证
    • 它增加了对诸如断路、分布式跟踪、金丝雀部署等新特性的支持

    让我们快速回顾一下这些差异。
    ## Envoy Proxy
    Envoy Proxy由Lyft撰写。它与其他代理(如HAProxy、NGINX、Traefik)有许多相似之处,但Lyft编写它是因为它们需要当时这些代理中不存在的功能,而且构建一个新的代理比扩展现有代理更有意义。

    Envoy可以单独使用。如果有一组给定的服务需要连接到其他服务,可以把它连接到Envoy,然后动态地配置和重新配置其他服务的Envoy的位置,而得到很多漂亮的额外的功能,比如域的可观测性。这里,没有使用定制的客户端库,也没有在代码中添加跟踪调用,而是将流量定向到Envoy,让它为我收集指标。

    但Envoy也可以用作服务网格的数据平面。这意味着现在将由该服务网格的控制平面配置Envoy。
    ## 控制平面
    说到控制平面,Istio依赖于Kubernetes API。这与使用confd没有太大的不同。confd依赖etcd或Consul来监视数据存储中的一组密钥。Istio依赖Kubernetes API来监视一组Kubernetes资源。

    Aparte:我个人认为阅读Kubernetes API描述非常有帮助。

    Kubernetes API服务器是一个“哑服务器”,它提供API资源上的存储、版本控制、验证、更新和监视语义。



    Istio是为与Kubernetes合作而设计的;如果你想在Kubernetes之外使用它,则需要运行Kubernetes API服务器的实例(以及支持的etcd服务)。
    ## 服务地址
    Istio依赖Kubernetes分配的集群IP地址,因此Istio得到一个内部地址(不在127.0.0.1/8范围)。

    在没有Istio的Kubernetes集群上,前往给定服务的ClusterIP地址的流量被kube-proxy拦截,并发送到该代理的后端。更具体地说,如果你想确定技术细节:kube-proxy设置iptables规则(或IPVS负载平衡器,取决于它是如何设置的)来重写连接到集群IP地址的目标IP地址。

    一旦Istio安装在Kubernetes集群上,就不会发生任何变化,直到通过将sidecar容器注入到使用者Pod中,显式地为给定的使用者甚至整个名称空间启用Istio。sidecar将运行一个Envoy实例,并设置一些iptables规则来拦截到其他服务的流量,并将这些流量重定向到Envoy。

    结合Kubernetes DNS集成,这意味着我们的代码可以连接到一个服务名,一切都可以正常工作。换句话说,比如我们的代码向`http://api/v1/users/4242`发起一个请求,`api`将解析到10.97.105.48,一条iptables规则将解释连接到10.97.105.48并重定向到本地Envoy代理,本地代理将这个请求路由到实际的API后端。
    ## 额外的铃声和哨声
    Istio还可以通过名为Citadel的组件通过mTLS(双向TLS)提供端到端加密和身份验证。

    它还包括混合器,Envoy组件可以查询每一个请求,对请求进行一个临时的决定取决于各种因素,例如请求头、后端负载(别担心,有丰富的规定以确保混合高度可用,即使它休息,Envoy可以继续代理流量)。

    当然,我提到了可观察性。Envoy在提供分布式跟踪的同时收集大量的度量指标。微服务架构,如果单个API请求必须经过微服务A、B、C和D,分布式跟踪将添加一个惟一的标识符请求进入系统,并保留标识符在子请求中,所有这些微服务允许收集所有相关的调用、延迟等。
    # 自建还是购买
    Istio以复杂著称。相比之下,使用我们今天拥有的工具,构建像我在本文开头描述的那样的路由网格相对比较简单。那么,构建我们自己的服务网格是否有意义呢?

    如果我们有适度的需求(如果我们不需要可观察性,断路器,和其他细节),我们可能想建立自己的。但是如果我们正在使用Kubernetes,我们甚至可能不需要这样做,因为Kubernetes已经提供了基本的服务发现和负载平衡。

    现在,如果我们有高级的需求,购买服务网格可能是一个更好的选择。(由于Istio是开源的,所以它并不总是真正的购买,但是我们仍然需要投入工程时间来理解它是如何工作、部署和运行的。)
    #如何选择Istio、Linkerd和Consul Connect
    到目前为止,我们只讨论了Istio,但它并不是唯一的服务网格。Linkerd是另一个流行的选择,还有Consul Connect

    我们应该选哪一个呢?

    实际上在这一点上我也不好说,我不认为我有足够的了解能够帮助任何人做决策。不过,已经有一些有趣的文章比较它们(12),甚至基准测试

    一种值得一提并且很有潜力的方法是使用像SuperGloo这样的工具。SuperGloo提供了一个抽象层来简化和统一服务网格公开的API。我们可以使用SuperGloo提供的更简单的构造,并无缝地从一个服务网格切换到另一个服务网格,而不是学习各种服务网格的特定API(在我看来,相对复杂)。有点像我们有一个描述HTTP前端和后端的中间配置格式,能够为NGINX、HAProxy、Traefik、Apache生成实际配置

    我已经使用SuperGloo稍微涉足Istio,在未来的博客文章中,我想说明如何使用SuperGloo将Isio或Linkerd添加到现有的集群中,以及后者是否能实现它的承诺,即允许我在不重写配置的情况下从一个路由网格切换到另一个。

    如果你喜欢这篇文章,并且想让我尝试一些具体的场景,我很乐意听到你的消息!

    原文链接:Containers, microservices, and service meshes

    译者:Mr.lzc,软件研发工程师、DevOpsDays深圳组织者&志愿者,目前供职于华为,从事云存储工作,以Cloud Native方式构建云文件系统服务,专注于K8s、微服务领域。

    基于Kubernetes的服务网格简介

    JetLee 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-23 13:51 • 来自相关话题

    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只 ...查看全部
    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只对内部网络开放,然而对于现在流行的应用来说,这并不够。API通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做API版本化,做金丝雀部署,观察并记录每一个请求。这就引入了服务网格。无论你用Linkerd或是Istio,原理上都是一样的。如果你想和更多Service Mesh技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #为什么要用服务网格?

    服务网格并不是和Kubernetes一起出现。然而,因为有Kubernetes,服务网格更容易被引入到你的环境中。有两个逻辑组件组成了服务网格。我们已经有了pod用于承载各个容器。Sidecar是另一个绝好的例子用于扩展和加强pod里面的主要容器。在服务网格语境里,sidecar是服务代理或者数据平面。

    服务网格是云原生的核心组件

    为了更好的理解服务网格,你需要理解代理和反向代理这两个术语。代理,用一句话说,用于接收流量并中转到其它地方。反向代理,从各个地方接收流量并转交给各个服务。这种情况下,所有的客户只和一个代理实例交流。把数据平面想象为一个反向代理。Ingress也是Kubernetes里面用于暴露服务的反向代理。Ingress可以中止SSL,提供基于名称的路由,并且它主要就干这个事情。对于Kubernetes服务也是一样。如果你需要更复杂的路由该怎么做呢?

    下面列举一些其它服务网格可以做的事情:

    * 负载均衡
    * 精细流量策略
    * 服务发现
    * 服务监控
    * 追踪
    * 路由
    * 服务与服务的安全通信

    不仅有sidecar代理,所有的服务网格解决方案还包含控制器,用于定义sidecar容器应该如何工作。服务网格的控制平面是一个集中的、管理所有的服务网格和服务代理的地方。这个控制面板记录网络信息,所以它也是一个网络监控工具。

    所以,为什么要用服务网格?答案很简单,你可以做上面的任何事情并且不需要修改代码。它能够节省时间与金钱。不仅如此,更重要的是,你不能跳过测试,因为它对于初学者太复杂。甚至你可以通过Istio故障注入模拟不同的场景,来测试系统对于失败的反应。
    #Linkerd2与Istio

    在一开始,我提到过两个在Kubernetes上创建服务网格的著名的解决方案。未来也许还会有其它更多的解决方案。每一个产品都试图用自己的方式解决问题,相互之间肯定会有重复的地方。

    Buoyant,这家公司创造了Linkerd,同时还创造了Conduit服务。近期,Conduit被合并到Linkerd项目,称作Linkerd2。buoyant团队把Linkerd服务网格变成了一个更加通用的解决方案。它用Java编写,这意味着它很重。每一个pod会有一个或更多的容器,一个sidecar。Linkerd2设计应用于Kubernetes。它的开发语言包含Go-控制平面,和Rust-一个原生的服务代理,超级轻量、快速并安全。你可以定义重试和超时,定义编排规则,以及加密(TLS),同时还支持根据策略通过或拒绝请求。不仅如此,它还有一个很漂亮的控制台:
    1.png

    Linkerd2_dashboard

    如果你喜欢控制台的话也可以用Linkerd CLI。

    Linkerd的入门向导非常不错,你可以试一试。如果想学习更多,可以看看它的官方文档。

    Istio当前支持Kubernetes和Nomad,将来会添加更多的功能。Istio是一个多平台解决方案。它可以做微服务流量管理,策略应用以及聚合采样信息。Istio也是Go语言编写的轻量应用,但不同于Linkerd2,它使用Envoy来做服务代理。下图说明Istio中各个部分是如何组合工作的:
    2.png

    Istio_architecture

    我喜欢Istio的其中一点是sidecar自动注入,前提是你已经使用Helm来发布应用,这样的话就不需要手工把sidecar注入到kubernetes的配置文件里面。

    在Kubernetes上安装Istio请参考这篇快速指南。其它关于Istio的信息,请参考它的官方文档。

    这两个产品都是开源的。无论哪一个服务网格方式适合你,它们两个都很容易上手实验。不超过5分钟就可以把它跑起来。我鼓励你都去试一试然后再做决定。目前阶段Istio实现的功能比Linkerd2多了很多,并且也是一个稳定版本。
    #总结

    我希望这篇文章很好的介绍了服务网格。这篇文章并不是Linkerd2和Istio之间的比较。我列举了一些功能点,这样你可以了解一下服务网格给Kubernetes带来了什么。请继续关注我们的后续文章。

    原文链接:https://mp.weixin.qq.com/s/6EvdlPbx3NRekG6_BCCNmA

    Service Mesh 的本质、价值和应用探索

    翔宇 发表了文章 • 0 个评论 • 207 次浏览 • 2019-05-22 21:44 • 来自相关话题

    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 ...查看全部
    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。

    网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家至简和他的团队在这一领域探索的过程中想清楚了这两点。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #大规模分布式应用的挑战
    微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。

    在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演进所增加的特性并不是某些业务方所需要的时,这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本,使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

    当微服务框架是单一编程语言独大(Java 在阿里巴巴就是这样的)、不能同步支持好其他多个主流编程语言时(比如 C++、Go、Node.js 等), 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的,最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率,但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护,同样的特性需要用不同的编程语言去实现其成本着实很高。

    也许在企业内部统一单一的主流编程语言并不会带来什么劣势,但当企业需要通过收购其他公司来扩充自己的商业版图时就很可能面临技术栈不统一而带来业务无法低风险、高效率共存演进的挑战。当碰到母子公司的技术栈不统一时,在被收购子公司中进行推倒重建基本上是一件业务价值不大的劳命伤财之事。

    最后,在微服务软件架构所主张的拆分手法下,确实可以将每个拆分出来的服务从监管控层面做到足够的精致,但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同,最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。

    不难想象,采取强有力的团队组织形式、技术规范等手段是很难解决以上挑战的。回归通过技术途径去解决技术挑战才更为有力、有效,这正是 Service Mesh 这一技术可以帮助做好的。
    #Service Mesh 的形态
    Service Mesh 的核心思路与微服务软件架构的思路是一脉相承的,即通过拆分实现解耦——将 SDK 中频繁变更的逻辑与业务逻辑分别放到不同的进程中。下图以 RPC 框架为例示例了这一手法。
    1.jpg

    拆分之后,服务调用的流量通过技术手段以应用无感的形式导入 sidecar 进程。每个服务进程边上新增的 sidecar 使得完整的服务调用链中客户端和服务端分别增加了一跳,这是享受 Service Mesh 技术所需付出的成本。
    #Service Mesh 的挑战
    2.jpg

    第一个挑战来自心智模式需要改变。享受 Service Mesh 所带来的益处是需要付出成本的,这如同单体应用向微服务软件架构转变那样,核心是成本与收益问题。之所以业内仍有不少人纠结于 Service Mesh 的价值,根本原因在于企业的业务规模是否面临 Service Mesh 所致力于解决的那些挑战,如果没有则采纳 Service Mesh 只带来更高的成本而没有收益。

    对于那些服务规模还小的企业,确实没有必要引入尚处于探索和普及阶段的 Service Mesh 的必要。他们可以持续关注业务发展与技术的匹配,在合适的时间点去拥抱新技术。

    第二个挑战来自于技术层面,即如何做到增加 sidecar 后的“路径无损”。具体说来,如何在引入 Service Mesh 的情形下,最大可能地不增加服务的调用延时和消耗更多的 CPU 资源。这是未来需要持续去突破的技术方向。可以预见,突破的途径无外乎“应用层 + 内核层”或“软件 + 硬件”。
    #Service Mesh 的本质
    3.jpg

    无疑,技术发展是服务于业务价值创造的。在单体应用时代,因为软件规模、业务复杂度和参与人员数量的持续增大,使得软件开发和迭代工作因为耦合而举步为艰,这就有了微服务软件架构的出现。那时的业务发展效率问题集中体现于人员协同,在微服务软件架构的需要下产生了 RPC、Messaging 等技术。

    当人员的协同问题通过微服务软件架构得以解决时,随着软件规模、业务复杂度和参与人员数量的进一步增大,需要更好地解决多个业务(或服务)之间的协同问题,而这是 Service Mesh 这一技术的本质。
    #Service Mesh 的价值
    4.jpg

    在 Service Mesh 的形态下,RPC 框架中容易变更的内容被剥离到了 sidecar 进程,之前的胖 SDK 瘦身为只保留了功能恒定的协议编解码能力。如此一来,与 RPC 框架演进相关的逻辑几乎集中在 sidecar 进程中,这就完全可以做到让使用 RPC 框架的业务方无感知地对之进行升级与维护。最终的结果是,业务与 RPC 框架可以做到独立发展与升级,完全消除了之前胖 SDK 所导致的两者相互制约发展的不利局面。这一解耦所带来的好处是,使用 RPC 框架的业务团队可以更加聚焦于业务开发本身,这正是发挥技术价值应达到的境界。

    不难看出,Service Mesh 很好地解决了以往 RPC 框架多语言 SDK 的问题。虽然在 Service Mesh 下仍然需要 SDK,但由于 SDK 中的功能是相当稳定的,不存在应付频繁变更所带来的长期维护成本问题。由于 sidecar 是以进程的形式存在的,因此完全不关心使用 RPC 框架的业务逻辑是用什么编程语言实现的,只需实现一次而没有让人感到无聊的多语言特性对齐问题,将 RPC 框架技术团队的人力释放出来做更有价值的事。

    也因为 sidecar 是以独立进程的形式存在,当出现因为公司收购所面临的母子公司技术栈不一致问题时,可以将 sidecar 部署在两个技术栈的衔接处,由 sidecar 通过协议转换等形式完成两个异构服务框架的连接,为异构服务框架的渐进式融合发展提供了可能,很好地缓解了短期高强度技术改造所面临的技术风险和对业务发展的拖累。

    服务框架易变的功能剥离到了 sidecar 后,意味全网的服务流量治理能力可以通过 sidecar 进行收口——sidecar 自身的版本全网一致、流量规则与执行策略一致、监控口径一致,等等。诸多的“一致”将实现全网服务治理的体系化监管控,使得 Service Mesh 成为微服务软件架构拆分手法下完成横向连接与约束的强有力技术手段。

    如果用一句话来描述 Service Mesh 的话,那就是“层次化、规范化、体系化、无侵入的分布式服务(或应用)治理技术”。
    #Service Mesh 的终局
    5.jpg

    延着 Service Mesh 的切分逻辑,不难预见未来 Service Mesh 所形成的终局是一张大网。这个大网是企业统一且唯一的分布式应用治理的基础设施,其上天然地支持多语言应用的开发。当然,sidecar 是包罗万象地支持 RPC、DB、Messaging,还是衍生出 RPC sidecar、DB sidecar、Messaging sidecar 是仍需探索的主题。
    #Service Mesh 的发展路径
    6.jpg

    新技术诞生于逻辑上能解决当下所面临的技术或业务挑战,但能否真正落地去最大程度地发挥价值却具有不确定性和模糊性。正因如此,不少新技术出现之时存在各种基于自身立场去解读和挖掘其背后的价值,当然也不乏各种质疑之声。所有这一切让业内对挑战看得更加透彻,对新技术的探索也愈加高效。

    根本上,Service Mesh 的出现并非填补了技术空白,不少公司因为曾经有过相似的探索而给人“换汤不换药”的感觉,与今天时兴的云计算在十几、二十年前被称之为分布式计算、网格计算颇有相似之处。当一项新技术不是给人横空出世的感觉时,它的运用与采纳就会经历更多的波折,因为没有它似乎企业的业务发展仍能进行下去。

    在经历了一定的思考和市场感知后,发现 Service Mesh 真正发挥价值是需要分布式应用大到一定的规模并面临一开始所提出的那些挑战,这些在阿里巴巴集团内部都满足。最终我将 Service Mesh 的发展划分成三大阶段。

    阶段一:撬动。新技术被采纳的关键是它能解决业务当下所面临的痛点,阿里巴巴因为 Java 语言一家独大而使得多语言问题相当突出,这使得小众的编程语言乐于拥抱 Service Mesh 去解决自己维护 SDK 或 SDK 特性老旧的痛点。此外,阿里巴巴不时通过收购子公司扩大自己的商业版图,确实经历了异构服务架构共存演进所带来的挑战。

    撬动阶段让新技术得以落地而接触到更多的业务机会并争取到打磨技术的时间窗口,让 Service Mesh 技术团队对于需求的理解和把控更加到位。为进入下一发展阶段提供可能。

    阶段二:做透价值渗透。光解决多语言和异构服务架构共存演进并不足以实现大范围的体系化监管控,需要围绕集团内部更为丰富的业务场景去挖掘 Service Mesh 的价值,并在探索的过程中寻求技术突破去降低引入 Service Mesh 的成本。当分布式应用的体量特别大时,成本问题将变得备受关注。一旦 Service Mesh 的价值得以做透,还得考虑无缝迁移等用户体验使之得以更为方便地应用到更多的业务场景。

    阶段三:实现技术换代。分布式应用的全局、体系化监管控一定是未来云原生时代的强诉求。进入这一阶段代表技术进入了更高层次的集约发展时期,是偿还过去“跑马圈地”和“野蛮生长”所欠下技术债的重大里程碑。在这一阶段,Service Mesh 将成为企业所有分布式应用的基础设施,通过这一设施强有力地执行流量灰度、流量调度去保障业务的持续性,让安全、稳定性问题得以采用一致性、系统性的方案解决。“生长”在 Service Mesh 之上的所有业务完全可以根据团队的技术栈特长以更为经济和高效的方式去发展和探索。
    #Service Mesh 的发展思路
    7.jpg

    Dubbo Mesh 是 Service Mesh 在 Dubbo 生态下的落脚点。其发展不仅立足于在阿里巴巴集团遗留应用场景的包并兼容,还将迎合 Kubernetes 已成计算资源编排王者的大势,让 Service Mesh 在未来以 Kubernetes Way 去提供概念一致、体验一致的技术产品。

    整个 Service Mesh 的发展与探索将走“源于开源,反哺开源,集团内外版本一致”的思路。希望探索之路少走弯路、与更多的同行携手前行,成为开源社区的一名积极建设者。

    最终的技术选型是采用 Istio 的部分组件(Dubbo Control 控制面)和 Envoy(Dubbo Proxy 数据面)形成阿里巴巴自己的解决方案。Istio 中的 pilot-discovery 对于平台的抽象便于扩展支持阿里巴巴最近开源出来的 Nacos 而方便落地,同时为将来集团全面的 Kubernetes 化做好准备。Envoy 的性能与软件质量在很多生产环境上得到了检验,而采用 C++ 能从性能上得到很好的保证,避免有些语言存在 GC(垃圾回收)而带来的不确定性,也便于将来应用层与 OS 层、软件与硬件的结合发展。
    #Service Mesh 的进展
    8.jpg

    目前 Dubbo Proxy 完成了 Dubbo 服务调用统计信息收集的开发工作,这部分代码已合入了 GitHub 上 Envoy 仓库的 master 主干。Dubbo Proxy 全面支持 Dubbo 服务路由的工作正在进行,相信很快这部分代码将出现在开源社区。

    在阿里巴巴集团内部,为了快速落地已经完成 Dubbo over HTTP 技术方案的开发,目前已在两个多语言场景业务方的环境中完成部署并开始着手性能测试和调优工作。内部落地方案中,需要考虑通过 Nacos 与集团内部的 VIPServer、ConfigServer 集群进行对接去完成服务发现,这些对接工作开源社区无需关注,因为开源的 Nacos 已包含阿里集团内部的服务注册与发现和配置管理能力。

    值得一提,pilot-discovery 目前并非集群化部署,而是与 Dubbo Proxy 一样进行了下沉。未来在合适的时机会再考虑将之上拉并形成独立的部署集群。

    原文链接:https://mp.weixin.qq.com/s/PqeI1253SHIkMgv8hPCR5w

    服务迁移之路 | Spring Cloud向Service Mesh转变

    博云BoCloud 发表了文章 • 0 个评论 • 295 次浏览 • 2019-05-20 17:39 • 来自相关话题

    导读 Spring Cloud基于Spring Boot开发,提供一套完整的微服务解决方案,具体包括服务注册与发现,配置中心,全链路监控,API网关,熔断器,远程调用框架,工具客户端等选项中立的开源组件,并且可以根据需求对部分组件进行 ...查看全部
    导读

    Spring Cloud基于Spring Boot开发,提供一套完整的微服务解决方案,具体包括服务注册与发现,配置中心,全链路监控,API网关,熔断器,远程调用框架,工具客户端等选项中立的开源组件,并且可以根据需求对部分组件进行扩展和替换。

    Service Mesh,这里以Istio(目前Service Mesh具体落地实现的一种,且呼声最高)为例简要说明其功能。 Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。它也是一个平台,包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio的多样化功能集使你能够成功高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    从上面的简单介绍中,我们可以看出为什么会存在要把Spring Cloud体系的应用迁移到Service Mesh这样的需求,总结下来,有四方面的原因:

    1. 功能重叠

    来简单看一下他们的功能对比:



    微信截图_20190520171338.png




    从上面表格中可以看到,如果从功能层面考虑,Spring Cloud与Service Mesh在服务治理场景下,有相当大量的重叠功能,从这个层面而言,为Spring Cloud向Service Mesh迁移提供了一种潜在的可能性。



    2. 服务容器化

    在行业当前环境下,还有一个趋势,或者说是现状。越来越多的应用走在了通往应用容器化的道路上,或者在未来,容器化会成为应用部署的标准形态。而且无论哪种容器化运行环境,都天然支撑服务注册发现这一基本要求,这就导致Spring Cloud体系应用上容器的过程中,存在一定的功能重叠,有可能为后期的应用运维带来一定的影响,而Service Mesh恰恰需要依赖容器运行环境,同时弥补了容器环境所欠缺的内容(后续会具体分析)。



    3. 术业有专攻

    从软件设计角度出发,我们一直在追求松耦合的架构,也希望做到领域专攻。例如业务开发人员希望我只要关心业务逻辑即可,不需要关心链路跟踪,熔断,服务注册发现等支撑工具的服务;而平台支撑开发人员,则希望我的代码中不要包含任何业务相关的内容。而Service Mesh的出现,让这种情况成为可能。



    4. 语言壁垒

    目前而言Spring Cloud虽然提供了对众多协议的支持,但是受限于Java技术体系。这就要求应用需要在同一种语言下进行开发(这不一定是坏事儿),在某种情况下,不一定适用于一些工作场景。而从微服务设计考虑,不应该受限于某种语言,各个服务应该能够相互独立,大家需要的是遵循通信规范即可。而Service Mesh恰好可以消除服务间的语言壁垒,同时实现服务治理的能力。


    基于以上四点原因,当下环境,除了部分大多已经提前走在了Service Mesh实践的道路上互联网大厂以外(例如蚂蚁金服的SOFASTACK),也有大部分企业已经开始接触Service Mesh,并且尝试把Spring Cloud构建的应用,迁移到Service Mesh中。



    #Spring Cloud向Service Mesh的迁移方案



    Spring Cloud向Service Mesh迁移,从我们考虑而言大体分为七个步骤,如图所示:



    图片1.png




    1. Spring Cloud架构解析

    Spring Cloud架构解析的目的在于确定需要从当前的服务中去除与Service Mesh重叠的功能,为后续服务替换做准备。我们来看一个典型的Spring Cloud架构体系,如图所示:



    图片2.png






    从图中我们可以简要的分析出,一个基于Spring Cloud的微服务架构,主要包括四部分内容:服务网关,应用服务,外围支撑组件,服务管理控制台。



    • 服务网关
    服务网关涵盖的功能包括路由,鉴权,限流,熔断,降级等对入站请求的统一拦截处理。具体可以进一步划分为外部网关(面向互联网)和内部网关(面向服务内部管理)。
    • 应用服务
    应用服务是企业业务核心。应用服务内部由三部分内容构成:业务逻辑实现,外部组件交互SDK集成,服务内部运行监控集成。
    • 外围支撑组件
    外围支撑组件,涵盖了应用服务依赖的工具,包括注册中心,配置中心,消息中心,安全中心,日志中心等。
    • 服务管理控制台
    服务管理控制台面向服务运维或者运营人员,实现对应用服务运行状态的实时监控,以及根据情况需要能够动态玩成在线服务的管理和配置。



    这里面哪些内容是我们可以拿掉或者说基于Service Mesh(以Istio为例)能力去做的?分析下来,可以替换的组件包括网关(gateway或者Zuul,由Ingress gateway或者egress替换),熔断器(hystrix,由SideCar替换),注册中心(Eureka及Eureka client,由Polit,SideCar替换),负责均衡(Ribbon,由SideCar替换),链路跟踪及其客户端(Pinpoint及Pinpoint client,由SideCar及Mixer替换)。这是我们在Spring Cloud解析中需要完成的目标:即确定需要删除或者替换的支撑模块。



    2. 服务改造

    服务单元改造的目的在于基于第一步的解析结果,完成依赖去除或者依赖替换。根据第一步的分析结果服务单元改造分为三步:

    · 删除组件,包括网关,熔断器,注册中心,负载均衡,链路跟踪组件,同时删除对应client的SDK;
    · 替换组件,采用httpClient的SDK支持http协议的远程调用(原来在Ribbon中),由原来基于注册中心的调用,转变成http直接调用;
    · 配置信息变更,修改与删除组件管理的配置信息以及必要的组件交互代码(根据实际应用情况操作);

    当然服务单元改造过程中,还会涉及到很多的细节问题,都需要根据应用特点进行处理,这里不做深入分析。



    3. 服务容器化

    服务容器化是目前应用部署的趋势所在。服务容器化本身有很多不同的方式,例如基于Jenkins的pipeline实现,基于docker-maven-plugin + dockerfile实现,当然还有很多不同的方式。这里以Spring Cloud一个demo服务通过docker-maven-plugin+dockerfile实现说明为例:



    简易的一个服务的Dockerfile如下所示:


    ROM openjdk:8-jre-alpine
    ENV TZ=Asia/Shanghai \
    SPRING_OUTPUT_ANSI_ENABLED=ALWAYS \
    JAVA_OPTS="" \
    JHIPSTER_SLEEP=0
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    CMD echo "The application will start in ${JHIPSTER_SLEEP}s..." && \
    sleep ${JHIPSTER_SLEEP} && \
    java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /app.jar
    # java ${JAVA_OPTS} -Djava.security.egd=environment:/dev/./urandom -jar /app.@project.packaging@

    EXPOSE 8080
    ADD microservice-demo.jar /app.jar



    文件中定义了服务端口以及运行命令。


    Maven-docker-plugin的插件配置如下所示:



    microservice-demo

    ......

    com.spotify
    docker-maven-plugin
    1.2.0


    build-image
    package

    build



    tag-image
    package

    tag


    ${project.build.finalName}:${project.version}
    ${docker.registry.name}/${project.build.finalName}:${project.version}





    ${project.basedir}/src/main/docker
    ${project.build.finalName}:${project.version}


    /
    ${project.build.directory}
    ${project.build.finalName}.${project.packaging}








    通过增加docker-maven-plugin,在执行mvn package的时候可以加载Dockerfile,自动构建服务的容器镜像(需要说明的前提是本地安装docker运行环境,或者通过环境变量在开发工具中配置Docker的远程连接环境),从而完成服务容器化改造。



    4. 容器环境构建

    容器环境决定这Service Mesh的部署形态,这里不详细描述容器环境的部署过程。感兴趣的朋友,可以参考https://github.com/easzlab/kubeasz 开源项目,提供了Kubernetes基于ansible的自动化部署脚本。我们也建议选择Kubernetes来构建容器环境。这里说明容器环境构建的考虑因素:


    · 集群部署方案
    集群部署方案主要考虑多集群,跨数据中心,存储选择,网络方案,集群内部主机标签划分,集群内部网络地址规划等多方面因素。

    · 集群规模
    集群规模主要考虑etcd集群大小,集群内运行实例规模(用来配置ip范围段),集群高可用节点规模等因素。


    基于以上两点来考虑容器化环境的部署方案,关键是合理规划,避免资源浪费。



    5. Service Mesh环境构建

    Service Mesh环境构建依赖于容器环境构建,主要考虑两个方面,以Isito为例:


    · 部署插件
    Istio部署插件需要根据需要的场景,考虑采用的插件完整性,例如prometheus,kiali,是否开启TLS等,具体安装选项可以参考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。

    · 跨集群部署
    依据容器环境考虑是否需要支持Isito的跨集群部署方案.



    6. 服务注入

    服务注入用于将容器化的服务接入到Service Mesh的平台中,目前主要有两种方式。以Isito为例说明,主要包括自动注入和手动入住。选择手动注入的目的在于可以根据企业内部上线流程,对服务接入进行人为控制。而自动注入则能够更加快捷,方便。到此实际上已经完成服务迁移工作。



    7. 服务管理控制台

    由于Service Mesh目前而言,多是基于声明式的配置文件,达到服务治理的效果,因此无法实时传递执行结果。基于这种原因,需要一个独立的Service Mesh的管理控制台,一方面能够查看各个服务的运行状态以及策略执行情况,另外一方面能够支持服务运行过程中策略的动态配置管理。目前而言,可以在Isito安装过程中选择kiali作为一个控制台实现,当然未来也会有大量的企业提供专门的服务。


    通过以上七个步骤,能够在一定程度上帮助企业应用,从Spring Cloud迁移到Service Mesh上,但迁移过程中必然存在不断踩坑的过程,需要根据应用特点,事前做好评估规划。



    #迁移优缺点分析

    Spring Cloud迁移到Service Mesh是不是百利而无一害呢?

    首先,从容器化的环境出发,后续Knative,Kubernetes,Service Mesh必然会构建出一套相对完整的容器化PaaS解决方案,从而完成容器化PaaS支撑平台的构建。Service Mesh将为容器运行态提供保驾护航的作用。

    其次,就目前Service Mesh的落地实现而言,对于一些特定需求的监测粒度有所欠缺,例如调用线程栈的监测(当然,从网络层考虑,或者不在Service Mesh的考虑范围之内),但是恰恰在很多服务治理场景的要求范围之中。我们也需要针对这种情况,考虑实现方案。

    最后,大家一直诟病的性能和安全问题。目前已经有所加强,但是依然被吐槽。

    整体而言,Spring Cloud是微服务实现服务治理平台的现状,而Service Mesh却是未来,当然也不能完全取而代之,毕竟设计思路和侧重点不同,是否迁移需要根据业务场景而定。


    本文由博云研究院原创发表,转载请注明出处。

    基于事件驱动机制,在Service Mesh中进行消息传递的探讨

    博云BoCloud 发表了文章 • 0 个评论 • 297 次浏览 • 2019-05-13 14:05 • 来自相关话题

    翻译 | 宋松 原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging # 关键点 ...查看全部
    翻译 | 宋松
    原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging



    # 关键点

    当前流行的Service Mesh实现(Istio,Linkerd,Consul Connect等)仅满足微服务之间的请求 - 响应式同步通信。

    为了推进和采用Service Mesh,我们认为支持事件驱动或基于消息的通信是至关重要的。

    在Service Mesh中实现消息传递支持有两种主要的体系结构模式;协议代理sidecar,它是来自消费者和生产者的所有入站和出站事件的代理;以及HTTP bridge sidecar,它将事件驱动的通信协议转换为HTTP或类似的协议。

    不管使用哪种bridge模式,sidecar都可以促进跨功能特性的实现(和纠正抽象),比如可观察性、节流、跟踪等。

    Service Mesh作为基础技术和基于微服务、云原生架构的架构模式越来越受欢迎。 Service Mesh主要是一个网络基础结构组件,允许您从基于微服务的应用程序卸载网络通信逻辑,以便您可以完全专注于服务的业务逻辑。

    Service Mesh是围绕代理的概念构建的,代理与服务作为sidecar进行协作。虽然Service Mesh常常被宣传为任何云原生应用程序的平台,但目前流行的Service Mesh实现(Istio/Envoy、Linkerd等)只满足微服务之间同步通信的request/response风格。但是,在大多数实用的微服务用例中,服务间通信通过各种模式进行,例如request/response(HTTP,gRPC,GraphQL)和事件驱动的消息传递(NATS,Kafka,AMQP)。 由于Service Mesh实现不支持事件驱动的通信,Service Mesh提供的大多数商品功能仅可用于同步request/response服务 - 事件驱动的微服务必须支持这些功能作为服务代码本身的一部分,这与Service Mesh架构的目标相矛盾。

    Service Mesh支持事件驱动的通信至关重要。本文着眼于支持Service Mesh中事件驱动架构的关键方面,以及现有Service Mesh技术如何尝试解决这些问题。



    # 实现事件驱动的消息传递

    在典型的request/response同步消息传递方案中,您将找到一个服务(服务器)和一个调用该服务的使用者(客户端)。 Service Mesh数据平面充当客户端和服务之间的中介。 在事件驱动的通信中,通信模式是截然不同的。 事件生成器异步地将事件发送到事件代理,生成器和使用者之间没有直接的通信通道。 通信风格可以是pub-sub(多个使用者)或基于队列的(单个使用者),并且根据样式,生产者可以分别向主题或队列发送消息。


    消费者决定订阅驻留在事件代理中的主题或队列,该事件代理与生产者完全分离。 当有可用于该主题或队列的新消息时,代理会将这些消息推送给使用者。


    有几种方法可以将Service Mesh抽象用于事件驱动的消息传递。


    Protocol-proxy sidecar

    协议代理模式围绕所有事件驱动的通信信道应该通过Service Mesh数据平面(即,边车代理)的概念构建。 为了支持事件驱动的消息传递协议(如NATS,Kafka或AMQP),您需要构建特定于通信协议的协议处理程序/过滤器,并将其添加到sidecar代理。 图1显示了使用service mesh进行事件驱动的消息传递的典型通信模式。



    1.jpg



    图1:使用service mesh的事件驱动的消息传递



    由于大多数事件驱动的通信协议都是在TCP之上实现的,所以sidecar代理可以在TCP之上构建协议处理程序/过滤器,以专门处理支持各种消息传递协议所需的抽象。

    生产者微服务(微服务A)必须通过底层消息传递协议(Kafka,NATS,AMQP等)向side car发送消息,使生产者客户端使用最简单的代码,而side car去处理与协议相关的大部分的复杂性。Envoy团队目前正在基于上述模式实现对Envoy代理的Kafka支持。它仍在进行中,但你可以在GitHub上跟踪进展。




    HTTP-bridge sidecar


    不需要为事件驱动的消息传递协议使用代理,我们可以构建一个HTTP bridge来转换需要消息协议的消息(to/from)。构建此桥接模式的关键动机之一是大多数事件代理提供REST API(例如,Kafka REST API)来使用和生成消息。如图2所示,通过控制连接两个协议的sidecar,现有的微服务可以透明地使用底层事件代理的消息传递系统。sidecar代理主要负责接收HTTP请求并将其转换为Kafka/NATS/AMQP/等。消息,反之亦然。




    2.jpg



    图2:HTTP bridge允许服务通过HTTP与事件代理通信



    同样,您可以使用HTTP桥接器允许基于Kafka / NATS / AMQP的微服务直接与HTTP(或其他request/response消息传递协议)微服务进行通信,如图3所示。在这种情况下,sidecar接收Kafka / NATS / AMQP 请求,将它们转发为HTTP,并将HTTP响应转换回Kafka / NATS / AMQP。目前正在努力在Envoy和NATS上添加对此模式的支持(例如,AMQP / HTTP Bridge和NATS / HTTP Bridge,都在Envoy做此种模式的支持)。




    3.jpg



    图3:HTTP Bridge允许基于事件驱动的消息传递协议的服务使用HTTP服务



    尽管HTTP-bridge模式适用于某些用例,但它还不够强大,不能作为service mesh体系结构中处理事件驱动消息传递的标准。因为对于基于request/response的事件驱动消息协议来说总是存在一些限制。它或多或少是一种适用于某些用例的方法。



    # 事件驱动service mesh的关键功能


    基于request/response样式消息传递的传统service mesh的功能与支持消息传递范例的service mesh的功能有些不同。以下是一个支持事件驱动消息传递的service mesh将提供的一些独特功能:


    • 消费者和生产者抽象:对于大多数消息传递系统,比如Kafka,代理本身是相当抽象和简单的(微服务上下文中的哑管道),而您的服务是智能端点(大多数智能都存在于生产者或消费者代码中)。这意味着生产者或消费者必须在业务逻辑旁边有大量的消息协议代码。通过引入service mesh,您可以将与消息传递协议相关的特性(例如Kafka中的分区再平衡)转移到sidecar,并完全专注于微服务代码中的业务逻辑。
    • 消息传递语义:有很多消息传递语义,比如“至多一次”、“至少一次”、“恰好一次”等等。根据底层消息传递系统所支持的内容,可以将这些任务转移到Service Mesh(这类似于在request/response范例中支持断路器、超时等)。
    • 订阅语义:还可以使用service-mesh层来处理订阅语义,例如消费者端逻辑的持久订阅。
    • 限流:可以根据各种参数(如消息数量,消息大小等)控制和管理消息限制(速率限制)。
    • 服务发现(代理、主题和队列发现):Service -mesh sidecar允许你在消息生产和使用期间发现代理位置、主题或队列名称。这涉及到处理不同的主题层次结构和通配符。
    • 消息验证:验证用于事件驱动消息传递的消息变得越来越重要,因为大多数消息传递协议(如Kafka、NATS等)都协议无关的。因此,消息验证是使用者或生产者实现的一部分。Service Mesh可以提供这种抽象,以便使用者或生产者可以转移消息验证。例如,如果您将Kafka和Avro一起用于模式验证,那么您可以使用sidecar进行验证(即,从外部scheme注册表(如Confluent)获取模式,并根据该模式验证消息)。您还可以使用它来检查消息中的恶意内容。
    • 消息压缩:某些基于事件的消息传递协议,如Kafka,允许数据被生产者压缩,以压缩格式写入服务器,并被消费者解压。您可以很容易地在sidecar-proxy级别实现这些功能,并在service-mesh控制平面上控制它们。
    • 安全性:您可以通过在service-mesh sidecar级别启用TLS来保护代理和消费者/生产者之间的通信,这样您的生产者和消费者实现就不需要担心安全通信,而可以用纯文本与sidecar通信。
    • 可观察性:由于所有通信都发生在service-mesh数据平面上,因此可以为所有事件驱动的消息传递系统部署指标、跟踪和开箱即用的日志记录。




    关于作者

    Kasun Indrasiri是WSO2的集成架构总监,是微服务架构和企业集成架构的作者/传播者。 他撰写了“微服务企业(Apress)和开始WSO2 ESB(Apress)”一书。 他是Apache提交者,曾担任WSO2 Enterprise Integrator的产品经理和架构师。 他曾参加过O'Reilly软件架构大会,GOTO芝加哥2019大会以及大多数WSO2会议。 他参加了旧金山湾区的大部分微服务会议。 他创建了硅谷微服务,API和集成会议,这是湾区的供应商中立的微服务会议。



    本文由博云研究院原创翻译发表,转载请注明出处。

    Linkerd or Istio?哪个Service Mesh框架更适合你?

    博云BoCloud 发表了文章 • 0 个评论 • 511 次浏览 • 2019-04-30 14:09 • 来自相关话题

    翻译 | 宋松 原文 | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42 本周我开始写一篇比较Istio和Linked的帖子,并 ...查看全部
    翻译 | 宋松
    原文 | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42



    本周我开始写一篇比较Istio和Linked的帖子,并且告诉我自己:我将用一个表格来比较两者的特性,这将会很棒,人们会爱上它,这个世界将会幸福几秒钟。我向自己承诺这将是一个公平的比较,没有任何偏见。虽然比较的表格仍然存在,但我转移了文章的终点:目标不再是哪个更好,而是哪个更适合你、你的应用程序和你的组织。

    在职业生涯的一段时间中,我曾担任某公司的售前架构师,记得有很多次我们被要求填写产品比较表。我经常需要运用创造力来确保产品看起来很好,几乎不惜一切代价避免表格中令人不愉快的“不支持”的框。考虑到诚信工作,但是有时候不得不这样做。

    站在评价者的角度来看,我理解他们(希望)的目的是进行公平的比较,在这种程度上,对比的表格似乎是一种可靠的方式。我们知道一个项目的成功可以预测职业的发展,我们都喜欢这一点。但问题是:如果评估的最终目标是产品对比表格,而不是能让企业更有竞争力的高质量软件,那么这个评估的最后将只是一些“表格”的工作。

    产品比较并不是最终目的,通过比较知道哪些对你的用例最好才是最终目的。因此让我们通过七个方面来深入研究Service Mesh,主要是以下几个方面:

    • 流量管理
    • 安全
    • 安装/配置
    • 支持的环境
    • 监测
    • 策略管理
    • 性能
    对于上述七个方面中的每一个,我都将发表个人观点,希望我的观点能够帮你做出更接近于简洁的决策。#流量管理需要强调的是,Istio和Linkerd的区别在于数据平面使用了两种不同的代理技术。Istio使用Envoy作为其代理。Envoy是C++编写的,最初是由Lyft构建,以便以非Kubernetes方式促进微服务的流量管理。许多公司已经将Envoy扩展为Kubernetes的ingress技术。Linkerd(v2)使用的是一种名为Linkerd-proxy的专用服务网格代理。这个代理是使用Rust编写的,与该代理一起,许多低级代理(网络客户机与服务器)功能在另一个也是由rust编写名为Tower的项目中实现。Tower依赖于Tokio,Tokio是一个由Rust编写的事件驱动非阻塞I/O库。如果你和我一样欣赏统计学,那么Rust已经连续四年(2016、2017、2018、2019)一直是Stack-overflow最受欢迎的语言。
    微信截图_20190429162020.png
    Istio是构建与Envoy之上的因此在流量管理方面它是占据优势的,Envoy已经包含了重要的IMHO功能,比如子集路由。用户仍然可以使用Linkerd实现金丝雀/蓝绿/a-b发布,但必须依靠单独的Kubernetes服务和能够分发流量的集群ingress技术,比如Gloo(gloo.solo.io)。Linkerd团队在最近一次社区会议上公开表示,计划在未来的版本中实现更加高级的L7流量管理功能。#安全关于安全,我正在考虑保护通信通道的能力。Istio和Linkerd两者都提供了合理的安全保护功能。
    微信截图_20190429162033.png
    Istio和Linkerd都依赖于外部根证书,因此两者都能保证进行安全通信。这听起来像是一个很好的周末项目,你觉得呢?#安装和配置
    3.png
    鉴于Istio可以安装在许多不同的平台上,安装说明可能会存在很大的不同。在写这篇文章的时候,关于Linkerd的安装,我对一些预先需要安装功能的检查印象很深刻。有很多次我在共享的Kubernetes集群中安装一些Linkerd功能时,我不清楚我是否拥有必要的权限。对于Linkerd,pre-check(或check-pre)检查你是否拥有在安装过程中创建Kubernetes所需资源的权限。#环境支持和部署模型对于是选择kubernetes或者是非Kubernetes安装,这是一个很直接的问题,Linkerd2是用基于kubernetes方式构建的,至少目前是这样的,而Istio收到了一下其他的公司的贡献,希望istio能在非kubernetes环境中运行。
    4.png
    考虑多集群部署,客观来说对于它的解释可能很棘手。从技术上来讲,共享根CA证书的多个不同集群(具有不同的控制平面)上的服务之间可以有效的通信。Istio扩展了上述概念,因为它支持不同情形下的多个集群:
    • 单个控制平面即可满足不同集群之间网络连接和pod之间IP寻址。
    • 通过使用具有单个控制平面的集群边界网关(egress和ingress)即可访问多个集群上的kubernetes API服务器。

    在上述两种情况下,包含控制平面的集群将成为mesh管理的SPOF(single point of failure)。在我们这个可以在同一区域下的多个可用区域上部署单个集群的世界中,这将不再是一个问题,但仍然不能完全忽略它。




    #监测



    5.png




    可以说Istio的管理控制台是一个缺失的部分。 Kiali Observability Console确实解决了一些管理员对service mesh所需的一些需求。

    Kiali(κιάλι)是一个希腊词,意思是望远镜,从Kiali的网站上可以清楚的看到它打算成为一个可监测性的控制台,而不仅仅是一个Service Mesh管理控制台。

    Linkerd控制台还不完整,但是社区决定也要构建一个管理仪表盘的目标是一个优势。

    Linkerd未能提供请求追踪。想要以非侵入方式查看请求追踪跨度必须等待Linkerd实现该功能。Istio利用了Envoy支持添加追踪headers的事实。

    应该提醒用户,应用程序需要准备好转发跟踪headers,如果没有准备,代理可以生成新的跟踪IDS,这可能会无意中将单个请求分割为多个请求跨度使请求之间失去必要的关联性。大多数开发框架都有转发headers的选项,而无需用户编写大量的代码。



    #策略管理

    Istio的爱好者,请欢欣鼓舞!Istio的策略管理能力令人印象深刻。

    该项目构建了一个可扩展的策略管理机制,允许其他技术可从多个方面与Istio集成,请参阅下面的“template”列表以及一些集成的提供者。你可以认为“template”是一种集成。


    6.png



    为了突出其他策略类型,Istio也可适用于rating和limiting以及提供对主体身份验证的开箱即用支持。Linkerd用户依赖集群ingress控制器提供rating和limiting。

    对于主体身份验证,我一直认为它应该委托给应用程序。请记住#4分布式计算的谬论:网络是安全的。对此持零信任策略。


    7.png



    Istio令人印象深刻的策略管理能力是需要代价的。考虑到他的广泛性,管理众多的选项增加了本已昂贵的运营成本。

    Istio(Mixer)的策略管理组件也增加了显著的性能,我们将在下面详细讨论。



    #性能

    对比表在哪里?幸运的是,就在最近,发布了两个很棒的博客,对Istio和Linkerd的性能进行了比较,我在下面引用了其中一些结论:

    对于这种综合工作负载,Istio的Envoy代理使用比Linkerd多50%的CPU。Linkerd的控制平面使用了一小部分Istio,特别是在考虑“core”组件时。



    ——Michael Kipper — Benchmarking Istio & Linkerd CPU(https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

    And…

    在本实验中,与基线设置相比,Linkerd2-meshed设置和Istio-meshed设置都经历了更高的延迟和更低的吞吐量。在Istio-meshed设置中产生的延迟高于在Linkerd2-meshed设置中观察到的延迟。Linkerd2-Meshed设置能够处理比Istio-Meshed设置更高的HTTP和GRPC ping吞吐量。



    ——Ivan Sim — Linkerd 2.0 and Istio Performance Benchmark(https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

    意识到Mixer所增加的处理时间,Istio团队目前正致力于重写Mixer组件:“Mixer将用c++重新并直接嵌入到Envoy中。将不再有任何独立的Mixer服务。这将提高性能并降低运营复杂性。”



    —Source Mixer V2 Design Document(https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s/edit)



    #总结



    是的,Istio比Linkerd2.3有多的特性。这是很好的,更多的特性意味着处理更复杂和边缘用例的能力增强。这没什么神奇的,更多的特性通常意味着更多的配置,潜在的资源利用率和运营成本的增加,所有这里有三条建议:



    如果你不知道80%最常见的工作负载是什么样子的,那么你将很难选择服务网格。如果你不知道这些数字,你的企业可能还没有准备好进行服务网格的使用。如果你只是在探索,那就另当别论了。

    如果你想计划解决所有可能的当前和未来的cases(通常叫做comparison spreadsheet),那么你将会有一段糟糕的时间。你很可能会过度获取,这对你购买的任何软件都是如此。

    盲目的选择一种技术或另一种会让你过的很糟糕。炒作可能很厉害,但请记住,你并不是在炒作业务(除非真的在炒作)。

    试试Istio和Linkerd! Solo SuperGloo是最简单的方式。

    我使用SuperGloo是因为它非常简单,可以快速启动两个服务网格,而我几乎不需要做任何努力。我们并没有在生产中使用它,但是它非常适合这样的任务。每个网格实际上是两个命令。

    ——Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify(https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781)。



    微信图片_20190429150753.png




    在Solo.io(https://www.solo.io/),我们希望为你的服务网格采用之旅提供便利。 Solo SuperGloo我们的服务Mesh orchestrator可以通过直观简单的命令安装和管理流行的服务网格技术。 正如Michael上面所指出的那样,安装Istio或Linkerd会成为一个单行活动。 SuperGloo并不止于此,它在不同的服务网格技术之上提供了一个抽象,允许对多个网格进行一致且可重复的操作。 SuperGloo是完全开源的,you can try it right now(https://supergloo.solo.io/)。

    本文由博云研究院原创翻译发表,转载请注明出处。

    企业应用架构演化探讨:从微服务到Service Mesh

    博云BoCloud 发表了文章 • 0 个评论 • 339 次浏览 • 2019-04-28 14:33 • 来自相关话题

    #导读 当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化,并形成落地方案。需要特别说明:本文讨 ...查看全部
    #导读

    当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化,并形成落地方案。需要特别说明:本文讨论的架构目前适用于普通的企业级应用,其他行业(例如互联网)需要进一步扩展。



    在讨论之前,我们需要明确一个事实:企业应用一定是围绕业务进行的。无论采用什么的架构落地,都是为了更好的为应用业务进行服务。从企业应用的特性考虑,主要包括:稳定性,安全性,扩展性,容错性。

    围绕着企业应用的这些特点,我们来看一个典型的微服务企业架构模型,如图所示:


    图片1.png



    • 服务接入层:企业暴露到外部访问的入口,一般通过防火墙等。
    • 网关层:服务网关是介于客户端和服务端的中间层,所有的外部请求会先经过服务网关,为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分,聚合,路由,认证以及流控综合体现。
    • 支撑服务层:为企业应用提供运行所需的支撑环境,包括注册发现,集中配置,容错限流,认证授权,日志聚合,监测告警,消息服务等
    • 业务服务层:业务服务是企业应用的核心所在,为企业领域应用的具体实现,一般进一步拆分为基础服务(基础功能)和聚合服务(综合场景)。
    • 平台服务层:为企业应用提供运行所需的软件资源,包括应用服务器,应用发布管理,应用镜像包管理,服务治理。
    • 基础设施层:为企业应用提供运行所需的硬件资源,包括计算资源,网络资源,存储资源,基本的安全策略控制等。
    从这个典型的服务架构体系中,能够清晰的表明层级架构以及各层涵盖的职责说明。我们暂不考虑基础设施层和平台服务两层,重点关注网关服务,业务服务,支撑服务,突出其中的一些基础支撑功能组件,这也是我们本篇探讨的重点内容。如下图所示:
    图片2.png
    根据图中红色标识,我们会发现这样一个事实:在微服务架构下,无论是哪种落地实现方式,都集中在网关服务、支撑服务两个层面。无论是Spring Cloud“套装组件”,Dubbo“套件”还是其他开源组件,都为支撑服务的实现提供了数量众多的选择。功能完整、选择性多这是业内喜闻乐见的事情,但是也无形中增加了开发,测试,运维人员的压力。大家需要掌握越来越多的“使用工具”以更“方便”、“快捷”地应对业务服务。有时候,可能为了实现单一功能,而必须引入一堆组件,这时候我们希望能够有一个完整的平台来为应用业务提供一体化的支撑服务,而不是一系列“套装组件”与业务的集成。那么如何基于一个平台来实现这些企业应用需要的能力呢?经过一定阶段的技术调研,我们认为Service Mesh能够帮助我们初步达到这个目标。我们都知道Service Mesh以解决“服务通信”的问题作为其设计初衷,聚焦基础设施“网络层”,并以此做技术基础,解决业务通信场景面临的问题。那么如何把它应用在企业应用架构中来取代“微服务套装组件”呢?那接下来让我们针对网关服务,业务服务,支撑服务分别来看一下,如何从原来的微服务“套装组件”中抽离出来,实现Service Mesh方向的转变。#网关服务前面提到过:服务网关是介于客户端和服务端的中间层。从功能上不难理解,对内屏蔽内部细节,对外提供统一服务接口。从场景聚焦角度考虑,网关根据不同的场景承载不同的职责,包括认证,授权,路由,流控,负载等。(之前我们也聊过网关组件的对比及具体实现,感兴趣的同学可点击微服务五种开源API网关实现组件对比)。由此可见,服务网关是企业应用架构下一些列功能的综合体现。那么在Service Mesh情况下如何处理网关服务呢?在展开之前首先需要说明一个前提:目前为止Service Mesh跟真正企业网关相比还存在一定的不足之处,例如“协议转化”,“安全策略”,“性能要求”等方面。在这里我们也是探讨这样的可能性。下面以Istio为例,我们来看一下,如何提供网关层面的服务。Istio在网关层面提供两种类型的网关服务:Ingress Gateway,Egress。
    • Ingress Gateway
    Ingress Gateway用于接收传入的HTTP/TCP连接,它配置暴露端口,协议供外部统一接入,但是自身不提供任何的路由配置,而是完全依赖 Istio 的控制规则来进行流量路由。从而与内部服务请求统一到同一个控制层面上。
    • Egress
    在企业应用与外部应用之间,有时候为了业务需要会出现内部服务调用外部服务的情况,此时一般会从企业内部接入第三方网关来获取服务数据。在 Isito 中你同样可以基于Egress来达到目的。Isito中提供两种方式:一种基于ServiceEntry VirtualService的配置,实现第三方服务的访问,一种扩大sidecar的访问地址列表。(参考文档:https://preliminary.istio.io/zh/docs/tasks/traffic-management/egress/)。基于上述两种场景,我们可以看出,在 Service Mesh 的体系下,网关层面变成一个可以动态生成和销毁的组件,能够通过控制层面实现统一规则管理,并且实时生效。基于Service Mesh的网关服务如下图所示:
    图片3.png
    从实现原理上分析,传统的网关实现基于 Servlet 的 filter 的模式,实现服务请求转移过程中的层层过滤和处理。区别在于采用同步或者异步处理机制,用来解决网关的性能瓶颈。而Service Mesh的网关完全是基于网络代理的请求转发与控制,本质上作用在服务的 Iptables 上,通过对 Iptables 的规则控制达到同样的效果。 #业务服务业务是企业应用的“重中之重”,无论哪种企业架构,最终都是为了更好地为业务提供服务,那么我们如何在Service Mesh的体系下,重构业务服务呢?我们以两个简化的服务调用来说明整个架构的转变过程。假如要实现服务A,服务B的相互调用,最原始的方式是服务A基于协议层直接调用服务B(这里暂时忽略高可用,多副本,负载均衡的方式),如图所示:
    图片4.png
    由图可见,服务A基于某种协议完成对服务B的请求,相对比较简单。但是我们知道这样虽然能够快速完成业务关联,但是无法确保业务正常稳定的运行,因此我们需要引入更多的服务来保证业务的稳定,可靠,可控。此时我们最容易想到的是引入微服务的支撑组件来达到目标。以Spring Cloud方案为例,我们来说明当前微服务架构的实现方式。为了满足企业应用对服务A,服务B的管理控制,需要额外引入“注册中心”,“网关”,“配置中心”,“服务监测”,“事件消息”,“链路跟踪”,“日志服务”等众多与直接业务无关的“旁路保障服务”,简化一下,如下图所示:
    图片5.png
    从图中可以看出,每个服务都引入了大量与业务无关的“保障服务”,这些“旁路保障服务”消耗的资源,与比业务本身消耗的资源成“倍数关系”。随着服务数目的增多,业务服务本身占用的资源比会越来越少,此时开发人员会把大量的精力花费在维护这些“旁路保障服务”上,而忽略业务本身。这对于企业应用而言,有些本末倒置的意思。我们再来看一下 Service Mesh 体系下,我们如何解决上述问题。Service Mesh为了解决企业应用的“通信问题”重点做了四个方面的工作,以 Istio 为代表,提供了包括流量管理,安全配置,策略控制以及外围组件支撑的遥测功能(需要的朋友,可以参考官方文档:https://preliminary.istio.io/zh/docs),在Service Mesh的架构下,服务A调用服务B的架构会变成下图所示:
    图片5.png
    通过上图我们可以发现,与Spring Cloud的实现方式相比,似乎简单了很多,我们不再需要在业务服务中引入众多的“旁路保障服务”,而是保障了业务服务本身的简单化。那么Service Mesh是如何处理的呢?第一,引入了Sidecar代理模型,作为服务流量控制的入口和出口,保证能够对网络层面数据做实时监控和调整;第二,控制器根据具体业务情况,分发控制状态和控制指令,Sidecar获取控制信息后,及时更新缓存信息,保证策略有效性。第三,Sidecar由于能够拦截所有请求的流量信息,定期把收集的数据向控制层进行上报,从而完成服务状态和应用链路的监测。第四,所有的这些都是在应用部署阶段完成,在开发层面不需要花费大量的精力。基于以上四点我们可以发现,Service Mesh 仅仅通过方式转变就达到了同样的效果,还极大的解放了开发人员。通过业务服务调用方式的实现转变,我们发现这样一个事实:Service Mesh在保证业务简化有效的同时,进一步屏蔽了多种开发语言带来的障碍。它完全基于网络层面和协议层面作为出发点,达到“以不变应万变”的效果。 #支撑服务从企业业务的价值角度考虑,其实支撑服务更多属于“资源消耗”品,虽然如此,它却是企业应用架构不可或缺的一部分。从单一的业务调用--->微服务体系业务调用--->Service Mesh 体系业务调用的转变方式中,可以看出支撑服务处于一个层级不断下降的过程。而依赖于ServiceMesh的定位,最终一些支撑服务会作为基础设施的形态呈现出来,这也是未来发展的趋势所在。支撑服务在企业架构的形态转变如图所示:
    图片6.png
    • 传统架构:传统架构下,支撑服务,业务服务基本上没有明确的边界区分,实现方式上都通过代码杂糅在一起。
    • 微服务架构:微服务架构下,支撑服务,业务服务能够初步分离,但是需要保证代码框架的统一性和依赖性,跨语言受限比较严重。
    • Service Mesh架构:Service Mesh架构下,支撑服务,业务服务能够彻底分离,不收语言限制,唯一需要考虑的是不同协议的支持情况。
    通过支撑服务的转变形态可以看出,支撑服务与业务服务分离是必然趋势,而最终的受限取决于多元化的网络协议的处理分析能力。当然我们需要明确一个事实:就Service Mesh目前的发展趋势和定位而言,并不能够完全取代所有的支撑服务,例如事件消息,配置管理等。我们更多期望它能够帮助解决应用服务在网络层面需要面对的场景和问题。这也是它发挥价值的地方所在。通过对网关服务,业务服务,支撑服务在不同体系架构下的转变,我们清晰的认识到Service Mesh能够帮助我们重点解决微服务体系下繁琐的“旁路支撑”服务,保证业务服务的简单有效性。通过演化分析,最终基于Service Mesh的企业应用架构如下图:
    图片6.png
    从图中可以看到 Service Mesh 架构下重点做了三件事情:
    • 网关层的接入工作,无论是外部请求接入,还是内部服务请求转发,都可以基于 Service Mesh 提供的不同类型的 gateway 实现,同时还可以保证策略的统一控制和管理。省略了独立的网关管理控制台。
    • 针对业务服务,增加了 Sidecar 的代理模型,用来处理所有的入站和出站流量,并且配合支撑服务的控制策略,实现业务服务的旁路控制功能。
    • 统一面向网络的支撑服务,基于控制与数据分离的思想,根据业务的运行情况,提高企业应用运行过程中的动态控制能力。
    同样我们也意识到,利用 Service Mesh 处理服务通信的能力,替换需要不同组件支撑的“注册发现”,“容错限流”“认证授权”“日志搜集”,“监控告警”“流量控制”等功能。在减少组件代码开销的同时,将企业应用的支撑服务进一步下移。无论是开发人员,还是领域专家,可以集中精力用来处理应用业务,而不用在维护第三方的不同的功能组件上“浪费时间”。而业务运维人员,通过 Service Mesh 的控制平台,能够实时监测企业服务的运行状态,而不需要向之前那样花费精力维护不同的工具和组件。 最后让我们一起讨论一下,Service Mesh是如何做到这些的。Service Mesh 本质上并没有采用任何技术上的创新,更多是思想层面的变革。我们认为有几个转变是需要提出来的:
    • 层级转变:Service Mesh在设计思路上,把自己不再定位成企业应用组件,而是把自己下沉到基础设施层,成为基础设施的一部分,这样层级的转变就与企业业务本身划清楚界限。
    • 方式转变:Service Mesh在实现思路上,高度抽象,聚焦于通信链路本身,而不是聚焦于组件功能上,从网络层入手,抓住了服务通信交互的本质。
    • 控制转变:Service Mesh将控制和实现分离,提供统一,灵活的控制入口,能够快速方便的针对业务场景进行自定义处理。


    最后的最后需要说明 Service Mesh 还不完善,还有很多问题需要在实际的企业应用过程中逐步去解决,让我们一起拭目以待吧。


    本文由博云研究院原创发表,转载请注明出处。

    什么是服务网格?

    grace_shi 发表了文章 • 0 个评论 • 292 次浏览 • 2019-06-04 22:29 • 来自相关话题

    服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观 ...查看全部
    服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观察性,可追溯性,身份验证和授权,以及对断路器模式【1】的支持。

    服务网格是如何实现的呢?它通常会为每个服务实例提供一个称为边车(sidecar)的代理实例。这些边车会处理服务间的通信,监控和安全相关的问题, 以及任何可以从各个服务中抽象出来的东西。这样,开发人员就可以专注于服务中应用程序代码的开发,支持和维护,而运维团队可以负责维护服务网格以及运行应用程序。

    Istio,由Google,IBM和Lyft支持,是目前最著名的服务网格架构。Kubernetes,最初由Google设计,是目前Istio支持的唯一容器编排框架。供应商正在寻求商业版本的Istio。如果Istio能添加到开源项目中,将会带来更大的价值。

    Istio并不是唯一的选择,其他服务网格实现也在开发中。目前边车代理模式是最受欢迎的,例如Buoyant,HashiCorp,Solo.io等项目都使用了这种模式。与此同时,Netflix的技术套件使用了一种替代架构,他们使用了应用程序库(包含Ribbon,Hysterix,Eureka,Archaius)来提供服务网格功能,而Azure Service Fabric等平台在应用程序框架中嵌入了类似服务网格的功能。 服务网格包含一些专业术语来描述组件服务和功能:

    • 容器编排框架。随着越来越多的容器被添加到应用程序的基础架构中,用于监视和管理容器组的容器编排框架变得至关重要。
    • 服务和实例(Kubernetes Pod)。实例是微服务的单个运行副本。有时实例是一个容器;在Kubernetes中,一个实例由一小组相互依赖的容器(称为Pod)组成。客户端很少直接访问实例或Pod,通常他们会访问服务,服务通常是一组可扩展且具有容错性的实例或Pod(副本)。
    • 边车代理。 边车代理与单个实例或Pod一起运行。 边车代理的目的是路由或者代理从容器发出或者接收的流量。 边车与其他边车代理进行通信,编排框架会管理这些边车。许多服务网格的实现会使用边车代理来拦截和管理实例或Pod的所有进出流量。
    • 服务发现。当实例需要与不同的服务进行交互时,它需要找到 - 发现 - 其他服务的健康的,可用的实例。通常,这个实例会执行DNS查找来寻找其他服务的实例。容器编排框架保留实例列表(这些实例都可以正常接收请求),并且框架会提供DNS查询的接口。
    • 负载均衡。大多数编排框架已经提供了第4层(传输层)的负载均衡。服务网络实现了更复杂的第7层(应用层)负载均衡,具有更丰富的算法以及更强大的流量管理。同时可以通过API修改负载均衡的参数,从而可以编排蓝绿部署【2】或金丝雀部署【3】。
    • 加密。服务网格可以加密和解密请求和响应,因此每个服务不需要额外对请求进行加密,减少了负担。服务网格还可以通过优先重用现有的持久连接来提高性能,这减少新连接的创建(创建新连接十分耗费计算资源)。一般实现加密流量都是用双向TLS(mTLS),其中公钥架构(PKI,public key infrastructure)生成并分发证书和密钥,提供给边车代理使用。
    • 身份验证和授权。服务网格可以授权和验证从应用程序外部和内部发出的请求,仅向实例发送经过验证的请求。
    • 支持断路器模式【1】。服务网格可以支持断路器模式,这可以隔离不健康的实例,然后在安全的情况下逐渐将它们恢复并加入到健康的实例池中。

    服务网格应用中管理实例之间的网络流量的的部分称为数据平面。另外有一个独立的控制平面负责生成和部署数据平面的配置(这个配置可以控制数据平面的行为)。控制平面通常包含(或被设计为连接到)一个API,命令行界面和用于管理App的图形用户界面。

    *服务网格中的控制平面在数据平面中边车代理上分发配置*

    服务网格架构的一个常见用例是在使用容器和微服务时解决非常苛刻的操作问题。微服务领域的先驱包括Lyft,Netflix和Twitter等公司,这些公司任何时间都能为全球数百万用户提供强大的服务。 (请参阅我们对Netflix面临的一些架构挑战的深入描述。)如果应用程序对这方面要求比较低,那么更简单的架构就足够了。

    服务网格架构不可能解决所有应用程序操作和交付问题。架构师和开发人员可以选择多种工具,这些工具之中,有些是锤子,可以解决不同类型的问题,而另一些可能是钉子。例如,NGINX微服务参考架构包括几种不同的模型,这些模型提供了使用微服务来解决问题的一系列方法。 服务网格架构中的组成部分 - 例如:NGINX,容器,Kubernetes,以及微服务(作为架构方法),可以在非服务网格架构实现中高效地使用。例如,Istio是作为一个完整的服务网格架构开发的,但其模块化的设计意味着开发人员可以自由选择他们需要的部分组件技术。考虑到这一点,即使您不确定是否以及何时会完全实现服务网格应用程序,也值得深入了解一下服务网格概念。 

    注释: 

    【1】断路器模式: 一种设计模式。用以侦测错误,并避免不断地触发相同的错误(如维护时服务不可用、暂时性的系统问题或是未知的系统错误)。https://zh.wikipedia.org/wiki/斷路器設計模式 
    【2】蓝绿部署(blue‑green deployment):蓝绿部署是保留老版本,同时部署新版本然后进行测试,测试通过后,将流量切换到新版本,然后老版本同时也升级到新版本。 
    【3】金丝雀部署(canary deployment):又叫做灰度部署,即选择部分部署新版本,将部分流量引入到新版本,新老版本同时提供服务。等待灰度的版本测试完毕,之后全量覆盖老版本。 

    原文链接:What Is a Service Mesh? 

    ============================================================================== 
    译者介绍:Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。

    你好,SMI:Service Mesh 互操作性说明书

    YiGagyeong 发表了文章 • 0 个评论 • 264 次浏览 • 2019-05-27 23:36 • 来自相关话题

    【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为 Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。 今 ...查看全部
    【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为
    Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。

    今天,我们兴奋地发布了 `Service Mesh Interface(SMI)`,它定义了一组通用的可移植 API,为开发人员提供跨不同 Service Mesh(服务网格)技术的互操作性,其中包括 Istio,Linkerd 和 Consul Connect。SMI 是一个与微软,Linkerd,HashiCorp,Solo.io,Kinvolk 和 Weaveworks 合作开展的开放项目;同样也得到了 Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat 和 VMware 的支持。

    多年来,网络架构的真言是让网络管道尽可能愚蠢,并在应用中构建智能。网络的职责是转发数据包,而任何关于加密,压缩或身份的逻辑则存在于网络端点内。互联网是以此真言为前提的,所以你会觉得它可以运转良好。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    但是,如今随着微服务、容器以及编排系统如 `Kubernetes` 的爆炸式增长,工程团队将要保障、管理和监控越来越多的网络端点。Service Mesh 技术通过使网络更加智能,来解决上述问题。Service Mesh 技术不是教授所有服务来加密会话,授权客户端,发出合理的遥测,并在应用程序版本之间无缝转换流量,而是将此逻辑推入网络,由一组单独的管理 API 控制。

    这是 `cloud-native` 系统中比较流行的模式。我们发现,随着许多供应商为应用开发人员提供了令人兴奋的新选择,Service Mesh 技术也随之激增。问题是,转向 Service Mesh 的开发人员必须选择一个供应商,并直接对接其 API。他们被束缚在了某种 Service Mesh 的实现中。如果没有通用接口,开发人员就会失去可移植性以及灵活性,并且从广泛的生态系统中获益的能力也会受限。

    SMI 提供了如下功能:

    • Kubernetes 网格的标准界面
    • 最常见的网格用例的基本功能集
    • 随着时间的推移灵活地支持新的网格功能
    • 为生态系统提供利用网格技术进行创新的空间
    # SMI 覆盖了哪些功能我们与 HashiCorp,Buoyant,Solo.io 以及其他公司合作,为企业级客户所希冀的三大 Service Mesh 功能构建初始规范:[list=1]
  • 流量策略:应用跨服务应用身份和传输加密等策略
  • 流量遥测:捕获关键指标,如错误率和服务之间的延迟
  • 流量管理:在不同服务之间转移和加权流量

  • 这些只是我们希望通过 SMI 初步实现的功能。由于开发过程中有许多令人兴奋的网格功能,我们完全希望随着时间的推移,不断发展 SMI API,并期待通过新功能扩展当前规范。
    # SMI是如何工作的
    Service Mesh Interface 背后的观点并非新创。它追寻 Ingress,Network Policy 和 CNI 等现有 Kubernetes 资源的足迹。与 Ingress 或 Network Policy 一样,SMI 不提供具体实现。相反,SMI 规范定义了一组通用 API,允许网格提供者提供自己的最佳实现。与 SMI 集成可以通过两种方式实现,工具和网格提供者可以直接使用SMI API,也可以构建运算符将 SMI 转换为原生 API。

    SMI 是 Linkerd 迈向 Service Mesh 大众化的一大步,我们很高兴能够向更多的 Kubernetes 用户提供简洁和易用的 Linker 服务。
    > ——William Morgan,Linkerd 维护者



    对于跨技术和生态系统协作来说,接口的标准化对确保最佳用户体验至关重要。凭借这种精神,我们很高兴能与微软和其他公司合作开发 SMI 规范,并已经通过 Service Mesh Hub 和 SuperGloo 项目提供了首个参考实现。
    > ——Solo.io 创始人兼首席执行官,Idit Levine。



    # 生态系统友好
    对于 Service Mesh 等早期技术,我们必须为其生态系统创造创新空间,并探索解决客户问题的不同方法。随着 service mesh 技术的不断发展,SMI 提供的互操作性将有助于新兴工具和实用程序与现有网格供应商集成,而不是单独集成每个网格,像 flagger 和 SuperGloo 这样的工具就可以与 SMI 集成,从而获得跨网格功能。

    “Service Mesh 的兴趣和动力已达到了行业需要在一系列标准上进行协作的程度,这些标准可以帮助确保他们的成功。”VMware 服务网络首席架构师 Sushil Singh 表示,“Service Meshe 为应用程序的未来提供了丰富的基础功能。现在是制定标准 API 的最佳时机,这些 API 可以简化 Service Mesh 技术的消耗和功能,从而实现健康的生态系统。VMware 很高兴参与这项非常重要的工作。“



    客户和社区成员都在寻求一种方法来更好地标准化 Service Mesh 的配置和操作。随着 Service Mesh Interface(SMI)的出现,我们认为这是一种可以帮助我们最大化 Red Hat OpenShift 客户选择和灵活性的方法。这种灵活性使用户能够优先考虑实现细节的功能。
    > ——Brian Redbeard Harrington,Red Hat Service Mesh 首席产品经理



    原文链接:Hello Service Mesh Interface (SMI): A specification for service mesh interoperability (翻译:李加庆

    容器、微服务与服务网格

    cleverlzc 发表了文章 • 0 个评论 • 286 次浏览 • 2019-05-26 11:03 • 来自相关话题

    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给 ...查看全部
    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给出了自己的见解。

    如你所知,已经有很多关于服务网格的资料(1234),但这是另外一篇。是的!但是为什么会有这篇文章呢?因为我想给你们一些不同的视角,他们希望服务网格在10年前就已经存在,远早于Docker和Kubernetes这样的容器平台的兴起。我并不是说这个视角比其他视角更好或更差,但是由于服务网格是相当复杂的“野兽”,所以我相信多种视角有助于更好地理解它们。

    我将讨论dotCloud平台,这是一个建立在100多个微服务之上的平台,支持数千个运行在容器中的生产应用程序;我将解释在构建和运行它时所面临的挑战;以及服务网格会(或不会)提供帮助。
    # dotCloud的历史
    我已经写过关于dotCloud平台的历史和它的一些设计选择,但是我没有过多地讨论它的网络层。如果你不想深入了解我之前关于dotCloud的博客,你需要知道的是它是一个PaaS,允许客户运行各种应用程序(Java、PHP、Python等),支持广泛的数据服务(MongoDB、MySQL、Redis等)以及类似于Heroku的工作流程:你可以将代码推送到平台,平台将构建容器映像,并部署这些容器映像。

    我将告诉你流量是如何在dotCloud平台上路由的;不是因为它是特别棒或其他什么(我认为现在是比较合适的时间),但主要是因为,如果一个普通的团队需要一种在一个微服务群或一个应用程序群之间路由流量的方法,那么这种设计可以在短时间内用现在已有的工具轻松实现。因此,它将为我们提供一个很好的比较点,“如果我们破解它,我们会得到什么”和“如果我们使用现有的服务网格,我们会得到什么”,也就是老生常谈的“构建与购买”的困境。
    # 托管应用的流量路由
    部署在dotCloud上的应用程序会暴露HTTP和TCP端点。

    HTTP端点被动态地添加到Hipache负载平衡器集群的配置中。这与我们今天使用Kubernetes Ingress资源和Traefik这样的负载平衡器可以实现的功能类似。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    只要域名指向dotCloud的负载平衡器,客户端就可以使用它们的关联域名连接到HTTP端点。这里没有什么特别的。

    TCP端点与端口号相关联,然后端口号通过环境变量与该堆栈上的所有容器通信。

    客户端可以使用指定的主机名(类似于gateway-X.dotcloud.com)和端口号连接到TCP端点。

    该主机名将解析为一个“nats”服务器集群(与NATS没有任何关系),该集群将把传入的TCP连接路由到正确的容器(或者,在负载平衡服务的情况下,路由到正确的容器)。

    如果你熟悉Kubernetes,这可能会让你想起NodePort服务。

    dotCloud平台没有集群IP服务的等价物:为了简单起见,从内部和外部访问服务的方式是相同的。

    这非常简单,最初的HTTP和TCP路由网格的实现可能都是几百行Python代码,使用相当简单(我敢说,很天真)的算法,但是随着时间的推移,它们不断发展,以处理平台的增长和额外的需求。

    它不需要对现有应用程序代码进行大量重构。十二因素应用程序尤其可以直接使用通过环境变量提供的地址信息。
    # 它与现代服务网络有何不同?
    可观察性有限。对于TCP路由网格根本没有度量标准。至于HTTP路由网格,后来的版本提供了详细的HTTP度量,显示错误状态码和响应时间;但是现代服务网格的功能远远不止于此,它还提供了与度量收集系统(例如Prometheus)的集成。

    可观察性非常重要,不仅从操作角度(帮助我们解决问题),还可以提供安全的蓝/绿部署金丝雀部署等功能。

    路由效率也受到限制。在dotCloud路由网格中,所有流量都必须经过一组专用路由节点。这意味着可能跨越几个AZ(可用性区域)边界,并显著增加延迟。我记得对一些代码进行故障排除,这些代码发出100多个SQL请求来显示给定的页面,并为每个请求打开了到SQL服务器的新连接。在本地运行时,页面会立即加载,但在dotCloud上运行时,需要几秒钟,因为每个TCP连接(以及随后的SQL请求)都需要几十毫秒才能完成。在这种特定的情况下,使用持久连接起了作用。

    现代服务网络做得更好。首先,通过确保连接在源位置路由。逻辑流仍然是客户端-->网格-->服务,但是现在网格在本地运行,而不是在远程节点上运行,因此客户端-->网格连接是本地连接,因此速度非常快(微秒而不是毫秒)。

    现代服务网格还实现了更智能的负载平衡算法。通过监控后端的运行及健康状况,它们可以在更快的后端上发送更多的流量,从而提高整体性能。

    随着现代服务网络的出现,安全性也越来越强。dotCloud路由网格完全在EC2 Classic上运行,并且没有加密流量(假设如果有人设法嗅探EC2上的网络流量,那么无论如何都会遇到更大的问题)。现代服务网格可以透明地保护我们所有的通信,例如通过相互的TLS身份验证和随后的加密。
    # 平台服务的流量路由
    OK,我们已经讨论了应用程序是如何通信的,但是dotCloud平台本身呢?

    平台本身由大约100个微服务组成,负责各种功能。其中一些服务接受来自其他服务的请求,而其中一些服务是后台工作应用,它们将连接到其他服务,但不能自己接收连接。无论哪种方式,每个服务都需要知道它需要连接到的地址的端点。

    许多高级服务都可以使用上面描述的路由网格。事实上,dotCloud平台的100多个微服务中有很大一部分是作为常规应用程序部署在dotCloud平台上的。但是少数低级服务(特别是那些实现路由网格的服务)需要一些更简单的东西,需要更少的依赖关系(因为它们不能依靠自己来运行;这是一个老生常谈的“先有鸡还是先有蛋”的问题)。

    通过直接在几个关键节点上启动容器,而不是依赖于平台的构建器、调度程序和运行器服务,部署了这些底层的基本平台服务。如果你想要与现代容器平台进行比较,这就像直接在节点上运行Docker来启动我们的控制平面,而不是让Kubernetes为我们做这件事。这与kubeadmbootkube在引导自托管集群时使用的静态Pod的概念非常相似。

    这些服务以一种非常简单和粗糙的方式被公开:有一个YAML文件列出了这些服务,将它们的名称映射到它们的地址;作为其部署的一部分,这些服务的每个使用者都需要一份该YAML文件的副本。

    一方面,这是非常强大的,因为它不涉及像ZooKeeper那样维护外部键值存储(记住,etcd或Consul在那个时候不存在)。另一方面,这使得服务难以移动。每次移动服务时,它的所有消费者都需要接收更新的YAML文件(并且可能会重新启动)。不太方便!

    我们开始实现的解决方案是让每个消费者都连接到一个本地代理。使用者不需要知道服务的完整地址+端口,只需要知道它的端口号,并通过localhost进行连接。本地代理将处理该连接,并将其路由到实际后端。现在,当一个后端需要移动到另一台机器上,或按比例放大或缩小,而不是更新它的所有消费者,我们只需要更新所有这些本地代理;我们不再需要重新启动消费者。

    (还计划将流量封装在TLS连接中,并在接收端使用另一个代理来打开TLS并验证证书,而不涉及接收服务,该服务将被设置为仅在本地主机上接受连接。稍后会详细介绍。)

    这与AirBNB的SmartStack非常相似;与SmartStack实现并部署到生产环境的显著区别是,当dotCloud转向Docker时,它的新的内部路由网格被搁置了。

    我个人认为SmartStack是诸如Istio、Linkerd、Consul Connect等系统的先驱之一,因为所有这些系统都遵循这种模式:

    • 在每个节点上运行代理
    • 消费者连接到代理
    • 后端改变时,控制平面更新代理的配置
    # 今天实现一个服务网格如果我们今天必须实现类似的网格,我们可以使用类似的原则。例如,我们可以设置一个内部域名系统区域,将服务名映射到127.0.0.0/8空间中的地址。然后在集群的每个节点上运行HAProxy,接受每个服务地址(在127.0.0.0/8子网中)上的连接,并将它们转发/负载平衡到适当的后端。HAProxy配置可以由confd管理,允许在etcd或Consul中存储后端信息,并在需要时自动将更新的配置推送到HAProxy。这就是Istio的工作原理!但是有一些不同之处:
    • 它使用Envoy Proxy而不是HAProxy
    • 它使用Kubernetes API而不是etcd或Consul来存储后端配置
    • 服务在内部子网中分配地址(Kubernetes集群IP地址),而不是127.0.0.0/8
    • 它有一个额外的组件(Citadel),用于在客户机和服务器之间添加相互的TLS身份验证
    • 它增加了对诸如断路、分布式跟踪、金丝雀部署等新特性的支持

    让我们快速回顾一下这些差异。
    ## Envoy Proxy
    Envoy Proxy由Lyft撰写。它与其他代理(如HAProxy、NGINX、Traefik)有许多相似之处,但Lyft编写它是因为它们需要当时这些代理中不存在的功能,而且构建一个新的代理比扩展现有代理更有意义。

    Envoy可以单独使用。如果有一组给定的服务需要连接到其他服务,可以把它连接到Envoy,然后动态地配置和重新配置其他服务的Envoy的位置,而得到很多漂亮的额外的功能,比如域的可观测性。这里,没有使用定制的客户端库,也没有在代码中添加跟踪调用,而是将流量定向到Envoy,让它为我收集指标。

    但Envoy也可以用作服务网格的数据平面。这意味着现在将由该服务网格的控制平面配置Envoy。
    ## 控制平面
    说到控制平面,Istio依赖于Kubernetes API。这与使用confd没有太大的不同。confd依赖etcd或Consul来监视数据存储中的一组密钥。Istio依赖Kubernetes API来监视一组Kubernetes资源。

    Aparte:我个人认为阅读Kubernetes API描述非常有帮助。

    Kubernetes API服务器是一个“哑服务器”,它提供API资源上的存储、版本控制、验证、更新和监视语义。



    Istio是为与Kubernetes合作而设计的;如果你想在Kubernetes之外使用它,则需要运行Kubernetes API服务器的实例(以及支持的etcd服务)。
    ## 服务地址
    Istio依赖Kubernetes分配的集群IP地址,因此Istio得到一个内部地址(不在127.0.0.1/8范围)。

    在没有Istio的Kubernetes集群上,前往给定服务的ClusterIP地址的流量被kube-proxy拦截,并发送到该代理的后端。更具体地说,如果你想确定技术细节:kube-proxy设置iptables规则(或IPVS负载平衡器,取决于它是如何设置的)来重写连接到集群IP地址的目标IP地址。

    一旦Istio安装在Kubernetes集群上,就不会发生任何变化,直到通过将sidecar容器注入到使用者Pod中,显式地为给定的使用者甚至整个名称空间启用Istio。sidecar将运行一个Envoy实例,并设置一些iptables规则来拦截到其他服务的流量,并将这些流量重定向到Envoy。

    结合Kubernetes DNS集成,这意味着我们的代码可以连接到一个服务名,一切都可以正常工作。换句话说,比如我们的代码向`http://api/v1/users/4242`发起一个请求,`api`将解析到10.97.105.48,一条iptables规则将解释连接到10.97.105.48并重定向到本地Envoy代理,本地代理将这个请求路由到实际的API后端。
    ## 额外的铃声和哨声
    Istio还可以通过名为Citadel的组件通过mTLS(双向TLS)提供端到端加密和身份验证。

    它还包括混合器,Envoy组件可以查询每一个请求,对请求进行一个临时的决定取决于各种因素,例如请求头、后端负载(别担心,有丰富的规定以确保混合高度可用,即使它休息,Envoy可以继续代理流量)。

    当然,我提到了可观察性。Envoy在提供分布式跟踪的同时收集大量的度量指标。微服务架构,如果单个API请求必须经过微服务A、B、C和D,分布式跟踪将添加一个惟一的标识符请求进入系统,并保留标识符在子请求中,所有这些微服务允许收集所有相关的调用、延迟等。
    # 自建还是购买
    Istio以复杂著称。相比之下,使用我们今天拥有的工具,构建像我在本文开头描述的那样的路由网格相对比较简单。那么,构建我们自己的服务网格是否有意义呢?

    如果我们有适度的需求(如果我们不需要可观察性,断路器,和其他细节),我们可能想建立自己的。但是如果我们正在使用Kubernetes,我们甚至可能不需要这样做,因为Kubernetes已经提供了基本的服务发现和负载平衡。

    现在,如果我们有高级的需求,购买服务网格可能是一个更好的选择。(由于Istio是开源的,所以它并不总是真正的购买,但是我们仍然需要投入工程时间来理解它是如何工作、部署和运行的。)
    #如何选择Istio、Linkerd和Consul Connect
    到目前为止,我们只讨论了Istio,但它并不是唯一的服务网格。Linkerd是另一个流行的选择,还有Consul Connect

    我们应该选哪一个呢?

    实际上在这一点上我也不好说,我不认为我有足够的了解能够帮助任何人做决策。不过,已经有一些有趣的文章比较它们(12),甚至基准测试

    一种值得一提并且很有潜力的方法是使用像SuperGloo这样的工具。SuperGloo提供了一个抽象层来简化和统一服务网格公开的API。我们可以使用SuperGloo提供的更简单的构造,并无缝地从一个服务网格切换到另一个服务网格,而不是学习各种服务网格的特定API(在我看来,相对复杂)。有点像我们有一个描述HTTP前端和后端的中间配置格式,能够为NGINX、HAProxy、Traefik、Apache生成实际配置

    我已经使用SuperGloo稍微涉足Istio,在未来的博客文章中,我想说明如何使用SuperGloo将Isio或Linkerd添加到现有的集群中,以及后者是否能实现它的承诺,即允许我在不重写配置的情况下从一个路由网格切换到另一个。

    如果你喜欢这篇文章,并且想让我尝试一些具体的场景,我很乐意听到你的消息!

    原文链接:Containers, microservices, and service meshes

    译者:Mr.lzc,软件研发工程师、DevOpsDays深圳组织者&志愿者,目前供职于华为,从事云存储工作,以Cloud Native方式构建云文件系统服务,专注于K8s、微服务领域。

    基于Kubernetes的服务网格简介

    JetLee 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-23 13:51 • 来自相关话题

    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只 ...查看全部
    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只对内部网络开放,然而对于现在流行的应用来说,这并不够。API通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做API版本化,做金丝雀部署,观察并记录每一个请求。这就引入了服务网格。无论你用Linkerd或是Istio,原理上都是一样的。如果你想和更多Service Mesh技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #为什么要用服务网格?

    服务网格并不是和Kubernetes一起出现。然而,因为有Kubernetes,服务网格更容易被引入到你的环境中。有两个逻辑组件组成了服务网格。我们已经有了pod用于承载各个容器。Sidecar是另一个绝好的例子用于扩展和加强pod里面的主要容器。在服务网格语境里,sidecar是服务代理或者数据平面。

    服务网格是云原生的核心组件

    为了更好的理解服务网格,你需要理解代理和反向代理这两个术语。代理,用一句话说,用于接收流量并中转到其它地方。反向代理,从各个地方接收流量并转交给各个服务。这种情况下,所有的客户只和一个代理实例交流。把数据平面想象为一个反向代理。Ingress也是Kubernetes里面用于暴露服务的反向代理。Ingress可以中止SSL,提供基于名称的路由,并且它主要就干这个事情。对于Kubernetes服务也是一样。如果你需要更复杂的路由该怎么做呢?

    下面列举一些其它服务网格可以做的事情:

    * 负载均衡
    * 精细流量策略
    * 服务发现
    * 服务监控
    * 追踪
    * 路由
    * 服务与服务的安全通信

    不仅有sidecar代理,所有的服务网格解决方案还包含控制器,用于定义sidecar容器应该如何工作。服务网格的控制平面是一个集中的、管理所有的服务网格和服务代理的地方。这个控制面板记录网络信息,所以它也是一个网络监控工具。

    所以,为什么要用服务网格?答案很简单,你可以做上面的任何事情并且不需要修改代码。它能够节省时间与金钱。不仅如此,更重要的是,你不能跳过测试,因为它对于初学者太复杂。甚至你可以通过Istio故障注入模拟不同的场景,来测试系统对于失败的反应。
    #Linkerd2与Istio

    在一开始,我提到过两个在Kubernetes上创建服务网格的著名的解决方案。未来也许还会有其它更多的解决方案。每一个产品都试图用自己的方式解决问题,相互之间肯定会有重复的地方。

    Buoyant,这家公司创造了Linkerd,同时还创造了Conduit服务。近期,Conduit被合并到Linkerd项目,称作Linkerd2。buoyant团队把Linkerd服务网格变成了一个更加通用的解决方案。它用Java编写,这意味着它很重。每一个pod会有一个或更多的容器,一个sidecar。Linkerd2设计应用于Kubernetes。它的开发语言包含Go-控制平面,和Rust-一个原生的服务代理,超级轻量、快速并安全。你可以定义重试和超时,定义编排规则,以及加密(TLS),同时还支持根据策略通过或拒绝请求。不仅如此,它还有一个很漂亮的控制台:
    1.png

    Linkerd2_dashboard

    如果你喜欢控制台的话也可以用Linkerd CLI。

    Linkerd的入门向导非常不错,你可以试一试。如果想学习更多,可以看看它的官方文档。

    Istio当前支持Kubernetes和Nomad,将来会添加更多的功能。Istio是一个多平台解决方案。它可以做微服务流量管理,策略应用以及聚合采样信息。Istio也是Go语言编写的轻量应用,但不同于Linkerd2,它使用Envoy来做服务代理。下图说明Istio中各个部分是如何组合工作的:
    2.png

    Istio_architecture

    我喜欢Istio的其中一点是sidecar自动注入,前提是你已经使用Helm来发布应用,这样的话就不需要手工把sidecar注入到kubernetes的配置文件里面。

    在Kubernetes上安装Istio请参考这篇快速指南。其它关于Istio的信息,请参考它的官方文档。

    这两个产品都是开源的。无论哪一个服务网格方式适合你,它们两个都很容易上手实验。不超过5分钟就可以把它跑起来。我鼓励你都去试一试然后再做决定。目前阶段Istio实现的功能比Linkerd2多了很多,并且也是一个稳定版本。
    #总结

    我希望这篇文章很好的介绍了服务网格。这篇文章并不是Linkerd2和Istio之间的比较。我列举了一些功能点,这样你可以了解一下服务网格给Kubernetes带来了什么。请继续关注我们的后续文章。

    原文链接:https://mp.weixin.qq.com/s/6EvdlPbx3NRekG6_BCCNmA

    Service Mesh 的本质、价值和应用探索

    翔宇 发表了文章 • 0 个评论 • 207 次浏览 • 2019-05-22 21:44 • 来自相关话题

    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 ...查看全部
    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。

    网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家至简和他的团队在这一领域探索的过程中想清楚了这两点。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #大规模分布式应用的挑战
    微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。

    在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演进所增加的特性并不是某些业务方所需要的时,这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本,使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

    当微服务框架是单一编程语言独大(Java 在阿里巴巴就是这样的)、不能同步支持好其他多个主流编程语言时(比如 C++、Go、Node.js 等), 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的,最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率,但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护,同样的特性需要用不同的编程语言去实现其成本着实很高。

    也许在企业内部统一单一的主流编程语言并不会带来什么劣势,但当企业需要通过收购其他公司来扩充自己的商业版图时就很可能面临技术栈不统一而带来业务无法低风险、高效率共存演进的挑战。当碰到母子公司的技术栈不统一时,在被收购子公司中进行推倒重建基本上是一件业务价值不大的劳命伤财之事。

    最后,在微服务软件架构所主张的拆分手法下,确实可以将每个拆分出来的服务从监管控层面做到足够的精致,但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同,最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。

    不难想象,采取强有力的团队组织形式、技术规范等手段是很难解决以上挑战的。回归通过技术途径去解决技术挑战才更为有力、有效,这正是 Service Mesh 这一技术可以帮助做好的。
    #Service Mesh 的形态
    Service Mesh 的核心思路与微服务软件架构的思路是一脉相承的,即通过拆分实现解耦——将 SDK 中频繁变更的逻辑与业务逻辑分别放到不同的进程中。下图以 RPC 框架为例示例了这一手法。
    1.jpg

    拆分之后,服务调用的流量通过技术手段以应用无感的形式导入 sidecar 进程。每个服务进程边上新增的 sidecar 使得完整的服务调用链中客户端和服务端分别增加了一跳,这是享受 Service Mesh 技术所需付出的成本。
    #Service Mesh 的挑战
    2.jpg

    第一个挑战来自心智模式需要改变。享受 Service Mesh 所带来的益处是需要付出成本的,这如同单体应用向微服务软件架构转变那样,核心是成本与收益问题。之所以业内仍有不少人纠结于 Service Mesh 的价值,根本原因在于企业的业务规模是否面临 Service Mesh 所致力于解决的那些挑战,如果没有则采纳 Service Mesh 只带来更高的成本而没有收益。

    对于那些服务规模还小的企业,确实没有必要引入尚处于探索和普及阶段的 Service Mesh 的必要。他们可以持续关注业务发展与技术的匹配,在合适的时间点去拥抱新技术。

    第二个挑战来自于技术层面,即如何做到增加 sidecar 后的“路径无损”。具体说来,如何在引入 Service Mesh 的情形下,最大可能地不增加服务的调用延时和消耗更多的 CPU 资源。这是未来需要持续去突破的技术方向。可以预见,突破的途径无外乎“应用层 + 内核层”或“软件 + 硬件”。
    #Service Mesh 的本质
    3.jpg

    无疑,技术发展是服务于业务价值创造的。在单体应用时代,因为软件规模、业务复杂度和参与人员数量的持续增大,使得软件开发和迭代工作因为耦合而举步为艰,这就有了微服务软件架构的出现。那时的业务发展效率问题集中体现于人员协同,在微服务软件架构的需要下产生了 RPC、Messaging 等技术。

    当人员的协同问题通过微服务软件架构得以解决时,随着软件规模、业务复杂度和参与人员数量的进一步增大,需要更好地解决多个业务(或服务)之间的协同问题,而这是 Service Mesh 这一技术的本质。
    #Service Mesh 的价值
    4.jpg

    在 Service Mesh 的形态下,RPC 框架中容易变更的内容被剥离到了 sidecar 进程,之前的胖 SDK 瘦身为只保留了功能恒定的协议编解码能力。如此一来,与 RPC 框架演进相关的逻辑几乎集中在 sidecar 进程中,这就完全可以做到让使用 RPC 框架的业务方无感知地对之进行升级与维护。最终的结果是,业务与 RPC 框架可以做到独立发展与升级,完全消除了之前胖 SDK 所导致的两者相互制约发展的不利局面。这一解耦所带来的好处是,使用 RPC 框架的业务团队可以更加聚焦于业务开发本身,这正是发挥技术价值应达到的境界。

    不难看出,Service Mesh 很好地解决了以往 RPC 框架多语言 SDK 的问题。虽然在 Service Mesh 下仍然需要 SDK,但由于 SDK 中的功能是相当稳定的,不存在应付频繁变更所带来的长期维护成本问题。由于 sidecar 是以进程的形式存在的,因此完全不关心使用 RPC 框架的业务逻辑是用什么编程语言实现的,只需实现一次而没有让人感到无聊的多语言特性对齐问题,将 RPC 框架技术团队的人力释放出来做更有价值的事。

    也因为 sidecar 是以独立进程的形式存在,当出现因为公司收购所面临的母子公司技术栈不一致问题时,可以将 sidecar 部署在两个技术栈的衔接处,由 sidecar 通过协议转换等形式完成两个异构服务框架的连接,为异构服务框架的渐进式融合发展提供了可能,很好地缓解了短期高强度技术改造所面临的技术风险和对业务发展的拖累。

    服务框架易变的功能剥离到了 sidecar 后,意味全网的服务流量治理能力可以通过 sidecar 进行收口——sidecar 自身的版本全网一致、流量规则与执行策略一致、监控口径一致,等等。诸多的“一致”将实现全网服务治理的体系化监管控,使得 Service Mesh 成为微服务软件架构拆分手法下完成横向连接与约束的强有力技术手段。

    如果用一句话来描述 Service Mesh 的话,那就是“层次化、规范化、体系化、无侵入的分布式服务(或应用)治理技术”。
    #Service Mesh 的终局
    5.jpg

    延着 Service Mesh 的切分逻辑,不难预见未来 Service Mesh 所形成的终局是一张大网。这个大网是企业统一且唯一的分布式应用治理的基础设施,其上天然地支持多语言应用的开发。当然,sidecar 是包罗万象地支持 RPC、DB、Messaging,还是衍生出 RPC sidecar、DB sidecar、Messaging sidecar 是仍需探索的主题。
    #Service Mesh 的发展路径
    6.jpg

    新技术诞生于逻辑上能解决当下所面临的技术或业务挑战,但能否真正落地去最大程度地发挥价值却具有不确定性和模糊性。正因如此,不少新技术出现之时存在各种基于自身立场去解读和挖掘其背后的价值,当然也不乏各种质疑之声。所有这一切让业内对挑战看得更加透彻,对新技术的探索也愈加高效。

    根本上,Service Mesh 的出现并非填补了技术空白,不少公司因为曾经有过相似的探索而给人“换汤不换药”的感觉,与今天时兴的云计算在十几、二十年前被称之为分布式计算、网格计算颇有相似之处。当一项新技术不是给人横空出世的感觉时,它的运用与采纳就会经历更多的波折,因为没有它似乎企业的业务发展仍能进行下去。

    在经历了一定的思考和市场感知后,发现 Service Mesh 真正发挥价值是需要分布式应用大到一定的规模并面临一开始所提出的那些挑战,这些在阿里巴巴集团内部都满足。最终我将 Service Mesh 的发展划分成三大阶段。

    阶段一:撬动。新技术被采纳的关键是它能解决业务当下所面临的痛点,阿里巴巴因为 Java 语言一家独大而使得多语言问题相当突出,这使得小众的编程语言乐于拥抱 Service Mesh 去解决自己维护 SDK 或 SDK 特性老旧的痛点。此外,阿里巴巴不时通过收购子公司扩大自己的商业版图,确实经历了异构服务架构共存演进所带来的挑战。

    撬动阶段让新技术得以落地而接触到更多的业务机会并争取到打磨技术的时间窗口,让 Service Mesh 技术团队对于需求的理解和把控更加到位。为进入下一发展阶段提供可能。

    阶段二:做透价值渗透。光解决多语言和异构服务架构共存演进并不足以实现大范围的体系化监管控,需要围绕集团内部更为丰富的业务场景去挖掘 Service Mesh 的价值,并在探索的过程中寻求技术突破去降低引入 Service Mesh 的成本。当分布式应用的体量特别大时,成本问题将变得备受关注。一旦 Service Mesh 的价值得以做透,还得考虑无缝迁移等用户体验使之得以更为方便地应用到更多的业务场景。

    阶段三:实现技术换代。分布式应用的全局、体系化监管控一定是未来云原生时代的强诉求。进入这一阶段代表技术进入了更高层次的集约发展时期,是偿还过去“跑马圈地”和“野蛮生长”所欠下技术债的重大里程碑。在这一阶段,Service Mesh 将成为企业所有分布式应用的基础设施,通过这一设施强有力地执行流量灰度、流量调度去保障业务的持续性,让安全、稳定性问题得以采用一致性、系统性的方案解决。“生长”在 Service Mesh 之上的所有业务完全可以根据团队的技术栈特长以更为经济和高效的方式去发展和探索。
    #Service Mesh 的发展思路
    7.jpg

    Dubbo Mesh 是 Service Mesh 在 Dubbo 生态下的落脚点。其发展不仅立足于在阿里巴巴集团遗留应用场景的包并兼容,还将迎合 Kubernetes 已成计算资源编排王者的大势,让 Service Mesh 在未来以 Kubernetes Way 去提供概念一致、体验一致的技术产品。

    整个 Service Mesh 的发展与探索将走“源于开源,反哺开源,集团内外版本一致”的思路。希望探索之路少走弯路、与更多的同行携手前行,成为开源社区的一名积极建设者。

    最终的技术选型是采用 Istio 的部分组件(Dubbo Control 控制面)和 Envoy(Dubbo Proxy 数据面)形成阿里巴巴自己的解决方案。Istio 中的 pilot-discovery 对于平台的抽象便于扩展支持阿里巴巴最近开源出来的 Nacos 而方便落地,同时为将来集团全面的 Kubernetes 化做好准备。Envoy 的性能与软件质量在很多生产环境上得到了检验,而采用 C++ 能从性能上得到很好的保证,避免有些语言存在 GC(垃圾回收)而带来的不确定性,也便于将来应用层与 OS 层、软件与硬件的结合发展。
    #Service Mesh 的进展
    8.jpg

    目前 Dubbo Proxy 完成了 Dubbo 服务调用统计信息收集的开发工作,这部分代码已合入了 GitHub 上 Envoy 仓库的 master 主干。Dubbo Proxy 全面支持 Dubbo 服务路由的工作正在进行,相信很快这部分代码将出现在开源社区。

    在阿里巴巴集团内部,为了快速落地已经完成 Dubbo over HTTP 技术方案的开发,目前已在两个多语言场景业务方的环境中完成部署并开始着手性能测试和调优工作。内部落地方案中,需要考虑通过 Nacos 与集团内部的 VIPServer、ConfigServer 集群进行对接去完成服务发现,这些对接工作开源社区无需关注,因为开源的 Nacos 已包含阿里集团内部的服务注册与发现和配置管理能力。

    值得一提,pilot-discovery 目前并非集群化部署,而是与 Dubbo Proxy 一样进行了下沉。未来在合适的时机会再考虑将之上拉并形成独立的部署集群。

    原文链接:https://mp.weixin.qq.com/s/PqeI1253SHIkMgv8hPCR5w

    Service Mesh 是什么,我们又为什么需要它?

    明远 发表了文章 • 0 个评论 • 933 次浏览 • 2019-03-29 14:32 • 来自相关话题

    Service Mesh 是一个专门使服务与服务之间的通信变得安全、快速和可靠的的基础设施。如果你正在在构建一个云原生( Cloud Native )应用,那么你一定需要 Service Mesh 。 在过去的一年中, Service ...查看全部
    Service Mesh 是一个专门使服务与服务之间的通信变得安全、快速和可靠的的基础设施。如果你正在在构建一个云原生( Cloud Native )应用,那么你一定需要 Service Mesh 。

    在过去的一年中, Service Mesh 成为了云原生技术栈的关键组件。像 PayPal , Ticketmaster 和 Credit Karma 这样的大厂,已经将 Service Mesh 加入到他们的应用中。并且在 2017 年 1 月,开源的 Service Mesh 软件 Linkerd 加入云原生基金会( CNCF ),成为云原生基金会( CNCF )的官方项目。但是什么是真正的 Service Mesh ?它又为何突然变的如此重要?

    在这篇文章,我会讲解 Service Mesh 的定义,并通过应用服务架构过去十年的发展追溯其起源。并将 Service Mesh 与其他相似的概念,包括 API 网关,边缘代理以及 ESB (enterprise service bus)进行区分。最终,将会描述 Service Mesh 的发展方向,以及随着云原生概念的普及,Service Mesh 发生的变化。
    # 什么是 Service Mesh
    Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施,并让整个架构更为先进和 Cloud Native。在实践中,Service Mesh 基本来说是一组轻量级的服务代理和应用逻辑的服务在一起,并且对于应用服务是透明的。

    Service Mesh 作为独立层的概念与云原生应用的兴起有关。在云原生模式,单个应用可能有数百个服务组成,每个服务又可能有上千个实例,而每个实例都有可能被像 Kubernetes 这样的服务调度器不断调度从而不断变化状态。而这些复杂的通信又普遍是服务运行时行为的一部分,这时确保端到端的通信的性能和可靠性就变的至关重要。
    # Service Mesh 就是一个网络模型吗?
    Service Mesh 是一个位于 TCP/IP 上的抽象层的网络模型。它假定底层 L3/L4 网络存在并且能够从一点向另一点传输数据。(它还假定这个网络和环境的其他方面一样不可靠,所以 Service Mesh 也必须能够处理网络故障。)

    在某些方面,Service Mesh 就像是网络七层模型中的第四层 TCP 协议。其把底层的那些非常难控制的网络通讯方面的控制面的东西都管了(比如:丢包重传、拥塞控制、流量控制),而更为上面的应用层的协议,只需要关心自己业务应用层上的事了。

    与 TCP 不同的是, Service Mesh 想要达成的目的不仅仅是正常的网络通讯。它为应用提供了统一的,可视化的以及可控制的控制平面。Service Mesh 是要将服务间的通信从无法发现和控制的基础设施中分离出来,并对其进行监控、管理和控制。
    # Service Mesh 实际上做了什么?
    在云原生应用中传递可靠的请求是十分复杂的。而 Linkerd 提供了服务熔断、重试、负载均衡、熔断降级等功能,通过其强大的功能来管理那些必须运行在复杂环境中的服务。

    这里列举一个通过 Linkerd 向服务发出请求的简单流程:

    1. 通过 Linkerd 的动态路由规则来确定打算连接哪个服务。这个请求是要路由到生产环境还是演示环境?是请求本地数据中心的服务还是云上的服务?是请求正在测试的最新版的服务还是已经在生产中经过验证的老版本?所有的这些路由规则都是动态配置的,可以全局应用也可以部分应用。
    2. 找到正确的目的服务后,Linkerd 从一个或几个相关的服务发现端点检索实例池。如果这些信息与 Linkerd 的服务发现信息不同, Linkerd 会决定信任哪些信息来源。
    3. Linkerd 会根据观察到的最近的响应延迟来选择速度最快的实例。
    4. Linkerd 发送请求给这个实例,记录延迟和响应类型。
    5. 如果这个实例挂了、无响应或者无法处理请求, Linkerd 会再另一个实例上重试这个请求(但只有在请求是幂等的时候)。
    6. 如果一个实例一直请求失败, Linkerd 会将其移出定时重试的负载均衡池。
    7. 如果请求超时, Linkerd 会主动将请求失效,而不是进一步重试从而增加负载。
    8. Linkerd 会记录指标和分布式的追踪上述行为的各个方面,将他们保存在集中的指标系统中。

    以上只是简化版的介绍, Linkerd 还可以启动和重试 TLS ,执行协议升级,动态切换流量,甚至在故障之后数据中心的切换。
    ad5fbf65ly1g1in1q1jnuj20sg0gbt99.jpg

    值得注意的是,这些功能旨在为每个实例和应用程序提供弹性伸缩。而大规模的分布式系统(无论是如何构建的)都有一个共同特点:都会因为许多小的故障,而升级为全系统灾难性的故障。Service Mesh 则被设计为通过快速的失效和减少负载来保护整个系统免受这样灾难性的故障。
    # 为什么 Service Mesh 是必要的?
    Service Mesh 本质上并不是什么新技术,而是功能所在位置的转变。Web 应用需要管理复杂的服务通信,Service Mesh 模式的起源和演变过程可以追溯到15年前。

    参考2000年左右中型 Web 应用的典型三层架构,在这个架构中,应用被分为三层:应用逻辑、Web 服务逻辑、存储逻辑。层之间的通信虽然复杂,但是毕竟范围有限,最多只有 2 跳。这里并不是 “Mesh” 的,但在每层中处理跳转的代码是存在通信逻辑的。

    当这种架构向更大规模发展的时候,这种通信方式就无以为继了。像 Google、Netflix 和 Twitte ,在面临巨大的请求流量的时候,他们实现了云原生应用的前身:应用被分割成了许多服务(现在称作“微服务”),这些服务组成了一种网格结构。在这些系统中,通用通信层突然兴起,表现为“胖客户端”的形式——Twitter 的 Finagle,Netflix 的 Hystrix 和 Google 的 Stubby 都是很典型的例子。

    现在看来,像 Finagle 、Stubby 和 Hystrix 这样的库就是最早的 Service Mesh。虽然它们是为特定环境、语言和框架定制了,但都是作为基础设施专门用于管理服务间的通信,并(在 Finagle 和 Hystrix 开源的情况下)在其他公司的应用中被使用。

    这三个组件都有应用自适应机制,以便在负载中进行拓展,并处理在云环境中的部分故障。但是对于数百个服务或数千个实例,以及不时需要重新调度的业务层实例,单个请求通过的调用链可能变的非常复杂,而且服务可能由不同的语言编写,这时基于库的解决方案可能就不再适用了。

    服务通信的复杂性和重要性导致我们急需一个专门的基础设施层来处理服务间的通信,该层需要与业务代码解耦,并且具有捕获底层环境的动态机制。这就是 Service Mesh 。
    # Service Mesh 的未来
    Service Mesh 在云生态下迅速的成长,并且有着令人激动的未来等待探索。对无服务器计算(Serverless, 例如 Amazon 的 Lambda)适用的 Service Mesh 网络模型,在云生态系统中角色的自然拓展。Service Mesh 可能成为服务身份和访问策略这些在云原生领域还是比较新的技术的基础。最后,Service Mesh,如之前的TCP / IP,将推进加入到底层的基础架构中。就像 Linkerd 是由像 Finagle 这样的系统发展而来,Service Mesh 将作为单独的用户空间代理添加到云原生技术栈中继续发展。
    # 结语
    Service Mesh 是云原生技术栈的关键技术。Linkerd 成立仅 1 年就成为了云原生基金会(CNCF)的一部分,拥有蓬勃发展的社区和贡献者。使用者从像 Monzo 这样颠覆英国银行业的创业公司,到像 PayPal、 Ticketmaster 和 Credit Karma 这样的互联网大厂,再到像 Houghton Mifflin Harcourt 这样经营了数百年的公司。

    使用者和贡献者每天都在 Linkerd 社区展示 Service Mesh 创造的价值。我们将致力于打造这一令人惊叹的产品,并继续发展壮大我们的社区,加入我们吧

    原文链接:What's a service mesh? And why do I need one?(翻译:郭旭东)

    用Envoy配置Service Mesh

    alex_wang2 发表了文章 • 0 个评论 • 609 次浏览 • 2019-03-15 16:16 • 来自相关话题

    【编者的话】在这篇文章中,我们会简明扼要的介绍一下什么是Service Mesh,以及如何使用Envoy构建一个Service Mesh。 #那什么是Service Mesh呢? Service Mesh在微服务架构体系中属于通信层。所 ...查看全部
    【编者的话】在这篇文章中,我们会简明扼要的介绍一下什么是Service Mesh,以及如何使用Envoy构建一个Service Mesh。
    #那什么是Service Mesh呢?
    Service Mesh在微服务架构体系中属于通信层。所有从微服务发出和收到的请求都会经过Mesh。每个微服务都有一个自己的代理服务,所有的这些代理服务一起构成Service Mesh。所以,如果微服务之间想进行相互调用,他们不是直接和对方进行通信的,而是先将请求路由到本地的代理服务,然后代理服务将其路由到目标的微服务。实际上,微服务根本不了解外部世界,只和本地代理打交道。
    1.png

    当我们讨论Service Mesh的时候,一定听说过一个词叫“Sidecar", 它是一个在服务之间的代理程序,它负责为每一个服务实例服务。
    2.jpeg

    #Service Mesh能提供什么?

    1. ServiceService Discovery
    2. Observability(metrics)
    3. Rate Limiting
    4. Circuit Breaking
    5. Traffic Shifting
    6. Load Balancing
    7. Authentication and Authorisation
    8. Distributed Tracing

    #Envoy
    Envoy是一个用C++语言编写的高性能代理程序。不是一定要使用Envoy来构建Service Mesh,其他的代理程序比如Nginx、Traefix也可以,但是在文本中,我们使用Envoy。

    现在,我们来构建一个3个节点的Service Mesh,下面是我们的部署图:
    3.png

    #Front Envoy
    "Front Envoy"是一个环境中的边缘代理,通常在这里执行TLS termination,authentication生成请求headers等操作……
    ---
    admin:
    access_log_path: "/tmp/admin_access.log"
    address:
    socket_address:
    address: "127.0.0.1"
    port_value: 9901
    static_resources:
    listeners:
    -
    name: "http_listener"
    address:
    socket_address:
    address: "0.0.0.0"
    port_value: 80
    filter_chains:
    filters:
    -
    name: "envoy.http_connection_manager"
    config:
    stat_prefix: "ingress"
    route_config:
    name: "local_route"
    virtual_hosts:
    -
    name: "http-route"
    domains:
    - "*"
    routes:
    -
    match:
    prefix: "/"
    route:
    cluster: "service_a"
    http_filters:
    -
    name: "envoy.router"
    clusters:
    -
    name: "service_a"
    connect_timeout: "0.25s"
    type: "strict_dns"
    lb_policy: "ROUND_ROBIN"
    hosts:
    -
    socket_address:
    address: "service_a_envoy"
    port_value: 8786

    下面是Front Envoy的配置信息:

    主要由4部分组成:1、Listener;2、Routes;3、Clusters;4、Endpoints。
    ##Listeners
    我们可以为一个Envoy配置1个或者多个Listener,从配置文件的第9-36行,可以看到当前侦听器的地址和端口,并且每个Listener可以有一个或多个network filter。通过这些filter,可以实现大多数功能,如routing,tls termination,traffic shifting等。“envoy.http_connection_manager”是我们在这里使用的内置filter之一,除了这个Envoy还有其他几个filter
    ##Routes
    第22-34行是route的相关配置,包括domain(应该接受request的域),以及与每个request匹配后发送到其适当集群中。
    ##Clusters
    Clusters段说明了Envoy将流量转发到哪个upstream Services。

    第41-50行定义了“service_a",这是“Front Envoy"将要与之通信的唯一的upstream service。

    "connect_timeout"是指如果连接upstream服务器的时间超过了connect_timeout的制定,就会返回503错误。

    通常会有多个“Front Envoy"实例,Envoy支持多个负载平衡算法来路由请求。这里我们使用的是round robin。
    ##Endpoints
    "hosts"指定了我们会将流量转发到哪里,在本例中,我们只有一个Service A。

    在第48行,你可以发现,我们并不是把请求直接发送到Service A,而是发给了Service A的Envoy代理service_a_envoy,然后将其路由到本地Service A实例。

    还可以注意到一个service的名字代表了所有的对应的实例,就类似Kubernetes里的面的headless service。

    我们在这里做一个客户端的负载均衡。Envoy缓存了所有Service A的实例,并且每5秒刷新一次。

    Envoy支持主动和被动两种方式的健康检查。如果想使用主动方式,那就在cluster的配置信息里设置。
    ##Others
    第2-7行是关于管理方面的,比如日志级别,状态查看等。

    第8行是"static_resources",意思是手动加载所有的配置选项,稍后的内容中我们会做详细介绍。

    其实配置的选项还有很多,我们的目的不是介绍所有的选项及其含义,我们主要是想用一个最小的配置范例做一个入门介绍。
    #Service A
    下面是一个Service A在Envoy的配置:
    admin:
    access_log_path: "/tmp/admin_access.log"
    address:
    socket_address:
    address: "127.0.0.1"
    port_value: 9901
    static_resources:
    listeners:

    -
    name: "service-a-svc-http-listener"
    address:
    socket_address:
    address: "0.0.0.0"
    port_value: 8786
    filter_chains:
    -
    filters:
    -
    name: "envoy.http_connection_manager"
    config:
    stat_prefix: "ingress"
    codec_type: "AUTO"
    route_config:
    name: "service-a-svc-http-route"
    virtual_hosts:
    -
    name: "service-a-svc-http-route"
    domains:
    - "*"
    routes:
    -
    match:
    prefix: "/"
    route:
    cluster: "service_a"
    http_filters:
    -
    name: "envoy.router"
    -
    name: "service-b-svc-http-listener"
    address:
    socket_address:
    address: "0.0.0.0"
    port_value: 8788
    filter_chains:
    -
    filters:
    -
    name: "envoy.http_connection_manager"
    config:
    stat_prefix: "egress"
    codec_type: "AUTO"
    route_config:
    name: "service-b-svc-http-route"
    virtual_hosts:
    -
    name: "service-b-svc-http-route"
    domains:
    - "*"
    routes:
    -
    match:
    prefix: "/"
    route:
    cluster: "service_b"
    http_filters:
    -
    name: "envoy.router"

    -
    name: "service-c-svc-http-listener"
    address:
    socket_address:
    address: "0.0.0.0"
    port_value: 8791
    filter_chains:
    -
    filters:
    -
    name: "envoy.http_connection_manager"
    config:
    stat_prefix: "egress"
    codec_type: "AUTO"
    route_config:
    name: "service-b-svc-http-route"
    virtual_hosts:
    -
    name: "service-b-svc-http-route"
    domains:
    - "*"
    routes:
    -
    match:
    prefix: "/"
    route:
    cluster: "service_c"
    http_filters:
    -
    name: "envoy.router"
    clusters:
    -
    name: "service_a"
    connect_timeout: "0.25s"
    type: "strict_dns"
    lb_policy: "ROUND_ROBIN"
    hosts:
    -
    socket_address:
    address: "service_a"
    port_value: 8081
    -
    name: "service_b"
    connect_timeout: "0.25s"
    type: "strict_dns"
    lb_policy: "ROUND_ROBIN"
    hosts:
    -
    socket_address:
    address: "service_b_envoy"
    port_value: 8789

    -
    name: "service_c"
    connect_timeout: "0.25s"
    type: "strict_dns"
    lb_policy: "ROUND_ROBIN"
    hosts:
    -
    socket_address:
    address: "service_c_envoy"
    port_value: 8790

    上面定义了一个listener,用于将流量路由到实际的"Service A"的实例,您可以在103–111上找到Service A实例的相应cluster定义。

    "Service A"与“Service B"和“Service C"通信,因此分别创建两个listener和cluster。在这里,我们为每个upstream(localhost、Service B和Service C)都有单独的listener,另一种方法是创建一个listener,然后根据url或headers路由到upstream。
    #Service B & Service C
    Service B和Service C是最下层的服务,除了和本地服务实例通信外,没有其他的upsteam,所以他们的配置信息比较简单,如下:
    admin:
    access_log_path: "/tmp/admin_access.log"
    address:
    socket_address:
    address: "127.0.0.1"
    port_value: 9901
    static_resources:
    listeners:

    -
    name: "service-b-svc-http-listener"
    address:
    socket_address:
    address: "0.0.0.0"
    port_value: 8789
    filter_chains:
    -
    filters:
    -
    name: "envoy.http_connection_manager"
    config:
    stat_prefix: "ingress"
    codec_type: "AUTO"
    route_config:
    name: "service-b-svc-http-route"
    virtual_hosts:
    -
    name: "service-b-svc-http-route"
    domains:
    - "*"
    routes:
    -
    match:
    prefix: "/"
    route:
    cluster: "service_b"
    http_filters:
    -
    name: "envoy.router"

    clusters:
    -
    name: "service_b"
    connect_timeout: "0.25s"
    type: "strict_dns"
    lb_policy: "ROUND_ROBIN"
    hosts:
    -
    socket_address:
    address: "service_b"
    port_value: 8082

    可以看出Service B和Service C的配置没什么特别的,仅仅一个listener和一个cluster。

    至此,我们完成了所有的配置文件,现在可以把他们部署到Kubernetes集群或者`docker-compose`里面了。运行`docker-compose build and docker-compose up` 并且访问`localhost:8080`端口。如果一切都没问题,那么http的访问请求会穿过所有的service和Envoy的proxy,并且在logs里可以看到这些记录。
    #Envoy xDS
    我们完成了对Sidecar的配置,设置了不同的service。如果我们仅仅有2到3个Sidecar和service的时候,手工配置还算OK,但是当服务的数量变得越来越多,手动配置几乎就是不太可能的了。并且一旦Sidecar的配置改动后,还需要手动进行重启那就更麻烦了。

    在刚开始我们提到过为了避免手工修改配置和加载组件,Clusters(CDS),Endpoints(EDS),Listeners(LDS)& Routes(RDS) 使用了api server。所以Sidecar会从api server读取配置信息,并且会动态更新到Sidecar里,而不是重启Sidecar程序。

    更多的关于动态配置可以点击这里查看,点击这里可以看到关于xDS的示例。
    #Kubernetes
    这个小结中我们可以看到,如何在Kubernetes集群中配置Service Mesh:
    4.png

    所以我们需要做如下工作:

    1. Pod
    2. Service

    ##Pod
    通常情况下,一个Pod里面之运行一个container,但其实在一个Pod里可以运行多个container,因为我们想为每个service都运行一个Sidecar的proxy,所以我们在每个Pod里都运行一个Envoy的container。所以为了和外界进行通信,service的container会通过本地网络(Pod内部的local host)和Envoy Container进行通信。
    apiVersion: apps/v1beta1
    kind: Deployment
    metadata:
    name: servicea
    spec:
    replicas: 2
    template:
    metadata:
    labels:
    app: servicea
    spec:
    containers:
    - name: servicea
    image: dnivra26/servicea:0.6
    ports:
    - containerPort: 8081
    name: svc-port
    protocol: TCP
    - name: envoy
    image: envoyproxy/envoy:latest
    ports:
    - containerPort: 9901
    protocol: TCP
    name: envoy-admin
    - containerPort: 8786
    protocol: TCP
    name: envoy-web
    volumeMounts:
    - name: envoy-config-volume
    mountPath: /etc/envoy-config/
    command: ["/usr/local/bin/envoy"]
    args: ["-c", "/etc/envoy-config/config.yaml", "--v2-config-only", "-l", "info","--service-cluster","servicea","--service-node","servicea", "--log-format", "[METADATA][%Y-%m-%d %T.%e][%t][%l][%n] %v"]
    volumes:
    - name: envoy-config-volume
    configMap:
    name: sidecar-config
    items:
    - key: envoy-config
    path: config.yaml

    在container配置段,我们可以看到关于sidecar的配置信息,我们在33到39行通过configmap mount了Envoy的配置。
    ##Service
    Kubernetes的service负责代理Pod的路由转发信息。用kube-proxy作为负载均衡(译者注:现在早已经不是kube-proxy负载了) 。但是在我们的例子中,我们采用客户端负载均衡,所以我们不适用kuber-proxy,我们要得到所有运行sideproxy的Pod的list,然后用"headless service"去负载。
    kind: Service
    apiVersion: v1
    metadata:
    name: servicea
    spec:
    clusterIP: None
    ports:
    - name: envoy-web
    port: 8786
    targetPort: 8786
    selector:
    app: servicea

    第六行标注了service headless,你可以发现我们并没有mapping Kubernetes的service端口到应用的服务端口,而是mapping了Envoy的监听端口,所以流量会转发到Envoy。

    通过以上的配置,Service Mesh应该可以运行在Kubernetes里面了,从这个连接可以找到文章中提到的所有demo。

    原文连接:Service Mesh with Envoy 101(翻译:王晓轩)

    为什么 Service Meshes,容器编排工具是云原生部署的必然选择?

    samzhang 发表了文章 • 0 个评论 • 567 次浏览 • 2019-03-11 09:31 • 来自相关话题

    【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝 ...查看全部
    【编者的话】Service Mesh 通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。

    独立,短暂的微服务过程带来了一些重大好处,但是保持跟踪每一个单独的微服务是一个挑战,特别是尝试去弄清楚当一个微服务下线后,剩下的服务会受到什么样的影响。最终的结果是,如果你正在一个微服务架构下运营或开发,那么你的一部分时间将会被消耗在搞清楚你的服务到底是什么上。

    随着微服务的采用,大型系统中存在大量服务,因此出现问题不可避免。诸如,安全,负载均衡,监控和限速这些问题,过去不得不同意解决,而现在,不得不单独为每个服务一一解决。

    幸好工程师乐于这样的挑战。而且每当微服务产生新的问题时,他们都会通过新兴的微服务工具和技术来定位这些问题。也许微服务的出现只是工程师确保饭碗的智能游戏。

    如今Cloud Native的宠儿Kubernetes,缓解了微服务带来的许多挑战。自动调度,横向扩展和服务发现,解决了大多在微服务中构建和部署服务将遇到的问题。

    Kubernetes 留下了一些尚未解决的容器化应用环境的问题。这就是 Service Mesh 的介入点。让我们看一下 Kubernetes 提供了什么,和 Istio 如何增强 Kubernetes 解决微服务运行环境的问题。
    #Kubernetes 解决了构建和部署的挑战
    容器编排工具,诸如 Kubernetes,解决了许多来自于容器化应用的构建和部署的挑战。

    Kubernetes 支持微服务架构,使开发者能够抽象出一组 Pod 的功能,并且通过明确的 API 来曝露服务给其他开发者。Kubernetes 支持四层负载均衡,但是不能解决更高层的问题,例如,七层指标、流量分流、限速和断路。
    #Service Mesh 解决了运行时管理流量的挑战
    Service Mesh 有助于解决最终用户使用应用程序时出现的许多挑战。能够监控哪些服务相互通信,他们的通信是否安全和是否能够控制你的集群中服务和服务间的通信,这是确保你的应用安全和弹性运行的关键。

    通过在整个过程中生成统一的度量标准,Istio 可以在微服务架构中提供一致的视图。它消除了协调各种运行时代理发出的不同类型的度量标准的需要,或添加任意代理来收集旧的未检测应用程序的度量标准。它在您的多语言服务和集群中增加了一定程度的可观察性,这在任何其他工具的细粒度水平上是无法实现的。

    Istio 还增加了更深层次的安全性。Kubernetes 仅提供基本的秘密分发和控制平面证书管理,但是 Istio 提供 mTLS 功能,因此您可以对线路流量进行加密,以确保您的服务间通信是安全的。
    #完美的匹配
    将 Kubernetes 与 Istio 配对可以为您提供两全其美的优势,而且由于 Istio 是在 Kubernetes 上运行的,因此两者可以无缝协作。您可以使用 Kubernetes 来管理所有构建和部署需求,Istio 负责处理重要的运行时问题。

    Kubernetes 已经成熟到大多数企业都将其用于集装箱编排。目前,有 74 家 CNCF 认证的服务提供商,这证明了市场规模庞大且不断增长。我认为 Istio 是 Kubernetes 的延伸,为了解决更多挑战。

    Istio 已经快速成熟,并开始在企业中更多地采用。可能在 2019 年,我们将看到 Istio 成为企业的服务网格标准,就像 Kubernetes 作为集装箱编排的标准一样。

    原文链接:Why Service Meshes, Orchestrators Are Do or Die for Cloud Native Deployments(翻译:Sam)

    什么是Service Mesh?

    尼古拉斯 发表了文章 • 0 个评论 • 907 次浏览 • 2019-02-22 23:00 • 来自相关话题

    【编者的话】在前面的文章中,小码农介绍过《基于SpringCloud的微服务演进之路》,作为一款最近两年比较火的微服务框架Spring Cloud已经在不少创业型互联网公司落了地,然而无奈变化太快,这不还没来得及熟悉Spring Cloud的全部组件,就猛然发 ...查看全部
    【编者的话】在前面的文章中,小码农介绍过《基于SpringCloud的微服务演进之路》,作为一款最近两年比较火的微服务框架Spring Cloud已经在不少创业型互联网公司落了地,然而无奈变化太快,这不还没来得及熟悉Spring Cloud的全部组件,就猛然发现了Service Mesh的崛起,而Spring Cloud就显得有点过时了。

    和大部分吃瓜码农一样,刚开始小码农对此也是一头雾水。那么什么是Service Mesh?它与Spring Cloud相比有什么优势呢?在接下来的内容中,就和大家一起初步了解下Service Mesh吧!
    #微服务的核心问题

    在了解Service Mesh之前,我们先来讨论下这样一个问题:“微服务架构的核心技术问题是什么?”。

    我们知道在将整个软件系统架构升级为微服务模式以后,服务(这里是指独立对外提供服务的进程实体)的规模会越来越大,少则几个到十几个,多则上百个。而这,还只是从应用拆分本身的数量上看的,在实际的生产部署中,单个微服务进程也不会以单节点的方式部署,而多是以集群的方式进行部署。

    此时自然就会产生两个核心的问题:一是服务发现,即服务的消费方(Consumer)如何发现服务的提供方(Provider)的问题?二是负载均衡,即我们的微服务在以集群方式部署后,服务的消费方如何以某种负载均衡策略访问集群中的微服务实例?

    在回答以上两个问题时,我们先来回顾下目前业界经历过的三种服务发现及负载模式:
    ##模式一:传统集中式代理

    这种模式在微服务架构模式兴起之前,是业界非常主流的模式,目前大部分公司的架构模型依然采用的是这种模式。
    01.jpg

    在集中式处理方式中,应用系统根据各自需要进行模块化设计与拆分,虽然呈现了一定分布式的特性,但是在服务间调用时,仍然需要通过F5或Nginx这类软硬件负载均衡器来进行通信,从而保证高可用。

    并且这种方式的服务注册更多的是一种依赖于运维人员、手工配置、明确调用的方式。在实践中一般是通过DNS域名解析服务的方式配合实现,通过在Nginx或F5上建立服务域名和服务IP/端口之间的映射关系,来实现消费端通过请求服务域名,域名指向代理(Nginx/F5),代理通过解析目标IP地址并最终进行负载均衡和服务调用。

    这种架构模式,目前依然是最为普遍的一种方式,即便很多互联网公司最终会转向微服务时代的模式二、模式三,但是在其初创期仍然会选择这种方式进行过渡。
    ##模式二:客户端嵌入式代理

    这种方式就是目前以Spring Cloud框架为代表的微服务架构模式所使用的方式,包括在此之前比较著名的Dubbo框架采用的也这样的方式。在这种模式下,服务发现和负载均衡逻辑都是以本地库的方式嵌在具体的应用中。

    这种模式一般需要独立的服务中心注册组件配合,服务启动时自动注册到服务中心并定期上报心跳,客户端代理则通过注册中心进行服务发现并进行负载均衡。
    02.jpg

    在之前的文章中(推荐阅读有链接)我们介绍的基于Spring Cloud的微服务架构就是通过采用Consul作为注册中心,客户端通过集成Spring Cloud提供的相关本地组件(@EnableDiscoveryClient),进行服务调用时通过FeignClient(底层采用Ribbon)实现了服务的发现与负载均衡。

    客户端嵌入的模式,在应用本身嵌入了服务发现&负载均衡的逻辑,虽然像Spring Cloud这样的框架提供了很方便快捷的开发集成,但因为应用本身的业务逻辑与底层通信逻辑耦合在了一起,从架构角度看会显得让人有点不是很爽的感觉,当然这种缺陷,也在某些层面的确限制了很多的能力,在我们具体讨论Service Mesh时再和大家讨论。

    从目前的实践看,因为微服务架构的概念最近几年才开始流行,加上Spring Cloud的热度,以及之前Dubbo等框架的助推,目前很多互联网公司的微服务架构体系都是基于这种模式进行的。作者所在的公司,目前也主要是基于Spring Cloud框架进行的一些实践,当然,因为最近Service Mesh的火热,也在逐步开始进行新的架构尝试。

    在这里,还需要特别澄清一下,这种模式也并非完全是对模式一的替代,这种架构方式的主要关注点在于内部服务的治理,对于需要通过互联网访问的服务,我们依然需要通过F5/Nginx之类软硬件负载均衡器进行负载均衡,例如在这种模式下API Gateway在向外提供公网服务时,仍然是通过DNS+Nginx进行的扩展。
    ##模式三:独立式进程代理

    这种模式其实上面两种模式的一种折中方案,用于实现服务发现和负载均衡的代理(Proxy)既不是独立集中部署(像F5/Nginx),也不是嵌入在客户应用程序中(像Ribbon)。而是作为一个独立的进程部署在每一台主机上,主机上的多个消费者(Consumer)应用可以共用这个代理来实现服务发现和负载均衡。
    3.jpg

    这种模式相比较于模式二而言,也需要独立的服务注册中心组件配合。只是将负责服务发现、负载均衡、熔断限流等相关逻辑从原有的消费客户端进程拆分到单独的代理进程中了,由这个独立部署的代理来负责服务发现、路由分流(负载均衡)、熔断限流、安全控制、监控等功能。
    #Service Mesh(服务网格)

    在了解完以上三种模式后,我们再来一起探讨下什么是Service Mesh?Service Mesh又称为服务网格,本质上就是我们前面介绍过的模式三。之所为称之为服务网格是因为按照模式三的结构,每个主机上同时运行了业务逻辑代码和代理,此时这个代理被形象地称之为SideCar(业务代码进程相当于主驾驶,共享一个代理相当于边车),服务之间通过SideCar发现和调用目标服务,从而形成服务之间的一种网络状依赖关系,然后通过独立部署的一种称之为控制平面(ControlPlane)的独立组件来集中配置这种依赖调用关系以及进行路由流量调拨等操作,如果此时我们把主机和业务逻辑从视觉图上剥离,就会出现一种网络状的架构,服务网格由此得名。
    04.jpg

    05.png

    在新一代的Service Mesh架构中服务消费方和提供方的主机(或容器)两边都会部署代理SideCar,此时SideCar与服务所在的主机又称之为数据平面(DataPlane),与我们前面说到的用于依赖关系配置和流量调拨操作的控制平面相对应。
    #Istio

    通过上述的内容,我们从概念上应该是大概理解了什么是Service Mesh。而具体要落地Service Mesh只有概念是远远不够的,相反,如果没有一种可落地执行的开源框架,这个概念也不会这么快被大家所接受。

    Istio就是目前受Google/IBM等大厂支持和推进的一个Service Mesh开源框架组合。它解决了开发人员和运维人员在整体应用程序向分布式微服务体系结构过渡时所面临的挑战。我们知道无论是基于Spring Cloud的微服务架构体系还是目前我们说到的Service Mesh,随着微服务规模的增长会带来很多的复杂性,如服务发现、负载均衡、故障恢复、监控,甚至A/B测试、访问控制等。而要对涉及这些问题的微服务架构体系进行管理,如果没有成熟的组件的话,就会需要耗费很多的精力去开发一些运维工具,而这个成本是非常高的。

    而Istio则提供了一个完整的解决方案来满足微服务应用程序的各种需求。下图是Istio官网(https://istio.io)所展示的关于Istio的一张架构图:
    06.jpg

    在这张架构图中Istio服务网格在逻辑上还是分为数据平面和控制平面。数据平面中的SideCar代理是由一款叫做Envoy的组件来承担的,它是一款用C++开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量。

    Envoy提供了很多内在的特性如:

    * 动态服务发现
    * 负载均衡
    * TLS终止
    * HTTP/2和gRPC代理
    * 熔断器
    * 健康检查
    * 基于百分比的流量分割
    * 故障注入
    * 丰富的指标

    从上面的特性上看实际上Envoy已经提供了很完备的SideCar的功能,只是由于其采用的是C++开发的,目前在国内的落地实践中会有不同的取舍和选择,如蚂蚁金服内部在实践的过程中就没有使用Istio默认集成的Envoy,而是用Golang开发了新的SideCar,已经开源的SOFAMosn,来替代Envoy。

    在Istio控制平面中的各个组件的作用如下:

    * Mixer:负责收集代理上采集的度量数据,进行集中监控;
    * Pilot:主要为SideCar提供服务发现、智能路由(如A/B测试)、弹性(超时、重试、断路器)的流量管理功能;
    * Citadel:负责安全控制数据的管理和下发;

    以上就是关于Istio及其组件的一些介绍,具体如何使用Istio进行服务开发及安装操作,大家可以看看Istio的官网,另外需要强调的是kubernetes是目前 Isito 主力支持的容器云环境。
    #Service Mesh的优势

    事实上Service Mesh这种架构模式并不新鲜,很早就有公司进行过尝试,之所以最近又火起来的原因,主要还是因为模式一、模式二的确有一些固有的缺陷,模式一相对比较重,有单点问题和性能问题。

    而模式二则有客户端复杂,支持多语言困难,路由、熔断、限流等服务操作无法集中治理的问题。而Service Mesh则正好弥补了二者的不足,它是纯分布式的,没有单点的问题,性能也比较优秀并且与开发语言无关,还可以集中进行治理。

    此外,随着微服务化、多语言和容器化的发展趋势,很多公司也迫切需要一种轻量级的服务发现机制,加上一些大厂如Google/IBM的助推(如Kubernetes与Docker的容器之争),正好Service Mesh迎合了这种趋势,所以才有今天火热的局面。
    #实践案例

    目前国内如阿里、微博、摩拜等公司都在积极探索Service Mesh的架构模式,只是在实践中一般具备一定开发能力的公司都会选择基于Istio进行二次开发,如目前阿里开源的SOFAMesh/SOFAMosn两个项目。

    而对于开发及运维能力不强的公司,是否有必要将自己的架构体系立刻升级为Service Mesh模式还是需要好好考虑考虑,因为毕竟这会带来很大的运维成本。

    以上就是小码农关于Service Mesh的一点认识和见解,由于水平有限,不足之处还请多多包涵!

    原文链接:https://mp.weixin.qq.com/s/iSzQgsK4ANoCV0daIHMuNw

    DockOne微信分享(二零二):房多多Service Mesh实践

    大卫 发表了文章 • 0 个评论 • 854 次浏览 • 2019-02-22 10:13 • 来自相关话题

    【编者的话】随着微服务数量越来越多,给业务开发团队的增加了沟通和维护的成本,为了解决这一的痛点,我们关注到了Service Mesh技术,本次分享主要介绍房多多在Service Mesh中的一些经历和过程,以及在工程效率方面的一些感悟。 #概述和 ...查看全部
    【编者的话】随着微服务数量越来越多,给业务开发团队的增加了沟通和维护的成本,为了解决这一的痛点,我们关注到了Service Mesh技术,本次分享主要介绍房多多在Service Mesh中的一些经历和过程,以及在工程效率方面的一些感悟。
    #概述和需求背景

    房多多国内领先的经纪人直卖平台,目前房多多APP和多多卖房APP的后端服务主要运行在自建的IDC机房。2018年之前,我们的服务都是运行在VM上,也同时基本上完成了基于Dubbo的微服务改造,目前的语言技术栈主要有:Java、Node.js、Golang。相对于其他公司而言,技术栈不是特别分散,这给我们服务容器化带来了极大的便利。

    我们在2018年Q3的时候已经完成大部分服务容器化,此时我们的微服务数量已经超过400个了,在沟通和维护上的成本很高。因为我们后端服务是主要是基于Dubbo的,跟前端直接的交互还是通过http的方式,在没有上Service Mesh之前,http请求都是经过Nginx转发的。维护Nginx的配置文件是一个工作量大且重复性高的事情,运维团队和业务团队迫切的需要更高效的方案来解决配置管理和沟通成本的问题,构建房多多Service Mesh体系就显得尤为重要。Envoy是一个成熟稳定的项目,也能够满足近期的需求,在现阶段我们并没有人力去动Envoy,所以我们直接使用了Envoy做Service Mesh的数据平面,关于控制平面这块,在调研了一些方案之后,我们采用了自研的方案。
    #整体平台架构

    我们的容器平台整体是基于物理机的,除了调度节点是用的虚拟机以外,所有的工作节点都是使用物理机。之前我们的虚拟化方案是用的Xenserver,Xenserver对高版本的内核支持并不好,会时不时的出现自动虚拟机关机的bug,所以我们在工作节点上只使用物理机以保障业务的稳定和高效。

    我们的业务主要工作在自建IDC机房,公有云只有少量的灾备服务。因为是自建机房,相比较公有云而言,自建机房使用Macvlan是一个比较好的方案。我们预先划分了几个20位地址的子网,每个子网内配置一些物理机,通过集中式的IP管理服务去管理物理机和容器的IP。相比较bridge网络,Macvlan网络有着非常接近物理网络的性能,尤其是在大流量场景下性能出色,下面一张图显示了性能对比:
    1.png

    2.png

    3.png

    我们把Envoy作为两个网络之间的连接桥,这么做的好处在于可以控制流量都经过负载均衡器,便于集中管理以及对流量做分析。看到这里,肯定有疑问是为什么不使用Sidecar的方式部署Envoy。关于Sidecar我的考虑是,在现有的业务场景下,集中部署的维护成本更低且性能满足需求,也相对来说比较简单。我们在2018年Q4已经完成主要业务http2接入,目前来看,我们的网站速度应该是同行业中最快的,大家可以体验一下,https://m.fangdd.com 。
    4.png

    #如何解决虚拟机业务和容器业务的并存问题

    我们原有的架构大量使用了虚拟机,迁移虚拟机上面的服务是一个漫长的过程,当前阶段还需要解决业务的并存问题,我们自己开发了Envoy对应的配置集中管理服务,同时支持虚拟机服务和容器服务。

    控制平面服务主要基于data-plane-api开发,功能上主要是给数据平面提供服务的集群配置、路由配置等信息,并且需要实现微服务架构中降级和限流的配置功能。容器内部的集群数据主要依赖DNSRR实现,而虚拟机上的服务,我们在CMDB上存有AppID和机器的对应关系,很容器生成集群配置数据。


    由于历史原因,还有相当多的业务无法从VM迁移到容器,需要有一个同时兼容容器和VM的数据平面服务,目前XDS服务的支持的功能如下:

    * 集群数据来源同时包括容器内部DNS和外部CMDB中的VM数据
    * 支持多个 vhost 配置
    * 支持路由配置
    * 支持速率控制和网关错误重试

    5.png

    #应用开发流程变化

    初步建设起Service Mesh体系之后,理论上业务开发只需要开发一个单体服务,在服务间互相调用的过程中,只需要知道服务名即可互相调用,这就很像把所有服务都看做一个微服务一样,所以我们的业务开发流程发生了以下变化:
    6.png

    同时也降低了框架开发成本和业务改动的成本,每次推动业务升级框架都需要比较长的一段时间,业务无法及时用上新框架的功能,多种框架版本也加重运维负担,Service Mesh帮我们解决了很多痛点。同时再加上我们的网关层建设,我们上线一个新服务几乎是零配置成本的。

    * 代理层实现服务发现,对于开发而言只需要开发一个单机的应用,降低框架开发成本
    * 降级和限流都在代理层实现,规则灵活,方便修改策略
    * 框架功能的升级无需依赖业务

    #SOA和Service Mesh的对比与取舍

    在我们的Service Mesh实践中,增加了链路的请求长度,并且服务的链路越长,链路请求的放大效应会越明显,这就带来了一些性能上面的担忧。毫无疑问,Mesh层本身的业务逻辑开销是不大,但是在网络传输和内存复制上的性能消耗在一定程度上会影响链路的性能,Envoy也在探索相关的方案来优化网络传输性能,如Bpfilter和VPP,减少用户态和内核态的内存拷贝。在可定制性层面,SOA能做的事情也相对较多,可以实现很多hack的需求。

    在我们现有的业务场景下,Service Mesh主要还是解决前后端的微服务对接问题,当做前后端服务的连接桥梁。但不可否认的是,Service Mesh带来研发效率的提升,在现有的场景下的价值远大于性能上的损失。在大多数的场景下,维护业务框架需要比较大的人力成本,很多团队都没有全职的人去维护业务框架。此外,推动业务框架的更新和升级也相对来说成本较高,这也是我们考虑的一个重要方面。
    #总结

    得益于云原生架构,Service Mesh可以使用云原生的基础设施,基础设施能力的改进可以直接赋能业务,而不像传统的框架一样,基础设施的升级和改进无法提高传统框架的服务能力。房多多的Service Mesh还处于初级阶段,后面还将继续探索。
    #Q&A

    Q:容器和微服务的区别以及它们的关联性、应用场景、客户群体、带来的价值?
    A:微服务的应用场景主要是解决降低单个服务体积,满足业务的快速开发需求。容器可以说是微服务的载体,容器方面还是运维关注的比较多,带来的标准化流程和环境的提升对整个研发团队都有很大的作用。

    Q:软件实现 Service Mesh,Istio?
    A:我们目前只使用了Envoy,Istio也做过一些选型的调研,不是很符合我们现在的业务场景和业务需求,我们在之后的实践中会考虑使用一部分Istio的功能。

    Q:实施过程当中有使用到Istio吗?有定制一些Mixer适配器吗?
    A:目前还没有用,之后会考虑是用Istio中的pilot,我们目前在流量的控制的精细程度上面还欠缺,粒度还很粗。

    Q:请问,实现微服务过程中有没有考虑分布式跟踪和分布式?
    A:Service Mesh层可以做到简单的分布式追踪,比如可以做到基于请求的追踪,Envoy可以把trace数据接入Zipkin这样的trace系统,但是更细粒度的trace目前还做不到。

    Q:不论是使用都会产生大量的配置(yaml),尤其是Envoy/Istio,系统中会有大量零散的配置文件,维护困难,还有版本管理,有什么很好的维护实践经验吗?谢谢。
    A:是的,据我所知有些团队会使用ConfigMap来管理配置,我们做了一个配置的集中管理服务,从CMDB和DNS定时的抓取数据,数据会存在数据库里面,也会存一定量的副本用于配置回退,这个地方还是要结合你们现在其他配套系统的建设来看看怎么做比较好的。

    Q:有没有遇到过Envoy被oom kill的情况,你们是如何处理的?
    A:这个我有碰到过一次,之前我们在对Envoy做测试的时候,发现Envoy总会尽可能的占满CGroup的内存大小,这个之前在使用TLS的情况下碰到的比较多。但是目前我们内部服务间使用TLS的情况并不多,所以后续这个问题就没有继续跟进了。

    Q:性化方案有哪些?
    A:之前文章中有提到过,对于http服务可以全量接入http2,http2的长连接和多路复用对于一般的业务来说升是很明显的,我们在全量接入http2之后,网站的响应时间几乎下降了50%。另外还可以在底层的依赖上面做一些优化,比如底层的libc库,以及尽可能的减少基础镜像的大小,我们基本上所有业务都使用了alpine,这样可以保证发布性能和速度在一个很好的水平上。

    Q:还是有一个服务治理/配置管理的问题请教,比如CPU,内存,这种资源request,在dev,test,staging,prod环境均不同,那么我们在编写Kubernetes配置的时候不同环境会不同,比如测试环境的replics数跟CPU需求就很低,生产就很高,另外这个配置在不同环境是多个还是一个呢?谢谢。
    A:我们现在会在CMDB里面维护这些配置数据,一般来说在新建项目的时候,我们就会要求业务线评估一下这个业务需要的资源,比如你说到的test和staging环境这种,我们默认会给一个很低的需求,比如1c1g这样的,而且replication也会默认设置为1,除非业务有特殊的需求,然后我们去根据配置的数据去生成yaml格式为配置。
    配置在数据存储的形式上是多个,但是在对业务展示上,尽量让业务感觉到是一个数据,这样也能使每个环境都规范起来,跟生产环境尽可能保持一致,这个对测试的好处还是很大的。

    Q:你们目前的项目中,大量的微服务,以及调度层,瓶颈和容灾是如何处理的?
    A:由于我们的业务类型还是B端业务为主,流量的峰值是可以预估的,很少会出现突发的大流量的情况,我们一般都预留了1倍的容量用于临时的扩容。容灾和调度的话我们主要还是尽可能的隔离工作节点和调度节点,以及大量使用物理机集群,从我们的使用体验上来看,物理机的稳定性还是很不错的。

    Q:如何用Jenkins自动完成Kubernetes部署?
    A:自动部署这块我们有完善的发布系统,如果单纯只要实现Jenkins自动完成Kubernetes的话,Jenkins可以直接调用Kubernetes的API,这个网上有挺多资料的,你可以找找看。

    Q:Service Mesh比传统的微服务治理好在哪里?
    A:降低框架开发成本、代理规则灵活,方便修改策略、框架功能的升级无需依赖业务,最大的好处我觉得就是可以降低框架开发成本。

    Q:我理解房多多目前的Mesh方案没有给每个微服务配一个Envoy作为Sidecar,而是使用一组Enovy并自研了xDS的配置发布管理系统,对吗?我想请问backend微服务之间的请求现在是怎么走的呢?谢谢。
    A:是的,刚刚文章中说了,我们后端SOA服务还是基于Dubbo的,这块目前我们还没有做改动,之后的话我们的初步构想会通过Sidecar的方式把这些Dubbo服务都接入到Mesh里面来。我们目前的Envoy也是会充当网关的角色。

    以上内容根据2019年2月21日晚微信群分享内容整理。分享人杜雅林,房多多平台工具负责人,负责容器平台、发布系统、Service Mesh相关功能开发。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesd,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    什么是服务网格?

    grace_shi 发表了文章 • 0 个评论 • 292 次浏览 • 2019-06-04 22:29 • 来自相关话题

    服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观 ...查看全部
    服务网格 是一个可配置的低延迟的基础设施层,目的是通过API(应用程序编程接口)处理应用程序服务之间的大量基于网络的进程间通信。服务网络确保容器化的短暂存在的应用程序的基础结构服务之间的通信快速,可靠和安全。网格提供关键功能,包括服务发现,负载平衡,加密,可观察性,可追溯性,身份验证和授权,以及对断路器模式【1】的支持。

    服务网格是如何实现的呢?它通常会为每个服务实例提供一个称为边车(sidecar)的代理实例。这些边车会处理服务间的通信,监控和安全相关的问题, 以及任何可以从各个服务中抽象出来的东西。这样,开发人员就可以专注于服务中应用程序代码的开发,支持和维护,而运维团队可以负责维护服务网格以及运行应用程序。

    Istio,由Google,IBM和Lyft支持,是目前最著名的服务网格架构。Kubernetes,最初由Google设计,是目前Istio支持的唯一容器编排框架。供应商正在寻求商业版本的Istio。如果Istio能添加到开源项目中,将会带来更大的价值。

    Istio并不是唯一的选择,其他服务网格实现也在开发中。目前边车代理模式是最受欢迎的,例如Buoyant,HashiCorp,Solo.io等项目都使用了这种模式。与此同时,Netflix的技术套件使用了一种替代架构,他们使用了应用程序库(包含Ribbon,Hysterix,Eureka,Archaius)来提供服务网格功能,而Azure Service Fabric等平台在应用程序框架中嵌入了类似服务网格的功能。 服务网格包含一些专业术语来描述组件服务和功能:

    • 容器编排框架。随着越来越多的容器被添加到应用程序的基础架构中,用于监视和管理容器组的容器编排框架变得至关重要。
    • 服务和实例(Kubernetes Pod)。实例是微服务的单个运行副本。有时实例是一个容器;在Kubernetes中,一个实例由一小组相互依赖的容器(称为Pod)组成。客户端很少直接访问实例或Pod,通常他们会访问服务,服务通常是一组可扩展且具有容错性的实例或Pod(副本)。
    • 边车代理。 边车代理与单个实例或Pod一起运行。 边车代理的目的是路由或者代理从容器发出或者接收的流量。 边车与其他边车代理进行通信,编排框架会管理这些边车。许多服务网格的实现会使用边车代理来拦截和管理实例或Pod的所有进出流量。
    • 服务发现。当实例需要与不同的服务进行交互时,它需要找到 - 发现 - 其他服务的健康的,可用的实例。通常,这个实例会执行DNS查找来寻找其他服务的实例。容器编排框架保留实例列表(这些实例都可以正常接收请求),并且框架会提供DNS查询的接口。
    • 负载均衡。大多数编排框架已经提供了第4层(传输层)的负载均衡。服务网络实现了更复杂的第7层(应用层)负载均衡,具有更丰富的算法以及更强大的流量管理。同时可以通过API修改负载均衡的参数,从而可以编排蓝绿部署【2】或金丝雀部署【3】。
    • 加密。服务网格可以加密和解密请求和响应,因此每个服务不需要额外对请求进行加密,减少了负担。服务网格还可以通过优先重用现有的持久连接来提高性能,这减少新连接的创建(创建新连接十分耗费计算资源)。一般实现加密流量都是用双向TLS(mTLS),其中公钥架构(PKI,public key infrastructure)生成并分发证书和密钥,提供给边车代理使用。
    • 身份验证和授权。服务网格可以授权和验证从应用程序外部和内部发出的请求,仅向实例发送经过验证的请求。
    • 支持断路器模式【1】。服务网格可以支持断路器模式,这可以隔离不健康的实例,然后在安全的情况下逐渐将它们恢复并加入到健康的实例池中。

    服务网格应用中管理实例之间的网络流量的的部分称为数据平面。另外有一个独立的控制平面负责生成和部署数据平面的配置(这个配置可以控制数据平面的行为)。控制平面通常包含(或被设计为连接到)一个API,命令行界面和用于管理App的图形用户界面。

    *服务网格中的控制平面在数据平面中边车代理上分发配置*

    服务网格架构的一个常见用例是在使用容器和微服务时解决非常苛刻的操作问题。微服务领域的先驱包括Lyft,Netflix和Twitter等公司,这些公司任何时间都能为全球数百万用户提供强大的服务。 (请参阅我们对Netflix面临的一些架构挑战的深入描述。)如果应用程序对这方面要求比较低,那么更简单的架构就足够了。

    服务网格架构不可能解决所有应用程序操作和交付问题。架构师和开发人员可以选择多种工具,这些工具之中,有些是锤子,可以解决不同类型的问题,而另一些可能是钉子。例如,NGINX微服务参考架构包括几种不同的模型,这些模型提供了使用微服务来解决问题的一系列方法。 服务网格架构中的组成部分 - 例如:NGINX,容器,Kubernetes,以及微服务(作为架构方法),可以在非服务网格架构实现中高效地使用。例如,Istio是作为一个完整的服务网格架构开发的,但其模块化的设计意味着开发人员可以自由选择他们需要的部分组件技术。考虑到这一点,即使您不确定是否以及何时会完全实现服务网格应用程序,也值得深入了解一下服务网格概念。 

    注释: 

    【1】断路器模式: 一种设计模式。用以侦测错误,并避免不断地触发相同的错误(如维护时服务不可用、暂时性的系统问题或是未知的系统错误)。https://zh.wikipedia.org/wiki/斷路器設計模式 
    【2】蓝绿部署(blue‑green deployment):蓝绿部署是保留老版本,同时部署新版本然后进行测试,测试通过后,将流量切换到新版本,然后老版本同时也升级到新版本。 
    【3】金丝雀部署(canary deployment):又叫做灰度部署,即选择部分部署新版本,将部分流量引入到新版本,新老版本同时提供服务。等待灰度的版本测试完毕,之后全量覆盖老版本。 

    原文链接:What Is a Service Mesh? 

    ============================================================================== 
    译者介绍:Grace,程序员,研究生毕业于SUNY at Stony Brook,目前供职于Linktime Cloud Company,对大数据技术以及数据可视化技术感兴趣。

    Service Mesh发展趋势:云原生中流砥柱

    大卫 发表了文章 • 0 个评论 • 186 次浏览 • 2019-05-28 15:32 • 来自相关话题

    【编者的话】本文主要介绍了 ServiceMesh 最新的产品动态,分析其发展趋势和未来走向;结合蚂蚁的上云实践,阐述在云原生背景下 Service Mesh 的核心价值,以及对云原生落地的关键作用。 内容主要有三个部分: ...查看全部
    【编者的话】本文主要介绍了 ServiceMesh 最新的产品动态,分析其发展趋势和未来走向;结合蚂蚁的上云实践,阐述在云原生背景下 Service Mesh 的核心价值,以及对云原生落地的关键作用。

    内容主要有三个部分:

    1. Service Mesh 产品动态:介绍最近半年 Service Mesh 的产品动态,包括开源项目和云厂商推出的云上服务
    2. Service Mesh 发展趋势:根据最近的产品动态,总结 Service Mesh 的发展趋势,推断未来的走向
    3. Service Mesh 与云原生:结合云原生,更好的理解 Service Mesh 的价值和作用

    #Service Mesh产品动态

    ##Istio 1.1 发布

    Istio 是目前 Service Mesh 社区最引人注目的开源项目,在今年的3月份发布了期待已久的 Istio 1.1 版本,我们来看看 Istio 最近几个版本的发布情况:

    * 2018年6月1日,Istio 发布了 0.8 版本,这是Istio历史上第一个LTS版本,也是Istio历史上变动最大的一个版本
    * 2018年7月31日,Istio发布了1.0版本,号称 “Product Ready”
    * 然后就是漫长的等待,Istio 1.0 系列以每个月一个小版本的方式一路发布了1.0.1 到 1.0.6,然后才开始 1.1.0 snapshot 1到6,再 1.1.0-rc 1到6,终于在2019年3月20日发布了 1.1 版本,号称 “Enterprise Ready”。

    从 Istio 1.0 到 Istio 1.1,中间的时间跨度高达 9 个月!我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西:
    1.png

    图中标红的部分,涉及到 Istio 的架构调整,下面将详细介绍 Istio 1.1 版本中带来的架构变化。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    ##Istio 1.1 架构变化

    下图是 Istio 1.0 和 Istio 1.1 的架构图对比:
    2.png

    Istio 1.1 的第一个架构变化来自 Galley:在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在,只是当时 Galley 的功能非常简单,只是做配置更新之后的验证(Validation),在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后,Galley 的定位发生了巨大的变化:Galley开始分担 Pilot/Mixer 的职责。

    在 Istio 1.1 版本之前的设计中,Istio的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server,以获取服务注册信息和配置信息,包括 Kubernetes 原生资源如 Service/Deployment/Pod 等,还有 Istio 的自定义资源(数量多达50多个的 CRD) 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server 产生强绑定,不仅仅代码大量冗余,而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。

    为了解决这个问题,在 Istio 1.1 之后,访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件,而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。
    3.png

    这个工作还在进行中,目前 Istio 的CRD 已经修改为由 Galley 读取,而 Kubernetes 的原生资源(Service/Deployment/Pod 等),暂时还是由 Pilot 读取。

    为了方便在各个组件中同步数据,Istio 引入了MCP(Mesh Configuration Protocol)协议。在 Istio 1.1 版本中,Pilot 通过 MCP 协议从 Galley 同步数据。MCP是受 xDS v2 协议(准确说是 aDS)的启发而制定的新协议,用于在Istio 各模块之间同步数据。

    Istio 1.1 的第二个架构变化来自于 Mixer,在 Istio 1.1 版本中,推荐使用 Out-of-Process Adapter,即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter,目前所有的 Adapter 都将改为 Out-of-Process adapter。

    什么是 In-Proxy Adapter?下图是 Mixer 的架构图,在 Istio 的设计中,Mixer 是一个独立进程,Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式,定义了 Adapter API,然后内建了数量非常多的各种 Adapter。这些 Adatper 的代码存放在 Mixer 代码中,运行时也在 Mixer 的进程内,因此称为 In-Process Adapter。
    4.png

    In-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定,包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer,任意一个 Adapter 的实现出现问题也会影响整个 Mixer,而且数量众多的 Adapter 也带来了数量众多的CRD。为此,Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。
    5.png

    Out-of-Process Adapter以独立进程的方式运行在 Mixer 进程之外,因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer,从而将 Mixer 从 Adaper 的实现细节中解脱出来。

    但是,Out-of-Process Adapter的引入,会导致新的性能问题:原来 Mixer 和 In-Process Adapter 之间是方法调用,现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议,之前 Proxy 和 Mixer 之间的远程调用,已经造成非常大的性能瓶颈,而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次(每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用),这会让性能雪上加霜。

    总结 Out-of-Process Adapter 的引入:架构更加的优雅,性能更加的糟糕。

    在 Istio 1.1 为了架构而不顾性能的同时,Istio 内部也有其他的声音传出,如正在规划中的 Mixer v2。这个规划最重要的决策就是放弃 Mixer 独立进程的想法,改为将 Mixer 的功能合并到 Envoy 中,从而避免 Envoy 和 Mixer 之间远程调用的开销。关于 Mixer 的性能问题和 Mixer 合并的思路,蚂蚁金服在去年六月份开始 SOFAMesh 项目时就有清晰的认识和计划,时隔一年,终于欣喜的看到 Istio 开始正视 Mixer 的架构设计问题并回到正确的方向上。

    对此有兴趣的朋友可以通过阅读下面的文章获取更详细的信息(发表于一年前,但是依然有效):

    * 大规模微服务架构下的Service Mesh探索之路:第二节架构设计中的”合并部分Mixer功能”
    * Service Mesh架构反思:数据平面和控制平面的界线该如何划定?
    * Mixer Cache: Istio的阿克琉斯之踵?: 系列文章,有两篇
    * Istio Mixer Cache工作原理与源码分析:系列文章,有四篇

    目前 Mixer v2 的规划还处于 Review 状态,实现方式尚未有明确决定。如果要合并 Mixer,考虑到目前 Mixer 是基于 Golang 编写,而 Envoy 是基于 C++ ,这意味着需要用 C++重写所有的 Adapter,工作量巨大,恐怕不是短期之内能够完成的。当然也有另外一个新颖(或者说脑洞大开)的思路:引入 Web Assembly(WASM)。目前 Envoy 在进行支持 Web Assembly 的尝试,如果成功,则通过 Web Assembly 的方式来支持 Mixer Adapter 不失为一个好选择。
    ##其他社区产品动态

    最近,CNCF 在筹建 Universal Data Plane API (UDPA/通用数据平面API)工作组,以制定数据平面的标准 API,为 L4/L7 数据平面配置提供事实上的标准。Universal Data Plane API 的创意来自 Envoy,实现为 xDS API。而目前 xDS v2 API 已经是数据平面API的事实标准,这次的 UDPA 会以xDS v2 API 为基础。工作组的初始成员来自包括 Envoy 和 gRPC 项目的代表,蚂蚁金服也在积极参与 UDPA 工作组,目前还处于非常早期的筹备阶段。

    Linkerd2 在2019年4月17日发布了最新的稳定版本 Linkerd 2.3 版本。Linkerd2 是目前开源产品中唯一正面对抗 Istio 的存在,不过在国内知名度不高,使用者也很少。比较有意思的是,开发Linkerd2 的初创公司 Buoyant 最近的B轮融资来自 Google 的投资部门。
    ##云厂商的产品动态

    随着 Service Mesh 技术的发展,和各方对 Service Mesh 前景的看好,各大主流云提供商都开始在 Service Mesh 技术上发力。

    首先看 AWS,在2019年4月,AWS 宣布 App Mesh GA。App Mesh 是 AWS 推出的AWS原生服务网格,与AWS完全集成,包括:

    * 网络(AWS cloud map)
    * 计算(Amazon EC2 和 AWS Fargate)
    * 编排工具(AWS EKS,Amazon ECS 和 EC2 上客户管理的 Kubernetes)

    6.png

    App Mesh 的数据平面采用 Envoy,产品非常有创意的同时支持VM和容器,支持多种产品形态,如上图所示。

    Google 的打法则是围绕 Istio 。首先是在2018年底推出了 Istio on GKE,即”一键集成 Istio”,并提供遥测、日志、负载均衡、路由和 mTLS 安全能力。接着 Google 又推出 Google Cloud Service Mesh,这是 Istio 的完全托管版本,不仅仅提供 Istio 开源版本的完整特性,还集成了 Google Cloud上 的重要产品 Stackdriver 。

    近期,Google 推出 Traffic Director 的 beta 测试版本,Traffic Director 是完全托管的服务网格流量控制平面,支持全局负载均衡,适用于虚拟机和容器,提供混合云和多云支持、集中式健康检查和流量控制,还有一个非常特别的特性:支持基于流量的自动伸缩。
    7.png

    微软则推出了 Service Fabric Mesh。Azure Service Fabric 是 Microsoft 的微服务框架,设计用于公共云,内部部署以及混合和多云架构。而 Service Fabric Mesh 是 Azure 完全托管的产品,在 2018 年 8 月推出预览版。
    8.png

    上周(5月21号)最新消息,微软在 kubeconf 上推出 Service Mesh Interface。SMI 是在 Kubernetes 上运行服务网格的规范,定义了由各种供应商实现的通用标准,使得最终用户的标准化和服务网格供应商的创新可以两全其美,SMI 预期将为 Service Mesh 带来了灵活性和互通性。

    SMI是一个开放项目,由微软,Linkerd,HashiCorp,Solo,Kinvolk 和 Weaveworks联合启动;并得到了 Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat 和 VMware 的支持。
    9.png

    #Service Mesh发展趋势

    在分享完最近半年 Service Mesh 产品的动态之后,我们来分析探讨 Service Mesh 的发展趋势。
    ##趋势 1:上云 + 托管

    在微服务/容器这些年的发展历程中,我们会发现一个很有意思(甚至有些哭笑不得)的现象:
    10.png


    * 为了解决单体的复杂度问题,我们引入微服务架构
    * 为了解决微服务架构下大量应用部署的问题,我们引入容器
    * 为了解决容器的管理和调度问题,我们引入 Kubernetes
    * 为了解决微服务框架的侵入性问题,我们引入 Service Mesh
    * 为了让 Service Mesh 有更好的底层支撑,我们又将 Service Mesh 运行在 Kubernetes 上

    在这个过程中,从单个应用(或者微服务)的角度看,的确自身的复杂度降低,在有底层系统支撑的情况下部署/维护/管理/控制/监控等也都大为简化。但是站在整个系统的角度,整体复杂度并没有消失,只是从单体分解到微服务,从应用下沉到 Service Mesh,复杂度从总量上不但没有减少,反而大为增加。

    解决这个问题最好的方式就是 上云,使用 托管 版本的 Kubernetes 和 Service Mesh,从而将底层系统的复杂度交给云厂商,而客户只需要在云的基础上享受 Service Mesh 技术带来的使用便利和强大功能。

    前面我们分享产品动态时,可以看到目前 Google/AWS/微软这三巨头都已经推出了各自的 Service Mesh 托管产品,而在国内,阿里云/华为云等也有类似的产品推出,我们蚂蚁金服也将在稍后在金融云上推出 SOFAMesh 的云上托管版本。在这里,我总结为一句话:

    几乎所有的主要公有云提供商都在提供(或者准备提供)Service Mesh托管方案
    ##趋势 2:VM 和容器混用

    第二个趋势就是 VM 和容器混用,即 Service Mesh 对服务的运行环境的支持,不仅支持容器(尤其指 Kubernetes),也支持虚拟机,而且支持运行在这两个环境下的服务相互访问,甚至直接在产品层面上屏蔽两者的差异。

    比如 Google 的 Traffic Director 产品:
    11.png

    AWS 的 App Mesh产品:
    12.png

    都是在产品层面直接提供 VM 和容器混用的支持,不管应用是运行在 VM 上还是容器内都可以支持,而且可以方便的迁移。
    ##趋势 3:混合云和多云支持

    混合云和多云支持最近正成为一个新的技术热点和商业模式,甚至 Google Cloud 都喊出口号,要 “All in Hybrid Cloud”!

    Google Traffic Director 旗帜鲜明的表达了 Google Cloud 对混合云的重视:
    13.png

    下图是 Google Traffic Director 给出的一个应用改造示例:从单体结构转为微服务架构,从私有云转为公有云加私有云的混合云模式。
    14.png

    Service Mesh 毫无疑问是实现上述转型并提供混合云和多云支持的一个非常理想的解决方案。
    ##趋势 4:和 Serverless 的结合

    Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术:

    * Service Mesh 技术的关注点在于服务间通讯,其目标是剥离客户端 SDK,为应用减负,提供的能力主要包括安全性、路由、策略执行、流量管理等。
    * Serverless 技术的关注点在于服务运维,目标是客户无需关注服务运维,提供服务实例的自动伸缩,以及按照实际使用付费。

    理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方,可以结合使用。事实上目前业界也开始出现这个趋势,而融合的方式有两种:

    1. 在Serverless中引入Service Mesh:典型如 Knative 项目和 Knative 的 Google Cloud 托管版本 Google Cloud Run,通过引入对容器的支持和使用 Istio,Knative 将 Serverless 的支持扩展到 Function 之外,在极大的扩展 Serverless 适用范围的前提下,也将服务间通讯的能力引入到 Serverless。
    2. 在Service Mesh 中引入 Serverless:典型如 Google Traffic Director 产品,在提供 Service Mesh 各种能力的同时,支持按照流量自动伸缩服务的实例数量,从而融入了部分 Serverless 的特性。

    对于 Serverless 和 Service Mesh 的结合,我们来展望未来形态:未来应该会出现一种新型服务模式,Serverless 和 Service Mesh 合二为一。只要将服务部署上来,就自动可以得到 Service Mesh 的服务间通讯能力和 Serverless 的无服务器运维。在蚂蚁金服,我们将这理解成为是未来云原生应用的终态之一,正在积极的探索其落地的实际方式。
    15.png

    ##趋势 5:Mesh 模式延伸

    回顾一下 Service Mesh 模式的核心,其基本原理在于将客户端 SDK 剥离,以 Proxy 独立进程运行;目标是将原来存在于 SDK 中的各种能力下沉,为应用减负,以帮助应用云原生化。

    遵循这个思路,将 Service Mesh 的应用场景泛化,不局限于服务间的同步通信,就可以推广到更多的场景:特征是有网络访问,而是通过客户端 SDK 来实现。

    在蚂蚁金服的实践中,我们发现 Mesh 模式不仅仅适用于服务间同步通讯,也可以延伸到以下场景:

    * Database Mesh: 数据库访问
    * Message Mesh:消息机制
    * Cache Mesh:缓存

    以上模式的产品蚂蚁金服都在探索中,相关的产品正在开发和尝试落地。社区也有一些相关的产品,比如 Database Mesh 方面张亮同学在力推的 Apache Shardingsphere 项目。

    通过更多的 Mesh 模式,我们可以覆盖更多的场景,从而实现让应用在各个方面都做到减负,而不仅仅是 Service Mesh 对应的服务间通讯,从而为后续的应用云原生化奠定基础。
    ##趋势 6:标准化,不锁定

    云原生的一个重要主张,就是希望在云上为用户提供一致的用户体验,提倡标准化,避免供应商绑定(Not Lock-In)。

    从前面分享的 Service Mesh 产品动态可以看出,目前 Service Mesh 市场上出现了众多的供应商和产品:开源的,闭源的,大公司出的,小公司出的,市场繁荣的同时也带来了市场碎片化的问题——所有围绕业务应用的外围工作,比如通过 Service Mesh 对流量进行控制,配置各种安全/监控/策略等行为,以及在这些需求上建立起来的工具和生态系统,却不得不牢牢的绑死在某个具体的 Service Mesh 实现上,所谓”供应商锁定”。其根本问题在于各家实现不同,又没有统一标准。因此,要想解决上述问题,就必须釜底抽薪:解决 Service Mesh 的标准化问题。

    就在最近这一个月,Service Mesh 社区出现了两个推动标准化的大事件:

    1. CNCF筹建 Universal Data Plane API (通用数据平面API)工作组,计划以 xDS v2 API 为基础制定数据平面的标准API,工作组的初始成员来自包括 Envoy 和 gRPC 项目的代表(可以理解为 Google 为首)
    2. 微软在 kubeconf 上推出 Service Mesh Interface,准备定义在 Kubernetes 上运行服务网格的规范,为 Service Mesh 带来了灵活性和互通性。SMI由微软牵头,联合 Linkerd,HashiCorp,Solo,Kinvolk 和Weaveworks。

    为了方便理解这两个标准,我为大家准备了一张图:
    16.png

    其中,Universal Data Plane API 是数据平面的标准,控制平面通过这个 API 来控制数据平面的行为。而 Service Mesh Interface 是控制平面的标准,上层的应用/工具/生态体系通过 Service Mesh Interface 来实现跨不同的 Service Mesh 实现为最终用户提供一致性的体验。

    当然这两个标准化 API 都刚刚起步,而且,标准化的工作通常不仅仅是技术问题,涉及到复杂的利益关系,具体未来走向现在难于推断,只能密切关注。
    ##发展趋势分析

    我们总结一下上面列出的 Service Mesh 最近的6个发展趋势:
    17.png

    这些趋势都和云有关,核心在于让云来提供能力,包括:

    * 让云承担更多职责
    * 提供更高抽象
    * 适用更多场景
    * 减少应用负担:实现应用轻量化

    最终实现让业务应用专注业务的战略目标。

    对于 Service Mesh 技术未来的走向,我的看法是:Service Mesh 技术必然不是孤立的自行发展,而是在云原生的大环境下,与云原生的其他技术、理念、最佳实践一起相互影响、相互促进、相互支撑、共同发展。云原生是一个庞大的技术体系,Service Mesh 需要在这个体系中获得各种支撑和配合,才能最大限度的发挥自身的优势。
    #Service Mesh与云原生

    在最后一段,我们来谈谈 Service Mesh 技术和云原生的关系,也就是本次分享的标题所说的:云原生中流砥柱。

    凭什么?
    ##什么是云原生?

    在解释之前,首先问一个问题:什么是云原生?相信这个问题很多同学都问过,或者被问过,每个人心里可能都有自己的理解和表述。在今年年初,我也特意就这个问题问了自己,然后尝试着给出了一个我的答案:

    云原生指 “原生为云设计”,具体说就是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。
    18.png

    关于云原生的理解,以及对这句话的详细阐述,这里不详细展开。
    #Service Mesh的核心价值

    关于 Service Mesh 的核心价值,我个人的理解,不在于 Service Mesh 提供的玲琅满目的各种功能和特性,而是:

    实现业务逻辑和非业务逻辑的分离

    将非业务逻辑的功能实现,从客户端 SDK 中剥离出来,放到独立的 Proxy 进程中,这是 Service Mesh 在技术实现上走出的第一步,也是至关重要的第一步:因为这一步,实现了业务逻辑和非业务逻辑的分离,而且是最彻底的物理分离,哪怕需要为此付出一次远程调用的代价。

    而这一步迈出之后,前面就是海阔天空:

    * 业务逻辑和非业务逻辑分离之后,我们就可以将这些非业务逻辑继续下沉
    * 下沉到基础设施,基础设施可以是基于VM的,可以是基于容器和k8s的;也可以是VM和容器混合
    * 基础设施也可以以云的形式提供,可以是公有云、私有云,也可以是混合云、多云;
    * 可以选择云上托管,完全托管也好,部分托管也好,产品形态可以很灵活

    总结说,业务逻辑和非业务逻辑的分离:

    * 为下沉到基础设施提供可能
    * 为上云提供可能
    * 为应用轻量化提供可能

    备注:这里说的上云,指的是上云原生(Cloud Native)的云,而不是上云就绪(Cloud Ready)的云。
    ##Mesh 化是云原生落地的关键步骤

    在过去一年中,蚂蚁金服一直在努力探索云原生落地的方式,在这个过程中,我们有一些感悟,其中非常重要的一条就是:Mesh 化是云原生落地的关键步骤。
    19.png

    如上图所示:

    * 最下方是云,基于 Kubernetes 和容器打造,提供各种基础能力,这些能力有一部分来自传统中间件的下沉
    * 在云上是 Mesh 层,包含 Service Mesh 以及我们前面提到的各种扩展的 Mesh 模式,实现通信的标准化
    * 在通过 Mesh 剥离非业务功能并下沉之后,应用实现了轻量化,传统的 App 和新兴的微服务都可以受益于此
    * 更进一步,轻量化之后的业务应用,其工作负载在瘦身减负之后变得相当的干净,基本只剩业务逻辑,包括传统的 App,以 Container 形式运行的服务和新颖的 Function,这些负载在往 Serverless 形态转换时相对要轻松很多

    配合 Serverless 技术领域最新的技术潮流和产品发展(如以 knative 项目为代表,Serverless 不再仅仅是 Function 形式,也支持 BaaS 等偏传统的工作负载),Mesh化为现有应用转型为 Serverless 模式提供助力。

    在这里我们再分享一下蚂蚁金服对未来中间件产品发展的感悟,我们认为中间件的未来在于 Mesh 化,并融入基础设施,如下图所示:
    20.png

    左边是传统的中间件形态,在云原生时代,我们希望将非业务功能从传统中间件的富客户端中剥离出来,然后将这些能力以及这些能力背后的中间件能力,下沉到基础设施,下沉到云。而中间件产品也会融入基础设施,如图中右边所示。未来的中间件将作为基础设施和云的一部分,而 Mesh 则成为连接应用和基础设施以及其他中间件产品的桥梁。

    更重要的是:业务应用因此而实现轻量化,在剥离各种非业务功能之后,业务应用就实现了只关注业务逻辑的战略目标,从而实现从传统应用到云原生应用的转型。

    总结:通过 Service Mesh 技术,我们实现了业务逻辑和非业务逻辑的分离,为应用的轻量化和云原生化提供可能;并通过将非业务逻辑的各种功能下沉到基础设施和云,极大的增强了基础设施和云的能力,为云原生的落地提供了极大助力。

    因此,我们认为: Service Mesh 技术将在云原生落地中扮演了非常重要的作用,不可或缺。
    ##Service Mesh发展展望

    最后再次展望一下 Service Mesh 的未来发展。

    左边是 Service Mesh 发展初期的最重要的两个原始动力:多语言支持和类库升级。关于这两点,最近这两年中介绍和推广 Service Mesh 理念和产品的同学基本都讲过,但是今天我想指出的是:这只是 Service Mesh 的起点,而远不是 Service Mesh 的终点。

    Service Mesh 的未来,不会停留在仅仅满足多语言支持和类库升级,而是跟随云原生的大潮,解决各种实际需求,同时又尽量维持上层业务应用的简单直白。
    21.png

    在这次分享的最后,我想给大家一个留一个课外作业,有心的同学可以尝试一下:如果您想更深入的理解 Service Mesh 的价值,想对 Service Mesh 未来的发展方向有更清晰的认识,尤其是希望能通过自身的思考和感悟来理解 Service Mesh 而不是简单的被灌输(包括被我灌输),那么请尝试独立的做如下思考:

    1. 抛开左边的这两点,不要将思维局限在这个范围内
    2. 考虑云原生的大背景,结合您自身对云原生的理解,和对云的期望
    3. 针对右边的 Service Mesh 的六个趋势,忘记我前面讲述的内容,只考虑其背后的实际场景和客户需求,以及这个场景带来的业务价值,然后认真对比使用 Service Mesh 和不使用 Service Mesh 两种情况下的解决方案
    4. 请在上述思考的过程中,更多的从业务应用的角度来看待问题,假设你是那个云上的应用(还记得前面图上的小 baby 吗?),你会希望被如何对待

    希望这样的思考能让您有所收获。

    原文链接:https://skyao.io/talk/201905-servicemesh-development-trend/

    你好,SMI:Service Mesh 互操作性说明书

    YiGagyeong 发表了文章 • 0 个评论 • 264 次浏览 • 2019-05-27 23:36 • 来自相关话题

    【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为 Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。 今 ...查看全部
    【编者的话】本文主要介绍了最近发布的 Service Mesh Interface(SMI),SMI 为
    Service Mesh 技术提供了通用的 API 规范,并且是生态系统友好的,为后续新兴工具的集成提供了保障。

    今天,我们兴奋地发布了 `Service Mesh Interface(SMI)`,它定义了一组通用的可移植 API,为开发人员提供跨不同 Service Mesh(服务网格)技术的互操作性,其中包括 Istio,Linkerd 和 Consul Connect。SMI 是一个与微软,Linkerd,HashiCorp,Solo.io,Kinvolk 和 Weaveworks 合作开展的开放项目;同样也得到了 Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat 和 VMware 的支持。

    多年来,网络架构的真言是让网络管道尽可能愚蠢,并在应用中构建智能。网络的职责是转发数据包,而任何关于加密,压缩或身份的逻辑则存在于网络端点内。互联网是以此真言为前提的,所以你会觉得它可以运转良好。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    但是,如今随着微服务、容器以及编排系统如 `Kubernetes` 的爆炸式增长,工程团队将要保障、管理和监控越来越多的网络端点。Service Mesh 技术通过使网络更加智能,来解决上述问题。Service Mesh 技术不是教授所有服务来加密会话,授权客户端,发出合理的遥测,并在应用程序版本之间无缝转换流量,而是将此逻辑推入网络,由一组单独的管理 API 控制。

    这是 `cloud-native` 系统中比较流行的模式。我们发现,随着许多供应商为应用开发人员提供了令人兴奋的新选择,Service Mesh 技术也随之激增。问题是,转向 Service Mesh 的开发人员必须选择一个供应商,并直接对接其 API。他们被束缚在了某种 Service Mesh 的实现中。如果没有通用接口,开发人员就会失去可移植性以及灵活性,并且从广泛的生态系统中获益的能力也会受限。

    SMI 提供了如下功能:

    • Kubernetes 网格的标准界面
    • 最常见的网格用例的基本功能集
    • 随着时间的推移灵活地支持新的网格功能
    • 为生态系统提供利用网格技术进行创新的空间
    # SMI 覆盖了哪些功能我们与 HashiCorp,Buoyant,Solo.io 以及其他公司合作,为企业级客户所希冀的三大 Service Mesh 功能构建初始规范:[list=1]
  • 流量策略:应用跨服务应用身份和传输加密等策略
  • 流量遥测:捕获关键指标,如错误率和服务之间的延迟
  • 流量管理:在不同服务之间转移和加权流量

  • 这些只是我们希望通过 SMI 初步实现的功能。由于开发过程中有许多令人兴奋的网格功能,我们完全希望随着时间的推移,不断发展 SMI API,并期待通过新功能扩展当前规范。
    # SMI是如何工作的
    Service Mesh Interface 背后的观点并非新创。它追寻 Ingress,Network Policy 和 CNI 等现有 Kubernetes 资源的足迹。与 Ingress 或 Network Policy 一样,SMI 不提供具体实现。相反,SMI 规范定义了一组通用 API,允许网格提供者提供自己的最佳实现。与 SMI 集成可以通过两种方式实现,工具和网格提供者可以直接使用SMI API,也可以构建运算符将 SMI 转换为原生 API。

    SMI 是 Linkerd 迈向 Service Mesh 大众化的一大步,我们很高兴能够向更多的 Kubernetes 用户提供简洁和易用的 Linker 服务。
    > ——William Morgan,Linkerd 维护者



    对于跨技术和生态系统协作来说,接口的标准化对确保最佳用户体验至关重要。凭借这种精神,我们很高兴能与微软和其他公司合作开发 SMI 规范,并已经通过 Service Mesh Hub 和 SuperGloo 项目提供了首个参考实现。
    > ——Solo.io 创始人兼首席执行官,Idit Levine。



    # 生态系统友好
    对于 Service Mesh 等早期技术,我们必须为其生态系统创造创新空间,并探索解决客户问题的不同方法。随着 service mesh 技术的不断发展,SMI 提供的互操作性将有助于新兴工具和实用程序与现有网格供应商集成,而不是单独集成每个网格,像 flagger 和 SuperGloo 这样的工具就可以与 SMI 集成,从而获得跨网格功能。

    “Service Mesh 的兴趣和动力已达到了行业需要在一系列标准上进行协作的程度,这些标准可以帮助确保他们的成功。”VMware 服务网络首席架构师 Sushil Singh 表示,“Service Meshe 为应用程序的未来提供了丰富的基础功能。现在是制定标准 API 的最佳时机,这些 API 可以简化 Service Mesh 技术的消耗和功能,从而实现健康的生态系统。VMware 很高兴参与这项非常重要的工作。“



    客户和社区成员都在寻求一种方法来更好地标准化 Service Mesh 的配置和操作。随着 Service Mesh Interface(SMI)的出现,我们认为这是一种可以帮助我们最大化 Red Hat OpenShift 客户选择和灵活性的方法。这种灵活性使用户能够优先考虑实现细节的功能。
    > ——Brian Redbeard Harrington,Red Hat Service Mesh 首席产品经理



    原文链接:Hello Service Mesh Interface (SMI): A specification for service mesh interoperability (翻译:李加庆

    容器、微服务与服务网格

    cleverlzc 发表了文章 • 0 个评论 • 286 次浏览 • 2019-05-26 11:03 • 来自相关话题

    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给 ...查看全部
    【编者的话】本文结合dotCloud的发展为例,阐述了一个基本的服务网格应该具备什么样的能力,对诸如Istio、Linkerd、Consul Connect等现代服务网格系统的基本模式进行了阐述,最后对于“自建还是购买(或者使用开源)”这个老生常谈的话题作者给出了自己的见解。

    如你所知,已经有很多关于服务网格的资料(1234),但这是另外一篇。是的!但是为什么会有这篇文章呢?因为我想给你们一些不同的视角,他们希望服务网格在10年前就已经存在,远早于Docker和Kubernetes这样的容器平台的兴起。我并不是说这个视角比其他视角更好或更差,但是由于服务网格是相当复杂的“野兽”,所以我相信多种视角有助于更好地理解它们。

    我将讨论dotCloud平台,这是一个建立在100多个微服务之上的平台,支持数千个运行在容器中的生产应用程序;我将解释在构建和运行它时所面临的挑战;以及服务网格会(或不会)提供帮助。
    # dotCloud的历史
    我已经写过关于dotCloud平台的历史和它的一些设计选择,但是我没有过多地讨论它的网络层。如果你不想深入了解我之前关于dotCloud的博客,你需要知道的是它是一个PaaS,允许客户运行各种应用程序(Java、PHP、Python等),支持广泛的数据服务(MongoDB、MySQL、Redis等)以及类似于Heroku的工作流程:你可以将代码推送到平台,平台将构建容器映像,并部署这些容器映像。

    我将告诉你流量是如何在dotCloud平台上路由的;不是因为它是特别棒或其他什么(我认为现在是比较合适的时间),但主要是因为,如果一个普通的团队需要一种在一个微服务群或一个应用程序群之间路由流量的方法,那么这种设计可以在短时间内用现在已有的工具轻松实现。因此,它将为我们提供一个很好的比较点,“如果我们破解它,我们会得到什么”和“如果我们使用现有的服务网格,我们会得到什么”,也就是老生常谈的“构建与购买”的困境。
    # 托管应用的流量路由
    部署在dotCloud上的应用程序会暴露HTTP和TCP端点。

    HTTP端点被动态地添加到Hipache负载平衡器集群的配置中。这与我们今天使用Kubernetes Ingress资源和Traefik这样的负载平衡器可以实现的功能类似。如果你想和更多Kubernetes技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    只要域名指向dotCloud的负载平衡器,客户端就可以使用它们的关联域名连接到HTTP端点。这里没有什么特别的。

    TCP端点与端口号相关联,然后端口号通过环境变量与该堆栈上的所有容器通信。

    客户端可以使用指定的主机名(类似于gateway-X.dotcloud.com)和端口号连接到TCP端点。

    该主机名将解析为一个“nats”服务器集群(与NATS没有任何关系),该集群将把传入的TCP连接路由到正确的容器(或者,在负载平衡服务的情况下,路由到正确的容器)。

    如果你熟悉Kubernetes,这可能会让你想起NodePort服务。

    dotCloud平台没有集群IP服务的等价物:为了简单起见,从内部和外部访问服务的方式是相同的。

    这非常简单,最初的HTTP和TCP路由网格的实现可能都是几百行Python代码,使用相当简单(我敢说,很天真)的算法,但是随着时间的推移,它们不断发展,以处理平台的增长和额外的需求。

    它不需要对现有应用程序代码进行大量重构。十二因素应用程序尤其可以直接使用通过环境变量提供的地址信息。
    # 它与现代服务网络有何不同?
    可观察性有限。对于TCP路由网格根本没有度量标准。至于HTTP路由网格,后来的版本提供了详细的HTTP度量,显示错误状态码和响应时间;但是现代服务网格的功能远远不止于此,它还提供了与度量收集系统(例如Prometheus)的集成。

    可观察性非常重要,不仅从操作角度(帮助我们解决问题),还可以提供安全的蓝/绿部署金丝雀部署等功能。

    路由效率也受到限制。在dotCloud路由网格中,所有流量都必须经过一组专用路由节点。这意味着可能跨越几个AZ(可用性区域)边界,并显著增加延迟。我记得对一些代码进行故障排除,这些代码发出100多个SQL请求来显示给定的页面,并为每个请求打开了到SQL服务器的新连接。在本地运行时,页面会立即加载,但在dotCloud上运行时,需要几秒钟,因为每个TCP连接(以及随后的SQL请求)都需要几十毫秒才能完成。在这种特定的情况下,使用持久连接起了作用。

    现代服务网络做得更好。首先,通过确保连接在源位置路由。逻辑流仍然是客户端-->网格-->服务,但是现在网格在本地运行,而不是在远程节点上运行,因此客户端-->网格连接是本地连接,因此速度非常快(微秒而不是毫秒)。

    现代服务网格还实现了更智能的负载平衡算法。通过监控后端的运行及健康状况,它们可以在更快的后端上发送更多的流量,从而提高整体性能。

    随着现代服务网络的出现,安全性也越来越强。dotCloud路由网格完全在EC2 Classic上运行,并且没有加密流量(假设如果有人设法嗅探EC2上的网络流量,那么无论如何都会遇到更大的问题)。现代服务网格可以透明地保护我们所有的通信,例如通过相互的TLS身份验证和随后的加密。
    # 平台服务的流量路由
    OK,我们已经讨论了应用程序是如何通信的,但是dotCloud平台本身呢?

    平台本身由大约100个微服务组成,负责各种功能。其中一些服务接受来自其他服务的请求,而其中一些服务是后台工作应用,它们将连接到其他服务,但不能自己接收连接。无论哪种方式,每个服务都需要知道它需要连接到的地址的端点。

    许多高级服务都可以使用上面描述的路由网格。事实上,dotCloud平台的100多个微服务中有很大一部分是作为常规应用程序部署在dotCloud平台上的。但是少数低级服务(特别是那些实现路由网格的服务)需要一些更简单的东西,需要更少的依赖关系(因为它们不能依靠自己来运行;这是一个老生常谈的“先有鸡还是先有蛋”的问题)。

    通过直接在几个关键节点上启动容器,而不是依赖于平台的构建器、调度程序和运行器服务,部署了这些底层的基本平台服务。如果你想要与现代容器平台进行比较,这就像直接在节点上运行Docker来启动我们的控制平面,而不是让Kubernetes为我们做这件事。这与kubeadmbootkube在引导自托管集群时使用的静态Pod的概念非常相似。

    这些服务以一种非常简单和粗糙的方式被公开:有一个YAML文件列出了这些服务,将它们的名称映射到它们的地址;作为其部署的一部分,这些服务的每个使用者都需要一份该YAML文件的副本。

    一方面,这是非常强大的,因为它不涉及像ZooKeeper那样维护外部键值存储(记住,etcd或Consul在那个时候不存在)。另一方面,这使得服务难以移动。每次移动服务时,它的所有消费者都需要接收更新的YAML文件(并且可能会重新启动)。不太方便!

    我们开始实现的解决方案是让每个消费者都连接到一个本地代理。使用者不需要知道服务的完整地址+端口,只需要知道它的端口号,并通过localhost进行连接。本地代理将处理该连接,并将其路由到实际后端。现在,当一个后端需要移动到另一台机器上,或按比例放大或缩小,而不是更新它的所有消费者,我们只需要更新所有这些本地代理;我们不再需要重新启动消费者。

    (还计划将流量封装在TLS连接中,并在接收端使用另一个代理来打开TLS并验证证书,而不涉及接收服务,该服务将被设置为仅在本地主机上接受连接。稍后会详细介绍。)

    这与AirBNB的SmartStack非常相似;与SmartStack实现并部署到生产环境的显著区别是,当dotCloud转向Docker时,它的新的内部路由网格被搁置了。

    我个人认为SmartStack是诸如Istio、Linkerd、Consul Connect等系统的先驱之一,因为所有这些系统都遵循这种模式:

    • 在每个节点上运行代理
    • 消费者连接到代理
    • 后端改变时,控制平面更新代理的配置
    # 今天实现一个服务网格如果我们今天必须实现类似的网格,我们可以使用类似的原则。例如,我们可以设置一个内部域名系统区域,将服务名映射到127.0.0.0/8空间中的地址。然后在集群的每个节点上运行HAProxy,接受每个服务地址(在127.0.0.0/8子网中)上的连接,并将它们转发/负载平衡到适当的后端。HAProxy配置可以由confd管理,允许在etcd或Consul中存储后端信息,并在需要时自动将更新的配置推送到HAProxy。这就是Istio的工作原理!但是有一些不同之处:
    • 它使用Envoy Proxy而不是HAProxy
    • 它使用Kubernetes API而不是etcd或Consul来存储后端配置
    • 服务在内部子网中分配地址(Kubernetes集群IP地址),而不是127.0.0.0/8
    • 它有一个额外的组件(Citadel),用于在客户机和服务器之间添加相互的TLS身份验证
    • 它增加了对诸如断路、分布式跟踪、金丝雀部署等新特性的支持

    让我们快速回顾一下这些差异。
    ## Envoy Proxy
    Envoy Proxy由Lyft撰写。它与其他代理(如HAProxy、NGINX、Traefik)有许多相似之处,但Lyft编写它是因为它们需要当时这些代理中不存在的功能,而且构建一个新的代理比扩展现有代理更有意义。

    Envoy可以单独使用。如果有一组给定的服务需要连接到其他服务,可以把它连接到Envoy,然后动态地配置和重新配置其他服务的Envoy的位置,而得到很多漂亮的额外的功能,比如域的可观测性。这里,没有使用定制的客户端库,也没有在代码中添加跟踪调用,而是将流量定向到Envoy,让它为我收集指标。

    但Envoy也可以用作服务网格的数据平面。这意味着现在将由该服务网格的控制平面配置Envoy。
    ## 控制平面
    说到控制平面,Istio依赖于Kubernetes API。这与使用confd没有太大的不同。confd依赖etcd或Consul来监视数据存储中的一组密钥。Istio依赖Kubernetes API来监视一组Kubernetes资源。

    Aparte:我个人认为阅读Kubernetes API描述非常有帮助。

    Kubernetes API服务器是一个“哑服务器”,它提供API资源上的存储、版本控制、验证、更新和监视语义。



    Istio是为与Kubernetes合作而设计的;如果你想在Kubernetes之外使用它,则需要运行Kubernetes API服务器的实例(以及支持的etcd服务)。
    ## 服务地址
    Istio依赖Kubernetes分配的集群IP地址,因此Istio得到一个内部地址(不在127.0.0.1/8范围)。

    在没有Istio的Kubernetes集群上,前往给定服务的ClusterIP地址的流量被kube-proxy拦截,并发送到该代理的后端。更具体地说,如果你想确定技术细节:kube-proxy设置iptables规则(或IPVS负载平衡器,取决于它是如何设置的)来重写连接到集群IP地址的目标IP地址。

    一旦Istio安装在Kubernetes集群上,就不会发生任何变化,直到通过将sidecar容器注入到使用者Pod中,显式地为给定的使用者甚至整个名称空间启用Istio。sidecar将运行一个Envoy实例,并设置一些iptables规则来拦截到其他服务的流量,并将这些流量重定向到Envoy。

    结合Kubernetes DNS集成,这意味着我们的代码可以连接到一个服务名,一切都可以正常工作。换句话说,比如我们的代码向`http://api/v1/users/4242`发起一个请求,`api`将解析到10.97.105.48,一条iptables规则将解释连接到10.97.105.48并重定向到本地Envoy代理,本地代理将这个请求路由到实际的API后端。
    ## 额外的铃声和哨声
    Istio还可以通过名为Citadel的组件通过mTLS(双向TLS)提供端到端加密和身份验证。

    它还包括混合器,Envoy组件可以查询每一个请求,对请求进行一个临时的决定取决于各种因素,例如请求头、后端负载(别担心,有丰富的规定以确保混合高度可用,即使它休息,Envoy可以继续代理流量)。

    当然,我提到了可观察性。Envoy在提供分布式跟踪的同时收集大量的度量指标。微服务架构,如果单个API请求必须经过微服务A、B、C和D,分布式跟踪将添加一个惟一的标识符请求进入系统,并保留标识符在子请求中,所有这些微服务允许收集所有相关的调用、延迟等。
    # 自建还是购买
    Istio以复杂著称。相比之下,使用我们今天拥有的工具,构建像我在本文开头描述的那样的路由网格相对比较简单。那么,构建我们自己的服务网格是否有意义呢?

    如果我们有适度的需求(如果我们不需要可观察性,断路器,和其他细节),我们可能想建立自己的。但是如果我们正在使用Kubernetes,我们甚至可能不需要这样做,因为Kubernetes已经提供了基本的服务发现和负载平衡。

    现在,如果我们有高级的需求,购买服务网格可能是一个更好的选择。(由于Istio是开源的,所以它并不总是真正的购买,但是我们仍然需要投入工程时间来理解它是如何工作、部署和运行的。)
    #如何选择Istio、Linkerd和Consul Connect
    到目前为止,我们只讨论了Istio,但它并不是唯一的服务网格。Linkerd是另一个流行的选择,还有Consul Connect

    我们应该选哪一个呢?

    实际上在这一点上我也不好说,我不认为我有足够的了解能够帮助任何人做决策。不过,已经有一些有趣的文章比较它们(12),甚至基准测试

    一种值得一提并且很有潜力的方法是使用像SuperGloo这样的工具。SuperGloo提供了一个抽象层来简化和统一服务网格公开的API。我们可以使用SuperGloo提供的更简单的构造,并无缝地从一个服务网格切换到另一个服务网格,而不是学习各种服务网格的特定API(在我看来,相对复杂)。有点像我们有一个描述HTTP前端和后端的中间配置格式,能够为NGINX、HAProxy、Traefik、Apache生成实际配置

    我已经使用SuperGloo稍微涉足Istio,在未来的博客文章中,我想说明如何使用SuperGloo将Isio或Linkerd添加到现有的集群中,以及后者是否能实现它的承诺,即允许我在不重写配置的情况下从一个路由网格切换到另一个。

    如果你喜欢这篇文章,并且想让我尝试一些具体的场景,我很乐意听到你的消息!

    原文链接:Containers, microservices, and service meshes

    译者:Mr.lzc,软件研发工程师、DevOpsDays深圳组织者&志愿者,目前供职于华为,从事云存储工作,以Cloud Native方式构建云文件系统服务,专注于K8s、微服务领域。

    基于Kubernetes的服务网格简介

    JetLee 发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-23 13:51 • 来自相关话题

    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只 ...查看全部
    几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是,嘿,难道Kubernetes服务和ingress还不够么?你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只对内部网络开放,然而对于现在流行的应用来说,这并不够。API通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做API版本化,做金丝雀部署,观察并记录每一个请求。这就引入了服务网格。无论你用Linkerd或是Istio,原理上都是一样的。如果你想和更多Service Mesh技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #为什么要用服务网格?

    服务网格并不是和Kubernetes一起出现。然而,因为有Kubernetes,服务网格更容易被引入到你的环境中。有两个逻辑组件组成了服务网格。我们已经有了pod用于承载各个容器。Sidecar是另一个绝好的例子用于扩展和加强pod里面的主要容器。在服务网格语境里,sidecar是服务代理或者数据平面。

    服务网格是云原生的核心组件

    为了更好的理解服务网格,你需要理解代理和反向代理这两个术语。代理,用一句话说,用于接收流量并中转到其它地方。反向代理,从各个地方接收流量并转交给各个服务。这种情况下,所有的客户只和一个代理实例交流。把数据平面想象为一个反向代理。Ingress也是Kubernetes里面用于暴露服务的反向代理。Ingress可以中止SSL,提供基于名称的路由,并且它主要就干这个事情。对于Kubernetes服务也是一样。如果你需要更复杂的路由该怎么做呢?

    下面列举一些其它服务网格可以做的事情:

    * 负载均衡
    * 精细流量策略
    * 服务发现
    * 服务监控
    * 追踪
    * 路由
    * 服务与服务的安全通信

    不仅有sidecar代理,所有的服务网格解决方案还包含控制器,用于定义sidecar容器应该如何工作。服务网格的控制平面是一个集中的、管理所有的服务网格和服务代理的地方。这个控制面板记录网络信息,所以它也是一个网络监控工具。

    所以,为什么要用服务网格?答案很简单,你可以做上面的任何事情并且不需要修改代码。它能够节省时间与金钱。不仅如此,更重要的是,你不能跳过测试,因为它对于初学者太复杂。甚至你可以通过Istio故障注入模拟不同的场景,来测试系统对于失败的反应。
    #Linkerd2与Istio

    在一开始,我提到过两个在Kubernetes上创建服务网格的著名的解决方案。未来也许还会有其它更多的解决方案。每一个产品都试图用自己的方式解决问题,相互之间肯定会有重复的地方。

    Buoyant,这家公司创造了Linkerd,同时还创造了Conduit服务。近期,Conduit被合并到Linkerd项目,称作Linkerd2。buoyant团队把Linkerd服务网格变成了一个更加通用的解决方案。它用Java编写,这意味着它很重。每一个pod会有一个或更多的容器,一个sidecar。Linkerd2设计应用于Kubernetes。它的开发语言包含Go-控制平面,和Rust-一个原生的服务代理,超级轻量、快速并安全。你可以定义重试和超时,定义编排规则,以及加密(TLS),同时还支持根据策略通过或拒绝请求。不仅如此,它还有一个很漂亮的控制台:
    1.png

    Linkerd2_dashboard

    如果你喜欢控制台的话也可以用Linkerd CLI。

    Linkerd的入门向导非常不错,你可以试一试。如果想学习更多,可以看看它的官方文档。

    Istio当前支持Kubernetes和Nomad,将来会添加更多的功能。Istio是一个多平台解决方案。它可以做微服务流量管理,策略应用以及聚合采样信息。Istio也是Go语言编写的轻量应用,但不同于Linkerd2,它使用Envoy来做服务代理。下图说明Istio中各个部分是如何组合工作的:
    2.png

    Istio_architecture

    我喜欢Istio的其中一点是sidecar自动注入,前提是你已经使用Helm来发布应用,这样的话就不需要手工把sidecar注入到kubernetes的配置文件里面。

    在Kubernetes上安装Istio请参考这篇快速指南。其它关于Istio的信息,请参考它的官方文档。

    这两个产品都是开源的。无论哪一个服务网格方式适合你,它们两个都很容易上手实验。不超过5分钟就可以把它跑起来。我鼓励你都去试一试然后再做决定。目前阶段Istio实现的功能比Linkerd2多了很多,并且也是一个稳定版本。
    #总结

    我希望这篇文章很好的介绍了服务网格。这篇文章并不是Linkerd2和Istio之间的比较。我列举了一些功能点,这样你可以了解一下服务网格给Kubernetes带来了什么。请继续关注我们的后续文章。

    原文链接:https://mp.weixin.qq.com/s/6EvdlPbx3NRekG6_BCCNmA

    Service Mesh 的本质、价值和应用探索

    翔宇 发表了文章 • 0 个评论 • 207 次浏览 • 2019-05-22 21:44 • 来自相关话题

    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 ...查看全部
    Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。

    网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家至简和他的团队在这一领域探索的过程中想清楚了这两点。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态
    #大规模分布式应用的挑战
    微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。

    在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演进所增加的特性并不是某些业务方所需要的时,这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本,使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

    当微服务框架是单一编程语言独大(Java 在阿里巴巴就是这样的)、不能同步支持好其他多个主流编程语言时(比如 C++、Go、Node.js 等), 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的,最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率,但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护,同样的特性需要用不同的编程语言去实现其成本着实很高。

    也许在企业内部统一单一的主流编程语言并不会带来什么劣势,但当企业需要通过收购其他公司来扩充自己的商业版图时就很可能面临技术栈不统一而带来业务无法低风险、高效率共存演进的挑战。当碰到母子公司的技术栈不统一时,在被收购子公司中进行推倒重建基本上是一件业务价值不大的劳命伤财之事。

    最后,在微服务软件架构所主张的拆分手法下,确实可以将每个拆分出来的服务从监管控层面做到足够的精致,但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同,最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。

    不难想象,采取强有力的团队组织形式、技术规范等手段是很难解决以上挑战的。回归通过技术途径去解决技术挑战才更为有力、有效,这正是 Service Mesh 这一技术可以帮助做好的。
    #Service Mesh 的形态
    Service Mesh 的核心思路与微服务软件架构的思路是一脉相承的,即通过拆分实现解耦——将 SDK 中频繁变更的逻辑与业务逻辑分别放到不同的进程中。下图以 RPC 框架为例示例了这一手法。
    1.jpg

    拆分之后,服务调用的流量通过技术手段以应用无感的形式导入 sidecar 进程。每个服务进程边上新增的 sidecar 使得完整的服务调用链中客户端和服务端分别增加了一跳,这是享受 Service Mesh 技术所需付出的成本。
    #Service Mesh 的挑战
    2.jpg

    第一个挑战来自心智模式需要改变。享受 Service Mesh 所带来的益处是需要付出成本的,这如同单体应用向微服务软件架构转变那样,核心是成本与收益问题。之所以业内仍有不少人纠结于 Service Mesh 的价值,根本原因在于企业的业务规模是否面临 Service Mesh 所致力于解决的那些挑战,如果没有则采纳 Service Mesh 只带来更高的成本而没有收益。

    对于那些服务规模还小的企业,确实没有必要引入尚处于探索和普及阶段的 Service Mesh 的必要。他们可以持续关注业务发展与技术的匹配,在合适的时间点去拥抱新技术。

    第二个挑战来自于技术层面,即如何做到增加 sidecar 后的“路径无损”。具体说来,如何在引入 Service Mesh 的情形下,最大可能地不增加服务的调用延时和消耗更多的 CPU 资源。这是未来需要持续去突破的技术方向。可以预见,突破的途径无外乎“应用层 + 内核层”或“软件 + 硬件”。
    #Service Mesh 的本质
    3.jpg

    无疑,技术发展是服务于业务价值创造的。在单体应用时代,因为软件规模、业务复杂度和参与人员数量的持续增大,使得软件开发和迭代工作因为耦合而举步为艰,这就有了微服务软件架构的出现。那时的业务发展效率问题集中体现于人员协同,在微服务软件架构的需要下产生了 RPC、Messaging 等技术。

    当人员的协同问题通过微服务软件架构得以解决时,随着软件规模、业务复杂度和参与人员数量的进一步增大,需要更好地解决多个业务(或服务)之间的协同问题,而这是 Service Mesh 这一技术的本质。
    #Service Mesh 的价值
    4.jpg

    在 Service Mesh 的形态下,RPC 框架中容易变更的内容被剥离到了 sidecar 进程,之前的胖 SDK 瘦身为只保留了功能恒定的协议编解码能力。如此一来,与 RPC 框架演进相关的逻辑几乎集中在 sidecar 进程中,这就完全可以做到让使用 RPC 框架的业务方无感知地对之进行升级与维护。最终的结果是,业务与 RPC 框架可以做到独立发展与升级,完全消除了之前胖 SDK 所导致的两者相互制约发展的不利局面。这一解耦所带来的好处是,使用 RPC 框架的业务团队可以更加聚焦于业务开发本身,这正是发挥技术价值应达到的境界。

    不难看出,Service Mesh 很好地解决了以往 RPC 框架多语言 SDK 的问题。虽然在 Service Mesh 下仍然需要 SDK,但由于 SDK 中的功能是相当稳定的,不存在应付频繁变更所带来的长期维护成本问题。由于 sidecar 是以进程的形式存在的,因此完全不关心使用 RPC 框架的业务逻辑是用什么编程语言实现的,只需实现一次而没有让人感到无聊的多语言特性对齐问题,将 RPC 框架技术团队的人力释放出来做更有价值的事。

    也因为 sidecar 是以独立进程的形式存在,当出现因为公司收购所面临的母子公司技术栈不一致问题时,可以将 sidecar 部署在两个技术栈的衔接处,由 sidecar 通过协议转换等形式完成两个异构服务框架的连接,为异构服务框架的渐进式融合发展提供了可能,很好地缓解了短期高强度技术改造所面临的技术风险和对业务发展的拖累。

    服务框架易变的功能剥离到了 sidecar 后,意味全网的服务流量治理能力可以通过 sidecar 进行收口——sidecar 自身的版本全网一致、流量规则与执行策略一致、监控口径一致,等等。诸多的“一致”将实现全网服务治理的体系化监管控,使得 Service Mesh 成为微服务软件架构拆分手法下完成横向连接与约束的强有力技术手段。

    如果用一句话来描述 Service Mesh 的话,那就是“层次化、规范化、体系化、无侵入的分布式服务(或应用)治理技术”。
    #Service Mesh 的终局
    5.jpg

    延着 Service Mesh 的切分逻辑,不难预见未来 Service Mesh 所形成的终局是一张大网。这个大网是企业统一且唯一的分布式应用治理的基础设施,其上天然地支持多语言应用的开发。当然,sidecar 是包罗万象地支持 RPC、DB、Messaging,还是衍生出 RPC sidecar、DB sidecar、Messaging sidecar 是仍需探索的主题。
    #Service Mesh 的发展路径
    6.jpg

    新技术诞生于逻辑上能解决当下所面临的技术或业务挑战,但能否真正落地去最大程度地发挥价值却具有不确定性和模糊性。正因如此,不少新技术出现之时存在各种基于自身立场去解读和挖掘其背后的价值,当然也不乏各种质疑之声。所有这一切让业内对挑战看得更加透彻,对新技术的探索也愈加高效。

    根本上,Service Mesh 的出现并非填补了技术空白,不少公司因为曾经有过相似的探索而给人“换汤不换药”的感觉,与今天时兴的云计算在十几、二十年前被称之为分布式计算、网格计算颇有相似之处。当一项新技术不是给人横空出世的感觉时,它的运用与采纳就会经历更多的波折,因为没有它似乎企业的业务发展仍能进行下去。

    在经历了一定的思考和市场感知后,发现 Service Mesh 真正发挥价值是需要分布式应用大到一定的规模并面临一开始所提出的那些挑战,这些在阿里巴巴集团内部都满足。最终我将 Service Mesh 的发展划分成三大阶段。

    阶段一:撬动。新技术被采纳的关键是它能解决业务当下所面临的痛点,阿里巴巴因为 Java 语言一家独大而使得多语言问题相当突出,这使得小众的编程语言乐于拥抱 Service Mesh 去解决自己维护 SDK 或 SDK 特性老旧的痛点。此外,阿里巴巴不时通过收购子公司扩大自己的商业版图,确实经历了异构服务架构共存演进所带来的挑战。

    撬动阶段让新技术得以落地而接触到更多的业务机会并争取到打磨技术的时间窗口,让 Service Mesh 技术团队对于需求的理解和把控更加到位。为进入下一发展阶段提供可能。

    阶段二:做透价值渗透。光解决多语言和异构服务架构共存演进并不足以实现大范围的体系化监管控,需要围绕集团内部更为丰富的业务场景去挖掘 Service Mesh 的价值,并在探索的过程中寻求技术突破去降低引入 Service Mesh 的成本。当分布式应用的体量特别大时,成本问题将变得备受关注。一旦 Service Mesh 的价值得以做透,还得考虑无缝迁移等用户体验使之得以更为方便地应用到更多的业务场景。

    阶段三:实现技术换代。分布式应用的全局、体系化监管控一定是未来云原生时代的强诉求。进入这一阶段代表技术进入了更高层次的集约发展时期,是偿还过去“跑马圈地”和“野蛮生长”所欠下技术债的重大里程碑。在这一阶段,Service Mesh 将成为企业所有分布式应用的基础设施,通过这一设施强有力地执行流量灰度、流量调度去保障业务的持续性,让安全、稳定性问题得以采用一致性、系统性的方案解决。“生长”在 Service Mesh 之上的所有业务完全可以根据团队的技术栈特长以更为经济和高效的方式去发展和探索。
    #Service Mesh 的发展思路
    7.jpg

    Dubbo Mesh 是 Service Mesh 在 Dubbo 生态下的落脚点。其发展不仅立足于在阿里巴巴集团遗留应用场景的包并兼容,还将迎合 Kubernetes 已成计算资源编排王者的大势,让 Service Mesh 在未来以 Kubernetes Way 去提供概念一致、体验一致的技术产品。

    整个 Service Mesh 的发展与探索将走“源于开源,反哺开源,集团内外版本一致”的思路。希望探索之路少走弯路、与更多的同行携手前行,成为开源社区的一名积极建设者。

    最终的技术选型是采用 Istio 的部分组件(Dubbo Control 控制面)和 Envoy(Dubbo Proxy 数据面)形成阿里巴巴自己的解决方案。Istio 中的 pilot-discovery 对于平台的抽象便于扩展支持阿里巴巴最近开源出来的 Nacos 而方便落地,同时为将来集团全面的 Kubernetes 化做好准备。Envoy 的性能与软件质量在很多生产环境上得到了检验,而采用 C++ 能从性能上得到很好的保证,避免有些语言存在 GC(垃圾回收)而带来的不确定性,也便于将来应用层与 OS 层、软件与硬件的结合发展。
    #Service Mesh 的进展
    8.jpg

    目前 Dubbo Proxy 完成了 Dubbo 服务调用统计信息收集的开发工作,这部分代码已合入了 GitHub 上 Envoy 仓库的 master 主干。Dubbo Proxy 全面支持 Dubbo 服务路由的工作正在进行,相信很快这部分代码将出现在开源社区。

    在阿里巴巴集团内部,为了快速落地已经完成 Dubbo over HTTP 技术方案的开发,目前已在两个多语言场景业务方的环境中完成部署并开始着手性能测试和调优工作。内部落地方案中,需要考虑通过 Nacos 与集团内部的 VIPServer、ConfigServer 集群进行对接去完成服务发现,这些对接工作开源社区无需关注,因为开源的 Nacos 已包含阿里集团内部的服务注册与发现和配置管理能力。

    值得一提,pilot-discovery 目前并非集群化部署,而是与 Dubbo Proxy 一样进行了下沉。未来在合适的时机会再考虑将之上拉并形成独立的部署集群。

    原文链接:https://mp.weixin.qq.com/s/PqeI1253SHIkMgv8hPCR5w

    服务迁移之路 | Spring Cloud向Service Mesh转变

    博云BoCloud 发表了文章 • 0 个评论 • 295 次浏览 • 2019-05-20 17:39 • 来自相关话题

    导读 Spring Cloud基于Spring Boot开发,提供一套完整的微服务解决方案,具体包括服务注册与发现,配置中心,全链路监控,API网关,熔断器,远程调用框架,工具客户端等选项中立的开源组件,并且可以根据需求对部分组件进行 ...查看全部
    导读

    Spring Cloud基于Spring Boot开发,提供一套完整的微服务解决方案,具体包括服务注册与发现,配置中心,全链路监控,API网关,熔断器,远程调用框架,工具客户端等选项中立的开源组件,并且可以根据需求对部分组件进行扩展和替换。

    Service Mesh,这里以Istio(目前Service Mesh具体落地实现的一种,且呼声最高)为例简要说明其功能。 Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。它也是一个平台,包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio的多样化功能集使你能够成功高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。如果你想和更多 Service Mesh 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

    从上面的简单介绍中,我们可以看出为什么会存在要把Spring Cloud体系的应用迁移到Service Mesh这样的需求,总结下来,有四方面的原因:

    1. 功能重叠

    来简单看一下他们的功能对比:



    微信截图_20190520171338.png




    从上面表格中可以看到,如果从功能层面考虑,Spring Cloud与Service Mesh在服务治理场景下,有相当大量的重叠功能,从这个层面而言,为Spring Cloud向Service Mesh迁移提供了一种潜在的可能性。



    2. 服务容器化

    在行业当前环境下,还有一个趋势,或者说是现状。越来越多的应用走在了通往应用容器化的道路上,或者在未来,容器化会成为应用部署的标准形态。而且无论哪种容器化运行环境,都天然支撑服务注册发现这一基本要求,这就导致Spring Cloud体系应用上容器的过程中,存在一定的功能重叠,有可能为后期的应用运维带来一定的影响,而Service Mesh恰恰需要依赖容器运行环境,同时弥补了容器环境所欠缺的内容(后续会具体分析)。



    3. 术业有专攻

    从软件设计角度出发,我们一直在追求松耦合的架构,也希望做到领域专攻。例如业务开发人员希望我只要关心业务逻辑即可,不需要关心链路跟踪,熔断,服务注册发现等支撑工具的服务;而平台支撑开发人员,则希望我的代码中不要包含任何业务相关的内容。而Service Mesh的出现,让这种情况成为可能。



    4. 语言壁垒

    目前而言Spring Cloud虽然提供了对众多协议的支持,但是受限于Java技术体系。这就要求应用需要在同一种语言下进行开发(这不一定是坏事儿),在某种情况下,不一定适用于一些工作场景。而从微服务设计考虑,不应该受限于某种语言,各个服务应该能够相互独立,大家需要的是遵循通信规范即可。而Service Mesh恰好可以消除服务间的语言壁垒,同时实现服务治理的能力。


    基于以上四点原因,当下环境,除了部分大多已经提前走在了Service Mesh实践的道路上互联网大厂以外(例如蚂蚁金服的SOFASTACK),也有大部分企业已经开始接触Service Mesh,并且尝试把Spring Cloud构建的应用,迁移到Service Mesh中。



    #Spring Cloud向Service Mesh的迁移方案



    Spring Cloud向Service Mesh迁移,从我们考虑而言大体分为七个步骤,如图所示:



    图片1.png




    1. Spring Cloud架构解析

    Spring Cloud架构解析的目的在于确定需要从当前的服务中去除与Service Mesh重叠的功能,为后续服务替换做准备。我们来看一个典型的Spring Cloud架构体系,如图所示:



    图片2.png






    从图中我们可以简要的分析出,一个基于Spring Cloud的微服务架构,主要包括四部分内容:服务网关,应用服务,外围支撑组件,服务管理控制台。



    • 服务网关
    服务网关涵盖的功能包括路由,鉴权,限流,熔断,降级等对入站请求的统一拦截处理。具体可以进一步划分为外部网关(面向互联网)和内部网关(面向服务内部管理)。
    • 应用服务
    应用服务是企业业务核心。应用服务内部由三部分内容构成:业务逻辑实现,外部组件交互SDK集成,服务内部运行监控集成。
    • 外围支撑组件
    外围支撑组件,涵盖了应用服务依赖的工具,包括注册中心,配置中心,消息中心,安全中心,日志中心等。
    • 服务管理控制台
    服务管理控制台面向服务运维或者运营人员,实现对应用服务运行状态的实时监控,以及根据情况需要能够动态玩成在线服务的管理和配置。



    这里面哪些内容是我们可以拿掉或者说基于Service Mesh(以Istio为例)能力去做的?分析下来,可以替换的组件包括网关(gateway或者Zuul,由Ingress gateway或者egress替换),熔断器(hystrix,由SideCar替换),注册中心(Eureka及Eureka client,由Polit,SideCar替换),负责均衡(Ribbon,由SideCar替换),链路跟踪及其客户端(Pinpoint及Pinpoint client,由SideCar及Mixer替换)。这是我们在Spring Cloud解析中需要完成的目标:即确定需要删除或者替换的支撑模块。



    2. 服务改造

    服务单元改造的目的在于基于第一步的解析结果,完成依赖去除或者依赖替换。根据第一步的分析结果服务单元改造分为三步:

    · 删除组件,包括网关,熔断器,注册中心,负载均衡,链路跟踪组件,同时删除对应client的SDK;
    · 替换组件,采用httpClient的SDK支持http协议的远程调用(原来在Ribbon中),由原来基于注册中心的调用,转变成http直接调用;
    · 配置信息变更,修改与删除组件管理的配置信息以及必要的组件交互代码(根据实际应用情况操作);

    当然服务单元改造过程中,还会涉及到很多的细节问题,都需要根据应用特点进行处理,这里不做深入分析。



    3. 服务容器化

    服务容器化是目前应用部署的趋势所在。服务容器化本身有很多不同的方式,例如基于Jenkins的pipeline实现,基于docker-maven-plugin + dockerfile实现,当然还有很多不同的方式。这里以Spring Cloud一个demo服务通过docker-maven-plugin+dockerfile实现说明为例:



    简易的一个服务的Dockerfile如下所示:


    ROM openjdk:8-jre-alpine
    ENV TZ=Asia/Shanghai \
    SPRING_OUTPUT_ANSI_ENABLED=ALWAYS \
    JAVA_OPTS="" \
    JHIPSTER_SLEEP=0
    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    CMD echo "The application will start in ${JHIPSTER_SLEEP}s..." && \
    sleep ${JHIPSTER_SLEEP} && \
    java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /app.jar
    # java ${JAVA_OPTS} -Djava.security.egd=environment:/dev/./urandom -jar /app.@project.packaging@

    EXPOSE 8080
    ADD microservice-demo.jar /app.jar



    文件中定义了服务端口以及运行命令。


    Maven-docker-plugin的插件配置如下所示:



    microservice-demo

    ......

    com.spotify
    docker-maven-plugin
    1.2.0


    build-image
    package

    build



    tag-image
    package

    tag


    ${project.build.finalName}:${project.version}
    ${docker.registry.name}/${project.build.finalName}:${project.version}





    ${project.basedir}/src/main/docker
    ${project.build.finalName}:${project.version}


    /
    ${project.build.directory}
    ${project.build.finalName}.${project.packaging}








    通过增加docker-maven-plugin,在执行mvn package的时候可以加载Dockerfile,自动构建服务的容器镜像(需要说明的前提是本地安装docker运行环境,或者通过环境变量在开发工具中配置Docker的远程连接环境),从而完成服务容器化改造。



    4. 容器环境构建

    容器环境决定这Service Mesh的部署形态,这里不详细描述容器环境的部署过程。感兴趣的朋友,可以参考https://github.com/easzlab/kubeasz 开源项目,提供了Kubernetes基于ansible的自动化部署脚本。我们也建议选择Kubernetes来构建容器环境。这里说明容器环境构建的考虑因素:


    · 集群部署方案
    集群部署方案主要考虑多集群,跨数据中心,存储选择,网络方案,集群内部主机标签划分,集群内部网络地址规划等多方面因素。

    · 集群规模
    集群规模主要考虑etcd集群大小,集群内运行实例规模(用来配置ip范围段),集群高可用节点规模等因素。


    基于以上两点来考虑容器化环境的部署方案,关键是合理规划,避免资源浪费。



    5. Service Mesh环境构建

    Service Mesh环境构建依赖于容器环境构建,主要考虑两个方面,以Isito为例:


    · 部署插件
    Istio部署插件需要根据需要的场景,考虑采用的插件完整性,例如prometheus,kiali,是否开启TLS等,具体安装选项可以参考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。

    · 跨集群部署
    依据容器环境考虑是否需要支持Isito的跨集群部署方案.



    6. 服务注入

    服务注入用于将容器化的服务接入到Service Mesh的平台中,目前主要有两种方式。以Isito为例说明,主要包括自动注入和手动入住。选择手动注入的目的在于可以根据企业内部上线流程,对服务接入进行人为控制。而自动注入则能够更加快捷,方便。到此实际上已经完成服务迁移工作。



    7. 服务管理控制台

    由于Service Mesh目前而言,多是基于声明式的配置文件,达到服务治理的效果,因此无法实时传递执行结果。基于这种原因,需要一个独立的Service Mesh的管理控制台,一方面能够查看各个服务的运行状态以及策略执行情况,另外一方面能够支持服务运行过程中策略的动态配置管理。目前而言,可以在Isito安装过程中选择kiali作为一个控制台实现,当然未来也会有大量的企业提供专门的服务。


    通过以上七个步骤,能够在一定程度上帮助企业应用,从Spring Cloud迁移到Service Mesh上,但迁移过程中必然存在不断踩坑的过程,需要根据应用特点,事前做好评估规划。



    #迁移优缺点分析

    Spring Cloud迁移到Service Mesh是不是百利而无一害呢?

    首先,从容器化的环境出发,后续Knative,Kubernetes,Service Mesh必然会构建出一套相对完整的容器化PaaS解决方案,从而完成容器化PaaS支撑平台的构建。Service Mesh将为容器运行态提供保驾护航的作用。

    其次,就目前Service Mesh的落地实现而言,对于一些特定需求的监测粒度有所欠缺,例如调用线程栈的监测(当然,从网络层考虑,或者不在Service Mesh的考虑范围之内),但是恰恰在很多服务治理场景的要求范围之中。我们也需要针对这种情况,考虑实现方案。

    最后,大家一直诟病的性能和安全问题。目前已经有所加强,但是依然被吐槽。

    整体而言,Spring Cloud是微服务实现服务治理平台的现状,而Service Mesh却是未来,当然也不能完全取而代之,毕竟设计思路和侧重点不同,是否迁移需要根据业务场景而定。


    本文由博云研究院原创发表,转载请注明出处。

    基于事件驱动机制,在Service Mesh中进行消息传递的探讨

    博云BoCloud 发表了文章 • 0 个评论 • 297 次浏览 • 2019-05-13 14:05 • 来自相关话题

    翻译 | 宋松 原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging # 关键点 ...查看全部
    翻译 | 宋松
    原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging



    # 关键点

    当前流行的Service Mesh实现(Istio,Linkerd,Consul Connect等)仅满足微服务之间的请求 - 响应式同步通信。

    为了推进和采用Service Mesh,我们认为支持事件驱动或基于消息的通信是至关重要的。

    在Service Mesh中实现消息传递支持有两种主要的体系结构模式;协议代理sidecar,它是来自消费者和生产者的所有入站和出站事件的代理;以及HTTP bridge sidecar,它将事件驱动的通信协议转换为HTTP或类似的协议。

    不管使用哪种bridge模式,sidecar都可以促进跨功能特性的实现(和纠正抽象),比如可观察性、节流、跟踪等。

    Service Mesh作为基础技术和基于微服务、云原生架构的架构模式越来越受欢迎。 Service Mesh主要是一个网络基础结构组件,允许您从基于微服务的应用程序卸载网络通信逻辑,以便您可以完全专注于服务的业务逻辑。

    Service Mesh是围绕代理的概念构建的,代理与服务作为sidecar进行协作。虽然Service Mesh常常被宣传为任何云原生应用程序的平台,但目前流行的Service Mesh实现(Istio/Envoy、Linkerd等)只满足微服务之间同步通信的request/response风格。但是,在大多数实用的微服务用例中,服务间通信通过各种模式进行,例如request/response(HTTP,gRPC,GraphQL)和事件驱动的消息传递(NATS,Kafka,AMQP)。 由于Service Mesh实现不支持事件驱动的通信,Service Mesh提供的大多数商品功能仅可用于同步request/response服务 - 事件驱动的微服务必须支持这些功能作为服务代码本身的一部分,这与Service Mesh架构的目标相矛盾。

    Service Mesh支持事件驱动的通信至关重要。本文着眼于支持Service Mesh中事件驱动架构的关键方面,以及现有Service Mesh技术如何尝试解决这些问题。



    # 实现事件驱动的消息传递

    在典型的request/response同步消息传递方案中,您将找到一个服务(服务器)和一个调用该服务的使用者(客户端)。 Service Mesh数据平面充当客户端和服务之间的中介。 在事件驱动的通信中,通信模式是截然不同的。 事件生成器异步地将事件发送到事件代理,生成器和使用者之间没有直接的通信通道。 通信风格可以是pub-sub(多个使用者)或基于队列的(单个使用者),并且根据样式,生产者可以分别向主题或队列发送消息。


    消费者决定订阅驻留在事件代理中的主题或队列,该事件代理与生产者完全分离。 当有可用于该主题或队列的新消息时,代理会将这些消息推送给使用者。


    有几种方法可以将Service Mesh抽象用于事件驱动的消息传递。


    Protocol-proxy sidecar

    协议代理模式围绕所有事件驱动的通信信道应该通过Service Mesh数据平面(即,边车代理)的概念构建。 为了支持事件驱动的消息传递协议(如NATS,Kafka或AMQP),您需要构建特定于通信协议的协议处理程序/过滤器,并将其添加到sidecar代理。 图1显示了使用service mesh进行事件驱动的消息传递的典型通信模式。



    1.jpg



    图1:使用service mesh的事件驱动的消息传递



    由于大多数事件驱动的通信协议都是在TCP之上实现的,所以sidecar代理可以在TCP之上构建协议处理程序/过滤器,以专门处理支持各种消息传递协议所需的抽象。

    生产者微服务(微服务A)必须通过底层消息传递协议(Kafka,NATS,AMQP等)向side car发送消息,使生产者客户端使用最简单的代码,而side car去处理与协议相关的大部分的复杂性。Envoy团队目前正在基于上述模式实现对Envoy代理的Kafka支持。它仍在进行中,但你可以在GitHub上跟踪进展。




    HTTP-bridge sidecar


    不需要为事件驱动的消息传递协议使用代理,我们可以构建一个HTTP bridge来转换需要消息协议的消息(to/from)。构建此桥接模式的关键动机之一是大多数事件代理提供REST API(例如,Kafka REST API)来使用和生成消息。如图2所示,通过控制连接两个协议的sidecar,现有的微服务可以透明地使用底层事件代理的消息传递系统。sidecar代理主要负责接收HTTP请求并将其转换为Kafka/NATS/AMQP/等。消息,反之亦然。




    2.jpg



    图2:HTTP bridge允许服务通过HTTP与事件代理通信



    同样,您可以使用HTTP桥接器允许基于Kafka / NATS / AMQP的微服务直接与HTTP(或其他request/response消息传递协议)微服务进行通信,如图3所示。在这种情况下,sidecar接收Kafka / NATS / AMQP 请求,将它们转发为HTTP,并将HTTP响应转换回Kafka / NATS / AMQP。目前正在努力在Envoy和NATS上添加对此模式的支持(例如,AMQP / HTTP Bridge和NATS / HTTP Bridge,都在Envoy做此种模式的支持)。




    3.jpg



    图3:HTTP Bridge允许基于事件驱动的消息传递协议的服务使用HTTP服务



    尽管HTTP-bridge模式适用于某些用例,但它还不够强大,不能作为service mesh体系结构中处理事件驱动消息传递的标准。因为对于基于request/response的事件驱动消息协议来说总是存在一些限制。它或多或少是一种适用于某些用例的方法。



    # 事件驱动service mesh的关键功能


    基于request/response样式消息传递的传统service mesh的功能与支持消息传递范例的service mesh的功能有些不同。以下是一个支持事件驱动消息传递的service mesh将提供的一些独特功能:


    • 消费者和生产者抽象:对于大多数消息传递系统,比如Kafka,代理本身是相当抽象和简单的(微服务上下文中的哑管道),而您的服务是智能端点(大多数智能都存在于生产者或消费者代码中)。这意味着生产者或消费者必须在业务逻辑旁边有大量的消息协议代码。通过引入service mesh,您可以将与消息传递协议相关的特性(例如Kafka中的分区再平衡)转移到sidecar,并完全专注于微服务代码中的业务逻辑。
    • 消息传递语义:有很多消息传递语义,比如“至多一次”、“至少一次”、“恰好一次”等等。根据底层消息传递系统所支持的内容,可以将这些任务转移到Service Mesh(这类似于在request/response范例中支持断路器、超时等)。
    • 订阅语义:还可以使用service-mesh层来处理订阅语义,例如消费者端逻辑的持久订阅。
    • 限流:可以根据各种参数(如消息数量,消息大小等)控制和管理消息限制(速率限制)。
    • 服务发现(代理、主题和队列发现):Service -mesh sidecar允许你在消息生产和使用期间发现代理位置、主题或队列名称。这涉及到处理不同的主题层次结构和通配符。
    • 消息验证:验证用于事件驱动消息传递的消息变得越来越重要,因为大多数消息传递协议(如Kafka、NATS等)都协议无关的。因此,消息验证是使用者或生产者实现的一部分。Service Mesh可以提供这种抽象,以便使用者或生产者可以转移消息验证。例如,如果您将Kafka和Avro一起用于模式验证,那么您可以使用sidecar进行验证(即,从外部scheme注册表(如Confluent)获取模式,并根据该模式验证消息)。您还可以使用它来检查消息中的恶意内容。
    • 消息压缩:某些基于事件的消息传递协议,如Kafka,允许数据被生产者压缩,以压缩格式写入服务器,并被消费者解压。您可以很容易地在sidecar-proxy级别实现这些功能,并在service-mesh控制平面上控制它们。
    • 安全性:您可以通过在service-mesh sidecar级别启用TLS来保护代理和消费者/生产者之间的通信,这样您的生产者和消费者实现就不需要担心安全通信,而可以用纯文本与sidecar通信。
    • 可观察性:由于所有通信都发生在service-mesh数据平面上,因此可以为所有事件驱动的消息传递系统部署指标、跟踪和开箱即用的日志记录。




    关于作者

    Kasun Indrasiri是WSO2的集成架构总监,是微服务架构和企业集成架构的作者/传播者。 他撰写了“微服务企业(Apress)和开始WSO2 ESB(Apress)”一书。 他是Apache提交者,曾担任WSO2 Enterprise Integrator的产品经理和架构师。 他曾参加过O'Reilly软件架构大会,GOTO芝加哥2019大会以及大多数WSO2会议。 他参加了旧金山湾区的大部分微服务会议。 他创建了硅谷微服务,API和集成会议,这是湾区的供应商中立的微服务会议。



    本文由博云研究院原创翻译发表,转载请注明出处。

    Linkerd or Istio?哪个Service Mesh框架更适合你?

    博云BoCloud 发表了文章 • 0 个评论 • 511 次浏览 • 2019-04-30 14:09 • 来自相关话题

    翻译 | 宋松 原文 | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42 本周我开始写一篇比较Istio和Linked的帖子,并 ...查看全部
    翻译 | 宋松
    原文 | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42



    本周我开始写一篇比较Istio和Linked的帖子,并且告诉我自己:我将用一个表格来比较两者的特性,这将会很棒,人们会爱上它,这个世界将会幸福几秒钟。我向自己承诺这将是一个公平的比较,没有任何偏见。虽然比较的表格仍然存在,但我转移了文章的终点:目标不再是哪个更好,而是哪个更适合你、你的应用程序和你的组织。

    在职业生涯的一段时间中,我曾担任某公司的售前架构师,记得有很多次我们被要求填写产品比较表。我经常需要运用创造力来确保产品看起来很好,几乎不惜一切代价避免表格中令人不愉快的“不支持”的框。考虑到诚信工作,但是有时候不得不这样做。

    站在评价者的角度来看,我理解他们(希望)的目的是进行公平的比较,在这种程度上,对比的表格似乎是一种可靠的方式。我们知道一个项目的成功可以预测职业的发展,我们都喜欢这一点。但问题是:如果评估的最终目标是产品对比表格,而不是能让企业更有竞争力的高质量软件,那么这个评估的最后将只是一些“表格”的工作。

    产品比较并不是最终目的,通过比较知道哪些对你的用例最好才是最终目的。因此让我们通过七个方面来深入研究Service Mesh,主要是以下几个方面:

    • 流量管理
    • 安全
    • 安装/配置
    • 支持的环境
    • 监测
    • 策略管理
    • 性能
    对于上述七个方面中的每一个,我都将发表个人观点,希望我的观点能够帮你做出更接近于简洁的决策。#流量管理需要强调的是,Istio和Linkerd的区别在于数据平面使用了两种不同的代理技术。Istio使用Envoy作为其代理。Envoy是C++编写的,最初是由Lyft构建,以便以非Kubernetes方式促进微服务的流量管理。许多公司已经将Envoy扩展为Kubernetes的ingress技术。Linkerd(v2)使用的是一种名为Linkerd-proxy的专用服务网格代理。这个代理是使用Rust编写的,与该代理一起,许多低级代理(网络客户机与服务器)功能在另一个也是由rust编写名为Tower的项目中实现。Tower依赖于Tokio,Tokio是一个由Rust编写的事件驱动非阻塞I/O库。如果你和我一样欣赏统计学,那么Rust已经连续四年(2016、2017、2018、2019)一直是Stack-overflow最受欢迎的语言。
    微信截图_20190429162020.png
    Istio是构建与Envoy之上的因此在流量管理方面它是占据优势的,Envoy已经包含了重要的IMHO功能,比如子集路由。用户仍然可以使用Linkerd实现金丝雀/蓝绿/a-b发布,但必须依靠单独的Kubernetes服务和能够分发流量的集群ingress技术,比如Gloo(gloo.solo.io)。Linkerd团队在最近一次社区会议上公开表示,计划在未来的版本中实现更加高级的L7流量管理功能。#安全关于安全,我正在考虑保护通信通道的能力。Istio和Linkerd两者都提供了合理的安全保护功能。
    微信截图_20190429162033.png
    Istio和Linkerd都依赖于外部根证书,因此两者都能保证进行安全通信。这听起来像是一个很好的周末项目,你觉得呢?#安装和配置
    3.png
    鉴于Istio可以安装在许多不同的平台上,安装说明可能会存在很大的不同。在写这篇文章的时候,关于Linkerd的安装,我对一些预先需要安装功能的检查印象很深刻。有很多次我在共享的Kubernetes集群中安装一些Linkerd功能时,我不清楚我是否拥有必要的权限。对于Linkerd,pre-check(或check-pre)检查你是否拥有在安装过程中创建Kubernetes所需资源的权限。#环境支持和部署模型对于是选择kubernetes或者是非Kubernetes安装,这是一个很直接的问题,Linkerd2是用基于kubernetes方式构建的,至少目前是这样的,而Istio收到了一下其他的公司的贡献,希望istio能在非kubernetes环境中运行。
    4.png
    考虑多集群部署,客观来说对于它的解释可能很棘手。从技术上来讲,共享根CA证书的多个不同集群(具有不同的控制平面)上的服务之间可以有效的通信。Istio扩展了上述概念,因为它支持不同情形下的多个集群:
    • 单个控制平面即可满足不同集群之间网络连接和pod之间IP寻址。
    • 通过使用具有单个控制平面的集群边界网关(egress和ingress)即可访问多个集群上的kubernetes API服务器。

    在上述两种情况下,包含控制平面的集群将成为mesh管理的SPOF(single point of failure)。在我们这个可以在同一区域下的多个可用区域上部署单个集群的世界中,这将不再是一个问题,但仍然不能完全忽略它。




    #监测



    5.png




    可以说Istio的管理控制台是一个缺失的部分。 Kiali Observability Console确实解决了一些管理员对service mesh所需的一些需求。

    Kiali(κιάλι)是一个希腊词,意思是望远镜,从Kiali的网站上可以清楚的看到它打算成为一个可监测性的控制台,而不仅仅是一个Service Mesh管理控制台。

    Linkerd控制台还不完整,但是社区决定也要构建一个管理仪表盘的目标是一个优势。

    Linkerd未能提供请求追踪。想要以非侵入方式查看请求追踪跨度必须等待Linkerd实现该功能。Istio利用了Envoy支持添加追踪headers的事实。

    应该提醒用户,应用程序需要准备好转发跟踪headers,如果没有准备,代理可以生成新的跟踪IDS,这可能会无意中将单个请求分割为多个请求跨度使请求之间失去必要的关联性。大多数开发框架都有转发headers的选项,而无需用户编写大量的代码。



    #策略管理

    Istio的爱好者,请欢欣鼓舞!Istio的策略管理能力令人印象深刻。

    该项目构建了一个可扩展的策略管理机制,允许其他技术可从多个方面与Istio集成,请参阅下面的“template”列表以及一些集成的提供者。你可以认为“template”是一种集成。


    6.png



    为了突出其他策略类型,Istio也可适用于rating和limiting以及提供对主体身份验证的开箱即用支持。Linkerd用户依赖集群ingress控制器提供rating和limiting。

    对于主体身份验证,我一直认为它应该委托给应用程序。请记住#4分布式计算的谬论:网络是安全的。对此持零信任策略。


    7.png



    Istio令人印象深刻的策略管理能力是需要代价的。考虑到他的广泛性,管理众多的选项增加了本已昂贵的运营成本。

    Istio(Mixer)的策略管理组件也增加了显著的性能,我们将在下面详细讨论。



    #性能

    对比表在哪里?幸运的是,就在最近,发布了两个很棒的博客,对Istio和Linkerd的性能进行了比较,我在下面引用了其中一些结论:

    对于这种综合工作负载,Istio的Envoy代理使用比Linkerd多50%的CPU。Linkerd的控制平面使用了一小部分Istio,特别是在考虑“core”组件时。



    ——Michael Kipper — Benchmarking Istio & Linkerd CPU(https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

    And…

    在本实验中,与基线设置相比,Linkerd2-meshed设置和Istio-meshed设置都经历了更高的延迟和更低的吞吐量。在Istio-meshed设置中产生的延迟高于在Linkerd2-meshed设置中观察到的延迟。Linkerd2-Meshed设置能够处理比Istio-Meshed设置更高的HTTP和GRPC ping吞吐量。



    ——Ivan Sim — Linkerd 2.0 and Istio Performance Benchmark(https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

    意识到Mixer所增加的处理时间,Istio团队目前正致力于重写Mixer组件:“Mixer将用c++重新并直接嵌入到Envoy中。将不再有任何独立的Mixer服务。这将提高性能并降低运营复杂性。”



    —Source Mixer V2 Design Document(https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s/edit)



    #总结



    是的,Istio比Linkerd2.3有多的特性。这是很好的,更多的特性意味着处理更复杂和边缘用例的能力增强。这没什么神奇的,更多的特性通常意味着更多的配置,潜在的资源利用率和运营成本的增加,所有这里有三条建议:



    如果你不知道80%最常见的工作负载是什么样子的,那么你将很难选择服务网格。如果你不知道这些数字,你的企业可能还没有准备好进行服务网格的使用。如果你只是在探索,那就另当别论了。

    如果你想计划解决所有可能的当前和未来的cases(通常叫做comparison spreadsheet),那么你将会有一段糟糕的时间。你很可能会过度获取,这对你购买的任何软件都是如此。

    盲目的选择一种技术或另一种会让你过的很糟糕。炒作可能很厉害,但请记住,你并不是在炒作业务(除非真的在炒作)。

    试试Istio和Linkerd! Solo SuperGloo是最简单的方式。

    我使用SuperGloo是因为它非常简单,可以快速启动两个服务网格,而我几乎不需要做任何努力。我们并没有在生产中使用它,但是它非常适合这样的任务。每个网格实际上是两个命令。

    ——Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify(https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781)。



    微信图片_20190429150753.png




    在Solo.io(https://www.solo.io/),我们希望为你的服务网格采用之旅提供便利。 Solo SuperGloo我们的服务Mesh orchestrator可以通过直观简单的命令安装和管理流行的服务网格技术。 正如Michael上面所指出的那样,安装Istio或Linkerd会成为一个单行活动。 SuperGloo并不止于此,它在不同的服务网格技术之上提供了一个抽象,允许对多个网格进行一致且可重复的操作。 SuperGloo是完全开源的,you can try it right now(https://supergloo.solo.io/)。

    本文由博云研究院原创翻译发表,转载请注明出处。

    企业应用架构演化探讨:从微服务到Service Mesh

    博云BoCloud 发表了文章 • 0 个评论 • 339 次浏览 • 2019-04-28 14:33 • 来自相关话题

    #导读 当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化,并形成落地方案。需要特别说明:本文讨 ...查看全部
    #导读

    当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化,并形成落地方案。需要特别说明:本文讨论的架构目前适用于普通的企业级应用,其他行业(例如互联网)需要进一步扩展。



    在讨论之前,我们需要明确一个事实:企业应用一定是围绕业务进行的。无论采用什么的架构落地,都是为了更好的为应用业务进行服务。从企业应用的特性考虑,主要包括:稳定性,安全性,扩展性,容错性。

    围绕着企业应用的这些特点,我们来看一个典型的微服务企业架构模型,如图所示:


    图片1.png



    • 服务接入层:企业暴露到外部访问的入口,一般通过防火墙等。
    • 网关层:服务网关是介于客户端和服务端的中间层,所有的外部请求会先经过服务网关,为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分,聚合,路由,认证以及流控综合体现。
    • 支撑服务层:为企业应用提供运行所需的支撑环境,包括注册发现,集中配置,容错限流,认证授权,日志聚合,监测告警,消息服务等
    • 业务服务层:业务服务是企业应用的核心所在,为企业领域应用的具体实现,一般进一步拆分为基础服务(基础功能)和聚合服务(综合场景)。
    • 平台服务层:为企业应用提供运行所需的软件资源,包括应用服务器,应用发布管理,应用镜像包管理,服务治理。
    • 基础设施层:为企业应用提供运行所需的硬件资源,包括计算资源,网络资源,存储资源,基本的安全策略控制等。
    从这个典型的服务架构体系中,能够清晰的表明层级架构以及各层涵盖的职责说明。我们暂不考虑基础设施层和平台服务两层,重点关注网关服务,业务服务,支撑服务,突出其中的一些基础支撑功能组件,这也是我们本篇探讨的重点内容。如下图所示:
    图片2.png
    根据图中红色标识,我们会发现这样一个事实:在微服务架构下,无论是哪种落地实现方式,都集中在网关服务、支撑服务两个层面。无论是Spring Cloud“套装组件”,Dubbo“套件”还是其他开源组件,都为支撑服务的实现提供了数量众多的选择。功能完整、选择性多这是业内喜闻乐见的事情,但是也无形中增加了开发,测试,运维人员的压力。大家需要掌握越来越多的“使用工具”以更“方便”、“快捷”地应对业务服务。有时候,可能为了实现单一功能,而必须引入一堆组件,这时候我们希望能够有一个完整的平台来为应用业务提供一体化的支撑服务,而不是一系列“套装组件”与业务的集成。那么如何基于一个平台来实现这些企业应用需要的能力呢?经过一定阶段的技术调研,我们认为Service Mesh能够帮助我们初步达到这个目标。我们都知道Service Mesh以解决“服务通信”的问题作为其设计初衷,聚焦基础设施“网络层”,并以此做技术基础,解决业务通信场景面临的问题。那么如何把它应用在企业应用架构中来取代“微服务套装组件”呢?那接下来让我们针对网关服务,业务服务,支撑服务分别来看一下,如何从原来的微服务“套装组件”中抽离出来,实现Service Mesh方向的转变。#网关服务前面提到过:服务网关是介于客户端和服务端的中间层。从功能上不难理解,对内屏蔽内部细节,对外提供统一服务接口。从场景聚焦角度考虑,网关根据不同的场景承载不同的职责,包括认证,授权,路由,流控,负载等。(之前我们也聊过网关组件的对比及具体实现,感兴趣的同学可点击微服务五种开源API网关实现组件对比)。由此可见,服务网关是企业应用架构下一些列功能的综合体现。那么在Service Mesh情况下如何处理网关服务呢?在展开之前首先需要说明一个前提:目前为止Service Mesh跟真正企业网关相比还存在一定的不足之处,例如“协议转化”,“安全策略”,“性能要求”等方面。在这里我们也是探讨这样的可能性。下面以Istio为例,我们来看一下,如何提供网关层面的服务。Istio在网关层面提供两种类型的网关服务:Ingress Gateway,Egress。
    • Ingress Gateway
    Ingress Gateway用于接收传入的HTTP/TCP连接,它配置暴露端口,协议供外部统一接入,但是自身不提供任何的路由配置,而是完全依赖 Istio 的控制规则来进行流量路由。从而与内部服务请求统一到同一个控制层面上。
    • Egress
    在企业应用与外部应用之间,有时候为了业务需要会出现内部服务调用外部服务的情况,此时一般会从企业内部接入第三方网关来获取服务数据。在 Isito 中你同样可以基于Egress来达到目的。Isito中提供两种方式:一种基于ServiceEntry VirtualService的配置,实现第三方服务的访问,一种扩大sidecar的访问地址列表。(参考文档:https://preliminary.istio.io/zh/docs/tasks/traffic-management/egress/)。基于上述两种场景,我们可以看出,在 Service Mesh 的体系下,网关层面变成一个可以动态生成和销毁的组件,能够通过控制层面实现统一规则管理,并且实时生效。基于Service Mesh的网关服务如下图所示:
    图片3.png
    从实现原理上分析,传统的网关实现基于 Servlet 的 filter 的模式,实现服务请求转移过程中的层层过滤和处理。区别在于采用同步或者异步处理机制,用来解决网关的性能瓶颈。而Service Mesh的网关完全是基于网络代理的请求转发与控制,本质上作用在服务的 Iptables 上,通过对 Iptables 的规则控制达到同样的效果。 #业务服务业务是企业应用的“重中之重”,无论哪种企业架构,最终都是为了更好地为业务提供服务,那么我们如何在Service Mesh的体系下,重构业务服务呢?我们以两个简化的服务调用来说明整个架构的转变过程。假如要实现服务A,服务B的相互调用,最原始的方式是服务A基于协议层直接调用服务B(这里暂时忽略高可用,多副本,负载均衡的方式),如图所示:
    图片4.png
    由图可见,服务A基于某种协议完成对服务B的请求,相对比较简单。但是我们知道这样虽然能够快速完成业务关联,但是无法确保业务正常稳定的运行,因此我们需要引入更多的服务来保证业务的稳定,可靠,可控。此时我们最容易想到的是引入微服务的支撑组件来达到目标。以Spring Cloud方案为例,我们来说明当前微服务架构的实现方式。为了满足企业应用对服务A,服务B的管理控制,需要额外引入“注册中心”,“网关”,“配置中心”,“服务监测”,“事件消息”,“链路跟踪”,“日志服务”等众多与直接业务无关的“旁路保障服务”,简化一下,如下图所示:
    图片5.png
    从图中可以看出,每个服务都引入了大量与业务无关的“保障服务”,这些“旁路保障服务”消耗的资源,与比业务本身消耗的资源成“倍数关系”。随着服务数目的增多,业务服务本身占用的资源比会越来越少,此时开发人员会把大量的精力花费在维护这些“旁路保障服务”上,而忽略业务本身。这对于企业应用而言,有些本末倒置的意思。我们再来看一下 Service Mesh 体系下,我们如何解决上述问题。Service Mesh为了解决企业应用的“通信问题”重点做了四个方面的工作,以 Istio 为代表,提供了包括流量管理,安全配置,策略控制以及外围组件支撑的遥测功能(需要的朋友,可以参考官方文档:https://preliminary.istio.io/zh/docs),在Service Mesh的架构下,服务A调用服务B的架构会变成下图所示:
    图片5.png
    通过上图我们可以发现,与Spring Cloud的实现方式相比,似乎简单了很多,我们不再需要在业务服务中引入众多的“旁路保障服务”,而是保障了业务服务本身的简单化。那么Service Mesh是如何处理的呢?第一,引入了Sidecar代理模型,作为服务流量控制的入口和出口,保证能够对网络层面数据做实时监控和调整;第二,控制器根据具体业务情况,分发控制状态和控制指令,Sidecar获取控制信息后,及时更新缓存信息,保证策略有效性。第三,Sidecar由于能够拦截所有请求的流量信息,定期把收集的数据向控制层进行上报,从而完成服务状态和应用链路的监测。第四,所有的这些都是在应用部署阶段完成,在开发层面不需要花费大量的精力。基于以上四点我们可以发现,Service Mesh 仅仅通过方式转变就达到了同样的效果,还极大的解放了开发人员。通过业务服务调用方式的实现转变,我们发现这样一个事实:Service Mesh在保证业务简化有效的同时,进一步屏蔽了多种开发语言带来的障碍。它完全基于网络层面和协议层面作为出发点,达到“以不变应万变”的效果。 #支撑服务从企业业务的价值角度考虑,其实支撑服务更多属于“资源消耗”品,虽然如此,它却是企业应用架构不可或缺的一部分。从单一的业务调用--->微服务体系业务调用--->Service Mesh 体系业务调用的转变方式中,可以看出支撑服务处于一个层级不断下降的过程。而依赖于ServiceMesh的定位,最终一些支撑服务会作为基础设施的形态呈现出来,这也是未来发展的趋势所在。支撑服务在企业架构的形态转变如图所示:
    图片6.png
    • 传统架构:传统架构下,支撑服务,业务服务基本上没有明确的边界区分,实现方式上都通过代码杂糅在一起。
    • 微服务架构:微服务架构下,支撑服务,业务服务能够初步分离,但是需要保证代码框架的统一性和依赖性,跨语言受限比较严重。
    • Service Mesh架构:Service Mesh架构下,支撑服务,业务服务能够彻底分离,不收语言限制,唯一需要考虑的是不同协议的支持情况。
    通过支撑服务的转变形态可以看出,支撑服务与业务服务分离是必然趋势,而最终的受限取决于多元化的网络协议的处理分析能力。当然我们需要明确一个事实:就Service Mesh目前的发展趋势和定位而言,并不能够完全取代所有的支撑服务,例如事件消息,配置管理等。我们更多期望它能够帮助解决应用服务在网络层面需要面对的场景和问题。这也是它发挥价值的地方所在。通过对网关服务,业务服务,支撑服务在不同体系架构下的转变,我们清晰的认识到Service Mesh能够帮助我们重点解决微服务体系下繁琐的“旁路支撑”服务,保证业务服务的简单有效性。通过演化分析,最终基于Service Mesh的企业应用架构如下图:
    图片6.png
    从图中可以看到 Service Mesh 架构下重点做了三件事情:
    • 网关层的接入工作,无论是外部请求接入,还是内部服务请求转发,都可以基于 Service Mesh 提供的不同类型的 gateway 实现,同时还可以保证策略的统一控制和管理。省略了独立的网关管理控制台。
    • 针对业务服务,增加了 Sidecar 的代理模型,用来处理所有的入站和出站流量,并且配合支撑服务的控制策略,实现业务服务的旁路控制功能。
    • 统一面向网络的支撑服务,基于控制与数据分离的思想,根据业务的运行情况,提高企业应用运行过程中的动态控制能力。
    同样我们也意识到,利用 Service Mesh 处理服务通信的能力,替换需要不同组件支撑的“注册发现”,“容错限流”“认证授权”“日志搜集”,“监控告警”“流量控制”等功能。在减少组件代码开销的同时,将企业应用的支撑服务进一步下移。无论是开发人员,还是领域专家,可以集中精力用来处理应用业务,而不用在维护第三方的不同的功能组件上“浪费时间”。而业务运维人员,通过 Service Mesh 的控制平台,能够实时监测企业服务的运行状态,而不需要向之前那样花费精力维护不同的工具和组件。 最后让我们一起讨论一下,Service Mesh是如何做到这些的。Service Mesh 本质上并没有采用任何技术上的创新,更多是思想层面的变革。我们认为有几个转变是需要提出来的:
    • 层级转变:Service Mesh在设计思路上,把自己不再定位成企业应用组件,而是把自己下沉到基础设施层,成为基础设施的一部分,这样层级的转变就与企业业务本身划清楚界限。
    • 方式转变:Service Mesh在实现思路上,高度抽象,聚焦于通信链路本身,而不是聚焦于组件功能上,从网络层入手,抓住了服务通信交互的本质。
    • 控制转变:Service Mesh将控制和实现分离,提供统一,灵活的控制入口,能够快速方便的针对业务场景进行自定义处理。


    最后的最后需要说明 Service Mesh 还不完善,还有很多问题需要在实际的企业应用过程中逐步去解决,让我们一起拭目以待吧。


    本文由博云研究院原创发表,转载请注明出处。