大纲?发现问题：服务开发过程中的痛点?前车之鉴：从服务框架的演进中寻找规律?从大道至简：大型微服务框架的设计要点?精雕细琢：业务发展过程中框架关键实现细节复杂PainPointsPainPoints?时间紧、任务多、团队大、业务增长，如何保证架构稳定可靠？?研发水平参差不齐，项目压力大。如何保证质量底线不被打破？?公司拥有各种工具平台、SDK和良好实践。如何在业务中尽可能多地使用它们？?什么“框架”可以用来解决问题？从服务框架的演进中寻找规律。我们先来看看服务框架的演进史。标志性的服务框架Web服务框架：MVC架构?ASP.Net（2002年以来）：Web应用上传统的C/S开发模式?RubyonRails（2005年以来）：MVC框架的巅峰之作，“约定优于配置”"?Web服务框架：SaaS和RESTful?Sinatra（自2007年起）：纯路由框架，许多框架的灵感来源?微服务框架：RPC服务?Thrift（自2007年起）：基于IDL的开源框架的始祖?微服务架构：容器化和FaaS?Serverless（2015年起）：基于云计算平台，回归框架本质?Istio（2018年起）：关注服务框架向新“操作系统”演进?学习曲线：ExponentialRise(progressive)→Sigmoid(step)?Style:Configuration→Convention→DSL→Containerization?业务代码与框架代码的关系：Is-a→Has-a→Duck-typingToolchain：IDE→CodeGenerator→Co编译器微服务框架的设计目标框架是面向开发者的效率产品，基于公司基础设施量身定制?目标用户：不同背景的具有基础业务研发能力的开发者?设计要点：让开发人员专注于业务发展本身，而没有关注滴滴各种基础设施的底层细节。设计原则：直观、简洁、智能、个性化。预期收益：提高人的工作效率，降低维护成本；提高整体架构的稳定性和可扩展性；简化技术升级难度大规模微服务框架的设计要点，完全屏蔽与业务无关的通用技术细节功能：服务治理、虚拟化、水平扩展、问题定位、性能压力测试、系统监控、兼容遗留系统...工具链：项目模板、代码生成器、文档生成器、发布打包脚本...?设计风格：拦截器、复合模式、依赖注入...?让不可靠的调用变得可靠?RPC调用≈函数调用?访问基础服务≈接入本地存储?服务拆分/合并≈类拆分/合并框架关键实现细节业务实践业务背景：业务流程复杂，快速增长迭代，异构服务架构，跨国多机房部署?核心能力?隔离层封装：各种存储、队列和平台服务封装透明支持各种运维基础设施：构建、发布、多机房配置、指标提供效率和测试工具：日志收集、自动问题跟踪、全链路压测、mock、接口测试?应用层协议隔离：支持thrift/http协议拦截器?工具链：模板、代码生成器、依赖管理、版本管理、发布脚本站在巨人的肩膀上：滴滴基础平台建设现状?Odin：运维平台，提供metrics报表，多-维度监控、告警、服务树等功能?Pulse：日志平台，提供日志采集通道和基于traceid的全链路日志查询能力?DiSF：服务注册平台，提供高可用的服务名称服务和管理服务分组?RDS：提供高可用、透明水平扩展的MySQL集群，支持数据总线、分身等?DDMQ：低延迟、高可用的消息队列服务，单机TPS吞吐量超过百万，支持延迟消息?Fusion：基于Rocksdb的高性能高可用分布式持久化存储解决方案，完全兼容Redis协议?弹性云：基于k8s，高效可扩展的集群管理平台，自动容错服务，无基础架构运行和维护整体架构实现要点：框架和业务正交实现思路?MVC、中间件、AOP、传统框架的执行过程不存在，也不需要?框架是一个执行环境，由一堆不相关的基础库，可扩展性强，业务可以独立于框架运行k如何实现?提供生成初始项目模板的工具链，通过代码生成器实现类AOP效果?基于Go接口的duck-typing特性和运行时反射，动态生成业务路由好处?业务开发不需要需要关注的框架本身?框架本身的升级可以完全透明，方便所有业务。...)定义接口，业务只允许调用接口的方法基于SPI设计思想，提供基础服务的工厂，并动态实例化相应的接口收入?透明升级服务驱动，以及快速实现大量服务中的通用逻辑或修复常见问题?透明管理服务基础资源（长连接、mysql游标等），避免资源泄露?重试、超时、服务发现、故障排除逻辑统一控制，业务无关，不易出错，提高整体稳定性?提供所有基础服务的mock能力，可实现AOP能力案例：Redis接口设计与实现要点：如何实现协议劫持?HTTP协议：包装http.Handler，handlehttp.Requestandhttp.ResponseWriterwithresponsibilitychainmodeRPCprotocol:劫持协议序列化过程，使用FSM（有限状态机）跟踪序列化过程，及时修改数据收入?业务数据和服务框架数据完全隔离，避免相互干扰?实现接口热补丁和in/out数据记录和回放，方便测试?可用透明增强服务能力，为实现跨服务边界上下文打下坚实基础利用FSM劫持thrift协议FSM实现思路?利用Go接口特??性实现一个接口proxy，代理并劫持一些感兴趣的接口?维护一个FSM状态机作为协议当read/write到感兴趣的地方时，篡改read/write数据超时控制?结合协议劫持，透明提取必要信息从服务框架数据中反序列化，将所有RPC调用前的最新上下文透明序列化，放入服务框架数据中传输给下游?需要重新实现一个基于时间片的Rotating低精度时间定时器。提高并发效率，避免定时器泄漏好处?可以在服务之间透明传递上下文信息，从而实现流量着色、调用跟踪、雪崩预防等功能实现?通过上下文跨服务边界传递上游超时期望，并持续记录每个环节的时间消耗?一旦框架发现其可用时间已经耗尽，它会主动终止后续的rpc调用并快速返回，以防止请求积压。为了避免请求堆积造成的雪崩，跨服务边界的超时时间控制了超时信息如何跨服务边界传输。超时时间由最上游设置。框架捕获超时信息并将时间记录在跟踪中以透明地传播到每个下游服务节点。?每个节点收到请求后统计时间，自动计算消耗的时间并计算当前调用链路的总时间?当总链路时间超过超时时间时，会自动fail-fast，快速返回失败信息?使用Gocontextdeadline只会缩短不会进阶的特性，使用context管理超时比较方便&b空;避免服务器之间的时钟差异影响计时，始终使用时间差异来记录数字，而不是使用绝对期限业务收入支持规模?涉及近100名开发人员，70+服务在线，国内外双机房部署?可支持百万-级日订单规模，万级并发长连接业务收益零成本：透明接入公司运维、发布、日志、压测等平台，支持服务注册发现、弹性伸缩等能力零事故：从未发生过单点故障导致的全局稳定性事故?高质量：快速实现全链路压测常态化，透明实现多环境部署、单体测试、集成测试?易维护：透明升级各种驱动，简化流程代码依赖管理Process未来计划改进de开发者体验?命令行工具集成各种工具?与滴滴线上线下环境进一步集成?集成更多公司服务和框架?集中配置管理?开源？
