大型雲原生專案在數字化企業落地過程解密

當前，隨著網際網路的高速發展，各企業的業務量出現幾何級增長趨勢。越來越多企業發現，使用傳統模式部署及運營的產品越來越難以適應新模式下的要求，運維工作越發難以推進。如何搭建一套能夠滿足子系統高效排程，系統資源充分利用，同時具有動態調整資源，具備高系統擴充套件性的應用排程系統，成為擺在各企業面前的一道難題。

用友雲開發者中心是一個應用全生命週期管理的平臺，它的底層基於容器技術，結合DevOps等理念，為使用者提供了資源管理、持續整合、應用管理等應用基礎服務，同時提供了完備的應用排程服務。現在，開發者中心正用著它全新的技術模式快速改變著公司和使用者建立、釋出和執行分散式應用的方式。

本文將站在實施人員的角度，帶您瞭解面對具體客戶實施現場時需要考慮的實際問題，給出一種通用的部署開發者中心方法，同時解析部署於開發者中心的業務應用的訪問鏈路，分析各訪問環節可能遇到的問題。

通過本文的講解，相信您一定能夠更加熟悉開發者中心在客戶現場的實施過程，同時會對開發者中心的業務鏈路有更加深刻的理解，以便更加容易排查和解決客戶現場可能遇到的業務訪問相關問題。

1 瞭解客戶IT需求，制定實施方案

我們知道，面對具體客戶和其所在行業，會遇到不同的業務需求。平臺所面對的客戶和所需承載的壓力也有不同，為了平臺交付後的穩定執行，在專案實施前需要對客戶的業務進行了解，跟據客戶前期的基礎資料，行業經驗等資訊，與使用者充分溝通後，給出最適合的資源需求清單，並完成方案設計。

在瞭解客戶需求等基本情況時，需要確認的資訊至少應包含客戶的業務特點及規模、平臺註冊使用者數、預期業務峰值與低谷期訪問量、現行業務流、可能出現瓶頸的地方、業務風險、有無外部資料互動等。

瞭解客戶需求後，需要評估IaaS資源需求。評估時，需要考慮客戶的業務特點，綜合評估未來一段時間的業務量，並根據專案經驗評估專案所需資源。

開發者中心對主機資源需求的詳細配置如下表。通常出於提高可用性等原因，建議客戶使用叢集模式安裝平臺。

配置項	叢集模式主機配置推薦	完整安裝模式推薦配置
數量	6+2	1
記憶體	16G及以上	80G 及以上
CPU	8核，2.4G Hz	40核，2.4G Hz
硬碟	（主節點）500GB及以上 （節點機）200GB及以上	1TB及以上
網路卡	1000Mb及以上	1000Mb及以上
作業系統	CentOS 7.4及以上	CentOS 7.4及以上

在客戶需求及基礎資源準備完畢後，需要制定詳細的專案實施方案。制定方案時，應該考慮到以下幾點：

l 產品版本：包括開發者中心版本、所用中介軟體版本、應用版本等

l 基礎設施：包括檢查主機的實際配置，檢查系統安全性，設計網路安全方案等

l 基礎平臺：制定開發者中心的部署方案，著重考慮關鍵節點的高可用實現方法，資料儲存、維護方式等

l 業務架構：制定業務架構方案，制定資料庫、中介軟體等服務部署方案

2 實施部署開發者中心

開發者中心提供了大量的基礎平臺功能，具有較多的功能模組，因此其在實施部署時，需要按其給出的文件，按規範操作進行。

通常，開發者中心建議採用6+n模式實施部署，即平臺部署於6臺伺服器，n臺伺服器接入到資源池中，用於部署業務應用。

在部署平臺前，根據已有計算資源規劃每臺伺服器的用途，較為合理的一種資源配置方案如下表。

開發者中心的部署過程可概述為四個階段：

l 第一階段：在CentOS 7作業系統上，配置並確認好基礎安裝環境

l 第二階段：上傳並解壓開發者安裝包，安裝開發者中心後臺管理系統

l 第三階段：新增節點機，並啟動各個模組

l 第四階段：按順序安裝開發者中心其他元件，完成開發者中心安裝

在第一階段，需要對安裝環境進行確認，保證安裝環境符合安裝要求。具體需要檢查確認的內容包括安裝盤完整性，伺服器作業系統及核心版本，CPU、記憶體、磁碟大小，主機名稱，防火牆狀態，Python版本等。

在第二階段，部署開發者中心後臺管理系統。在此階段中，由於安裝部署內容較多，配置較多，因此安裝過程中最有可能由於環境等原因導致出現安裝異常中斷現象。瞭解具體的安裝內容，可更好的便於在出現異常狀況時定位並排查問題。

在此階段中，具體的安裝內容如下：

1. 平臺根據使用者選擇的安裝模式和指定的IP地址等基礎配置，在系統中載入安裝配置檔案，並對系統進行對應設定；

2. 平臺啟動Nexus服務，同時設定系統的yum源，用於平臺安裝時載入所依賴的系統元件；

3. 安裝Java、系統常用工具如net-tools等，並安裝Docker服務；

4. 解壓映象倉庫等壓縮檔案，並適配所有配置檔案中的內容，以適應當前安裝環境。此步驟需消耗較長時間，安裝過程中需耐心等待；

5. 啟用映象倉庫服務，並拉取平臺所需的模組映象到伺服器中；

6. 安裝並配置Calico網路，建立SDN環境；

7. 通過docker compose服務，啟動平臺依賴的中介軟體服務，同時啟動開發者中心後臺管理系統；

8. 初始化開發者中心所用的資料庫；

9. 在本地安裝Mesos-Slave節點，使本機加入資源池中，具備部署應用能力；

10. 啟動開發者中心的部分基礎模組。

在第三階段，啟動License Server服務，並按照部署計劃，通過開發者中心後臺管理系統，將其他節點機加入至資源池中，然後部署開發者中心全部所需模組。全部模組啟動後，可根據使用者需求配置郵箱地址等使用者定製化內容。

在第四階段，按照安裝文件要求，在各伺服器中依次安裝Kubernetes Master服務、系統監控服務、DNS服務、監控大盤服務等，完成平臺的實施過程，並驗證平臺功能。

3 功能模組全景圖

開發者中心所涉及的模組眾多，依賴中介軟體也較多，理清各模組間的呼叫關係，以及依賴的中介軟體關係，有助於在使用開發者中心遇到平臺相關問題時，快速定位出現問題的模組，找出問題的原因所在，並解決問題。

開發者中心各模組可按其功能歸類。具體的類別、功能描述、模組間呼叫關係，及其依賴的中介軟體可見下文。開發者中心的大多數模組均用到了MySQL資料庫服務、Redis快取服務、ZooKeeper分部式協調服務，在描述中不再贅述。

許可權控制及域名管理類

包括單點登入器、使用者中心、租戶中心、校驗中心、域名管理等模組，用於控制使用者的登入，系統許可權，域名訪問等功能。使用者通過DNS、Nginx等中介軟體訪問平臺後，首先呼叫的即此類別中的模組。一些Spring Cloud微服務相關的元件也在此類中。

前端工程類

包括門戶和前端工程兩個模組，用於在瀏覽器中向使用者展現和互動平臺功能。使用者登入系統後，通過前端工程訪問平臺提供的如資源池管理、持續整合、應用管理等功能。

資源池服務類

包括資源池管理、資源池API、遠端登入、資源池定時任務等四個模組，用於提供資源池管理相關功能。使用者可將自有伺服器新增至資源池中，以部署業務應用。此類服務依賴中介軟體MongoDb，用來快取節點部署應用數等狀態資訊。

構建與部署類

包括持續整合、應用部署、定時排程等三個模組，用於提供持續整合相關功能。持續整合中的持續構建任務和流水線任務，均通過持續整合模組實現，構建映象後通過應用部署模組，將任務傳送至應用管理模組。設定定時構建的流水線任務，將通過定時排程模組觸發任務，完成指定的工作。需要注意的是，在應用部署時，僅第一次部署的新應用會呼叫應用部署模組。已部署的應用在執行部署操作時，會直接呼叫應用管理模組。使用者通過流水線任務構建應用時，上傳的war包等資源會儲存於FastDFS提供的分散式儲存服務中。

應用管理類

包括應用管理、定時排程、智慧運維、應用拓撲圖等四個模組，用於提供應用管理相關功能。應用管理模組向使用者提供當前部署的應用狀態等資訊，智慧運維向使用者推薦最可能操作應用。此類模組呼叫中介軟體較多，如RabbitMQ訊息佇列服務，系統監控服務，應用效能監控服務等。使用者部署應用在資源池節點機中，其依賴於Mesos/Marathon服務，Calico、etcd服務等。

基礎資料管理類

包括統一接入、基礎資料、許可權模型等三個模組，用於提供基礎資料管理相關功能。使用者在建立應用後，會通過基礎資料模組將應用資訊儲存至資料庫中，以便於其他模組統一呼叫。應用的授權、統一接入等功能也由此類模組提供。

映象倉庫服務類

包括映象認證服務、映象倉庫、映象同步等三個模組，用於提供映象倉庫服務相關功能。使用者構建的應用每次執行構建操作時，均會通過此類服務，將映象儲存至伺服器中。此類模組依賴映象倉庫中介軟體，同時在資源池節點機在啟動業務應用時，相其提供對應的應用映象。

監控服務類

包括監控大盤API、前端埋點、監控大盤後臺、全鏈路監控等模組，用於監控並記錄應用執行時的狀態。通過此類模組可更加深入的瞭解應用執行時的狀況，如應用佔用資源情況，應用內部請求呼叫鏈路及耗時等資訊。此類模組依賴中介軟體ElasticSearch、Kibana、kafka等，儲存監控資訊。

報警、變更及日誌類

包括報警中心、變更大盤、應用日誌、簡訊服務等模組，用於採集應用執行時日誌，記錄應用變更狀態等資訊，並在出現應用異常狀況時觸發報警系統。

資源申請及審批類

包括資源池申請、應用審批、中介軟體管理等模組，用於快速搭建業務應用所需中介軟體，及進行業務應用相關審批流程。

4 基於Docker+Calico網路的應用部署架構

開發者中心在部署應用時，使用Docker技術來構建應用映象，將任務傳送至資源池中，由資源排程系統定奪接收任務的節點機，並通過Docker容器的方式啟動應用。

Docker是一個開源的引擎，可以輕鬆的為任何應用建立一個輕量級的、可移植的、自給自足的容器。使用Docker，可以實現更快速的交付和部署應用，方便的對應用例項進行擴容縮容等操作，與Mesos排程框架結合，能夠進一步提高系統資源的利用率，簡化應用管理過程。

當應用部署至各節點機後，接下來需要考慮並解決的問題是跨主機容器通訊問題。開發者中心採用Calico搭建SDN網路，解決多主機容器網路問題。

在原理上，使用Calico 搭建的虛擬網路中，整個過程始終都是根據iptables規則進行路由轉發，並沒有進行封包/解包的過程，這使得其傳輸效率更高。

5 應用訪問鏈路物理結構

如前文所述，應用可基於Mesos架構，使用Docker技術部署於Calico的虛擬網路中。一個應用可以啟動多個例項，以實現高可用特性。當應用的一個例項出現問題時，只要系統中此應用仍有其他例項存活，即可保證整個業務系統的可用性。

一個應用的多個例項之間，需要由服務發現和負載均衡技術實現業務的統一出口，開發者中心採用Marathon-LB來實現此功能。Marathon-LB是Marathon的服務發現系統，它使用HAProxy實現代理伺服器的功能。使用Marathon-LB可以配置應用的固定埠，而訪問應用的IP就是執行Marathon-LB的節點機IP。Marathon LB會監聽Marathon的排程事件，獲取容器實際執行的IP與埠，然後更新HAProxy的配置檔案。因此，當重新部署應用時，仍然可以通過固定的IP與埠訪問該應用。Marathon-LB的服務發現功能由系統自動完成，使用者無需手動配置。

Mesos-DNS主要功能是對部署在Mesos架構下的應用生成域名，並提供相應的域名解析服務。Mesos-DNS為Mesos任務定義了一個DNS域，預設為.mesos。此時，使用者直接訪問由Mesos-DNS生成的域名來訪問應用。但是大多數情況下，使用者難以感知和記錄自動生成的DNS地址來訪問服務，因此此項功能更多用於平臺內部應用相互呼叫時的場景。

那麼，使用者如何使用自定義的域名，來訪問自己構建部署的業務應用呢？此時Ceryx便可登場了。Ceryx是一個動態反向代理，它的內部依託於Nginx服務，可代理主機上任意多的服務，同時它的配置可即時生效。Ceryx的這種域名解析服務又被稱為泛域名解析服務。在Ceryx的幫助下，使用者可自定義業務應用的域名，並由此來訪問業務應用。

在開發者中心建立的應用體系內，不僅僅有業務應用，更有一些平臺內部服務作為底層支撐，所有服務均需有相同的統一出口，便於統計和管理。同時在一些專案內，客戶也有需要配置短域名等需求。Nginx作為反向代理（Reverse Proxy），可滿足上述的全部要求。Nginx可以以代理伺服器來接受網路上的連線請求，然後將請求轉發給內部網路上的服務，這個Nginx所在的代理伺服器對外就表現為一個伺服器。

最後，在接入層面，開發者中心使用DNS實現對訪問域名的解析。所謂域名解析，即通過域名得到該域名對應的IP地址的過程。域名是網際網路上的身份標識，是不可重複的唯一標識資源。當使用者配置了主機的DNS為開發者中心的DNS後，即可使用自定義域名放問開發者中心和業務應用。

6 應用訪問過程詳解

在瞭解了開發者中心應用訪問物理鏈路後，可以模擬一次請求，以更清晰的瞭解應用的訪問過程。本文以模擬一個業務域名a.app.yyuap.com為例，描述其訪問過程如下：

1. 使用者輸入域名後，通過DNS域名解析服務，將請求轉發至Nginx反向代理服務；

2. Nginx通過內部的匹配規則，尋找並匹配最優解。Nginx在匹配域名至對應的location時有著複雜的匹配規則，感興趣的讀者可查閱相關資料，這裡不再贅述；

3. Nginx匹配到對應的轉發規則後，將請求轉發至Ceryx服務。此時Nginx提交請求的訪問域名仍為a.app.yyuap.com，未做任何解析和轉換；

4. EDNA服務實時獲取使用者的域名配置，並主動將其重新整理至Redis快取服務中；

5. Ceryx從Redis快取服務中獲取對應的域名解析規則，並將域名轉換為由mesos生成的域名地址；

6. Ceryx獲取到了轉換後的地址，如marathon-lb.isv.marathon.mesos:36273。36273埠是Marathon-LB服務為應用代理的隨機埠號。此時完成了泛域名解析的工作；

7. Ceryx通過Mesos-DNS域名解析服務，獲取marathon-lb.isv.marathon.mesos 的實際IP地址，如192.168.33.101；

8. 請求繼續轉發至Marathon-LB負載均衡服務；

9. Marathon-LB內部由HAproxy服務實現，其根據埠號尋找定位應用例項；

10. Marathon-LB定位成功後，根據指定的演算法規則，將請求匹配至應用中健康的某一例項下，並將請求地址轉換為由Calico虛擬網路生成的業務Docker例項IP和埠，如172.20.17.11:31999，轉發此請求。

11. 業務應用的Docker例項處理此請求，並將請求原路轉發返回，最終返回至使用者端。

以上即開發者中心中，應用的一次完整的請求訪問過程。

7 業務訪問關鍵節點問題排查方法

在應用的訪問鏈路中，任何一個關鍵節點出現故障，均可能導致應用訪問請求失敗，在瀏覽器頁面中出現503、504等錯誤程式碼提示。瞭解各關鍵節點的部署位置，部署方式，應用鏈路相關資料，將有助於出現應用鏈路錯誤時，排查問題。

DNS服務相關問題排查方法

DNS服務即域名解析服務，由實施部署平臺時，在規劃伺服器中手動啟動執行。DNS服務由BIND服務實現，並使用Docker容器方式啟動。

l 確認DNS容器存在並正在執行：登入DNS所在主機，執行 docker ps | grep bind 命令，若返回對應容器資訊，且狀態為RUNNIND，可確認DNS容器存在，否則需重新啟動DNS服務；

l 確認DNS服務日誌無異常或錯誤資訊：通過docker logs -f DNS容器ID命令，可跟蹤檢視DNS的docker容器輸出日誌，判斷是否有異常發生；

l 確認DNS的轉發規則中配置了所需的域名：編輯install_dns.sh檔案，檢視env變數的配置，此變數為DNS的轉發規則。若其配置沒有正確填寫，需修改為正確的配置後，重新啟動DNS服務，使配置生效；

l 確認發出請求主機或伺服器配置了對應的DNS服務：在每臺伺服器的/etc/resolv.conf檔案中，配置了DNS的地址。若沒有正確配置，則請求中的域名將無法正常解析。

Nginx服務相關問題排查方法

Nginx服務負責提供反向代理服務，在實施部署平臺時，一般部署於開發者中心主節點中。Nginx服務由docker-compose方式啟動。

l 確認Nginx容器存在並正在執行：登入開發者中心主節點伺服器，執行 docker ps | grep nginx 命令，可檢視對應容器及狀態。如需重啟Nginx服務，則需進入${DCEE_HOME}/script/compose_manage目錄，執行docker-compose up -d nginx命令；

l 確認服務埠存活，且伺服器的防火牆設定為允許訪問狀態：一般情況下，Nginx的服務埠設定為80。在伺服器中執行netstat -tunlp| grep 80命令，可檢視80埠存活，及是否由Nginx服務佔用；

l 確認Nginx的配置檔案正確：進入${CONFIG_CENTER}/nginx目錄中，應用的配置資訊位於upstream-dev.conf檔案中。開啟並確認檔案中的配置是否正確。修改配置檔案後，需重啟Nginx的docker容器，使配置生效。

Ceryx服務相關問題排查方法

Ceryx服務負責提供泛域名解析服務，在實施部署平臺時，由使用者在開發者中心後臺管理系統中啟動。Ceryx服務使用Docker容器啟動，執行於開發者中心的主節點或從節點中。

l 確認Ceryx服務是否正常執行：在瀏覽器中開啟並登入開發者中心後臺管理系統，在容器管理中檢視Ceryx容器執行狀態，若無此容器或容器健康狀況不為健康，則可通過檢視日誌等方法，使Ceryx服務正常工作；

l 確認Redis快取中有對應資料：Ceryx服務對應用的轉發請求依賴於Redis服務，其會從Redis快取中獲取應用轉發地址。通過工具檢視Redis服務中資料，若無對應資料，則可能EDNA服務出現異常。

Marathon-LB服務相關問題排查方法

Marathon-LB服務負責提供負載均衡功能，其在安裝開發者中心主節點服務時自動部署啟動。在Marathon-LB容器的內部，負載均衡功能實際由HAProxy服務完成。

l Marathon-LB服務是否正常啟動：登入開發者中心後臺管理系統，在容器管理中檢視marathon-lb容器狀態。Marathon-LB正常工作需佔用較大記憶體，建議適當增加記憶體分配，保障服務穩定可用；

l Marathon-LB註冊埠是否與伺服器本地埠有衝突：由於Marathon-LB在工作時需向所在宿主機申請大量埠，若出現與伺服器的埠衝突的情形，則會導致Marathon-LB服務無法正常工作。導致埠衝突的可能的原因較多，如宿主機埠被使用者應用或其他中介軟體佔用，應用在長連線未斷開時被更新，Calico使用隨機埠訪問等。排查問題時需根據使用者實際環境，一一排查；

l Haproxy頁面是否含有應用註冊的相關資訊：在瀏覽器中輸入http://開發者中心主控機IP:9090/haproxy?stats，訪問HAProxy資訊頁，確認訪問的應用是否已註冊至HAProxy中。

總結

本文對開發者中心的實施過程進行了簡單介紹，同時著重介紹了基於開發者中心搭建應用的部署架構，並詳細解析應用訪問過程，給出了幾種排查應用訪問關鍵節點問題的方法。

通過本文，您可以瞭解開發者中心的實施部署過程，瞭解功能模組及其用途，對部署於開發者中心的應用訪問鏈路有更加深入的理解。同時可以以此為依據，解決在使用開發者中心時遇到的應用訪問鏈路問題。

需要讀者注意的是，影響業務正常訪問的因素仍然有很多，如伺服器問題、平臺架構服務問題、應用自身問題、網路問題等。排查問題時，不限於本文列出的情形及解決辦法。希望本文能夠拋磚引玉，給讀者您帶來更多解決問題的思路。

開發者中心還有更多的功能和祕密，等待著你來探索！