微服务结合容器云平台的思考和实践 2018.06.25 徐运元关于我 2008年毕业于浙江大学，曾在思科和浙大网新有超过 9年的工作经验和5年的云计算领域工作经验，带领团 队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 Pilot核心功能解读 Pilot-Agent核心流程解读Kubernetes平台下的微服务演进当我们在讨论微服务的时候我们在讨论什么？ • 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 • 基本的监控 • 快速部署 • 易于分配的存储 • 易于访问的外围（负载均衡） • 服务注册和发现 致富问题 • 认证和授权 • 智能路由 • 流量管理 • 服务降级 …Kubernetes对于微服务的支撑 功能列表 详情 快速资源分配 容器编排和调度 服务部署&弹性伸缩 Deployment 服务注册&服务发现 Service概念和分布式DNS API网关 简单路由功能 统一日志中心 Fluentd & ES 统一监控中心 Prometheus 统一配置管理 Configmap、Secret 负载均衡 简单负载均衡，基于Iptables Roundrobin

• 技术架构的演进 • 如何提升工程效率？DevOps • CI/CD 实战 • ServiceMesh • 踩过的一些坑 • Q&A技术架构的演进 • 单体架构 • 一个框架 • 一个数据库 • 分模块整合架构（前后端分析） • 不同的框架或业务模块 • 多种数据源 • 微服务架构 • 各种语言、各种框架或子系统 • 各种数据源 • ServiceMesh一般的开发流程 • 1 1. 开启一个新的 feature； • 2. Developer 从 develop 分支新建一个 feature/new_branch 来做特定 feature 的开发； • 3. 开发并自测后，提交 merge request（MR）请求合并到 develop 分 支；（执行单元测试，测试状态呈现 MR 中） • 4. Reviewer 对 MR 进行 code review ，批准合并之后， 沟通成本高 • 开发需要通知负责人、测试、产品等；（而且是每次构建/部署 都需要） • 依赖多较好的开发流程（流程化、自动化） • 1. 开启一个新的 feature； • 2. Devloper 从 develop 分支新建一个 feature/new_branch 来做特定 feature 的开发； • 3. 开发完成后，提交 merge request（MR）请求合并到 develop 分支；

SOFA MESH 的通用协议扩展 Service Mesh Meetup #3 深圳站 邵俊雄（熊啸） 2018.08.25AGENDA • SOFA MESH 介绍 • SERVICE MESH 落地的问题 • SOFA MESH 的通用落地方案 • DNS 服务寻址方案 • X-PROTOCOL 通用协议 • 问答SOFA MESH • 从 ISTIO 克隆并保持同步更新 • 使用 • 支持主流的微服务框架 • SOFA • HSF • DUBBO • SPRING CLOUD • … • 控制平面创新的地方 • MESH OPERATOR • RPC SERVICE CONTROLLER • …SERVICE MESH 落地中的问题常见的 MESH 落地方案 在非 KUBERNETES 环境部署 ISTIO 把 KUBERNETES 当作一个更好用的虚拟化方案 KUBERNETES 自己做控制平面KUBERNETES NATIVE 微服务 • 使用 Kubernetes 作为注册中心 • Service • Endpoint • Pod • 使用 DNS 寻址 • 使用 iptables/ebpf 透明地路由所有网络流量 • 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • …MESH

唯品会Service Mesh的实践分享 郑德惠 2019.1.6 Service Mesh Meetup #5 广州站• 唯品会内部Service Mesh的演进 • 与Istio的区别 • 实践中踩过的坑 • 今年规划（Roadmap）内部Service Mesh的演进 我是作者名称服务化体系1.0 • OSP（Open Service Platform） • Thrift over over Netty • 基于Java语法的DSL • Zookeeper • 胖客户端 • 基本服务治理功能 App OSP Server Service Registry Service Config Center 服务发现 服务注册 服务元数据下发 OSP client 服务路由 网络传输 服务元数据上报缺点 • 语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2 备用链路 服务发现 服务注册 配置下发 服务路由 网络传输 OSP client多语言客户端接入 • HTTP & TCP • Local & Remote • 根据接入对象的不同，制定 不同的接入策略，达到 • 接入简单 • 保证性能 • 节省资源 Java App Local Proxy OSP Server Remote Proxy Cluster Thrift over

深入 Kubernetes 的“无人区” —— 蚂蚁金服双十一的调度系统 曹寅2/19 一、蚂蚁金服的Kubernetes现状 二、双十一Kubernetes实践 三、展望未来迎接挑战 目 录 contents 目录3/19 一、蚂蚁金服的Kubernetes现状 Part 1：4/19 发展历程与落地规模 Part 1：蚂蚁金服的Kubernetes现状 平台研发 灰度验证 全站 Kubernetes 落地，超过 90% 的资源通过 Kubernetes 分配，核心链路100%落地支撑 大促。5/19 大促规模 Part 1：蚂蚁金服的Kubernetes现状 数万台 服务器和ECS 超一万 单集群规模 90%+ 应用服务 数十万 应用 Pods业务 6/19 统一资源调度架构 Part 1：蚂蚁金服的Kubernetes现状 非云 资源 云化 快速腾挪的问题 1.实例上下线需要预热 2. 腾挪耗时不可控 3. 大规模腾挪的稳定性技术风险 9/19 资源分时链路切换 Part 2：资源分时调度 Kubernetes Node 分时调度 Agent Pod 资源 Node 分时调度 Agent Pod 资源 Node 分时调度 Agent Pod 资源 容量平台 监控平台 巡检平台 流量控制 流量平台

Service Mesh的延伸 之论道Database Mesh 分享人：张亮 日期：2018年07月25日Service Mesh风头正劲Service Mesh产品多样化Service Mesh的优势 云原生 零入侵 可观察性 面向运维服务化之后，数据库怎么办？ 服务 • 无状态 • 根据规则路由 • 业务方处理事务 数据库 • 有状态 • 根据SQL路由 • 数据库自动处理事务数据库的进化趋势 数据库自动处理事务数据库的进化趋势 • SQL • ACID • 分布式 RDBMS • SQL • BASE ACID • 分布式 NoSQL • SQL • ACID+BASE • 分布式 NewSQLNewSQL的分类 New Architecture Transparent Sharding Middleware Database-as-a-Service What's What's Really New with NewSQL?数据库中间层的优势 系统 •事务 运维 • DBA 开发 • SQL数据库中间层应具备的能力 分片化 多副本 数据一致性 弹性化 治理能力 观察能力数据分片 App2 DB App1 App3 App2 DB1 DB2 DB3 App1 App3数据分片：引入中间件 App1 M1 App2 App3 S2

数据面：cNginx • 控制面：Consul 管理后台5/24 服务治理能力 – 基于严选第一代ServiceMesh（cNginx） 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：基于 Consul √ 调用控制 协议支持：HTTP 1.X/2.X，可扩展至 TCP √ 路由控制：提供简单的路由能力 √ 负载均衡：支持 Hash 等 √ 流量复制：不提供 × 故障转移：继承 Nginx 的 Failover 机制 √ 安全 访问控制：主要依靠中间件 × 中间件 治理控制 熔断降级：主要依靠中间件 中间件 限流：速率限制 √ 中间件 资源隔离：主要依靠中间件 中间件 故障注入：不提供 × 超时控制、重试、重写、重定向等：继承 Nginx 的 timeout 机制 √ 监控/故障诊断 链路追踪：主要依靠中间件 APM APM 访问日志：主要依靠日志平台 日志平台 日志平台6/24 Service Mesh 为严选带来了哪些架构收益 • 历史包袱：现有的服务在不改造的情况下引入了服务治理能力 • 大大降低了中间件的研发投入和演进成本，也降低了业务和中间件的耦合成本 • 基础架构与业务架构可以独立演进 • 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 •

Service Mesh Meetup #6 广州站基于 Secret Discovery Service Sidecar 的证书管理方案 使用可信身份服务构建敏感数据下发通道 Service Mesh Sidecar 的 TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes Secret 证书管理流程 场景下，证书是通过 secret 的方式来管理，使用时通过 secret mount 以 Volume 形式挂载。 存在以下三个问题：  Secret 管理方式与现有密钥管理系统有冲突，需要密钥管理系统强依赖 Kubernetes  Secret 以明文形式挂载在容器的文件系统中，存在安全隐患  Secret 更新时，Sidecar 需要通过热重启方式重新加载，成本高昂基于 Secret Discovery Sidecar 的证书管理方案 Envoy SDS 证书管理流程 Secret Discovery Service 是 Envoy 提出的 Sidecar 证书管理方案，方案的核心流程在于引入 SDS Server 进行密钥管理和分发，Sidecar 通过 gRPC 请求获取证书，并利用 gRPC stream 能力实现证书动态轮转。 当然，Sidecar 和 SDS Server 的通信也需要保证自身的通信安全，存在以下两种方案：

Service Mesh是下一代SDN吗？ 从通信的角度看Service Mesh的发展 赵化冰 中兴通讯 软件专家/Istio Committer 2019.10.26 Service Mesh Meetup #7 成都站什么是Service Mesh？- by Willian Morgan(Buoyant) A service mesh is a dedicated infrastructure 服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着 复杂的服务拓 扑，服务网格负责在这些拓扑中实现请求的可靠传递。 在实践中，服务网格通常实 现为一组轻量级网络代理，它们与应用程 序一起部署，但对应用程序透明。什么是Service Mesh？- by Istio 服务发现 负载均衡 流量控制 ... 黑白名单 限流 ... 身份认证 通信加密 权限控制 ... 调用追踪 指标收集 ...什么是Service Mesh？- 从网络的视角 Service Mesh关注点 网络视角： Service Mesh是一个主要针对七层的网络解决方案，解决的是服务间的连通问题Service Mesh是下一代的SDN吗？ 通信网络 l 互不兼容的专有设备 l 基于IP的通信缺乏质量保证 l 低效的业务部署和配置 ... 微服务系统 l 互不兼容的代码库 l 不可靠的远程方法调用 l 低效的服务运维 ...

实现平滑迁移的关键 3 DNS寻址方案的演进 4 5 总结 DNS寻址方案的后续规划ü 对未来长期目标的认可 • Service Mesh（带控制平面，如Istio） • Kubernetes • 微服务 ü 现实中有很多挑战 • 还有很多应用没有实现微服务化 • 还有很多应用没有运行在kubernetes之上 • Istio目前还不够稳定，也无法原生支持我们的规模 • 现 现有系统中的众多应用不可能一夜之间全部迁移 ü 最重要的：平滑迁移 • 微服务 + Service Mesh + Kubernetes 是目标 • 但是如何从现有体系向目标迈进，必须给出可行的实践指导 ü Roadmap • 预计2019年初 蚂蚁金服主站落地：目标与现状 百川归海蚂蚁金服主站落地方案的实施原则 Target 长期 目标 Step By Step 分步 进行 Resiliency 符合远期规划 • 不走弯路，不浪费投资 • 每一步都为下一步奠定基础 • 谢绝中途推倒重来 循序渐进 • 不要有一步登天的幻想，小步快跑 • 每一步的工作量和复杂度都控制在可 接受范围内 • 每一步都简单方便，切实可行 可操纵性 • 操作层面上要有足够的弹性 • 每个步骤都是可分批进行 • 步步为营，扩大战果 • 杜绝一刀切k8s和Service Mesh落地方案演进路线 部署在