明星分分合合的洪荒點擊量，微博Mesh服務化改造如何支撐？（附PPT下載）

你們好，我今天的分享主要圍繞如下幾點，首先跟你們簡要介紹一下微博服務化的演進過程，其次是微博自研跨語言RPC 框架 Motan 實現的一些關鍵技術要點，主要是跨語言方面，再次，結合目前市面上的一些Service Mesh 實現對比，給出基於 Motan-Go 的更符合微博場景的Weibo Mesh 實現。

最後，是我我的對於面向將來泛服務化架構的一些思考。一些同窗對Service Mesh比較感興趣，也想在生產上作一些實踐，若是沒有歷史包袱，新開發一個項目用什麼架構，怎麼實現都是能夠的。由架構去取捨，看咱們更迫切須要的是什麼，所追求的是性能仍是其它高擴展性等等，目前也有一些現成的解決方案。可是若是沒有作任何服務化，或者服務化過程當中歷史包袱比較重，可能很難找到一種能夠直接實施的現成方案，由於須要考慮的每每會更多。本次分享更可能是關於操做性內容，但願對你們有必定的借鑑意義。

微博平臺服務化演進

咱們先看微博平臺服務化的演進過程。

微博2009年上線，在業務高速發展的初期是傳統的模塊化單體服務，每一個小的業務都有可能隨時爆發成長爲一個核心業務。咱們的目標很簡單，就是知足業務快速發展的需求，而且在突發流量增加時保證服務的高可用。隨着業務的擴張，單體架構各個模塊嚴重耦合，導致相互的影響愈來愈大，請求成功率得不到保障，長尾問題嚴重。爲了解決這一系列問題，微博從 2013 年開發了Java 語言的 Motan RPC 框架，並基於此完成了服務化改造。Motan 從2013年上線至今經歷過每次熱點事件、三節高峯的嚴峻考驗，穩定性和可靠性都獲得了實際場景的驗證。這些經歷之下微博 Motan 也積累了一套服務治理型 RPC 的服務化體系。

除了Motan，2015年開始，爲了應對愈來愈猛的流量洪峯，更合理的對資源進行整合利用，開發了Open DCP 彈性雲計算平臺。實現了動態的彈性擴縮容，告別了以往花費動輒幾千萬的資源成本，以及節前幾個月就要開始的勞民傷財爲三節作準備的日子，也不須要在爲了一個個的熱點事件提心吊膽。

上圖是當時微博平臺技術體系的概貌，是一個基於 Open DCP 彈性雲計算平臺和 Motan RPC 的服務化架構，通過幾年的運營和考驗，咱們已經在混合雲的服務化方向有了豐富的經驗和積累。但在解決了微博平臺內部服務高可用、高性能的問題後，業務方平臺服務調用的問題開始顯現出來。好比調用鏈路過長，致使坑多性能差，又好比，每一個業務方都須要作高可用和服務治理，而這些事情平臺已經有豐富的積累，你們都再作一遍特別重複且浪費。當想把在平臺上的技術積累服務到微博更多的業務方時，平臺內部基於 Java 的服務化體系已經不能完成任務，因此咱們須要一個跨語言的解決方案。從2016年起，咱們開始了跨語言服務化改造之路。

跨語言RPC要點

異構系統如何作總體服務化的解決方案，也是今天探討的一個主題。

服務化經歷了前面幾個階段後，須要構建一個跨語言的服務化體系，將原來在 Java 體系積累的經驗加以總結，給其它的技術棧業務賦能，更好的維護微博總體的穩定和高可用。

上圖我簡單列舉跨語言 RPC 的幾個技術要點，最下面是可靠性和易用性，好比咱們的 Motan 有 Cluster 的概念，每次調用都是從這個 Cluster 裏面經過負載均衡（LB）策略來找出可用的節點（Endpoint），再經過一種高可用的策略（HA）完成調用。整個過程的各類理念可複用，各類語言照章實現就好。各類策略也是能夠按需根據實際狀況進行擴展的。而傳輸、I/O、進程線程模型等各個語言都不同，須要根據語言自身的特性來選擇。

協議和序列化，這是解決跨語言比較重要的一點，由於要讓各類語言互相理解對方，互相溝通。

上圖的故事你們可能都有所耳聞，人類很狂妄地說，我要建一個塔直通到天堂。可是上帝聽到之後以爲很不爽，因此讓人類說不一樣的語言。由於語言不通，致使塔建歪了，整個工程就失敗了，這是說交流的重要性。要作跨語言服務化，負責數據通訊的RPC 框架跨語言是重中之重的基礎設施。而協議和序列化如何取捨，很關鍵。

Motan的Java版，所要解決的是微博平臺內部 Java 服務之間的調用，所以 Motan1 協議時，其實並無考慮到跨語言的問題，用的是對Java比較友好的 Hessian。後期在跨語言方面，motan1的協議顯得對跨語言不是很友好，motan2 的協議就給了一個足夠容易理解的協議，是一個簡單的TCP描述。好比，要請求一些方法、服務的分組，或Body，請求發過去，對方語言收到後，怎麼樣讓這個語言理解呢？關鍵一點就在於序列化。

如今 Motan 使用簡單序列化的方式（Simple），只支持幾種簡單的類型。不過咱們一直都在迭代中，也正在之前支持更復雜的類型上作擴充。但本質上，它還是簡單的協議，咱們會盡可能保證它的簡單。只有足夠的簡單，才能在跨語言上下降成本，開發成本還好，主要是語言溝通起來解析的成本，好比，編譯型語言每每有各類明確的強類型，而解釋性語言每每並不須要強制類型約束，如何讓他們很好的溝通，這就須要作取捨。

這裏給出一個 MotanRPC 框架簡圖，微博有一個自研的註冊中心叫 Vintage，也支持其它像ZK等一些註冊中心。圖中給出了 Motan RPC 關鍵的一些組件和他們之間的調用關係。若是對Motan 感興趣的，歡迎你們到GitHub 搜索關注，咱們有更詳細的文檔，你們也能夠網上搜索。爲何要說這些？由於Weibo Mesh 是基於Motan來作的。但願你們對Motan有個總體的認識。

現有實現跨語言，支持不一樣語言的Motan，最下面是Java版，就是最開始的一版，如今支持Golang（Motan-go）、Openresty-Lua（Motan-OpenResty）、PHP（Motan-PHP）。

基於 Motan-Go的 Weibo-Mesh

下一個話題：基於motango的Weibo-Mesh。數人云敖小劍老師扛着ServiceMesh大旗已經衝了一段時間了。剛開始咱們也看到這一點，其實你們的想法都同樣，由於需求和痛點基本是同樣的。因此咱們嚴重認同ServiceMesh是下一代微服務，固然不一樣人都有本身的理解，經過初步的實踐，若是一個很複雜的架構，你們在作服務化，服務化到必定程度，會因爲微服務的力度和規模慢慢增大，出現依賴複雜度的增長帶來流量交錯，難以管控以及服務治理更加困難等一序列的問題。爲了解決這些就須要一個東西很好的管控這些服務和流量，這就是爲何會有Mesh。

看一下如今業界公認最牛的 Mesh Istio是怎麼玩的。這裏我但願你們關注兩點，一個是 Istio 有一個基於Envoy 的數據傳輸層，另外是控制面板，Istio 經過這個控制面板來完成流量調度，鑑權，服務治理等工做。這是 Istio 如今的作法，那微博怎麼作的呢？

首先，咱們從2016年開始作跨語言的服務化改造，那時尚未 Service Mesh ，剛開始很簡單，只想作跨語言，想解決跨語言調用鏈路過長的問題。好比，原來全部的跨語言服務都是經過 Restful 接口提供的，每一個請求都須要層層轉發，尤爲如今是混合雲的架構。舉個極端又及其常見的例子 ， A 機房的服務依賴一個Restful 接口，請求發出後，內部 DNS 解析說這個域名在 B 機房提供服務，你到B 機房後，HA 告訴你，這個請求應該去C 機房的一個Member 上去完成，繞了一大圈，頗有可能發現那個 C 機房在公有云上，鏈路特別長。因此，但願經過實現跨語言的 Motan RPC，Client 對Server 發起直連，經過點對點的通訊來解決鏈路過長的問題。然後來的演進，後面再細說。

今天講的這個可能比較簡單，目的是但願你們能更好的入戲，更好的理解。能夠用直連的方式，或用任何其它方式，像咱們用了 Motan。

微博從2016年開始作這個事情踩了不少坑 。微博作跨語言，剛纔在後面跟老師們交流你們還說 GRPC 把跨語言帶跑偏了，當時作跨語言的時候就是想GRPC已經作的很好，就想經過Motan支持GRPC 協議的方式來實現Motan的跨語言調用。你們能夠去翻 Motan 的開源，裏面是有GRPC支持的，如今也還有（不過最先支持的是PHP，對接的是鳥哥寫的那個Yar的RPC框架, 最先 Motan還支持Yar協議。）。

因此當時想法很簡單，想依託GRPC來解決跨語言的問題，因此是上面這樣的一個結構，用GRPC來搞。

這個結構出來之後，咱們開始拿線上的業務來摸索改造。發覺須要把原來的Restful 接口徹底重寫成GRPC的服務，這樣的改造避免不了大範圍的代碼重寫。硬着頭皮改了一些後，發覺性能也沒有像宣稱的那麼好。

你們平時可能都會上微博，咱們一條微博數據裏面可能有百十個字段，因此基於GRPC 改造就須要把這些字段和服務都用PB 進行定義，完了之後發現最終的Proto文件寫下來一大坨。雖說請求過程並不須要傳遞這些proto 數據，可是請求數據回來之後須要解析組裝。跨語言的時候，好比說PHP來解析那個對象，性能就比較差了，因此這種方案應對微博這種場景最終被淘汰了，並且就算勉強接受性能的損失，這裏也只是基於GRPC 解決了跨語言的部分。那另一個很重要的部分 --- 服務治理呢？

由於咱們多年服務化演進，Motan整個體系在服務治理方面作了不少工做，有不少積累。可是基於 Motan 支持GRPC 協議來完成跨語言的服務化的服務治理怎麼作呢？好比說這個時候PHP 怎麼去作服務發現？PHP 每個過來，都是一次處理整個過程就結束了，沒有一個常駐的可用存儲每次請求狀態的地方來實現服務發現、服務治理這相似的事情。

可是咱們也作了不少嘗試，好比經過一個本機的後臺進程來作服務發現，或者在Nginx 上基於OpenResty 的timer 來實現服務發現，併發結果寫到PHP 的$_SERVER 變量中，讓PHP 能直接使用（上面右圖那樣）等，可是實踐的效果並不理想。

因此總體經過 GRPC 來作跨語言這個方案作下來，效果不是很理想，這並不適合咱們的場景。因此咱們就走到WeiboMesh的原形（以下圖），咱們想既然解釋性語言的跨語言服務化因爲語言自己的特性和咱們的特殊場景（主要是改形成本、性能等方面的考量）下，並不適合直接經過語言自己來實現，那這樣的話，還不如去作一個代理。這個代理可能就是WeiboMesh的一個雛形，相似如今ServiceMesh 中的SideCar。

好比說Java啓動一個服務，一般狀況下，好比 Java Client 訪問這個服務是這樣的一個流程：Java Client 啓動的時候會根據配置去註冊中心訂閱本身須要訪問的服務，請求過程當中會有一個線程不斷的從註冊中心去發現當前可用的節點列表回來，組成Client 端的一個Cluster而完成的調用（如前面Motan 請求處理簡圖所示的那樣），而若是是PHP 須要經過Motan RPC 訪問這個服務呢？PHP無法作服務發現，它就把它的請求扔給Go Agent，服務訂閱、發現、治理這些事情讓Motan Go Agent 來作，其餘的都同樣。咱們作這個的時候，尚未ServiceMesh這個東西呢，因此一路踩了不少坑。

繼續往下想，若是反過來 PHP要作server的時候呢？以前說 RPC 跨語言所要解決的一堆技術問題，比較重要的是傳輸模型，怎麼選一個比較靠譜的模型來做爲Server 處理請求呢？如今也有不少很好的現成的解決方案，可是咱們沒有從中選哪一套來作。主要由於微博業務實在是很龐雜，裏面有不少 PHP 的業務，若是把原來基於 LNMP 的服務架構改爲 PHP 直接作Server的話，涉及到排山倒海的業務重寫，PHP 同窗可能會要了咱們的命，他們是不會接受的（我要是他們，我也不會幹）。因此咱們就想，怎麼能更簡單的把這個事情作了，由於已經有了前面 PHP 經過 Motan Go Agent 去請求RPC 服務，咱們就繼續在上面擴展了一下。

PHP 要作SERVER，咱們使用Motan-Go-Agent來幫助PHP作服務的導出，這個就不是簡單的請求調通了，由於 Motan-Go-Agent 除了負責請求的連通，還負責Server 端 PHP 服務的註冊。Motan-Go-Agent的角色更像是是一個Motan Server。啓動的時候他會把須要導出的PHP的服務，好比註冊中心完整導出，並保持像註冊中心服務狀態的上報更新。導出後，假如說一個Java的Client 須要調動這個服務，Java-Client 會訂閱這些服務，請求過程當中會經過服務發現回來的節點對它發起調用。Motan-Go-Agent 接到請求後，它把這個請求轉給後端的PHP 處理，它之間多是基於CGI或者是HTTP協議完成的，回來這個請求就完成了。

服務化之後，最直接的感覺，原來服務調用時依賴一些 lib 庫、Jar 包，或者Restful接口，如今變成依賴一些服務。在服務調用時，再也不是倒入某個包或者Curl 某個接口，而是直接去註冊中心訂閱和發現某個服務，這是一個本質的改變。

這個本質的改變提升了服務依賴和複用的效率，可是原來的不少服務都經過這種方式暴露了，也直接提高了服務治理的複雜度，服務治理成本變得相對較高。

可是這一切都是值得的，由於這一來咱們統一了服務治理的方式，高可用等各類保障，通用邏輯的封裝等實現起來都更輕鬆天然。

咱們基於 Motan-Go-Agent提出對像 PHP 這樣不方便實現服務化的語言，經過正向、反向代理的方式來實現跨語言服務化，Java、Golang這樣很方便實現服務化的語言，有簡單的Motan實現，或者也能夠直接經過Motan-Go 導出服務，這樣就只須要實現一個簡單的Motan-Client 來完成服務調用便可。

咱們服務化作到這個階段，發現性能已經符合預期，可是當想擴大規模的時候，發現節點和服務數量少。服務化規模很小的時候，好比平臺提供幾個服務，供幾個業務方來調用，可能人工確認，事先配好就沒問題。但服務化規模大了以後，就無法人工確認來解決，咱們的作法是經過擴展註冊中心的功能來解決。

在咱們束手無策的時候，發現Service Mesh這個概念出現了，並且解決的問題和麪臨的挑戰都同樣，都是解決跨語言服務化的問題，也都面臨流量、服務管控和治理複雜化的挑戰。並且，那麼多大牛公司在後面作背書，因此咱們就立刻轉到這個方向上來，但願實現一套更符合微博現狀的Weibo Mesh。

要更符合微博現狀，首先咱們在 Motan RPC、服務治理上有不少積累，這是已有的，不想拋棄的，這是寶貴的技術資源。另外一個目標，要作跨語言。因此，一體化的解決方案更符合微博的結構。

另外，微博是混合雲架構，彈性雲計算平臺已經有了。若是新起一個項目，沒有任何歷史包袱，任何方案均可以。但假若有歷史包袱，就不同了。

這就是基於微博現狀作的 Weibomesh。這裏給你們詳細的說一下，一個是Mesh，跟Istio就很像。可是不同的地方是說，微博體系裏除了一些編譯型語言，還有一些解釋型語言。只有解釋型語言須要走用Mesh來導出服務的方式。好比Java 就不須要，由於有比較好的原生積累。Istio宣稱不須要業務方改任何一行代碼。可是咱們這裏須要一個簡單的薄薄的client層，算是咱們對本身業務的一點犧牲，對後面的收益極大。

其它都同樣，包括服務註冊、發現、調用。另外，決策系統比如 Istio 裏的控制面板同樣，負責發指令。跟Istio不同的地方是，Istio 中是經過一些請求的 Header 的數據，經過一些規則來作基於 iptables 的流量轉發，而Weibo Mesh不須要轉發，由於服務都是經過發現回來的，要調什麼服務，就發現什麼服務。調用是明確的，出門以前就知道本身要去哪兒，不須要轉發。只是有一點，可能發現回來是一堆節點，須要把控的是怎麼讓流量更均勻，更好的控制流量，因此有一個自動流量調度和彈性擴容。

彈性擴容自己就有，爲了應對峯值流量，應對節日。好比原來爲了過年，要提早三個月準備好幾千萬的服務器。

服務治理是Motan體系的積累，服務傳輸就是經過它來收發請求，流量過來，由於請求都通過Mesh層，因此經過時時調用的信息，來時時調配流量，對總體系統進行保障。

這就解決了剛纔說的，若是微服務力度大，服務劃分很細，Services 規模大到必定程度，多個服務之間，怎麼互聯互通。

這是微博自動臺調動體系，分爲幾個關鍵點。容量評估模型、是自動化壓測容量評估系統。彈性調動要解決的問題，一個是調配集羣的流量，一個是控制集羣的規模。怎麼調配？首先要度量，度量系統包括：它何時是正常的，健康的，何時是冗餘的。一個系統的冗餘度是怎麼度量出來的。

經過上面這個公式來度量集羣的冗餘度，還評估了集羣是否須要擴容，流量是否須要調動。

下面這裏有幾條水位線的概念，一個是安全線，一個是警惕線，一個是危險線，紅色的就是危險線，這個時候就須要擴容了。你們能夠理解爲水庫，一個水庫能蓄多少水，何時水位上來，扛不住了就會發生洪災。

經過對整個集羣的流量評估，能夠知道這個集羣是否空閒，是否安全。當集羣流量扛不住，是否把這些流量切到其它集羣，支撐整個彈性調動和動態容量調動。

Weibo Mesh改造收益

WeiboMesh改造，通用於任何異構系統。有些操做好比解釋型語言，由於某些語言特性，不能實現那個功能，可是用Mesh的方式，能夠在 Mesh 層實現。好比， PHP 請求一個接口，若是接口響應慢，一般的作法是重試，這樣會帶來危險，由於原來走的都是集羣的轉發。可是若是直連，若是一個節點慢了，一直重試可能就試掛了。若是重試三次不能夠，就再也不往這裏調了，把它從可用節點裏摘掉，解決宕機的問題。

監控裏會常常看到一些長尾的調動，發現系統性很好。可是真正跑起來，由於網絡或者機器的因素，可能會致使後面的長尾特別長，特別佔資源。若是在 Mesh上，時間長於某一個閾值的時候，就再給發一個，若是後發的請求響應先回來的話，能夠把前面的請求拋掉。

體系化是說，不須要在每一套語言裏都實現一套。這跟通用的ServiceMesh方案同樣，你們都是爲了通用和統一。

這是微博搜索，接入這個系統以後生產當中的一些數據，也通過了一些實驗的驗證。好比，這是薛之謙和前妻複合事件，這個圖同事在不少場合都講過，原來運營發一個 PUSH ，你們都提心吊膽。在新浪若是遇到爆炸性的新聞，運營在發 PUSH 以前，都要通知到全部技術。可是如今不須要這樣，好比說那次運營發了一個PUSH，你們能夠想象一下山洪爆發，調動系統發現已通過了黃色警惕線了，已經須要擴容了，它就自動擴了，冗餘就上來了，這是動態擴容。彈性調動也是如此，用的同一個技術體系。

面向將來架構，從新定義服務化

在開發過程當中會遇到不少問題，原來作服務化，所提供的是一些Lib、Jar包或是像接口之類的，可是如今已經再也不依賴那些，如今依賴的是服務，Service Mesh 裏甚至都沒有Client和Server的概念了，都是Service。可是在Motan裏面，是有Client和Server的。它有兩端，由於要去發調動，兩端的處理不同。調動不是通盤都按Service來說的，是經過服務發現，而後對Server 發起直連。這個過程致使須要每個實現跨語言的地方，都須要一些特殊的處理。

首先通用性方面，使用Motan來刻畫一個服務，如今再也不依賴包，而依賴於服務。提供的時候，告訴這個服務，註冊到那個分組下，調動那個分組下面的服務就能夠了，一個很簡單的RPC服務調用的方式，上面會有協議，節點和版本號相似的數據，用URL來惟一刻畫一個服務。

微博有歷史包袱，但願已有的系統不要改動太多，以最小的成本獲得最大的收益。因此，咱們對原來基於 Jersey 開發的 Cedrus Restful 框架進行了適配，在Motan框架層面把原來全部的Restful 接口自動導出爲Motan RPC 服務，經過這種方式減小改造的成本。原來改造的時候，須要把全部 Restful 服務都重寫成RPC服務，成本特別高。

支持協議，好比支持GRPC，前面有GPRC能夠去調，如今支持HTTP，HTTP對等的是Cedrus（其實就是Servlet）。它其實中間傳輸的是Motan協議，可是能夠按照HTTP的方式調動一個Motan服務，這樣的話，Client也不須要改任何一行代碼。

咱們對WeiboMesh 的一些思考，Weibo Mesh 跟一般的Service Mesh 有本質的不一樣，咱們對服務的調用是經過服務發現後直連的，不是經過攔截和轉發。一般Service Mesh 不能直接知足咱們的需求，可能你們也有不少相似的場景。因此這些思考但願能給你們一些借鑑的意義。

Weibo Mesh的服務調用須要更輕薄的Motan Client，一個緣由是下降已有架構的改形成本，一個是泛服務化的概念。好比訪問微博，須要調動用戶的服務、微博的服務，評論的服務，可是後端的底層資源，好比說MC，Kafka等的資源都是服務，若是把這些資源用 Motan 協議來實現資源服務化，只須要一個Client就能完成全部的服務調用。並且服務治理體系，流量管控體系均可以複用，解決了你們在開發的時候面對各類資源的不一樣Client實現而各類調研，選型。微博基於OpenResty 實現了 Motan-OpenResty 版本，就是想以此來對OpenResty 社區在資源服務化方面實現複用，提供更多更方便的服務。

基於泛服務化理念，經過輕薄的Client，就能夠調全部服務。雖然改造的時候須要改一點代碼。泛服務化跟 Istio的思路不同之處還在於，泛服務化不止針對本身開發的應用級服務，還有一些底層服務，資源的服務。他們均可以經過封裝爲簡單的 Motan2 協議來進行簡單的訪問，全部功能都是可編程可擴展的。用過Motan的人都知道，Motan在作擴展的時候特別簡單，好比說要加一個通用的邏輯，不管是擴展一個Filter 仍是新增一種HA策略，這個架構是一個可編程，泛服務化的架構。

Weibo Mesh後期規劃

微博是混合雲架構，若是是新的公司可能就直接上雲了，因此咱們後期也考慮在雲原生計算方面作一些支持。出於微博自己的技術須要，咱們還會在服務治理的總體方案方面作更多的嘗試。咱們也但願Weibo Mesh 能作成更通用化的服務方案，讓更多團隊受益。

另外，Motan還有Motan—Openresty 版本。出於我我的對OpenResty的理解，我認爲OpenResty 多是目前惟一稱得上服務器應用開發平臺，把Nginx 做爲一個開發平臺，在上面開發各類服務，並且是基於極其簡單、表現力極強的Lua開發。最使人欣喜若狂的是，重啓維護的Stream-lua 模塊讓OpenResty不止能開發 HTTP 服務，一樣能開發 TCP、UDP 服務。基於此的 Motan-OpenResty 能夠複用 OpenResty 積累的一切，我但願能在Openresty方面作一些事情。

由於就Mesh體系來說，你們可能都是有包袱的。當有既有技術體系的時候，Java應用或者其餘應用，前面都掛着Nginx，從Nginx 到OpenResty 的遷移成本幾乎爲零。在整個流量分發當中，它起到比較關鍵的做用，若是能在這一層上作一些事情，那是否是把不少改造的工做又減輕掉了，平臺本身來解決不少問題，應用級別就不須要搞，由於如今比Istio，感受須要強化一點在於說，有一個Client，須要你們改一點代碼，可是又但願能不能更少的成本，因此我須要作這樣的一些事情，這是我本身後期的一個摸索的方向。但願一樣對這種思路感興趣的同窗能一塊兒參與，自己整個體系都是開源的，歡迎你們有什麼想法或者是有什麼問題提出來，一塊兒來作。

由於以爲在這個方面走的也不算特別早，也不晚，如今在業務場景上真正落地的Mesh的，微博應該是比較早的，而那個Motan-Openresty版本多是基於最新的Openresty Stream模塊開發的。那個如今也做爲Openresty社區比較標準版的Stream模塊開發樣板項目，也但願你們多多的關注，我今天的分享就到這，謝謝你們。

關注Service Mesh中文網公衆號(帳號ID：servicemesh），回覆1216，便可下載本次演講實錄PPT.