技术架构来源于人员组织架构
过去两年做了不少大型的中台项目，什么是中台？这篇文章就不多说了，自行百度一下，总而言之最后我得出了一个结论——企业什么样的人员组织架构就会什么样的系统技术架构。我们先以下一幅图：
1、第一阶段：小型企业
这个阶段就是企业的初创阶段。公司就几个员工，甚至就老板一个员工，开发是他，销售是他，人事是他，搬运也是他。这个时候需要配置系统就是典型的单机应用，特点：简单快速、易于开发、易于部署；重点是---省钱！
2、第二阶段：中型企业
这个阶段就是老板熬过了生存阶段，开始有些小钱可以招聘员工，但这时没算富裕，会在淘宝买些便宜的系统支持一下业务，自己的系统服务器扩容一下，从2核买到了4核
3、第三阶段：大型企业
这个阶段老板正式暴富了或者拿到融资了，公司人员越来越多，有了部门的概念了，每个部门也需要管理，业务也需要更多功能模块来支持，这时候我们系统就需要集群来支持更多的访问量和业务量了，如下图：
4、第四阶段：
这个阶段我就不多说了，整个公司至少拿到B轮或者已经有三位数以上的员工了，也猜到我会说用微服务或者更高大上中台的架构。
前面说的都是些大概，我直接说我的案例吧，我在上一家公司（乙方）时候已经做了不少中台项目，自以为对这种架构已经有些了解了，直到遇到到了这家企业（甲方）实际做需求的时候才遇到这些坑。
真实案例
业务背景：
我们这企业主要做移动共享充电宝业务，和国内几大x电不一样，我们是做国际化，需求方在日本、中国台湾、泰国、中国香港地区，所以看起来简单的租借逻辑变得异常复杂，因为仅仅是第三方支付公司就十几家，支付方式积分、优惠卷也十几种。而且这也是一个国际化团队，因为日本的需求非常特殊，所以他们有自己的开发，由于领导层原因而我们的核心代码又不能给日本开放，所以每次上线都要有专人去拿日本方的代码合并到我们master分支里面去。
犯下的错误：
- 为了做中台，直接把负责每个地区的核心开发抽取出来做中台
- 在没有调理好开发的组织架构前，直接安排开发任务
就是这两个错误，导致我们的业务线在接下来一个月直接瘫痪，泰国、日本需求线全面告急；一个跟了我很长时间的开发兄弟直接跟我提离职；bug数量直线上升；产品总监跑来跟说，再这样下去，产品团队就不玩了。
但问题又来了，中台架构如果不这样做，让不熟悉业务的人去做重构我完全不放心，业务层给的压力特别大，不然现有架构支持不了几大需求方的并发。
后面我发现是我方法论错误了，我没有太多甲方的经验，那我应该怎么做呢？后来，我把业务拆了出来进行了分析!
经过讨论和调研，每次新需求都离不开主要几大的业务模块开发：
- 支付对接业务 占比30%
- 机柜业务 占比20%
- 营销活动 占比20%
- 代理合作商 占比10%
- 日常报表 占比20%
于是我对组织架构做了微调
不知道有没有发现我把组织架构从业务线拆出来以后，我的中台架构，自然就出来了，过程中我没有重构过任何代码，只是慢慢把业务从业务线剥离出来，增加了一个接口层，而且几乎没有增加过多的代价和成本，这就是我的结论，改变技术架构首先解决组织架构。
本文作者：子祖
本文为云栖社区原创内容，未经允许不得转载。
网友评论