架構師小組交流會：每期選一個時下最熱門的技術話題進行實踐經驗分享。
第二期：本篇文章是對於《來自滴滴、微博、魅族、唯品會、點評關於高可用架構的實踐分享》的續接。
本期參與嘉賓：滴滴技術負責人彭令鵬、魅族系統架構師何偉、唯品會應用架構負責人張廣平、新浪微博技術專家聶永、大衆點評交易平臺技術負責人陳一方、七牛雲首席架構師李道兵。
本文是對此次交流的整理，歡迎探討。
第二輪：話題交流
主持人：大家覺得是需要有統一的技術架構部門，還是不需要有統一技術架構部門，各個業務部門自己獨立往前發展？
唯品會張廣平：如果我們有一個通用的基礎架構，這樣開發的學習成本比較低，學習一套，然後他可以持續的開發。那如果有多套框架的話，對於開發人員學習成本比較高，另外就是運維的成本。其實任何一個系統，它不是一個獨立存在的東西。要上線的話，還需要去做運維。簡單舉個例子，我們開發了一套日誌監控的框架，叫 Mercury，這個框架看起來技術和現有的一些比較流行的東西差不多。比如說用kafka，之類的等等的一系列作業。如果要運維，需要幾百臺機器才能這套系統玩得起來。如果我們各用各的框架，對於公司來說成本非常高，運維上去以後，每個框架都要去建一個運維團隊去運維。剛開始是有這個問題，開發的東西很難推出去，剛開發了基礎組件出一點點問題，然後就被無限地放大，就沒人用了。我剛提到那個重構，我們自己去招聘一個團隊，也是因爲我們的CTO支持，給了我們一個團隊，讓我們去把這個重構做起來。當我們核心的服務一點一點接進去，發現效果非常好，後面接入的團隊越來越多。我們肯定也不能強行的去壓，因爲每個團隊他們都有KPI。我們當時是採取漸進的方式，一個一個模塊去接。
滴滴彭令鵬：我還是傾向於業務架構跟着業務技術部一起走。因爲無論是從百度的經驗，還是在滴滴的感覺來講，我們肯定是需要一些最基礎的架構，像消息隊列、存儲、計算這些，這個可以交給基礎架構去做。但是做業務架構，我覺得還是要非常貼近業務，個人感覺，之前碰到過不少做基礎架構的同學，他們做的架構其實和業務，比如說在延遲，或其他方面的一些需求，其實相差還是很大的，用起來不那麼順手。
魅族何偉：因爲基礎架構其實是大家都認可的，業務架構它一定是跟業務組的，因爲業務的場景，比如原來技術架構開發MQ的框架，它的框架可能MQ正常，技術架構團隊做出來的可能就是，消息的基本特徵能發能接，業務要求是消息到達的時序，消息到達有延遲，它有時候就要求延遲，有時候這個消息必須在這個消息前面有持續的。像這種的話，架構團隊是不瞭解的，還是要重新做。
滴滴彭令鵬：我覺得從整個團隊來講，可能在組建初期，這樣做是可行的。但隨着業務發展，團隊肯定會去招一些新人，但新人其實他對業務會越來越不瞭解。而老人可能會逐漸偏向於做頂層設計，具體落地的時候，到最後新同學會實施的不好，那基本上滿足不了業務需求。像百度網頁搜索部和其他部門原來都是有自己的基礎架構的，在2011年聯合成立了一個專門的基礎架構部，最開始業務部門和架構部門還願意合作，但到2013年以後，基本上就不相往來了。
唯品會張廣平：我們當時成立了一個架構評審委員會，我們在推的同時，也通過委員會去做一些強制要求，比如說每個項目我們都來做評審，如果你不用一些標準的東西，或者不按照一些比較好的方法去解決，我們就不讓他上線。
七牛雲七道兵：如果有基礎架構，其實最擔心的事情，就是基礎架構的東西賣不出去，就是業務部門不買基礎架構部門的賬。如果是各自做的話，就比較擔心效率問題。更多是一些企業前期與後期的策略。
大衆點評陳一方：技術架構其實是跟組織架構走的，或者是跟業務架構走的。基礎架構其實和組織架構相關的。
第三輪：架構師能力提升的建議
主持人：這裏有三個問題，大家挑一個來發表自己的觀點。
1、很多架構師都是從程序員轉過來的，那麼對於一個想成爲架構師的程序員，你有什麼好的建議?
2、不同架構師的在選型上會有不同的做法，有的偏保守，有的偏激進，你的觀點是什麼？爲啥你會做這樣的選擇？
3、在做架構設計時，你最害怕什麼情況？爲什麼？
滴滴彭令鵬：我選程序員轉型。因爲我做一線的工作挺多的。很重要的一點是，我們不能純寫代碼，還要留充足地時間去思考和抽象。因爲我發現很多一線工程師他幹了五六年，換了一家公司，或在一家公司呆了很久總是在寫類似的業務代碼。如果沒有思考，我覺得他的能力還是上不去。第二是我們做一些事情要打破邊界，很多程序員會覺得，這東西不屬於我的，我不去接觸，或者說這個東西c++的，我不熟，我也不管等等，這樣知識面較窄。第三做了架構師以後，還是要貼近業務。而且對於一個程序員轉過來的架構師，需要注意的是不要純看技術，更重要的是貼近業務去落地。第四我們做一個東西，比如做服務治理，你戰略上可以很大，有一個理想目標在那裏，但是具體落地的時候，你每一項戰術要做的非常細，纔有可能做成。整個是一個螺旋迭代的過程。
魅族何偉：我剛纔還是第二個問題，其實前面都很認同，一個是基礎打好，然後就是學習一些業界架構方面的經驗。我補充一點，做程序員，你要找機會來鍛鍊自己，而不是給你安排什麼，你就去做什麼，而是要多思考，敢於跟別人PK。第二個問題架構選型，我覺得沒有必然偏保守或者激進，這個沒有絕對。關鍵業務，我是傾向於偏保守，畢竟是穩定第一，經過驗證的東西，我纔敢用在業務環境上。不太重要的一些業務，成長的新業務，可以去嘗試一些新的技術，適當的做一些激進的嘗試。
微博聶永：第一個問題，我認爲不要在意是不是架構師，不要爲架構而做架構，要結合實際，用心去思考，在思考的時候思維角度要全面一些，然後全身心就去投入所構建的系統中去，很自然的就能把技術做的很深。第二個問題，關於保守還是激進？其實我可能偏於保守型的，我們在做架構或系統的時候，針對外部依賴就要儘可能少依賴，因爲你一旦添加了一項依賴，在後續實踐過程中，每一個環節都有可能會出現問題，造成運維層面的難度增加。第三個問題，在做架構的時候，最害怕的問題就是你所引入的每一個所依賴組件，你沒有認真的去深度理解，這樣到後面出現問題的時候就很麻煩了。
唯品會張廣平：我針對第二個問題。到底是偏保守還是激進，要看一些具體的場景。如果架構師參與到時間比較緊的項目，或者是關鍵的項目，這些項目做改動對生產環境影響比較大，這時候衡量方案一定要謹慎。到底應不應該去做一些改動，而且這些改動給我們帶來的回報是什麼。那麼對於新的項目，類似於重構。如果只是在原地踏步，有可能得不到一些回報。所以我們需要去發揮主觀能動性，比如說發揮一些抽象思維，對現有的系統做一些充分的調研，大膽提出一些自己的方案。當然這個方案需要跟各個團隊去做一些互動，然後去驗證。
大衆點評陳一方：我其實是偏實用的，也不叫保守，也不叫激進。就像產品的理念一樣，少就是美。現在一個系統都很複雜，如果每個人都採取不一樣的策略，或者不一樣的技術戰，其實很難管理，這裏是要求簡單，大家儘量是統一的。然後這個模塊和這個技術的引進來以後，是可維護的。還要對這個系統負責，誰引進來的，誰就要駕馭這個技術戰。這個策略總體稱爲是偏實用的。還要做迭代，加工，調整都有可能的，沒有一下子就能出一個非常好的系統出來，都是慢慢進入技術戰往上加的。技術站的優劣，要根據自己的用戶場景，經營的流量規模來選擇，因爲長期流量規模就決定了你這個系統會有多大的衝擊，將來的瓶頸是什麼。
七牛雲李道兵：關於第一個問題，我覺得首先是提高眼界，其次是刻意練習。提高眼界主要是多看一些書，多參加一些會議，多瞭解一些新興的思路，如何把這些思路融合到你現在的知識體系裏邊去。刻意練習主要是兩塊，如何解決問題和如何評估解決方案的優劣，比如看一個演講，就嘗試先只讀問題部分，不看解決部分，自己嘗試去解決這個問題，再跟演講者提出的方案對比，評估一下優劣。