ASP.NET Core 中的微服务架构

多尼克

什么是微服务架构？


一、单体架构

单体，即：一个进程完成全部的后端处理，如果搞不定，就多个进程一起，单体中一般包含：客户端（App、H5、Web）、服务端部署（反向代理、数据库、中间件等），目前市面上大多数项目都还是主流于使用单体结构；
但是，随着 用户量、流量、数据的增长，单体架构出现了瓶颈（即：单台服务器处理能力有限、包括但不限于：并发处理不过来、内存、cpu、磁盘IO等瓶颈），就出现了：垂直、水平拆分，即使用多台服务器均衡请求；
二、水平、垂直拆分
水平拆分：同一个后端多环境部署，他们都处理相同的内容，使用反向代理来均衡负载；这种也叫集群（多个节点干相同的事儿）
垂直拆分：不同业务拆分为各个节点，反向代理通过路由将请求分发给每个业务节点上；
但是不论是 水平拆分 还是 垂直拆分，都是为了应对并发，使用更多的服务器来处理更多的请求；


三、分布式和集群

在 水平、垂直拆分时，假设我们的业务节点所产生的日志信息需要统一汇总记录，我们就分离出了一些共用的服务（Service-mini，小服务），供我们的业务层节点请求访问，比如共用的日志处理服务，每个业务节点都需要把自己的日志发送到公共的节点上，这时，慢慢就演变成了，一个业务节点，需要多个业务节点相互配合，最后才将用户的请求返回出去，这种架构，我们称之为：分布式；

关于真正理解 集群 和 分布式 的区别，包括什么是节点、什么是服务实例等，可以参考(https://www.zhihu.com/question/20004877)

CAP：分布式的入门理论，即：C / A / P 这三个不能同时满足，或者说：一致性C、可用性A、分区容错P 不能同时满足；（关于CAP的分区容错P和为什么不能同时满足的更详细解释，(https://www.zhihu.com/question/54105974)）
P：网络之间的的互相请求连接总是有不稳定（包括：丢包、断网、延迟等）的时候；
C和A：在P不满足的条件下，我们不能保证其高可用性、数据的一致性；
分布式事务：在分布式环境下，如何保证事务的一致性，即多节点之间的数据执行过程中，要么都成功、要么都失败；
分布式锁：单体中因为是一个进程，所以上锁是很简单的，比如内部锁lock，但是多进程的话，是很难保证他们之间事务的一致性；
临时加更干货分享

大家能看到这里，已是对我们的支持了。分享一组9月录制的C#零基础教程。我们喜欢做这样的分享，它足够的基础，对新手友好。如果需要的话，就来免费领取吧！



快来领取吧

资料免费自取：

由于内容过多不便呈现，需要视频教程和配套源码的小伙伴，点击下方卡片！
也可点击下方卡片：点击后自动复制威芯号，并跳转到威芯。搜索威芯号添加，内容已做打包，备注知乎
即可免费领取，注意查收！
四、微服务
当分布式的问题都解决掉之后，微服务就出现了；
所谓微服务架构，就是在分布式技术成熟后，使用分布式的方式去完成业务解耦，这种架构风格就是微服务架构(还包括全套的微服务架构组件)


官方含义：微服务架构是一个用分布式服务来拆分业务逻辑，完成解耦的架构模式(架构风格)
微服务架构就是在分布式技术成熟后，通过分布式服务来拆分业务逻辑，完成解耦，并且通过一系列组件和方法论来解决落地问题，这套架构风格+落地标准就是微服务架构！
微服务:每个服务就是方法，调用分布式服务
微服务图如下：


要想实现微服务的落地，必须先完成对服务的拆分！
推荐使用DDD领域驱动设计，来完成服务的拆分，即：按照领域来拆分（按照这种来拆分，每个人最终的结构都会是不一样的，所以，没有确切的结果！）
提示：学习微服务前，最好先了解什么是DDD领域驱动模型，里面的几个大概念需要理清，比如：领域和子领域、领域模型、实体和值对象、聚合和聚合根、领域事件、充血模型和贫血模型等；
微服务的知识体系

核心要求（必须掌握）

• 服务注册发现——高可用+伸缩性
  
• 网关服务治理——在客户端和服务端之间
  

功能性要求

• 全链路追踪：skywalking
  
• 分布式日志 ELK
  
• Apollo 配置中心
  
• 独立鉴权授权中心 SSO
  
• Prometheus+Grafana 监控分析
  
• 分布式锁——分布式事务
  

运维需求

• Git+Jenkins+Docker+Kubernetes
  

微服务的根基（核心要求）

根基包括两点：

• 服务的高可用：即服务必须保证在线、存活，尽量降低服务不可用的情况；
  
• 服务的可伸缩：即服务能根据请求过来的流量、并发数等，去自动增减自身的服务（有些服务压力大，有些服务压力小，那么我们需要通过一种策略去动态地增加压力大的服务实例数量，减少压力小的服务实例数量）；
  

那怎么实现高可用和可伸缩功能呢？即：怎么实现动态检查服务实例状态、动态增减服务实例数量呢？
我们就需要引入一个工具：服务注册发现
服务注册发现

每当每一个微服务实例启动时，都会向 服务注册发现中心 注册，服务注册发现中心 就会保存每个注册过来的服务实例，并向这些服务实例发送心跳、判断对应的服务实例是否正在工作、或者是否出现宕机等；


看上图，服务注册中心保存了已经注册的服务实例，我们在网关这里先去 服务注册中心Consul集群 中获取这些服务实例的信息（比如地址等），再去调用对应的集群中的某个服务实例节点；
现在又有一个问题，我们客户端如果要访问，那么是直接击中到服务实例集群中吗？很显然不是，，这就引出了第二个核心内容：网关服务治理；
网关服务[治理] Gateway

如果我们的客户直接击中服务实例节点，那么将会这样：


缺点：
1、上面只有8个服务实例，就那么乱了，而我们以后项目中部署的服务实例肯定会上百个，如果是这样子的话关系就会更加的复杂化了；
2、服务实例直接暴露给外网，公网IP肯定不够用，资源利用完全不可行；
3、安全性：难道每个微服务都要自己检查其自身的安全性吗？这样工作量太大，以后出现安全性问题也非常难以排查；
我们通过引入网关解决上面3个问题：


首先，客户端访问反向代理Nginx，然后反向代理将请求转发给 网关 ，网关根据请求来的信息，在 服务注册中心 中获取对应的微服务节点信息，然后根据信息找到微服务节点并请求该节点处理业务逻辑；
因为所有的请求都需要听过网关，所以我们可以在网关上做一些特殊的事情，包括但不限于：缓存、鉴权授权、均衡负载、路由转发、Polly（熔断服务、限流、超时和重试）等，我们将这些事情称之为：网关服务治理
Polly 是一种.NET弹性和瞬态故障处理库，允许我们以非常顺畅和线程安全的方式来执诸如重试，断路，超时，故障恢复等策略。
上面，我们了解了微服务的必须条件：服务注册发现 和 网关服务，下面，我们继续介绍几大与微服务有关的框架；
1、全链路追踪（skywalking）
在微服务中，因为每个服务实例之间的连接关系、甚至包括服务注册中心、网关等之间的通讯，其关系网是非常复杂的；
假如有一个请求进来，发现这个请求在这套微服务体系中，需要执行15s才成功，我们如何排查这个耗时的操作是哪里的呢？
链路追踪，就是解决这种关系混乱的局面，它能把调用过程（包括：位置、时间、参数、结果），都列出来；
Net中用得最多的是：skyapm
官方：分布式追踪和APM的Server端，它将包含Collector, Storage，独立的Web UI，并使用Open Tracing规范来设计追踪数据。
2、分布式日志 ELK

每个微服务产生的日志的存放位置，发现问题能及时查询到，包括：收集日志、可视化、全文检索、筛选；
一般的解决方案有：
Exceptionless:开源的日志收集和分析框架，能为应用程序提供实时错误、特性和日志报告；https://github.com/exceptionless/Exceptionless.Net
ELK，最强的分布式日志解决方案
3、Apollo 配置中心

分布式配置中心，管理每个微服务实例的配置信息的；
Apollo:配置管理平台，能够集中化管理应用不同环境、不同集群的配置配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
https://github.com/apolloconfig/apollo
https://www.cnblogs.com/edisonchou/p/9419379.html




4、独立鉴权授权中心 SSO

鉴权在网关处处理，而不是分配到每个微服务实例中；
鉴权一般是使用 Bearer JWT 方式；


5、Prometheus+Grafana 监控分析

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)
Grafana 是一个开箱即用的可视化工具，具有功能齐全的度量仪表盘和图形编辑器，有灵活丰富的图形化选项，可以混合多种风格，支持多个数据源特点


https://prometheus.io/docs/introduction/overview/
https://github.com/prometheus-net/prometheus-net
https://github.com/grafana/grafana
6、分布式锁——分布式事务
跨进程的互斥机制来控制共享资源的访问，这就是分布式锁；

• 基于数据库
  
• 基于Redis
  
• 基于Consul/Zookeeper
  

7、上线部署



做微服务开发的后期部署一般都是容器化部署的了，，，
Jenkins 是一个开源的、提供友好操作界面的持续集成(CI)工具，主要用于持续、自动的构建/测试软件项目、监控外部任务的运行，白话：一键将写好的、修改好的服务部署到已有的服务集群中；（即：发布部署都傻瓜化全自动【打包镜像、运营测试、编译生成发布文件，上传、拷贝到自动目录中、甚至每一次发布都会发个信息给别人审核是否需要发布等】）
https://www.jenkins.io/zh/doc/
Docker 是一个开源的应用容器引擎，可以打包应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。（优点：轻量化、隔离、镜像打包和回滚）
https://docs.docker.com/
Kubernetest，编排容器，是管理应用的全生命周期的工具，从创建应用/部署，应用提供服务，扩容缩容，更新，都非常的方便，而且可以做到故障自愈，功能包括：流量自适应、灰度发布、滚动发布、失效转移、快速伸缩等
https://kubernetes.io/zh/docs/home/
如果你是一步步看到这里，你就会觉得微服务不过如此啊？为啥大多数公司不用呢？主要还是因为：门槛太高、太过于复杂、体系很大；
第三代微服务架构：服务网格（ServerMesh）
即：程序员只需要把重心交给业务，而不需要去关心什么熔断啊、分布式日志啊、配置中心啊、服务注册啊、全链路追踪啊等这些问题；
https://www.cnblogs.com/xishuai/p/microservices-and-service-mesh.html


再次升级：云原生（Cloud Native）







最终升级：无服务架构（Serverless）

FaaS: Function as a Service
即：web api 你都不需要写了，直接写函数，然后部署上去。。。


过去式泡沫：中台架构

阿里想推动的，但是阿里已经放弃了。。。
微服务属于技术架构---从技术的角度出发进行描述
中台属于业务架构---从业务层面来描述架构


原文链接：ASP.NET Core 中的微服务架构。