再小的應用也有架構，面向架構新手的架構實踐！

文章主人公：小明，就任於某互聯網公司，從過後端開發工做。最近小明收到通知公司須要開發一款《證件照》應用，須要徵集架構方案，主要功能包括：

小明雖然從過後端開發工做，可是一直很關注架構這方面的知識，以往都是開發大佬們架構好的應用如今有機會本身去實踐下，打算把本身學到的知識應用於實際案例中來。

小明的腦海裏是回想了下架構的基本三原則：

• 合適優於業界領先
• 簡單優於複雜
• 演化優於一步到位

小明做爲架構新手，雖然幹勁十足，可是也像大部分同樣開發人員同樣架構經驗較少，不知道如何下手去開始架構，萬事開頭難啊！小明請教了下公司的西踢毆（CTO），給了一句25字的架構真言：架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題

小明也算骨骼驚奇，久經沙場（996沒少鍛鍊人~~），思考了「架構真言」既然是爲了解決軟件系統繁雜度的問題，那不得先找出系統的複雜點在哪裏嗎？

發現複雜點

小明根據「架構真言」開始思考《證件照》應用的複雜點，首先它是一款工具類應用，主要功能是進行圖像處理：

小明發現圖像處理和圖像存儲可能比較複雜，公司現階段沒有專門作圖像處理團隊，也沒有大數據團隊，這兩個問題是要優先解決的問題。

小明如今使用的手機是Galaxy s9一張照片大概是6m，若是初期應用日活1w，假設有20%的人會處理圖片，那一天的存儲量大約10g，運行一個月就須要300g的存儲空間，這個配置個幾T的磁盤能夠跑個1年左右。不過這只是1w日活還要考慮到十萬、百萬級別的時候怎麼辦。

通過討論小明列出了一些複雜的地方並按優先級作了排序：

1. 圖像存儲
2. 圖像處理
3. 訂單處理
4. 物流處理
5. ...

設計架構方案

對於圖像存儲複雜性，小明第一個想到的是一個分佈式文件存儲方案，這樣數據容量、可用性均可以獲得很好的保障。他首先將這個想法和西踢毆交流了下，西踢毆也沒有否定這個方案只是讓小明考慮下成本方面的因素，小明回頭一想確認引入"分佈式文件存儲"首先會帶來如下幾點問題：

• 系統複雜性提升
• 運維成本提升
• 系統可用性下降
• ...

小明思考了下簡單優於複雜原則，決定使用最簡單的本地磁盤存儲圖像文件，可是使用本地磁盤的方案必定要考慮擴展性，未來隨時均可能擴容、遷移數據，因而小明對圖像存儲作了個簡單的抽象層：

小明對於存儲複雜性應用了架構原則中的原則簡單優於複雜、演化優於一步到位，同時對於存儲的可變性，經過引入抽像層可以有效合理的應對將來的變化。

初步定下來圖像存儲後，小明開始對圖像處理複雜性的問題進行設計，一張證件照的製做流程大體以下：

• 用戶提交圖片
• 檢測人臉
• 人像與背景切割
• 將切割後的圖交給客戶處理
• 客戶端合成背影、正裝生成證件照

檢測人臉、頭像分割這類技術公司也沒有使用過，基本上自研是不可能的，再說人力成本也不夠，首先合適的方案就是用第三方的服務，一番調研發現百度AI有人像處理的能力，小明開始考慮使用百度AI的服務，因而引入百度AI的服務：

對於圖像處理小明考慮合適優於業界領先原則，考慮人力、物力的成本選擇合適的方案，而不是一開始就說要自研一套圖像處理系統，投入大量的時間和人力去作最後得不償失。通過一番操做後，小明最後整理出一張基礎架構圖交給了西踢毆，等待西踢毆的轉身~~

總結

根據架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題的綜指，小明首先找出系統的複雜點，而後通過優先級排序，一步步的解決複雜性的問題，最後結合實際狀況設計出一套可行的架構方案。架構設計也是有套路可尋的，雖然案例架構比較簡單沒有大規模的分佈式、高可用、高併發場景，再小的應用也是有架構，也要通過深思熟慮再去實行否則會是滿地的技術債，後期要花更多的成本去維護重構。

《架構文摘》天天一篇架構領域重磅好文，涉及一線互聯網公司應用架構（高可用、高性 能、高穩定）、大數據、機器學習等各個熱門領域。