.Net Core微服务系列--理论篇
微服務的由來
微服務最早由Martin Fowler與James Lewis于2014年共同提出來的，但是微服務也不是一個全新的概念，它是由一系列在實踐中獲得成功并流行起來的概念中總結出來的一種模式，一種概念。而這一系列的概念大體上有這些:
領域驅動設計(DDD),持續交付，按需虛擬化，基礎設施自動化，小型的自治團隊，大型集群系統。
領域驅動設計(DDD)
DDD中我們關心了三個概念：領域建模，限界上下文，職責。這三個概念能很好的幫我們在微服務中按照業務分割出足夠小且高內聚低耦合的服務， 這也是Evans 在《領域驅動設計》一書中的比喻 “細胞之所以會存在，是因為細胞膜定義了什么在細胞內，什么在細胞外，并且確定了什么物質可以通過細胞膜”，我們每個服務都應該是有自己的職責或者可以說要滿足單一原則，要盡量保證內聚，并且要定義好與外部的交互。
持續交付
以往也包括現在的很多公司，生產環境的發布幾乎總是痛苦的事情，凌晨或者周末加班加點進行發布而且很可能一出問題就是全部回滾到上一個版本。但是現在， 因為實行了持續交付，團隊在一天內都可能在生產環境發布很多次。
持續集成，持續交付已經是現代軟件很重要的一個特性，對軟件產業產生了深遠的影響，當然這一特性也跟微服務緊密的結合在一起了。 當然單體架構在持續交付方面的問題太顯著了，但是微服務在這一方面確實優勢明顯。 微服務系統設計開始就是拆分為獨立自治的一些服務的集合，每次的持續交付我們只需要關注某個或者某些微服務的交付，從而在很大程度上減少了持續交付的工作量和風險。當然這就要保證各個服務之間的低耦合，在一個服務更改的時候不會帶消費方帶來影響。
按需虛擬化
系統在高并發的時候總是會遇到性能瓶頸，但是瓶頸一般不是存在在整個系統而是在某幾個特有的模塊比如說訂單，也不是說會一直存在瓶頸比如雙11。所以按需進行擴展是必要解決的問題。而對于微服務，我們借助虛擬化平臺，可以單獨的為某個服務按需創造機器并調整大小。
基礎設施自動化
這個其實跟按需虛擬化可以一起的，當我們需要水平擴展的時候，不可能為每次創造的機器進行一番部署，所以我們需要基礎設施的自動化來幫組我們完成方便快捷的擴展
小型的自治團隊
自治團隊，可以對應到自治服務。一個獨立的服務，可以語言自由，架構自由，集成自由，部署自由，我們只需要保證團隊做出來的東西滿足一定的條件就可以完全作為一個獨立的單元來進行開發管理維護。
什么是微服務
微服務就是一些協同工作的小而自治的服務。
小，專注于一件事
這個就是我們常常說的職責單一。
在我的職業生涯中，不乏會接手其他人的項目，每每總是會抱怨這個項目代碼量太多了，業務邏輯太分散，常常有牽一發而動全身的時候。而微服務則是把職責單一原則應用到服務上，根據業務來劃分限界上下文，進而劃分出不同的服務，這樣每個服務都只用關注到某個限界上下文中，從而很大程度上避免了代碼庫過大而難以維護的問題。
自治
這是微服務的優點，也一定程度上導致了微服務的復雜性。 自治，代表每個服務是獨立個體，所以我們可以自由的進行技術選型，服務之間通信用語言無關的api進行網絡通信。也是因為自治，所以我們要保證每個服務能夠獨立的升級部署而不會對消費者產生影響，避免一個問題出現導致整個系統功能不可用的情況。
協同
雖然我們是一系列不同的個體，但是我們還是一個整體，所以就需要我們各個服務之間有交互有通信，并且需要用某些技術來解決分布式帶來的新的問題。
微服務的好處
微服務是分布式的，所以具有分布式的所有好處，而且明確定義了界限上下文，也帶來了更多的好處。
技術異構
彈性好（處理服務不可用和功能降級）
擴展方便，成本低
簡化部署
與組織結構相匹配
可組合 易于重用完整的功能
對技術替代性的優化
微服務的缺點
當然微服務不是銀彈，不是整個軟件行業的終極解決方案，總是會存在不可忽視的缺點。同樣大部分的缺點也是分布式帶來的
性能（內存處理轉化為遠程調用）
可靠性 （遠程調用失敗的可能性）
最終一致性
操作的復雜性
因為還沒有在實際中使用過微服務，但是對分布式還是有不少實踐，所以結合一些書籍，寫下了這篇文章做了一下總結。
原文地址:??https://www.cnblogs.com/rstar/p/9055993.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.Net Core微服务系列--理论篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET Core实战项目之CMS 第一
- 下一篇： Asp.net Core Jenkins