我眼中的ASP.NET Core之微服务

### 前言

前几天在博客园看到有园友在分享关于微软的一个微服务架构的示例程序，想必大家都已经知道了，那就是[eShopOnContainers](https://github.com/dotnet-architecture/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 其实是一个非常适合做微服务的一个 Web 框架，它足够的轻量级并且拥有超高的性能。并且对于 Rest 这些风格的接口支持的非常的友好。更多好处我其实不太愿意去说，因为只有你自己去体会才会知道。还不如来点实在的，去教你们怎么在 ASP.NET Core 中构建一个或者叫一组微服务集群。在我看来，有时候讲那么多理论也都是扯淡的。那就废话不多说，开始吧。

### 步骤

在开始之前还是要说一句，你的架构一定要符合你的业务和需求，不要为了架构而架构。举个例子，你的网站每天的访问量就那么几百号人，以后也不会大量的增加，你又是分布式又是大数据又是docker集群的这不没事给自己找事干么。切记。

**第一步，业务拆分。**

业务拆分其实有时候是需要经验积累的，有时候不仅仅是需要你有软件架构经验，还需要你有行业知识的经验。这时候你的业务拆分的才足够合理，不会随着时间的推移导致你的微服务变“大”。

如果你对 DDD 中领域建模这种软件建模方式在行的话可能会帮助你解决大量的潜在问题，如果你不会也没关系，因为你可以去学呀~ 2333

**第二步，建模。**

在微服务架构中，建模仍然是重要的一步，因为你使用的是 EF Code First , 建模质量的好坏肯定是和你以后的代码质量挂钩了。如果你不使用 EF，那我们就不能愉快的做朋友了。

给大家个小提示，如果你的项目中全是增删改查，没有什么业务算法或者逻辑可言的话，就让你的模型尽量的符合你的界面上的显示字段，这样可以最大化的提升开发效率。

**第三步，写代码。**

这个时候我希望你抛弃掉三层架构这种架构风格的设计，不是说那种不好，而是有更加便捷的方式了，你需要知道，你写的每一个 Action 都应该是尽量的简单，再去调用 BLL 层绕一大圈子就为了一个增删改查纯粹是给自己找活干，那样并没有提高项目的可维护度。

前段时间在 QQ 群听学姐说过这么一句话，就是佛家的人生三重境界之说, 即：“看山是山, 看水是水; 看山不是山, 看水不是水; 看山还是山, 看水还是水。”

这一句话对于软件架构的设计过程中同样适用，在最初的时候，我们对于软件程序不懂就按照官方给的示例程序来进行设计，即看山是山；随着我们的知识，见解，经验的积累我们有了自己的一些看法理解，出了自己的各种框架，即看山不是山；随着时间的推移，我们已经悟到了其中的精髓，又回到了官方示例，大道至简，即看山还是山。