再小的應用也有架構,面向架構新手的架構實踐!

来源:https://www.cnblogs.com/xwgblog/archive/2019/11/07/11812244.html

文章主人公:小明,就職於某互聯網公司,從事後端開發工作。最近小明收到通知公司需要開發一款《證件照》應用,需要徵集架構方案,主要功能包括: 小明雖然從事後端開發工作,但是一直很關註架構這方面的知識,以往都是開發大佬們架構好的應用現在有機會自己去實踐下,打算把自己學到的知識應用於實際案例中來。 小明的腦 ...


文章主人公:小明,就職於某互聯網公司,從事後端開發工作。最近小明收到通知公司需要開發一款《證件照》應用,需要徵集架構方案,主要功能包括:

小明雖然從事後端開發工作,但是一直很關註架構這方面的知識,以往都是開發大佬們架構好的應用現在有機會自己去實踐下,打算把自己學到的知識應用於實際案例中來。

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

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

小明作為架構新手,雖然幹勁十足,但是也像大部分一樣開發人員一樣架構經驗較少,不知道如何下手去開始架構,萬事開頭難啊!小明請教了下公司的西踢毆(CTO),給了一句25字的架構真言:架構設計的主要目的是為瞭解決軟體系統複雜度帶來的問題

小明也算骨骼驚奇,久經沙場(996沒少鍛煉人~~),思考了“架構真言”既然是為瞭解決軟體系統繁雜度的問題,那不得先找出系統的複雜點在哪裡嗎?

發現複雜點

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

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

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

經過討論小明列出了一些複雜的地方並按優先順序做了排序:

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

設計架構方案

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

  • 系統複雜性提高
  • 運維成本提高
  • 系統可用性降低
  • ...

小明思考了下簡單優於複雜原則,決定使用最簡單的本地磁碟存儲圖像文件,但是使用本地磁碟的方案一定要考慮擴展性,將來隨時都可能擴容、遷移數據,於是小明對圖像存儲做了個簡單的抽象層:

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

初步定下來圖像存儲後,小明開始對圖像處理複雜性的問題進行設計,一張證件照的製作流程大致如下:

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

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

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

總結

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





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


您的分享是我們最大的動力!

更多相關文章
  • GoF設計模式一共有23個。一般可以按目的和作用範圍來進行劃分,具體劃分方法如下: 第一,這些模式按目的(即完成什麼樣任務)來劃分為創建型、結構型和行為型這三種模式: 創建型:用來創建對象。單例、原型、抽象工廠、建造者、工廠方法這五個都屬於這一分類。這種類別起到了將對象的創建與其使用進行分離解耦。 ...
  • 重構改善既有代碼 第一次做某件事情的時候儘管去做,第二次做類似的事會產生反感,第三次再做類似的事,你就應該重構。 小型函數優美動人 一個類最好是常量類,任何的改變都是調用該類本身的介面實現。 0 壞代碼的味道 1、重覆代碼 Duplicated Code 同一類中的兩個函數含有相同的表達式,提取到方 ...
  • 0 簡單工廠模式 0.0 簡單工廠模式動機 考慮一個簡單的軟體應用場景,一個軟體系統可提供多個外觀不同按鈕(如圓形、矩形按、菱形按鈕等), 這些按鈕都源自同一個父類,不過在繼承父類後不同的子類修改了部分屬性從而使得它們可呈現不同外觀,如果希望在使用這些按鈕時,不需要知道這些具體按鈕類的名字,只需要知 ...
  • 要想理解持續集成和持續部署,先要瞭解它的部分組成,以及各個組成部分之間的關係。下麵這張圖是我見過的最簡潔、清晰的持續部署和集成的關係圖。 "圖片來源" 持續部署: 如圖所示,開發的流程是這樣的: 程式員從源碼庫(Source Control)中下載源代碼,編寫程式,完成後提交代碼到源碼庫,持續集成( ...
  • 本解決方案是一個Windows應用編程框架和UI庫,包括四個項目: Ligg.EasyWinForm是一個Winform應用編程框架和UI庫。通過這個該框架,不需任何代碼,通過XML配置文件,搭建任意複雜的Windows應用界面,以類似Execel公式的方式實現基本的過程式控制制(賦值、條件判斷、迴圈、 ...
一周排行
x