Home | 简体中文 | 繁体中文 | 杂文 | 打赏(Donations) | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 知乎专栏 | 视频教程 | About

1.10. 收缩技术栈

技术部门常常会陷入技术思维,恨不得将所有主流技术都使用上,却忽略了他们兼容性,以及对该技术的掌握程度。

当团队没有100%掌握某项技术是,风险是巨大的,我们常常会看到网上有这种文章《XXX踩过的坑》,无疑是拿生产环境练手,为自己的职业生涯打怪升级。

大炮打蚊子,很多需求根本无需使用复杂的技术,最终变成庞然大物。

尽量使用一种技术解决所有问题,而不是使用所有技术解决一种问题。这样技术团队学习起来不会太吃力,且团队人力资源可以共享,测试难度和运维难度都会降低。

1.10.1. 模块化思维

技术思维另一个误区就是,拆整为零,模块化。例如,用户中心,商品中心,订单中心,物流中心 ……

			
   用户中心 —---—- 商品中心,
     |  \       /   |
     |    \   /     |
     |      X       |
     |    /  \      |
     |  /      \    |
  订单中心 ——---- 物流中心			
			
			

看这个架构多么清晰

  1. 用户中心: 负责用户注册,登录,找回密码
  2. 商品中心:商品分类,商品搜索,商品列表,商品展示
  3. 订单中心:订单报价,订单合并……
  4. 物流中心:对接物流平台……

技术人员的成就感飘飘然,然票票。运维根据需求将上面四个中心使用四台高配置服务器部署起来。

市场部需求

  1. 用户登录
  2. 浏览商品
  3. 下订单
  4. 走物流
  5. 用户积分+100

平时没有什么问题,订单量一大所有问题都暴漏出来, 积分添加失败,库存数据出错,物流下单失败……

这种模式的问题有很多,例如

  1. 运维复杂,部署复杂,配置管理复杂
  2. 排查问题难度搞
  3. 分离后,通过网络连接,网络存在延迟和超时等等其他不可控因素
  4. 分布式事务处理,复杂且难以保证
  5. 分布式锁,并发的杀手

任何一个系统都不能简单的进行拆分,抓中拆分同样是我们教育的问题,导致思维方式产生问题。

15年前我就意识到这种问题所在,15年后去一下电商公司面试,发现他们仍然在采用这种模式。