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

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

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

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

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

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

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

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

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

Alt pic

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后，PaaS可能是一套開發(fā)、測(cè)試、運(yùn)維的規(guī)范和流程的實(shí)戰(zhàn)總結(jié)，也可能是系統(tǒng)化的工具組合，但業(yè)務(wù)和技術(shù)是不斷變化的，沒有那個(gè)理論和工具能一勞永逸地回答和解決所有問題，只有最好，只有適合，所以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)易 云計(jì)算基礎(chǔ)服務(wù) 深度整合了 IaaS 、 PaaS 及容器技術(shù)，提供彈性計(jì)算、 DevOps 工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決 IT 、架構(gòu)及運(yùn)維等問題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計(jì)算平臺(tái)， 點(diǎn)擊可免費(fèi)試用 。

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