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