最新公告
  • 新注册用户请前往个人中心绑定邮箱以便接收相关凭证邮件!!!点击前往个人中心
  • 服务网格ServiceMesh是什么?

    原始时代

    1969年11月,为了便于高校间共享资源,美国国防部高级研究计划管理局建立一个名为阿帕网络ARPAnet,起初只有四个节点。

    阿帕网起源

    一年后阿帕网的节点数量增至15个,此后平均每隔二十天就有一台大型计算机接入。

    随着网络在世界范围不断扩大,不同国家不同地区各自形成了一个网络,操着不同方言彼此间互不相通,诸侯割据格局已经形成。

    隔离的阿帕网

    这个时候机器与机器之间通信是靠彼此约定的方式进行。

    计算机靠方言通信

    机器需要自行处理网络通信过程中遇到的丢包、乱序、重试等问题。

    青铜时代

    为了解决各国家各地区网络不能互通的问题,1973年两位年轻的小伙子开始发力了,致力于研究一种通讯方法,能够解决不同机器型号的计算机互相通信,简单说就是用普通话替代方言,这就是大家熟知的“TCP/IP”协议。

    鲍勃·卡恩(左)与温顿·瑟夫(右)

    随着 TCP/IP 协议逐渐普及后,一张大的 Internet 网络由此形成。

    Internet

    这个时候机器与机器之间通信的问题已经解决,TCP/IP 可以保证信息可靠性传输,我们只用关系业务逻辑即可。

    依赖 TCP/IP协议实现机器间传输

    黄金时代

    在 TCP/IP 协议刚兴起时,计算机上的应用还很贫乏,机器与机器之间通信一般用来简单的数据传输。

    随着 WEB 互联网技术兴起,基于 TCP/IP 协议出现了很多应用层协议,国内出现了一批优秀的互联网公司如腾讯、新浪、搜狐、淘宝等。

    当时访问量并不大,采用单体架构基本就可以满足。

    单体应用之间调用

    服务的数量不多,每个服务都有一个唯一的IP 地址,服务与服务之间交互通过 IP寻址。

    铂金时代

    网民数量越来越多,单个实例扛不住日益增长的访问量。通常会在一个机器上部署多个实例组成集群,服务1访问服务2不再是之前的点到点了,现在变成了点到多点,中间会加一个负载均衡解决流量均衡问题。

    单体应用集群之间调用

    钻石时代

    随着互联网业务访问量井喷,通过横向扩展服务实例的方法也开始遇到瓶颈了,单个服务越来越大,代码模块耦合严重,修改一行代码可能影响整个系统。

    问题来了,解决方案也随着而来,“微服务”横空出世了。将一个业务服务按功能模块切分为多个微服务,比如将 Service1 切分为 Micro Service1,Micro Service2,Micro Service3。

    在单体服务中Micro Service1调用Micro Service2可能就是一个模块调用另外一个模块,调用一个公开的函数就能搞定,拆为微服务之后就变成了两个微服务直接的调用,这种调用是要通过网络通信实现。

    微服务间调用

    星耀时代

    随着业务扩张,对系统的高可用要求越来越高,一些重点微服务如订单、账单等可能会部署成百上千个实例,运维人员的负担也在逐渐加大,如果机器挂了要手动删除,如果遇到重大活动如双十一可能要扩展几千个实例,运维人员需要手工添加,人工干预越多出错的概率越大。

    第一代微服务技术应运而生。

    代理内嵌

    每个微服务内嵌一个代理用来处理服务注册和发现的逻辑,国内以阿里Dubbo,微博的 Motan 为代表。这类框架不足的地方很明显:微服务与代理耦合、不支持多语言。

    王者时代

    针对第一代微服务框架的不足,大家在纷纷探索下一代微服务框架。

    在每一个主机上单独部署一个代理进程,多个微服务共用一个代理进程,实现服务发现和负载均衡。

    代理进程

    这种模式通常被大家称为“sideCar”,也就是“边车模式”。

    什么叫“边车”,在早期有一种摩托车,驾驶位置旁边挂着一个拖斗,对比微服务旁边挂一个代理进程,所以形象地称为“边车模式”。

    摩托车拖斗

    在新一代的 ServiceMesh 架构中,服务消费者和服务提供者都会部署SideCar。

    SideCar 模式

    服务与服务之间是靠 sideCar 连接起来,sideCar 用来处理与业务无关的注册、发现、熔断、限流等治理能力。

    略去业务服务和其他无关的东西,将所有的 sideCar 连接起来可以得到下面这张图:

    服务网格

    是不是长得像网格,服务网格(service mesh)由此得名。

    维基百科是这样定义服务网格

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

    总结

    ServiceMesh(服务网格)的特点:

    • 场景:用于微服务间的服务通信和服务治理
    • 方案:边车模式
    • 定位:基础设施层

    服务网格是一种比较新的架构风格,大家在技术选型时不要盲目追新,适合当前业务发展的技术才是最好的技术。大家学会了吗?

    本站所有文章均由网友分享,仅用于参考学习用,请勿直接转载,如有侵权,请联系网站客服删除相关文章。若由于商用引起版权纠纷,一切责任均由使用者承担
    极客文库 » 服务网格ServiceMesh是什么?

    常见问题FAQ

    如果资源链接失效了怎么办?
    本站用户分享的所有资源都有自动备份机制,如果资源链接失效,请联系本站客服QQ:2580505920更新资源地址。
    如果用户分享的资源与描述不符怎么办?
    可以联系客服QQ:2580505920,如果要求合理可以安排退款或者退赞助积分。
    如何分享个人资源获取赞助积分或其他奖励?
    本站用户可以分享自己的资源,但是必须保证资源没有侵权行为。点击个人中心,根据操作填写并上传即可。资源所获收益完全归属上传者,每周可申请提现一次。
    如果您发现了本资源有侵权行为怎么办?
    及时联系客服QQ:2580505920,核实予以删除。

    参与讨论

    • 155会员总数(位)
    • 3735资源总数(个)
    • 0本周发布(个)
    • 0 今日发布(个)
    • 382稳定运行(天)

    欢迎加入「极客文库」,成为原创作者从这里开始!

    立即加入 了解更多
    成为赞助用户享有更多特权立即升级