hyperf | 萌推 PHP 微服务化改造

date: 2019-05-05 11:03:01
title: hyperf | 萌推 PHP 微服务化改造

刚进萌推时输出的一份文档, 现在回头看来, 有不少地方值得推敲. 先放到 blog 上, 权且抛砖引玉吧.

微服务基础 & 选型

服务化架构演进

微服务现状, 以 spring 为例, 怎么把单体服务 -> 微服务

microservice - spring cloud

PHP 微服务现状: 包含 hyperf 框架实现的支持
hyperf doc: 包含框架组件 + 脚手架

开发组支持, 全部都是线上在使用, 统计截止时间 2019.05:

• 李/武: KnowYourself - 在线教育
• 黄/张: KK - 新零售
• dayday: 萌推

迁移计划

• 评审, 可行性分析, 现有业务贴合度
• 技术培训:
  • 微服务化概念
  • swoole服务器开发入门(全协程)
    • 根据 swoole wiki 整理: swoole| swoole wiki 笔记
    • NP(network programming)基础
    • swoole 协程
    • swoole 核心模块/各功能组件一览
  • hyperf框架基础:
    • hyperf-component: 框架核心, 由开发组维护, 欢迎一起参与
    • hyperf-skeleton: 开发组提供的全量 demo, 需要的功能都可以在这里找到代码实例
    • doc 已经可以满足常规开发使用
    • 框架核心/特性/快速入门
• 基础设施搭建与现有基础服务接入
  • hyperf 组件+脚手架+开发环境/测试环境(建议docker, mac 下搭建很快)
  • 日志
  • 监控
  • cache
  • redis
  • mysql
  • 异步队列
  • mq: rabbitmq kafka
  • consul
  • grpc
  • zipkin
  • ...
• 业务服务接入, 基础服务可以配合服务的接入过程一步步来
  • 选取非核心service, 加入 A/B test 验证
  • 切换到核心服务

改造过程相关问题

• 推进: 暂时将微服务改造放到第二优先级, 业务按照 紧急/重要 2个维度来评估是否插入
• 工程衡量指标
  • 开发效率: 容易卡住的点, 是否需要提供技术培训; 任务时间的评估, 留好buffer
  • 错误率, 错误响应时间（解决问题的效率）: 前期 日志/监控/报警 等基础服务, 人员的熟悉
• 人员分配: 待评估
  • 运维部署, 测试环境/pre/prod, 各环境下的依赖
  • 具体开发人员角色切换
• 改造过程中的业务痛点问题攻关
  • 熟悉业务, 才能技术上有的放矢
  • 提炼出工作流: 问题 负责人 涉及业务模块 监控日志 处理时效 总结

more

• 关于工作流的一个例子: db小分队解决慢查 -> 邮件慢查给技术经理 -> 成立小分队(数据分析团队兼任) -> 看慢查, 提建议给业务开发 -> 自己处理, 不确定再和业务开发对
• 关于2种技术管理风格: 传统 vs film, 传统 -> 技术经理越来越强; film -> 能力越大, 责任越大
• 关于新人培训: 来源于以前CTO的经验, 结合我几次经历重构的经验, 场景其实出奇的一致(新入职的新, 和重构需要面临的新), 要给「新人超出现有能力的任务」