重構技術架構首先解決組織架構

技術架構來源於人員組織架構

過去兩年作了很多大型的中臺項目，什麼是中臺？這篇文章就很少說了，自行百度一下，總而言之最後我得出了一個結論——企業什麼樣的人員組織架構就會什麼樣的系統技術架構。咱們先如下一幅圖：

• 第一階段：小型企業
  這個階段就是企業的初創階段。公司就幾個員工，甚至就老闆一個員工，開發是他，銷售是他，人事是他，搬運也是他。這個時候須要配置系統就是典型的單機應用，特色：簡單快速、易於開發、易於部署；重點是---省錢！

• 第二階段：中型企業
  這個階段就是老闆熬過了生存階段，開始有些小錢能夠招聘員工，但這時沒算富裕，會在淘寶買些便宜的系統支持一下業務，本身的系統服務器擴容一下，從2核買到了4核
• 第三階段：大型企業
  這個階段老闆正式暴富了或者拿到融資了，公司人員愈來愈多，有了部門的概念了，每一個部門也須要管理，業務也須要更多功能模塊來支持，這時候咱們系統就須要集羣來支持更多的訪問量和業務量了，以下圖：

• 第四階段：
  這個階段我就很少說了，整個公司至少拿到B輪或者已經有三位數以上的員工了，也猜到我會說用微服務或者更高大上中臺的架構。

前面說的都是些大概，我直接說個人案例吧，我在上一家公司（乙方）時候已經作了很多中臺項目，自覺得對這種架構已經有些瞭解了，直到遇到到了這家企業（甲方）實際作需求的時候才遇到這些坑。

真實案例

業務背景：
咱們這企業主要作移動共享充電寶業務，和國內幾大x電不同，咱們是作國際化，需求方在日本、中國臺灣、泰國、中國香港地區，因此看起來簡單的租借邏輯變得異常複雜，由於僅僅是第三方支付公司就十幾家，支付方式積分、優惠卷也十幾種。並且這也是一個國際化團隊，由於日本的需求很是特殊，因此他們有本身的開發，因爲領導層緣由而咱們的核心代碼又不能給日本開放，因此每次上線都要有專人去拿日本方的代碼合併到咱們master分支裏面去。

犯下的錯誤：

• 爲了作中臺，直接把負責每一個地區的核心開發抽取出來作中臺
• 在沒有調理好開發的組織架構前，直接安排開發任務

就是這兩個錯誤，致使咱們的業務線在接下來一個月直接癱瘓，泰國、日本需求線全面告急；一個跟了我很長時間的開發兄弟直接跟我提離職；bug數量直線上升；產品總監跑來跟說，再這樣下去，產品團隊就不玩了。
但問題又來了，中臺架構若是不這樣作，讓不熟悉業務的人去作重構我徹底不放心，業務層給的壓力特別大，否則現有架構支持不了幾大需求方的併發。
後面我發現是我方法論錯誤了，我沒有太多甲方的經驗，那我應該怎麼作呢？後來，我把業務拆了出來進行了分析!

通過討論和調研，每次新需求都離不開主要幾大的業務模塊開發：

1. 支付對接業務 佔比30%
2. 機櫃業務 佔比20%
3. 營銷活動 佔比20%
4. 代理合做商 佔比10%
5. 平常報表 佔比20%
   因而我對組織架構作了微調

不知道有沒有發現我把組織架構從業務線拆出來之後，個人中臺架構，天然就出來了，過程當中我沒有重構過任何代碼，只是慢慢把業務從業務線剝離出來，增長了一個接口層，並且幾乎沒有增長過多的代價和成本，這就是個人結論，改變技術架構首先解決組織架構。

原文連接
本文爲雲棲社區原創內容，未經容許不得轉載。