什么是服务网格?为什么你需要它?
什么是服务网格?为什么你需要它?
服务网格是专注于基础设施层???,让服务可以更安全、更快、更可靠地通信。如果构建云应用,你就需要服务网格。
在过去一年,服务网格已经呈现出,并在云原生栈中起着决定性的作用。像一些高流量的公司,比如说Paypal,Lyft,Ticketmaster, 还有Credit Karma,在今年一月份就已经在自己的产品中使用了服务网格。Linkerd,一个开源的为云原生应用而生的服务网格,成为了云原生计算设施的官方项目。精确地来说,什么是服务网格呢?为什么和它有关系呢?
在本文中,通过过去十年的应用架构,给服务网格定义和它的组织体系。从有关系的但是不同的API网关、边缘代理、服务总线的组成,来区分服务网格。描述哪里是服务网格顶层,还有期待它是由什么组成的,并使得云计算基础设施进化的?
什么是服务网格?
服务网格,是在基础设施层,让处理服务间可以通信。它的责任是通过服务里复杂的技术组成的云基础设施层,来保证请求的可靠性。在实践中,服务网格是有代表性地实现了一组,在服务代码之外的轻量级网络代理,而不需要服务来唤醒它。(但正如我们所看到的,这是奇怪想法)
服务网格作为一个独立的层与云原生应用相联系。在云原生模型里,单个应用可能由数以百个服务组成,甚至是几千个实例。因为它们是动态被调度(类似于Kubernetes),所以每个实例可能不断地改变状态。在非常复杂的世界中,不仅是服务通信,这是普遍基本运行行为的一部分。管理它是至关重的,要确保端对端的性能和可靠性。
服务网格是网络模型?
服务网格是一个网络模型,它是在TCP/IP之上的抽象层。假设在L3/L4网络下是即时的,并可以从点对点中发送字节。(这也可以假设这个网络,有其他环境东西,是不可靠的。因此服务网格必须可以处理网络失败的)
在其他方式中,服务网格是类似TCP/IP。因为在网络之间,TCP栈抽象了字节传输的可靠结构;而在服务间,服务网格抽象了请求传输的可靠结构。类似于TCP,服务网格不关心实际负荷和具体如何编码的。应用有高级别的目标(从A发送一些东西给B),而服务网格的工作就像是TCP,当任何失败在其中的时候,也要完成目标。
不像TCP,在“可以工作之外”,服务网格是有一个主要目标的:提供一个统一的,为了介绍可见的广泛应用的点,并控制应用的运行时。服务网格的明确目标是让服务间通信移动到不可见的领域中,隐秘的基础设施,成为生态系统中的首要成员,你在这里监控,管理和控制。
服务网格实际上是做什么的?
在云原生应用,可靠的传输请求可以非常复杂的。服务网格中,比如 Linkerd ,它管理着复杂的一组有能量的技术:熔断,负载均衡,最终的服务发现(咨询),重试,截止日期。特性必须结合地工作和交互,在复杂的环境中,它们的处理是很微妙的。
作为例子,当一个请求通过Linkerd创造一个服务,是简单的时间轴事件,如下:
- Linkerd提供动态的路由规则来决定哪个服务来准备。在生产中和预上线,请求应该被路由哪个服务呢?服务在本地中心还是在云上呢?为了获取最新版本的服务来测试,或者在生产环境检验一个比较老的服务。所有路由规则是动态配置的,而且可以设置为全局和有任意分片运输。
- 可以找到正确的目的地,Linkerd从相关的服务发现中,恢复实例的通信池,而且可能有几个。在实践中,如果信息分别来自Linkerd的观察,会让源信息更真实。
- Linkerd选择实例并快速返回,这基于许多因素,包括默默地观察最近的请求。
- 意图发送请求到实例中,记录潜在因素和结果的相应类型。
- 如果实例挂载了,没有响应,或者请求失败,会重试发送请求给另外一个实例(但是请求是要幂等的)。
- 如果实例持续返回错误,会从负载均衡池里面把它给踢掉,而后会偶尔重试(在例子中,实例可能会有短暂的失败)。
- 如果请求在截止时间没有响应,将会主动放弃请求而不是进行重试。
- 它捕获了上面各种行为,获取到了指标和踪迹,可以集中系统指标数据。
在简易版本中,Linkerd可以初始化和终止TLS,协议更新,动态迁移,和在数据中心之间故障切换。
服务网格管理着服务间通信,而从程序代码中分离。
这是重要的笔记,这些特性是包含逐步恢复和应用广泛恢复。大规模分布式系统,无论是它们是怎么样的架构,有典型的特征:提供很多。服务网格必须设计得安全,当系统接近极限的时候,要增加限流和速失败。
为什么服务网格至关重要?
服务网格是根本上没有介绍新的功能,而是功能定位???改变了。web应用总是管理这服务通信的复杂性。服务网格模型的起源,可以在这些应用过去十年半演变过程追溯.
想起了在2000年的经典中型web项目架构:三层应用。在这个模型下,应用逻辑、web服务逻辑、储存逻辑都是按层分开的。两个层次之间通信,是复杂的,在作用域里有限制,只有两个地方可以跳。这不是“网格”,但是在节点中这样的通信,由每一层的代码自身处理。
在这个架构形式可以提供很大的规模,并开始破裂。一些公司:Google、Nerflix、Twitter面对着大量传输需求,实现了有效的云原生方法的前身:应用层分布了多个服务(有时候称为“微服务”),这些排列的层次变成技术。在这些系统,广义上的通信层变得有关系了,但是代表性地拿到了“胖客户端”库代码——Twitter的Finagle, Netflix的Hystrix, 还有Google的Stubby 成为了这个方面的例子。
在很多方式中,库像Finagle、Hystrix、Stubby是第一个服务网格。当它们指定了周边环境的细节,需要使用指定的语言和框架,专注于基础设施并用于管理服务间通信,(在案例中,开源的例子有Finagle 和 Hystrix libraries)起源于它们公司的外部使用。
快进到现代的云原生应用。云原生模型组合了很多微服务方法,使用了两个额外的因素:容器(例如Docker),它可以提供资源的隔离和依赖管理;还有协调层,(例如Kubernetes),它可以抽象下层的硬件到一个资源池里。
这三个组件可以让应用适应原生机制的收缩,和处理云环境经常出现的局部错误。但是成千上百的服务实例,而管理层时时刻刻地重新调度实例,一个请求路径通过服务使用的技术可以变得非常复杂,在容器里可以容易地让每个服务可以使用不同的语言编写,类库的使用不再可行。
在复杂的组成和临界点的驱动下,需要专注的层来实现服务间通信,使得代码分离开了应用,能够获取更高的动态原生的环境。这一层就是服务网格。
服务网格的未来
在云原生应用???的生态中,服务网格的使用在迅速地增长,广泛的让人兴奋的学习路依旧在探索中。无服务器计算的需求(例如Amazon的Lambda)适合使用服务网格模型来命名和连接,在云原生生态中它是其中的延伸。在服务原生环境中,服务的角色身份和权限依然很初级,服务网格可以很自然地成为这个故事的一部分。最终,服务网格,像之前的TCP/IP,将继续默默地推进基础设施的发展。例如Linkerd和Finagle一样,就是从系统中逐步形成,当前服务网格典型工作是,隔离,用户空间代理,这些必须明确加入到云原生栈中并继续发展。
结论
服务网格是云原生栈决定性???的组件。它启动已经超过一年,Linkerd是云原生计算基础设施的一部分,而它的社区里有活跃的贡献者和用户。从启动到接管像Monzo,那时候英国的银行业很混乱。对于高流量的互联网公司,像Paypal、Ticketmaster、Credit Karma,像公司一样Houghton Mifflin Harcourt已经有数百年的业务了。
posted on 2019-05-21 14:47 William_Dai 阅读(655) 评论(0) 编辑 收藏 举报