一.开发阶段

1.需求

自我驱动/客户驱动

  这里注意的是两者的优先级别，以及个别客户定制化对业务抽象造成的耦合问题

2.迭代

版本的划分，重构时机的选择

新项目，最好采取通用的starter新建项目，服务基础的组件做到封装
比如http库，线程池

3.方案设计

要提前思考可能出现的并发场景，并设法验证以及解决

例子: 对外的API设计要按照业务划分
例子: 方案中涉及到的数据结构是否线程安全？
例子: SQL相关的效率，通过mock大数据量进行检查

服务间调用

1.push/pull模型, 子系统利用HTTP/RPC/MQ解耦
2.轮询的push模型改为异步回调通知

4.安全性

密码等认证方式安全性，禁止明文泄漏 内部/外部服务之间认证，比如jwt等，安全加固

5.兼容性

SDK版本升级/故障处理, 发布灰度 防御性编程，必传参数的异常类型检查(比如UNDEFINE， NONE)

二.上线阶段

1.上线方案

全量/灰度

预发布先行测试功能，灰度发布运行观察无问题后，进行SLB摘流量

测试

核心流程功能测试/客户app核心流程验证

监控

服务内部异常报警
非200Nginx相关日志提前预警 5分钟采集一次

行为分析

客户端埋点上报，便于分析用户trace
服务质量相关/用户行为数据上报, Elk图标统计展示

服务灾备

是否存在服务单点？主备，主从，热备/冷备
服务机器是否多可用区部署

三.维护阶段

1.沟通

客服<=>开发

根据紧急程度，及时反馈，快速定位
如果客户使用问题，则对应解决
如果全局问题，则服务回滚
偶现问题，排期解决

测试<=>开发

开发自测后，提交测试，说明测试功能点，测试环境，测试范围
有问题后，要求尝试复现，找出对应规律方便解决

以上是本人从业相关的总结

最大的痛点在toB行业， 1.因为服务企业，所以有企业个性化定制的功能 会对整体的系统造成侵入性，并且做出来以后客户也可能不签单。 2.项目迭代的周期，以及重构的时机(越往后越难改动，一处改动可能引发雪崩) 3.方案的选择，有时候内部服务之间的调用，因为要协同开发，所以有些临时方案 为了功能实现只能折中，此处应及时避免，并且排期解决

 例子:
     一个文档状态查询，原先一直有定时任务一直轮询接口请求来查询
     几乎大部分时间造成cpu空转和无必要的并发请求
     改为服务异步通知后，配置个回调地址即可

4.开发上线全流程问题的跟踪，要确保所做的改动实际生效

 例子:
     mysql主从分离，采用了阿里云的proxy，代码中换了个连接地址
     但是框架层次，每次request自动开启一个事务，读写操作都合并在了一个事务
     导致数据库请求都打到了主库