確保系統(tǒng)的架構和設計可以隨著業(yè)務的發(fā)展而擴展，需要在'業(yè)務需要'發(fā)生之前就想好，遠在業(yè)務部門的預測超過平臺的容量之前，就已經(jīng)對如何擴展系統(tǒng)深思熟慮了。 軟件的整個生命周期中，開發(fā)交付其實只是一小部分，后期的需求變更、維護升級、重構優(yōu)化才是主旋律。那么多考慮軟件的擴展性和未來預期是很有必要的，作為架構師至少看得到半年后的規(guī)模擴展吧？

負責各項標準、規(guī)范、流程的設定和推行。這是架構團隊的一個重要職能，也是最容易被忽視的。技術手段并不是所有的問題的最佳解決方案，很多場景通過推行標準規(guī)范就可以達到不錯的預期效果。

比如編碼規(guī)范，可以通過投入大量人力來開發(fā)IDE/代碼庫的插件進行代碼規(guī)范的自動檢查，再需要不斷的測試來驗證這個插件的可靠性。通過編程考試或者平時的review來強化這一規(guī)范的落地，再加上編程規(guī)范的不斷宣導可以達到至少八成的效果，何樂而不為，最后那兩成效果就放到公司真到一定的級別了考慮技術實吧。再比如架構組研發(fā)了統(tǒng)一的基礎日志組件，可以規(guī)范日志格式、掩碼敏感信息、自動截取/壓縮超長日志報文等功能，這種組件就應該作為標準全員推廣。

在參與業(yè)務迭代的過程中，能夠抽絲剝繭(拆解)，發(fā)現(xiàn)需求、編碼、測試、發(fā)布等環(huán)節(jié)中的痛點、共性點或未來瓶頸點等進行抽象、實現(xiàn)并最終推廣全員。在代碼層面也適用，拆解交織繁雜的代碼邏輯，抽象出基礎公共模塊。都是架構團隊的基本技能。

舉例來說，架構師經(jīng)常會參加各種各樣的評審，對那些常見的review comments，五花八門的自造輪子，一旦發(fā)現(xiàn)就要有這種敏感度需要制定標準規(guī)范或者研發(fā)統(tǒng)一的組件了。

架構師需要足夠的技術寬度，從軟件到硬件，從語言到操作系統(tǒng)，從編碼到測試，從運維到安全，從擁抱開源到自造輪子都要有所涉獵。有個比喻，說架構師需要具備某種上帝視角，來俯視軟件產(chǎn)品的誕生、成長、重構整個生命過程。而且架構師要有空杯心態(tài)，若學習的技術越多，就覺得自己的水平越高，那基本不會是一個合格的架構師；實際應該是越學習覺得自己不懂的越多。

另外，特別要有面對疑難雜癥的自信和能力，為業(yè)務團隊提供強力的技術輸出。因為疑難雜癥的最后一關就只有架構團隊。

架構團隊絕對不是偏安一角寫寫基礎組件，既然要制定標準，推行規(guī)范，那就必須與其他團隊進行協(xié)作，需要征得他們的合作態(tài)度，才能順暢的推行，這個靠架構團隊在技術和業(yè)務上的影響力來驅(qū)動協(xié)調(diào)基本可以辦到。但在某些情況下，需要一些強制的手段，比如設計文檔的強制評審，那就必須賦權給架構團隊一定的權力，或者在一些矩陣型組織里架構師就是擁有技術的絕對權威，這個就是領導力。

技術的存在就是為業(yè)務服務的，脫離業(yè)務的架構都是耍流氓，99%的情況下這句話都沒毛病。有些技術人有嚴重的重技術輕業(yè)務思想，這種人除非真的是鉆研技術的一把好手，可能不善言談不善溝通（筆者本人是可以接受的），但是架構團隊里這種人不能多。后文我們會詳細討論下架構團隊和業(yè)務團隊的協(xié)作問題。

架構團隊在IT內(nèi)部必須是第一生產(chǎn)力，不管是單兵作戰(zhàn)還是團戰(zhàn)能力。除了過硬的基本功外，不斷的學習和尋求技術上的突破，是貫穿架構團隊始終的一個Object。前人已經(jīng)累計了很多經(jīng)典優(yōu)秀的平臺、框架或思想作為傳承，我們可以繼承但絕不能守舊。

在學術研究中，“創(chuàng)新”一詞用來表示團隊有增加值的產(chǎn)出。而有些創(chuàng)新調(diào)研項目很多時候并不會有實際的產(chǎn)出，甚至更糟糕些，會產(chǎn)生許多沉沒成本，但這都不是阻礙創(chuàng)新的借口。創(chuàng)新是架構團隊延續(xù)生命力的最佳營養(yǎng)品和必要條件?？梢韵胂鬀]有創(chuàng)新突破，架構團隊完全可以就地解散。

架構團隊的處世之道

《架構即未來》《架構真經(jīng)》兩本經(jīng)典架構書里都對架構的原則展開了很多，但都是偏向技術層面的。這里我要另辟蹊徑，說的不只是架構本身的原則，還有架構團隊如何玩得轉的原則，跟上文架構團隊的定位是戚戚相關的：

1. 可抽象的有基礎組件面相的實現(xiàn)盡量由架構統(tǒng)一實現(xiàn)，然后推動各系統(tǒng)使用通用的基礎框架，而不是每個系統(tǒng)寫。比如加解密，比如HTTP客戶端，并不是所有人對加密的填充、編碼、提供者都有清晰的認識，也并不是所有人對HTTP客戶端里的超時時間、DEFAULT_MAX_PER_ROUTE、SSL配置等都了解，專業(yè)的事情交給相對更加專業(yè)的人去實現(xiàn)。

   
   

2. 《架構即未來》里提到一條“要使用成熟的技術”，個人延伸一下：不僅如此還要使用盡量統(tǒng)一的技術，盡量統(tǒng)一的代碼層級結構（起碼有一些約定俗成的層級）。有人用Gson, fastjson，jackson的比比皆是，hibernate/mybatis也是各有所好。都是成熟的技術，但是不統(tǒng)一，導致了不管是矩陣式還是敏捷式團隊，同一個人維護不同系統(tǒng)時，必然會有一些不適應，需要思維的跳躍，無形的增加很多非必要成本；再者不同技術的引入可能會增加更多的BUG或管控風險和排障的難度。

   
   

   常見的代碼層級結構 controller->business->service->dao，在一些人的項目里 business變成了handler, service變成了proxy，怎么都會讓人無所適從吧？

   
   

3. 微服務體系內(nèi)的單體系統(tǒng)必須做好自我保護，這是架構團隊理應對IT產(chǎn)品做出的承諾。服務提供方根據(jù)需求說明設計并承諾了一個服務接口定義，如果調(diào)用方只管調(diào)用服務方只管實現(xiàn)，一個不慎就會把接口設計成一顆雷。

   
   

   比如會員系統(tǒng)提供用戶基本信息的查詢接口，這個接口提供的用戶信息“基本”的邊界在哪里，單表查詢也就罷了，如果需要多表連接查詢呢？有些人喜歡把這個接口做的大而全，很靈活，比如在最基礎的用戶信息之上，會附加一些其他字段如QQ號，工作單位，年收入等等算不上基本信息的信息，只要調(diào)用方多傳入一些參數(shù)即可。確實感覺靈活了，但為此服務方不得不做各種的入?yún)⑴袛嗪蚐QL拼接，最差的情況可能需要關聯(lián)用戶的所有相關表，性能差到冰點不用說，對系統(tǒng)本身的吞吐量和并發(fā)能力都會有特別大的影響。這就是系統(tǒng)沒有自我保護好。因為并不是說系統(tǒng)有什么BUG， 但是因為這個靈活度引入了極大的性能隱患。

   
   

   再比如用戶列表的查詢，服務使用方傳入?yún)?shù)作為WHERE條件進行過濾，如果使用方什么都不傳，這個查詢接口基本等同于全表查詢的脫庫了。這時候必掛無疑，那么是不是應該加上分頁，或者最大結果集的限定條件進行自我保護呢？

   
   

4. 架構團隊的任何框架、組件級別的需求，都應該做好充分調(diào)研，不能閉門造車自己臆想需求。技術人很少能做到喬幫主似的，對方不知道自己想要什么由我來告訴你應該用什么；再者如果臆想的實現(xiàn)最終發(fā)現(xiàn)并不適用又耗費了大量成本，或多或少總會被別的團隊看輕吧，身為架構師如何能忍？而且把需求調(diào)研溝通清楚，未來推廣也會得到大家的支持，很簡單，因為需求是大家一起提出來的。

   
   

5. 任何的標準規(guī)范的推行、框架組件的立項、實現(xiàn)和發(fā)布需要獲得高層的充分授權，也需要與重要干系人（比如團隊或職能部門負責人）提前溝通好，減少推動阻力，獲得推行計劃的承諾。比如為了線上系統(tǒng)的監(jiān)控和排障考慮，需要有健康檢查、規(guī)范的日志格式等，這些業(yè)務需求之外的任務勢必會增加業(yè)務團隊的負擔，如果沒有從上至下的強制性推動，很難有實際進展。架構團隊萬勿把自身置為其他團隊的對立面。

   
   

6. 在迭代周期內(nèi)的重要環(huán)節(jié)都需要有架構團隊(或架構評審委員會,后文會詳說)的深度參與，包括需求調(diào)研，接口/數(shù)據(jù)庫設計評審，代碼評審，上線評審等。這個對于創(chuàng)業(yè)公司起步階段特別有益，因為在規(guī)范和標準沒有在IT內(nèi)部形成一種文化驅(qū)動的高度，同一個事情被不同的人做出來完全是千人千面，那對于一個組織來說，這種不可控是很危險的。

   
   

   特別注意，這些參與絕對不能以俯視批判挑毛病的角度展開，而應該以合作共贏建議的方式展開。當然如果是無法妥協(xié)的雙方起沖突的問題必須通過授權來強制修正。

   
   

7. 《架構及未來》把監(jiān)控設計放在15條原則的第4條，它也是筆者推崇的一個重要原則。監(jiān)控可以把我們整個系統(tǒng)的健康度清晰的展示出來，兩眼一抹黑只是另一種形式的掩耳盜鈴。監(jiān)控的顆粒度細化到什么程度需要視團隊成熟度有所不同，不在本文討論范圍。重要的是，監(jiān)控設計應該在系統(tǒng)的初期概要設計期間作為非功能性需求就考慮進去。

   
   

   再做個提醒，監(jiān)控可以視作運維工作的一部分，所以在前期做架構設計的時候，一些運維工作也應該記錄Involve進來。文件傳輸?shù)降走x擇FTP還是接口傳輸，有沒有考慮運維帶寬、斷點續(xù)傳、CDN等問題呢？

   
   

8. 盡量通過工程化來替代人工。工程化就是Engineering，軟件工程化是個比較抽象的概念，就是把軟件按照工程的方式進行開發(fā)維護。這里我們說的工程化可以簡單理解成工具化，自動化的動手文化。當然這里的“動手”不是打架，而是敲代碼，Just show me the code。我們的自動化運維、實時監(jiān)控告警、自動化發(fā)布、智能排障，都是工程化手段來解放人力。這也是驅(qū)使團隊不斷進步的一種方式，不能陷在一些重復勞動的舒適區(qū)里，要不斷的想辦法改進工作效率和質(zhì)量。

   
   

9. 架構團隊出品的任何產(chǎn)品、流程必須建立最嚴格的標準，比如代碼質(zhì)量、性能指標、監(jiān)控指標、高可用性、可擴展性等。在一個大的組織架構里建立信任是個很慢的過程，但是失去信任卻可能是瞬間的?！凹軜嫵銎?，必屬精品”應該是架構團隊的一塊金字招牌，必須保護好。Besides, 架構團隊要有比較優(yōu)秀的宣傳能力，能夠把自己的產(chǎn)品包裝成一個高附加值的優(yōu)秀作品，好像你不用就會懊惱一輩子似的，當然這一切都是必須是真實的不能盲目夸大。因為筆者是實實在在看過不少架構師撰寫的產(chǎn)品發(fā)布郵件，寫的不痛不癢，平平淡淡，完全激不起想要試用一下的沖動，還何談推廣。

   
   

10. 線上系統(tǒng)特別注意驚群效應的影響。比如緩存失效后，如何解決驚群效應帶來的數(shù)據(jù)庫或者微服務化鏈路尾端服務的壓力驟增的問題。這個是技術問題。比如秒殺場景下會有平時百倍千倍萬倍的流量打進來，服務器資源會被瞬間消耗殆盡導致崩潰和癱瘓，這就不僅僅是技術問題了，還有與前線業(yè)務方協(xié)調(diào)溝通的問題，這種活動必須提前通知到IT。

架構評審委員會ARC

七拼八湊好不容易整理了一個個人還算滿意的定義：架構評審委員會Architect Review Committee作為IT的一個治理監(jiān)管機構，有權力確保IT運轉在整個架構生態(tài)內(nèi)保持一致，提高IT的產(chǎn)品質(zhì)量，并最終與公司的目標、戰(zhàn)略達成一致。

那為什么要有ARC？是否必要呢？那是必然的。上圖中歸納的5大塊：技術、流程、標準、質(zhì)量和創(chuàng)新都在ARC的轄內(nèi)，且ARC有絕對的話語權提供決策結果，另外ARC也是捏合架構團隊（落地）、PMO（項目管理辦公室）和業(yè)務團隊的關鍵機構。

不能再搞笑的是筆者竟然先看到了微軟2012年的一篇題為Should We Kill The Architecture Review Board?>的文章...WTF...

我簡單給大家歸納一下文中表達的意思：按照COBIT標準IT的治理體系應該有三個委員會：架構Arch委員會、策略Strategy委員會和指導Steering委員會 ，而架構委員會只對項目工程有話語權，指導委員會卻對IT投資、預算和交付等有話語權，一句話就是管錢袋子的定規(guī)則，架構委員會干不過指導委員會。既然架構委員會說了不算那就不要了，成立一個CIO牽頭的說了算的IT治理委員會，來完成滿足COBIT標準的事情。標題說的那么嚇人說Kill掉，其實也就是因為微軟里的ARB說了不算，對于決策權這個在筆者的定義里已經(jīng)標明了。

咱們中小型公司沒有也不需要微軟那么大的標準體系，當然不關心那么多道道，三者合一就叫ARC來行使所有IT治理框架需要的所有職能。

創(chuàng)業(yè)公司如果有如下困擾，并開始越來越明顯的影響到IT正常的運作，那么貴公司應該考慮成立ARC：

• 軟件產(chǎn)品的質(zhì)量不可控，時常發(fā)生缺陷Escapse到線上生產(chǎn)環(huán)境的事件；

• 職能團隊、業(yè)務團隊、項目團隊之間各自為戰(zhàn)，沒有統(tǒng)一的規(guī)范，代碼、接口、數(shù)據(jù)庫千變?nèi)f化，比如那些三無項目：無注釋無文檔無單元測試；

• 有各種各樣的阻力或者痼疾導致無法推動持續(xù)交付/持續(xù)部署的進行；
  

• 研發(fā)團隊與測試團隊之間脫節(jié)，比如研發(fā)不自測就提交測試，測試團隊在需求階段未被拉入，導致測試案例缺失等；

• IT產(chǎn)品整體在架構、治理方面沒有人或者只有CTO一人負責，導致IT團隊對產(chǎn)品的遠期路線線缺乏足夠的認識，僅僅滿足于實現(xiàn)業(yè)務功能而已；

• 公司已經(jīng)出具規(guī)模了，但非功能性需求還從來沒有被正式提出來過，性能、安全等。

1. 提高軟件產(chǎn)品的質(zhì)量

2. 規(guī)劃，設計和實施IT基礎設施和應用程序健壯的、可擴展的、可靠安全的架構

3. 定義架構設計的標準，政策和總體原則

4. 建立和推廣優(yōu)秀架構設計的最佳實踐

5. 創(chuàng)建架構的路線圖：持續(xù)交付、灰度發(fā)布、服務治理、智能監(jiān)控等等

6. 負責軟件產(chǎn)品在各個過程環(huán)節(jié)的評審，包括但不限于可行性、需求、接口、數(shù)據(jù)庫、生產(chǎn)發(fā)布等的評審

7. 保持對新技術、新框架、新思想的敏感度和足夠的深入度，方能從容應對未來可能的升級

8. 必須保證擁有或者領導權或者充分的授權

9. 驅(qū)動IT產(chǎn)品的創(chuàng)新和升級，補齊短板，但是要做好與常規(guī)任務的權衡

1. 嚴格堅持統(tǒng)一的評審標準，堅決不能存在雙標情況，否則會降低ARC的權威性；

   
   

2. 確保ARC過程得到足夠的尊重，且ARC一旦產(chǎn)生結論則被視為最終決定。若最終評審結果得不到修正，浪費大家的時間，ARC失去公信力，標準規(guī)范也就失去了意義。

   
   

3. 不能以任何理由，比如常見的項目周期緊就不要評審了之類的借口，隨隨便便繞開ARC過程。一旦開了頭就會有其他團隊的效仿并繞開，最終ARC的價值就會不斷被迅速削弱。

   
   

4. ARC組織內(nèi)必須固定一部分永久性的委員，可以是有話語權有地位的領導（CTO，總監(jiān)，VP），可以是專業(yè)或技術上有威望的專家（架構師，業(yè)務負責人等），這部分的委員是保證ARC流程是可以容易下達傳導的。其他再配置一些某些專長的候選人作為輪換委員，作為ARC過程的補充力量，畢竟ARC組織的人數(shù)相比整個IT組織是遠不夠用的。

   發(fā)生如下情況說明成員需要調(diào)整了：

   a. 時不時的發(fā)生ARC成員之間的意見不一致, 總有一方要被踢出去，保證內(nèi)部的絕對統(tǒng)一；

   b. 發(fā)現(xiàn)成員有濫用權力、刁難、憑個人好惡等違反公司利益的方式做事，必須剔除并作為長期關注對象，以防做出其他對公司有損害的事情；

   c. ARC過程經(jīng)常被合理挑戰(zhàn)，而且挑戰(zhàn)的結果是對的，這個人可以考慮被培養(yǎng)并吸納；

   
   

5. ARC的大部分活動實際上對于每個成員來說是一種額外的工作，在保證自己日常工作的情況下還要隨時出席各種的ARC會議，這對ARC成員的日常工作規(guī)劃是個考驗，所以ARC過程和會議都要盡可能的準備充分和直接了當。比如代碼接口評審的代碼必須提前準備好演示IDE環(huán)境，數(shù)據(jù)庫評審提前準備好PDM, 會議過程要足夠的FOCUS，不能太發(fā)散導致會議時間過長。

   
   

6. 某些時候不得不在ARC的權威性和業(yè)務排期之間做選擇的時候，一定要拋給決策高層(比如CTO)來做出決定，ARC不能站出來當'惡人'。反過來，如果ARC對業(yè)務團隊的資源占用經(jīng)常被抱怨，那必須考慮重新調(diào)整輕量化ARC的過程了。

終于寫完了，基本都是大段大段的文字，配圖都不好配，確實不如貼代碼來的舒爽，可能大家會看的比較累。我就再總結一下，其實主要就說了一下架構團隊應該如何以及如何更好的自處或他處，IT管理者如何使用好架構團隊這把尖刀的事情。論點太多沒有再花時間找到他們的內(nèi)在聯(lián)系做個歸集，還請各位看客多擔待，擱筆。