Service Mesh：下一代微服務？（service層的作用）

微服務方興未艾如火如荼之際，在 Spring Cloud? 等經典框架之外，Service Mesh 技術正在悄然興起。到底什么是 Service Mesh，它的出現能帶來什么，又能改變什么？本文整理自數人云資深架構師敖小劍在 QCon 2017 上海站上的演講。

簡單回顧一下過去三年微服務的發展歷程。在過去三年當中，微服務成為我們的業界技術熱點，我們看到大量的互聯網公司都在做微服務架構的落地。也有很多傳統企業在做互聯網技術轉型，基本上還是以微服務和容器為核心。

在這個技術轉型中，我們發現有一個大的趨勢，伴隨著微服務的大潮，Spring Cloud微服務開發框架非常普及。而今天講的內容在Spring Cloud之外，我們發現最近新一代的微服務開發技術正在悄然興起，就是今天要給大家帶來的Service Mesh/服務網格。

我做一個小的調查，今天在座的各位，有沒有之前了解過服務網格的，請舉手。（備注：調查結果，現場數百人僅有3個人舉手）

既然大家都不了解，那我給大家介紹，首先，什么是Service Mesh？然后給大家講一下Service Mesh的演進歷程，以及為什么選擇Service Mesh。為什么我將它稱之為下一代的微服務，這是我們今天的內容。

什么是Service Mesh？

我們首先可以說一下Service Mesh，確實是一個非常非常新的名詞，像剛才調查的，大部分的同學都沒聽過。

這個詞最早使用由開發Linkerd的Buoyant公司提出，并在內部使用。2016年9月29日第一次公開使用這個術語。2017年的時候隨著Linkerd的傳入，Service Mesh進入國內技術社區的視野。最早翻譯為“服務嚙合層”，這個詞比較拗口。用了幾個月之后改成了服務網格。后面我會給大家介紹為什么叫網格。

先看一下Service Mesh的定義，這個定義是由Linkerd的CEO William給出來的。Linkerd是業界第一個Service Mesh，也是他們創造了Service Mesh這個詞匯的，所以這個定義比較官方和權威。

我們看一下中文翻譯，首先服務網格是一個基礎設施層，功能在于處理服務間通信，職責是負責實現請求的可靠傳遞。在實踐中，服務網格通常實現為輕量級網絡代理，通常與應用程序部署在一起，但是對應用程序透明。

這個定義直接看文字大家可能會覺得比較空洞，不太容易理解到底是什么。我們來看點具體的東西。

Service Mesh的部署模型，先看單個的，對于一個簡單請求，作為請求發起者的客戶端應用實例，會首先用簡單方式將請求發送到本地的Service Mesh實例。這是兩個獨立進程，他們之間是遠程調用。

Service Mesh會完成完整的服務間調用流程，如服務發現負載均衡，最后將請求發送給目標服務。這表現為Sidecar。

Sidecar這個詞中文翻譯為邊車，或者車斗，也有一個鄉土氣息濃重的翻譯叫做邊三輪。Sidecar這個東西出現的時間挺長的，它在原有的客戶端和服務端之間加多了一個代理。

多個服務調用的情況，在這個圖上我們可以看到Service Mesh在所有的服務的下面，這一層被稱之為服務間通訊專用基礎設施層。Service Mesh會接管整個網絡，把所有的請求在服務之間做轉發。在這種情況下，我們會看到上面的服務不再負責傳遞請求的具體邏輯，只負責完成業務處理。服務間通訊的環節就從應用里面剝離出來，呈現出一個抽象層。

如果有大量的服務，就會表現出來網格。圖中左邊綠色方格是應用，右邊藍色的方框是Service Mesh，藍色之間的線條是表示服務之間的調用關系。Sidecar之間的連接就會形成一個網絡，這個就是服務網格名字的由來。這個時候代理體現出來的就和前面的sidecar不一樣了，形成網狀。

再來回顧前面給出的定義，大家回頭看這四個關鍵詞。首先第一個，服務網格是抽象的，實際上是抽象出了一個基礎設施層，在應用之外。其次，功能是實現請求的可靠傳遞。部署上體現為輕量級的網絡代理。最后一個關鍵詞是，對應用程序透明。

大家注意看，上面的圖中，網絡在這種情況下，可能不是特別明顯。但是如果把左邊的應用程序去掉，現在只呈現出來Service Mesh和他們之間的調用，這個時候關系就會特別清晰，就是一個完整的網絡。這是Service Mesh定義當中一個非常重要的關鍵點，和Sidecar不相同的地方：不再將代理視為單獨的組件，而是強調由這些代理連接而形成的網絡。在Service Mesh里面非常強調代理連接組成的網絡，而不像sidecar那樣看待個體。

現在我們基本上把Service Mesh的定義介紹清楚了，大家應該可以大概了解什么是Service Mesh了。

Service Mesh的演進歷程

第二個部分和大家追溯一下Service Mesh的演進歷程。要注意，雖然Service Mesh這個詞匯直到2016年9才有，但是它表述的東西很早以前就出現了。

首先看“遠古時代”，第一代網絡計算機系統，最早的時候開發人員需要在自己的代碼里處理網絡通訊的細節問題，比如說數據包順序、流量控制等等，導致網絡邏輯和業務邏輯混雜在一起，這樣是不行的。接下來出現了TCP/IP技術，解決了流量控制問題，從右邊的圖上可以看到，功能其實沒發生變化：所有的功能都在，代碼還是要寫。但是，最重要的事情，流程控制，已經從應用程序里面抽出來了。對比左右兩邊的圖，抽出來之后被做成了操作系統網絡層的一部分，這就是TCP/IP，這樣的話應用的結構就簡單了。

現在寫應有，就不用考慮網卡到底怎么發。在TCP/IP之后，這是完全不需要考慮的。上面說的是非常遙遠的事情，大概發生在五十年前。

微服務時代也面臨著類似的一些東西，比如說我們在做微服務的時候要處理一系列的比較基礎的事情，比如說常見的服務注冊、服務發現，在得到服務器實例之后做負載均衡，為了保護服務器要熔斷/重試等等。這些功能所有的微服務都跑不掉，那怎么辦呢？只能寫代碼，把所有的功能寫進來。我們發現最早的微服務又和剛才一樣，應用程序里面又加上了大量的非功能性的代碼。為了簡化開發，我們開始使用類庫，比如說典型的Netflix OSS套件。在把這些事情做好以后，開發人員的編碼問題就解決了：只需要寫少量代碼，就可以把這些功能實現。因為這個原因，最近這些年大家看到Java社區Spring Cloud的普及程度非常快，幾乎成為了微服務的代名詞。

到了這個地步之后，完美了嗎？當然，如果真的完美了，那我今天就不會站在這里了：）

我們看這幾個被稱之為痛點的東西:內容比較多，門檻比較高。調查一下，大家學Spring Cloud，到你能熟練掌握，并且在產品當中應用，可以解決出現的問題，需要多長時間？一個星期夠不夠？大部分人一個星期是不夠的，大部分人需要三到六個月。因為你在真實落地時會遇到各種問題，要能自己解決的話，需要的時間是比較長的。這里是Spring Cloud的常見子項目，只列出了最常見的部分，其中Spring Cloud Netflix下還有Netflix OSS套件的很多內容。要真正吃透Spring Cloud，需要把這些東西全部吃透，否則遇到問題時還會非常難受。

這么多東西，在座的各位相對來說學習能力比較強一點，可能一個月就搞定了，但是問題是你的開發團隊，尤其是業務開發團隊需要多久，這是一個很要命的事情：業務團隊往往有很多比較初級的同事。

然后事情并不止這么簡單，所謂雪上加霜，我們還不得不面對一堆現實。

比如首先，我們的業務開發團隊的強項是什么？最強的會是技術嗎？不，通常來說我們的業務開發團隊最強的是對業務的理解，是對整個業務體系的熟悉程度。

第二個事情，業務應用的核心價值是什么？我們辛辛苦苦寫了這么多的微服務，難道是為了實現微服務嗎？微服務只是我們的手段，我們最終需要實現的是業務，這是我們真正的目標。

第三個事情是，就微服務這個手段而言，有比學習微服務框架更艱巨的挑戰。在做微服務的真正落地時，會有更深刻的理解。比如微服務的拆分，比如要設計一個良好的API，要保持穩定并且易于擴展，還有如果涉及到跨多個服務的數據一致性，大部分團隊都會頭疼。最后是康威定律，但凡做服務的同學最終都會遇到這個終極問題，而大多數情況下是欲哭無淚。

但是這些還沒完，比你寫一個新的微服務系統更痛苦的事情，是你要對舊有的系統進行微服務改造。

所有這些加在一起，還不夠，還要再加一條，這條更要命：業務開發團隊往往業務壓力非常大，時間人力永遠不足。說下月上線就是下月上線，說雙十一促銷就不會推到雙十二。老板是不會管你有沒有時間學習spring cloud的，也不會管你的業務團隊能否搞得定微服務的方方面面。業務永遠看的是結果。

第二個痛點，功能不夠，這里列出了服務治理的常見功能。而Spring Cloud的治理功能是不夠強大的，如果把這些功能一一應對做好，靠Spring Cloud直接提供的功能是遠遠不夠的。很多功能都需要你在Spring Cloud的基礎上自己解決。

問題是你打算投入多少時間人力資源來做這個事情。有些人說我大不了有些功能我不做了，比如灰度，直接上線好了，但是這樣做代價蠻高的。

第三個痛點，跨語言。微服務在剛開始面世的時候，承諾了一個很重要的特性：就是不同的微服務可以采用自己最擅長最喜歡的最適合的編程語言來編寫，這個承諾只能說有一半是OK的，但是另外一半是不行的，是假的。因為你實現的時候，通常來說是基于一個類庫或者框架來實現的，一旦開始用具體編程語言開始編碼的時候你就會發現，好像不對了。為什么？左邊是我從編程語言排行列表列出來的主流編程語言，排在前面的幾種，大家比較熟悉.后面還有幾十種沒有列出來，中間是新興的編程語言，比較小眾一點。

現在的問題在于我們到底要為多少種語言提供類庫和框架。

這個問題非常尖銳，為了解決這個問題，通常只有兩條路可選：

一種就是統一編程語言，全公司就用一種編程語言

另外一個選擇，是有多少種編程語言就寫多少個類庫

我相信在座的如果有做基礎架構的同學，就一定遇到過這個問題。

但是問題還沒完，框架寫好了，也有能夠把各個語言都寫一份。但是接下來會有第四個痛點：版本升級。

你的框架不可能一開始就完美無缺，所有功能都齊備，沒有任何BUG，分發出去之后就再也不需要改動，這種理想狀態不存在的。必然是1.0、2.0、3.0慢慢升級，功能逐漸增加，BUG逐漸被修復。但是分發給使用者之后，使用者會不會立馬升級？實際上做不到的。

這種情況下怎么辦，會出現客戶端和服務器端版本不一致，就要非常小心維護兼容性，然后盡量督促你的使用者：我都是3.0了，你別用1.0了，你趕緊升級吧。但是如果如果他不升級，你就繼續忍著，然后努力解決你的版本兼容性。

版本兼容性有多復雜？服務端數以百計起，客戶端數以千計起，每個的版本都有可能不同。這是一個笛卡爾乘積。但是別忘了，還有一個前面說的編程語言的問題，你還得再乘個N！

設想一下框架的Java1.0客戶端訪問node.js的3.0的服務器端會發生什么事情，C++的2.0客戶端訪問golang的1.0服務器端會如何？你想把所有的兼容性測試都做一遍嗎？這種情況下你的兼容性測試需要寫多少個Case，這幾乎是不可能的。

那怎么辦？怎么解決這些問題，這是現實存在的問題，總是要面對的。

我們來想一想：

第一個是這些問題的根源在哪里：我們做了這么多痛苦的事情，面臨這么多問題，這些多艱巨的挑戰，這些和服務本身有關系嗎？比如寫一個用戶服務，對用戶做CRUD操作，和剛才說的這些東西有一毛錢關系嗎？發現有個地方不對，這些和服務本身沒關系，而是服務間的通訊，這才是我們需要解決的問題。

然后看一下我們的目標是什么。我們前面所有的努力，其實都是為了保證將客戶端發出的業務請求，發去一個正確的地方。什么是正確的地方？比如說有版本上的差異，應該去2.0版本，還是去1.0版本，需要用什么樣的負載均衡，要不要做灰度。最終這些考慮，都是讓請求去一個你需要的正確的地方。

第三個，事情的本質。整個過程當中，這個請求是從來不發生更改的。比如我們前面說的用戶服務，對用戶做CRUD，不管請求怎么走，業務語義不會發生變化。這是事情的本質，是不發生變化的東西。

這個問題具有一個高度的普適性：所有的語言，所有的框架，所有的組織，這些問題對于任何一個微服務都是相同的。

講到這里，大家應該有感覺了：這個問題是不是和哪個問題特別像？

五十年前的前輩們，他們要解決的問題是什么？為什么會出現TCP，TCP解決了什么問題？又是怎么解決的？

TCP解決的問題和這個很像，都是要將請求發去一個正確的地方。所有的網絡通訊，只要用到TCP協議，這四個點都是一致的。

有了TCP之后會發生什么? 我們有了TCP之后，我們基于TCP來開發我們的應用，我們的應用需要做什么事情? 我們的應用需要關心TCP層下鏈路層的實現嗎？不需要。同理，我們基于HTTP開發應用時，應用需要關心TCP層嗎？

為什么我們開發微服務應用的時候就要這么關心服務的通訊層？我們把服務通訊層所有的事情學一遍，做一遍，我們做這么多是為什么？

這種情況下，自然產生了另外一個想法：既然我們可以把網絡訪問的技術棧向下移為TCP，我們是可以也有類似的，把微服務的技術棧向下移？

最理想的狀態，就是我們在網絡協議層中，增加一個微服務層來完成這個事情。但是因為標準問題，所以現在沒有實現，暫時這個東西應該不太現實，當然也許未來可能出現微服務的網絡層。

之前有一些先驅者，嘗試過使用代理的方案，常見的nginx，haproxy，apache等代理。這些代碼和微服務關系不大，但是提供了一個思路：在服務器端和客戶端之間插入了一個東西完成功能，避免兩者直接通訊。當然代理的功能非常簡陋，開發者一看，想法不錯，但是功能不夠，怎么辦？

這種情況下，第一代的Sidecar出現了，Sidecar扮演的角色和代理很像，但是功能就齊全很多，基本上原來微服務框架在客戶端實現的功能都會對應實現。

第一代的Sidecar主要是列出來的這幾家公司，其中最有名氣的還是Netflix。

在這個地方我們額外提一下，注意第四個，前面三個功能都是國外的公司，但是其實Sidecar這個東西并不是只有國外的人在玩，國內也有廠商和公司在做類似的事情。比如唯品會，我當年在唯品會基礎架構部工作的時候，在2015年上半年，我們的OSP服務化框架做了一個重大架構調整，加入了一個名為Local Proxy的Sidecar。注意這個時間是2015上半年，和國外差不多。相信國內肯定還有類似的產品存在，只是不為外界所知。

這個時期的Sidecar是有局限性的，都是為特定的基礎設施而設計，通常是和當時開發Sidecar的公司自己的基礎設施和框架直接綁定的，在原有體系上搭出來的。這里面會有很多限制，一個最大的麻煩是無法通用：沒辦法拆出來給別人用。比如Airbnb的一定要用到Zookeeper，Netflix的一定要用Eureka，唯品會的Local Proxy是綁死在Osp框架和其他基礎設施上的。

之所以出現這些綁定，主要原因還是和這些Sidecar出現的動機有關。比如Netflix是為了讓非JVM語言應用接入到Netflix OSS中，Soundcloud是為了讓遺留的Ruby應用可以使用到JVM的基礎設置。而當年我們唯品會的OSP框架，Local Proxy是為了解決非Java語言接入，還有前面提到的業務部門不愿意升級的問題。這些問題都比較令人頭疼的，但是又不得不解決，因為逼的憋出來Sidecar這個一個解決方式。

因為有這樣的特殊的背景和需求，所以導致第一代的Sidecar無法通用，因為它本來就是做在原有體系之上的。雖然不能單獨拿出來，但是在原有體系里面還是可以很好工作的，因此也沒有動力做剝離。導致雖然之前有很多公司有Sidecar這個東西，但是其實一直沒怎么流傳出來，因為即使出來以后別人也用不上。

這里提一個事情，在2015年年中的時候，我們當時曾經有一個想法，將Local Proxy從OSP剝離，改造為通用的Sidecar。計劃支持HTTH1.1，操作Http Header就可以，Body對我們是可以視為透明的，這樣就容易實現通用了。可惜因為優先級等原因未能實現，主要是有大量的其他工作比如各種業務改造，這個事情必要性不夠。

所有比較遺憾，當時我們有這個想法沒做實現，這是在2015年，時間點非常早的了。如果當時有實現，很可能我們就自己折騰出業界第一個Service Mesh出來了。現在想想挺遺憾的。

但是，不只有我們會有這想法。還有有一些人想法和我們差不多，但是比較幸運的是，他們有機會把東西做出來了。這就是第一代的Service Mesh，通用性的Sidecar。

通用型的Service Mesh的出現，左邊第一個Linkerd是業界第一個Service Mesh，也就是它創造了Service Mesh這個詞。時間點：2016年1月15號，0.0.7發布，這是Github上看到的最早的一個版本，其實這個版本離我們當時的有想法的時間點非常近。然后是1.0版本，2017年4月份發布，離現在六個月。所以說，Service Mesh是一個非常新的名詞，大家沒聽過非常正常。

接下來是Envoy，2016年發布的1.0版本。

這里面要特別強調，Linkerd和Envoy都加入了CNCF，Linkerd在今年1月份，而Envoy進入的時間是9月份，離現在也才1個月。在座的各位應該都明白CNCF在Cloud Native領域是什么江湖地位吧？可以說CNCF在Cloud Native的地位，就跟二戰后聯合國在國際秩序中的地位一樣。

之后出現了第三個Service Mesh，Nginmesh，來自于大家熟悉的Nginx，2017年9月發布了第一個版本。因為實在太新，還在剛起步，沒什么可以特別介紹的。

我們來看一下Service Mesh和Sidecar的差異，前面兩點是已經提到了：

首先Service Mesh不再視為單獨的組件，而是強調連接形成的網絡

第二Service Mesh是一個通用組件

然后要強調的是第三點，Sidecar是可選的，容許直連。通常在開發框架中，原生語言的客戶端喜歡選擇直連，其他語言選擇走Sidecar。比如Java寫的框架，Java客戶端直連，Php客戶端走Sidecar。但是也可以都選擇走Sidecar，比如唯品會的OSP就是所有語言都走Local Proxy。在Sidecar中也是可選的。但是，Service Mesh會要求完全掌控所有流量，也就是所有的請求都必須通過Service Mesh。

接下來給大家介紹Istio，這個東西我給它的評價是王者風范，來自于谷歌、IBM和Lyft，是Service Mesh的集大成者。

大家看它的圖標，就是一個帆船。Istio是希臘語，英文語義是”Sail”, 翻譯過來是起航的意思。大家看這個名字和圖標有什么聯想？Google在云時代的另外一個現象級產品，K8S，Kubernete也同樣起源于希臘語，船長，駕駛員或者舵手，圖標是一個舵。

Istio名字和圖標與K8s可以說是一脈相承的。這個東西在2017年5月份發布了0.1，就在兩周前的10月4號發布了0.2。大家都熟悉軟件開發，應該明白0.1/0.2在軟件迭代中是什么階段。0.1大概相當于嬰兒剛剛出世，0.2還沒斷奶。但是，即使在這么早期的版本中，我對他的評價已經是集大成者，王者風范，為什么？

為什么說Istio王者風范？最重要的是他為Service Mesh帶來了前所未有的控制力。以Sidecar方式部署的Service Mesh控制了服務間所有的流量，只要能夠控制Service Mesh就能夠控制所有的流量，也就可以控制系統中的所有請求。為此Istio帶來了一個集中式的控制面板，讓你實現控制。

左邊是單個視圖，在sidecar上增加了控制面板來控制sidecar。這個圖還不是特別明顯，看右邊這個圖，當有大量服務時，這個服務面板的感覺就更清晰一些。在整個網絡里面，所有的流量都在Service Mesh的控制當中，所有的Service Mesh都在控制面板控制當中。可以通過控制面板控制整個系統，這是Istio帶來的最大的革新。

Istio由三個公司開發，前兩個比較可怕，谷歌和IBM，而且都是云平臺，谷歌的云平臺，IBM的云平臺，尤其GCP的大名想必大家都知道。所謂出身名門，大概指的就是這個樣子吧？

Istio的實力非常強，我這里給了很多的贊譽：設計理念非常新穎前衛，有創意，有魄力，有追求，有格局。Istio的團隊實力也非常驚人，大家有空可以去看看istio的委員會名單感受一下。Istio也是Google的新的重量級的產品，很有可能成為下一個現象級的產品。Google現在的現象級產品是什么？K8s。而Istio很有可能成為下一個K8S級別的產品。

說到應時而生，什么是勢？我們今天所在的是什么時代？是互聯網技術大規模普及的時代，是微服務容器如日中天的時代，是Cloud Native大勢已成的時代。也是傳統企業進行互聯網轉型的時代，今天的企業用戶都想轉型，這個大勢非常明顯，大家都在轉或者準備轉，但是先天不足。什么叫先天不足？沒基因，沒能力，沒經驗，沒人才，而且面臨我們前面說的所有的痛點。所有說Istio現在出現，時機非常合適。別忘了Istio身后還有CNCF的背景，已經即將一統江湖的k8s。

Istio在發布之后，社區響應積極，所謂應者云集。其中作為市面上僅有的幾個Service Mesh之一的Envoy，甘心為Istio做底層，而另外兩個實現Linkerd/nginmesh也直接放棄和Istio的對抗，選擇合作，積極和Istio做集成。社區中的一眾大佬，如這里列出來的，都在第一時間響應，要和istio做集成或者基于Istio做自己的產品。為什么說是第一時間？Istio出0.1版本，他們就直接表明態度開始站隊了。

Istio的架構，主要分為兩大塊。下面的數據面板，是給傳統Service Mesh的，目前是Envoy，但是我們前面也提到Linkerd和Nginmesh都在和Istio做集成，指的就是替代Envoy做數據面板。

另外一大塊就是上面的控制面板，這是Istio真正帶來的內容。主要分成三大塊，圖中我列出了他們各自的職責和可以實現的功能。

Istio官方文檔中文翻譯（http://istio.doczh.cn/）

總結一下，Service Mesh這是一步一步過來的: 從原始的代理，到限制很多的Sidecar，再到通用性的Service Mesh，然后到加強管理功能的Istio，在未來成為下一代的微服務。

注意，離Service Mesh這個詞匯出現的時間點，也才一年。

為何選擇Service Mesh？

前面三個痛點都被解決了，有了Service Mesh之后這些問題都不是問題了。升級的痛點怎么解決？Service Mesh是一個獨立進程，可單獨升級，而應用程序不用改。

Service Mesh是以遠程調用的方式讓客戶端接入，只要能發出請求，簡單發給Service Mesh就可以。客戶端極度簡化，對于典型的Rest請求，幾乎所有的語言都有完善的支持。而服務器端只要做一個事情，服務注冊。這樣對于多語言的支持，就變得非常舒服了。現在終于可以真正的自由選擇編程語言。

這里有一個奇跡，魚與熊掌兼得：同時實現降低門檻，功能增加。有些信奉質量守恒的同學會感覺不科學，注意能同時實現這兩個改進的原因，是把工作量最大最辛苦的事情都交給了Service Mesh。而Service Mesh是通用的，可以反復重用的。

Service Mesh為業務開發團隊帶來的變革：降低入門門檻，提供穩定基座，幫助團隊實現技術轉型。最終達到的目的是，讓業務開發團隊從微服務實現的具體技術細節中解放出來，回歸業務。

第二個變革，是對運維管理團隊的強化，這里如果有做運維的同學，你們可以認真思考一下：如果有了Service Mesh，你們對系統的管理和控制力會有多大的？注意很多功能的實現已經不再和應用有關，都在移到Service Mesh中，而Service Mesh通常是在運維的掌控中。

Service Mesh對于新興小眾語言是極大的利好。對于新的語言來說，在和傳統的主流編程語言競爭時，最痛苦的事情是什么？是生態，比如各種類庫，各種框架。在微服務這個領域，新興小眾語言想和Java等比拼，非常的難：這是用自己的劣勢對上別人的優勢。而有了Service Mesh之后，小眾語言就有機會避開這個弊端，再不用和Java比拼生態，而是充分發揮自己的語言特點，做自己最擅長的領域。

微服務 容器

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。