在Service Fabric上運(yùn)行微服務(wù)

Service Fabric框架對(duì)微軟而言是一大進(jìn)步。其核心部分是一個(gè)分布式系統(tǒng)平臺(tái)，用于構(gòu)建可擴(kuò)展的可靠應(yīng)用。在便于封裝可部署代碼的同時(shí)，還內(nèi)置了微服務(wù)最佳實(shí)踐案例。
　　本文將帶您最快地上手使用Service Fabric框架，并保證您會(huì)愛(ài)不釋手。但想要了解Service Fabric框架以及它的重大意義，就有必要了解現(xiàn)代軟件發(fā)展到今天，在采用Service Fabric框架前，前人們血與淚的歷史。
　　面向?qū)ο蟮狞S金時(shí)代
　　在引入面向?qū)ο蠛同F(xiàn)代的計(jì)算模式之后，計(jì)算機(jī)界發(fā)生了翻天覆地的變化。Visual Basic在1991年面世，真正揭開(kāi)了現(xiàn)代風(fēng)格軟件開(kāi)發(fā)的序幕，使得開(kāi)發(fā)人員可以專注于商業(yè)價(jià)值，而不用像之前那樣顧慮一大堆硬件特性的問(wèn)題。之后在這種開(kāi)發(fā)思路下，出現(xiàn)了后來(lái)的運(yùn)行庫(kù)，比如1995年的Java，2000年的.NET framework和C#。盡管在之后幾年中，Java和C#出現(xiàn)了些許變化，但采用的模式和實(shí)踐方式卻沒(méi)有太大變化。
　　這些實(shí)踐、模式以及運(yùn)行庫(kù)在進(jìn)化過(guò)程中都有如下共性：內(nèi)部構(gòu)架變得原來(lái)越抽象，然而使用門檻卻越來(lái)越低。終端開(kāi)發(fā)者無(wú)需操心細(xì)枝末節(jié)、重復(fù)任務(wù)和管道問(wèn)題，從而專注于傳達(dá)產(chǎn)品的業(yè)務(wù)價(jià)值。
　　敏捷的誕生
　　在整個(gè)計(jì)算機(jī)行業(yè)的代碼編譯出現(xiàn)模式和實(shí)踐范例的同時(shí)，我們卻忽視了改進(jìn)提煉圍繞著產(chǎn)品開(kāi)發(fā)與SDLC的商業(yè)進(jìn)程。
　　當(dāng)時(shí)大多數(shù)人認(rèn)為SDLC相關(guān)的模式（瀑布、大爆炸/一次性集成、螺旋等）過(guò)于死板受限，無(wú)法適應(yīng)開(kāi)發(fā)者新的快速任務(wù)執(zhí)行的能力。開(kāi)發(fā)者在功能構(gòu)建上的速度已經(jīng)超過(guò)了商業(yè)進(jìn)程的速度，他們將大多時(shí)間花在構(gòu)建需求文檔和不注重價(jià)值的產(chǎn)品上。
　　2001年在猶他州Snowbird舉行的會(huì)議上，有一批先驅(qū)者提出了關(guān)于SDLC思考方式的指導(dǎo)思想，也就是后人所稱的敏捷宣言（Agile Manifesto）。
　　agileSHERPA提出：
　　“相比于強(qiáng)調(diào)提前規(guī)劃和需求詳盡，本指導(dǎo)思想的重點(diǎn)在于：如何進(jìn)行持續(xù)規(guī)劃、團(tuán)隊(duì)授權(quán)、彼此協(xié)作、緊急設(shè)計(jì)、早期測(cè)試和經(jīng)常探究根本，最重要的是能在短期快速迭代中交付軟件?！?br /> 　　但在實(shí)際應(yīng)用中，各公司尤其是企業(yè)組織最初非常抵觸這種思考方式與抽象化商業(yè)進(jìn)程。
　　
　　而其他人迫切渴望采用這種思想，卻完全無(wú)法理解。
　　
　　最終敏捷獲得大家的共識(shí)?！?a href='http://ttokpm.com/v/tag/1722/' target='_blank' class='arckwlink_none'>網(wǎng)絡(luò)泡沫”崩潰前，各家公司都在追求敏捷，最終演變成了公司之間的軍備競(jìng)賽。市場(chǎng)上對(duì)于敏捷的需求激增，但資源不足使得人們更加關(guān)注產(chǎn)品的價(jià)值主張和快速迭代。
　　敏捷性思維的廣泛影響一改業(yè)內(nèi)產(chǎn)品產(chǎn)出緩慢（一到兩年一個(gè)產(chǎn)品）的情況，通過(guò)流線化作業(yè)，現(xiàn)在可以按季度或者每半年發(fā)布一次版本了。實(shí)際可用的代碼一般會(huì)在發(fā)布日期前交付使用，但在整個(gè)行業(yè)內(nèi)，開(kāi)發(fā)的速度與工程及商業(yè)進(jìn)程的發(fā)展仍有斷層。
　　DevOps
　　盡管在商業(yè)與開(kāi)發(fā)進(jìn)程中出現(xiàn)了前文說(shuō)的種種進(jìn)步，但軟件的交付流程本質(zhì)上仍是瀑布式的。一切按部就班，我們?nèi)杂屑径然蛟露劝l(fā)布。讓事情更為復(fù)雜的，則是開(kāi)發(fā)自由與商業(yè)敏捷導(dǎo)致面向服務(wù)開(kāi)發(fā)所占的比重增加。不同于之前的單一應(yīng)用部署，現(xiàn)在我們還有很多需求各異的小型應(yīng)用需要協(xié)調(diào)。
　　大部分協(xié)調(diào)需求都只是因?yàn)檐浖l(fā)布不夠頻繁：只要單體功能已經(jīng)完成，并且符合質(zhì)量和業(yè)務(wù)需求的審驗(yàn)，就應(yīng)當(dāng)能夠交付使用。
　　在2008年，工程師、企業(yè)領(lǐng)導(dǎo)和運(yùn)營(yíng)專家開(kāi)始推動(dòng)DevOps，人們渴望一種在整個(gè)軟件開(kāi)發(fā)周期中工程師和運(yùn)營(yíng)者更為協(xié)調(diào)，同時(shí)重視重復(fù)工作自動(dòng)化的環(huán)境。
　　點(diǎn)擊這里可以查看視頻：DevOps的歷史。
　　風(fēng)暴來(lái)襲
　　隨著公司、工程師和運(yùn)營(yíng)者日臻磨合，過(guò)去5-10年間有大量代碼快速出爐，質(zhì)量也大幅提高，遠(yuǎn)勝之前的30年。
　　現(xiàn)在大部分代碼開(kāi)始老化。八年前我們所使用的編程模式可能也很優(yōu)秀，但直到兩年前商業(yè)模式都還不夠好。或者開(kāi)始時(shí)想要使用敏捷，卻沒(méi)能堅(jiān)持最佳實(shí)踐的開(kāi)發(fā)標(biāo)準(zhǔn)。這方面有很多類似的情況，不過(guò)我們的底限是：所有資源無(wú)論是現(xiàn)代化的還是較早期的，都要能為企業(yè)提供商業(yè)價(jià)值，需要維護(hù)的內(nèi)容也要滿足這個(gè)要求。
　　許多公司開(kāi)始花費(fèi)大量精力進(jìn)行資源協(xié)調(diào)，努力均勻分切。假設(shè)公司有2到5個(gè)敏捷開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé)一個(gè)產(chǎn)品的不同部分，或者干脆就是不同的產(chǎn)品，就會(huì)有各種問(wèn)題：這些項(xiàng)目的著陸點(diǎn)在哪，硬件是哪個(gè)隊(duì)伍的？在最初設(shè)計(jì)不適用水平擴(kuò)展或容錯(cuò)性不佳的情況下，如何確保關(guān)鍵程序的高可用性？如果某臺(tái)機(jī)器宕機(jī)怎么辦？是要繼續(xù)手頭的工作，還是選擇損失掉一些信譽(yù)，還可能帶來(lái)負(fù)面的口碑？
　　讓服務(wù)器不再嬌貴，而要成為頂用的老黃牛
　　許多公司都對(duì)于基礎(chǔ)架構(gòu)的需求，都依賴內(nèi)部獨(dú)立的交付團(tuán)隊(duì)是否有意識(shí)，通常的表現(xiàn)就是：公司只針對(duì)特定的框架需求設(shè)置服務(wù)器，所用的部署實(shí)踐也是多年來(lái)逐漸構(gòu)建的。我們多用神靈、星球甚至颶風(fēng)的命來(lái)給硬件命名，將它們看作脆弱、唯一的雪花般寶貴。然后，某個(gè)公司的阿波羅服務(wù)器宕機(jī)了。
　　全公司都亂套了，一時(shí)間公司內(nèi)哀鴻遍野，大家都想拼命做些什么來(lái)解決問(wèn)題。最瘋狂的是：由于這臺(tái)服務(wù)器太過(guò)關(guān)鍵，所有人都向它致以最深切的哀悼，整個(gè)公司都在經(jīng)歷“悲傷的七個(gè)階段”。
　　之后他們啟用全新的硬件，比之前的更加龐大快速。幾個(gè)月之后，阿波羅服務(wù)器完全被遺忘了，就像沒(méi)存在過(guò)一樣。盡管大家都知道不久的將來(lái)還會(huì)有宙斯和阿瑞斯這樣更先進(jìn)的設(shè)備，但知道有這件事不代表已經(jīng)做好了準(zhǔn)備。
　　進(jìn)入封裝技術(shù)時(shí)代
　　
　　講到這里推薦大家去閱讀一篇由Zach Gardner撰寫(xiě)的博文《Docker： VMs， Code Migration， and SOA Solved》，介紹了封裝技術(shù)在Docker中應(yīng)用的一些注意事項(xiàng)，值得一讀。
　　坦率地說(shuō)，我本人是個(gè)微軟粉，但微軟在封裝技術(shù)領(lǐng)域有些落后于其它公司。在Docker發(fā)布了近三年之后，微軟才跟上趟。不僅如此，在微服務(wù)的問(wèn)題上 .NET社群在工具和創(chuàng)新方式無(wú)法與Java社群中的Netflix和Amazon公司的成果比肩。
　　但我仍然喜歡微軟：盡管他們?cè)谶@點(diǎn)上落后于他人，但他們發(fā)行的產(chǎn)品更容易上手，而且售后與支持服務(wù)更好，Service Fabric也不例外。
　　Service Fabric框架不僅能讓開(kāi)發(fā)者封裝可部署代碼，另外還內(nèi)置了微服務(wù)的最佳實(shí)踐案例。想要查看更多信息，請(qǐng)移步。
　　Service Fabric框架吸引人的原因不止于此。隨著微軟最近幾年提出的透明和公開(kāi)原則，Service Fabric框架沒(méi)有被約束在Azure上，甚至突破了Windows的限制！沒(méi)錯(cuò)，它不僅可以在本地?cái)?shù)據(jù)庫(kù)的Linux上運(yùn)行，還可以在AWS上運(yùn)行！更重磅的消息：嵌入其中的微服務(wù)不必再使用.NET開(kāi)發(fā)，而是可以使用任何代碼，隨你喜歡——Java、C++或者Ruby。
　　我認(rèn)為：這才是人們需要的領(lǐng)先技術(shù)，是微軟的一大進(jìn)步。
　　演示開(kāi)始
　　有了前邊的長(zhǎng)篇大論，接下來(lái)進(jìn)入正題。演示過(guò)程十分簡(jiǎn)潔，但能讓你快速上手。
　　首先準(zhǔn)備好工作環(huán)境
　　完工之后，打開(kāi)Visual Studio（以管理員身份運(yùn)行），新建一個(gè)Service Fabric工程，命名為ServiceFabricDemo。
　　不要把它保存在根目錄里，因?yàn)橛行┮蕾噹?kù)的名字相當(dāng)冗長(zhǎng)，所以，默認(rèn)的文件夾名加上這個(gè)文件名，整個(gè)路徑名成可能會(huì)超出合法命名長(zhǎng)度。