在2016中國雲計算技術大會（CCTC 2016，專題報道）上，百度開放雲首席架構師徐串發表了題為《企業IT基礎架構在雲端如何變革》的主題演講，并接受CSDN記者專訪，深入分享了他對架構及設計的認識，對架構師工作和技能的了解，以及百度開放雲架構滿足大資料和人工智能等不同應用需求的實踐經驗。
徐串表示，雲計算環境下的架構，除了高吞吐、可擴充性、穩定性的需求，靈活性的實作也很重要。架構師的工作就是在各種沖突之間堅持或妥協，如高吞吐和低延遲的沖突，優雅架構和緊迫需求的沖突。保證業務的需求，是設計架構的一個基本原則，要成為優秀的架構師，就要學會了解業務，和一線産品經理溝通，找出最核心的訴求來解決。另一方面，架構師除了以寬廣的技術視野跟進最新的技術，也必須深入到到底層了解程式員的工作和痛苦，才能做出讓程式員滿意的取舍。
架構設計：沖突下的堅持與妥協
自2008年加入百度，徐串先後做網頁搜尋底層的分布式存儲，後來的分布式計算、Hadoop相關的領域，和整體的底層大規模叢集管理系統工作，在底層的分布式系統上摸爬滾打将近6年，到了2014年百度開始決定投入開放雲産品，他開始涉足面向公有雲的分布式系統的設計和研發。
最開始做分布式架構的時候，徐串通常考慮兩個因素：
- 高吞吐。一定要把大量的資料存儲和處理起來 ，用最大的吞吐量來解決。
- 可擴充性。百度的資料增長非常迅猛，幾乎每一年都會翻倍增長，要求系統有最大程度的可擴充性。
開始做雲産品以後，徐串更關注的，是怎麼使架構在穩定的前提下保證靈活性，因為需求千變萬化，需要豐富的功能元件更好地支撐快速的變化。
但也有不變的東西，就是一個取舍。架構師的工作，基本上就是不停地在各種各樣的沖突中正确地取舍，比如做分布系統時高吞吐和低延遲是一個沖突，很難在高吞吐的時候做到實時響應，必須取舍到底業務更想要什麼；做公有雲的時候，實作架構設計的優雅，與特别緊迫的需求，也是一個沖突，怎麼樣控制節奏，在某些時候做一些妥協，某些時候要堅持，在保證架構整體幹淨的情況下能更好地适應業務的發展。
關于堅持和妥協的決策，徐串分享了他的核心原則：首先要保證業務需求要被實作。
架構師很多時候會抱怨說：“我們的客戶需求太古怪，或者我們的産品經理經常迫使我們做一些很肮髒的事情”。但是徐串的經驗認為，很多時候客戶的需求都是可以改變的，關鍵是架構師一定要找出那些最基本的需求是什麼——客戶通常會講很多東西，但其中隻有一兩點是他最核心的訴求，其他東西都是附加的，滿足他的核心訴求其實并不需要太多東西——這個核心在于做底層架構的人不能脫離開業務，必須到第一線去和産品經理、客戶真正地商量，發現他的核心需求，進而在滿足核心需求的同時保持架構的優雅。
百度實踐：開源、容器、大資料和人工智能的影響
作為内部技術的開放産品，百度開放雲和百度私有雲架構一緻，是一個複雜的系統。百度私有雲最底層是IDC系統，提供主要的硬體基礎設施，在上面有一層完整的叢集作業系統，用來管理所有的機器和提供整體的資源排程，在這上面還有分布式系統，包括各種各樣的分布式存儲、分布式計算，還有資料處理層，包括能夠管理大資料的資料倉庫、資料接口、BI等，再上面是有一層PaaS，為内部的服務提供中間件各種服務，再這之上是百度自己的應用。徐串表示，在每個業務、每個産品都會選擇一套自己适用的技術棧，但是最底層都包含這個架構。當然，百度并不是一開始就有這麼多東西的，總體來說，經曆了三次比較大的改造。
- 2008年的時候，百度在IDC之上中間隻有很薄的一層，上面就直接是百度的應用。在這個情況下，百度發現自己的業務在飛速增長，資料也在飛速的增長，沒有大資料系統是不能支撐需求的，是以在上面發明了分布式存儲系統（包括分布式檔案系統、分布式表格系統、分布式對象存儲）和分布式計算系統（包括高吞吐離線計算平台、大規模機器學習平台、實時流式計算平台）。
- 雖然有了分布式存儲和分布式計算系統，整個公司的資料處理還是顯得雜亂無章，每個産品線基本上都有自己的構想，這對資料的管理以及業務之間的互動、打通形成很大的障礙，驅動百度做一層完整的資料處理層，把整個百度資料統一管理起來，提供一個規範，很友善地管理處理各種資料。
- 兩次大疊代之後，百度在IDC的使用中發現，因為資料量在飛速增長，如果沒有一套系統能夠把資源充分地利用起來進行排程，浪費是很嚴重的，是以研發了叢集作業系統進行資源排程。
百度開放雲首席架構師徐串：架構師必須了解程式員的痛 -
容器與微服務架構
容器技術目前在私有雲領域的應用極其廣泛，徐串表示，百度很早就開始做容器，現在所有的應用都是放在容器裡面。2012年，容器技術還沒有那麼像現在這樣的繁榮，隻有最基本的核心技術CGroup，技術還沒有成熟，百度做了很多的工作，現在形成了自己的一套技術，而不是采用現在流行的Docker這樣的成熟的容器解決方案；容器管理技術，因為發展其實比較早，也是自己研發的，但是百度會關注Kubernetes、Apache Mesos等業界的最新方向，希望找到一些先進的思想可以借鑒，引入到百度容器體系裡面（百度開放雲目前還沒有完整開放容器技術，隻是開放雲底層基于百度自己的容器技術運作，包括雲主機的整個開放底層都是建構在百度容器技術之上，未來在成熟的時候百度也會把容器作為一個服務開放出來）。
而對于目前很熱的微服務架構，徐串表示，微服務很難定義，百度的确有大量的底層分布式服務，由于業務太複雜，從頂到下可能要經過五六層，這個東西能否稱為微服務值得商榷——微服務理想的情況，是把每一個工作子產品拆分到最小并分别将其服務化，但是一般來說拆到這麼小粒度的，架構上會有極大的挑戰，首先是功能需求的變化，可能就貫穿到前後很多層的變化，這在服務中接口是一個重大的事情，需要完整測試。如果拆分太細，QA會經常說環境部署太麻煩了，本來隻是測試，但不得不部署整套服務來做這個事情。是以，微服務的粒度到底控制在什麼樣的程度，這是一個值得商榷的事情。
徐串認為，一個好的架構師，在微服務概念出現之前的架構設計工作中，其實就會有意識地發現一些瓶頸，或者一些高擴充的東西，但是要把這個粒度要控制住，一定不能造成不可控制的複雜性。百度的子產品拆分原則，是從最簡單的開始疊代式演進，強調不要過度設計——最開始是一個小服務的時候，可能就是一個單機系統，把所有的東西放在一起，當發現有部分代碼經常更新、形成瓶頸，就馬上做重構，把這部分拆分出來，形成一個獨立的服務——不是一開始就被服務化或者SOA的概念所困擾，一定要選擇适合業務發展水準來疊代式地發展。
PaaS與DevOps
整個PaaS的推進在中國最早不是很成功，徐串認為最關鍵的原因PaaS最初隻能适合單一的技術，隻适合起步階段的公司，但是任何一個公司業務發展起來以後，單一的技術基本都無法滿足需求，企業會擔憂受制于某個PaaS平台，業務不能很快地發展，是以即使一開始選擇PaaS，也希望是自己來搭建環境。是以，百度開放雲的PaaS會提供PHP、Java、Python、Node.js等的支援，提供MySQL、MongoDB、Redis、Port、Cache服務，同時為企業成長設計了一套方案，可以一步步地更新。
運維自動化也是PaaS強調的一點。徐串表示，國外的程式員對DevOps了解得更透徹一些，國外大公司的趨勢是講全棧，不但要做開發，也要做運維測試。國内的DevOps潮流剛剛起來，傳統模式下研發、運維、測試還是分得很清晰，研發往往認為運維的工作運維就能搞定，研發不用去考慮。但是百度在實踐中會發現，一個系統研發上線以後運維要投入大量的人力，因為系統在運維上設計的不完善，比如怎麼做更新，怎麼做一些小流量測試，這些東西如果做得不好，經常會對穩定性産生內建産生巨大的影響。是以百度逐漸要求在設計階段就要考慮，一個系統上線以後一定會涉及怎麼更新，要怎麼樣在不影響業務的情況下做這些設計操作，怎麼樣友善部署，怎麼樣提取出更多的資訊，要提供對外的接口，友善地觀測到内部運作情況，讓後期能夠很友善地發現系統中潛在的問題。是以在整體上來說，DevOps的趨勢絕對是正确的，如果不能在設計、開發階段就把可運維性考慮充厘清楚，對可靠性将是巨大的挑戰。
百度的自動化運維，慢慢地從日常業務運維轉向自動化運維，比如監控、部署都可以平台化、标準化，讓所有的平台設計綜合自動管理對接。從把代碼送出到代碼托管SVN以後，後面的CI內建、上線釋出、小流量控制，都是一套完全自動化的全流程。工具方面，百度使用的基本都是内部研發的，包括監控平台、日志收集系統等，在叢集作業系統裡面進行部署操作，進行小批量更新、流程控制等，這些東西會運用開源的思想，但是不會直接用開源，因為百度的需求要解決的時候，社群往往還沒有成熟的開源産品。
開源的借鑒
百度在多個技術領域都有對于開源技術的借鑒，徐串表示，百度會時刻密切關注開源技術的發展，思考開源技術到底對百度業務有什麼樣的作用，哪些應該引入，哪些不應該引入，最新引入的是在做Spark的一些工作。- 最開始是Hadoop，整個分布式存儲和分布式計算都是2008年開始從Hadoop發展出來的，到2009年百度的需求就超出了社群的需求，社群主要面向的還是一些機器數在1000台以内的中小型企業，而百度很快就到了3000台的瓶頸，隻能自己優化Hadoop核心，再到一萬台的時候，百度和社群同時開始做，已經産生了巨大的分歧。
- 資料倉庫層面，百度借鑒了開源的Hive、Impala來建構自己的産品和服務，包括列式存儲、MPP架構等重要思想。
- 容器叢集管理方面，百度并不落後于Google太多，開始之時還沒有開源的Kubenetes。Kubenetes比較好的一點，就是它把一些先進的理念标準化、規範化，百度會觀察Kubenetes标準化定義了什麼東西，能否用于自己的容器管理排程，為後續要開放自己的容器服務提供參考。
從大資料到人工智能
大資料的工作涵蓋資料收集、存儲、統計分析和應用，百度主要關注高效資料傳輸、海量資料存儲、海量資料處理和資料倉庫建設與管理，基礎還是分布式存儲系統和分布式計算系統。分布式存儲也不完全是做大資料，也會支援一些圖檔、視訊、手機軟體的分發，日志，同時一些做基因檢測的公司也會把一些低成本存儲需求放到百度開放雲；在計算方面，百度開放了BMR——一個Hadoop、Spark雲端托管服務，把現在完全開源的生态內建到百度開放雲端來，利用百度運維、管理經驗和核心優化，為企業提供更好的服務；此外，百度大資料還做了一個做報表和多元分析的OLAP引擎Palo。
大資料的高階應用是支援人工智能技術發展，人工智能對于百度開放雲架構的影響包括硬體和軟體兩個層面。
- 硬體層面，面向通用計算的CPU，其性能不能很好地滿足人作為一個工智能平台的需求，百度正在嘗試兩種方案：
- GPU加速。大規模機器學習需要的大量矩陣、向量運算，是GPU所擅長的，用GPU加速成為業界通行的做法，尤其是在分布式深度學習訓練中。百度也建構了大規模GPU叢集，GPU數量在這兩年有飛躍式的增長，支援各種機器學習任務。大規模GPU叢集同時也意味着高性能網絡改造的需求，因為單機性能增強，能處理的資料量提升，百度此前已經完全更新為萬兆網絡，但從人工智能的發展情況來看，節點和節點之間的互動也越來越頻繁，百度也在高速網絡方面試點做一些預演性工作。
- FPGA加速。 GPU雖然計算性能好，但耗能比較大，會影響IDC的成本，而在相同能耗下FPGA能夠提供比GPU更好的性能，可能将來的人工智能算法會有專用的FPGA。百度目前也在探索FPGA的規模應用，基本所有支援線上廣告的機器都插一塊FPGA卡。最大的障礙，是FPGA本身還具有一些硬體的特征，涉及到布線、功耗優化、流片，一個FPGA程式的疊代周期要遠比單純的程式疊代周期要長。如果未來FPGA開發具有像現在軟體編譯器一樣的工具，能夠智能化地進行功耗的調優，減少對晶片工程師編寫代碼的能力的需求，疊代速度就會大大提升FPGA平台也允許快速疊代，包括功耗測試。這需要很長的時間來實作，需要業界共同努力，百度目前是根據業務的情況，以自然增長的方式進行探索。
- 軟體層面，百度在人工智能工程化上發現一些比較重要的東西其實是通用的流程，如底層網絡通信的優化，可以說跟算法不相關，但是實際上應用的時候不可避免遇到這些問題，百度基于大規模的機器學習的經驗建構一個統一的平台，包裝成BML産品提供服務，讓算法工程師隻需要關注自己的主要算法，怎麼更好地設計人工智能政策，而不用關心底層大規模平台的設計。BML目前基本上實作全流程托管，包含了20多種最常用的機器學習算法——百度發現需要對現有經典算法做改動的需求很少，大量工作還是在資料處理、特征提取上——使用者可以基于标準流程自定義成自己的平台。
架構師必須是程式員
盡管百度在積極利用人工智能技術，百度架構師也在努力為人工智能的發展提供更好的平台以促進該技術的進步，但被問及人工智能能否簡化架構師的一些工作，徐串認為這在目前還很難，因為架構師面臨的最大問題是取舍，這是一個很複雜的事情，要從業務需求出發，在人工智能能夠了解這個業務的情況下，這會是一個趨勢，但是這還需要一個很長時間——如果人工智能能做到這樣，人類現在大部分工作都可以由人工智能取代了。
談到架構師的自我修養，徐串表示，一個比較好的架構師，既要有很寬的技術視野，也要能了解業務需求。
- 架構師必須是程式員，如果不能了解程式開發中的痛，就不能了解程式員為什麼對需求的變化那麼敏感，考慮為什麼會有這些架構的代碼的時候，很難作出讓程式員滿意又能滿足業務需求的取舍。是以架構師首先必須必須深入到底層了解程式員在做什麼事情，開發架構是怎麼樣的，要跟進最新的技術。
- 程式員和架構師的差距，在于不能脫離底層程式設計的工作，從更高的高度來看待問題。在一個系統複雜的時候，底層程式員常常隻看到比較底層的一部分，但更重要的是業務需求到底應該怎麼拆解的，過于複雜的系統應該怎麼分析，是以架構師需要提升自己的高度，真正地去看業務上有什麼樣的需求才需要做這個架構的變化。
- 關注一些國際頂級的會議。因為最新的一些思路、研究方向，都會在一些國際頂級學術會議上發表論文。而等到書籍出現的時候，意味着該技術已經比較成熟，是以書隻适合程式員，他們剛剛進入新領域的時候，找一些經典的書籍去很快地了解該領域有什麼東西。
- 跟進整個開源界。現在開源成為大趨勢，基本上很多新技術都會進行開源，是以架構師要緊跟這個潮流，同時結合自己的業務經驗來做一些判斷——雖然很多開源技術很繁榮，但也有很多開源技術隻是昙花一現，是以架構師要了解技術的本質，到底是在解決一個什麼樣的業務問題，才能做出正确的判斷。