專訪阿里云高級專家趙林：從0到1，中間件的研發運維之路
中間件，英文名為Middleware，它提供應用層和系統層之間連接，是應用層實現系統資源集中調用的抽象邏輯，同時協調各個應用之間的溝通；并且自動處理分布式系統中的常見異常，最終簡化大規模分布式應用的編寫。
早期的中間件，起源于1968年IBM的CICS（Customer Information Control System ）交易事務控制系統，是一個分布式的文件服務用來管理用戶信息。伴隨著互聯網發展和分布式系統的興起，中間件的概念也在發生演變。在分布式網絡環境下，中間件面臨更復雜的情況：如何解決眾多應用復雜依賴的問題？如何屏蔽分布式系統的技術細節？新時代的基礎中間件會追求更高性能、更強的可用性和擴展性。同時，在基礎中間件基礎之上，需要建立分布式系統的數據化運營能力，以及整個業務系統的高可用架構設計能力。
互聯網時代，大多數企業都面臨著IT構架轉型的陣痛。一方面，業務創新受阻：傳統構架建設周期長，信息孤島現象嚴重；另一方面，系統處理能力有限：如果業務發展起來，傳統的集中式系統很難及時擴容，導致無法處理不斷增長的并發量。分布式系統將成為不可回避的選擇。
為什么阿里云把中間件作為進入企業級市場的重要武器？InfoQ就中間件的技術實現對阿里中間件高級產品專家趙林進行了采訪。
受訪嘉賓介紹
趙林，花名丹臣，中間件高級產品專家。2006年加入淘寶，負責淘寶產品DBA團隊，維護淘寶生產數據庫；2009年開始推動和設計了淘寶許多核心業務的去IOE歷程； 2012年轉崗到中間件團隊，從0到1建立起中間件云產品團隊，主導了一系列的中間件產品上云及商業化，完成了一些重要客戶項目的業務拓展和項目支持。
InfoQ：可以簡要介紹下阿里中間件的研發初衷和歷程嗎？
趙林：阿里在2003年-2006年的時候是單機的集中式的系統，采用的是IOE架構（IBM、Oracle和EMC）。隨著業務的發展，傳統構架的弊端逐漸顯現：上線慢（高端設備的采購周期長、不能快速擴容），故障多（高并發的情況下系統的穩定性出現了多起嚴重的故障），成本高。技術不能束縛業務的發展，為了改變現狀，2008年-2010年阿里研發基礎分布式中間件三大產品，大大提升阿里的業務研發團隊構建分布式系統的效率。我在阿里工作十年，前五年負責維護淘寶核心數據庫，見證了淘寶從只有三個數據庫演化為現在的幾千個數據庫；近五年都在做中間件，目前負責中間件的云產品團隊。
在研究分布式系統問題域的時候，我們是從分布式系統基礎中間件開始入手的。當時業界對中間件的認知和今天還不一樣，可供參考的資料非常少。在2007年到2008年，我們研發了三個最早的中間件：
- RPC遠程過程調用框架
初期是一個比較簡單的框架，后期改進成現在的HSF框架支撐了生產環境所有系統的服務化調用。目前阿里云HSF服務框架采用了去“中心化”的系統架構，服務的提供者和調用者都直接相連，不僅去除了中心單點的風險，還能大大提高調用效率。峰值時，每分鐘調用次數可以達到25億次。 - MQ消息中間件
在傳統的拓撲結構中，系統不同業務之間的依賴性過強過多。舉例說明：如交易拍照、發旺旺消息等業務，依賴于下訂單這個業務；數據處理流需要經過不同的業務模塊，一旦其中某個模塊出現問題，就會有整個網站下不了單的風險。加入消息中間件后，處理流程發生了改變：不同模塊之間無直接關聯，通過消息訂閱的方式獲取信息。交易中心只負責下訂單寫數據庫操作，其他中心則只需訂閱交易中心的消息。這很大程度上提升了分布式系統的健壯性。 - 分布式數據庫
分布式系統中會有很多很小的數據庫。為了減少上層應用開發難度，需要屏蔽底層數據庫的形態，使得應用系統開發人員無需額外留意這些細節。設計分布式數據庫需要注意三點：
- 業務拆分：根據系統的業務特性，拆分業務核心表數據，其中Partition Key的選擇很重要。需要找到最適合自己的拆分方案。
- 拆分數量： 如何確定數據庫和表的拆分個數？一方面需要判斷業務能力的現狀，這需要基于當前單個分庫的業務處理能力；另一方面需要預估將來的業務，為擴展做準備。
- 存儲方式：對數據庫類型的選擇，是常見關系型數據庫（如MySQL），還是NoSQL非關系型數據庫（如HBase）？數據是否可以采用高壓縮存儲以降低存儲成本？(如日志數據、歷史數據、物聯網數據等，便可以采用高壓縮存儲)。根據不同的業務場景，選擇不同的數據存儲。如果業務場景于存儲產品的技術特性非常契合，那么系統就可以發揮出最好的特性。
InfoQ：在中間件研發過程中，開源技術起到怎樣的作用？
趙林：淘寶早期沒有直接構建分布式系統有兩個原因，一是自身技術積累不夠，優先發展業務為主 ; 二是因為當時外界沒有什么開源技術可以用。開源技術在分布式系統構建初期幫助很大；而如果后期業務發展起來了，則需要對開源產品有更多的掌控能力，最后就回歸到自主研發的能力上來。
在我看來分布式系統分為三個層次：
- 簡單的非大規模分布式系統
運用開源技術可以構建一個簡單的分布式系統。 - 數據化運營的大規模分布式系統
構建一個更大規模的分布式系統，必須就進行數據化運營。目前大家都在講業務如何數據化運營，其實分布式系統也需要數據化運營。第一種層次那種簡單的分布式系統，近乎一個黑盒子：我們不知道它是怎么運行的，一旦出現問題，就是黑暗世界的降臨。早期時，阿里的數據化運營很基礎很粗糙，比如會做一個產品統計各個主要接口的訪問量或者交易數據，然后與前一天的數據進行對比判斷系統有沒有出現問題；后期我們又將它做為實時的。數據化的好處是你可以清晰地感知變化，這對于淘寶這樣大體量的公司來講很重要，輕微的數字浮動就是很大的影響。 - 高效運維可精確定位問題的分布式系統
數據化運營可以及時發現系統問題；那么接下來如何改進這些問題，維護如此龐大系統？這時就需要借助于運維，在出現問題的時候，團隊可以心里不慌，可以快速定位問題根源。我們實現了全鏈路跟蹤系統：實現所有服務各個模塊端到端的數據采集，為各個產品建立全鏈路的監控。（相關詳情可參見 2014年的阿里云監控體系現狀概覽 一文。）
很多阿里自主研發的中間件現在是開源的。比如，遠程過程調用Dubbo、中間件消息RocketMQ和分布式數據庫Cobar等。阿里技術氛圍是很開放，大家也可以看到阿里在國內外做了很多的技術分享。
InfoQ：您剛才提到了阿里云實現了全鏈路跟蹤，最開始是怎么會想到研發分布式系統的全鏈路跟蹤？系統實現高效運維是得益于此嗎？
趙林：最早時基礎中間件這一層是沒有運維的，但在內部場景使用中遇到了好多問題，于是就開始開發越來越多的組件進行運維監控，組件慢慢沉淀下來就和我們中間件融合在一起。如果沒有這些運維模塊的話；系統是沒有辦法支撐起阿里如此多如此廣的內部業務的，更無法談及上云之后服務眾多大中小企業。現在，經過這么多場景的歷練，中間件產品已經很完整了，這層運維做得好、易用且成本低。
全鏈路跟蹤，即從入口處開始到流經的所有系統的所有節點，都通過可視化的方式串起來。這樣可以快速定位系統出現了哪些問題。
關于系統高效運維，這里再拿消息中間件的消息軌跡追蹤舉例：從消息的發送開始，它發到哪些topic，有哪些訂閱方，訂閱方有哪些機器，被哪些機器消費，最終是消費成功還是失敗。如果有機器消費失敗，需要再次投遞到所在集群中的另外一個機器上去，直到集群中至少一臺機器消費成功，才會停止投遞。如果一直投遞失敗，就會按照一定的策略進行不斷地降級投遞服務。
不過，對于企業級互聯網架構，只有全鏈路跟蹤系統是不夠的，還需要一個自助式的在線壓測系統。如果在開發的時候做壓測，得到的結果數據不是真實的，因為這個和實際的生產環境是不一樣的。我們需要壓測平臺與中間件基礎設施相結合，自動去導流量，用它去推測每個接口每個節點到底能夠實現多大的業務能力，最后再清晰地算出來結果：以這個科學數字的方式合理分布資源，告知各個業務線當前業務量是多少，是否需要對一些應用進行擴容或者縮容。
InfoQ：對各個應用組件進行全鏈路的監控，這意味每一個產品在開發時都要實現運維部分？
趙林：是的，基礎中間件都是自帶運維的。比如MQ消息中間件，這是一個很廣泛的產品。阿里的創新點在于實現了消息軌道追蹤。消息的產生和投遞、發送消息的中間件、最終投遞的各個消費方、投遞到消費方的哪臺機器、投遞次數和結果，都會清晰地顯示出來。這些鏈路工具和MQ中間件是組合在一起，放在阿里云上提供給用戶，這樣用戶的體驗才是完整的。
換個角度來講，這也是阿里中間件都變成了云服務的必要條件。否則的話：一、根本無法知道問題出現在哪里；二、客戶不能每次出現問題都來找我們，不能為每個客戶都配備一個中間件技術專家。一個技術產品要真正變成一個云服務，方方面面都是要做細的，要讓其完整并成為真正的應用服務。如果每個客戶使用過程中小小的問題還需要和產品研發團隊交互；那么這就是能力很弱的產品，它不能去服務越來越多的客戶。
InfoQ：那阿里采用的是將開發和運維融合在一起的 DevOps 文化嗎？
趙林：這是必須的，因為我們有太多的場景需要這個能力。我知道現在很多的大公司，基本上開發和運維還是分開的，阿里幾年前也是這樣的，但是現在我們在融合各個團隊實現DevOps。
做產品研發，不是說只做個App就大功告成了，因為服務端還不具有這樣的能力。服務端去改起來還是很麻煩的。應用集群變大之后，如果一個應用有成百上千臺機器的時候，連一個簡單的發布都是個問題。快速發布、快速回滾，有可能需要半天或者一天，這是一個非常現實的問題。如果想發布應用，那就必須把應用的所有管理和監控都做出來。
產品功能開發出來就需要運維，不能丟給別人去運維；其對應的運維工具本來是一個產品不可或缺的部分。打個比方，這好比生孩子容易，養孩子難。通常在開發團隊在自己維護的過程中，遇到一次什么樣的故障，知道整個系統中有哪里需要補，這里是不是需要加一個端對端的全天候監控，那里是不是需要補一個權限漏洞：就這樣一點點地形成一個更加豐富完整的體系。真正把一個系統給運維好是需要很深厚的功力，開發運維那些周邊工具所花的時間精力，很可能比研發中間件核心花的時間還要多很多。
InfoQ：阿里云的企業級互聯網構架圖中，在中間件的業務能力這一層，業務服務被分成了不同的模塊。這些模塊的拆分是出于什么考慮呢？
趙林：2008年之前業務發展很快，沒有更多的研發力量投入到基礎技術的研究當中。那個時候是怎樣實現更快，就怎樣做。
后來開始一點點將不同的業務中心拆分出來。拆分業務時，需要特別警惕一種做法：核心應用錯誤地依賴非核心應用，這會導致本來應該有的弱依賴成為強依賴。我建議所有的分布式系統，都應該最先拆分用戶中心。現在很多公司的系統仍然沒有獨立用戶這一塊，他們面臨著和阿里當初的一樣的情況：在建立分布式系統時，可能各個模塊都在連接底層的用戶庫。這時其實用戶的數據安全是沒有辦法保障的。因為，一無法知道誰改變了用戶數據、改得有沒有問題；二如果有問題，想去查也不知道怎么查。
2007年我們拆分了用戶中心。用戶中心統一接管用戶數據的所有訪問，其他系統不允許連接用戶數據庫。此外，將用戶中心獨立出來，也可以做緩存等性能上的統一優化，省去了上層優化的成本。這同時解決了安全和性能的兩方面問題。
從最開始時只有兩個業務系統，然后一個一個地拆分業務應用，到最后有幾千個應用。在有幾千個應用的時候，應用之間依賴是很復雜的，業務系統交互的流程圖是畫不出來的。同時隨著研發人員增多，開發代碼的維護也增加了不可控性。如何管理這樣的系統變成了一個新的挑戰，如果能把這個問題處理好了，那么我認為分布式系統一定變成個很好的東西，它可以并且一定會支撐更大的業務量。
InfoQ：幾千個應用，是怎樣實現持續性部署？是基于Docker做到的嗎？
趙林：關于持續性部署與Docker之間關系的問題：一方面，我們中間件本身的部署，支持Docker化的部署，但是同時也支持物理機和虛擬機的部署。而另一方面，對于用戶的應用，采用的是與Jenkins、SVN等工具的無縫對接，完成研發各個環節的持續集成。阿里云提供的企業級分布式應用服務EDAS，可以支持用戶應用的Docker化部署。此外，為了提高開發者體驗和研發效率，我們提供了許多插件。例如改變代碼無需重啟就可以立刻生效，這對于一些大應用的研發格外重要。
關于Docker：客觀上講，Docker只能解決一些最基本的應用部署和監控問題；但是如果你真正要把一個大型分布式系統構建并且運營起來，就需要自主研發的中間件或者利用一些成熟的開源中間件產品，因為Docker本身并不能解決這些問題。
InfoQ：研發接下來努力的方向是什么呢？
趙林：提高系統的效率。當規模小、服務器比較少的時候，優化效果不是很明顯；但是當機器達到十萬臺以上規模的時候，優化10%就是優化了一萬臺機器，這就意味著可以為公司節省下來好幾個億的成本。現在很多公司不管是在線業務還是離線業務，服務器處于空跑階段是很常見的問題。
因此利用技術手段提高資源的利用率，就成了我們一個非常重要的課題。國外像谷歌這樣的公司，他們的機器利用率很高，可以達到40%-50%；我們總體上還是比他們落后一些，我們會繼續不斷地提高存儲和計算效率。
來自：http://www.infoq.com/cn/news/2016/06/middleware-operations