256
企業級API網關的設計
本文目錄：
一、網關簡介
二、網關的作用和價值
三、企業級API網關需要具備的條件
四、業界常用的API網關方案
五、如何設計一個好的企業級API網關產品
六、小結
一、網關簡介
1.1 API網關背景介紹
API Gateway（APIGW / API 網關），顧名思義，是出現在係統邊界上的一個麵向API的、串行集中式的強管控服務，這裏的邊界是企業IT係統的邊界，主要起到隔離外部訪問與內部係統的作用。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機係統，它也是解決訪問認證、報文轉換、訪問統計等問題的。
API網關的流行，源於近幾年來，移動應用與企業間互聯需求的興起。移動應用、企業互聯，使得後台服務支持的對象，從以前單一的Web應用，擴展到多種使用場景，且每種使用場景對後台服務的要求都不盡相同。這不僅增加了後台服務的響應量，還增加了後台服務的複雜性。隨著微服務架構概念的提出，API網關成為了微服務架構的一個標配組件。
1.2 網關的幾種使用場景
我司王延炯博士的文章《談API網關的背景、架構以及落地方案》中，提到了網關的幾種使用場景：
1、麵向Web App的網關
這類場景，在物理形態上類似前後端分離，此時的Web App已經不是全功能的Web App，而是根據場景定製、場景化的App。
2、麵向MobileApp的網關
這類場景，移動App是後端Service的使用者，此時的APIGW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。
3、麵向PartnerOpenAPI的網關
這類場景，主要為了滿足業務形態對外開放，與企業外部合作夥伴建立生態圈，此時的API GW需要增加配額、流控、令牌等一係列安全管控功能。
4、麵向PartnerExternalAPI的網關
這類場景，主要是為了滿足企業自身業務的需要，實現對企業自有業務的映射。一個典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平台支付」等等。此時的APIGW就需要在邊界上，為企業內部Service 統一調用外部的API做統一的認證、授權、以及訪問控製。
5、麵向IoTSmartDevice的網關
這類場景主要在傳統企業，尤其是工業企業，傳感器、物理設備從工業控製協議向IP轉換，導致物理鏈路上會存在一部分公網鏈路。此時的API GW所需要滿足的「內外兼修」的雙向數據流，設備一般通過一個「客戶側」的集中網關在和企業的接入網關進行通信。
在我們講的微服務架構下的API網關，一般指的是前兩種使用場景。即，主要是把企業內部的API能力，暴露給其他應用或合作夥伴使用。
二、網關的作用和價值
網關層作為客戶端與服務端的一層擋板，主要起到了三大類作用：
第一類作用是隔離作用，作為企業係統邊界，隔離外網係統與內網係統。
第二類作用是解耦作用，通過解耦，使得微服務係統的各方能夠獨立、自由、高效、靈活地調整，而不用擔心給其他方麵帶來影響。
第三類作用是腳手架作用，提供了一個地點，方便通過擴展機製對請求進行一係列加工和處理。
2.1 內外的隔離
企業為了保護內部係統的安全性，內網與外網都是隔離的，企業的服務應用都是運行在內網環境中，為了安全的考量，一般都不允許外部直接訪問。API網關部署在防火牆外麵，起到一層擋板作用，內部係統隻接受API網關轉發過來的請求。網關通過白名單或校驗規則，對訪問進行了初步的過濾。相比防火牆，這種軟件實現的過濾規則，更加動態靈活。
2.2 多方的解耦
在微服務架構下，整個環境包括服務的提供者、服務的消費者、服務運維人員、安全管理人員等，每個角色的職責和述求都不同。例如：服務消費者已經需要提出一些新的服務需求，以快速應對業務變化；服務提供者，作為業務服務的沉澱方，希望保持服務的通用性與穩定性，很難應對快速的變化。有了API網關這一層，可以很好的解耦各方的相互依賴關係，讓各方更加專注自己的目標。
1、解耦功能與非功能
企業在把服務提供給外部訪問時，除了實現業務邏輯功能外，還麵臨許多非功能性的要求。例如：需要防範黑客攻擊，需要應對突發的訪問量、需要確認用戶的權限，需要對訪問進行監控等。這些非功能邏輯，不能與業務邏輯的開發混在一起，需要有專業的人員甚至專業的團隊來處理。
2、解耦客戶端與服務提供者
客戶端與服務提供者分屬於不同的團隊，工作性質要求也不相同。對於服務提供者來說，他主要的職責是對業務進行抽象，提供可複用的業務功能，他們需要對業務模型進行深入的思考和沉澱，不能輕易為了響應外部的需求而破壞業務模型的穩定性。而業務的快速變化，又要求企業快速提供接口來滿足客戶端需求。這就需要一個中間層，來對服務層的接口進行封裝，以及時響應客戶端的需求。
通過解耦，服務層可以使用統一的接口、協議和報文格式來暴露服務，而不必考慮客戶端的多種形態。
3、網關層是否需要實現服務的編排？
在介紹API網關的一些文章中，提到了網關層的服務編排能力。從解耦的角度出發，服務的編排不適合在網關層進行。對服務的編排，其實是提供了一種業務能力，如果把服務的編排放在了網關層，實際上是把一部分業務能力放在了網關層，這樣一來，服務層、網關層都有一些業務能力，造成團隊職責的不清，也不利於業務能力的沉澱。
2.3 插件的腳手架
網關層除了請求的路由、轉發外，還需要負責安全、鑒權、限流、監控等。這些功能的實現方式，往往隨著業務的變化不斷調整。例如權限控製方麵，早期可能隻需要簡單的用戶+密碼方式，後續用戶量大了後，可能會使用高性能的第三方解決方案。又例如，針對不同的監控方案，需要記錄不同的日誌文件。
所以，這些能力不能一開始就固化在網關平台上，而應該是一種可配置的方式，便於修改和替換。這就要求網關層提供一套機製，可以很好地支持這種動態擴展。
2.4 帶來的好處
這裏總結下網關的價值：
網關層對外部和內部進行了隔離，保障了後台服務的安全性。
對外訪問控製由網絡層麵轉換成了運維層麵，減少變更的流程和錯誤成本
減少客戶端與服務的耦合，服務可以獨立發展。通過網關層來做映射。
通過網關層聚合，減少外部訪問的頻次，提升訪問效率。
節約後端服務開發成本，減少上線風險。
為服務熔斷，灰度發布，線上測試提供簡單方案。
便於擴展。
三、企業級API網關需要具備的條件
3.1 微服務架構下，企業API網關的定位
API網關作為對外提供服務的入口，就像企業服務的大門。一方麵，要有足夠的能力，應對大量的對外訪問，另一方麵，還要給對內的服務提供一定的安全保障。
除此之外，企業提供的API服務多種多樣，API網關要能夠對這些API的全生命周期進行便捷的管理，例如服務發布、調整、下架、計費、監控等。
3.2 企業環境下，API網關需要考慮哪些要素
1、安全性問題
企業在把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對公司業務的影響，特別是涉及交易方麵的服務，更是要全麵考慮安全性。為確保安全，需要考慮在通訊鏈路的建立、通訊數據的加密、數據的完整性、不可抵賴性等方麵。
2、性能問題
作為企業API的入口，所有的請求都會經過API網關進行轉發，可想而知，對API網關的訪問壓力是巨大的，有的網站甚至達到每分鍾上千萬的訪問量。特別是在一些互聯網企業，海量的移動終端每時每刻都需要與後端的服務進行交互，如果不能保證網關的高性能，企業在網關層需要投入大量的設備和成本。曾在一家互聯網公司發生過，由於網關性能問題，網關的機器數量，需要與後台服務器的數量保持同步增長。這種情況顯然是企業服務忍受的。
3、高可用問題
API網關作為邏輯上的單點，一旦發生問題，將造成企業服務的不可用，對企業來說可能造成的致命的影響。計算短時間的不可用，也會給企業帶來直接的經濟損失。所以，如何保證API網關的7*24小時的穩定運行，網關的自動伸縮、API的熱更新等問題，都是企業級的網關需要考慮的。
4、擴展性問題
前麵說到，企業網關提供了一個腳手架，一些非功能性的問題，例如日誌、安全、負載均衡策略、鑒權等。這些插件會隨著企業業務規模等的變化進行不斷的強化與調整。這就需要網關層提供這樣一種機製，使得可以靈活地進行這些調整和變化，而不用頻繁對網關層進行改動，確保網關層的穩定性。
5、API高效運維的問題
API在上線、發布過程中，都需要涉及到網關層的配合，例如，需要網關層知道API發布的地址，API的接口形式、報文格式，也需要網關層對後台API進行封裝。在API調整後，需要作出相應的修改。所以，API網關設計時，需要明確網關層與服務層的職責切分與協作模式，使得API的管理、發布更加高效。
6、API全生命周期管理的問題
API服務的全生命周期，包括服務的開發、測試、上線發布；服務使用的申請、開通；服務分類分級別的管理、服務使用情況的監控、計費等等。
一個企業可能會暴露成百上千個API，日常也會經常進行API的發布、升級、改造、下架等操作。對不同的服務，不同的訪問者，需要提供不同的服務訪問策略。有的商業API公司，還需要對API的使用進行付費。所以，與API網關配套的，需要一套完善的自助係統，提供給服務的提供者、管理者、使用者，來對服務的發布、使用、和運營。
四、業界常用的API網關方案
業界API網關解決方案有很多，包括商業的、開源的。例如Tyk、Kong、api-umbrella、apiaxle、Netflix zuul、WSO2 API Manager、clydeio等。下麵介紹三種常見的 API 網關方案。
4.1 Nginx+ Lua
Nginx是由IgorSysoev為俄羅斯訪問量第二的Rambler.ru站點開發的，一個高性能的HTTP和反向代理服務器。2012年，Nginx榮獲年度雲計算開發獎，並成長為世界第二大Web服務器。全世界流量最高的前1000名網站中，超過25%都使用Nginx來處理海量的互聯網請求。
Nginx基本功能：
靜態web資源服務器，能夠緩存打開的文件描述符
支持http/imap/pop3/smtp的反向代理；支持緩存、負載均衡
支持fastcgi(fpm)
模塊化，非DSO機製，支持過濾器zip壓縮，SSI以及圖像大小調整
支持SSL
Nginx通過插件的擴展功能：
基於名稱和IP的虛擬主機
支持keepalive的保持機製
支持平滑升級
定製訪問日誌，支持使用日誌緩存區提高日誌存儲性能
支持url rewrite
支持路徑別名（root或alias指定）
支持基於IP以及用戶的訪問控製
支持傳輸速率限製，並發限製
Nginx在性能和高可用性上的表現：
Nginx性能極高，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機製、極少的進程間切換以及許多優化設計，都使得Nginx天生善於處理高並發壓力下的互聯網請求。Nginx的穩定性也在各大網站得到驗證。官方提供的常用模塊都非常穩定，每個worker進程相對獨立，master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務。支持熱部署，可以不停機更新配置文件、更新日誌文件、更新服務器程序版本。
Nginx的擴展性：
Nginx的設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修複Bug或進行升級時，可以專注於模塊自身，無須在意其他。
Nginx的易用性：
Nginx使用最自由的BSD許可協議，允許用戶在自己的項目中直接使用或修改Nginx源碼，有大量的插件可以利用。但是，Nginx模塊需要用C開發，而且必須符合一係列複雜的規則。雖然通過第三方模塊，可以支持Nginx與Perl、Lua等腳本語言集成工作，但對使用者的要求還是很高。
Nginx可以說是一款能夠工業化API網關，在國內的很多互聯網公司，例如阿裏、新浪等都得到很好的應用。
4.2 SpringCloud Zuul
Zuul Netflix公司開源的一個API網關組件。提供了認證&鑒權、限流、動態路由，監控，彈性，安全、負載均衡、協助單點壓測、靜態響應等邊緣服務的框架。
Zuul的基本功能：
驗證與安全保障: 識別麵向各類資源的驗證要求並拒絕那些與要求不符的請求。
審查與監控: 在邊緣位置追蹤有意義數據及統計結果，從而為我們帶來準確的生產狀態結論。
動態路由: 以動態方式根據需要將請求路由至不同後端集群處。
壓力測試: 逐漸增加指向集群的負載流量，從而計算性能水平。
負載分配: 為每一種負載類型分配對應容量，並棄用超出限定值的請求。
靜態響應處理: 在邊緣位置直接建立部分響應，從而避免其流入內部集群。
Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
雖然提供的功能還算豐富，但都比較弱，很難滿足高要求的場景。
Zuul在性能和高可用性上的表現：
Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。通常情況下，為了提高性能，所有請求會被放到處理隊列中，從線程池中選取空閑線程來處理該請求。2016年底，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul 2將HTTP請求的處理方式從同步變成了異步，以提升其處理性能。除了Netflix公司，目前Zuul在企業中用的還比較少，性能和穩定性方麵還有待進一步觀察。
Zuul的擴展性：
從Zuul的架構圖上可以看出，Zuul更像是一個過濾器框架，其自身的路由、日誌、反向代理、ddos預防等功能都是通過過濾器實現的。提供了PRE、ROUTING、POST和ERROR四個擴展點，可以很容易的添加自定義的過濾器。
Zuul的易用性：
Zuul的搭建非常簡便，使用和配置也很簡單。Zuul的開源社區比較活躍，一直在更新狀態，但版本不算太穩定，在使用的過程中，還有一些坑要踩。例如重定向問題、異常處理問題，還沒有解決的很好，需要自己重寫一些filter。
如果從通盤考慮， 這種方案不是最佳方案。但如果自己的團隊對整體技術設施把控有限，且團隊規模不大，沒有專門的網關開發人員的情況下，Zuul是一款快速上手的最佳方案。
4.3 MashapeKong
Kong是Mashape提供的一款API管理軟件，它本身是基於Ngnix+lua的，但比nginx提供了更簡單的配置方式，數據采用了 ApacheCassandra/PostgreSQL存儲，並且提供了一些優秀的插件，比如驗證，日誌，調用頻次限製等。
Kong的一個非常誘人的地方就是提供了大量的插件來擴展應用，通過設置不同的插件可以為服務提供各種增強的功能。Kong默認插件插件包括：
身份認證：Kong提供了Basic Authentication、Key authentication、OAuth2.0authentication、HMAC authentication、JWT、LDAP authentication認證實現。
安全：ACL（訪問控製）、CORS（跨域資源共享）、動態SSL、IP限製、爬蟲檢測實現。
流量控製：請求限流（基於請求計數限流）、上遊響應限流（根據upstream響應計數限流）、請求大小限製。限流支持本地、Redis和集群限流模式。
分析監控：Galileo（記錄請求和響應數據，實現API分析）、Datadog（記錄API Metric如請求次數、請求大小、響應狀態和延遲，可視化API Metric）、Runscope（記錄請求和響應數據，實現API性能測試和監控）。
轉換：請求轉換、響應轉換
Kong本身也是基於Nginx的，所以在性能和穩定性上都沒有問題。Kong作為一款商業軟件，在Nginx上做了很擴展工作，而且還有很多付費的商業插件。Kong本身也有付費的企業版，其中包括技術支持、使用培訓服務以及API 分析插件。
從對上麵三種方案的比較中可以看到，Spring Cloud Zuul非常適合創業初期的團隊，快速搭建一個“基本可用”的API網關。Nginx適合有較強研發團隊，自主開發企業自己的API網關。Kong適合於沒有自身研發團隊，但需要擁有企業級API網關能力的公司。
五、如何設計一個
好的企業級API網關產品
5.1 功能上的考量
API 生命周期管理功能：
覆蓋 API 的定義、測試、發布的整個生命周期管理，便捷的日常管理、版本管理，支持熱升級和快速回滾。
開發和使用支持功能：
提供頁麵調試工具，自動生成 API 文檔和 SDK，大大降低人力成本。
安全防護功能：
API 請求到達網關需要經過嚴格的身份認證、權限認證，才能到達後端服務。支持算法簽名，支持 SSL 加密。
流量控製功能：
可控製單位時間內 API 允許被調用次數。用來保護企業的後端服務，實現業務分級和用戶分級。
支持對 API 流控，您可以根據 API 的重要程度來配置不同流控，從而保障重要業務的穩定運行；
支持用戶、應用和例外流控，您可以根據用戶的重要性來配置不同流控，從而可以保證大用戶的權益；
流控粒度：分鍾、小時、天。
請求管理功能：
可根據配置進行參數類型、參數值（範圍、枚舉、正則、Json Schema）的校驗，減少後端對非法請求、無效請求的資源消耗和處理成本。
可以在 API 網關定義參數映射規則，網關通過映射規則將後端服務通過映射翻譯成任何形式，以滿足不同用戶的不同需求，從而避免功能重複開發。
監控告警功能：
提供實時、可視化的 API 監控，包括：調用量、調用方式、響應時間、錯誤率，讓您能夠清楚的了解API 的運行狀況和用戶的行為習慣。
支持自定義報警規則，來針對異常情況進行報警，降低故障處理時間。
提供可訂閱的數據分析報表和智能分析。
API交易功能：
提供API交易市場，計量計費、Quota 控製、運營售賣等需求。
5.2 網關的高性能設計
傳統的基於線程的並發模型（Thread-based concurrency），為每一個請求分配一個線程或進程。這種模型編程簡單，可以將處理一個完整請求的代碼編寫在一個代碼路徑中。這種模型的弊端是，隨著線程(進程)數的上升，操作係統在這些線程(進程)之間的頻繁切換，將急劇降低係統的性能。
另一種更高效的並發模型是事件驅動的並發模型（Event-driven concurrency）。在這種模型中，每一個請求在係統被表示成一個有限狀態機（FSM）。每一個FSM的狀態表示請求的一係列的操作。服務器由一組線程/進程（一般是 one per CPU）循環處理各種來自隊列的事件(Event)。
這種模型要求每一個狀態的操作是短暫的並且是非阻塞的，所以 Event-driven concurrency模型一般都用了非阻塞的I/O接口（NIO）。
普元的產品中，為增加係統的吞吐量，是采用了基於事件的並發模型的SEDA的架構。SEDA架構的核心思想是：把一個請求處理過程分成幾個Stage，每個Stage可由不同的handle進行處理，不同資源消耗的Stage使用不同數量的線程來處理，handle之間采用異步通訊的模式。
詳細的SEDA架構介紹可以參見普元同事的一篇文章《選擇SEDA作為雲平台的基礎消息處理架構》。
5.3 網關的高可用設計
保證高可用一般做法是解決單點故障給係統整體帶來的影響。普元在產品設計時，為確保高可用，考慮了如下幾點要素：
1、無狀態設計原則：網關層為保證高可以，易於伸縮，快速啟動，需要設計成無狀態的。用戶的狀態數據我們通常使用session對象來封裝，網關層要設計成無狀態的，也就是說，不能由網關來負責session的維護。那由誰來維護session相關的信息呢？我們是采用cookie+session服務器的方式；
用戶在登錄頁完成登錄操作後，服務器會生成一個登錄session信息，保存起來，設置個失效時間，並設置到用戶的cookie裏
用戶後續的每次請求裏會帶著這個cookie信息，服務端會對這個cookie信息進行校驗，通過了就認為是合法用戶，執行請求操作
2、優雅下線原則：當網關發現某一個節點不可用時（例如請求響應時間超過閥值），不是直接斷開與此節點的連接，而是先把此節點標記為不可用（後續不在發送請求到此節點），但還會留出一段時間讓之前的請求都響應完畢。
3、Slow start特性：當網關監聽到有一台新的服務注冊上來時，考慮到有些服務啟動後，剛開始會有許多初始化的工作，此時服務對請求的響應速度是比較慢的。如果一開始就給這台服務分配太多的壓力，有可能導致服務瞬間被壓垮。為了避免這種情況，網關層需要考慮支持SlowStart特性。即，經過一段時間，逐漸把壓力增加到預設的值。
5.4 網關的擴展性設計
網關的擴展性設計時，需要考慮下麵幾點：
在哪些地點進行攔截處理
攔截器的處理順序
如何在攔截器間傳遞數據
支持在線關閉或啟動一個攔截器
在哪些地點進行攔截處理
我們知道，網關對請求的處理，可以分為三個階段：接受請求、路由並轉發請求、接受服務的返回數據並返回給請求者，除此之外，還有一種情況是處理錯誤。所以我們也可以在這四個地方添加擴展點。
接受到請求後
定位到一個服務，並準備轉發之前
接受到服務的返回數據，返回給客戶端之前
當服務調用失敗後
攔截器的處理順序
攔截器的處理順序，可以分為兩大類：一類為網關平台自帶的攔截器，例如安全校驗、日誌記錄等；一類為網關層邏輯開發的，例如格式轉換等。一般來說，網關先執行網關平台自帶的攔截器，再執行為了業務邏輯編寫的攔截器。當然，網關也需要提供一種機製，可以較容易地調整攔截器的執行順序。最簡單的一種方法，就是給每個攔截器定義一個優先級，網關按優先級順序依次調用各攔截器。
如何在攔截器間傳遞數據
對網關層來說，它接收和處理的數據都是Request對象，網關層在接收到請求後，把請求封裝為Request對象，為了讓後續的filter能夠獲得這個對象，可以考慮把Request對象保存在線程變量中。
支持在線關閉或啟用一個攔截器
有些攔截器，例如一些調試日誌的攔截器，通常情況下都是關閉的，隻有在出現問題的時候才需要打開。為了保證網關的高可用，網關層必須具備在線啟用或關閉攔截器的能力。一般，網關需要提供restful接口方式，來關閉和啟用一個攔截器。類似這樣的命令：PUT/apigateway/v1/filters/filterName?enable=value
5.5 API管理與動態發布設計
對服務管理來說，分為前端服務管理與後端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API，後端服務指的是服務層提供的業務服務API。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外，還需要配置前端服務與後端服務的映射關係。
API的描述
要對API進行管理，首先要對API進行描述。我們常見的接口描述語言有yaml、json、xml、PB等，這幾種語言各有優劣。普元選擇的對API契約的描述方式，是參考swagger spec規範，使用yaml語言來描述。當然，swagger的描述是針對restful接口的，我們可以針對自己接口定義的需要，自定義自己的描述屬性。例如，普元在對微服務描述的時候，擴展了x-primeton-service、x-primeton-operation等屬性來對服務進行描述。例如：
有了API接口契約，除了用來描述服務接口外，還可以：
使用契約，自動生成服務的API文檔。
使用契約，自動生成客戶端的調用代碼。
使用契約，生成服務接口的測試框架代碼。
前後端服務映射
網關層API調用服務層API，有多種方式。例如，可以由按照服務層API的服務契約，生成一段客戶端代碼，發布給網關層使用。這種方式的弊端是，網關層代碼依賴於服務層代碼，服務層頻繁修改和調整接口時，導致網關層的代碼很難維護。
可以通過配置前後端服務映射的方式，解耦網關層對服務層的依賴。當服務層的API（例如服務名、參數名等）發生變化時，隻需調整映射關係，無需對網關層的代碼進行調整。網關層按照映射，自動裝配服務層API所需要的數據格式。這樣，網關層團隊與服務層團隊可以相互不受幹擾地開發各自的服務。
映射的設置，包括服務URL的映射與參數的映射。有了前麵提供的服務契約描述，可以可視化的配置這種映射關係。
API上架
前後端的服務發布後，並配置了映射關係後，就可以把服務暴露給外部使用了。在上架過程中，還需要設置訪問權限、流量控製等信息。這一塊，每個企業的業務要求都不一樣，就不做過多介紹了。
六、總結
API網關作為企業能力開放的一個門戶，除了具備基本的請求轉發、協議轉換、路由等功能，以及高性能和高穩定性外，還需具備良好的擴展性，已便於網關能力的不斷增強。在網關實施過程中，要規劃好網關層與服務層的交互方式，盡量使得網關層與服務層解耦，便於各個團隊工作的獨立性。另外，在API的管理上，需要提供API全生命周期的發布、配置、鑒權、流控、監控等配套的管理功能。這樣，才能讓API網關真正在企業中運轉起來。
最後更新：2017-06-21 18:02:16