前言 前幾天在博客園看到有園友在分享關於微軟的一個微服務架構的示常式序，想必大家都已經知道了，那就是 "eShopOnContainers" 。 我們先不看項目的尾碼名稱 OnXXX ，因為除了 OnContainers 還有 OnAzure，OnWeb，OnKubernetes 以及 OnServ ...
前言
前幾天在博客園看到有園友在分享關於微軟的一個微服務架構的示常式序，想必大家都已經知道了，那就是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 群聽學姐說過這麼一句話，就是佛家的人生三重境界之說, 即：“看山是山, 看水是水; 看山不是山, 看水不是水; 看山還是山, 看水還是水。”
這一句話對於軟體架構的設計過程中同樣適用，在最初的時候，我們對於軟體程式不懂就按照官方給的示常式序來進行設計，即看山是山；隨著我們的知識，見解，經驗的積累我們有了自己的一些看法理解，出了自己的各種框架，即看山不是山；隨著時間的推移，我們已經悟到了其中的精髓，又回到了官方示例，大道至簡，即看山還是山。
（未完待續）
