PaaS是Platform-as-a-Service的縮寫,意思是平臺即服務。 把服務器平臺做爲一種服務提供的商業模式。經過網絡進行程序提供的服務稱之爲SaaS(Software as a Service),而云計算時代相應的服務器平臺或者開發環境做爲服務進行提供就成爲了PaaS(Platform as a Service)。所謂PaaS其實是指將軟件研發的平臺(計世資訊定義爲業務基礎平臺)做爲一種服務,以SaaS的模式提交給用戶。所以,PaaS也是SaaS模式的一種應用。可是,PaaS的出現能夠加快SaaS的發展,尤爲是加快SaaS應用的開發速度。html
IaaS(Infrastructure as a Service),即基礎設施即服務。緩存
雲的特色是資源池化,甚至爲每一個用戶開闢他本身獨有的應用資源空間,而與其餘應用隔離起來。咱們
稱之爲「多租戶機制」,好比k8s的namespace就是實現了這種隔離機制.
如何實現哪?
1)對於Iaas,VM是資源隔離的很是好的手段,可是比較重。
2)LXC實現了OS級別的資源隔離,並演化成相似Docker這種隔離手段。可是依然是本地隔離手段。
3)須要結合1-2的本地級隔離手段,在Paas上層的資源分配機制上進行處理,資源分配時將各個資源
匯聚成一個隔離的組並掛接或者註冊到一個App的「名下」,這些都須要配置和元數據管理的支持。
之後再分配資源時,其餘App將不會得到當前App的資源,而且當前資源若是崩潰,也不會影響到
其餘應用。
4)網絡也能夠進行隔離,好比Vxlan,或者劃分專有網絡:計算網絡、存儲網絡、管理網絡等等
安全
將監控集羣狀態的心跳與集羣命令下發合併,優化通訊線路的負載。服務器
1.部署時涉及編排的問題,也就是服務應該以何種狀態部署哪個容器或者節點上,以及與其餘節點的關係
策略:相親性和反相親性。
2.部署時還涉及版本管理、配置管理、持續發佈和持續集成的問題,用於更好的走完生產的最後一千米。
可是在開發應用期間是建議頻繁地在測試環境部署驗證的,能夠儘快發現問題並演練部署策略和程序微信
1.總體由部分組成,部分的效能最大化就是總體效能的最大化的重要因素之一,總體效能還取決於各個組件的整合和協做方式的設計以及實現。首先實現本地合理的治理,是必須實現的事情。
2.RPC的效能、服務器線程以及IO的處理方式、埋點的透明化、本地監控、本地緩存、本地調用調度(節點管理器),本地升級策略等等都是要關注的點。
3.生命週期管理:節點管理器必須實現對服務實例的生命週期管理,並與集羣管理器緊密結合,在節點服務失敗或者崩潰時能夠試圖從新恢復和拉起服務進程或者通知上層集羣管理器從新調度。
網絡
1.以上的內容,說明了Paas的三個核心內容:開發設施自動化、運維自動化和運行時環境自動化。
2.可是這樣的狀況直接致使了遺留系統遷移的困難,由於老時代的系統每每很「重」,一開始就被鎖定在厚重的鎧甲中,另一個更加讓人爲難的就是釋放鎧甲必須修改應用代碼,這就涉及業務、功能重構! 這也是不少企業實施Paas很艱難的緣由!
3.具體的一些狀況:
A:系統服務之間使用獨立密碼庫受權通訊,難以使得自動化手段開通策略,實現自動擴容和伸縮。
B:老應用代碼依賴於應用服務器的Api,好比很老的系統使用EJB架構。使得適應新的Paas變得很是困難!
C:上Paas的動因也在於老系統面臨的環境從內部走向外部了,可是以前架構師設計系統時是按由裏往外的思路進行的,好比重點放在交易模塊上(由於此時線下活動佔主流),由於業務的發展,對系統的要求愈來愈高,要適應互聯網環境的要求,好比互聯網上查詢的量要遠遠大於交易的量,正好和原來的思路相反,是從外向裏的,這形成應用架構的極大不一樣,那麼就要求調整到分而治之的架構,那麼必然要求要進行調整和重構。
D:….......
那麼就沒有很好的辦法儘可能減小這些麻煩嗎?由於麻煩意味着風險和成本架構
1.總的方向就是向自動化、自省化、彈性化等努力。
2.咱們能夠經過回答如下的問題來決定如何調整您的系統:
A:本地應用不要依賴於本地的存儲來持久化數據(能夠臨時性的,可是給系統帶來風險),日誌變成流匯聚到分佈式日誌系統中,若是非要使用存儲,請使用相似HDFS來保存,您的系統是否依賴於本地存儲哪?
B:若是應用上傳文件,那麼這些文件應該如何存儲?請參考問題一。
C:集羣中多實例的配置文件是否徹底與底層OS解耦,配置文件是否不依賴於主機名和Ip?(能夠採用環境變量來解決)
D:應用是否存在須要很長時間處理的任務類型?(儘可能異步化的方式解決)
E:集羣中實例是否採用了獨立安全受權的方式組建?(須要拆除)
F:集羣中是否使用了硬件負載均衡設備?(須要撤除)
G:須要把服務無狀態化,您的App到底有多少部分須要依賴狀態?
H:您若是拆分業務系統,是按業務視角仍是用戶視角?(建議採用業務視角,由於熱點根本沒法預測)
I:業務拆分的原則是:識別基礎核心業務能力、業務核心能力、上層業務能力等負載均衡
在分佈式、雲等基礎設施支持下,從SOA演變而來的、具有明確的事務上下邊界的、鬆散耦合的、
能夠並行開發、簡單開發、簡單或自動運維的、相互協做造成有機總體併爲外部應用提供自省治理的
、不間斷的、高性能的服務系統。運維
前面提到互聯網的分而治之的策略,大規模的分佈式服務化系統在穩健的服務治理、彈性拓展、容災
以及開發週期能力支持下變得可管理、開跟蹤、高性能、高生命力。服務化的基礎是基礎設施的穩定力!
只要有一個堅如磐石的基礎設施,服務化就是很是可行的決策!異步
1.在介紹核心實現的部分中,提到配置必須先行的道理,就是要保證內環境和外環境的一致性。
2.Docker雖然能夠保證內部小環境的一致性,諸如CoreOS之類能夠保證OS級別的版本一致性,可是Paas
因爲是分佈式系統,它的各個組成組件也須要一致性保證,不然很難保證服務質量和延續性。
能夠採用冗餘服務+滾動式升級的辦法解決這個難題。
最近一年來,看到Docker幾乎瀰漫在各類系統中了,可是Docker解決了App內部環境一致性、解決了傳統Paas彈性拓展和容災時效的問題\基準鏡像分發等等,可是從架構上看過去,
它自己並不能解決App生產的其餘大部分問題,因此當您僅僅關注Docker的話,那就失去了Paas的能力,K8s、Swarm、Mesos等解決了一部分自動化問題,可是還不完整,只是算是Mini Paas。
微服務是活在Tomcat或者Docker裏面並無本質區別,之因此業界喜歡採用Docker做爲微服務的設計期和運行時基礎,是由於它有着諸多好的有點,好比環境一致性能夠簡化配置管理、簡化Paas
生命週期管理的難度等等,可是本質來說,微服務和Docker並沒有強關係,只是Docker的諸多方便之處,更加適合而已,因此採用Docker的系統未必是微服務,微服務構建的系統也未必是Docker構成。
經濟的發展、業務的發展所致使工做量的增長將促進PaaS獲得採用。
• IaaS提供商將往堆棧的上層移動,涵蓋PaaS IT,大量的中間件被雲化。
• 公共PaaS將贏得中小企業市場,由於它提供了開箱即用的基礎設施。
• 公共服務將把大企業市場讓給私有PaaS。
• 開源PaaS平臺將蓬勃發展,造成助推的做用。
• 開源PaaS平臺將經過流行的Linux發行版來提供,進一步簡化Paas的管理複雜度。
• 專有的PaaS將開始如同開源產品,也體現出業界標準化的意願。
• PaaS兼容性?更像是PaaS衝突性,因爲各個廠家爲了在競爭中取勝,也會更多的在本身的特殊性上下功夫,形成標準的不統一的局面,可是在市場的驅動力下,標準早晚會統一塊兒來。
• Paas變成一種生產互聯網產品的工廠,逐漸成爲標配,並融合在平常的基礎設施中。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
但願對您軟件項目開發,運維管理,系統架構與研發管理體系, 信息安全等有幫助。 其它您可能感興趣的文章:
雲計算參考架構幾例
微服務與Docker介紹
互聯網直播平臺架構案例一
高可用架構案例一
某互聯網公司廣告平臺技術架構
某大型電商雲平臺實踐
雲計算參考架構幾例
移動應用App測試與質量管理一
全面的軟件測試
著名ERP廠商的SSO單點登陸解決方案介紹一
軟件項目風險管理介紹
企業項目化管理介紹
智能企業與信息化之一
由企業家基本素質想到的
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
餐飲連鎖公司IT信息化解決方案一
若有想了解更多軟件研發 , 系統 IT集成 , 企業信息化,項目管理,企業管理 等資訊,請關注個人微信訂閱號:
做者:Petter Liu
出處:http://www.cnblogs.com/wintersun/
本文版權歸做者和博客園共有,歡迎轉載,但未經做者贊成必須保留此段聲明,且在文章頁面明顯位置給出原文鏈接,不然保留追究法律責任的權利。
該文章也同時發佈在個人獨立博客中-Petter Liu Blog。