• Service Mesh


    简单的说,Service Mesh就是微服务时代的TCP。

    我们来看看它的产生:

    最初

    服务A和服务B想要通讯,于是添加了网络传输,大佬建立了一套底层能够传输字节码和电子信号。

    为了能够服务自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题,因此服务实现中,除了业务逻辑外,还夹杂着对网络传输问题的处理逻辑。

    流量控制

    服务A和服务B可能是不同的机器,他们发送和消化的速度不一定一致,这样就可能导致B被阻塞,甚至带来包乱序的问题,或者B干脆被过载,甚至崩溃。

    所以添加了flow control (流量控制)。流量控制是一种机制,可以防止一个服务器发送的数据包数量超过下游服务器可以处理的数量

    TCP的出现

    TCP/IP等协议将流量控制和许多其他问题的解决方案纳入网络堆栈本身。

    到这里,我们使用计算机进行网络通讯的时候,已经对上诉问题无感了。

    微服务的到来

    分布式系统的出来,带来了新的机遇和挑战。它将多个服务器组合起来,迸发了更强的能力,但是相互之间的协调也成了新的问题。

    就想操作系统,需要管理各个资源的协同,微服务,也需要一个管家。

    它需要处理:熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等,让各个服务之间更和谐地沟通、协作。

    这里引申一下:

    分布式计算的八个谬误

    分布式计算的八个谬误

    1. 该网络是可靠;
    2. 延迟为零;
    3. 带宽无限;
    4. 网络是安全的;
    5. 拓扑不变;
    6. 有一名管理员;
    7. 运输成本为零;
    8. 网络是同质的。
    

    谬论的影响

     • 编写软件应用程序时几乎没有对网络错误进行错误处理。在网络中断期间,此类应用程序可能会停止或无限等待应答数据包,从而永久消耗内存或其他资源。当出现故障的网络可用时,这些应用程序也可能无法重试任何停止的操作或需要(手动)重新启动。
     • 对网络延迟及其可能导致的数据包丢失的无知导致应用层和传输层开发人员允许无限流量,从而大大增加丢弃的数据包并浪费带宽。
     • 流量发送方对带宽限制的无知可能会导致瓶颈。
     • 对网络安全的自满导致被恶意用户和不断适应安全措施的程序蒙蔽了双眼。
     • 网络拓扑的变化会对带宽和延迟问题产生影响,因此可能会出现类似的问题。
     • 与竞争对手公司的子网一样,多个管理员可能会制定相互冲突的策略,即网络流量的发送者必须了解哪些策略才能完成其所需的路径。
     • 构建和维护网络或子网的“隐藏”成本是不可忽视的,因此必须在预算中注明,以避免出现巨大的短缺。
     • 如果一个系统假设一个同构网络,那么它可能会导致与前三个谬误相同的问题。
    

    进一步抽象

    这种协同是属于公共方法,每个服务都需要具备,大佬开始想将他们抽象成一个基础库,就想之前将限流组件抽象出来一样。

    让开发者不必关心这些细节。

    Sidecar 边车模式

    每个服务自己控制自己的限流熔断逻辑,这已经和TCP很接近了,但是还不够,因为微服务是需要调控的,也就是需要管家去指挥。所以我们需要集中管理:

    集中式的控制面板

    总结

    现在,我们再回过头来看Buoyant的CEO William Morgan,也就是Service Mesh这个词的发明人,对Service Mesh的定义:

    服务网格是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中,服务网格通常是由一系列轻量级的网络代理组成的,它们与应用程序部署在一起,但对应用程序透明。

    这个定义中,有四个关键词:

    • 基础设施层+请求在这些拓扑中可靠穿梭:这两个词加起来描述了Service Mesh的定位和功能,是不是似曾相识?没错,你一定想到了TCP;
    • 网络代理:这描述了Service Mesh的实现形态;
    • 对应用透明:这描述了Service Mesh的关键特点,正是由于这个特点,Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题;

    总结一下,Service Mesh具有如下优点:

    • 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等),服务只用关注业务逻辑;
    • 真正的语言无关,服务可以用任何语言编写,只需和Service Mesh通信即可;
    • 对应用透明,Service Mesh组件可以单独升级;

    当然,Service Mesh目前也面临一些挑战:

    • 以代理模式计算并转发请求,一定程度上会降低通信系统性能,并增加系统资源开销;
    •接管了网络流量,因此服务的整体稳定性依赖于Service Mesh,同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战;

    历史总是惊人的相似。为了解决端到端的字节码通信问题,TCP协议诞生,让多机通信变得简单可靠;微服务时代,Service Mesh应运而生,屏蔽了分布式系统的诸多复杂性,让开发者可以回归业务,聚焦真正的价值。

    参考:

    https://zhuanlan.zhihu.com/p/61901608
    https://philcalcado.com/2017/08/03/pattern_service_mesh.html

  • 相关阅读:
    魏新 20190912-1 每周例行报告
    魏新 20190912-2 命令行
    魏新 20180912-3 词频统计
    魏新 20190905-1 每周例行报告
    魏新 20190905-3 命令行和控制台编程
    魏新 20190905-2 博客作业
    20190911-例行报告
    肖亚男 20190910-2 博客作业
    宋晓丽20190919-5 代码规范,结对要求
    宋晓丽20190919-3 效能分析
  • 原文地址:https://www.cnblogs.com/HappyTeemo/p/15457133.html
Copyright © 2020-2023  润新知