網易杭州研究院·堯飄海

本文作于2015年2月

接前文：PaaS服務之路漫談（二）

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架構的應用，我們的自動部署平臺系統能較好的擔當這類角色，但是對于MSA服務架構的項目，自動部署平臺系統盡管也能部署，但是也會遇到上面提到部署問題，比如：主機數量爆炸式的增長帶來的管理成本，對資源的合理使用等。如何解決這些問題，需要大家一起努力來解決，特別是如果和GOOGLE一樣每周需要20億個服務部署的時候，我們對應的服務能跟上業務的需求不？我們的PaaS的服務能否很好的面對這些挑戰？作好準備了嗎？

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

最后，PaaS可能是一套開發、測試、運維的規范和流程的實戰總結，也可能是系統化的工具組合，但業務和技術是不斷變化的，沒有哪個理論和工具能一勞永逸地回答和解決所有問題，只有最好，只有適合，所以PaaS也不是銀彈。

期待大家提供高見建設我們的PaaS服務之路！

「

往期回顧

」

﹀

﹀

﹀

PaaS服務之路漫談（二）

PaaS服務之路漫談（一）

網易云信∣真正穩定的IM云服務

ID：neteaseim ?長按識別，關注精彩

總結

以上是生活随笔為你收集整理的PaaS服务之路漫谈（三）：MSA分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。