架构师接龙 孙立VS. 孙朝晖
主持人:冯大辉孙立:你是如何在架构层面,提高开发人员开发效率的?比如通过合理的分层,不同层安排不同能力的开发人员。孙朝晖:首先孙立老师已经谈到了这个问题的两个核心,第一是合理的分层,第二是让不同能力层次的队伍有机组合。对于分层,具体到我们的技术体系,可以清晰地分成四个层次,对应四个技术层次,分别是:前端(JavaScript开发)、Web应用(PHP开发)、中间件(Java开发)和通...
·
主持人:冯大辉
孙立:你是如何在架构层面,提高开发人员开发效率的?比如通过合理的分层,不同层安排不同能力的开发人员。 孙朝晖:首先孙立老师已经谈到了这个问题的两个核心,第一是合理的分层,第二是让不同能力层次的队伍有机组合。
- 对于分层,具体到我们的技术体系,可以清晰地分成四个层次,对应四个技术层次,分别是:前端(JavaScript开发)、Web应用(PHP开发)、中间件(Java开发)和通信与管理基础(C开发)。各层有独立的团队,开发人员专注于本层次的技术发展,各层次的开发团队Leader每日进行晨会交流开发进度,每周例会进行技术整合研讨。对于较完整的功能模块,设置有“技术方案评审会”,各团队专家参加,通过对各层技术特点的分析,综合考虑方案的可行性。
- 对于组织结构保证,每个团队都会有1~2名技术专家,1名团队Leader,若干开发人员。每个团队的技术专家负责开发基础框架,比如我们PHP应用的MVC框架、Java的Service Framework、前端JavaScript的基础类库,对于不同层次的开发人员根据能力安排角色,决定担任部件级别开发还是组合功能级别开发,保证每个团队都有不同层次的人员合理组合,每个开发人员都保持技术上升通道。这样会有效地提高开发效率,同时每个技
- 在技术方案评审阶段,充分考虑数据存储方式的合理性。不是每种数据都适合采用数据库存储,有些数据适合采用JSON,或者采用缓存中的List对象存储,而不适合分解到数据单元,这样的数据就没有必要设计成为关系型结构。
- 在数据结构设计过程中,保留适当的冗余字段,尤其是预估有动态变更的数据结构,而且状态标志尽量组合成为数据位结构,即典型的Mask应用。需要扩充状态位时,采用位扩充的方式替代字段扩充。
- 对于数据量很大的数据结构,比如我们业务当中的Feed数据,保持数据按照代龄进行分层,并且有合理的归档结构,保持活跃数据所在库的规模不过度,对于活跃数据库需要紧急调整的时候,变更代价也是可控制的。
- 对于数据量非常大的数据需要调整数据结构,那么只能靠数据库架构解决。我们采用的数据库架构都是M-M-S-S架构,需要进行大规模数据迁移,所以会利用备份库进行轮换下线(或半下线)维护变更,通过轮次的数据结构调整,最终达到数据结构完全变更。
- 功能测试环境的建设:功能测试环境主要面对的挑战不是线上、线下系统结构不一致,而是测试数据的不一致,由于数据不一致导致某些边界条件没有测试出来。对于这个问题,需要保持线上、线下关键数据的增量同步,采用小时间粒度的定期日志备份方法解决,同时要保证活跃数据的规模,以便能够控制线下数据库同步的规模。
- 性能测试环境的建设:性能测试环境的建设主要用于发现性能问题和容量规划。对于发现性能问题的目标,只要保持数据库服务器尽可能使用物理主机,在物理主机上采用多实例隔离的模式部署,其他服务器可采用虚机化技术,这样可以保持测试数据的可用性。
- 我们采用配置了SSD卡的服务器,以本地存储方式替代SAN存储设备作为MySQL数据库的文件存储,提升了MySQL单机访问能力。
- 我们正在测试使用虚拟机的方式,将Java中间件的物理服务器分拆成为多个虚拟机服务器。由于受到JVM的内存限制,我们的单机中间件服务器始终没有得到充分的利用,可以尝试一分多,提高系统并行访问能力。
- 对单机的性能提升,我们更倾向于在单机内部采取应用结构内的Scale Out方式,比如刚才说的虚拟机拆分,还有使用异步I/O替代多线程、对象池技术等,最后可能采取选用内存升级或CPU升级的方案。而Scale Up仅是为了满足某个具体需求采用的综合解决方案的一个组成部分。
- 在技术层次之间的通信协议尽量不要选用某种语言的私有标准,尤其是数据序列化,这样有利于扩展到通用的技术平台。
- 在通信模型上尽量选用通用设计结构。比如我们的进程间通信模型选择了Unix Domain Socket,保持与远程通信方式接口一致,保持可一致性,方便于服务的物理架构迁移。
- 在开源软件选择上尽量选择我们技术标准范围内的技术。如果没有找到对应项,一般选择改造现有相似开源软件或者独立开发的方向。由于我们选择Java和C开发技术,开源软件很多,目前来看还没有出现某个方面找不到对应功能的开源软件的情况。
- 每次出现故障时进行分析,准确定位故障的源头逻辑节点与物理节点,统计后作为知识库,标识出每个系统中的脆弱节点,出现故障后,优先挑选脆弱节点排查。
- 在架构进行Review时,尽量保持每个业务流程保证不超过3个物理节点的请求跳转,尽量减少物理层次深度。还有保证在一次调用流程中,级联的异步调用至少2次以下。在所有发出连续同步调用的初始节点上负责统一trace,方便故障排查。在物理架构图中标出这些调用流程中的关键节点,出现问题优先从关键节点开始排查。
- 在物理架构上,尽量明确服务器的角色,在某个角色服务器上部署同类型的服务。对于Java中间件服务器由于服务数目较多,尽量采用虚拟机技术拆分。单独服务器承载独立服务,比较容易定义监控策略并发出预警。
- 每次故障后Review告警与故障的关系,对没有及时告警的部分增加告警监控,告警不准确的部分及时修正,增强监控和告警的准确性。
- 在我们的技术体系内开发了针对分布式应用系统的部署和监控系统,应用服务器会集中的监控服务器汇总系统日志,统一与预警和告警系统集成。
更多推荐
已为社区贡献1642条内容
所有评论(0)