在创业公司，不懂运维的程序员如何兼顾公司的运维工作
我是一名創業公司的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未來可以提供更加簡單的操作體驗，進一步提高我們的工作效率。例如，一次引導用戶配置使用后，便可實現全自動化，資源自動整合達到用戶所想要的效果，包括一鍵拉起完整測試環境，一鍵搭建一主一備的異地多活架構等。
總結
以上是生活随笔為你收集整理的在创业公司，不懂运维的程序员如何兼顾公司的运维工作的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用Python将Excel中的数据导入
- 下一篇： [Cinder] 存储 Qos