在創業公司，不懂運維的程序員如何兼顧公司的運維工做

我是一名創業公司的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將來能夠提供更加簡單的操做體驗，進一步提升咱們的工做效率。例如，一次引導用戶配置使用後，即可實現全自動化，資源自動整合達到用戶所想要的效果，包括一鍵拉起完整測試環境，一鍵搭建一主一備的異地多活架構等。