Service Mesh结合容器云平台的思考和实践队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 Pilot-Agent核心流程解读Kubernetes平台下的微服务演进当我们在讨论微服务的时候我们在讨论什么? • 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 认证和授权 • 智能路由 • 流量管理 • 服务降级 • … • 微服务拆分原则 • 业务API设计 • 数据一致性保证 • 可扩展性考虑 • …Kubernetes对于微服务的支撑 功能列表 详情 快速资源分配 容器编排和调度 服务部署&弹性伸缩 Deployment 服务注册&服务发现 Service概念和分布式DNS API网关 简单路由功能 统一日志中心 Fluentd Fluentd & ES 统一监控中心 Prometheus 统一配置管理 Configmap、Secret 负载均衡 简单负载均衡,基于Iptables Roundrobin 流量控制 简单根据服务实例进行控制云平台微服务演进之基于API网关的微服务方案 API网关功能增强 • 安全认证 • 流量控制 • 审计日志 • 黑白名单 • …K8S集群 云平台微服务演进之基于Spring Cloud的微服务方案0 码力 | 28 页 | 3.09 MB | 6 月前3
金融级云原生 PaaS 探索与实践机房级和地域级容灾能力; 业务背景业务背景 CAFÉ API Server Aggregation Layer 异地多活架构 同城双活架构 K8S API Server 基础发布运维 跨集群应用 资源管理 IaaS层(Aliyun/OpenStack/VMWare/Bare Metal) PaaS 核心层 核 心 流 程 两地三中心架构 跨机房和地域统一应用运维 容器运行时 (Docker/Pouch/安全容器) (SLB/ALB) 容 器 层 跨集群管理 单元化能力 容器镜像管理 批次发布 原生资源管理 Pod伸缩管理 集群伸缩管理 变更管控 配额管理 运维原子操作 精细化调度 接入层流程调拨 应用层流量调拨 跨集群状态 分发/汇聚 数据层流量调拨 压测/灰度 流量管理 单元化 元数据管理 弹性流量管理 跨集群发布策略 多集群管理 跨集群网络 跨集群镜像管理 蓝绿发布 灰度分组发布 中间件变配 中间件变配 (DRM/Scheduler/Message) Mesh流调拨和治理 弹性建站/下站 容器腾挪/迁移 容灾切换和恢复 应急预案管理 … 分钟级容灾切换和恢复 全面变更风险管理 无限弹性可扩展 业务架构 产品层 云原生 PaaS 产品架构方案 7/209/20 二、多集群管控 多集群管控10/20 为什么要有集群联邦 • 异构屏蔽: 底层集群变化; • 统一管控:0 码力 | 20 页 | 1.71 MB | 6 月前3
严选 ServiceMesh 实践/014/24 严选第一代 Service Mesh 架构 • 使用 Consul 作为服务发现组件 • 数据面:cNginx • 控制面:Consul 管理后台5/24 服务治理能力 – 基于严选第一代ServiceMesh(cNginx) 类型 功能 能力提供方 服务调用方(Client) 服务提供方(Server) 服务注册与发现 注册发现:基于 Consul √ 调用控制 协议支持:HTTP 大大降低了中间件的研发投入和演进成本,也降低了业务和中间件的耦合成本 • 基础架构与业务架构可以独立演进 • 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 • 增强流量管理能力 • 将更多治理特性(如限流、熔断、故障注入)与业务架构解耦 • 支持更多的协议 • 增强控制面 • 配合业务容器化上云及混合云架构8/24 行业技术演进 - 通用型 Service Mesh 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面:Envoy • 控制面:Pilot,Mixer,Citadel,Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 类型 功能 能力提供方 服务调用方(Client) 服务提供方(Server) 服务注册与发现 注册发现:云外基于 Consul,云内基于 K8s 默认的 ETCD √0 码力 | 25 页 | 2.07 MB | 6 月前3
七牛容器云ServiceMesh实践七牛容器云Service Mesh实践 冯玮 七牛容器云架构师 2018.11.25 Service Mesh Meetup #4 上海站Ingress Controller • 流量管理 • 安全管理 • 统一配置 • 反向代理Contour • 本质上还是Ingress Controller • Kubernetes深度整合 • Gimbal生态组件Contour特点 • 基于Envoy 兼容Kubernetes标准Restful接口 • 统一的Kubernetes管理接口 • Gimbal生态 • 多集群入口流量整合管理 • 劣势 • 缺少大规模落地案例 • 功能/非功能仍需加强Contour & Istio • 南北向流量 • API版本共存(Istio & Kubernetes Ingress) • 东西向流量 • Istio支持全量功能 • Contour支持Tracing能力 • 数据面共存 数据面共存 • 共用边车组件Envoy七牛现有Service Mesh体系 • Istio产品化 • 东西流量产品化 • 南北流量产品化 • TLS管理优化 • Contour增强 • 入口流量管控 • 跨集群调度 • 发展策略 • API版本兼容两种方式 • 数据面优先,控制面按需迭代七牛容器云Service Mesh发展 • 产品发展 • 依托容器云PaaS中台 • 辐射业务线:Spock,Kodo,Dora等0 码力 | 15 页 | 3.86 MB | 6 月前3
Service Mesh 在蚂蚁金服生产级安全实践Service Sidecar 的证书管理方案 使用可信身份服务构建敏感数据下发通道 Service Mesh Sidecar 的 TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes Secret 证书管理流程 在 Kubernetes 场景下,证书是通过 secret 的方式来管理,使用时通过 secret 存在以下三个问题: Secret 管理方式与现有密钥管理系统有冲突,需要密钥管理系统强依赖 Kubernetes Secret 以明文形式挂载在容器的文件系统中,存在安全隐患 Secret 更新时,Sidecar 需要通过热重启方式重新加载,成本高昂基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程 Secret Discovery Discovery Service 是 Envoy 提出的 Sidecar 证书管理方案,方案的核心流程在于引入 SDS Server 进行密钥管理和分发,Sidecar 通过 gRPC 请求获取证书,并利用 gRPC stream 能力实现证书动态轮转。 当然,Sidecar 和 SDS Server 的通信也需要保证自身的通信安全,存在以下两种方案: Sidecar 与 SDS Server0 码力 | 19 页 | 808.60 KB | 6 月前3
SOFAMOSN持续演进路径及实践分享块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4.0 Ø TCP代理/7层通用代理 Ø 简单匹配路由 Ø 集群管理 & 基本负载均衡(RR、 RANDOM) Ø SofaRpc及HTTP/1.1、 HTTP/2.0支持 Ø 进程平滑升级 Ø SOFAMesh集成,支持 xDS on ADS Ø X-Protocol协议扩展机制, 支持subset复杂匹配路由 Ø 无损平滑迁移 Ø ProtocolEngine协议扩展 机制 Ø 支持Router模式 Ø GRPC支持 Ø 协议自动识别 Ø 链式路由扩展 Ø 完善流量管理策略,包括 Retry、DirectResponse、 HTTP Header add/delete、 流控、故障注入等 Ø 支持必要的admin接口性能 0.1.0 0.2.0 0.3.0 0 体和解析流程 Ø 框架适配 ü IO框架 ü 内存复用框架 ü workerpool协程池框架 Ø 功能支持 ü 请求流式处理模式 ü 热升级 ü metrics ü 修复HTTP/2 headers key不支持冒号开头字段的问题 ü 适配envoy的HTTP2配置项 Ø 代码管理 ü fork x/net/http2 代码 ü 新增mosn_http2.go文件,复用原生结构体和方法,暴露mosn框架0 码力 | 29 页 | 7.03 MB | 6 月前3
网易云Service Mesh的产品架构与实现com 一、微服务与Docker、Kubernetes163yun.com 应用架构 数据架构 IT架构 微服务的交付形式Kubernetes 轻量级的IT运维模式Swarm 资源利用率高的任务执行模式Mesos 快速迭代 高并发 OPEX CAPEX 大数据分析,运营 容器技术的三种视角微服务形态 Hailo Amazon Netflix 来源: https://www.linkedin 调用次数 调用时间 服务治理 日志分析 统计监控 Data Stream Kafka Storm集群 Hbase Hadoop Redis DDB NQS 监控平台 用户空间VPC 管理控制服务 云主机 云网络 云硬盘 UAS Agent 对象存储 UAS Server OpenStack 管控节点(主) 管控节点(备) 监控节点(主) 监控节点(备) 注册中心 控制中心163yun /agents/haproxy/haproxy.conf网易云容器服务逻辑架构 = Docker + Kubernetes + OpenStack + DevOps工具链网易云容器服务架构www.163yun.com 容器管理平台本身也是微服务 所有的多租户容器请求入口流量 对接多个业务:OpenStack, Kubernetes,所有PaaS,持 续集成,镜像仓库,计费,用 户,认证,…… 高可用,横向扩展 熔断,限流,降级0 码力 | 35 页 | 6.33 MB | 6 月前3
Service Mesh是下一代SDN吗:从通信角度看Service Mesh的发展Plane Programmable API APP ...... Data Plane Control Layer Application Layer通过Service Mesh控制面统一管理F5和Envoy https://aspenmesh.io/2019/03/expanding-service-mesh-without-envoy/ Control Plane Security 原生组件 APP: Traffic Management APP ...产品化增强-服务注册发现 出于历史原因,我们使用了Kubernetes来部署服务,但并未使用Kubernetes内置的 服务发现功能。 Process Service-A Service-B Service-C Coarse grained Service Application Process Process and Rate limiting Other business logic ... 提供七层网关能力, 但和服务网格是割裂 的 提供七层网关和网格 能力,但缺少API管 理能力 提供API管理能力, 缺少服务网格能力在DexMesh场景下Mesh和API Gateway的分工与协同 External request MSB API Gateway API Management Ingress0 码力 | 27 页 | 11.99 MB | 6 月前3
微博Service Mesh实践Register Subscribe NotifyService Mesh Meetup · BeiJing 服务治理理 �9 微博Service Mesh实践 - WeiboMesh 相同的治理理功能,不不同语⾔言的服务都要做⼀一遍?Service Mesh Meetup · BeiJing 跨语⾔言服务化的本质 �10 微博Service Mesh实践 - WeiboMesh • 协议中⽴立/跨语⾔言 微博Service Mesh实践 - WeiboMesh Http代理理 RPC模块 Agent代理理 研发成本 低 ⾼高 中 维护成本 低 ⾼高 中 使⽤用成本 低 低 中 治理理功能 中 ⾼高 ⾼高 扩展能⼒力力 低 中 ⾼高Service Mesh Meetup · BeiJing Service Mesh �12 微博Service Mesh实践 - WeiboMeshService 资源服务化 • 兜底逻辑 Mesh Light Client SM 功能 功能 强化 Go 并发 适配 不不同 语⾔言Service Mesh Meetup · BeiJing Weibo Mesh 数据⾯面 �17 微博Service Mesh实践 - WeiboMesh ➢ Cluster(发现集群管理理,group + path) ➢ HA(⾼高可⽤用策略略) ➢ LB(负载均衡)0 码力 | 43 页 | 1007.85 KB | 6 月前3
Service Mesh 在『路口』的产品思考与实践Mesh? Service 业务逻辑 SDK 协议编解码 服务发现 负载均衡 熔断限流 服务路由 …… 混合在一个进程内, 应用既有业务逻辑, 也有各种功能, 每次升级都要重新发布应用 升级成本高 版本碎片化严重 中间件演进困难6/39 微服务治理与业务逻辑解耦 Part 1: 为什么需要Service Mesh? Service 专注业务实现 - 无需感知Mesh - 专注服务间通讯和相 关能力 - 与业务逻辑无关 将SDK客户端 的功能剥离 混合在一个进程内, 应用既有业务逻辑, 也有各种功能, 每次升级都要重新发布应用 业务进程专注于业务逻辑 SDK 中的大部分功能, 拆解为独立进程, 以 Sidecar 的模式运行 将服务治理能力下沉到基础设施,实现独立演进,透明升级7/39 webhook/operator 机制可以方便地实现注入、升级 等运维操作 • 然而大量系统还没有跑在 k8s 上,所以我们通过 agent 的模式来管理 sidecar 进程,从而可 以使 Service Mesh 能够帮助老架构下的应用完成服务化改造,并支持新架构和老架构下服务 的统一管理。 VM 应用进程 Sidecar Agent SOFAMosn 注入 升级 SOFAMosn:https://github0 码力 | 40 页 | 15.86 MB | 6 月前3
共 29 条
- 1
- 2
- 3













