編程語言從最初的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。歡迎閱讀原文學習。

原文地址: https://cloud.tencent.com/developer/edu/major-100017

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的云时代的.NET的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。