互联网服务后台框架的九个要点

 

对于互联网服务后台团队，开发框架的选择是非常关键的一个问题，多年的海量服务经验和教训使得我们团队深刻的认识到：

• 要尽早规范团队的开发服务框架，避免到了后期，各种开发语言混杂、各类存储组件充斥、重复编码、每个模块形态不统一、文档缺失、监控瘫痪、人员离职造成大量信息丢失，最后积重难返、痛苦不堪。
• 没有框架来规范，团队的随意性就太大，合作效率就大打折扣，甚至于内耗、反复的挖坑填坑，系统的成败过于依靠人的意识和水平。
• 规范，不能靠文档、不能靠劳动纪律、不能靠苦口婆心、不能靠人员意识、不能靠运动式的整顿，要靠技术框架上切实的限制与贴心保护。

如果有机会从0开始定义一个理想的开发框架，需要考虑哪些点？我们觉得主要有如下9个方面：

1. 同步编码异步执行：兼顾运行效率和编码效率，希望代码写起来是同步和顺序的，而执行的时候是异步的。
2. IDL/RPC：支持IDL（接口描述语言）和RPC，减少网络协议相关的重复工作，协议有比较好的扩展性；远程调用友好且高效，做到覆盖主要的开发语言。
3. LB：对服务间的调用选路进行统一的管理，对单机故障和网络波动等常见情况有自动容错，我们简称load balance(LB)。
4. 存储服务化：这个其实和开发框架关系不太紧密，这里提一下，强调存储应该有统一的组件且由专业的团队运维，就像共有云一样。
5. 过载保护：框架必须有成熟自带的过载保护机制，不需要业务开发人员关注或者关注很少。
6. 基础的监控和告警：RPC调用、机器的cpu/网络活动、任务并发度、时延、进程监控和秒起等基础信息，要有上报、统计和告警，不需要业务开发人员关注。
7. 完整的业务流转呈现：统一日志，在一个地方能够清晰的呈现某次业务处理过程的流转详细情况：经过了哪些模块间调用，调用参数是怎样的，每个模块处理的重要分支和结果是怎样的，最好图形化呈现。支持染色和不同的日志详细级别。