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