微服务架构
1.什么是微服务架构？
微服务框架当下很火，那到底什么是微服务呢？为什么会火呢？
我们传统的应用程序是一个项目，在一个进程里面运行的。这样就会导致各个业务逻辑模块耦合性高，有时代码调整时，牵一发而动全身。传统的项目大部分采用单体式开发，如下图所示：
如上图所示，单体式开发弊端显而易见。我们改动订单模块时，仓储、物流、用户模块也可能会受到影响。
业务推动技术的发展，技术应用于业务。由此，诞生了我们的微服务架构。
微服务架构的定义：是一种程序设计风格，把各种业务分离成单独的服务，在独立进程中运行。这样就可以降低各模块之间的耦合性。
2.微服务的通信方式
微服务把各模块独立分离出来，那么各个模块之间需要进行通信时，通过什么方式通信呢？
微服务的各个模块是单独的一个进程，我们要实现他们之间的通信，只能通过跨进程通信方式。
跨进程通信主要方式有：基于第三方共享存储（如：队列、数据库）、网络协议通信（webservice/WCF/WebApi等）、Remoting（RPC），其中网络协议通信用的最多
3.微服务注册与发现-consul
微服务要求我们任何服务都要集群（提供多个进程处理，避免单一进程挂死带来影响）
集群的好处：提升承载能力、避免单一故障、动态伸缩。
提到集群，很多人会想到用Nginx来集群，如下图所示：
虽然Nginx可以实现服务集群，但是Nginx不能实现动态新增服务实例、同时由于服务可能会挂死，所以必须要经常检查服务的健康状况，这个Nginx也做不到，这就产生了我们的consul。
consul可以动态进行服务的注册与删除，是微服务必须的。consul的工作过程如下图所示：
创建服务实例时，都会先在consul注册服务，这样consul就能动态知道添加了哪些服务，同时consul也会对每一个服务进行健康检查，及时删除一些挂死的服务。
4.应急机制处理--Polly
尽管我们已经把模块划分成很多进程服务了，但是毕竟资源有限，我们在遇到流量大爆发时（比如双11），可能会导致总资源不够用，这个时候应该怎么处理？
这时，我们可以考虑降级的方法，划分优先级，在一定的条件下（比如总资源不够用的情况），我们可以选择关闭一些优先级较低的服务（比如淘宝的评论服务）。这时候我们就需要引入Polly应急机制处理。
我们再Polly里面配制好服务的优先级，平时能正常访问，特殊时期选择关闭部分服务。
Polly的主要功能有：
①限流：限制单位时间内服务的请求频率（比如秒杀活动），只允许几个请求进来
②降级处理：降低优先级来实现特殊时期关闭某些服务
③缓存：可以对一些数据进行缓存，这样就可以从缓存里面取数据，避免再进入服务层调用服务。
④重试机制：当对一个服务实例访问时，访问失败，我们重新访问，避免遇到服务偶然性挂死问题
⑤超时机制：设置一个超时时间，如果一个实例在规定时间内访问不上，就跳出去访问其他服务。
⑥熔断机制：一个服务不能响应，就停止访问，不再请求。
5.网关Gateway-Ocelot（微服务核心部分）
每一个模块可能有很多个微服务，客户端不可能要管理所有的服务，因为如果管理的话客户端会变得非常臃肿，不易维护。
这时，网关Gateway就可以帮我们管理这么多且复杂的各个服务。
网关Gateway是微服务中最核心的，可以说没有网关，微服务就无法运行
网关的工作机制如下所示：
我们上面所说的Polly位于API Gateway这一层，认证授权（IdentityServer4也处于API Gateway里面）
6.Dock容器
我们的服务就存放在Dock容器里面，有点类似一个镜像文件。
Dock容器：快速部署、敏捷迭代
微服务的分享到此结束，笔者也是第一次接触微服务，感觉微服务很强大，特别数据并发处理这一块，今后还需花时间好好学习。上述内容如有不正确地方，欢迎批评指正。