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

當前，隨着互聯網的高速發展，各企業的業務量出現幾何級增加趨勢。愈來愈多企業發現，使用傳統模式部署及運營的產品愈來愈難以適應新模式下的要求，運維工做愈加難以推動。如何搭建一套可以知足子系統高效調度，系統資源充分利用，同時具備動態調整資源，具有高系統擴展性的應用調度系統，成爲擺在各企業面前的一道難題。
用友雲開發者中心是一個應用全生命週期管理的平臺，它的底層基於容器技術，結合DevOps等理念，爲用戶提供了資源管理、持續集成、應用管理等應用基礎服務，同時提供了完備的應用調度服務。如今，開發者中心正用着它全新的技術模式快速改變着公司和用戶建立、發佈和運行分佈式應用的方式。
本文將站在實施人員的角度，帶您瞭解面對具體客戶實施現場時須要考慮的實際問題，給出一種通用的部署開發者中心方法，同時解析部署於開發者中心的業務應用的訪問鏈路，分析各訪問環節可能遇到的問題。
經過本文的講解，相信您必定可以更加熟悉開發者中心在客戶現場的實施過程，同時會對開發者中心的業務鏈路有更加深入的理解，以便更加容易排查和解決客戶現場可能遇到的業務訪問相關問題。

1 瞭解客戶IT需求，制定實施方案
咱們知道，面對具體客戶和其所在行業，會遇到不一樣的業務需求。平臺所面對的客戶和所需承載的壓力也有不一樣，爲了平臺交付後的穩定運行，在項目實施前須要對客戶的業務進行了解，跟據客戶前期的基礎數據，行業經驗等信息，與用戶充分溝通後，給出最適合的資源需求清單，並完成方案設計。
在瞭解客戶需求等基本狀況時，須要確認的信息至少應包含客戶的業務特色及規模、平臺註冊用戶數、預期業務峯值與低谷期訪問量、現行業務流、可能出現瓶頸的地方、業務風險、有無外部數據交互等。
瞭解客戶需求後，須要評估IaaS資源需求。評估時，須要考慮客戶的業務特色，綜合評估將來一段時間的業務量，並根據項目經驗評估項目所需資源。
開發者中心對主機資源需求的詳細配置以下表。一般出於提升可用性等緣由，建議客戶使用集羣模式安裝平臺。

在客戶需求及基礎資源準備完畢後，須要制定詳細的項目實施方案。制定方案時，應該考慮到如下幾點：
 產品版本：包括開發者中心版本、所用中間件版本、應用版本等
 基礎設施：包括檢查主機的實際配置，檢查系統安全性，設計網絡安全方案等
 基礎平臺：制定開發者中心的部署方案，着重考慮關鍵節點的高可用實現方法，數據存儲、維護方式等
 業務架構：制定業務架構方案，制定數據庫、中間件等服務部署方案
2 實施部署開發者中心
開發者中心提供了大量的基礎平臺功能，具備較多的功能模塊，所以其在實施部署時，須要按其給出的文檔，按規範操做進行。
一般，開發者中心建議採用6+n模式實施部署，即平臺部署於6臺服務器，n臺服務器接入到資源池中，用於部署業務應用。
在部署平臺前，根據已有計算資源規劃每臺服務器的用途，較爲合理的一種資源配置方案以下表。

開發者中心的部署過程可概述爲四個階段：
 第一階段：在CentOS 7操做系統上，配置並確認好基礎安裝環境
 第二階段：上傳並解壓開發者安裝包，安裝開發者中心後臺管理系統
 第三階段：添加節點機，並啓動各個模塊
 第四階段：按順序安裝開發者中心其餘組件，完成開發者中心安裝

在第一階段，須要對安裝環境進行確認，保證安裝環境符合安裝要求。具體須要檢查確認的內容包括安裝盤完整性，服務器操做系統及內核版本，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 功能模塊全景圖
開發者中心所涉及的模塊衆多，依賴中間件也較多，理清各模塊間的調用關係，以及依賴的中間件關係，有助於在使用開發者中心遇到平臺相關問題時，快速定位出現問題的模塊，找出問題的緣由所在，並解決問題。
][6]
開發者中心各模塊可按其功能歸類。具體的類別、功能描述、模塊間調用關係，及其依賴的中間件可見下文。開發者中心的大多數模塊均用到了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 業務訪問關鍵節點問題排查方法
在應用的訪問鏈路中，任何一個關鍵節點出現故障，都可能致使應用訪問請求失敗，在瀏覽器頁面中出現50三、504等錯誤代碼提示。瞭解各關鍵節點的部署位置，部署方式，應用鏈路相關數據，將有助於出現應用鏈路錯誤時，排查問題。

DNS服務相關問題排查方法
DNS服務即域名解析服務，由實施部署平臺時，在規劃服務器中手動啓動執行。DNS服務由BIND服務實現，並使用Docker容器方式啓動。
 確認DNS容器存在並正在運行：登陸DNS所在主機，執行 docker ps | grep bind 命令，若返回對應容器信息，且狀態爲RUNNIND，可確認DNS容器存在，不然需從新啓動DNS服務；
 確認DNS服務日誌無異常或錯誤信息：經過docker logs -f DNS容器ID命令，可跟蹤查看DNS的docker容器輸出日誌，判斷是否有異常發生；
 確認DNS的轉發規則中配置了所需的域名：編輯install_dns.sh文件，查看env變量的配置，此變量爲DNS的轉發規則。若其配置沒有正確填寫，需修改成正確的配置後，從新啓動DNS服務，使配置生效；
 確認發出請求主機或服務器配置了對應的DNS服務：在每臺服務器的/etc/resolv.conf文件中，配置了DNS的地址。若沒有正確配置，則請求中的域名將沒法正常解析。

Nginx服務相關問題排查方法
Nginx服務負責提供反向代理服務，在實施部署平臺時，通常部署於開發者中心主節點中。Nginx服務由docker-compose方式啓動。
 確認Nginx容器存在並正在運行：登陸開發者中心主節點服務器，執行 docker ps | grep nginx 命令，可查看對應容器及狀態。如需重啓Nginx服務，則需進入${DCEE_HOME}/script/compose_manage目錄，執行docker-compose up -d nginx命令；
 確認服務端口存活，且服務器的防火牆設置爲容許訪問狀態：通常狀況下，Nginx的服務端口設置爲80。在服務器中執行netstat -tunlp| grep 80命令，可查看80端口存活，及是否由Nginx服務佔用；
 確認Nginx的配置文件正確：進入${CONFIG_CENTER}/nginx目錄中，應用的配置信息位於upstream-dev.conf文件中。打開並確認文件中的配置是否正確。修改配置文件後，需重啓Nginx的docker容器，使配置生效。

Ceryx服務相關問題排查方法
Ceryx服務負責提供泛域名解析服務，在實施部署平臺時，由用戶在開發者中心後臺管理系統中啓動。Ceryx服務使用Docker容器啓動，運行於開發者中心的主節點或從節點中。
 確認Ceryx服務是否正常運行：在瀏覽器中打開並登陸開發者中心後臺管理系統，在容器管理中查看Ceryx容器運行狀態，若無此容器或容器健康情況不爲健康，則可經過查看日誌等方法，使Ceryx服務正常工做；
 確認Redis緩存中有對應數據：Ceryx服務對應用的轉發請求依賴於Redis服務，其會從Redis緩存中獲取應用轉發地址。經過工具查看Redis服務中數據，若無對應數據，則可能EDNA服務出現異常。

Marathon-LB服務相關問題排查方法
Marathon-LB服務負責提供負載均衡功能，其在安裝開發者中心主節點服務時自動部署啓動。在Marathon-LB容器的內部，負載均衡功能實際由HAProxy服務完成。
 Marathon-LB服務是否正常啓動：登陸開發者中心後臺管理系統，在容器管理中查看marathon-lb容器狀態。Marathon-LB正常工做需佔用較大內存，建議適當增長內存分配，保障服務穩定可用；
 Marathon-LB註冊端口是否與服務器本地端口有衝突：因爲Marathon-LB在工做時需向所在宿主機申請大量端口，若出現與服務器的端口衝突的情形，則會致使Marathon-LB服務沒法正常工做。致使端口衝突的可能的緣由較多，如宿主機端口被用戶應用或其餘中間件佔用，應用在長鏈接未斷開時被更新，Calico使用隨機端口訪問等。排查問題時需根據用戶實際環境，一一排查；
 Haproxy頁面是否含有應用註冊的相關信息：在瀏覽器中輸入http://開發者中心主控機IP:9090/haproxy?stats，訪問HAProxy信息頁，確認訪問的應用是否已註冊至HAProxy中。

總結
本文對開發者中心的實施過程進行了簡單介紹，同時着重介紹了基於開發者中心搭建應用的部署架構，並詳細解析應用訪問過程，給出了幾種排查應用訪問關鍵節點問題的方法。
經過本文，您能夠了解開發者中心的實施部署過程，瞭解功能模塊及其用途，對部署於開發者中心的應用訪問鏈路有更加深刻的理解。同時能夠以此爲依據，解決在使用開發者中心時遇到的應用訪問鏈路問題。
須要讀者注意的是，影響業務正常訪問的因素仍然有不少，如服務器問題、平臺架構服務問題、應用自身問題、網絡問題等。排查問題時，不限於本文列出的情形及解決辦法。但願本文可以拋磚引玉，給讀者您帶來更多解決問題的思路。
開發者中心還有更多的功能和祕密，等待着你來探索！