大纲
• 发现问题：服务开发过程中的痛点
• 以史鉴今：从服务框架的演进历程中找到规律
• 大道至简：大型微服务框架的设计要点
• 精雕细琢：框架关键实现细节
复杂业务开发过程中的痛点
痛点
• 时间紧、任务多、团队大、业务增快，如何还能保证架构稳定可靠？
• 研发水平参差不其、项木压力自顾不暇，如何保证质量基线不被突破？
• 公司有各种⼯具平台、 SDK、优秀实践，如何尽可能的在业务中使用？
•用什么“框架”可以解决问题？
从服务框架的演进历程中找到规律
让我们先来看下服务框架的进化史
标志性的服务框架
Web 服务框架： MVC 架构
• ASP.Net（since 2002）：传统 C/S 开发模式在 Web 上的应⽤
• Ruby on Rails（since 2005）： MVC 框架的巅峰， “约定⼤于配置”
• Web 服务框架： SaaS 与 RESTful
• Sinatra（since 2007）：纯路由框架，诸多框架的灵感源泉
• 微服务框架： RPC 服务
• Thrift（since 2007）：开源 IDL-based 框架的⿐祖
• 微服务架构：容器化与 FaaS
• Serverless（since 2015）：基于云计算平台，回归框架本质
• Istio（since 2018）：专注于解决网络问题
服务框架的演进趋势
服务框架正在演变成新的“操作系统”
• 学习曲线： Exponential Rise（渐进式） → Sigmoid（阶跃式）
• 风格：配置 → 约定 → DSL → 容器化
• 业务代码与框架代码的关系： Is-a → Has-a → Duck-typing
• 工具链： IDE → 代码⽣成器 → 编译器
大型微服务框架的设计要点
站在全局视⻆观察微服务架构
大型微服务框架的设计目标
框架即一款面向开发人员的效率产品，基于公司的基础设施量身定制
• 目标用户：来不不同背景、具有基本业务研发能⼒的开发者
• 设计要点：让开发人员专注于业务开发本身，无需关注滴滴各种基础设施底层细节
• 设计原则：直观、简洁、智能、个性化
• 预期收益：提升⼈效，降低维护成本；提升整体架构稳定性和可伸缩性；简化技术升级难度
大型微服务框架的设计要点
完全屏蔽业务无关的通用技术细节
• 功能：服务治理、虚拟化、水平扩容、问题定位、性能压测、系统监控、兼容遗留系统……
• 工具链：项目模板、代码生成器、文档生成器、发布打包脚本……
• 设计⻛格： Interceptors、组合模式、依赖注入……
• 让不可靠的调⽤变得可靠
• RPC 调用 ≈ 函数调用
• 访问基础服务 ≈ 访问本地存储
• 服务拆分/合并 ≈ 类拆分/合并
框架关键实现细节
业务实践
业务背景：复杂的业务流程，快速增涨与迭代，异构服务架构，跨国多机房部署
• 核心能力
• 隔离层封装：各种存储、队列、平台服务封装
• 透明支持各种运维基础设施：构建、发布、多机房配置、 metrics
• 提供效率和测试⼯具：⽇志采集、问题⾃动跟踪、全链路压测、 mock、接⼝测试
• 应⽤层协议隔离：⽀持 thrift/http 协议 interceptor
• 工具链：模板、代码⽣成器、依赖管理、版本管理、发布脚本
站在巨人肩膀上：滴滴基础平台建设现状
• Odin：运维平台，提供 metrics 上报、多维度监控、报警、服务树等功能
• 把脉：日志平台，提供日志采集通道、基于 traceid 的全链路⽇志查询能⼒
• DiSF：服务注册平台，提供高可用的服务名字服务、管理服务分组
• RDS：提供高可用、透明水平扩展的 MySQL 集群，支持数据总线、分身等能力
• DDMQ：低延迟高可用的消息队列服务，单机 TPS 吞吐超过百万，支持延时消息
• Fusion：基于 rocksdb 的高性能高可用分布式持久化存储方案，完全兼容 Redis 协议
• 弹性云：基于 k8s，高效、可伸缩的集群管理平台，服务自动容错，基础设施免运维
