摘要：說起，必須要介紹是什么東西，為什么中小企業(yè)私有云適合使用?？匆幌卢F(xiàn)在的架構(gòu)圖開個玩笑。上面這四點導致我們必須要統(tǒng)一架構(gòu)，最終把整個業(yè)務系統(tǒng)遷移到基于的類似于的私有云的平臺。

本文系 ArchSummit 大會 CODING 工程師王振威演講實錄。

大家好，非常高興在這里跟大家分享，我是王振威，來自 Coding 的一個程序員。今天給大家?guī)淼姆窒碇饕俏覀儓F隊在使用 Docker 改進原有的業(yè)務系統(tǒng)的演進計劃和實施的經(jīng)驗教訓。

說起 Docker，必須要介紹 Docker 是什么東西，為什么中小企業(yè)私有云適合使用 Docker。其次是我們做一套架構(gòu)系統(tǒng)的變遷，總是事出有因的，我們必須介紹一下為什么變遷。第三是怎么變遷，作為中小型企業(yè)要想把業(yè)務假設到私有云上，如何一步一步來做。最后我們在使用Docker的過程中遇到了比較棘手和麻煩的問題。

第一，Docker，在座有相當一部分人已經(jīng)了解了，它是容器技術，跟私有云有什么關系？那么首先要解釋一下什么叫私有云。

私有云用這樣一句話來形容是最為貼切的：就是企業(yè)內(nèi)部的服務于企業(yè)自身的云服務平臺。企業(yè)內(nèi)部有很多服務器，有不同的業(yè)務系統(tǒng)，但是想讓這些業(yè)務系統(tǒng)高效地運行起來，我們往往會采用類似于 IaaS 或者 PaaS 的技術來搭建這個平臺。那么 Docker 為什么適用于搭建一個私有云的企業(yè)平臺呢？因為容器技術比傳統(tǒng)的VM技術成本更低、效率更高。關鍵點在于這種技術是兼容性又好的，可以使我們傳統(tǒng)的架構(gòu)變遷顯得更為平滑，這是最為重要的一點。另外，容器技術一大特點就是快速實現(xiàn)隔離，統(tǒng)一調(diào)配。有如下三快：

構(gòu)建快
一個應用最終的形式往往是環(huán)境加上程序包，形成最終的鏡像，image 就是程序本身外加環(huán)境，Docker 讓我們可以用 Dockerfile 之類的技術定義鏡像，自動構(gòu)建，免去在很多服務器上繁雜的安裝配置應用程序環(huán)境的過程

啟動快
容器相比虛擬機的啟動速度是非常快的，開一臺虛擬機的啟動速度慢一點的一分鐘，快一點的也要十幾秒，但是容器往往可以做到秒級啟動，這為我們后面所講的容器化交付奠定了基礎。

遷移快
應用以容器的方式標準化交付，這個主機跟另外一個主機只要安裝了 Docker 就沒有什么差別，image 不管扔到這里還是扔到那里都可以很快地正常運行。而傳統(tǒng)的 VM，只是省去了我們購置租用物理服務器的過程，本質(zhì)上來講還是一個裸的操作系統(tǒng)，本來這個程序在 A 機運行，但 A 機掛了，現(xiàn)在來配置 B機，裝了 JDK，發(fā)現(xiàn)不行，這個 JDK 版本不對啦，JDK 缺少了本地的庫啦，之類一系列問題。但是如果用了 Docker，用了容器技術，它把這些依賴環(huán)境全打成 image，只要把 image 下載下來就行了，這是編程語言，框架無關的，因為應用的環(huán)境是跟著應用走的。

看一下現(xiàn)在的架構(gòu)圖

開個玩笑。

如果我們的架構(gòu)是這樣的話那就沒什么好講了，我的意思是說一個成熟的以容器來做基層建設的私有云環(huán)境，最終的效果應該像巨輪一樣，可以把所有的貨艙都碼放整齊，可以平穩(wěn)地向前航行，這是基于容器的私有云的愿景。

有人會問了，如果說你之前的架構(gòu)沒問題，為何要遷移到這個環(huán)境來呢？

事出有因，假如傳統(tǒng)的架構(gòu)是很好的，我們沒必要遷移到 Docker 這種私有云環(huán)境來，我們?yōu)槭裁匆w移？

有幾個原因：

第一是我們之前的業(yè)務系統(tǒng)隨著時間的發(fā)展越來越多，不同的組件需要協(xié)同去做不同的工作，給運維帶來了巨大的挑戰(zhàn)，有 JAVA 寫的程序，還有些程序制定了必須用 JDK7，一些部門覺得 JDK8 有些特性比較好用所以用了 JDK8，還有些組件是用 Ruby 寫的，還有 Golang，NodeJS等等，目前我們系統(tǒng)中牽扯的系統(tǒng)語言已經(jīng)達到了八九種，這對運維來講是一個巨大的挑戰(zhàn)，我們必須要給各種各樣的程序準備各種各樣的環(huán)境，維護，遷移都非常麻煩。

另外配置混亂，當你應用的服務器數(shù)量越來越多，有的系統(tǒng)可能是用 upstart 來管理程序，有的是用 Supervisor , 有些程序可能只是個 定時任務。我們的編程語言每一種都會有自己的構(gòu)建工具，構(gòu)建工具對依賴的管理也不太一樣。最終的結(jié)果是操作系統(tǒng)中的配置文件和各種黑科技補丁腳本散落在系統(tǒng)的各個角落，沒人能找得到，也沒人搞得懂。

最后致命的一點是監(jiān)控和資源的混亂,?監(jiān)控混亂，如果是一個很簡單的程序，往往只需要做到當發(fā)生錯誤，把這個錯誤日志打印出來，運維上看一下日志就行了。當涉及到幾百臺應用服務器，其中的各個組件每天打印上百萬條、上千萬條各種不同級別的日志的時候，運維是沒有精力去了解的，我們只能做錯誤報告，做消息的推送，但是因整體系統(tǒng)混亂，每個應用有各自的方式，最終導致日志，錯誤監(jiān)控都沒能達到相應的預期。然后是混亂的資源，我們做 WEB 的應用往往出現(xiàn)白天是高峰期，晚上是低峰期，低峰期zi"yuanziyuan使用率很低，屬于資源的浪費。另外有些業(yè)務在申請計算資源的時候不能提前預估到使用量有多少，申請的過多或者過少，運維又要經(jīng)常承擔著縮容擴容的問題。

有因必有果，環(huán)境不匹配導致測試跟生產(chǎn)環(huán)境不一樣，比如生產(chǎn)環(huán)境是 JDK8 跑的，某一個開發(fā)者本地用 JDK7 測試的程序，上去發(fā)現(xiàn)這個東西根本不對，雖然 JDK7 和 JDK8 的兼容性已經(jīng)是99%以上，但是一個嚴謹?shù)臉I(yè)務系統(tǒng)必須要做到測試環(huán)境跟生產(chǎn)環(huán)境是一致的。

配置混亂導致事故頻發(fā)，做過運維的肯定了解，這個配置被誰改掉了，這個服務宕掉了，當你的組件越來越多的時候根本無從管理。監(jiān)控不一致，資源效率低。計算資源的成本很高，卻達不到相應的目標。所以之前那艘看起來航行很平穩(wěn)的巨輪，在上面這四大原因的影響下，事實上是這樣的。

上面這四點導致我們必須要統(tǒng)一架構(gòu)，最終把整個業(yè)務系統(tǒng)遷移到基于 Docker 的類似于 PaaS 的私有云的平臺。

架構(gòu)變遷，作為一個架構(gòu)團隊的 Leader，在做架構(gòu)變遷遵循的時候要掌握如下原則：

即面向未來，又不過于激進

即追求穩(wěn)定，又不過與保守

其實就是掌握平衡，追求一個度。我們用新技術，必然是為了解決舊技術的問題我們才用，但如果過于追求新技術，忽略了業(yè)務的重要性，你會發(fā)現(xiàn)你最終是得不償失的。所以我們遵循的原則是既面向未來，又不過于激進，既追求穩(wěn)定，又不過于保守。

關于技術選型，這是我們團隊的做法。

容器技術現(xiàn)在有幾種選擇，Docker 本身的底層就是 RunC。谷歌內(nèi)部有自己的容器技術，VMware 也有容器技術，但是就目前來講，Docker 是最好的選擇。服務發(fā)現(xiàn)我們用了 ETCD，我不再講哪個軟件好哪個軟件壞，不同的軟件會適用不同的業(yè)務場景，只有適合與不適合。

接下來我會講具體的架構(gòu)變遷三步走。

架構(gòu)變遷三步走遵循的最重要的一點是平滑演進。我們都知道我們的業(yè)務系統(tǒng)是脆弱的，經(jīng)不起風吹雨打，如果大動干戈搞一下，新的架構(gòu)出問題了，業(yè)務系統(tǒng)是承受不住，技術部門也無法承受住其他部門帶來的壓力。所以我們必須有序平穩(wěn)平滑的演進升級。微服務是這套升級的一個基礎點，如果你的這些應用不是微服務，不是無狀態(tài)化的，那你就沒辦法讓多個實例協(xié)同工作。最后是軟硬分離，分割計算資源和具體業(yè)務的強依賴，其實這個問題，在我們?nèi)孔咄?，只要在配置好的服務器環(huán)境裝一個 Docker 就搞定了。

先把應用無狀態(tài)化，你可以采用一些集中式緩存這種技術讓應用變得沒有自己的狀態(tài)，它隨時起停，起多少份都是無所謂的，只要有負載均衡器就可以讓這些組件對外提供一致的服務。當無狀態(tài)化應用實現(xiàn)之后，我們就可以給這個應用寫 Dockerfile 了，Dockerfile 構(gòu)建的結(jié)果就是 Docker ?image ，其本身就是應用和環(huán)境，第一行是from java jdk7，第二行設置應用程序，第三行把這個程序運行起來。

# Base
FROM java:jdk-7

COPY ./.src/target/app-1.0.jar /app/

# ENTRYPOINT
WORKDIR /app
CMD [ "java", "-Dfile.encoding=UTF-8", "-jar", "./app-1.0.jar" ]

這是很簡單的 Dockerfile，不要看他簡單，我推薦的是各位用 Docker 就應該這么用。不需要在 Dockerfile 里寫一堆 apt-get install ,一大堆 run 命令這些東西，記住 Dockerfile 就是聲明應用環(huán)境和應用本身。Docker 現(xiàn)在做的功能太多了，很多都是不怎么靠譜的，Docker 需要更專注于它本身作為容器的技術。完成無狀態(tài)化應用和寫完 Dockerfile 之后，這個程序就可以被打報成 Docker image 了，放到一個 Docker Host 上運行起來就得到了無狀態(tài)的應用容器，也就完成了把應用裝容器的過程。

不能說應用扔進去就不管了，如何管，管的辦法有很多，容器技術這個圈里爭論最多的就是編排技術。

容器的管理方式對 Docker 來講，目前就三種：

第一是直接管，我們都知道Docker 官方有一個 CLI 工具，只要裝了 Docker 就可以使用這個 CLI 工具把指定的程序運行在容器里，這是更直接的方式。但明顯我們有幾十臺上百臺服務器的時候，不能每個都上去搞一下，雖然它更直接，但它比較麻煩。

另外一個是 Docker remote API，更為靈活，提供了相關的編程接口來管理容器。

最后是編排系統(tǒng)，它們更為復雜，定義的條條框框更多。我這里不推薦做架構(gòu)漸變演化的團隊采用。主要原因是，我們遷移到這些編排系統(tǒng)往往都是跳躍式的升級，不是平滑演進，業(yè)務系統(tǒng)不能容許直接把整個業(yè)務系統(tǒng)跳躍式升級，無法承擔風險，出問題的回退預案也很難定制。當然如果是一個本身從零開始的系統(tǒng)，那你可以嘗試一下，但也不保證這種編排系統(tǒng)就適應于你的業(yè)務系統(tǒng)。我們推薦一步一步走，先把這種應用變成容器，再來想辦法管理這些容器。

很顯然我們采用的是第二種選擇。

配置文件配合 Docker remote API。根據(jù)實際情況，選擇Docker的少量的一些特性，例如文件系統(tǒng)、網(wǎng)絡、資源限定等這些成熟的，我們最為需要的功能，我們編寫了一個便捷的操作工具 cli/web。

在配置文件中定義一個任務，名字寫下來，這個任務用什么 image 跑，什么版本，運行在哪臺機器上，注意這里，機器名并不跟具體的業(yè)務綁定，而是一個資源池，不管什么應用都是無差別的，只要是無狀態(tài)的應用，所有的存儲、依賴都通過網(wǎng)絡的形式來解決，我們整個資源池就可以實現(xiàn)自由調(diào)度。

如果把這個應用綁定到某一些具體的特有的機器上的話，局限性比較大，萬一這些機器出問題，將無法快速遷移。有一些選項是沒填的，比如 port， port 其實是 Docker 支持把容器內(nèi)的某個端口映射到容器外，我們沒填這個東西是因為，我們默認在全系統(tǒng)級都只使用Docker的 host 網(wǎng)絡模式。 host 模式下，Docker 內(nèi)部容器的網(wǎng)絡跟宿主機的網(wǎng)絡是一樣的，這是 Docker 所有網(wǎng)絡模式中性能最高的，缺點是不能做隔離。

這里有人可能會問，為什么要放棄隔離呢？這里解釋下沒用 Docker 的高級的網(wǎng)絡模式，以及 SDN、端口映射等的原因。就是沒必要。注意我們講的是私有云平臺，私有云平臺內(nèi)部都是企業(yè)自身的業(yè)務，大部分業(yè)務都基于業(yè)務層面做隔離和權(quán)限就可以了， 所以 Docker 用 host 的模式運行就跟傳統(tǒng)應用沒有差別，不需要做 NAT，SDN，也不需要做端口影射，另外一個好處就是，對于應用來講他們的依賴用容器和不用容器都是一樣的，這完全符合我們要求的平滑演進。

下面還有其他的配置，我們會通過環(huán)境變量控制一些應用內(nèi)部的參數(shù)，因為我們的配置文件往往是打包到 image 里面，但是 Docker 這點挺煩的，改一個配置文件都要重新打一個 image，我們最終把配置項做成環(huán)境變量或者 CMD 參數(shù)，這樣可以在組件間共享一些 image。

這是我們用CLI在更新某個實例的時候打印出的內(nèi)容，這是我們自己的定制的，它會告訴我們當前運行的實例的名字是什么，運行時間是什么等等一系列內(nèi)容，只要選擇指定版本代碼的 Docker image，我們就可以完成全自動化的更新。

另外我們還部署了一套 DockerUI，這個軟件總體用下來不是特別好用，這是它大概的界面，跟我們 CLI 的功能比較類似，我們之后會自己定制一個運維的系統(tǒng)級 DashBoard。

釜底抽薪，這個形容是比較貼切的。我們的服務都是無狀態(tài)化的，這個服務運行在哪里是無關緊要的，運行多少份也是無關緊要的，只要把這些新的容器化的交付應用替換掉之前的以各種雜亂的形式運行的應用，由于演進是平滑的，直接替換即可，整個系統(tǒng)就有機結(jié)合起來了。

完成架構(gòu)變遷前兩部之后，假如現(xiàn)在系統(tǒng)有50個組件，只完成了5個組件的 Docker 化、無狀態(tài)化、編排。沒問題，我們的原則就是平滑，漸進，你不需要全部搞定，就可以開始應用到生產(chǎn)環(huán)境了。目前 Coding 的 95% 的組件都運行在 Docker里面，為什么留5%，是因為有一些極其邊緣的組件，因歷史遺留原因還沒有遷移過去。事實上我們發(fā)現(xiàn)只要前兩步做的好，第三步是很容易的，簡單來說就是停掉舊服務，啟動新服務。

這里值得一提的是，不光我們的主業(yè)務系統(tǒng)需要這么做，我們的一些附屬業(yè)務系統(tǒng)包括監(jiān)控系統(tǒng)、負載均衡系統(tǒng)、服務發(fā)現(xiàn)等等，都應該按照這個架構(gòu)一步一步替換過來。最后實現(xiàn)計算和存儲分離，軟件和硬件分離。因之前不是在容器中運行，應用對某個服務器可能都是一種強依賴的狀態(tài)，而現(xiàn)在把這些組件替換掉之后，你所有應用的環(huán)境都封裝在 Docker image 里面，這些服務器上本身沒有任何各個語言的執(zhí)行環(huán)境，他們都是 Docker 宿主機，自動就變成無差別化的了。Docker Image只要放到任何一臺裝有 Docker 的環(huán)境上，就可以很快運行起來。

這是線上的 Docker 容器的列表截圖，這是某一臺服務器運行的實例。最終形成的架構(gòu)是這樣的：

當你們看到這個架構(gòu)的時候覺得它并不高端也并不奇怪，因為很多傳統(tǒng)架構(gòu)就是這樣。而我想說的是我們完成這些東西其實也并不違背傳統(tǒng)的高可用分布式架構(gòu)，只是釜底抽薪，把底層的進程組件換成了容器，把原來管理應用的方式換成了管理容器的方式。

我們現(xiàn)在運維的流程是這樣，運維有兩種方式來操作這些容器，分別是 CLI 和 UI 界面，運維操作都是發(fā)往這個工具，這個工具是可以管理現(xiàn)有所有的容器，所有的容器的定義都會存放在相應的配置文件里，這些配置文件還會在 ETCD 里做一個副本，LB 系統(tǒng)監(jiān)控系統(tǒng)等等需要知道這些組件的狀態(tài)。

LB系統(tǒng)是內(nèi)部服務的總?cè)肟冢热鐑?nèi)部有一個很小的服務，這個服務做的事情很簡單，所以它屬于微服務的特點，微服務就是某一個組件每一個服務只做好一件事情，把這個事情做到極致。而 LB 就是把對這些服務的請求轉(zhuǎn)發(fā)給相應的無狀態(tài)組件。

我們有一個微服務的組件 md2html 就做一件事情，就是編譯 Markdown ，所有其他組件但凡有需要編譯 Markdown 的都通過 LB 系統(tǒng)調(diào)它。這個組件使用 Ruby 寫的，其運行環(huán)境比較難配置，牽扯到一些原生的 C 的庫，會對一些本地庫有些版本需求，新增服務器很容易配置錯誤?，F(xiàn)在就沒問題了，這個應用的環(huán)境已經(jīng)被我們打包成 image 存入了 Docker registry ，即便我們裝有運行環(huán)境的那臺機器宕了，我們只要用 Docker pull 下來，立馬就能遷移到另外一臺服務器。

我們的監(jiān)控系統(tǒng)跟 LB 是什么關系？監(jiān)控系統(tǒng)會對每一個容器的關鍵指標做數(shù)據(jù)收集，比如 LB，比如剛提到的 md2html ，都會維護一個 Http 接口，這個接口里提供它的關鍵指標的數(shù)據(jù)信息。計算資源服務器的關鍵指標有內(nèi)存使用量，CPU 使用率等等。應用程序的關鍵指標都由各個業(yè)務應用自己定義。

例如我們這個 md2html 他的一個關鍵指標就是每秒鐘處理的MD數(shù)量。

我們的監(jiān)控系統(tǒng)會定時抓取這些關鍵指標，要求較高的是 5 秒一次，要求低的可能是1分鐘，抓取之后存入數(shù)據(jù)庫，再配上一些監(jiān)控的報警規(guī)則。比如一個 md2html 實例，正常業(yè)務量可能是每秒鐘處理10個編譯的任務，但是監(jiān)控系統(tǒng)查到連續(xù)五分鐘處理量都低于3，我們就認為這個實例有問題了。

監(jiān)控系統(tǒng)在遇到問題時，一方面會發(fā)一條消息到 ETCD 里面，告知現(xiàn)在這個實例異常，LB 系統(tǒng)訂閱ETCD，LB 系統(tǒng) watch 到相應的改變之后就會把自己的配置改一下然后做一次 reload，這個實例就自動下線了。另外，監(jiān)控系統(tǒng)監(jiān)測到問題的時候會發(fā)一條消息到通知中心，通知中心會把錯誤的信息直接通過手機 APP 推送給運維人員。另外我們還支持包括發(fā)郵件，發(fā)短信，打電話等等形式。通知中心是我們這個系統(tǒng)中組件共用的，還有些普通的業(yè)務應用也會用到通知中心這個組件。

這些組件都是運行的多個實例，不要覺得業(yè)務量不大何必運行這么多實例，對一個服務來講，它沒什么負載，它運行著也不會占你太多的計算資源，據(jù)我的了解我接觸大多數(shù)人的系統(tǒng)架構(gòu)里計算資源都屬于過剩的狀態(tài)，他們卻不愿意去多運行幾個實例來提升可靠度。

這里是我們這個架構(gòu)圖的一些細節(jié)：

LB 系統(tǒng)： Nginx / HAProxy / confd / Etcd

監(jiān)控系統(tǒng)： Prometheus / cAdvisor / Http Metrics

Docker Registry V1

Docker 網(wǎng)絡：Host

Docker 日志：Mount 宿主機

HAProxy/ nginx這些很普通的負載均衡軟件。confd 是一個很簡單的程序，就做一件事情，confd 一直 watch ?Etcd 中服務的容器應用狀態(tài)，一旦有改動，就生成新的LB 配置文件，并 reload LB 程序。這也印證了我們堅持的一點，系統(tǒng)中所有的組件只做一件事情，而且把這件事情做到極致。

假如說我們現(xiàn)在有三個 md2html 實例，當某一個實例掛了，監(jiān)控系統(tǒng)檢查到了相關問題，知道它掛了，這時監(jiān)控系統(tǒng)會兩件事情，把它掛的消息通知到 ETCD，推送到ETCD 后，confd 會自動 reload LB，實現(xiàn) LB 系統(tǒng)的自動切換。另外就是發(fā)送通知給運維人員，好讓運維查出系統(tǒng)的問題，從而做出響應。

我們搭建一個 Docker RegistryV1 版本，現(xiàn)在已經(jīng)發(fā)布了V2 版本，Docker 官方 V1 和 V2 版本不兼容，V2 也改了名字，叫做 Distribution。我們用到現(xiàn)在沒出特別大的問題，完全沒有激發(fā)我們升級新版本的動力，因為V1用得挺好的。

Docker 網(wǎng)絡，Host 模式，優(yōu)點在于性能高，平滑。如果不用Host的模式，用 NAT 模式會非常痛苦，NAT 模式雖然安全，但是對于私有云內(nèi)部來講沒有危險的應用，所有程序都是自己寫的，沒有不安全的，就算它不安全，你之前沒有用 Docker 的時候它也是這樣，所以用這個 Host 模式并沒有增加不安全度。最后是 Docker 日志，我們之前踩了一些坑，現(xiàn)在的做法是讓它直接寫到宿主機的日志文件里。

我們的架構(gòu)接下來的改進方向是如下幾個點：

Job-Tool 進化成 Job DashBoard ，集成監(jiān)控(cAdivsor)，日志(ELK)等功能

利用監(jiān)控系統(tǒng)的硬件指標，根據(jù)業(yè)務用量實現(xiàn)自動擴容，縮容

分析各個業(yè)務對硬件資源的使用量和高低峰，設計混布實現(xiàn)提升硬件使用率

Docker image 的構(gòu)建和管理

動態(tài)調(diào)整 container 的資源限制

吐槽一下Docker的問題。Dockerfile 有點用，但沒什么大用，就是幾句話的問題非要編譯那么大的鏡像，改一行配置都需要重新編譯一個 image。Docker Daemon，很不穩(wěn)定，我們出的很多問題都是它導致的，它功能太多，很多問題也就是他這些無用的功能導致，我們認為 Docker daemon 只需要做幾件簡單的事情，幫你管理容器，起、停、刪除就完了。Docker 官方最近剛推出了一個 ContainerD，就是一個簡化版的 Docker Daemon，基于 RunC 的，就非常符合我們對于 Container 管理的看法。

我們之前踩了兩個比較大的坑，一個是容器標準輸出輸出大量數(shù)據(jù)，會導致內(nèi)存泄露，從而導致 Docker Daemon crash。另外一個是Docker Daemon 在頻繁創(chuàng)建刪除容器（每天幾十萬個）會出現(xiàn)性能嚴重下降等問題，只能重啟 Docker Daemon。標準輸出問題，必須要滿足的兩個條件是輸出數(shù)據(jù)量大、輸出速度快。

這里列出了我們關于標準輸出問題的簡易重現(xiàn)方式和最終 Docker 的修復方案。

重現(xiàn)方式一： docker run ubuntu yes “something long”

重現(xiàn)方式二：docker run -i ubuntu dd if=/dev/zero of=/proc/self/fd/1 bs=1M count=1000

Issue: https://github.com/docker/docker/issues/14460

Fix By: https://github.com/docker/docker/pull/17877

最后，關于并發(fā)性能問題，測試環(huán)境比較復雜，還在進一步研究中，歡迎各位來 Coding.net 冒泡 共同探討。

謝謝大家。