本笔记是基于微软MVP-Eleven 老师的微服务课程
什么是微服务？
微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。
微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。
整体式架构与微服务架构
通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。
使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。
微服务的特性
可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。
每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。
微服务的优势
微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。您可以从组织的总吞吐量中显著获益。
通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。
微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。
技术自由
微服务架构不遵循“一刀切”的方法。团队可以自由选择最佳工具来解决他们的具体问题。因此，构建微服务的团队可以为每项作业选择最佳工具。
可重复使用的代码
将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。
弹性
服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障。
==============================================================================================================================================
以上都是网上关于微服务的介绍，其实微服务理解起来很简单
之前开发系统的一般都是把所有业务都放在一个系统里面，即所谓的单体系统
以京东为例：
京东包括京东自营，京东秒杀，京东超时，京东生鲜，京东金融，京东白条等等系统
按照单体系统来开发的话，系统结构图如下：
对于每一个系统来说，每个系统都会有用户操作，支付操作和日志操作等，按照这种单体系统来说的话，那么就需要在每一个系统中都需要分别去写这些操作，这样维护起来是非常不方便的，譬如我要修改日志逻辑，那么我就需要去修改所有的系统，那么就要对每一个系统进行开发，测试，发布等等流程，非常不合理。
针对以上问题，提出解决方案：
解决思路：
即分布式系统，
将用户服务，支付服务以及日志服务单独提出来，分别进行调用，这种结构优点如下：
1. 一系列服务组装成系统
2.独立部署，独立运行
3.独立开发和维护
4.分布式管理
5.强调隔离性
缺点：
1.服务调用会有延时
2.数据的事务问题
3.其中一个服务挂了，所有系统都会瘫痪
微服务也是分布式中的一种
微服务其实就是把BLL层独立成服务
针对分布式服务断开问题，可以靠服务集群解决
微服务架构基础：
1. 服务的高可用
2. 服务的可伸缩
解决办法：集群（负载均衡）：多台服务器做相同的事儿，共同承载压力。
微服务的任何一个服务都要使用服务集群
微服务的架构核心：
1. 服务发现，调用方如何发现服务
2. 负责均衡，如何调用服务
针对核心三种方案：
1. 集中式代理-Nginx
单纯是负载均衡
对于客户端而言，我只需要找到Nginx就可以找到服务，但是服务发现只可以通过人工配置
调用方式通过Nginx管理
配置步骤：
1>.nginx.conf里 server----listen
2>. location / { proxy_pass http://Microservice; }
3>.upstream Microservice{ server localhost:5726; server localhost:5727; server localhost:5728; }
4>.start nginx.exe
2. 客户端嵌入-Consul
描述：Consul可以实现服务的自动注册与发现,也可以实现健康检查,但是自身不可以实现负载均衡
Consul实现过程：客户端---Consul---发现服务实例----定期健康检查---返回给Consul
Consul实现步骤：
A.服务实例注册
B.客户端从Consul里发现服务实例
C.客户端调用服务实例
Consul优点：
功能强大，自动发现-自动下线
Consul缺点：
客户端集成复杂（负载均衡在客户端实现），客户端决定调度策
Consul.exe命令行启动
consul.exe agent -dev
访问地址：http://localhost:8500/ui/dc1/services
服务启动时注册，且注册一次
WebApi向Consul里注册
在Nuget里添加Consul
1>.在startup里注册服务实例
2>.在客户端拿到url
3>.通过URL找到实例
4>.服务挂了，影响业务，心跳检查
Consul跟Nginx对比
1>.Consul不用手动添加服务实例，有健康检查，可以调用根据url调用实例，但是得客户端实现负载均衡
2>.Nginx本身可以实现负载均衡，但是得手动添加服务实例
3. 网格服务-Service Mesh
描述：
每台电脑 里面都有一个Sidercar ，负责调度策略，负载均衡，健康检查
实现：
主机+代理
优点：
独立性，自己玩自己的，不受别人的影响
缺点：
复杂度上升，每台电脑得安装
服务治理-网关Gateway
就是将所有服务整合在一起进行管理，这样就可以实现服务的超时，熔断，限流，服务降级等。
服务的鉴权也可以放在这里进行
相当于路由的功能
为什么需要网关
1. 使用网关就不需要所有的服务都提供公网IP访问
2. 如果系统需要进行权限校验，那么可以写在三个位置：
- 每个服务自己实现一遍
- 写到一个公共的服务中，然后其他所有服务都依赖这个服务
- 写到服务网关的前置过滤器中，所有请求过来进行权限校验
第一种，缺点太明显，基本不用；第二种，相较于第一点好很多，代码开发不会冗余，但是有两个缺点：
- 由于每个服务引入了这个公共服务，那么相当于在每个服务中都引入了相同的权限校验的代码，使得每个服务都需要引用这个dll；
- 由于每个服务都引入了这个公共服务，那么我们后续升级这个服务可能就比较困难，而且公共服务的功能越多，升级就越难，而且假设我们改变了公共服务中的权限校验的方式，想让所有的服务都去使用新的权限校验方式，我们就需要将之前所有的服务都重新引包，编译部署。
而服务网关恰好可以解决这样的问题：
- 将权限校验的逻辑写在网关的过滤器中，后端服务不需要关注权限校验的代码；
- 如果想修改权限校验的逻辑，只需要修改网关中的权限校验过滤器即可，而不需要升级所有已存在的微服务。
所以，需要服务网关！！
网关和Ngnix的区别：
Ngnix是负责转发集群的，针对同一个服务，网关是负责服务映射的，针对的是不同服务。
进程间通信
1. 服务通信，如WebAPI，Web Service， WCF等
2. RPC， gRPC
3. 队列即第三方存储
技术栈：
Polly-> 瞬态故障处理
Skyapm-> 分布式追踪 追踪请求的服务
ExceptionLess-> 实时错误日志
Apollo -> 统一配置中心
分布式锁
分布式事务 TCC，2PC/3PC （CAP理论）
运维：
Dcoker -> 开源的应用容器引擎，可以打包应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows机器上，也可以实现虚拟化。
也就是一个轻量级的虚拟化系统，可以更快捷的启动服务器集群
容器编排K8S -> Kubernetes 编排容器，是管理应用的全生命周期的工具，即对Docker容器的管理，从创建应用/部署，应用提供服务，扩容缩容，更新，都非常方便，而且可以做到故障自愈。
Jenkins -> 是一个开源的，提供友好操作界面的持续集成（CI）工具，主要用于持续、自动的构建/测试软件项目、监控外部任务的运行，也就是分步交付测试。