摘要：期待大家提供高見建設(shè)我們的服務(wù)之路參考服務(wù)之路漫談一服務(wù)之路漫談二網(wǎng)易云計算基礎(chǔ)服務(wù)深度整合了及容器技術(shù)，提供彈性計算工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決架構(gòu)及運維等問題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計算平臺，點擊可免費試用。

此文已由作者堯飄海授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運營經(jīng)驗。

Monolithic架構(gòu)在產(chǎn)品訪問量很大的情況下，有可能常會導(dǎo)致整個產(chǎn)品迭代或升級過程不能按預(yù)期進行，或者上線風(fēng)險的不確定性導(dǎo)致上線時常常信心十足。那么MSA（微服務(wù)架構(gòu)）的模式能在很程度上避免Monolithic架構(gòu)在規(guī)模服務(wù)應(yīng)用下的一些缺陷。

微服務(wù)架構(gòu)這個詞語出現(xiàn)的較早，其實公司的很多產(chǎn)品也是這么開發(fā)和運行的，直到ThoughtWorks的專家討論過微服務(wù)后。Fred George，、James Lewis，Martin Fowler通過專門寫博文討論微服務(wù)，才使得微服務(wù)變成了下一個時髦術(shù)語，但實際上大量的論文也沒有劃分什么才是真正的微服務(wù)，但現(xiàn)在每個公司都想使用一些微服務(wù)來完成產(chǎn)品的開發(fā)。

MSA（微服務(wù)架構(gòu)）
在日常的工作中，我們有可能會有機會接觸到運行很多早的大型的遺留系統(tǒng)，除了特別強大的牛人之外，一般的開發(fā)人員或者新人基本上無法全面的理解系統(tǒng)內(nèi)部的運行方式，如果又有新的功能要及時上線 ，那么處理遺留代碼的風(fēng)險就很高了，經(jīng)常會出現(xiàn)在對業(yè)務(wù)理解不全面的情況下修改了某處代碼而引入其他關(guān)鍵的部分。日前有些業(yè)務(wù)團隊確定就遇到了這樣的問題，基本通過微服務(wù)能較好的解決這個難題，可能按最新的框架模型編寫一些小的服務(wù)組合起來，完成業(yè)務(wù)流程，等所以的業(yè)務(wù)都能夠覆蓋全面時，那么老的系統(tǒng)基本上就可以下線了。

微服務(wù)其實只是一種新的架構(gòu)概念，沒有什么新的東西，也沒有明確的范圍定義，只是通過將功能盡可能的按需求分解到各個離散的服務(wù)中從而達(dá)到各服務(wù)間的解藕，甚至可以簡單的看成一個個非常小的Monolithic架構(gòu)組合。

微服務(wù)是一種簡單的應(yīng)用，每個服務(wù)基本上只完成自己角色的任務(wù)，沒有額外的業(yè)務(wù)代碼，有些甚至一個算法實現(xiàn)都可能當(dāng)做一個服務(wù)來發(fā)布，比如之前Pomelo游戲框架的地圖的AOI服務(wù)，這些服務(wù)基本簡單到只能完成一個功能，非常的輕量級和容易理解，公司內(nèi)的新的項目有些目前基本上采用這樣服務(wù)化的方式來實現(xiàn)的，只是將一些業(yè)務(wù)代碼簡單的包裝通過通信層較好的完成服務(wù)調(diào)用。

這種架構(gòu)的方式的實現(xiàn)方式如下：

Alt pic

相對于前文中的Monolithic架構(gòu)模式中提到的應(yīng)用軟件開發(fā)的非功能要求，這些微服務(wù)的架構(gòu)有什么區(qū)別呢？

沒錯，這種MSA架構(gòu)實現(xiàn)方式與SOA的模式非常相似，有些人會認(rèn)為基本上一樣的，但是微服務(wù)還是有一定的區(qū)別的，SOA的架構(gòu)早期的采用ESB這種企業(yè)總線的方式來實現(xiàn)，里面包括了很多業(yè)務(wù)規(guī)則，消息路由，很多是采用重型的中間件來實現(xiàn)的，整體對開發(fā)人員不是很透明，查問題的效率也不是很高。微服務(wù)更加輕量級，所有的操作可能直接通過消息傳遞的方式來實現(xiàn)，中間件只是消息的搬運工，不會對消息進行任務(wù)處理。

采用這種架構(gòu)模式的優(yōu)勢是：

輕量級 每個開發(fā)者都能容易理解；相關(guān)開發(fā)工具對小應(yīng)用也也較好的支持，而不管相關(guān)的機器的配置；整個過程無論是編譯，部署過程都很輕量級，這將使用開發(fā)人員，測試人員和運維人員工作效率更加高效。

易升級 每個服務(wù)都可以獨立部署，只要輸入輸出一致，各服務(wù)可以更新的完成運維。

易上手 由于代碼簡單，無論是新入職的員工還是頂替的角色都能較好的現(xiàn)在業(yè)務(wù)邏輯，每個組都能獨立工作，減少和其他的組的溝通的開銷。

容錯性，每個服務(wù)獨立部署，某一個服務(wù)的失敗不會影響整體的業(yè)務(wù)不可訪問，能大大提高用戶的SLA服務(wù)時間，提高用戶的體驗。

易擴展 由于每個服務(wù)都有對應(yīng)的資源需求，很少會引起資源競爭，比如各個服務(wù)可以連接不同的數(shù)據(jù)庫來完成對數(shù)據(jù)庫的依賴。

易運維 通過復(fù)制多份的方式來實現(xiàn)模向擴展，負(fù)載均衡完成請求路由。

易掉頭 微服務(wù)能較好的隨時使用新技術(shù)，新的框架帶來的紅利，而不用受到技術(shù)債的影響。

當(dāng)然，隨著系統(tǒng)服務(wù)的逐步細(xì)化和擴大，每個服務(wù)多帶帶部署，微服務(wù)架構(gòu)的一些問題也暴露出來了：

由于每個服務(wù)的多帶帶部署，按照日前云計算的使用方式，每個服務(wù)都申請一臺云主機來部署，將造成大量的工作時間化在溝通和交流上，包括主機的申請，初始化和權(quán)限申請等，其次每個產(chǎn)品要申請大量的云主機來服務(wù)，數(shù)量將成指數(shù)級別增長，從來進一步帶來運維管理等相關(guān)問題。

資源的使用方式，微服務(wù)采用云主機部署的方式也將使用資源的利用不充分，造成很多的資源浪費，包括內(nèi)存，磁盤等，以前只有運行一個JVM就能跑起來的服務(wù)，現(xiàn)在可能需要運行多個JVM才能完成。

關(guān)鍵性業(yè)務(wù)復(fù)雜，對于一些業(yè)務(wù)要求很高的場景，比如訂單支付之類的服務(wù)會引入分布式事務(wù)的復(fù)雜操作，日前我們公司也開發(fā)了TCC的分布式事務(wù)來處理這類問題。

分布式系統(tǒng) 通過服務(wù)調(diào)用，至少增加了一層的開銷，當(dāng)然這種開銷一般情況下基本可以忽略，服務(wù)端調(diào)用除了業(yè)務(wù)的邏輯之外要的開銷非常?。怀酥膺€需要明確了解自己的業(yè)務(wù)類型，這樣才能更好的根據(jù)業(yè)務(wù)類型部署運行不同類型的主機上。

測試?yán)щy 開發(fā)人員在完成自己代碼開發(fā)后，由于涉及到各個系統(tǒng)的業(yè)務(wù)，因此實現(xiàn)的不同的測試用例要跨不同的服務(wù)來編寫，同時由于分布式事務(wù)之類的操作，導(dǎo)致測試場景更加復(fù)雜，對于服務(wù)的測試需要測試人員編譯相關(guān)的測試接口和集成測試用例來完成，因此對測試人員的要求會更高。

部署復(fù)雜 運維人員部署不同的類型的服務(wù)需要了解不同的部署方法，由于服務(wù)的部署復(fù)雜，對應(yīng)帶來的協(xié)調(diào)管理成本也會相應(yīng)的增加，如何高效的實現(xiàn)服務(wù)部署的自動化就變得非常的嚴(yán)峻。通過DEVOPS技術(shù)來減少和防止由于繁煩的配置導(dǎo)致事故。

通過二種架構(gòu)方式的對比，采用何種架構(gòu)方式來完成應(yīng)用的部署對于技術(shù)負(fù)責(zé)人或架構(gòu)師來說也是一個非常有挑戰(zhàn)性的難題，一般在項目的初期或業(yè)務(wù)上線DEADLINE的需求下，會采用前者架構(gòu)來快速實現(xiàn)，在項目初期一般也不會遇到非常大的訪問量的應(yīng)用的，同時細(xì)化，全分布化服務(wù)化的架構(gòu)也會導(dǎo)致開發(fā)速度變慢。而如果業(yè)務(wù)快速發(fā)展，項目的技術(shù)架構(gòu)債也會更加重，需要人員來完成服務(wù)化的架構(gòu)改造來適用業(yè)務(wù)的發(fā)展。因此何時采用架構(gòu)模式需求根據(jù)項目的業(yè)務(wù)需求和實際的能力來決定，當(dāng)其他的系統(tǒng)不能很好的服務(wù)于項目或不能滿足項目的生態(tài)需求時，這也是負(fù)責(zé)人或架構(gòu)師的職責(zé)所在。

同樣，在項目開發(fā)，測試和上線時，不同的架構(gòu)模式需要使用不同的部署工具來實現(xiàn)高效的自動部署，盡量減少各人員的溝通和管理等成本，專業(yè)人員只要把注意力放在自身的業(yè)務(wù)范圍內(nèi)，為項目的上線實現(xiàn)工作自身的價值。對于Monolithic架構(gòu)的應(yīng)用，我們的自動部署平臺系統(tǒng)(http://omad.hz.netease.com) 能較好的擔(dān)當(dāng)這類角色，但是對于MSA服務(wù)架構(gòu)的項目，自動部署平臺系統(tǒng)盡管也能部署，但是也會遇到上面提到部署問題，比如：主機數(shù)量爆炸式的增長帶來的管理成本，對資源的合理使用等。如何解決這些問題，需要大家一起努力來解決，特別是如果和GOOGLE一樣每周需要20億個服務(wù)部署的時候，我們對應(yīng)的服務(wù)能跟上業(yè)務(wù)的需求不？我們的PaaS的服務(wù)能否很好的面對這些挑戰(zhàn)？作好準(zhǔn)備了嗎？

后續(xù)本文將繼續(xù)介紹其他公司的服務(wù)化解決方案，包括ebay,Amazon，淘寶等國內(nèi)外，隨后也將詳細(xì)介紹我們的實現(xiàn)方案和具體做法，敬請期待。

其實，我們的PaaS服務(wù)化之路剛剛開始； 其實，我們的PaaS服務(wù)化之路已經(jīng)開始；

最后，PaaS可能是一套開發(fā)、測試、運維的規(guī)范和流程的實戰(zhàn)總結(jié)，也可能是系統(tǒng)化的工具組合，但業(yè)務(wù)和技術(shù)是不斷變化的，沒有那個理論和工具能一勞永逸地回答和解決所有問題，只有最好，只有適合，所以PaaS也不是銀彈。期待大家提供高見建設(shè)我們的PaaS服務(wù)之路！

參考：

http://flux7.com/devops-for-s...

http://www.oschina.net/transl...

http://www.infoq.com/cn/news/...

http://microservices.io/patte...

http://www.csdn.net/article/2...

PaaS服務(wù)之路漫談（一）

PaaS服務(wù)之路漫談（二）

網(wǎng)易 云計算基礎(chǔ)服務(wù) 深度整合了 IaaS 、 PaaS 及容器技術(shù)，提供彈性計算、 DevOps 工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決 IT 、架構(gòu)及運維等問題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計算平臺， 點擊可免費試用 。

文章來源： 網(wǎng)易云社區(qū)