计算密集型应用以ServiceMesh为支点解决分布式问题的探索与实践.pptx

计算密集型应用以ServiceMesh为支点解决分布式问题的探索与实践.pptx

  1. 1、本文档共31页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多

计算密集型应用以ServiceMesh为支点解决分布式问题的探索与实践

京东集团架构师/王志龙

个人简介

10年+互联网一线研发及架构经验,KubernetesContributor,LayottoWasmMaintainer,专注云原生领域,擅长性能极限优化。

曾工作于腾讯、阿里,参与过微信PaaS云平台从0到1建设,阿里ServerlessC++和GolangRuntime研发及落地。

目前工作于京东集团搜索与推荐部,负责京东搜推微服务治理和新一代Serverless云化平台研发工作。

目录

一、Mesh溯源及背景介绍二、落地挑战和方案选型三、业务赋能探索实践四、技术布局与未来展望

一、Mesh溯源及背景介绍

WilliamMorganBuoyantCEO

服务网格理念的提出者和先行者

以及最早的布道师

2016.09.29Buoyant

2016.01.15初次发布

2016.09.29概念诞生

Micro-Service=ServiceMesh一脉相承

专门的一层基础设施;负责可靠传输;轻量的网络代理;对应用程序透明

起源于Buoyant内部分享,从落地到概念

一般为Pod多容器,但是随着Node模式的演进,载体多样化起来,但整体形式一致

典型形式——Sidecar部署

服务网格和Sidecar的关系

绿方块为服务,蓝方块为边车部署的代理,多个Sidecar之间的连接和交互组成了Mesh

右转90°

栏目

栏目细分

方案1框架(bin)+

业务(so)

方案2框架(so)+业务(bin)

方案3

框架,业务一起编译

方案4框架(bin)+业务(bin)

方案5

框架(bin+支持插件)+业务(bin)

方案6

框架(bin)+业务(bin+多so)

方案7

框架bin+filterbin+业务bin

方案八

框架bin容器+多bin

目标

消除框架侵入

消除代码浸入

可观察性

可测试性

可扩展性

较高

很高

很高

很高

分离度

较高

很高

很高

很高

业务代码修改量

不需要

运维修改量

较高

较高

基础模块梳理量

框架开发量

较高

与框架发展契合度

潜在风险

So符号未定义和

符号冲突

符号冲突

-

-

-

So符号未定义

和符号冲突

-

-

从微信Svrkit框架与业务分离方案,回看Mesh的意义

基础框架作为承上启下的重要一环:对下充分利用底层系统能力,对上提供灵活可靠的底座

当年的基于EnvoyHTTP通道传输私有协议方案

如今的ServiceMesh百家争鸣,百花齐放

Mesh——协调微服务能力和分布式压力的一个支点

微服务分散能力

解决系统复杂度问题逻辑垂直拆分

……

分布式分散压力

解决系统性能问题物理横向拆分

……

日益复杂多样的需求高效迭代和极致性能大促突发大流量挑战跨部门跨语言联动共性问题难聚焦复用小语种服务治理弱

……

二、落地挑战和方案选型

数据量大

计算密集

实时性高

链路复杂

搜推广等计算密集型应用特点及落地挑战

VS

MOSN多协议框架快速落地,中长期使用MoE“双语”扩展

技术选型

Proxy性能损耗vsProxyless业务耦合——Proxy无损耗?!

MoE——MosnOnEnvoy

研发效能高

(Golang)

处理性能高

(C++)

多集群多主控制面架构

多形态数据面多数据面+多控制面架构

三、业务赋能探索实践

跨语言、多协议去中心化网关

TP99降低50%,抖动明显好转,可用率提高一个数量级

HTTP网关下沉到数据面=私有协议RPC调用

加权后不同规格机器可以相对均匀,TP99降5ms,但是个别算力或容器跟物理机差别大的,依然会不均匀

异构环境负载均衡——加权最小连接数

可根据业务需要设置CPU保护水位,打开远端负载感知 常规流量CPUTP7563%=60%,TP99降8ms

复合多策略负载均衡——加权本地耗时感知远端负载感知

EDF

应对突发大流量与业务内嵌限流的关键指标对比

CPU/QPS动态限流应对常规流量,可用率更高,TP99更低

cpu超过上限值,快速限流

文档评论(0)

优选文档 + 关注
实名认证
内容提供者

专注于发布优质文档,喜欢的可以关注一下哦~

1亿VIP精品文档

相关文档