我是一名創業公司的Java開發工程師，公司沒有運維團隊，由程式設計師負責代運維。

公司的產品幾乎都是部署在阿里雲上，專案存在需要頻繁改動並經常上線釋出的情況。但通過Jenkins本地構建然後再發布到阿里雲的ECS上的流程已經不太適用於當前的業務場景，再加上整個專案的IT架構已經升級改造為Spring Cloud微服務體系，在這套微服務架構中，原本很多服務都被打散，對應用的釋出就顯得更加複雜和容易出錯，這時候需要一套更加健全和可靠的線上釋出流程。

業務挑戰

由於業務不太穩定，存在大面積的老業務下線和新業務上線的情況，每一次釋出專案都需要整站暫停訪問來發布新的內容上線，這對使用者來說很不友好。我們需要在不停機的情況下，釋出專案快速註冊，並立即實現註冊中心可以對外提供服務訪問，以及必要時進行灰度釋出，但這些都是當前所欠缺的。

測試環境因專案進行拆分，微服務專案數量已達30個。每一次有新的需求過來，都是在專案的新建分支上進行開發，這樣前面的流程還沒有測試完畢，測試人員就會被開發人員提交到測試環境的自動構建的新程式碼給被迫暫停，等待構建完畢以後，由於改動了程式碼相關的功能，測試人員又需要進行重新測試，導致沒有一個完整的環境來交付給測試團隊進行持續測試。我們希望一旦出現新的改動，可以快速拉起來一套新的測試環境，以便測試團隊完成全流程測試以後再釋放資源，從而降低測試的工作量以及伺服器資源的成本。

在對比多個解決方案後，我們選用了阿里雲企業級分散式應用管理服務EDAS，EDAS包含的功能，以及能夠實現的效果很符合公司目前的需求，並帶來一些我們之前敢想，但是又不敢去實現的功能，大大降低了公司技術團隊運維方面的壓力，以及線上的各種監控指標，還能提高基礎服務的穩定性。

以下是我對阿里雲EDAS的測評，希望對那些在創業公司做業務開發的同時還需要兼顧運維的程式設計師有所幫助。

EDAS Serverless 操作體驗

首先從控制檯進入EDAS，在選擇名稱空間裡，管理控制檯右方出現了地區的切換以及選擇，這個時候選擇切換至華北2（北京）地區，這個時候，看到管理控制檯下方的企業級分散式應用服務出現了一個小箭頭，點選後選擇企業級分散式應用服務 - Serverless ，進入本次測評。

這個進入服務的操作流程以及切換稍顯複雜，建議在進入EDAS服務中預設是進入概述，是否能在出現概述的時候就增加出現地區的切換以及選擇，這樣可以少操作一步來快速進入想操作的地區。

接下來進入到了EDAS Serverless服務的頁面如下圖：

進行一個應用建立，介面如下圖：

在整個頁面上看來，所需要填寫的內容都還是很清晰和容易理解的，關於當前你免費體驗公測版Serverless應用的剩餘額度為 9 Core 9GiB 這段提示這裡，我的剩餘額度比剛開通進入該服務的小夥伴要多，這個是因為進行了工單申請然後通過稽核後給予我這邊提升了資源數量，在這裡額外點贊一下工單系統，是一個相當優秀的功能，已經處理過我們這種運維門外漢的相當多的問題，而且回答的內容都很細緻和認真，都是從使用者的角度出發和考慮來解決問題的。

接下來開始進行建立應用，我這邊填上對應的引數如下圖：

在這裡提一句VPC因為我沒有提前在北京區域建立過，在這個頁面看到提示建立VPC，建立VPC大概僅需1分鐘。

點選下一步，應用部署配置出現如下圖：

因為在開頭提到過，公司沒有運維團隊，所以對於Docker以及K8S都是出於0的狀態，所以本次部署方式不採用映象的形式，而是沿用目前的Jar包部署方式。

現在本地Jar包部署的方式通過了指令碼來操作並且在啟動時注入了一些引數例如：--spring.profiles.active=prod通過這些引數來區分一些不同環境對於的不同配置檔案，但是在本次進行測評的EDAS Serverless釋出的版本中，暫時還不支援Jar包部署方式的自定義啟動引數，所以將本地專案進行了一下修改和調整增加了一份application.properties這樣的配置檔案用來配合Jar包部署方式。Jar包部署方式頁面填寫引數具體內容如下圖：

選擇Java環境完畢以後，再接著上傳所需要部署的Jar包，這整個過程是很簡單和容易理解的。準備完畢以後點選確認建立按鈕，完成建立。確認建立完畢如下圖：

根據提示點選應用詳情頁跳轉至我們剛剛建立釋出的專案詳細資訊中，如下圖：

在本頁面等待1-2分鐘以後進入側邊的實時日誌檢視一下當前專案的情況，如下圖：

就可以看到專案的執行和啟動情況了，接著點選側邊的基本資訊欄回到基本資訊進行公網訪問地址的新增，測試一下公網是否能夠訪問當前專案，如下圖：

因為我當前的專案是80埠，所以對應也對映80埠，這個新增公網SLB訪問配置起來是非常簡化的，不用自己去新建一個SLB例項然後在進行配置了，直接在這裡配置雙向的埠點選確定就完成了一整套的建立，使用起來是相當方便的，點選確定後等待1分鐘刷新出現的內容，如下圖：

這樣一個對公網的對映就已經完成了，接下來嘗試一下進行訪問，檢測服務是否正常如下圖：

測試是能進行訪問的，以及我們的服務也是正常部署。下面嘗試一下應用擴縮功能，在基本資訊頁面，右上角有一個應用擴縮的按鈕點選後出現，如下圖：

我們嘗試調整為4個例項數，在這裡有一點小建議，不知道後續版本如何，但是這個地方應該變更為彈性伸縮，讓使用者自定義擴容引數和條件，以及縮容引數和條件，這樣更加實用以及貼合實際生產環境的需求。設定為4，點選確定按鈕後，如下圖：

在當前頁面的資料會每5秒重新整理一次，這個時候就可以實時看到自己擴容的例項的狀態，等待了1分鐘左右所有的擴容例項執行狀態都變為 Running 了這個時候在訪問剛才設定的公網訪問地址:39.97.9.248:80，多次重新整理測試以後發現剛才的四個例項都已經通過這個地址進行負載均衡了，新手不太懂底層的原理，原本以為建立完畢以後還需要自己手動設定一下負載均衡，測試以後發現已經自動實現了，這個是一個很舒服的點。

基於Jar包方式部署的內容到這裡基本上就已經測試完畢了，從整體流程體驗下來是相當容易上手和理解的，而且幾乎全程都不需要檢視幫助文件，簡單的理解一下頁面上的字面意思即可完成一套服務的釋出以及部署，是相當適合我們這種完全0知識基礎的小白使用者的，讓使用者簡單上手達到需要的目標，並且體驗過程中沒有出現難以理解和明白的地方，這個方面是處理的相當到位的，化簡為繁簡單易用。

支援原生Dubbo和Spring Cloud

基於阿里雲官方給出的兩個案例，增加了一個gateway-zuul專案進行Spring Cloud的操作體驗。按照官方操作文件，配置alibaba.edas.access-key 和 alibaba.edas.secret-key。完成配置後，就可以放到EDAS Serverless裡面去建立一個應用進行部署了，下載以後只需要改動配置檔案裡面的id ，ac key ，se key ，end這幾個引數即可，這些引數可以在如下圖：

名稱空間中，找到然後滑鼠移動到Key上面然後出現複製為properties格式，這樣操作一下然後在配置到案例中即可，這裡操作配置完畢以後，建立了三個新的應用如下圖：

一個服務釋出者，一個服務消費者，一個zuul閘道器。然後根據案例中寫的介面進行消費者請求測試，結果如下圖：

都是正常OK的，沒有出現任何問題，然後在進行閘道器的請求和測試如下圖：

因為轉發的匹配規則是api-consumer，所以請求閘道器的地址後面跟上了這一段引數，測試下來也是能成功轉發並且正常請求到對應的專案。

這樣本地基於Spirng Cloud的專案，只需要修改相關的POM依賴檔案，即可進行無縫接入了，專案中使用到的Feign，也都不需要進行更改和重新編碼，這個為接入EDAS專案省下來了很多力氣，這方面的體驗很好。當然在接入的時候發現對應的EDAS的一些功能目前暫時還不支援，比如全鏈路的鷹眼，以及日誌，相信這些功能都會在後續的版本陸陸續續加上並且支援。

總結下來支援原生Spring Cloud操作體驗：是相當流暢的，幾乎就是出於無縫接入的情況，僅需要稍稍的修改一些依賴和配置，就能輕鬆遷移到EDAS Serverless中，包括這樣一套完善穩定可靠的基礎服務，以及額外擴充套件功能，比自己搭建一套Spring Cloud基礎服務要輕鬆方便太多，大大提升了開發者的開發效率，專注業務層，至於基礎層面的東西就完全放心的交給阿里雲來處理無需任何的擔心，以及接入過程中遇到問題，在釘釘群中大家的相互配合使得一切問題都不是問題。

與其他運維工具對比的優劣勢

因為本人不是專門的運維出生，目前僅使用過Jenkins + GitLab進行CI/CD，本地的流程是Dev環境和Test環境，根據開發人員提交或者合併程式碼到對應的Dev和Test分支，GitLab就會呼叫對應Jenkins專案進行自動構建，然後開始完成程式碼提交，再執行構建更新發布操作，這樣的情況下對於開發測試都不是很友好，流程不完善和健全，線上環境是在Test環境全部測試OK後，手動點選所需要釋出的專案進行構建再發布，如果是所有專案進行釋出的話，則需要一個個進行點選，而且整一個釋出時間達20分鐘左右，在這20分鐘內整個網站的訪問都是不正常的。

目前，因為EDAS Serverless還有一些EDAS中的功能暫未接入，以及雲效還未支援，但是從案例和自己測試體驗下來看，接入這樣一套大環境以後，開發測試環境以後的健壯性將得到更多的保障，以及程式碼提交完畢以後的自動化，程式碼審計，單元測試，這些都將得到補充，基礎設施的管理將更加完善和安全。此外，線上環境的釋出和部署，也不會再耗費這麼多的時間，出現任何問題都支援快速回滾，後續還需要支援灰度釋出，這些都是接入EDAS+雲效以後能夠帶來的。價格方面，EDAS Serverless版本相比EDAS，節省了不少ECS計算資源上的成本，對於創業企業來講，是非常有吸引力的。

對EDAS的整體認知，以及優化方向

我們是網際網路金融創業企業，做的是電子承兌票相關的業務，和銀行進行對接支付，使用者群體是企業財務人員以及業務人員，對安全性和穩定性要求高。團隊目前的測試環境不夠完善，30個專案只有一個測試環境，當來了新的需求和功能的時候，都需要在新分支開發，開發完畢後再合併到test環境，或者不合並直接在test環境構建對應分支，這樣對測試環境來說是極大的不方便，需要一套能夠快速一鍵跑起來的測試環境，這樣便於測試針對各種不同的特性進行相應的測試。

公司目前沒有專職運維團隊，並且中短期內暫無配置計劃，線上的穩定性非常依賴EDAS，希望EDAS未來可以提供更加簡單的操作體驗，進一步提高我們的工作效率。例如，一次引導使用者配置使用後，便可實現全自動化，資源自動整合達到使用者所想要的效果，包括一鍵拉起完整測試環境，一鍵搭建一主一備的異地多活架構等。