电商企业内部技术衍进 - 复盘

公司刚好经历了4年,随着企业和公司的成长,组织结构也演变了很多次,对应的企业内部的系统也分化出来N多系统来,经历了两个同结构类型的部门,复盘下过往历程以及一些思考。

1. 2015~2017历程

处于五洲会期间

1.1. 销售端+ERP系统

  • 销售端基于ECShop疯狂建站,定时任务抛单给ERP系统的订单模块
  • ERP系统:涵盖了商品基础数据、订单数据、供应链仓储库存、财务几大模块

1.2. ERP拆分阶段

  • ERP单体应用,拆分成多个子系统:
    • OMS: 订单管理系统
    • PDM: 商品管理系统
    • WMS: 仓库管理系统
    • FMS: 财务管理系统
  • 销售端依旧没有什么太大的变化,新的项目依旧基于Copy-Modify-Run,依然是基于ECShop的维护
    • 该阶段技术中心整体技术栈还是PHP,代码管理基于SVN,后端架构LNAMP架构,无文档管理系统
  • 负责的五洲会初期
    • 在ECShop上改写了框架部分,最小程度拉起了一个MVC框架,依旧重构了相关核心业务,模块重组&梳理,整体故障和维护成本下降
    • 后端架构摒弃了Apache,直接都转到LNMP,基于phpfpm提供php脚本解析

1.3. 基于框架探索&重构阶段

  • 公司内部新项目试错很多,销售端的新项目的开发和维护成本很高
  • 随着ERP的拆分,也分组出来各个供应链的业务技术团队,负责供应链的四块业务
  • 该阶段技术中心整体技术栈还是PHP,单体框架的引入和尝试(ZF、YII、L…),虽然故障较多,但整体的业务响应速度还是较快
  • 负责五洲会前期,业务快速发展,五洲到家、B2B等业务
    • 五洲会的除主要的销售站点,五洲会其他新的系统都统一选择了L框架,有了框架和标准化的模块设计划分,维护成本较低
    • 五洲会加入了文档管理与文件资源内部共享服务

1.4. 技术引入与内部技术尝试

  • 很多销售团队业务同质化,技术部门引入Java团队、同时也设立了大数据、中间件团队
    • 中间件搜索这块,之前都是基于Sphinx,全面转ES(之前有建议过转ES,上一家也是用的ES,最终还是转了)
    • Java这块SOA团队,积极尝试新的业务(实际上是基于Java重构原有的商城业务系统)
  • 负责五洲会中期
    • 引入Swool框架解决任务处理过程中,原有的cron的一些弊端
    • 配合运维做一些CD的事情(DevOps)
  • 五洲会后期
    • 线下实体业没搞起来,海淘业务没有重大突破,最终搁浅

2. 2017年底~2019

转到电子研发,负责网站研发

2.1. 2017 - 业务维稳 + SOA尝试

  • 电子团队
    • 旧业务梳理、优化、调整,抗过双11
    • SOA一边试错,一边在对接一些小站点业务尝试
  • 技术中心
    • 接入Wiki(基于Confluence)、Jira,都是基于Atlassian的产品线(java系,整体效果还是不错)
    • 接入Gitlab,整体技术中心转Git

2.2. 2018 - SOA化

  • 业务团队SOA团队进一步基础抽象,做了一些三端业务的通用服务,虽然后续对接过程中
  • 电子站点团队转SOA重构,前面3端(PC\WAP\APP),基于L框架对接完SOA(时间以及团队水平的衡量),分3次切完了线上流量(实际是4次,第一次出现了回滚,没有考虑到推广流量问题)
  • 对接完后SOA,优化,扛过双11
  • 技术中心
    • AI、大数据、运维都开始有一定的改变,比如业务信息化、数字信息化(通过一些系统管理资源或业务)
    • 服务意识有了一定的开化,一些小型业务尝试以独立服务形式提供(库存)
    • 搜索、推荐、大数据曝光度度足够高

2.3. 2019 - 中台化

  • 技术中心
    • 中台化:期望做到资源整合与复用
    • 项目制:期望通过项目制拉通各组织部门人员
  • 个人
    • 基于Golang+Istio+K8S的服务化解决方案探索(全面拥抱Golang)

3. 发展历程的一些收获与思考

3.1. 组织不断演变,出现过的问题?

  1. 新的技术和思想引入,这些都没有问题,但是忽略了最基本的人的问题;
  2. 技术过快的引入,但对技术没有吃透,组织中对技术的一知半解,缺乏架构设计思维以及业务和产品的思维,导致技术变成了业务快速发展带来了掣肘;
  3. 没有技术积累,导致了目前的技术泥浆感,陷入技术债,业务跑不动,沟通部门墙;
  4. 组织结构变革依旧还是没有摆脱原有的弗雷德里克-泰勒的管理思想,树形结构以及层级管理思维依旧盛行

3.2. 管控一个新的业务

  1. 第一阶段,优先业务发展和试错,打开市场,积累资源
    • 业务小团队少,企业规模小的情况下,采用单体结构,通过模块化分,适当的系统分割,能够足矣支持业务即可,不要一味的追求技术的怪圈,目前大多数的单体足矣支持很多企业的业务发展
    • 小型技术团队难以支持起微服务套件,大多会停留在小规模尝试基础上,不要拿个锤子,总想着到处找钉子
    • 这一阶段,注意用户数据的积累与规整,做好相应的数据收集,为后期大数据赋能准备(万一大了呢)
  2. 第二阶段,业务快速发展期,技术某些特定情况下,成为技术的瓶颈(比如大促、秒杀活动)
    • 尝试将单体应用中的某些模块,解耦独立出来,将高频业务与低频业务分割,重型事务性业务与轻型业务分割解耦
    • 独立出来业务与原有的单体系统进行数据通信可以基于MQ解耦或者统一的API网关调用,同时也方便扩展
    • 独立出来业务做成服务化,需要考服务设计的标准,为后续更多的服务迁移打好基础,因此,最前面的几个抽离服务要么做得比较好,成为典范,要么准备后面再继续重构
    • 这一阶段,考虑技术对业务的支撑为主,同时提前预测好相关的技术转型储备(比如微服务架构)
    • 由于服务的逐步拆分,导致整体业务应用的监控逐步变得困难,因此一个好的链路监控系统,需要开始设计
  3. 第三阶段,业务高速发展期,企业核心业务成型
    • 考虑到业务很多基础形态已经足够清晰和明确,可以对应用系统进一步的重构演变,此时可以将更多的基础服务下沉,方便顶层前端应用的组装
    • 微服务可以大规模的推广(依托于第二阶段的一些前期工作准备),此时,服务标准化、服务注册发现、服务治理、服务监控、CI/CD、容器化等都提出来了
    • 微服务的开发需要有标准,方能自动化,以及快速CI/CD
    • 业务和产品的抽象,以及业务与技术的结合,需要拥有优秀架构思维的架构师来打通。同时公司内部划分成多个职能组织,架构师是能看清楚全貌的人,需要拥有良好的沟通技巧,协调各组织成员,拉通项目研发流程(如果架构师在业务与技术方面没有问题,但在沟通方面存在一定问题,可以安排一个PMO或者项目管理配合)
    • 各类新的技术的结合与数据反哺和加持业务,比如AI和大数据
  4. 第四阶段,分久必合合久必分
    • 企业内部的服务,能做资源整合的做资源整合
    • 大的业务,存在维护困难的,考虑逐步进一步拆分

3.3. 收获

  1. 人的重要性,企业成功,是管理者的成功,是员工的成功
    • 业务、产品、技术,形成短板效应(研发吐槽产品文档不清晰,产品说业务没调研清楚,业务说技术不给力)
    • 更进一步是招人考核,优秀的人能招来更加优秀的人
  2. 技术过早引入与技术变革,带来不一定是业务的增长,可能是掣肘
    • 思考当下企业或团队存在哪些问题,是否新的技术引入就能够解决这些问题,使用技术的人能否hold住这块新的技术
    • 提出有意义和价值问题的人,往往比解决问题的人更厉害
  3. 工具化、标准化以及自动化,甚至智能化
    • 标准化,可以让做事情流程化(这个是工业机械时代的最大效率的提升)
    • 工具化,可以替代原有手工或者人力做的事情(比如统计,报表)
    • 自动化,在标准化和工具化的前提下,更进一步的释放人,以及提升工作效率
    • 智能化,结合大数据,AI的一些分析,反哺和加持业务或者技术
  4. 基础理论的重要性
    • 在解决各类系统底层或者性能优化时候,对计算机科学的理论知识了解得越透彻,则对软件的开发调优更加容易
    • 软件工程师,需要有软件编写设计的能力(DSA、设计模式、编程语言)与工程实践的能力(SRE),除此以外,沟通和协助的能力也很重要
    • 学习东西需要成体系
    • 进一步看清自己的不足
  5. 圈子的重要性
    • 跟对人的重要性
    • 没有好的师傅,则自己找师傅,虽然比较难,有条件先提高自己的基线
    • 学会提出问题,往往比直接给出解决方案有效(管理手段)
  6. 机会选择的重要性
  7. 技术演变
    • 基于PHP的技术栈,到基于Golang技术栈的转变
    • 直接到K8S+Istio,微服务技术栈

4. 下一步计划

  1. 理论强化,进一步完善DSA与CS;
  2. 强化工程实践,拿出一套微服务技术解决方案(基于K8S+Istio),更多的项目学习、试错与总结;
  3. 增加见识,技术系统化,以及将技术整理和输出;
  4. 进一步深造,提升自己的基线(企业&学业);
  5. 与业务更好的结合(技术服务于业务);