文章出處

前言

前幾天在博客園看到有園友在分享關于微軟的一個微服務架構的示例程序,想必大家都已經知道了,那就是eShopOnContainers

我們先不看項目的后綴名稱 OnXXX ,因為除了 OnContainers 還有 OnAzure,OnWeb,OnKubernetes 以及 OnServiceFabric。

我們就還是來先說說 eShop 這個項目吧,eShop 是 ASP.NET Core 發布之后微軟新開源出來的一個示例項目,想必大家之前也都知道微軟放出來的關于 Web 的示例項目還有 PetShop, Music Store 這兩個項目。關于這兩個項目我們就不做過多的介紹了,但是關于這兩個項目的架構風格我們不得不提起。

PetShop:WebFrom 的示例程序。典型的三層架構風格的應用程序。

MusicStore: 針對于 MVC3-5 框架和 EF 的一個示例程序。無明顯架構風格。

eShop: 針對于 ASP.NET Core 的示例程序。它是一個 Rest 架構風格的應用程序。

我們從微軟放出來的這些示例程序中也許可以看出些許東西,那就是近些年來關于架構風格的演變,或者叫微軟架構風格的演變,在這里我不打算討論關于軟件架構更加深層次的一些這種東西,我們只從我們能夠理解的東西看起。

微軟架構風格

我不知道有沒有人看過這本書,目前已經絕版了,它是早年間關于微軟架構風格的一本指南書,里面描述了微軟體系的架構風格的一些匯總。

這本書中列出來了以下這些架構風格:

  • Client/Server Architectural Style
  • Component-Based Architectural Style
  • Domain Driven Design Architectural Style
  • Layered Architectural Style
  • Message-bus Architectural Style
  • N-Tier / 3-Tier Architectural Style
  • Object-Oriented Architectural Style
  • Service-Oriented Architectural Style

我們可以看到微軟所開源出來的這些示例程序其實都是在遵循這些架構風格中的某一種或者是多種。 PetShop 屬于 N-Trie ,Music Store 屬于 Layered,eShop 屬于 Service-Oriented。
當然在 eShop 中微軟不但使用了 Service-Oriented ,其中還包括 Domain Driver Design(DDD), Message-bus 也都應用到了示例程序中。

由此,我們可以看出,在現代的應用程序架構風格中,已經不是某一種架構風格可以獨自獨領風騷了,它一定是多種架構風格的混合體,互相補充來構建更加強大的應用程序解決方案。

下面進入到我們本篇博客的主題微服務。不,應該是 ASP.NET Core 中的微服務,有同學可能會說了,微服務是一種架構風格,它并不和某一種語言相關,也不是只有.NET 中才有微服務。在這里我想說的是我不想去討論大眾眼中的微服務,因為太多人去說這些東西了,不就你打開 InfoQ 或者 cnBeta 這些網站,滿屏的都是微服務的東西。 所以你可以說我的微服務叫 Savorboard 式微服務。

既然要說 ASP.NET Core 中的微服務,那就必須又要說到 eShop 這個項目了,之前沒有給大家分享關于 eShop 這個項目的一些信息其實是有原因的,因為這個項目有很多東西它沒有實現完,或者是叫它還是一個半成品,給大家分享的話大家又運行不起來,所以就一直在等一個合適的時間來做。

ASP.NET Core 微服務

ASP.NET Core 其實是一個非常適合做微服務的一個 Web 框架,它足夠的輕量級并且擁有超高的性能。并且對于 Rest 這些風格的接口支持的非常的友好。更多好處我其實不太愿意去說,因為只有你自己去體會才會知道。還不如來點實在的,去教你們怎么在 ASP.NET Core 中構建一個或者叫一組微服務集群。在我看來,有時候講那么多理論也都是扯淡的。那就廢話不多說,開始吧。

在開始之前還是要說一句,你的架構一定要符合你的業務和需求,不要為了架構而架構。舉個例子,你的網站每天的訪問量就那么幾百號人,以后也不會大量的增加,你又是分布式又是大數據又是docker集群的這不沒事給自己找事干么。切記。

第一步,業務拆分。

業務拆分其實有時候是需要經驗積累的,有時候不僅僅是需要你有軟件架構經驗,還需要你有行業知識的經驗。這時候你的業務拆分的才足夠合理,不會隨著時間的推移導致你的微服務變“大”。

如果你對 DDD 中領域建模這種軟件建模方式在行的話可能會幫助你解決大量的潛在問題,如果你不會也沒關系,因為你可以去學呀~ 2333

第二步,建模。

在微服務架構中,建模仍然是重要的一步,因為你使用的是 EF Code First , 建模質量的好壞肯定是和你以后的代碼質量掛鉤了。如果你不使用 EF,那我們就不能愉快的做朋友了。

給大家個小提示,如果你的項目中全是增刪改查,沒有什么業務算法或者邏輯可言的話,就讓你的模型盡量的符合你的界面上的顯示字段,這樣可以最大化的提升開發效率。

第三步,寫代碼。

這個時候我希望你拋棄掉三層架構這種架構風格的設計,不是說那種不好,而是有更加便捷的方式了,你需要知道,你寫的每一個 Action 都應該是盡量的簡單,再去調用 BLL 層繞一大圈子就為了一個增刪改查純粹是給自己找活干,那樣并沒有提高項目的可維護度。

前段時間在 QQ 群聽學姐說過這么一句話,就是佛家的人生三重境界之說, 即:“看山是山, 看水是水; 看山不是山, 看水不是水; 看山還是山, 看水還是水。”

這一句話對于軟件架構的設計過程中同樣適用,在最初的時候,我們對于軟件程序不懂就按照官方給的示例程序來進行設計,即看山是山;隨著我們的知識,見解,經驗的積累我們有了自己的一些看法理解,出了自己的各種框架,即看山不是山;隨著時間的推移,我們已經悟到了其中的精髓,又回到了官方示例,大道至簡,即看山還是山。

(未完待續)


文章列表


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()