用户您好!请先登录!

微服务框架设计实践

微服务框架设计实践

复杂业务开发过程中的痛点

  1. 时间紧、任务多、团队大、业务增⻓快,如何还能保证架构稳定可靠?
  2. 研发水平参差不其、项木压力自顾不暇,如何保证质量基线不被突破?
  3. 公司有各种⼯具平台、 SDK、最佳实践,如何尽可能的在业务中使用?
  4. 用什么“框架”可以解决问题?

从服务框架的演进历程中找到规律

标志性的服务框架

  • 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
  • 工具链:模板、代码⽣成器、依赖管理、版本管理、发布脚本

站在巨人肩膀上:复用造好的轮子

实现要点:

  • 框架与业务正交(业务开发⽆需关注框架本身,框架本身的升级可以做到完全透明,方便所有服务统一框架版本)
  • 隔离层屏蔽业务与底层的联系
  • 协议劫持(将业务数据和服务框架数据充分隔离,避免互相⼲扰)
  • 跨服务边界的 context (在可透明的在服务间传递上下文信息)
  • 防雪崩
  • 跨服务边界的超时时间控制
  • 其它……
行走的code
行走的code

要发表评论,您必须先登录