多年後的架構感悟

很久沒寫博客了，晃眼一看最近的一篇竟然是2013年的。今夜無意睡眠，結合這些年本身對應用架構的一些感悟，談談幾點體會。

一.架構是須要資源來實現的

我的以爲，這是最最核心，可是一些小白架構師最容易忽視的一點。

曾經看過幾種場景，看各位同僚是否遇到：

架構師來自大廠，經驗豐富，負載均衡/高可用/讀寫分離/緩存/隊列，一頓操做猛如虎，最後罵隊友二百五。

任何架構最後的實現都是人來作的，架構搭建的前提，不只僅是看應用的場景和擴展性，還要考慮團隊資源的能力和技術棧背景。一般架構師會遇到兩種資源和架構的匹配方式。

1) 外部團隊入場開發

這種就是所謂的外包項目。外包的好處，在於入場前，架構師/項目經理在招投標時就能夠根據多家供應商的技術背景和應用實際場景作篩選，儘可能匹配到更合適的技術棧和架子上去。

2) 內部團隊自主研發

我曾經的團隊裏面，很多開發資源甚至只會寫代碼，沒有完整部署生產機的經驗... 可能在不少年經驗的技術來看是沒法想象的，但這就是現實。這個時候要根據成員的能力來搭架子，判斷開發成員是否有相關的經驗：

• 你辛苦搭的微服務，團隊成員是否有相關經驗？
• 你搞的Redis，團隊成員是否理解內部機制?
• 你前端弄個mvc，團隊成員會不會只會用jQuery操做頁面元素?

這些都是須要思考的問題。(固然，這裏並非說必須完徹底全按照成員的能力來搭架子，畢竟人的技術是能夠經過學習成長的。若是有槓精朋友，請不要針對這裏拍磚)

就像作菜，咱們準備食材的時候必定要考慮廚師是否有烹飪能力，鮑魚大閘蟹當然好吃，但並非誰都會弄。假如最後沒得吃，食客都得餓死，廚師也得滾蛋。

二.架構是能夠持續改進的

筆者也曾經中途接手過一些項目，這些系統最開始的架構並不完善，可優化的點也不少，都是經過持續改進愈來愈好。

以一個C端的門崗機系統爲例。

剛剛接手時，這個系統是一個很簡單的B/S架構：後端.Net Webservice (1臺服務器), 前端H5(1臺服務器)嵌在門崗機裏面訪問，後端SqlServer數據庫作了簡單的讀寫分離(2臺服務器)，在放行的時候本身寫了一套隊列機制。

後面實際的場景中遇到了很多問題：

1. 當業主早上上班及晚上下班時，門崗放行每每是高峯期，這時1臺接口服務器的壓力很是大，通過討論後，改進爲多臺。

2. 兩臺接口服務器間須要讀取業主的身份和房間信息，這些信息每每會高頻訪問(例如同一業主，在很接近的時間段內進進出出；門崗隊員屢次查詢業主信息覈實；)。而且以往的架構中會緩存一些信息，當應用接口服務器拆分爲多臺後沒法共享內存中數據。ok，改進。

3. 在寫入放行數據時本身開發了一套隊列機制，可是後面卻發現bug不斷難以保證穩定性，維護成本也極高。ok，改進。

4.有一些數據，量比較大，因此必須存儲在數據庫中訪問(例如日積月累的放行數據，門崗會常常查看)。雖然現有架構作了讀寫分離，可是現有頻繁訪問的數據與一些核心數據揉在一塊兒，這些核心數據的保存必須保證穩定性，另外可能須要提供給其餘應用使用。ok，改進。拆分出主數據，增長多個讀庫，而且讀庫實時同步。

 

後面的改進不只於此，再也不贅述，可是這個過程的核心：架構是須要結合場景持續改進的，沒有一口吃出的大胖子，沒有平白無故的進化。

三.架構要結合場景，切忌過分設計

這裏有一些有趣的經歷，能夠分享。

筆者曾經帶過一個微信端企業號的開發團隊，企業號的模塊拆分是作得挺好的，全部應用能夠單獨拆分獨立設計，只須要繼承微信端的身份驗證便可。這個企業號裏面過往集成的應用來源和分類比較多，因此使用技術棧也較雜，團隊也不斷在作嘗試。前端有用普通jQuery的，有用react的，有用vue的；後端有用.net的，有用java的；數據庫oracle, mysql, sqlserver， 簡直是大雜燴。

其中一次版本發佈，須要新上線一個銀行卡信息修改功能，由一個團隊成員負責迭代，因爲這個成員在其餘項目使用過java的微服務，因此直接就把這一套代碼和架子拷貝過來開發。(筆者也失察，打本身兩耳光，:) )。 這下好，一個簡單的讀銀行卡信息&寫銀行卡信息的應用，微服務的熔斷/負載/網關/粒度拆分等機制都有了。而後發現項目的生產環境，並無這麼多服務器資源支持，而後這個開發人員沒多久直接跑路，倉促接手的技術對這一套架構也並不熟悉，最後簡單的應用模塊不得不延期，新開發人員也在部署時被折磨得滿頭包最後不得不重寫。

因此，並非越複雜越流行的架構就越好，有時候一個簡單的三層架構足以應付的，不必搭配一套雞肋的架子，最後發現食之無肉。

四.架構要結合開發流程

這裏又要再次提起，架構師所建的這一套應用架子/開發體系，要根據團隊成員的能力和迭代方式，因時因地因人取材。文章最初筆者提到了，一些團隊成員甚至只會寫代碼，抑或是來自xx大廠，他的編碼能力/對框架的理解/設計模式等等都無可挑剔，可是因爲大廠的工做細分，對產品的持續集成，總體的生產高可用等並無很強的認識。這個時候架構師不只僅要根據系統的使用場景，也要定義好開發流程，也就是常說的工程化。

• 應用的背後設計是否是要區分爲develop, qa, pre-product, product幾套環境；
• 根據持續集成的方式，使用jenkins等CI工具；
• 使用經常使用的單元測試框架，避免開發人員代碼自測不足的問題；
• 使用自動化的代碼規範檢查工具，發佈和持續集成提交版本前檢查質量(不要依賴於本身編寫的冗長的編碼規範了，那隻會成爲你Review代碼後跟團隊成員爭論的依據)；

架構師不只僅要圈出一個方向，帶領技術團隊前進，還要提供不斷的支持，幫助團隊克服現有的不足和困難。用架構的方式在流程中爲小白提供幫助，咱們不是高高在上的領導者，咱們低頭作事爲開發人員打下手。

 

以上是筆者結合多年的全棧實踐的總結，但願對初級架構獅有所啓發，與老架構獅產生共鳴。