技術沙龍 | 雲時代下的架構演進—企業雲及雲原生技術落地實踐

雲改變了IT行業的形態和市場格局，催生了應用的發展。隨着雲計算技術的不斷演進，做爲一名優秀的架構師，必須深刻了解雲計算平臺的特色及架構設計，包括構建數據庫、大規模落地微服務、Service Mesh和全鏈路監控等才能緊跟時代的步伐。

12月21日，京東雲開發者社區和英特爾聯合舉辦的「雲時代下的架構演進—企業上雲及雲原生技術落地實踐」沙龍在北京順利召開，在本次活動中來自京東技術專家從頂層視角解讀京東集團的雲化之路、京東物流的上雲之路、探尋數據庫上雲的探索之路、京東雲的落地服務網格和DevOps系統，五個模塊同現場的百位技術從業者進行了分享與交流。

1 京東的集團上雲之路

京東雲客戶成功部架構師 湯源

對於京東雲來講，一定要走一條與其餘雲廠商不一樣的道路，而京東雲認爲，集團上雲就是京東雲與其餘雲廠商的重要差別點。所以，集團上雲在京東內部就是一個戰略方向，京東雲客戶成功部專家級架構師湯源解釋道，京東的戰略就是構建以零售爲基礎的技術與服務。這個技術服務是TO B的技術與業務能力，須要去變現，它必需要有一個商業平臺，所以，京東集團作公有云，在戰略層面是堅決不移的。京東內部也是很是全面的去認識集團上雲，但京東雲的集團上雲，並非說要轉變京東雲的業務方向，也不是狹義上集團把自有業務遷移上雲（Cloud Migration），咱們京東雲將集團上雲細分爲自用上雲、回家上雲、投後上雲、賦能上雲、推薦上雲五個場景，來區別對待，因此說京東雲的集團上雲是一個廣義上借上雲來探索雲化之路（Cloud Transformation）。在這個前提之下，京東雲集團上雲的路徑實際上也就是京東雲做爲整個集團的技術服務後臺的路徑，同時，這也是集團技術轉型自身的發展思路一脈相承。

若是咱們從Cloud Transformation這個視角來解讀，你們可能知道，早期的京東技術體系，仍是基於Microsoft .Net技術棧的，因此，大概在2012年先後，京東決定要把.Net技術棧轉成基於Linux的開源技術棧，到了2015年，京東有第一朵雲問世，實際上就是京東作了一個私有云。京東把零售的業務、全部的計算，包括數據庫都作了容器化和資源池化，也作了一套基於開源的中間件體系，包括應用的治理。

2015年下半年，京東開始研發公有云2016年的4月京東雲正式開始提供公有云服務。

2019年，劉總提出集團上雲，將集團上雲做爲京東的戰略目標。這就是所謂的京東雲2.0階段，在此階段，京東將私有云和公有云打通，作成混合雲，利用混合雲架構來作集團的自用上雲。

湯源表示，京東計劃在明年到後年完成自用部分的上雲，到後年年末，將京東集團的全部業務都遷移到京東雲上。這就是一個Cloud Migration的過程，完成這個過程以後，或這過程當中的一些新業務，京東雲的CloudTransformation還會採用雲原生（Cloud Native）模式。

那麼，京東是如何理解、推進和執行集團上雲的？從京東雲的視角來看，京東集團的技術棧它分爲四個層次，底層是一體化物理層，主要是IT硬件基礎設施，這部分京東雲與英特爾有比較深刻的合做，包括CPU的定製。最上層是產品化的場景化服務。中間層是組件化能力和平臺化能力層，實際上就是一箇中臺的概念，京東雲把中臺分爲業務中臺和技術中臺，在業務中臺注重組件化，由於業務都是很是複雜的，研發人力重與時間週期長。同時，業務中臺承載了京東全部的營銷、交易、商品等系統。這樣，就能夠消弭以前的煙囪式的軟件架構，根據不一樣的業務場景去組合來提供快速的交付，提高業務賦能的速度，這個在京東零售出海東南亞獲得了很好的應用實踐。在技術中臺方面，則把IaaS、AI、包括數據平臺都集中在了技術中臺之中。

衆所周知，京東集團有很大的體量，也有很豐富的產品，同時也具備豐富的業務場景。不管是在計算仍是存儲的量級上，都是很海量的，這些豐富的場景對於京東雲的公有云平臺和產品的成熟度有着很是有效和快速的促進做用，在內部京東雲也把集團內部客戶做爲一個超級VVIP，這樣也鍛鍊了做爲To B業務的公有云團隊在規劃方案、交付、技術服務方面的能力。所以，其實是京東的業務發展和技術轉型戰略驅動京東走上了集團上雲之路。

但在京東的集團上雲之路中，安全問題、包括數據資產安全問題以及這樣一個大致量富場景雲遷移中的實際問題，其實都給京東雲帶來了很大的挑戰，但京東雲經過保持安全邊界、適配安全監控、對於新業務直接採用雲原生方式以及選擇組合多種遷移方式等方法在2019年作了積極探索，並將在接下來的兩年中完成集團上雲2.0階段的Cloud Transformation。而京東雲通過這四年多的發展，無論在豐富度仍是成熟度、穩定度上，都有足夠說服力讓咱們的內外用戶能夠放心上、大膽上京東雲。

同時，在接下來的京東雲3.0階段，京東雲還會在安全、數據處理、遷移方式方面繼續發力，讓用戶能夠更加放心的使用京東雲。

2 京東物流系統上雲實戰分享

京東物流集團基礎保障部架構師 史季強

京東物流集團基礎保障部架構師史季強則主要從啓動上雲、遷移準備工做、遷移過程詳解、案例解析、收益和問題、願景規劃六個方面對物流系統上雲實戰進行了分享。

史季強表示，京東物流之因此須要遷移上雲，除了整個京東集團上雲戰略上的考慮，從物流集團內部自驅來看有三點考慮，即輕資產化、下降成本、架構升級。

物流是很是重資產的行業，要有庫房、大量的員工還有物流系統也是很是龐大的，而這麼大致量的系統卻常年跑在不少物理機上面，隨着時間的推移，這些物理機可能過保或者損壞，帶來了大量的維護成本，而隨着業務的發展，還要採購更多的物理機，這就致使資產會愈來愈重。而從整個互聯網趨勢來看，你們都是但願本身的架構愈來愈輕，資產愈來愈輕。

第二就是下降成本，你們都知道雲計算的特色就是虛擬化和共享化。若是資源在不使用的時候能夠回收掉，使用的時候能夠採用按需申請，包括計費的模式，就能夠按小時按天進行計費。這樣對集團內部資產進行規劃，對於集團制定服務器的預算都有很好的幫助。

第三，若是隻是簡單的把系統搬到雲上去的話是沒有任何意義的，僅僅把系統服務器部署從私有云搬到公有云上意義也不大，真正有意義的是，在這個遷移的過程當中，能夠對自身的系統架構進行梳理，同時也能夠對陳舊的、過期的和如今業務發展不太匹配的系統架構進行必定的升級，包括雲原生的架構，這是一個很是好的機會。

而這三點就是京東物流啓動上雲的驅動力。

在肯定了上雲的策略以後，接下來就是遷移的準備工做，而這些準備工做首先就要從架構的從新設計作起，史季強表示，這是由於京東的物流系統很是複雜，不太可能照搬原來的架構直接遷移上雲。所以，就須要對原來的物流架構進行有效的梳理。

而從物流系統框架圖來看，在上層，京東物流有不少的業務模塊，包括冷鏈供應鏈、最大的客戶商城等，這些支持的系統及數據平臺是很是複雜的。此外，這些系統上還包含了底層的業務中間件、最底層依賴的基礎設施數據庫及緩存各類存儲，整個系統都是龐大且複雜的。

爲此，在肯定新的雲上架構時，採用了VPC架構，VPC是某一個BG有獨立虛擬的私有云區域，在這個區域中能夠劃分不一樣的子網，根據不一樣業務類型，將其放在不一樣的子網裏。這樣作的最大的優點在於，安全上有必定的隔離，流量上一樣也是。同時，因爲在新架構中同時包含了對公子網、業務子網和數據子網，而物流系統中有不少對外提供公共服務的系統，經過VPC架構，則能夠將它們與私有環境分離開，從而保證了物流系統的安全性。

在將基礎架構環境定義好後，下一步是啓動遷移工做。這其中包括上線、配置CMDB、部署監控等 。史季強表示，在遷移前監控的事情必定要作好，這其中包括資源監控和性能監控，不然上線以後系統運行就處於一個沒有監控的狀態，公有云平臺提供的相關資產和監控工具更主要面向商業客戶，適合小規模的公司，若是是大型公司，那必須在這些方面要根據OpenAPI有本身定製化的設計。

史季強詳細介紹了京東物流遷移的過程。首先是雲主機的遷移，研發經過Jone發佈到應用，同時發佈到私有云分組和公有云分組，運行到必定階段比較穩定後，那麼就從中間切開，至關於全部的應用實例都跑到公有云分組。基於這種模式，物流研發的全部應用基本上都在公有云上進行了部署，部分的系統徹底把私有云分組設備資源下掉，只保留在公有云分組。

京東物流以前使用的是自研的分佈式緩存服務（JIMDB），通過調研，雲團隊提供的緩存產品具有更大的優點，雲緩存是基於Redis協議的在線緩存服務，能夠知足大部分業務對可用性、可靠性和高讀寫性的要求，支持雙機熱備、自動容災切換、彈性擴容等特性，通過雙方反覆的磨合，在產品化的基礎上，Redis向物流定製了主從版及集羣版，物流能夠按需選擇，更加靈活，更加容易控制成本，此外在用戶接口層除了控制檯及SDK外，經過OpenAPI將雲管能力集成到物流系統中，實現共同治理。從JIMDB到雲Redis的數據遷移，要求業務不能中斷，雙方制定了可持續讀寫的全量與增量實時同步方案，通過反覆的測試與實踐，目前已支持全自動同步，遷移效率大大提高。

可是數據庫上雲的遷移相比應用服務器遷移，難度要高出不少，畢竟線上海量數據的複製轉移很難在短期完成，並且生產時段的遷移還可能會影響到線上數據庫的穩定性，對於遷移時間窗口也有很嚴格的要求，所以對於數據庫的遷移方案是慎之又慎。通過多方論證和測試，咱們採用如下兩種方式進行數據遷移：

數據庫原生的主備模式：主要針對核心系統數據庫，要保證數據庫遷移過程當中，若是有任何的問題，均可以作到新老集羣的快速切換，這樣的場景只有mysql原生的主從複製模式是最爲合適的。可是要保證私有云mysql數據庫的版本和RDS數據庫版本一致，對於5.6和5.7版本還須要開啓GTID，所以這種方式只能適合少部分系統。

使用自研的DTS工具，數據蜂巢Dcomb：Dcomb是一款輕量級的數據處理平臺，支持Join，Union，Where和用戶自定義邏輯同步等功能，支持從MySQL到MySQL、ES、Cassandra、JDQ、MQ、PostgreSQL等目標端的實時數據同步，平臺基於分佈式架構，具備高可用及負載均衡等特色。大多數數據庫上雲都採用數據蜂巢進行。

雖然數據庫遷移過程比較艱辛，但遷到公有云以後仍是有不少收益的，這其中包括故障恢復快、產品豐富、接口規範、智能監控、自動備份和快速部署。

史季強最後表示，京東物流在上雲過程當中算走在京東集團的最前列，截止目前已經有超過90%的應用在公有云上部署了實例，包括今年的雙11.11大量業務都是運行在公有云上，在業務流量超過了三倍以上的狀況下，總體運營仍是比較平穩的，後續京東物流還將持續推進系統去雲。上雲要作架構升級，不是簡單的搬遷。而將來，京東物流的願景有四個方向，分別是容器化的軟件部署模式、服務器資源利用率的提高、架構優化，服務治理以及基於公有云的基礎平臺，進行流程化的質量和效能平臺建設。

3 京東數據庫上雲探索之路

京東雲產品研發部專家架構師 張成遠

京東雲產品研發架構服務架構師張成遠講述了京東數據庫上雲探索之路。張成遠從傳統運維時代到雲時代、上雲的條件與時機、如何上雲以及雲時代DBA職業發展思考四個方面爲你們分享了他對數據庫上雲的深入理解和豐富經驗。

爲何要把數據庫上雲？緣由是顯而易見的，由於雲數據庫具備高度的彈性和擴展性，而這些對於京東這樣的電商應對例如61八、雙11.11等購物節帶來的突發海量流量的狀況是很是適合的。

京東雲數據庫能提供數據自動備份保證數據高可靠、實現自動高可用切換、在線擴縮容以及一整套完整的監控報警體系等功能，可以保證用戶數據安全、有效提高業務可用性，輕鬆應對突發訪問流量。

關於上雲的條件和時機，張成遠給出了他本身的理解：一是建議創業者直接用雲。創業者應該聚焦真正想作的事情，基礎設施建設對於創業者所作的業務來說每每不是核心內容，直接用雲就好。二是已有本地IDC服務。這種狀況下能夠作兩種考量，一是業務發展趨於平穩，但所用機器四年左右過保了，過保之後怎麼辦？二是業務繼續發展，機器繼續採購，但機房裏須要新增機架比較困難怎麼辦？

張成遠最後總結，他表示上雲的關鍵是數據庫遷移。分幾種狀況，第一種狀況是新部署的業務或者歷史數據能夠歸檔的業務，數據不須要往上遷，這是最簡單的，直接申請建立新的數據庫便可。第二種狀況是數據要遷移，這個事情比較麻，須要進行不少評估，好比數據量有多大，數據不可寫程度怎麼樣，業務容許中止的時間等。遷移過程當中可能會有一個階段是應用跨IDC訪問數據庫，此時很容易遇到的一個問題是網絡延遲，網絡延遲可能只是增長一毫秒，但在交互次數較多的狀況下，整個業務的延遲也會被嚴重放大，對業務影響比較大，有些甚至是業務系統層面要作相應的優化，因此數據庫遷移上雲是一個須要綜合考慮的事情。

4 Istio服務網格入門指南

京東雲產品研發部專家架構師 王碧波

衆所周知，lstio是業界關注度最高、生產環境落地最多的服務網格系統。王碧波從服務網格概念、Istio功能、Istio場景、Istio使用難點、京東雲和Istio五個方面帶來了Istio服務網格入門指南的課程分享。

首先，王碧波以老人和小孩對於數字技術的不一樣態度做爲類比，闡述什麼是雲原生的應用。他認爲，在應用一開始設計和實現的時候就充分採納能利用雲彈性、基礎組件豐富等優點的技術，這樣的應用就是雲原生的應用。而微服務和容器就是雲原生技術的典型表明。

王碧波表示，微服務簡單來講就是把大業務切分紅小單元的服務，以更加方便管理和維護，由於功能單一的小單元相對於複雜的系統更容易進行研發、優化和調整。涉及到微服務，就不得不談到切分和配合。切分不僅是指切分業務邏輯，同時還須要將數據、配置、工具、運行環境等與業務邏輯分離。關於如何拆分，能夠參考康威定律，領域驅動設計、十二要素等思想和方法。其次，是與微服務的配合，包括服務之間的關係什麼樣，服務依賴的其餘服務怎麼配合，服務與所依賴的持久化服務怎麼配合，和研發上線過程怎麼配合，問題定位怎麼配合，配合是比拆分更大的話題。所以就產生了新的概念叫服務治理，服務治理主要就是解決這些微服務之間怎麼配合的問題。

王碧波認爲，服務治理的能力能夠分紅如下五類：流量治理、安全治理、生命週期治理、業務輔助、服務觀測。流量治理包括從最基本的服務發現，到負載均衡，熔斷、調用協議、策略路由、流量複製錯誤、信息注入，API管理等，主要解決流量的管理。安全治理就是如何保證代碼運行、數據配置等方面的安全。生命週期管理包括CI、CD的機制，關於服務部署怎麼作、彈性伸縮和故障恢復怎麼作等等。業務輔助提供一些標準的基礎能力，幫助業務實現功能邏輯。服務觀測解決如何準確掌握系統的運行狀態，以及若是有線上問題如何能快速定位問題。

而服務治理能力時有兩種使用方式，一種能夠稱之爲集成方式，另一種是服務網格。前幾年更可能是集成方式，業務須要引入不少服務治理相關的庫，與開發語言和框架耦合較緊。後來誕生了服務網格這一類的技術，其核心理念就是把業務模塊和服務治理完全的切分開。這使得開發人員徹底不用關注業務，直接在網絡代理裏面中就可進行。並且服務網格還能夠在不須要作任何的研發的狀況下，直接進行線上的配置就能夠實現想要的一些功能。後續有新的治理需求時，也能夠直接經過網格來統一提供和配置，起到「一次接入、持續受益」的效果。

在服務網格的技術框架中，Istio是目前比較流行的技術框架，它具備架構清晰、功能完整、實現開放等諸多優勢，其中Galley解決配置管理的問題、Pilot能夠作服務發現，客戶端負載均衡，還能夠根據Host、Path、Header等靈活配置路由，靈活配置容錯。Mixer的功能則包括配置調用Quota、權限策略、請求轉換邏輯等，同時它還負責各類觀測數據的收集。

王碧波介紹說，京東雲是在2018年中開始嘗試使用服務網格，到2019年末已經有一百多個應用在服務網格里運行了。爲了保證穩定性，京東雲創建了比較完備的測試和質量評價的體系，Istio的每一個版本，放到測試框架裏面持續運行，以便及時發現問題。另外，京東雲的團隊裏邊也有不少關於網絡和服務治理的專家，在選定版本以後，假設後期發現該版本有比較嚴重的問題，這些專家有能力進行修改。在使用體驗方面，京東雲也作了不少簡化工做。同時，還研發了大量線上運維工具。另外，還整合了內部的關於安全、Devops、觀測等系統，讓各團隊能夠更容易的應用網格的各類功能。最後，京東雲投入了很大的精力在各個團隊配合和接入上，服務網格有不少新的理念、新的用法，和原有方式是有很大差異的，須要作不少的溝通探討。

下面是最終效果的示意圖：底層devops系統解決一些資源管理、應用管理、日誌權限等等一些事情，服務網格解決了服務發現、調用服務、安全治理、調用鏈等問題，最終使得各業務能夠靈活的灰度，伸縮，簡化部署過程，優化流量管理，得到原生安全能力以及更好的觀測能力。

經過內部一年多的線上運維，京東雲積累了豐富的線上運維經驗。京東雲已經將這些能力和經驗產品化，推出了雲服務網格產品，歡迎你們試用。

5 雲原生下的DevOps實踐

京東雲產品研發部架構師 井亮亮

井亮亮從雲原生 & DevOps、雲原生下的 DevOps 發展演進以及京東雲 DevOps 案例三個方面進行了闡述。

雲原生 & DevOps：雲原生貫穿瞭如今軟件的整個研發週期，重塑了整個軟件研發生命週期，是雲原生是提出的一個概念，它是一個思想的集合，包括（DevOps、持續交付、微服務、容器）。能夠說雲原生既包含技術（像微服務、容器這種基礎設施），也包含管理（DevOps，持續交付），還有例如像康威定律，重組等。雲原生也能夠說是一系列Cloud技術、企業管理方法的集合。

DevOps一樣是比較抽象的東西，DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。每一個企業環境不同，角度不同，DevOps解決的問題也是不同的。

雲原生下的 DevOps 發展演進：最明顯顯著的就是基礎設施的變化。在雲原生以前，咱們的服務是這樣的，最底層是傳統的IDC，機房、硬件、網絡、的基礎上，服務app通常是會部署在物理機中的，或者是基於物理機進行虛擬化的虛擬機中。研發和運維不只僅要關注業務，也得關注硬件以及網絡等資源。在雲原生時代，或者說雲的時代。咱們只需關注app，業務層。底層資源雲廠商都幫咱們解決了。咱們能夠花更多的時間在業務研發上。更加聚焦業務的研發。這是基礎設施的變化。

第二部分就是軟件交付方式的變化。隨着技術的不斷髮展，軟件的交付方式也發生的巨大的變化。爲了將資源最大化，這時候軟件會發布到虛擬機中，爲了提高發布效率，發佈方式也變成了腳本化。隨着資源的不斷增長，虛擬化技術的發展，慢慢地企業都開始自建私有云，隨着業務的發展，發佈的方式也變成了自動化發佈。你們也知道隨着容器技術的成熟，容器成了應用發佈交付的標準。隨着公有云的發展，好多企業開始擁抱公有云，提高企業的效率和成本，那麼企業內的發佈方式變成了容器和包共存。企業的基礎設施架構也基本上都是混合雲的模式。發佈的方式，在自動化的基礎上開始智能化，想彈性伸縮，故障自愈變的愈來愈受到推崇。

京東雲 DevOps 案例：在第三部分，井亮亮分享了京東雲構建DevOps的經驗。

這些年，不少企業都把多雲做爲企業的戰略，雞蛋不會都放在一個籃子，那又怎麼支撐整個多雲戰略挑戰呢？咱們經過摸索和實踐證實，配置管理CMDB是企業內部實施DevOps的基礎，決定了整個DevOps的成功和失敗。

京東雲的CMDB模型以應用爲核心，管控整個資源的層面，把整個業務的模型服務數的形式表現出來。關於系統怎麼使用這數據，CMDB準確性十分重要。整個CMDB模型的構建並不完善，有如下三個點供參考：第一個是提供最簡單的界面錄入方便研發、測試、運維把整個數據貫徹進去，另外須要提供API，讓關聯的業務系統可以方便把數據關聯起來。最後是經過Agent採集的方式，把一些機器中數據經過agent主動採集上報上來。確保cmdb數據的準確性。

第二個是客戶端資源的挑戰，據據2019年devops中國社區的統計報告數據，顯示有超過五成的企業在管理100臺以上的機器。在這麼多機器上，就會帶來一系列客戶端的挑戰，可能會面臨機器中各類Agent多、各類資源限制、存活守護、部署後更新升級和維護髮布等問題。基於這樣挑戰，咱們構建了超級Agent。根據業務訴求，具體到不一樣的業務Agent。

第三個是持續交付。早期，咱們的方式都是代碼包的形式，這些年隨着傳統的基礎設施從自建或者託管IDC機房的方式，轉變向公有云、混合雲；軟件架構也都在向微服務方向靠攏，部署的方式也由原來的包部署變成docker鏡像的方式，Docker 鏡像造成了應用分發和交付的標準，能夠將應用與底層運行環境實現解耦；所以在持續集成方面，不只僅須要支持代碼包的構建，也須要支持鏡像的方式，但最終全部的構建產物需以版本化的方式分別存在製品庫中。持續集成一方面除了要作構建，另外也會經過流水線的方式把代碼的靜態檢查，安全漏洞檢查結合起來一塊，提高代碼質量和安全。關於構建語言這塊，由於全部的構建都在鏡像中，那麼需提供各類語言的編譯鏡像，固然用戶可根據需求，定製一些本身特殊的編譯鏡像；docker的構建，咱們會提供統一的運行鏡像，這樣會規避一些os環境不一致，或者操做系統版本不一致的狀況。這是CI方面。

部署有兩方面，一個包的部署，一個容器的發佈。包的發佈整個CMDB有業務模型，向上構建業務模型，向下構建資源模型，設置好整個部署的一些策略就能夠去作發佈。容器發佈注意兩點，第一點是把一些偏計算應用放在容器裏面應用，作到整個容器的日誌存儲和展現。第二點是必定要打通關聯繫統。另外，每家企業的需求不同，彈性伸縮也不同，能夠根據業務場景擴縮或按需擴縮。複雜業務場景支持編排部署，其特性就是能夠實現暫停設置、併發設置、自動重試、失敗閾值、一鍵回滾等。同時，故障自動處理機制能夠實現實時發現告警，預診斷分析，自動處理恢復故障，並打通周邊系統實現整個流程的閉環。如下是DevOps能力全貌。

最後井亮亮分享了在企業如何落地實施DevOps。第一步考慮清楚爲何要改變，找到你的痛點是什麼，哪一個地方有問題。如何獲得支持。第二步分析現狀，有兩種方式，一是基於現有的DevOps能力成熟模型，自查企業中DevOps哪一個階段須要提高，二是找諮詢公司。找一些外部顧問深刻企業團隊中，評估哪些環節須要提高。第三步是分析現狀去設計要解決什麼問題，是採購仍是基於開源，抑或是本身研發，根據企業現狀設計出來一套DevOps模型。最後也是最難的一點就是推廣，在設計工具時必定要考慮到兼容性。在你們不肯意改變的狀況下，先進行試點，實質產生價值後進行規模化複製。

看了這麼多，你們有沒有收穫滿滿呢，若是您想了解更多關於沙龍的相關訊息，請點擊「閱讀」，進入京東雲開發者中心查看沙龍視頻~