Service Mesh的延伸 — 论道Database MeshMesh产品多样化Service Mesh的优势 云原生 零入侵 可观察性 面向运维服务化之后,数据库怎么办? 服务 • 无状态 • 根据规则路由 • 业务方处理事务 数据库 • 有状态 • 根据SQL路由 • 数据库自动处理事务数据库的进化趋势 • SQL • ACID • 分布式 RDBMS • SQL • BASE ACID • 分布式 NoSQL • SQL • Transparent Sharding Middleware Database-as-a-Service What's Really New with NewSQL?数据库中间层的优势 系统 •事务 运维 • DBA 开发 • SQL数据库中间层应具备的能力 分片化 多副本 数据一致性 弹性化 治理能力 观察能力数据分片 App2 DB App1 App3 App2 DB1 sync read分布式事务:定义 传统事务:ACID Atomicity - 原子性 Consistency - 一致性 Isolation - 隔离性 Durability - 持久性 柔性事务:BASE Basically Available - 基本可用 Soft state -软状态 Eventual consistency - 最终一致性分布式事务:分类 XA 最大努力送达0 码力 | 35 页 | 4.56 MB | 6 月前3
Service Mesh是下一代SDN吗:从通信角度看Service Mesh的发展Service的缺省处理会影响应用层逻 辑 -例子:Envoy的LB算法不能处理应用后端集群的Sharding Ø Istio中和HTTP Service 端口冲突会的TCP Service请求会被Envoy直接丢弃 - 要求对应用进行改造,避免端口冲突 建议 Ø 将TCP纳入Service Mesh管控还不成熟,成本远大于收益 Ø Service Mesh应主要关注L7,而不是L4 Shard 3改进:提供了HTTP Inspector,并且可以支持按照协议对filterchain进行 Match 可在一个TCP请求没有对应的TCP服务,并且端口和HTTP服务没有冲突的情况下, TCP请求会被缺省发送到原始目的地。 遗留问题: 端口冲突的情况下,TCP请求将会被丢弃,导致客户端请求失败。 长期演进方案:通过自定义Envoy Filter扩展Service Mesh对应用层协议的处理能力产品化增强:异步通信的流量管理0 码力 | 27 页 | 11.99 MB | 6 月前3
陌陌Service Mesh架构实践Architecture)于2013年初上线推广 微服务体系的其他产品也均为自研方案6/24 MOA 1.0微服务体系整体架构 注册中心 • Redis作为底层存储 • 跨语言地址发现服务Lookup • 中心化存活检测 多语言支持 • Java、PHP、Python、Go、NodeJs • Redis传输协议 / 复用Redis客户端 • 服务发布Proxy / 并行调用Proxy 服务治理 • 服务治理平台、配置中心 当前方案 运维Agent • 单个Pod升级Agent • 多个Pod发布编排 Agent发布流程19/24 数据平面容灾方式 服务类应用 • 场景:出流量由入流量产生 • 方案:由原有健康检测机制摘除流量 借助原有服务治理能力 特殊应用 • 场景:流式计算、定时任务 • 方案:出流量降级至本应用的其他Agent 出流量容灾20/24 数据平面性能优化 方案整体 • 新增MOA0 码力 | 25 页 | 1.25 MB | 6 月前3
Service Mesh Meetup #3 深圳站的开发; • 3. 开发完成后,提交 merge request(MR)请求合并到 develop 分支; • 4. MR 触发 Jenkins,Jenkins/Drone 触发 Sonar 代码质量检测系统; • 5. Sonar 将 report 和 issue 以 comments 的方式写到 Gitlab MR 中; • 6. Developer 对 MR 进行反复修复直至通过 Sonar 的分析; Drone(plugins/drone-downstream) • 支持自定义插件(你可以自己实现自己所需的插件) • 本机测试 .drone.yml : drone execAPI 支持我是作者名称.drone.yml代码质量检测 SonarQube 参考资料:https://github.com/developer-learning/night-reading- go/blob/master/articles/sonar0 码力 | 45 页 | 18.62 MB | 6 月前3
蚂蚁金服 API Gateway Mesh 思考与实践特点: • 干掉形式上的网关 • 轻路由前置到 LB • 业务集成网关 Jar • 业务之间互不干扰 • NodeJS 版 缺点: • 接入困难(几十个 jar 依赖) • Jar 包冲突 • 升级困难 • 版本离散 • NodeJS 版本维护成本高 30+系统、70-80%流量11/21 Mesh 化网关架构(2018-2019) APP Mesh 化网关架构 LB0 码力 | 22 页 | 1.72 MB | 6 月前3
Service Mesh 在蚂蚁金服生产级安全实践Kubernetes 场景下,证书是通过 secret 的方式来管理,使用时通过 secret mount 以 Volume 形式挂载。 存在以下三个问题: Secret 管理方式与现有密钥管理系统有冲突,需要密钥管理系统强依赖 Kubernetes Secret 以明文形式挂载在容器的文件系统中,存在安全隐患 Secret 更新时,Sidecar 需要通过热重启方式重新加载,成本高昂基于0 码力 | 19 页 | 808.60 KB | 6 月前3
SOFAMOSN持续演进路径及实践分享goroutine pool conn.read conn 1. 链接建立后,向epoll注册oneshot 可读事件监听;并且此时不允许有协 程调用conn.read,避免与runtime netpoll冲突。 2. 可读事件达到,从gorotine pool挑 选一个协程进行读事件处理;由于使 用的是oneshot模式,该fd后续可读 事件不会再触发。 …… 4. 请求处理完成,将协程归还给协程池;同时将fd重新0 码力 | 29 页 | 7.03 MB | 6 月前3
Service Mesh的实践分享编码难度 容易。IDL接口规范 容易。IDL接口规范 难。需要自行处理HTTP请求和 响应(目前还没有生成HTTP sdk) 应用侵入性 侵入性大。复杂客户端会给 应用造成负担,包括资源占 用、依赖冲突等等 侵入性小。SDK只有简单的寻址和序列化/ 反序列化的功能 无侵入性。应用自行调用 运维难度 难度大。客户端的问题会对 应用直接产生影响,耦合太 重 难度小。Sidecar故障可以将流量临时切到0 码力 | 30 页 | 4.80 MB | 6 月前3
阿里巴巴超大规模神龙裸金属 Kubernetes 集群运维实践秒级、分钟级监控 • 内核性能指标采集 • 监控大盘 • 在线率 • 宕机率 • 抖动率 • 基线系统 • 基础环境一致性故障自愈 (1-5-10) • 监控、故障发现 (1-5) • 本地检测 (walle, NPD) + 外部系统 (IDC、aliyun) • SLI、SLO、SLA • 钉钉、邮件、电话报警、ChatOps 自助诊断 • 节点故障自愈 (10) • 决策中心执行修复操作0 码力 | 21 页 | 7.81 MB | 6 月前3
蚂蚁金服双十一 Service Mesh 超大规模落地揭秘SOFABoot 研发框架App 容器 15 方案落地-框架升级后 应用代码 SOFABoot_Old SOFABoot/SOFARPC API SOFABoot_New JVM RPC 检测 pod 变量,注 入启动参数 判断开启了 MOSN 发布和订阅服务 直接调用,关闭寻 址功能 其他16 方案落地-容器替换 Pod Pod Old Pod New With MOSN0 码力 | 26 页 | 2.71 MB | 6 月前3
共 10 条
- 1













