重构技术架构首先解决组织架构

技术架构来源于人员组织架构

过去两年作了很多大型的中台项目，什么是中台？这篇文章就很少说了，自行百度一下，总而言之最后我得出了一个结论——企业什么样的人员组织架构就会什么样的系统技术架构。咱们先如下一幅图：

一、第一阶段：小型企业

这个阶段就是企业的初创阶段。公司就几个员工，甚至就老板一个员工，开发是他，销售是他，人事是他，搬运也是他。这个时候须要配置系统就是典型的单机应用，特色：简单快速、易于开发、易于部署；重点是---省钱！

二、第二阶段：中型企业

这个阶段就是老板熬过了生存阶段，开始有些小钱能够招聘员工，但这时没算富裕，会在淘宝买些便宜的系统支持一下业务，本身的系统服务器扩容一下，从2核买到了4核

三、第三阶段：大型企业

这个阶段老板正式暴富了或者拿到融资了，公司人员愈来愈多，有了部门的概念了，每一个部门也须要管理，业务也须要更多功能模块来支持，这时候咱们系统就须要集群来支持更多的访问量和业务量了，以下图：

四、第四阶段：

这个阶段我就很少说了，整个公司至少拿到B轮或者已经有三位数以上的员工了，也猜到我会说用微服务或者更高大上中台的架构。

前面说的都是些大概，我直接说个人案例吧，我在上一家公司（乙方）时候已经作了很多中台项目，自觉得对这种架构已经有些了解了，直到遇到到了这家企业（甲方）实际作需求的时候才遇到这些坑。

真实案例

业务背景：

咱们这企业主要作移动共享充电宝业务，和国内几大x电不同，咱们是作国际化，需求方在日本、中国台湾、泰国、中国香港地区，因此看起来简单的租借逻辑变得异常复杂，由于仅仅是第三方支付公司就十几家，支付方式积分、优惠卷也十几种。并且这也是一个国际化团队，由于日本的需求很是特殊，因此他们有本身的开发，因为领导层缘由而咱们的核心代码又不能给日本开放，因此每次上线都要有专人去拿日本方的代码合并到咱们master分支里面去。

犯下的错误：

• 为了作中台，直接把负责每一个地区的核心开发抽取出来作中台
• 在没有调理好开发的组织架构前，直接安排开发任务

就是这两个错误，致使咱们的业务线在接下来一个月直接瘫痪，泰国、日本需求线全面告急；一个跟了我很长时间的开发兄弟直接跟我提离职；bug数量直线上升；产品总监跑来跟说，再这样下去，产品团队就不玩了。
但问题又来了，中台架构若是不这样作，让不熟悉业务的人去作重构我彻底不放心，业务层给的压力特别大，否则现有架构支持不了几大需求方的并发。

后面我发现是我方法论错误了，我没有太多甲方的经验，那我应该怎么作呢？后来，我把业务拆了出来进行了分析!

通过讨论和调研，每次新需求都离不开主要几大的业务模块开发：

1. 支付对接业务 占比30%
2. 机柜业务 占比20%
3. 营销活动 占比20%
4. 代理合做商 占比10%
5. 平常报表 占比20%

因而我对组织架构作了微调

不知道有没有发现我把组织架构从业务线拆出来之后，个人中台架构，天然就出来了，过程当中我没有重构过任何代码，只是慢慢把业务从业务线剥离出来，增长了一个接口层，并且几乎没有增长过多的代价和成本，这就是个人结论，改变技术架构首先解决组织架构。

---

本文做者：子祖

阅读原文

本文为云栖社区原创内容，未经容许不得转载。