一家典型的互联网创业公司内部架构的演进过程

这家公司成立于2010年, 成立之初技术团队仅有4人. 得益于老板的英明, 再加上撞上了风口, 公司的业务一直发展的不错. 以下为这家公司的内部架构演进过程:

阶段1: 单体架构

2010年-2011年: 公司只有一条业务线, 业务处于缓慢发展阶段. 在团队成立之初, 技术负责人采用了SpringMVC + Spring + MyBatis的技术栈, 在一个月内上线了一套单体式系统. 技术团队根据业务需要不断上线单体系统. 此时公司业务处于试错阶段, 研发团队规模一直维持在4个人左右, 研发团队的交付能力能较好满足业务诉求.

阶段2: 烟囱式架构

2011年-2014年: 之前的老业务先1没有得到很好发展, 公司决定开辟一条新业务线2, 老业务1仅保持试错探索状态. 技术负责人决定通过copy老业务线1代码的方式独立部署新业务线2, 因为新老业务线的发展速度的不一致导致迭代速度不一致, 所以新老业务线独立部署, 不会相互影响迭代速度. 经过1个月的修改, 研发团队完成了业务线2的上线. 虽然研发团队扩大了10个人左右, 但疲于应对大量来自两条业务线的需求.

阶段3: 服务化架构

2014年-2016年: 业务2有了爆发式的增长, 给公司带来了大量的现金流, 公司决定扩张新的业务线3来进一步扩大市场边界. 研发团队也持续增长, 成为一个30人规模的组织. 虽然研发部门扩大了, 但是业务部门的投诉确越来越多: 交付速度缓慢, 交付物质量低下. 同时, 技术负责人也发现同样的坑在不同的产线总是重复发生. 为此技术负责人决定架构服务化: 通过将多产线共有的通用业务下沉, 分离了基础服务A和基础服务B, 每个服务由4人左右团队维护. 通过框架dubbo进行服务治理, 在技术团队进行了为期半年的服务治理后, 业务系统的交付速度和交付质量得到了很好的提升.

阶段4: 平台服务架构

2016年-至今: 因为业务2和业务3的发展, 公司巩固了细分市场的领先地位, 但公司需要进一步对其他市场进行开拓, 所以快速构建成熟稳定的业务线, 成了技术部门一项紧迫的任务. 技术负责人为此对业务线系统的通过逻辑进一步进行下沉, 构建了平台服务G和平台服务H,每个平台由一个3人研发团队维护, 两个平台提供了稳定可靠的基础业务能力. 而老的业务线复杂度也进一步得到降低. 公司在新的架构上启动了多条业务线, 平均每个业务线由2人研发团队 在2周内完成上线. 技术部门快速交付的能力得到了业务部门的认可.

场景

电商:

• 业务线系统: B2B业务系统, B2C业务系统, 团购系统 ...
• 基础服务: 用户服务, 商品服务, 订单服务, 购物车服务, 支付服务, 履约配送服务...
• 平台服务: 数据平台, CMS平台...

消费金融:

• 业务线系统: 3C场景贷, 家装场景贷, 现金贷...
• 基础服务: 风控服务, 用户服务, 贷前服务, 贷后订单服务, 资金服务, 催收服务...
• 平台服务: 数据平台, 申请流程平台...