理想的开发框架

发表于 更新于 分类于

以下内容, 由富途CTO ppchen总结

  1. 【同步编码异步执行】兼顾运行效率和编码效率，希望代码写起来是同步和顺序的，而执行的时候是异步的
  2. 【IDL/RPC】支持IDL（接口描述语言）和RPC，减少网络协议相关的重复工作，协议有比较好的扩展性；远程调用友好且高效。要开发语言无关，因为你用c开发，不表示其他团队也用c调用你的接口，所以IDL要能生成常见语言的RPC。
  1. 【LB】对服务间的调用选路进行统一的管理，对单机故障和网络波动等常见情况有自动容错，我们就简称load balance(LB)吧
  2. 存储组件化服务化，这个其实和开发框架关系不太紧密，这里提一下，强调存储应该有统一的组件且由专业的团队运维，就像公有云一样
  3. 【过载保护】框架必须有成熟自带的过载保护机制，不需要业务开发人员关注或者关注很少
  4. 【基础的监控和告警】RPC调用、机器的cpu/网络活动、任务并发度、时延、进程监控和秒起等基础信息，要有上报、统计和告警，不需要业务开发人员关注。在团队分工上，应该有专门的团队对框架进行运维，关注基础的监控和告警，业务开发人员将业务逻辑以.so等动态库形式提交到框架云端，业务开发人员关注业务逻辑告警
  5. 【完整的业务流转呈现】统一日志，在一个地方能够清晰的呈现某次业务处理过程的流转详细情况：经过了哪些模块间调用，调用参数是怎样的，每个模块处理的重要分支和结果是怎样的，最好图形化呈现。支持染色和不同的日志详细级别
  6. 【中央总控】整个系统的配置和文档，例如每个模块有哪些机器，分布在哪些机房、容量冗余情况、模块间调用关系、访问控制的配置动态管理甚至电子流，都希望能统一在一个地方web化的管理起来，并且与运营的系统是直接联系直接生效的，即避免文档记录是怎样怎样，而运营的系统实际情况是不一样。随便点开一个模块，就知道它的设备列表、分布、进程工作情况、调用了哪些模块、需要进行哪些接口权限申请，一目了然，人员更替无需交接，因为所有信息都在中央总控网站可见，且不会是过时的。
  7. 【云调度】容量的自动调度。例如要进行某个运营活动需要大量的扩容，只需要把设备放进去，就能自动的扩缩容。当某个城市机房故障，能够自动调度容量到其他城市