如何像參與開源那樣，去參與一款 IDE 插件的設計？
作爲一款 IDE 插件的使用者，我是否能決定下一個版本的功能？
自從產品經理銀時小夥和他的開發小哥們在去年12月發佈 Cloud Toolkit（一款 IDE 插件）以來，已幫助數以萬計的開發者們提高了業務的部署效率。期間，開發者們不僅是 Cloud Toolkit 的使用者，同時也作爲設計者參與了插件的更新迭代。
本文來自開發者徐靖峯，分享了他和 Cloud Toolkit 的故事
遇見 Cloud Toolkit
在與中間件×××姐的一次聊天中，偶然間瞭解到這款插件，×××姐跟我提到自己正在運營一款 IDE 開發者工具，能夠使開發部署效率提高 8 倍，出於好奇心，我就上手體驗了一下，看看究竟是一個什麼樣的產品。使用了一段時間之後，便迫不及待地向×××姐分享了我作爲開發者對插件的一些看法。
我對這款產品最直觀的感受：這是一款發佈工具，幫助用戶在 IDE 中直接打包應用並部署到各種終端。一開始看到這款產品位於阿里雲的頁面中，原本以爲是一款和阿里雲服務強綁定的產品，但試用過後才發現，即使對於普通的雲主機，也非常適用，還可以解決很多開發運維的痛點，非阿里雲用戶可以放心使用。
在 Cloud Toolkit 出現之前
作爲一個 Java 程序員，我們大多數會在 Intellij IDEA 中基於 SpringBoot 來開發 WEB 應用，所以本文中的測評將會基於以下幾個架構來構建：
開發環境：IDEA
項目組織方式：Maven
開發框架：SpringBoot
在接觸 Cloud Toolkit 之前，用什麼方法來部署一個 SpringBoot 應用呢？作爲一個偏正經的測評人員，我不會爲了凸顯出 Cloud Toolkit 的強大而去翻出一些上古的部署工具來做對比，而是直接使用 Intellij IDEA 的內置功能與之對比。
第一步：配置服務器信息
在 Tools -> Deployment 中找到 IDEA 對項目部署支持的內置插件，我們可以在其中進行服務器信息的配置，包括服務器地址和權限認證，並且在 Mapping 選項卡中完成本地工程與服務器路徑的映射。
第二步：配置 Maven 打包插件
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
由於是 SpringBoot 應用，配置專用的打包插件後，可以將整個工程打成一個 fatjar，示例工程非常簡單：
@SpringBootApplicationbr/>@RestController
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
@RequestMapping("/hello")
public String hello() {
return "hello world~~~~~~~~~~~~~~~~";
}}
之後，只要執行 install，即可得到一個可運行的 jar 包：
第三步：部署 jar 包
由於我們在第一步已經配置過項目路徑與服務器路徑的映射，可以選擇直接對 fatjar 右鍵，upload 到遠程服務器上。
第四步：啓動應用
上圖中展示的是 IDEA 中兩個非常棒的內置功能，可以在 Tools -> Start SSH session 中開啓遠程服務器的終端，在 IDEA 下方可以執行遠程指令；也可以在 Tools -> Deployment ->Browse Remote Host 中展開如圖右側的結構，可視化地瀏覽服務器上的文件列表，檢查應用是否部署成功。
在遠程終端中，找到對應的 fatjar，執行 java -jar spring-demo-1.0-SNAPSHOT.jar 便完成了整個部署流程。
IDEA 內置插件總結
IDEA 內置插件已經提供了相當強大的能力，整個部署過程我們完全沒有離開 IDEA！避免了頻繁切換窗口，裝各種部署工具，可以說已經很方便了，Cloud Toolkit 必須要比這個部署過程做的更加強大才行，那下面就讓我們來體驗下 Cloud Toolkit 是怎麼優化的吧。
Cloud Toolkit 初體驗
我們不急着用 Cloud Toolkit 來部署應用。雖然筆者是一位開發者，但還是從產品的角度來研究下它的菜單項，看看它的產品定位。IDEA 安裝插件的過程省略，詳情可以參考《IDE 插件新版發佈 | 支持更多場景，開發效率更“biu”了》。
其他菜單項暫且拋到一邊，這 5 個核心能力應該就是 Cloud Toolkit 的核心了。
即使作爲一個插件小白，應該也能夠望名知意，猜到這幾個菜單對應的功能：
Deploy to Host：部署到任意服務器。這一個功能決定了 Cloud Toolkit 強大的之處就是可以使得每個開發者受益，它其實並不是和阿里雲廠商強綁定的。我會在下文重點測評下這個功能。
Deploy to ECS：這裏的 ECS 指的阿里雲的 ECS，如果你的服務部署在阿里雲 ECS 上，可以選擇使用這個功能，獲得比 Deploy to Host 更加豐富的功能。在下文我也會簡單測評下這個功能。
Deploy to EDAS & EDAS Serverless：EDAS & EDAS Serverless 是阿里雲提供的分佈式服務治理服務，可以理解爲商業版的 Dubbo，具有強大的服務治理、服務調度能力，Cloud Toolkit 對 EDAS 做了個性化的部署支持，讓使用者無需登錄控制檯，在 IDEA 中即可完成 EDAS 的部署。
Deploy to CS K8S：在雲原生時代，很多應用使用容器化的方式進行部署，Cloud Toolkit 這一點做的還是不錯的，已經具備了容器化部署的能力，具有一定的前瞻性。
其實從簡單的功能介紹就可以看出，Cloud Toolkit 相比 IDEA 內置的部署能力的確是高出一大截了，甚至可以說，Deploy to Host 這一能力完全就可以覆蓋 IDEA 插件的所有能力，並且對流程還進行了一些簡化。下面我重點測評下 Deploy to Host 這一能力，與之前的部署流程進行一個對比。
使用 Cloud Toolkit 把應用部署到任意服務器
上圖展示的 Deploy to Host 功能的配置項，實際上涵蓋了以下幾點：
遠程服務器配置
部署方式：Maven 構建，直接上傳文件（目前還不支持 Gradle 構建，可能在後續的版本會支持）
本地文件與服務器路徑的映射配置
啓動腳本的集成
賬號管理
SSH 登錄賬戶可以在 Preferences -> Alibaba Cloud Toolkit -> SSH Profile 中管理，找不到也沒關係，需要設置的時候一般都會有超鏈接跳轉，這點做得很人性化。
主機管理
服務信息可以在 Tools -> Alibaba Cloud ->Alibaba Cloud View 中展開，如下圖所示：
image-20190602191159882
Deploy to Host
配置完賬號信息和主機信息，接下來只需要右鍵項目選擇 Alibaba Cloud -> Deploy to Host-> Run ，一切就搞定了。這個過程相比之前變得非常簡易：
不需要自己打包，Cloud Toolkit 集成了 Maven 插件。
不需要登錄遠程終端去執行腳本啓動服務，Cloud Toolkit 提供了應用部署生命週期必要的鉤子，只需要設置好啓動腳本即可。
修改完本地代碼，點擊下 Deploy to Host，即可完成改動代碼的部署。
經過如上的測評過程，相信即使沒有使用過 Cloud Toolkit 的用戶，也可以直觀體會到這是一款怎麼樣的插件了，並且它的功能是多麼的實用。
使用 Cloud Toolkit 把應用部署到 ECS
從產品設計的角度來分析，Cloud Toolkit 提供如此多的部署能力，可以想到是其直接預設了使用人羣。例如一個阿里雲的 ECS 用戶，在選擇部署方式時，既可以使用 Deploy to Host 也可以使用 Deploy to ECS；再者，例如一個 EDAS 用戶，在選擇部署方式時，既可以使用 Deploy to Host、Deploy to ECS，也可以使用 Deploy to EDAS（EDAS 可以理解爲一個定製化的 ECS）。從產品的角度，越定製化的功能，其服務的人羣越少，同時功能更強大；從用戶體驗的角度，其實也透露了雲服務的一個特點，雲廠商正在爲其所提供的雲服務創造更好的用戶體驗，藉助於此類插件，來降低使用者的開發運維門檻。
可以預見的一件事是，對於非阿里雲用戶來說，Deploy to Host 是他們使用 Cloud Toolkit 最大的誘惑了。作爲一個測評文章，除了介紹 Deploy to Host 之外，我還選擇了 Deploy to ECS 這一功能來進行測評。爲此我購買了一臺阿里雲的 ECS 來部署與上文相同的應用。
Accounts
在阿里雲控制檯可以獲取到賬號的 Access Key/Access Key Secret，在 IDEA 中的 Preferences -> Alibaba Cloud Toolkit -> Accounts 中可以設置賬號。
在賬號設置完畢後，Cloud Toolkit 看起來是通過內置的 API 直接關聯到了我的 ECS 實例，在選擇部署時，可以直接根據 region 選擇實例列表中的機器進行部署。
實例列表
其餘的部署流程和 Deploy to Host 相差無幾。也就是說，其實 Deploy to ECS 更多的完成了權限管理和主機管理，ECS 用戶使用這個功能就顯得非常高效了。
Cloud Toolkit 的亮點功能
Cloud Toolkit 除了主打的部署能力，還提供了不少亮點功能，我選擇了其中的 3 個功能來分享：上傳文件、遠程 Terminal、內置應用診斷功能來進行評測。
上傳文件
upload
有些腳本我們希望在本地編輯之後上傳到服務器上，Cloud Toolkit 對每一個主機都提供了一個 Upload 操作，可以將本地的文件上傳到遠程主機上，並且還可以觸發一個 commond，這個功能也是很人性化的，因爲上傳腳本後，往往需要運行一次，避免了我們再登錄到遠程主機上執行一次運行操作。
遠程 Terminal
特別是在 Mac 系統中，我一直苦惱的一件事便是如何管理衆多的遠程機器，我偶爾需要去搭建了博客的主機上查看個人博客爲什麼掛了，偶爾又要去看看我的 ××× 主機排查下爲什麼無法轉發流量了，在開發測試階段，又要經常去測試主機上執行一些簡單的命令。所有這一切通過 ssh 工具去完成都不麻煩，但所有的麻煩事集合到一起時往往會讓我變得焦頭爛額，針對這一點，Cloud Toolkit 簡直是一個 Life Saver。
image-20190604201228263
事實上，在前面的測評中我們已經瞭解到 IDEA 內置了遠程 Terminal 這個功能，Cloud Toolkit 是進一步優化了它的體驗，用戶可以直接在可視化的頁面選擇想要遠程登錄的主機，在對主機加了 Tag 之後，這個過程會更加直觀。
內置應用診斷功能
在測評體驗過程中，意外地發現了 Cloud Toolkit 的一個功能支持，就是前面的截圖有顯示，但我未提到的 Diagnostic （診斷）功能。Cloud Toolkit 集成了阿里巴巴開源的一款應用診斷框架 -- Arthas。
對於本地主機，可以直接通過 Tools -> Alibaba Cloud -> Diagnostic Tools 開啓診斷。
對於遠程主機，可以通過主機管理中的 Diagnostic 選項卡，開啓遠程診斷。
遠程診斷
在過去，我們想要進行診斷，必須要手動在服務器上安裝 Arthas，然而Cloud Toolkit 藉助 Remote Terminal 和 Arthas 的集成，讓這一切都可以在 IDEA 中完成，似乎是想要貫徹這個原則：徹底杜絕第三方工具，一切都用插件完成。
當你遇到以下類似問題而束手無策時，Arthas 可以幫助你解決：
這個類從哪個 jar 包加載的？爲什麼會報各種類相關的 Exception？
我改的代碼爲什麼沒有執行到？難道是我沒 commit？分支搞錯了？
遇到問題無法在線上 debug，難道只能通過加日誌再重新發布嗎？
線上遇到某個用戶的數據處理有問題，但線上同樣無法 debug，線下無法重現！
是否有一個全局視角來查看系統的運行狀況？
有什麼辦法可以監控到 JVM 的實時運行狀態？
作爲一個偏正經的評測，我們試用一下遠程診斷的功能，選取比較直觀的 trace 命令來進行評測。
慢應用
如上圖所示，我們構造了一個慢請求，其中 invokeServiceA_B() 相對於其他方法十分耗時，我們希望通過 Cloud Toolkit 定位到慢調用的源頭，找出 invokeServiceA_B 這個罪魁禍首。
arthas
點擊 IDEA 中對應部署服務器的 Diagnostic 菜單項，就會出現如上圖所示的一個 Arthas 診斷頁面，它會自動關聯到用戶的 Java 進程，用戶只需要選擇相應診斷的進程即可。
image-20190604200009328
在關聯到相應的進程之後，我們執行 trace 指令 trace moe.cnkirito.demo.Application * -j。
這個指令的含義是當 moe.cnkirito.demo.Application 中的任意方法被觸發調用後，會打印出相應的調用棧，並計算耗時，-j 的含義是過濾掉 JDK 內置的類，簡化堆棧。正如上圖所示，我們定位到是 invokeServiceA 的 invokeServiceA_B 最爲耗時。用戶可以自行監控對應的方法，把 * 替換爲想要監控的方式即可。（更多的監控指令可以參考 Arthas 文檔鏈接：https://alibaba.github.io/arthas/）
測評中發現的不足
是軟件就必然有 bug，或者是存在用戶體驗不佳的地方，接下來簡單地羅列下我認爲這款插件不足的幾個方面。
遠程連接容易出現異常
這個問題不是特別容易復現，表現是長時間運行項目後，再部署，會提示遠程連接失敗，在重啓 IDEA 之後可以解決這個問題，原因未知。在後面想要復現時一直無法復現，但的確耗費了我很長的時間，不知道有沒有其他的用戶遇到同樣的問題。
文件瀏覽器過於簡陋
ssh
當嘗試配置 SSH 公私鑰以實現免密登錄時，發現 Browse 打開的文件瀏覽器無法正常顯示 Mac 中的 .ssh 隱藏文件夾，大多數情況下用戶會將 SSH 公私鑰存放在 ~/.ssh 中，這個用戶體驗不是很好，或許有辦法在這個文件瀏覽器中訪問到隱藏文件夾，但至少我還沒找到方法。
缺少遠程主機的可視化功能
Remote Host
IDEA 的默認插件支持 Remote Host 功能，該功能可以讓用戶可視化地管理遠程主機並對其中的文件進行增刪，提升用戶體驗。而 Cloud Toolkit 提供了遠程主機的管理，卻沒有可視化管理其中文件的能力。如果 Cloud Toolkit 實現了 Remote Host 功能，會更方便用戶查看自己的部署結果。從連接協議的選擇上也可以發現，Cloud Toolkit 目前只支持 sftp 協議，而 IDEA 內置的 Deployment 插件還支持 ftp、ftps 等方式。
競品 & 產品定位 & 評價
其實本文基本是圍繞 IDEA 的內置 Deployment 順帶着 Cloud Toolkit 的測評一起進行的。實際上我並不覺得 Cloud Toolkit 存在什麼競品。
競品可能是 xftp 或者 xshell 嗎？它們只是一款 ssh 工具罷了，人家壓根沒想着跟你競爭。
可能是 jenkins 嗎？jenkins 有自己的 devops 流程，側重在持續集成，而 Cloud Toolkit 定位是在日常開發中完成部署驗證等行爲。
在我的測評過程中，能夠感受到這款產品的匠心，幾乎爲所有用戶可能遇到的問題都配備了文檔，比如：不知道啓動腳本怎麼寫？鏈接了常用的 Java 應用啓動腳本；不清楚該使用哪種部署方式？每種方式都有完整的部署文檔；多語言？同時提供了 Go、NodeJS 的部署案例…...同時還支持了一些贈品功能：查看實時日誌，文件上傳，SQL 執行等。
以個人愚見，聊聊這款產品的定位，一方面是雲廠商無關的特性，Cloud Toolkit 提供了 Deploy to Host、內置 Arthas 診斷等功能，造福了廣大的開發者，另一方面是阿里雲服務綁定的一些功能，Cloud Toolkit 爲 ECS、EDAS 用戶帶來了福音，可以享受比普通應用部署更加便捷的操作。前者爲 Cloud Toolkit 積累了業界口碑，後者爲阿里雲付費用戶增加了信心，同時也爲潛在的阿里雲用戶埋下了種子。