介绍：
写这篇文章有多方面的原因，第一当然是为了以后自己可以随时翻阅，第二也算是一种积累吧。因为有些东西你弄个之后，过了很长时间不用，可能会有些忘却，但是你因为以前弄个吧，有不是那种小白，需要去找示例代码，而你缺的只是一个引子然你回想起来。所以我们大多数园子的人不少写文章就是为了这个吧。当然有顺序有规律的去学习会比盲目的去学要好的多，所有我这也是分步进行的，也不失为一个想了解微服务，但是又不知道如何下手的人提供一个思路。当然我写的也不是多好，有些也是看着官网做的，有的理解也是不很到位。共同学习共同进步吗。
其实在写这个文章的时候我已经做了很多功课（已经写过其中的技术点了）。只是后来想了想还是整理出来一个目录吧，方便以后归类整理，不然每一篇单个的文章不知道是干什么，毕竟使用了多个技术点。我写的文章数也不是很多，我也不是特意为了写文章而写文章，只是为了自己的一个文档整理而已，所有有的篇幅问题了我们就笑笑吧。
我也没有那么多的时间去深入的发掘，所以写的都是一些入门示例，主要是让我们明白他是个什么，对就是这个意思。深入的我们入门以后可以自己去探索。还是刚才那句话，因为我只是做笔记记录，所有我是有时间说不定才会更新一些文章，所有高手就绕行吧，我现在只写了一些入门示例，当然以后有时间或者需要了还会持续更新本系列吧。
为什么选择微服务哪？相对于传统的应用架构：
- 业务代码混杂，团队成员职责边界不清，团队协作体验不佳，开发效率低下。传统应用架构中，各个业务模块代码都存在于同一个应用当中，各个业务模块之间交互逻辑复杂，代码统统混在一起，难免出现要去别人代码里改代码的情况
- 代码耦合度高，日趋臃肿，难以重构，维护成本越来越高。感受过被F12支配的恐惧吗？
- 容错能力弱，单点故障引发全局崩溃。
- 无法针对热点业务增加资源，造成浪费。
ASP.NET Core 其实是一个非常适合做微服务的一个 Web 框架，它足够的轻量级并且拥有超高的性能。并且对于 Rest 这些风格的接口支持的非常的友好。更多好处我其实不太愿意去说，因为只有你自己去体会才会知道。
微服务架构按照功能和业务将应用程序分离成若干个部分，使各个部分之间松绑。一个典型的简单微服务架构至少有以下几个部分：
- UI 层：即前端视觉层，包括 web 端网页、手机APP以及PC客户端
- 集群：根据需求不同，微服务集群中会包含至少1个微服务实例，通过负载平衡将请求分配到每个实例上。
- 代理：反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
- 网关层：网关层类似我们家里用的路由器，可以将入站请求重定向到目标为服务，并将站内的微服务进行整合打包输出到站外。UI层一般会通过 HTTP/HTTPS 协议访问网关向公网暴露的接口。
系列目录：
微服务系列文章主要介绍微服务所使用到的一些技术和一些技术示例：
