架構組織形式的討論，以及架構師之路的建議

架構師小組交流會：每期選一個時下最熱門的技術話題進行實踐經驗分享。
第二期：本篇文章是對於《來自滴滴、微博、魅族、惟品會、點評關於全鏈路壓測等問題實踐分享》的續接。
參與嘉賓：滴滴技術負責人彭令鵬、魅族系統架構師何偉、惟品會應用架構負責人張廣平、新浪微博技術專家聶永、大衆點評交易平臺技術負責人陳一方、七牛雲首席架構師李道兵。
本文是對這次交流的整理，歡迎探討。

第二輪：話題交流
主持人：你們以爲是須要有統一的技術架構部門，仍是不須要有統一技術架構部門，各個業務部門本身獨立往前發展？

惟品會張廣平：若是咱們有一個通用的基礎架構，這樣開發的學習成本比較低，學習一套，而後他能夠持續的開發。那若是有多套框架的話，對於開發人員學習成本比較高，另外就是運維的成本。其實任何一個系統，它不是一個獨立存在的東西。要上線的話，還須要去作運維。簡單舉個例子，咱們開發了一套日誌監控的框架，叫 Mercury，這個框架看起來技術和現有的一些比較流行的東西差很少。好比說用kafka，之類的等等的一系列做業。若是要運維，須要幾百臺機器才能這套系統玩得起來。若是咱們各用各的框架，對於公司來講成本很是高，運維上去之後，每一個框架都要去建一個運維團隊去運維。剛開始是有這個問題，開發的東西很難推出去，剛開發了基礎組件出一點點問題，而後就被無限地放大，就沒人用了。我剛提到那個重構，咱們本身去招聘一個團隊，也是由於咱們的CTO支持，給了咱們一個團隊，讓咱們去把這個重構作起來。當咱們核心的服務一點一點接進去，發現效果很是好，後面接入的團隊愈來愈多。咱們確定也不能強行的去壓，由於每一個團隊他們都有KPI。咱們當時是採起漸進的方式，一個一個模塊去接。

 

滴滴彭令鵬：我仍是傾向於業務架構跟着業務技術部一塊兒走。由於不管是從百度的經驗，仍是在滴滴的感受來說，咱們確定是須要一些最基礎的架構，像消息隊列、存儲、計算這些，這個能夠交給基礎架構去作。可是作業務架構，我以爲仍是要很是貼近業務，我的感受，以前碰到過很多作基礎架構的同窗，他們作的架構其實和業務，好比說在延遲，或其餘方面的一些需求，其實相差仍是很大的，用起來不那麼順手。

 

魅族何偉：由於基礎架構實際上是你們都承認的，業務架構它必定是跟業務組的，由於業務的場景，好比原來技術架構開發MQ的框架，它的框架可能MQ正常，技術架構團隊作出來的可能就是，消息的基本特徵能發能接，業務要求是消息到達的時序，消息到達有延遲，它有時候就要求延遲，有時候這個消息必須在這個消息前面有持續的。像這種的話，架構團隊是不瞭解的，仍是要從新作。

 

滴滴彭令鵬：我以爲從整個團隊來說，可能在組建初期，這樣作是可行的。但隨着業務發展，團隊確定會去招一些新人，但新人其實他對業務會愈來愈不瞭解。而老人可能會逐漸偏向於作頂層設計，具體落地的時候，到最後新同窗會實施的很差，那基本上知足不了業務需求。像百度網頁搜索部和其餘部門原來都是有本身的基礎架構的，在2011年聯合成立了一個專門的基礎架構部，最開始業務部門和架構部門還願意合做，但到2013年之後，基本上就不相往來了。

 

惟品會張廣平：咱們當時成立了一個架構評審委員會，咱們在推的同時，也經過委員會去作一些強制要求，好比說每一個項目咱們都來作評審，若是你不用一些標準的東西，或者不按照一些比較好的方法去解決，咱們就不讓他上線。

 

七牛雲七道兵：若是有基礎架構，其實最擔憂的事情，就是基礎架構的東西賣不出去，就是業務部門不買基礎架構部門的帳。若是是各自作的話，就比較擔憂效率問題。更可能是一些企業前期與後期的策略。

 

大衆點評陳一方：技術架構實際上是跟組織架構走的，或者是跟業務架構走的。基礎架構其實和組織架構相關的。

 

第三輪：架構師能力提高的建議

主持人：這裏有三個問題，你們挑一個來發表本身的觀點。

一、不少架構師都是從程序員轉過來的，那麼對於一個想成爲架構師的程序員，你有什麼好的建議?

二、不一樣架構師的在選型上會有不一樣的作法，有的偏保守，有的偏激進，你的觀點是什麼？爲啥你會作這樣的選擇？

三、在作架構設計時，你最懼怕什麼狀況？爲何？

 

滴滴彭令鵬：我選程序員轉型。由於我作一線的工做挺多的。很重要的一點是，咱們不能純寫代碼，還要留充足地時間去思考和抽象。由於我發現不少一線工程師他幹了五六年，換了一家公司，或在一家公司呆了好久老是在寫相似的業務代碼。若是沒有思考，我以爲他的能力仍是上不去。第二是咱們作一些事情要打破邊界，不少程序員會以爲，這東西不屬於個人，我不去接觸，或者說這個東西c++的，我不熟，我也無論等等，這樣知識面較窄。第三作了架構師之後，仍是要貼近業務。並且對於一個程序員轉過來的架構師，須要注意的是不要純看技術，更重要的是貼近業務去落地。第四咱們作一個東西，好比作服務治理，你戰略上能夠很大，有一個理想目標在那裏，可是具體落地的時候，你每一項戰術要作的很是細，纔有可能作成。整個是一個螺旋迭代的過程。

 

魅族何偉：我剛纔仍是第二個問題，其實前面都很認同，一個是基礎打好，而後就是學習一些業界架構方面的經驗。我補充一點，作程序員，你要找機會來鍛鍊本身，而不是給你安排什麼，你就去作什麼，而是要多思考，勇於跟別人PK。第二個問題架構選型，我以爲沒有必然偏保守或者激進，這個沒有絕對。關鍵業務，我是傾向於偏保守，畢竟是穩定第一，通過驗證的東西，我纔敢用在業務環境上。不過重要的一些業務，成長的新業務，能夠去嘗試一些新的技術，適當的作一些激進的嘗試。

 

微博聶永：第一個問題，我認爲不要在乎是否是架構師，不要爲架構而作架構，要結合實際，用心去思考，在思考的時候思惟角度要全面一些，而後全身心就去投入所構建的系統中去，很天然的就能把技術作的很深。第二個問題，關於保守仍是激進？其實我可能偏於保守型的，咱們在作架構或系統的時候，針對外部依賴就要儘量少依賴，由於你一旦添加了一項依賴，在後續實踐過程當中，每個環節都有可能會出現問題，形成運維層面的難度增長。第三個問題，在作架構的時候，最懼怕的問題就是你所引入的每個所依賴組件，你沒有認真的去深度理解，這樣到後面出現問題的時候就很麻煩了。

 

惟品會張廣平：我針對第二個問題。究竟是偏保守仍是激進，要看一些具體的場景。若是架構師參與到時間比較緊的項目，或者是關鍵的項目，這些項目作改動對生產環境影響比較大，這時候衡量方案必定要謹慎。到底應不該該去作一些改動，並且這些改動給咱們帶來的回報是什麼。那麼對於新的項目，相似於重構。若是隻是在原地踏步，有可能得不到一些回報。因此咱們須要去發揮主觀能動性，好比說發揮一些抽象思惟，對現有的系統作一些充分的調研，大膽提出一些本身的方案。固然這個方案須要跟各個團隊去作一些互動，而後去驗證。

 

大衆點評陳一方：我實際上是偏實用的，也不叫保守，也不叫激進。就像產品的理念同樣，少就是美。如今一個系統都很複雜，若是每一個人都採起不同的策略，或者不同的技術戰，其實很難管理，這裏是要求簡單，你們儘可能是統一的。而後這個模塊和這個技術的引進來之後，是可維護的。還要對這個系統負責，誰引進來的，誰就要駕馭這個技術戰。這個策略整體稱爲是偏實用的。還要作迭代，加工，調整都有可能的，沒有一會兒就能出一個很是好的系統出來，都是慢慢進入技術戰往上加的。技術站的優劣，要根據本身的用戶場景，經營的流量規模來選擇，由於長期流量規模就決定了你這個系統會有多大的衝擊，未來的瓶頸是什麼。

 

七牛雲李道兵：關於第一個問題，我以爲首先是提升眼界，其次是刻意練習。提升眼界主要是多看一些書，多參加一些會議，多瞭解一些新興的思路，如何把這些思路融合到你如今的知識體系裏邊去。刻意練習主要是兩塊，如何解決問題和如何評估解決方案的優劣，好比看一個演講，就嘗試先只讀問題部分，不看解決部分，本身嘗試去解決這個問題，再跟演講者提出的方案對比，評估一下優劣。