短视频go研发框架实践
全文7330字，预计阅读时间 12分钟。
一、产生背景
hulk框架是在“好看视频”服务端的go服务化架构升级背景下产生的。
1.1 为什么要做架构升级？当前架构面临哪些问题？
好看视频初期因业务需要快速、灵活的开发迭代，采⽤PHP作为开发语⾔实现后端服务，前期取得了⽐较好的开发迭代效果。但随着好看业务快速发展，服务端的项⽬(接⼝、代码等)急速膨胀，类单体的PHP架构在多个⽅⾯遇到了瓶颈和问题，主要体现在以下⼏个⽅⾯：
1.开发效率：对于主代码库，所有服务端同学都会在这同一个代码空间开发，此外还有依赖的第三方团队也会修改，频繁的修改/合并降低了开发效率，同时也加大了代码的维护成本和难度；
2.上线效率：多用户开发同一代码库的另一个弊端就是上线等待，由于同一个时刻只能有一个分支上线（分级上线），导致相连的上线需求要排队等待。这也导致我们的同学摸索出“搭车上线”的模式，虽然加快了上线效率，但也加大了上线的风险，没有从根本上解决问题；
3.运行效率：PHP在开发效率和灵活度方面确实有一定优势，但当所支撑的业务达到几千万DAU及以上时，我们必须要考虑服务的运行效率和资源成本等问题。PHP语言在多线程/多协程的支持上，弱于Java、C/C++、Go等语言，基于物理机部署的类单体服务部署架构，在资源利用率和服务扩缩容等方面也很难满足需求；
4.SRE效率：在出现稳定性问题时，我们期望能够做到快速感知、快速定位、快速止损。目前基于sia的监控/报警，基于日志的问题定位方式距离理想目标还有一定的距离：一是同学要奔波于各个平台/系统获取问题线索，二是获取到的线索及信息维度很多时候也无法满足快速、精确定位问题的需求；
这些问题需要通过“4化”，从总体业务架构、部署架构、基础设施等多方面去解决：
1.2 为什么不直接基于GDP2 ？
好看的go服务化升级工作开展时，GDP2还未正式发布，这也是其中一个因素。
1.3 hulk与gdp2能⼒对照
下⾯从三个⽅⾯与gdp2做⼀个简单的对照，初步了解hulk的整体能⼒及与gdp2的⼀些差异。
1.3.1 web server能⼒
hulk⽬前主要服务于web应⽤，⾸先了解⼀下hulk的web server能⼒。
1.3.2 功能/组件
功能/组件的丰富度及⾃身能⼒，很⼤程度上影响了框架对业务服务的⽀持能⼒。备注：ral资源访问层
1.3.3 框架周边及基础设施
框架从来不是“单打独⽃的”，它需要有周边⼯具和基础设施来⽀持。NOTE：
1. 好看在做go化时，也调研了开源社区⾥⽐较优秀的⼀些⼯具系统和⽅案并引⼊， hulk中默认添加了对这些基础设施的集成；
1.3.4 对照总结
本节主要站在hulk能力角度与GDP2做了一些方面的参考对照。以上对照，可以概括为4点：
1.很多基础能⼒，hulk是复⽤gdp的，如：bns、net、codec等；
2.⼀些通⽤/扩展组件，hulk按照业务需求场景，进⾏⼆次封装和增强，如：httpserver、ral、redis、mysql等；
3.对于gdp⽬前没有⽀持的⼀些业务需求，进⾏开发集成，如：定时任务、配置中⼼、服务治理等；
4.参考业界开源实践，引入了一些新的基础设施：如prometheus+grafana集群、sentry集群、故障定位系统等；
GDP2由几十个模块共同构成，由于时间有限，可能个别功能点的对照有偏差。
二、了解hulk
2.1 设计思路
2.2 框架结构
从功能上来看，hulk的整体能力可以划分为四层：
2.2.1 基础组件
提供了绝大部分项目都应该需要的基础能力，也是其他上层功能组件很可能依赖的组件。hulk框架通过这些基础组件，使上层应用可以无感的与基础设施进行集成：-
日志组件：默认支持与PHP兼容的打印格式（用于配置sia监控和报警），同时也兼容ftrace接入的格式（日志查询和问题定位）；
-
云原生监控：默认支持prometheus，对所有接口请求、redis、ral等远程调用进行多维度的metrics采集，并通过grafana展示；
-
配置中心：通过配置中心，可以实时下发并生效配置。目前支持Apollo/iConf，支持功能包括-版本管理、热发布、灰度发布、权限管理、审核与审计等；
-
事件追踪/定位：借助sentry，对于一些故障，我们可以秒级感知。hulk在异常信息中保存了比较完整的现场信息-如调用栈、request、集群和实例信息等，通过这些信息，可以直接定位问题的原因；
2.2.2 通用组件
这一层的组件能力是通用的，提供了一些管理控制和切面能力：-
ral组件：hulk的ral模块封装了GDP2的ral主体功能，同时，对ral进行了增强- a) 提供了通过字符串而非文件来进行ral初始化和ral懒加载功能；b) 提供了多个hook能力，如prometheus的监控信息采集，熔断、降级等；
-
服务治理：框架的服务治理能力是基于Sentinel （阿里开源的高可用流量防护组件）和配置中心来构建的，主要以流量为切入点，从限流、流量整形、熔断、降级等多个维度来协助保障微服务的稳定性，并提供动态控制能力；
-
协程池：a) 可以自动调度海量协程，复用goroutines，减少gc，b) 可以优雅处理 panic，防止程序崩溃 c) 提供了：任务提交、获取运行中的 goroutine 数量、封装了WaitGroup支持协程任务编排等功能；
-
事件通知：框架与如流做了集成。用户将robot token配置在项目里，就可以直接使用ruliu组件向指定的如流群发送报警/通告。如流组件结合sentry，可以让我们第一时间知道程序出了问题并快速定位到问题；
2.2.3 扩展组件
前两层功能对直接的业务处理逻辑参与较少，这一层的组件其能力多是为了处理某一类特定业务逻辑和场景，如redis/mysql/定时任务等：1.redis组件：基于GDP2 redis模块的封装并作了功能增，提供了：a) metrics hook，对所有的redis请求进行监控(prometheus)打点（latency/p99/qps/错误码分布等）；b) sentry hook，支持将redis错误在记错误日志同时发送到sentry；c) 降级hook，支持按集群/实例/百分比维度降级redis访问；d) 熔断hook，支持按集群/实例/错误率/慢请求率对依赖的服务进行熔断设置；2.mysql组件：mysql组件是基于GDP2 mysql和 gorm_adapter的封装，在已有能力之上，进行了以下功能扩展：a) 提供了metrics hook，对所有的mysql请求进行监控(prometheus)打点（latency/p99/qps/错误码分布等）；b) 提供了sentry hook，支持将mysql错误在记错误日志的同时发送到sentry；
3.分布式锁：hulk提供了基于redis的分布式锁实现。其中redis连接是基于GDP2的redis模块的改造，分布式锁功能是封装了开源项目redsync；
4.定时任务：支持两种定时任务模式；a) 带分布式锁的运行方式：对于多实例部署的定时任务，如果任务不是幂等的，则需要使用分布式锁对任务的调度运行进行控制；b) 不带分布式锁的运行方式：此模式下，如果部署了多实例，则所有实例上同一时刻的定时任务，会同时执行；
2.2.4 http server
hulk（目前只提供了http server能力）提供了很多通用且高效的http middleware，并对外暴露了一些管理控制接口，在一些特殊情况下，可以通过这些管理接口，在运行时干预服务的运行：-
logger_middleware：用于记录http的请求、响应、耗时等信息，同时支持实时修改日志打印策略-如按idc/ip/百分比/uid/cuid等维
请发表评论