最近感覺基于微服務架構下的容器化PaaS平臺還有必要進一步將思考的內容做一下整理，即在出現(xiàn)容器化和微服務架構后，對于傳統(tǒng)的私有云PaaS平臺究竟出現(xiàn)了哪些轉變，以及我們在設計這種容器化PaaS平臺的時候又需要考慮哪些內容等。
對于這些問題，首先會做一些零散的記錄，后續(xù)再進行系統(tǒng)化的整理。
一個PaaS平臺核心的管理對象就是業(yè)務系統(tǒng)，即每個業(yè)務系統(tǒng)都是PaaS平臺里面的一個租戶，在傳統(tǒng)PaaS下我們只需要管理到業(yè)務系統(tǒng)這個級別就可以了，在微服務架構結合后則需要管理到微服務模塊。即首先是應用注冊和管理功能，但是應用注冊后，還可以進一步注冊多個微服務模塊，每個微服務模塊是管理的最小單位。每個微服務模塊可以獨立進行設計，開發(fā)，打包和部署，包括后續(xù)的運行監(jiān)控。
PaaS平臺應該提供完整的開發(fā)者門戶功能，實現(xiàn)面向開發(fā)者的自服務流程和管控功能，簡單來說就是應該實現(xiàn)應用生命周期管理和服務生命周期管理兩條核心線條的管理能力。同時對于應用生命周期管理是到微服務模塊級別的管理能力。應用-》微服務模塊應該是一種松耦合的映射關系。
PaaS平臺的開發(fā)者門戶是面向開發(fā)者的，那么最終構建完成的微服務模塊發(fā)布到哪里去？因此一個完整的PaaS平臺構建，還需要構建一個集中的云門戶能力。對于云門戶至少應該包括傳統(tǒng)的4A能力，特別是針對所有微服務模塊的系統(tǒng)管理，權限管理能力，面向微服務模塊的統(tǒng)一認證和單點登錄能力。一個微服務模塊里面的菜單和功能注冊能力等，這些都應該是云門戶統(tǒng)一完成。也就是說微服務模塊完全只需要關注業(yè)務功能和業(yè)務邏輯的實現(xiàn)，在實現(xiàn)完成后統(tǒng)一在云門戶進行相關用戶，權限，流程等的配置。
4A+流程引擎模塊是一個厚PaaS平臺最集成的技術平臺模塊，需要提前規(guī)劃和建設好。按道理主數(shù)據(jù)模塊也是最基礎的模塊，也需要在整體應用構建的時候單獨拿出來進行規(guī)劃和建設。
每一個微服務模塊的開發(fā)，最好是統(tǒng)一采用標準的微服務開發(fā)框架，以方便進行統(tǒng)一，因此PaaS平臺需要提供相應的開發(fā)框架和開發(fā)環(huán)境能力。微服務模塊開發(fā)商只需要基于開發(fā)框架來實現(xiàn)業(yè)務功能。
一個微服務模塊的開發(fā)涉及到開發(fā)環(huán)境和集成環(huán)境，但是一個微服務模塊要能夠完整的跑起來往往涉及到消費和訂購基礎平臺，其它微服務模塊的服務接口能力。那么在這種場景下有兩個思路，一個思路就是即使在開發(fā)環(huán)境下也需要進行接口服務消費和訂購，否則模塊無法成功運行。其次就是在開發(fā)框架和環(huán)境中，實現(xiàn)一個能下沉到本地的SDK服務代理SDK包，微服務模塊在實現(xiàn)的時候只需要方便本地SDK包接口方法即可。在SDK包中我們還可以設計本地化的服務接口實現(xiàn)模擬，這樣減少在開發(fā)環(huán)境和開發(fā)階段的集成和耦合。
一個微服務模塊要跑起來，必定會涉及到服務消費和訂購，因此在服務全生命周期管理里面，首先要實現(xiàn)的就是服務的訂購，只有訂購了服務才能夠在微服務模塊進行折現(xiàn)服務的消費。而各個微服務模塊提供的接口服務能力首先還是體現(xiàn)在服務總線上，或者說輕量的微服務網(wǎng)關上面。也就是說一個微服務模塊開發(fā)，一方面是需要將自己提供的接口服務注冊到微服務網(wǎng)關，一方面又需要去訂購其它微服務模塊提供的服務接口。
即基礎技術平臺（流程引擎，技術服務能力），云門戶應用（含4A），微服務網(wǎng)關，PaaS管理門戶等，這些功能組件都必須提前部署和準備好，這些是后續(xù)微服務模塊依托的重要基礎能力。
PaaS層究竟應該提供哪些技術服務能力，最基本的仍然是數(shù)據(jù)庫服務（各類結構化數(shù)據(jù)庫和非結構化數(shù)據(jù)），中間件（應用中間件，消息中間件），緩存，負載均衡，文件存儲，任務，通知等，這些都是PaaS平臺應該提供的基礎技術服務能力。
在PaaS平臺化或容器化后，并不代表就只需要監(jiān)控Docker容器了，對于想要的虛擬機，各種計算和存儲資源往往也需要進行監(jiān)控。對于IaaS層的監(jiān)控當然也可以在獨立的IaaS平臺里面來完成，但是當我們在進行中間件監(jiān)控發(fā)現(xiàn)的問題的時候，能夠快速的定位到具體的邏輯資源或物理資源上。
比較理想化的狀態(tài)在前面文章也談到過，即登錄到PaaS平臺注冊一個招投標模塊應用，填寫相應注冊信息，同時對相關基礎接口服務進行訂購，然后下載開發(fā)框架進行功能的開發(fā)，對訂購的服務進行消費，完成微服務模塊的開發(fā)和構建，構建完成的部署包直接進行自動化部署，在測試通過后可以自動發(fā)布到云門戶環(huán)境，形成一個新的微服務模塊能力，同時在云門戶環(huán)境中進一步進行用戶，權限和菜單等的配置功能。
要實現(xiàn)和DevOps和持續(xù)集成的結合，必須能夠和類似GitLab，SVN等源代碼管理工具進行集成，同時通過類似Jekins來實現(xiàn)整體的持續(xù)集成過程，包括自動下載和更新代碼庫，自動運行Maven構建腳本進行構建，同時自動將構建完成的內容進行鏡像制作等。
鏡像 = 部署包+中間件容器+配置信息
一個鏡像你可以理解成就是一個可以完整獨立運行的小應用服務器。同時鏡像可以很靈活的實現(xiàn)復制，遷移，卸載和銷毀等能力。鏡像可以構建在虛擬機里面，也可以直接構建在物理服務器上。所有的鏡像都應該在鏡像倉庫鏡像管理，包括不同的版本。在資源調度的時候能夠很方便的從鏡像倉庫獲取鏡像快速的進行部署和調度。
在容器化PaaS下，部署是基于鏡像的，因此需要提前進行鏡像的設計。對于部署需要考慮的就是具體的部署策略和部署規(guī)則，包括實例數(shù)的最大和最小值分配，資源的動態(tài)調度規(guī)則等。在部署和發(fā)布的時候往往還需要支持灰度發(fā)布能力，這個在前面已經(jīng)有專門一篇文章在說明。
由于微服務模塊的部署已經(jīng)由PaaS平臺進行了應用托管和自動部署，而且對于Docker容器實例的分配也是相對靈活動態(tài)變化的。在這種場景下面就需要強調的應用日志采集和日志分析查看能力，這個是PaaS管控平臺必須提供的關鍵能力。舉例來說一個微服務模塊部署下去后，開發(fā)商不用關心底層的虛擬機和容器，而是在管控平臺的日志管理功能就能夠看到所有的中間件日志，應用日志等，方面進行問題分析和診斷。
也就是說PaaS平臺不僅僅提供應用模塊的健康監(jiān)控和管理，更加重要的是可以對應用的構建日志、部署日志、運行日志進行查詢，提供平臺上各系統(tǒng)的日志采集、查詢、分析工具。如果日志管理能力沒有跟上，那么后續(xù)微服務模塊的應用性能分析，應用監(jiān)控和故障處理將非常麻煩。
第三十四屆CIO班招生
北達軟EXIN網(wǎng)絡空間與IT安全基礎認證培訓
北達軟EXIN DevOps Professional認證培訓
責編：yangjun
免責聲明：本網(wǎng)站（http://www.www.gypb.net/）內容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
本網(wǎng)站刊載的所有內容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權歸原作者所有。任何單位或個人認為本網(wǎng)站中的內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，請及時通知本站，予以刪除。
搶沙發(fā)
