雲時代的.NET

 

編程語言從最初的0101機器碼到彙編語言再到面向對象的編程，不斷的發展，整個發展趨勢呈現高內聚、低耦合、可重用、可理解的特色。最先編程是用機器碼，人的大腦不像電腦，沒法處理0101；後來彙編語言仍是太費解，又出現了高級語言；而後由於咱們須要更加接近人類語言的方式描述問題，開始出現結構化編程或者模塊化編程的方式；但咱們要面對的問題仍是太複雜，因此就須要把他切割成小問題，即模塊化；模塊化出現以後，咱們又開始追求高內聚低耦合，因人腦仍然沒有辦法思考太多的模塊之間錯綜複雜的關係，因此須要高內聚低耦合，分層次的看待這些問題；但就算把這些功能都充分的去模塊化、高內聚低耦合，發現數據流仍是太複雜了，因此須要把數據也給高內聚低耦合，這個時候咱們開始去作面向對象的編程，當面向一個對象的時候編程就會比較高效。面向對象就是幫助咱們把數據對數據的操做分裝到模塊裏面，同時提供新的思考問題的方式，這樣子咱們原本只是比較簡單的大腦，竟然一會兒就能夠駕馭很是複雜的業務邏輯，作很龐大的軟件系統。

目前咱們發展出了23種設計模式，發展出CS、BS、MVC、MVP各類各樣神奇的架構模式以後，開始用這些概念「吵架」，或者作成面試題。整個發展的路線很明顯的趨勢是：不斷地追求更好的高內聚低耦合。相信可預見的將來仍然會繼續去尋找更好的一個高內聚低耦合的編程模式，咱們老是在追求更好的可重用性，儘可能地減小重複的工做。近幾年你們都在討論的微服務，微服務面對系統的時候，能不能用不少重複自治的子系統來完成。這些子系統應該能夠獨立於大系統獨立存在，每個子系統應該能夠管理好本身、保證本身是健壯的、可處理好異常狀況、面對壓力時候擴容負載均衡、沒有壓力時應該縮容。同時子系統無需擔憂被用，被越多的使用方使用，越說明該子系統有很好的可重用性，使用量越大越說明可能會產生規模效應，那就可用更低的平均成原本提供更好的服務。

討論微服務時，以前咱們僅僅是在討論一個系統怎麼被拆成幾個微服務，而後再用新形式來作新的系統。但這樣作與之前作的模塊化編程毫無區別。在雲時代基於微服務的設計理念開發軟件，首先要考慮的是有沒有一個現成優秀的雲服務能夠做爲一個系統須要的微服務，直接可用，好比圖片上傳、下載、裁剪、縮放等功能；若是沒有，那系統須要的服務，把它開發出來有沒有可能變成一個通用的服務，而後開放出去，這樣的話除了有可能去交付系統以外，還可能經過售賣個人微服務獲利。

軟件開發歷史上走過告終構化、面向對象，還有各類各樣的開發模式，這些全部的發展模式共同的發展方向是愈來愈高的高內聚低耦合，愈來愈好的可重用性，愈來愈容易被咱們的大腦理解。在雲時代，微服務是符合這三個大方向的全新軟件開發模式。

雲時代的雲服務公司，它們的核心業務和麪臨的問題就是今天這些純粹的技術問題，除了要可以解決並封裝成服務，還須要不斷的下降成本和優化效率，而在雲上的下降成本和優化效率這是真正意義上的技術價值的直接體現。亞瑪遜可以連續 降價來阻止競爭對手進入，正是技術綜合實力的體現，將來必然只有少數雲服務公司可以把提供服務的成本控制在自由市場競爭的價格之下。

雲時代咱們須要採用新平臺來革新咱們的軟件開發模式，做爲一個走過16年曆史的.NET, 在2014年順應時代要求自我刷新，推出的開源跨平臺的.NET Core, 就是爲雲原生應用的開發而準備的平臺，.NET Core相較於他的哥哥.NET的優點也正是咱們很容易的使用C# 語言去構建高內聚低耦合的系統。藉助於K8S，service fabric, 咱們很容易構建一個.NET Core的服務。最近結合.NET Core和k8s 容器服務在騰訊雲上製做了一個教程 《.NET 微服務實戰 — 微信公衆號開發（ https://cloud.tencent.com/developer/edu/major-100017）》，教程裏例子-公衆號開發雖然簡單，我只是使用這個簡單例子來闡述一個簡單的問題，雲時代的.NET 是怎麼樣的，咱們要怎麼樣使用.NET Core。