来源: 网络整理 时间: 23小时前 人气: -
我有一个好朋友老周, 他人在杭州, 带领着由八个人组成的团队, 主要负责去做餐饮类型的小程序开发业务, 而且那些程序的源代码都是他自己独立搭建出来的。
去年他在技术搭建方面踩过的坑, 数量多到了能够写成一本书的程度, 这些坑包括从项目立项这一阶段开始, 一直到现在为止的上架以及后续的重新施工过程。
这篇文章把整个技术搭建的过程全都扒出来了, 那些正在做小程序源码开发的朋友请认真地看完, 这样能够让你们至少少走三个月的弯路。
老周在西湖区那边的某些写字楼里面进行办公活动, 他的团队当中一共有八个人, 这八个人具体是四个人负责后端开发, 另外四个人负责前端开发, 他们主要负责的事情是接收一些中小型企业所提出的定制开发需求。
在今年他接到了一项工作任务, 这一任务的时间点发生在今年三月份。具体工作是为杭州当地的一家连锁类型火锅店开发一款小程序形式的点餐系统。在这一过程中, 客户方面明确提出了需要交付源码的要求。基于此要求, 后续的系统迭代与维护工作需要由其自身进行掌握与控制。
他在最初的时候认为, 搭建一个基础性的框架并且接入一套用户界面组件库这件事情, 只需要用两个星期的时间就能够成功解决。但是实际的执行过程并不是这样, 在第一个星期即将结束的时候项目陷入了停滞状态, 关于技术方向的最终选择问题, 整个团队的每一个成员都进行了争论, 并且这种争论持续了整整三天的时间。
前端到底是用原生的方式还是用跨端的方式, 这个还没定下来, 后端是使用Node环境还是使用Java环境, 也没达成一致。他后来跟我说了, 搭建技术框架的起步阶段最大的坑点就是没有人去把目标给量化清楚, 全凭感觉拍脑袋。
在四月中旬那个时间点, 老周召集人开了一个时长足足达到了两小时的方案探讨会, 随后将三套完全不同的技术搭建实施方案全部摊开, 摆在桌面上头对头部进行了一一的比对和考量。
最终的决定是采用原生小程序联合 Node.js 后端这种技术方案, 并且在选择数据库的时候选用了 , 同时在缓存层面又添加了一层 Redis 来增强系统能力。
在他那时候看来, 这样的技术架构是已经足够应对当前需求的, 因为只要核心的业务功能能够正常运行并顺利跑通, 其他的考量因素就可以暂时忽略不计。
结果是五月份在上线之前进行压力测试, 模拟一千个用户同时点菜、下单这个动作, 接口响应时间直接飙到了四秒多, 并且数据库的连接池直接被撑爆了。
那位负责测试的同学当场拍了桌子。他在这个时候才真正清楚地知道, 技术架构的搭建过程并不仅仅是看功能是否能够顺利运行那么简单, 关于并发能力的上限数字和具体的性能指标要求, 是需要提前进行明确的规定并且固定的。
到了当天的晚上以后, 他在公司里工作一直持续到了十一点钟的时间点, 并且再次对数据库索引的设置以及读写分离的整体实施方案进行了全面地梳理和处理。
当时是六月初, 老周对着监控面板, 他改架构这事一共改了整整两周。他把Redis给加上了, 拿它来做菜单和热门菜品方面的缓存预热工作, 数据库这块也做了读写分离这样的处理。
热数据走从库, 冷数据归档到冷存储。折腾完之后, 同样一千并发, 响应时间压到了三百毫秒以内。
他在进行复盘的时候指出, 最为严重的那个坑根本不是技术选型这件事情本身, 而是由于在项目启动的那个阶段没有把QPS还有数据量这两个要素给写入到技术方案里面去, 所以导致了后续的每一个决策行为都完全是依靠拍脑袋这样一个随意的方式来进行的。
在七月的时候, 客户那边提出了需求, 希望增加一个外卖配送的模块。因为当初在设计底层架构的时候, 特意预留了扩展的空间, 所以他仅仅用了三天的时间, 就把对接工作全都搞定了。最终的结果是客户感到非常的满意。
现在当老周接手任何的工程项目之时, 他所迈出的第一步, 并不是立刻去动笔写程序代码, 而是要拿出技术架构的方案, 将并发的数据流量规模、未来数据增长的具体预期数值、以及系统可扩展性的边界范围，统统都进行量化处理, 并且把这些细节全部用文字明确地固定下来。
他当时用的原话是说方案阶段需要花费三天的时间, 但是在后面的开发周期里能够节省出三个月的时间, 如果你目前正在进行小程序源代码的开发活动, 那么在技术架构构建方面确实不可以进行压缩, 原本想通过节约这部分投入而获得的时间收益, 最终往往还是会全部用于处理因为草率施工导致的返工问题上。
