PaaS服務之路漫談（三）

時間 2019-12-02

標籤 paas 服務之路漫談欄目雲服務简体版

原文原文鏈接

此文已由做者堯飄海受權網易雲社區發佈。
html

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。web

Monolithic架構在產品訪問量很大的狀況下，有可能常會致使整個產品迭代或升級過程不能按預期進行，或者上線風險的不肯定性致使上線時經常信心十足。那麼MSA（微服務架構）的模式能在很程度上避免Monolithic架構在規模服務應用下的一些缺陷。算法

微服務架構這個詞語出現的較早，其實公司的不少產品也是這麼開發和運行的，直到ThoughtWorks的專家討論過微服務後。Fred George，、James Lewis，Martin Fowler經過專門寫博文討論微服務，才使得微服務變成了下一個時髦術語，但實際上大量的論文也沒有劃分什麼纔是真正的微服務，但如今每一個公司都想使用一些微服務來完成產品的開發。數據庫

MSA（微服務架構）

在平常的工做中，咱們有可能會有機會接觸到運行不少早的大型的遺留系統，除了特別強大的牛人以外，通常的開發人員或者新人基本上沒法全面的理解系統內部的運行方式，若是又有新的功能要及時上線，那麼處理遺留代碼的風險就很高了，常常會出如今對業務理解不全面的狀況下修改了某處代碼而引入其餘關鍵的部分。日前有些業務團隊肯定就遇到了這樣的問題，基本經過微服務能較好的解決這個難題，可能按最新的框架模型編寫一些小的服務組合起來，完成業務流程，等因此的業務都可以覆蓋全面時，那麼老的系統基本上就能夠下線了。架構

微服務其實只是一種新的架構概念，沒有什麼新的東西，也沒有明確的範圍定義，只是經過將功能儘量的按需求分解到各個離散的服務中從而達到各服務間的解藕，甚至能夠簡單的當作一個個很是小的Monolithic架構組合。負載均衡

微服務是一種簡單的應用，每一個服務基本上只完成本身角色的任務，沒有額外的業務代碼，有些甚至一個算法實現均可能當作一個服務來發布，好比以前Pomelo遊戲框架的地圖的AOI服務，這些服務基本簡單到只能完成一個功能，很是的輕量級和容易理解，公司內的新的項目有些目前基本上採用這樣服務化的方式來實現的，只是將一些業務代碼簡單的包裝經過通訊層較好的完成服務調用。框架

這種架構的方式的實現方式以下：運維

相對於前文中的Monolithic架構模式中提到的應用軟件開發的非功能要求，這些微服務的架構有什麼區別呢？分佈式

沒錯，這種MSA架構實現方式與SOA的模式很是類似，有些人會認爲基本上同樣的，可是微服務仍是有必定的區別的，SOA的架構早期的採用ESB這種企業總線的方式來實現，裏面包括了不少業務規則，消息路由，不少是採用重型的中間件來實現的，總體對開發人員不是很透明，查問題的效率也不是很高。微服務更加輕量級，全部的操做可能直接經過消息傳遞的方式來實現，中間件只是消息的搬運工，不會對消息進行任務處理。微服務

採用這種架構模式的優點是：

輕量級每一個開發者都能容易理解；相關開發工具對小應用也也較好的支持，而無論相關的機器的配置；整個過程不管是編譯，部署過程都很輕量級，這將使用開發人員，測試人員和運維人員工做效率更加高效。
易升級每一個服務均可以獨立部署，只要輸入輸出一致，各服務能夠更新的完成運維。
易上手因爲代碼簡單，不管是新入職的員工仍是頂替的角色都能較好的如今業務邏輯，每一個組都能獨立工做，減小和其餘的組的溝通的開銷。
容錯性，每一個服務獨立部署，某一個服務的失敗不會影響總體的業務不可訪問，能大大提升用戶的SLA服務時間，提升用戶的體驗。
易擴展因爲每一個服務都有對應的資源需求，不多會引發資源競爭，好比各個服務能夠鏈接不一樣的數據庫來完成對數據庫的依賴。
易運維經過複製多份的方式來實現模向擴展，負載均衡完成請求路由。
易掉頭微服務能較好的隨時使用新技術，新的框架帶來的紅利，而不用受到技術債的影響。

固然，隨着系統服務的逐步細化和擴大，每一個服務單獨部署，微服務架構的一些問題也暴露出來了：

因爲每一個服務的單獨部署，按照日前雲計算的使用方式，每一個服務都申請一臺雲主機來部署，將形成大量的工做時間化在溝通和交流上，包括主機的申請，初始化和權限申請等，其次每一個產品要申請大量的雲主機來服務，數量將成指數級別增加，歷來進一步帶來運維管理等相關問題。
資源的使用方式，微服務採用雲主機部署的方式也將使用資源的利用不充分，形成不少的資源浪費，包括內存，磁盤等，之前只有運行一個JVM就能跑起來的服務，如今可能須要運行多個JVM才能完成。
關鍵性業務複雜，對於一些業務要求很高的場景，好比訂單支付之類的服務會引入分佈式事務的複雜操做，日前咱們公司也開發了TCC的分佈式事務來處理這類問題。
分佈式系統經過服務調用，至少增長了一層的開銷，固然這種開銷通常狀況下基本能夠忽略，服務端調用除了業務的邏輯以外要的開銷很是小；除此以外還須要明確瞭解本身的業務類型，這樣才能更好的根據業務類型部署運行不一樣類型的主機上。
測試困難開發人員在完成本身代碼開發後，因爲涉及到各個系統的業務，所以實現的不一樣的測試用例要跨不一樣的服務來編寫，同時因爲分佈式事務之類的操做，致使測試場景更加複雜，對於服務的測試須要測試人員編譯相關的測試接口和集成測試用例來完成，所以對測試人員的要求會更高。
部署複雜運維人員部署不一樣的類型的服務須要了解不一樣的部署方法，因爲服務的部署複雜，對應帶來的協調管理成本也會相應的增長，如何高效的實現服務部署的自動化就變得很是的嚴峻。經過DEVOPS技術來減小和防止因爲繁煩的配置致使事故。

經過二種架構方式的對比，採用何種架構方式來完成應用的部署對於技術負責人或架構師來講也是一個很是有挑戰性的難題，通常在項目的初期或業務上線DEADLINE的需求下，會採用前者架構來快速實現，在項目初期通常也不會遇到很是大的訪問量的應用的，同時細化，全分佈化服務化的架構也會致使開發速度變慢。而若是業務快速發展，項目的技術架構債也會更加劇，須要人員來完成服務化的架構改造來適用業務的發展。所以什麼時候採用架構模式需求根據項目的業務需求和實際的能力來決定，當其餘的系統不能很好的服務於項目或不能知足項目的生態需求時，這也是負責人或架構師的職責所在。

一樣，在項目開發，測試和上線時，不一樣的架構模式須要使用不一樣的部署工具來實現高效的自動部署，儘可能減小各人員的溝通和管理等成本，專業人員只要把注意力放在自身的業務範圍內，爲項目的上線實現工做自身的價值。對於Monolithic架構的應用，咱們的自動部署平臺系統(http://omad.hz.netease.com) 能較好的擔當這類角色，可是對於MSA服務架構的項目，自動部署平臺系統儘管也能部署，可是也會遇到上面提到部署問題，好比：主機數量爆炸式的增加帶來的管理成本，對資源的合理使用等。如何解決這些問題，須要你們一塊兒努力來解決，特別是若是和GOOGLE同樣每週須要20億個服務部署的時候，咱們對應的服務能跟上業務的需求不？咱們的PaaS的服務可否很好的面對這些挑戰？做好準備了嗎？

後續本文將繼續介紹其餘公司的服務化解決方案，包括ebay,Amazon，淘寶等國內外，隨後也將詳細介紹咱們的實現方案和具體作法，敬請期待。

其實，咱們的PaaS服務化之路剛剛開始；其實，咱們的PaaS服務化之路已經開始；

最後，PaaS多是一套開發、測試、運維的規範和流程的實戰總結，也多是系統化的工具組合，但業務和技術是不斷變化的，沒有那個理論和工具能一勞永逸地回答和解決全部問題，只有最好，只有適合，因此PaaS也不是銀彈。期待你們提供高見建設咱們的PaaS服務之路！

參考：