服务化的未来--ServiceMesh?

微服务之后什么最火?毫无疑问ServiceMesh。 目前各个大厂都在Mesh化,Mesh的前身是Side Car模式,随着互联网时代/移动互联网时代以及未来IOT时代发展,互联网架构在数据量,高并发,高可用场景会面临几何倍数的增长,同时对于我们的系统也是几何倍数的挑战,我们需要在这个时间点到来之前将我们的系统提前进化,于是CNNF,Service Mesh成为了服务化的未来。

系统服务化之后,服务间通信需要关注什么:

  • 服务发现
  • 负载均衡
  • 路由
  • 流控
  • 通信可靠性
  • 弹性
  • 安全
  • 监控,日志

API 网关

API网关可以集中式的管理这些功能,但是会出现单点故障,并且实现起来网关会变得越来越臃肿。 并且网关是一个集中式的处理,Service Mesh是网络通信基础设施,可以将网络功能从代码中剥离出来。 通过Service Mesh不用在服务代码中实现用于可靠性通信的模式或断路,超时等控制。

Service Mesh是一个专门的软件基础设施层,和主进程独立,通过(HTTP,GRPC)进行代理通信,用于控制和监控微服务应用程序中服务到服务的内部通信,让服务到服务通信变得快速,安全,可靠。

通常分为:数据层和控制层。

服务开发者不会意识到Service Mesh的存在,平台工程师则通过这套新的工具,以确保可靠性,安全性和可见性。

我们可以将Service Mesh看成路由器和交换机互联的设备组成的(第七层)网络。

通常我们采用代理方式,拦截所有出入的流量来进行请求的安全,可靠,及时的处理。

Service Mesh架构中代理使用的是边车模式实现的。

边车模式:是附属在主应用程序,提供平台功能用以补充该主应用程序功能,比如路由,负载均衡,弹性,深度探测和访问控制。

Service Mesh不仅扩展了主应用的能力,还要监控和保护应用程序,是插在微服务和网络之间的一个透明的基础设施层,以便对服务进行插入,收集检测数据,而无需修改应用程序。

以Linkerd为例

当一个请求经过Linkerd时,会发生以下事件。

Linkerd根据动态路由规则确定请求是发送给哪个服务的,比如是发送给生产环境的还是staging环境的服务? 是发给本地数据中心的还是云端数据中心的服务? 是发送给新版的还是旧版的服务?这些路由规则是可以动态配置的,可以应用在全局的流量上,也可以应用在部分流量上。

在确定了请求的目标服务后,Linkerd从服务发现端点获取相应的服务实例。如果服务实例信息出现了偏差,Linkerd需要决定从哪个信息的来源更值得信任。

Linkerd根据某些因子,比如最近处理请求的延迟情况,选择更优秀的实例。

Linkerd向选中的实例发送请求,并把延迟情况和响应信息记录下来。

如果选中的实例发生宕机,无法响应请求,Linkerd会把请求转发给其他实例,当然服务实例需要做成幂等的。

如果一个实例持续返回错误,Linkerd就会将其从负载均衡池移除,并在稍后定时重试,重试成功重新放入负载均衡池。

如果请求超时,则不进行重试,进行记录,最终一致性。

Linkerd以度量指标和分布式日志的方式记录上述行为,然后将度量指标发送中心度量指标系统。

Service Mesh

大规模分布式系统又一个共性:局部故障累积到一定程度会造成系统层面的灾难。

Service Mesh作用是在底层系统的负载达到上限之前,通过流量分散和快速实效来防止这些故障破坏整个系统。

云原生应用的前身:应用层被拆分成多个服务,也就是微服务,这样的系统需要一个通信层,以客户端SDK的方式存在。

云原生应用在之前微服务模型中加入了两个额外的元素:容器和服务编排层。容器提供了资源隔离和依赖管理,服务编排层对底层的硬件进行抽象池化。

边车SDK,容器,服务编排框架让应用程序在云环境中具备了伸缩能力和处理故障的能力。但随着服务实例的数量增长,服务编排需要无时无刻的调度实例,请求在服务拓扑之间穿梭的轨迹变得越来越复杂,再加上不用语言开发的服务实例很多,之前的“胖客户端”方式行不通了。

于是催生了服务间通信层的出现,这个层不会与应用程序的代码耦合,又能捕获底层环境的高度动态的特点,就是Service Mesh。

原文发布于微信公众号 - 服务端技术杂谈(ITIBB2014)

原文发表时间:2018-07-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

Python的web框架-Bottle

近日除了日常的工作复习(没错,KIM 是个准备裸考的考研狗),就是尝试着Python的web框架的一点点东西,今日特地搬出来跟大家分享下。 Python常见的文...

21910
来自专栏编程

大型分布式服务器架构原理解析

作为技术人员,我们都知道:几乎所有的项目,都是由简单到复杂,从单一服务器到集群服务器进行开发。但又有多少人知道这其中的技术原理呢?其实,这并不是那么深奥难懂。那...

4069
来自专栏微服务

关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识...

40615
来自专栏即时通讯技术

简述移动端IM开发的那些坑:架构设计、通信协议和客户端1、前言 2、学习交流3、概述4、有关移动端IM通信协议的坑5、移动端IM客户端的坑6、移动端IM架构设计的坑7、结语附录:更多IM技术文章

有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题,导致一个完整的移...

1931
来自专栏架构师之路

多key业务,数据库水平切分架构一次搞定

数据库水平切分是一个很有意思的话题,不同业务类型,数据库水平切分的方法不同。 本篇将以“订单中心”为例,介绍“多key”类业务,随着数据量的逐步增大,数据库性能...

4137
来自专栏网站设计制作、数字营销

网站制作前网站主机空间的选择

无论是企业公司还是学校教育机构等事业单位,网站制作完成之后往往需要将网站上传配置到相应的主机空间中。网站的主机空间的选择也是一项重要的工作,通常是由网站制作公司...

2633
来自专栏嵌入式程序猿

这只电子狗跑哪里去了,快找

最新新换了批电脑,所有的开发软件都要重装,其中在IAR安装完,license激活后,打开软件时总是提示找不到dongle,导致项目无法编译,我用的是8.20版本...

1102
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|性能测试

5175
来自专栏云计算D1net

混合云和多云管理不再难:基础架构即代码来帮忙

随着运维流程变得越来越灵活,IT团队面临着越来越大的复杂度。当应用动态改变时,可以使用敏捷或者持续应用开发。但是当IT资源本身动态变化的时候怎么办呢多云和混合云...

3867
来自专栏企鹅号快讯

Smartnet 网络运维

「举一反三」 「继开源工具分享之后,本章系列文章将带来团队初尝自研的一些故事和技术分享、几个python模块、几个自动化空白工作领域等....」 1、作者介绍 ...

2469

扫码关注云+社区

领取腾讯云代金券