本文為“技術瑣話” 老司機李豔鵬創作，首發於“GitChat精品課”，獲授權轉載。

我工作十餘年，從負責一個模組，到負責一個產品，再到負責整個支付平臺的架構設計，包括業務架構、產品架構到應用架構，再到技術架構，是一個從點到面逐漸轉型的過程，同樣是個“自相似”的現象，我一開始寫部落格，再到出版《分散式服務架構：原理、設計與實戰》，現在它的下冊《可伸縮服務架構：框架與中介軟體》年後在京東首發，雲時代架構系列書籍已經初具形態，也體現了從小到大的發展過程。

我很想把架構師成長過程總結成獨立的系列書籍，苦於沒有時間，於是，透過 Chat 把工程師向架構師轉型的方方面面，和大家分享，幫助大家從開發向架構師轉型要早作準備，記得早期的鳥兒有蟲吃。

通用的架構方法論

有人說架構是一門藝術，架構的好壞靠的是架構師的經驗和修行，但是近些年來，架構方法論如雨後春雨般的湧現，國際開源組織 Open Group 定義的 TOGAF 是其中一個行業標準的體系架構框架，它能被任何希望開發一個資訊系統體系架構的組織自由使用，結合 TOGAF，我們通常定義架構有幾個層次，這包括業務架構、產品架構、應用架構和技術架構。

業務架構：描述一個企業圍繞一個行業做了哪些業務，例如支付行業的收單、退款、出款、充轉提等能力，這與公司對外和對內定義的產品無關。
產品架構：描述對外和對內定義的可銷售的產品，例如微信的條碼支付、掃碼支付、公眾號支付等。
應用架構：描述提供了哪些系統和服務來實現對外和對內的產品架構，從而支援公司的業務架構，例如微信內部的訂單系統、支付系統、賬務系統和對賬系統等等。
技術架構：通常涉及採用什麼的技術棧，以及各個技術棧之間如何分工和協作的，具體會細分為資料架構檢視、服務化架構檢視、快取架構檢視、訊息架構檢視、安全架構檢視、效能架構師檢視等等。

有了架構方法論，我們通常可以根據架構方法論的指導來設計和規劃架構，而不再依賴於架構師本身的經驗來設計架構，也不會把架構當做藝術來發揮，發揮好的時候設計出來的是好架構，發揮不好的時候設計出來的就是壞架構。於是，按照行之有效的方法論來做架構的規劃和設計，就可最大程度上保證架構設計的合理性，從而保證專案的成功。

對於一個專案我們需要從不同的側面來描述專案的特質，對專案進行規劃，讓專案有條不紊的推動，我們通常依照架構方法論來設計架構，把架構分成不同的方面，這包括業務架構、產品架構、應用架構和技術架構，技術架構又可以細分成多個小的架構檢視，這包括資料架構檢視、服務化架構檢視、快取架構檢視、訊息架構檢視、安全架構檢視、效能架構師檢視等，我們從這些不同的架構和架構檢視來透析複雜的整體專案，架構方法論並不會保證我們100%的來透析完整的專案，而是要抓住專案的核心需求和特色需求，使用架構方法論的各個架構和檢視來透析專案和規劃專案，保證專案不跑偏，健康的進行下去。

通用架構師能力模型

有了架構方法論，我們通常在專案中或多或少的都會根據架構方法論來推進專案，使用架構方法論的這些人就是架構師，架構師會根據架構的種類和檢視具體分為不同的架構師，有業務架構師和技術架構師，技術架構師又分為資料架構師、應用架構師、效能架構師、安全架構師等等，那麼這裡我們給出通用架構師的能力模型，這更偏向於應用架構師。

作為通用架構師應該有眾多的能力，這涉及到方向、戰略、策略、決策、影響力、規劃等。

需求分析

一個通用架構師，首先要能夠進行高效的需求分析，能夠主動與客戶溝通，理解客戶需求，設計通用的業務流程，然後包裝成產品，將落地的產品再輸出給客戶，如果在業務流程上有創新就更加值得稱讚了。

程式設計

大多數架構師都曾經是從工程師成長而來，因此，架構師應該具有程式設計的能力，當然這裡的程式設計能力並不單單指的是編碼的能力，更多的是將業務流程轉化成技術領域的語言，並帶領一個團隊將其落地實現。

線上應急

在網際網路行業裡，多數的系統是對 C 端使用者的，使用者請求量較大，對線上壓力較大，線上系統粗線問題是家常便飯，這就需要一部分應急人員來解決這些線上問題，一個通用的架構師必須具有應急的能力和經驗，要了解應急的流程，緊急應急的目標，要以快速回復系統為己任，把公司的線上事故帶來的影響降低到最低。

技術攻關

在應急過程中或者專案實施過程中，一個最最要的環節是技術攻關，這個環節通常是需要架構師參與的，對於一些技術難點、應急過程中遇到的技術困難，架構師要能發現並解決所負責領域的關鍵難題，透過技術手段來臨時解決或者徹底解決，因此，架構師必須具有技術攻關的能力，例如，對於應急過程中產生 OOM 錯誤，架構師要能分析記憶體模型，找到記憶體溢位的根本原因，並進行解決，《如何在生產環境排查 OutOfMemoryError（OOM）》（）一文記錄了筆者這幾年處理的典型OOM的問題。

架構規劃

能夠使用架構方法論，帶領業務團隊做現狀的架構梳理，以及未來幾年的架構規劃，能夠結合組織結構和團隊人員來定義部門的職責和界定部門之間的職責邊界。

架構師要對所負責的領域具有規劃的能力，要制定規劃的原則和目標，根據原則和目標來實施規劃和落地規劃，同時要引領所負責領域的發展，是所負責領域發展的風向標。

風險控制

通用架構師一定要有風險控制的意識，無論對任何的設計方案要對風險具有嗅探的能力，如果是金融行業，把控資金底線是一項非常核心的要點，另外，系統設計的技術安全性也非常值得重視。在做任何決策之前，一定要評估可能產生的任何風險，並能提出有效的防控風險的方案。

效能最佳化

網際網路專案唯快而不破，效能是網際網路專案的首要目標，因此對效能最佳化、效能容量評估的能力，是必須掌握的。可以參考《分散式服務架構：原理、設計與實戰》的第3章的內容。

掌控方向

架構師在專案開發過程中，一項重要的職責就是掌控專案的方向，一定不能讓小夥伴們做事兒跑偏，我這幾年在做設計評審的過程中，發現很多小夥伴在解決無效的問題，或者不知道在解決什麼問題，這是非常重要的一項職責。

我已經連續做了幾年的技術序列升級的評審，發現一個共通的問題，就是大家做事兒的目的不明確，做一個專案不知道需求是啥，解決一個問題不知道到底問題是啥，說提高了效能，不知道原來效能哪裡差，差到什麼程度，更有甚者不知道用什麼來衡量效能，還有人上來堆砌一堆高大上的技術，比如有些人把高速存取的一共才幾十 K的規則資料放在了 FTP，還有些人非要把交易資料放在 MQ 中，美其名曰用 MQ 保證一致性，追問怎麼保證的，回答說 MQ 保證 AP 模型，所以最近我和人討論最多的就是做架構不要堆砌高大上的技術，要從問題本身出發，遵循目標、原則、方法、閉環的過程。

這裡給大家舉一個真實的案例，對賬單通常是透過 CSV 格式對外提供的，此格式簡介、高效、佔用空間少、網路傳輸快，既適合人類閱讀也適合系統對接。然而，有一天從前場傳來了一個需求，要做 Excel 的對賬單，原因就是 CSV 格式有時候會產生亂碼，產品經理接到這個需求就開始計劃實施實現 Excel 格式的對賬單。

在評審方案的過程中，我首先想到的是要挖掘真實的需求，為什麼有的使用者看到 CVS 格式的對賬單是亂碼的，根據經驗和我對亂碼的理解，如果設計的合理，使用正確的字符集開啟 CSV，是絕對不會產生亂碼的，於是經過詢問，前場人員確認確實有些使用者看到亂碼，經過了解更多的資訊，這些使用者的系統預設使用的不是 UTF-8 字符集，而是 GBK，因此，產生了亂碼。

瞭解到這個原因，那麼解決這個問題最簡單的辦法就是，讓所有的使用者系統都透過 UTF-8 編碼來開啟檔案，這完全可以透過寫 CSV 檔案的 BOM 頭來解決。最終的解決方案是，在沒有上線之前，嚮導使用者選擇正確的 UTF-8 字符集開啟檔案，然後上線一個新版本，寫 BOM 頭讓使用者透過 UTF-8 來開啟 CSV 檔案來避免亂碼。

這個案例裡，架構師透過技術手段掌控了處理使用者問題的方向，避免了透過增加 Excel 格式的對賬檔案來解決亂碼的問題，因為那樣的話就大材小用了，檢視透過增加一個新功能來解決已有的 Bug，其實只是掩蓋了之前的一個 Bug 而已，並沒有直接解決，因此做事情推進的方向性是非常重要的。

這裡給出另外一個案例，在我評審的一個線上應急案例中，由於底層出現問題，導致上層系統出現了髒資料，為了解決這個問題有人提出了將資料的關鍵欄位進行更新，避免資料被這個場景查詢，這是一個典型的用一個錯誤來掩蓋另外一個錯誤的解決方案，哪裡出現了問題我們就應該解決哪裡，而不應該嘗試用一種方法來掩蓋錯誤，掩蓋的方法可能會產生更大更嚴重的問題。這裡，針對髒資料，我們應該果斷的進行清理操作。

我推薦大家使用“目標、原則、方法、產出”的方法論來做事兒，做事兒前需要先確立目標和原則，然後評估各種方法，選擇最合理的方法，做完事情要進行復盤，驗證目標是否達成。關於此方法論請參考《技術人如何修煉內功主題演講》（）一文。

在設立目標的時候，要根據實際情況來設定合理的目標，不能過於偏激，也不能過於簡單，過於偏激難以實現，過於簡單又失去了鬥志，就失去了進步的動力，因此，針對現實，要敢於設定有挑戰的目標，並未目標而奮鬥。

在設立目標的時候，要評估目標實現的價值，一個目標實現了產生100萬的毛利和產生1萬的毛利有本質的區別。

辯論能力

這裡首先給大家舉個真實的案例，我們都知道支付行業除了服務 C 端使用者，還會服務商家，例如，一個商家要使用微信支付，首先需要在商家平臺進行註冊，其他的第三方支付公司亦是如此，註冊的過程通常稱為入網，入網一般會對商戶提供一個 API 介面，用來進行自動化入網。

入網後商戶可以登入商戶平臺進行可介面操作對入網資訊進行自助修改，但是有的商戶嫌棄自助修改太麻煩，於是想要 API 介面進行批次修改入網資訊，這樣問題就來了，入網資訊的批次修改 API 到底放在哪個系統來做，其中一個產品經理認為這個功能是商戶平臺提供的自助入網的功能不夠強大，所以入網資訊的批次修改 API 應該放置在商戶平臺上。

稍微有些技術背景的人都會知道，商戶平臺是一個具有 B/C 架構的專案，不適合對外輸出 API，對外輸出的 API 應該放到自動入網 API 系統，如果真的把一個 API 介面做到了商戶平臺上，那會極大的影響系統的架構合理性，商戶平臺對外開放了 API 這不但不合理，還會有很多的安全問題，這個時候，我們不但要及時組織，更重要的是作為架構師，我們應該如何來說服別人。

架構師一定具有與人辯論的能力，多數的場景下，會有很多人質疑你的方案，質疑你的決策，這個時候並不是靠誰的聲音大來壓倒別人，而是透過一定的方法來說服別人。

首先要持續積累影響力，要讓小夥伴們信任你的方案開始，再逐漸的開始信任你的人，如果小夥伴對你的人認可，那麼你的方案和決策就更容易被人接受。
可以曉之以理、動之以情，說出之所以這類 API 介面不適合在商戶平臺上開發的原因，讓產品經理知道它帶來的架構不合理性，對外開放介面帶來的不安全性，以及由於 API 介面和 B/S 結構的技術棧不同而帶來更多的開發成本。
有的時候，我們透過理論的敘述，很難說服別人，我們通常會找到一些經驗或者歷史資料來證明我們的思路是正確的。有的時候我們會透過類比來說明問題。例如在上面的案例中，我們通常透過對比，來說服對方，因為自動化的入網是透過入網 API 系統來做的，那麼修改入網資訊也應該是由入網 API 系統來做，因為他們維護的是同一類的資訊，只不過一個是資訊的初始化，而另外一個是資訊的修改，這就像我們生一個小孩，我們需要對小孩一直負責到底一樣。

影響力

架構師和工程師的一大不同就是架構師需要進行決策，要做決策必須讓小夥伴們相信你的決策能力，憑什麼小夥伴要讓你評審方案？為什麼小夥伴會聽你的方案？這就需要架構師具有一定的影響力，這能夠幫助你做決策、推動決策落地，因此，要不斷的培養自己的影響力，要能夠對負責領域的複雜問題的進行分析，分析後要判斷事情輕重緩急，判斷技術方案的優缺點，並與小夥伴們分享，讓小夥伴在架構師的帶領下學習和實施專案，營造和諧向上的技術氛圍，也就是具有技術影響力和對團隊的感召力。

架構師除了提高自身的影響力，還要能不斷的識別核心技術人才，對有潛力的小夥伴進行培養，要定期的進行分享技術，營造技術分為，要對小夥伴進行培訓，幫助小夥伴的提高。

決策能力

通用架構師要能參與高層的戰略的討論，並提出建設性的意見或者行之有效的策略，需要能夠從利潤、價效比、投產比的角度來考慮戰略的制定和執行，要能參與和主導所負責的專案的策略和決策的制定，在需要做決策的時候，權衡利弊，果斷給出最適合的方案。

然而，在很多場景下，直接說出你的想法和思路，是很難讓人理解和接受的，因此，我們常常需要制定合理的規則，然後根據制定的規則，讓小夥伴們根據規則自行推匯出正確的方案。

這裡，我們舉例說明，架構師經常碰到需要對某個功能應該劃分到哪個系統的問題，也就是職責邊界的劃分，處於某種內在的利益的考慮，有些是有應該負責這部分的功能的模組不想要，或者不應該負責這部分功能的模組卻想要，這都是很可能的，不管是想要這個功能的模組的負責人還是不想要這個功能的模組負責人都會想出各種理由來支援他們的想法，這個時候，即使我們給出幾種方案，並且明確列出幾種方案的優缺點，我們還是要一一進行決策。在這種場景下，我們需要對我們考慮的利弊進行優先順序排序，在這個時候，我們定義如下特點的優先順序。

資金底線的保證
需求的急迫性
架構合理性

這樣，我們就能很容易根據這個優先順序來確定合理的方案，實際上，確立了這樣的優先順序，並且明確了每種方案的利弊，我們很容易就做出決策，甚至可以讓小夥伴們自行說出決策的內容。

積極主動

多數工程師停留在執行層面，整體架構和模組設計都已經做好了，工程師按照設計做實現即可。而架構師則需要積極主動的承擔更多的職責。

下面給出幾個反例，這些反例都是我評審過的技術序列升級過程中工程師常見的一些問題。

有的小夥伴平時接需求的時候，會顯得很不樂觀，面對需求的第一反應就是這個需求不應該我做，或者這個需求我做不了，並且會給出很多理由來支援做不了或者不該他做，這也實現不了，那也實現不了，有的時候還會擺出一些看似“合理”的技術名詞來證明不可行，我就遇到一些小夥伴做了個批次查詢功能，查詢的內容是進行記憶體模式匹配，平均響應時間在10S以上，小夥伴陳述批次查詢效能就是要低於單量查詢，瞭解詳細資訊後，批次查詢一次最多30條，每一條都是在做記憶體匹配，每個匹配都是納秒級別的，為什麼那麼慢呢？詳細追問是記憶體匹配的資料儲存在 FTP 中導致，這是一種不嚴謹的行為，也是一種推諉行為，會給人以不好的印象，面對需求我們應該積極主動的承接。
在做商戶平臺的過程中，商戶平臺需要查詢多個服務化系統的資料，小夥伴要求各個業務系統必須提供介面，或者構建統一查詢系統才能提供商戶查詢功能，拒絕直接插資料庫，從設計上可以理解直接查資料庫不是最好的模式，但是基於現狀的資源情況，這是最快速的方案。
有很多小夥伴對應急流程不關心，沒有表現出對專案的主人翁的精神。

從點線面體看工程師到架構師的轉型

根據行業共識，工程師向上發展的路徑有兩個，一個是走向管理，朝著技術總監和 CTO 發展，另外一個是朝著技術專家和首席架構師的方向發展，這是人為的把管理和架構的角色割裂開來看的，實際上架構師和技術管理的能力模型沒有明顯的界限，我所在的公司多數使用矩陣制度和專案制，一個事兒需要一個帶頭大哥來負責，帶頭大哥帶領專案一起完成一個事情，這個帶頭大哥可能是一個技術總監，也可能是一個架構師。

因此，我們在談的通用架構師的角色是個廣義的架構師，也就是能夠帶領大家完成一個獨立專案的這樣的一個角色，上面我們學習了通用的架構方法論和通用架構師能力模型，這裡我們來看下工程師如何向通用架構師轉型。

對於技術人員在職位上的晉升，我們通常透過點線面體來類比，這也是從工程師到架構師的晉級過程。

點：能夠獨立負責一個模組的開發。
線：能夠根據設計，同時負責一個專案中多個模組的開發，甚至獨立負責一個專案的開發。
面：在所在領域內，可以負責一個產品的整個研發過程，並對業務和技術要有前瞻性。
體：能夠負責一個產品線的研發過程，並且能夠開拓某個行業。

1-2所描述的能力模型比較符合工程師，而3-4描述的是架構師的能力模型。因此，為了獲得3-4描述的架構師的能力，我們需要積極主動的去按照上面架構師能力模型進行休養，提前做好轉型的準備。

對於3-4所描述的架構能力，我們通常透過深度、廣度和高度上來衡量。

廣度：要有全棧的技術知識，針對所在領域的技術要有全面的瞭解，能夠評估各種技術的優缺點，要能根據優缺點來做技術選型的決策。
深度：要針對所在領域的核心技術有一定的造詣，閱讀過原始碼，針對產生的 Bug 要有能夠迅速定位的能力，或者曾經貢獻過核心程式碼。
高度：能夠理解業務的本質，能夠識別業務的風險，並做出合理的應對，對業務和技術都要具有前瞻性。要理解業務的本質，對業務的特殊性有所把控，要能抽象事務也要能具象事務。要能用技術服務業務，或者推動技術的更新換代，或者推動業務創新，從而直接產生價值。

各個公司對工程師和架構師兩個角色的定義不同，我也經常被 HR 美眉問到工程師和架構師到底有什麼區別，一般公司都要求工程師具有需求分析和程式設計的能力，而架構規劃的能力是架構師特有的，因此工程師要向架構師轉型，一定要學會做架構的規劃，未雨綢繆，要能夠識別出現狀架構中的痛點，提供有效的解決方案，規劃將來的架構解決現狀的痛點。

另外，對於線上應急和技術攻關，架構師並不一定需要親自動手去做，但是在應急和攻關的過程中，架構師應該是要把控方向的，不要讓大家跑偏，要嚴格把控應急和攻關的目標。

對於風險控制和保障效能的能力，無非是一個工程師向架構師轉型的必備知識，作為一個架構師要實施把控專案的風險，要實時保證專案的效能能夠滿足使用者對專案的效能需求。

作為一個工程師，通常是要理解需求，理解架構設計方案，可以自行寫出模組的設計方案，並且根據架構設計和模組設計來實現專案模組，很少要與人研討方案的優略，方案的選型，但是作為架構師這些能力都是要具備的，架構師經常要與人討論方案，挖掘方案的優缺點，最後選擇最合理的方案，因此要想從一個工程師轉變成架構師，必須要培養辯論能力。

掌控方向是一個架構師獨有的必須具備的能力，工程師在接受任務、完成任務的同時，需要多思考為什麼我們要這樣做，甚至為什麼我們要做這件事情，做這件事情的價值是什麼，不做有什麼樣的損失，要試圖掌控事情的方向，才能更早的向架構師轉型。

正確理解架構合理性的地位

我在做架構規劃和把關架構評審的幾年裡，充分理解了架構合理性的定位，通常來說架構合理性保證的是至少未來3年後的業務和技術方向的正確性，然而做現在的事兒或者唯滿足目前的目標為中心，或者完全以目標和盈利為導向的場景下，經常會導致急功近利，建設出來的是空中花園。

即使有一定的進步，也不會有質的飛躍，然而，如果以過程為導向，保證了整體方向的正確性，通常能夠對業務或者技術打下堅實的基礎，待量變積累到一定程度，會導致質的飛躍，這就是架構合理性的實際意義。

由於架構合理性的特殊定位，通常我將架構師團隊比喻成發改委，發改委綜合研究擬訂經濟和社會發展政策，進行總量平衡，指導總體經濟體制改革的宏觀調控部門，而架構師團隊保證組織前進的方向的正確性，總體調控業務和技術架構的方向性，有時我還會將架構師團隊比喻成政協，起著業務和技術方向的監督作用，以至於業務和技術的方向不會跑偏。

我們在實際的架構規劃和實施的過程中，根據架構合理性的定位，我們通常認為架構合理性的任務是重要不緊急的事情，在金融的行業裡，我們通常這樣給任務做如下的緊急程度的排序。

資金底線的保證
需求的急迫性
架構合理性

我們看到架構合理性並不是優先順序最高的考慮要素，但是是最重要的事兒，所以在短期的範圍內，面對資金底線和需求的急迫性等，架構合理性是可以妥協的，長期情況下是不能有任何妥協的。

通用架構師如何修煉內功

作為網際網路的通用架構師，是有別於某一個領域的技術專家，通用架構師不是專業與資料庫運維的 DBA，也不是專業與安全的安全專家，也不是專業的效能測試專家，因此，對於那些專業的 DBA 工具、安全測試工具、效能測試工具可能都不會特別熟悉，但是，他們應該瞭解其原理，有了相關的問題，應該能夠提供方法和方法論，組織相關的人員進行排查，因此，通用架構師需要修煉的是技術內功。

請參考 Chat 《技術人如何修煉內功》（）。

通用架構師的社交軟技能

權衡和博弈

架構師在多個相似的方案中如何應對各種博弈？又如何權衡利弊呢？我們需要先制定原則和規則，對利弊定義優先順序，例如前面多次說道，在金融的行業裡，我們通常對需求做如下的優先順序的排序。

資金底線的保證
需求的急迫性
架構合理性

根據這些原則，我們對多個方案進行權衡利弊，答案自然就清晰了。

抓住要點

做事情要定要抓住要點，古語有釜底抽薪，擒賊先擒王，打蛇打七寸，都是一個道理，就是做事兒要做最正確的事兒，要識別現在的痛點，針對痛點給予致命的一擊，一招解決問題。

前面關於為對賬系統提供 Excel 檔案做對賬的案例也說明了這一點，我們要抓住使用者真實的需求，直接解決使用者的痛點，而不是用一個新需求來掩蓋之前的問題。

社交軟技能

雖然作為架構師，並不應該用技術總監一類的管理人員的要求來衡量，但是，我們為了達成一個目標，或者完成一個專案，我們需要發動多個小夥伴，需要與多個部門溝通，需要與領導溝通和討價還價，因此，架構師要有基本的社交軟能力。

這裡我舉幾個例子，都是架構師應該具備的日常社交能力。

如果你定了會議室，你的領導要佔用，那麼無論你的會議有多重要，你一定要把會議室讓給領導，因為領導的事兒遠比你的事兒更重要，甚至領導開會可能是在為你解決問題。
小夥伴們再加班，領導過來視察，一定要拍照併發到朋友圈，這時你可能說這是拍馬屁，錯，這是在營造良好的氛圍。

強力推動

有些事情做著做著就沒了思路，沒法繼續推動，要不就是因為沒人，要不就是因為沒有方案，這個時候教給大家一個萬能的解法，沒人的時候先做方案，沒方案的時候先安排人，在探討方案的過程中可能會發現事情越來越清晰，也越來越簡單，會增加小夥伴們的自信心，慢慢的問題可能就迎刃而解，在探討的過程中要見縫插針，只要有一絲希望的思路都要繼續討論或者評估。

深入思考

要多觀察，最好能夠擴大參照系，站在較高的層次向下看可能會有驚人的收穫，或者跳出圈子，在圈外來看圈內，或者站在別人的角度上看自己，這樣會得到更多的客觀的資訊，有了足夠的資訊，要善於謀劃，以客觀資訊為基礎，制定合理有效的方案，才能解決問題。

這裡給出幾個深入思考的例子。

曾經由於 Fastjson 的安全漏洞問題，需要全面升級 Fastjson 的版本，仔細思考，如果部署一套網頁應用防火牆（WAF）是不是可以解決一部分的問題，至少可以臨時堵住很多安全漏洞，因此碰到一個問題，我們不能只站在自己的角度來看待問題，要擴大參照系來看問題，問題可能就迎刃而解。
要開發某個收入計算的批處理服務，收入計算依賴關係模型比較大，並且動態更新，小夥伴把整個關係模型維護在批處理機器的記憶體中，透過訊息佇列接受更新並且維護最新的記憶體模型，第二個月的第1天計算上一個月的收入情況，這是一個未經過思考的方案，場景是典型的批處理方案，但是使用了訊息佇列和節點記憶體維護實時的關係模型，浪費資源不說，穩定性還差，機器重啟等都會導致模型的重新載入等等，對這類方案一定要深入思考，找到問題的本質，解決問題的痛點，而不是隨意的堆砌高大上的技術。
把大約幾 M 大小的匹配規則放到了 FTP，並使用 ZK 通知更新，為了使用技術而使用技術。
某個公司評估的方案，從私有云同步資料到公有云，要使用 Sqoop，Sqoop其實只是一個資料提取工具，並不是一個公網資料同步工具，方案沒有經過詳細思考。切記，不要為了使用技術而使用技術。

管理模式

架構師要理解和適應各種管理的方法，通常有傳統的多層企業管理、扁平化的企業管理、矩陣式管理，一般情況下，扁平化管理的效率較高，溝通成本較低，適合初創企業，在這種管理模式下，架構師也比較容易發揮其價值。但是在多層的企業管理和矩陣式管理中，由於層次較多，溝通成本增加，一項事情從上面傳達到下面要經歷多箇中層領導，中層領導需要一層一層往下傳達。

傳達過程其實也是一種成本，對於每個任務和專案需要溝通確認達成一致，才能保證專案傳達的方向的正確性，由於層次多了，溝通成本增加，再由於中層領導區分戰略思維，或者有戰略思維沒有落地經驗，就會導致底層的人有可能沒有完全獲得上層人交給的任務，在下面就有可能“憋死了”，這些都是管理上的通病，架構師必須理解所處的環境，已經產生的問題，針對這些問題來提供合理有效的解決方案，畢竟組織架構也屬於架構的一部分。

從點線面體談開發到架構師的轉型

相關文章