刚进萌推时输出的一份文档, 现在回头看来, 有不少地方值得推敲. 先放到 blog 上, 权且抛砖引玉吧.
微服务基础 & 选型
微服务现状, 以 spring 为例, 怎么把单体服务 -> 微服务
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的经验, 结合我几次经历重构的经验, 场景其实出奇的一致(新入职的新, 和重构需要面临的新), 要给「新人超出现有能力的任务」
