.Net Core with 微服务 - 架构图
dotNET跨平台 今天
以下文章来源于馒哥不光会玩当耐特 ，作者MJZHOU上一次我们简单介绍了什么是微服务（.NET Core with 微服务 - 什么是微服务）。介绍了微服务的来龙去脉，一些基础性的概念。有大佬在评论区指出说这根本不是微服务。由于本人的能力有限，大概也只能理解到这个层次。先不管它到底是不是微服务吧，既然开篇了，那就硬着头皮把这个系列写完。我想不管是对自己对看官多少还是有点帮助的。
架构图
这篇文章将从一张架构图开始说起（开局一张图，内容全靠凑🤣）。
很多介绍微服务架构的文章画的架构图比这张图复杂的多。我根据自己的理解与实践修改跟精简了一下。
上次评论区说.Net只在标题上出现了一次，那么这次，大概也只会在标题上出现一次🤣。大概从下一篇开始就会正式介绍如何使用 .net core 一步步实现一个最简微服务系统。下面就开始对照这张架构图进行讲解吧。
基础服务层
基础服务层是一个抽象的概念。我们把提供基础业务处理能力的服务归类到这一层。我们按照模块\领域等概念把服务划分好，最后建成了一个个独立部署的服务。它们提供一些基础的服务功能，对外提供一些api接口。每个服务都有自己独立的数据库，独立的运行时。每个服务都可以根据压力进行伸缩。这一层可以说是微服务架构里最核心的一层。
比如一个酒店管理系统，我们一般可以划分成：“酒店基本信息服务”、“订单服务”、“会员服务”、“支付服务”等等基础服务，每个服务都提供一些api，比如订单服务提供查询下单等服务，支付服务提供微信支付的支付能力等等。
当然如何划分都是似情况而定的，这里只是举个例子。
聚合服务层
我们已经有了基础服务，为什么还会有聚合服务这一层呢。假设现在用户根据订单号查询订单明细的功能。这个功能可能需要涉及到订单基本信息、用户基本信息、会员信息、支付信息、房型信息等多个api。如果有前端直接调用基础服务层，那么可能要发送多次http请求。所以为了效率往往还需要有一个服务来聚合跟适配，合并成一次请求再对前端提供服务，这样对于前端来说效率相对会高一些，开发起来也简单很多。
再比如我们现在的系统往往会接入很多终端，有PC，有APP，有小程序。由于设备的不同，我们对外需要展示的内容也会有差异，我们可以在聚合层进行api的适配跟裁剪，根据不同的设备返回不同的响应。
网关
微服务网关在这个微服务架构中起着至关重要的的地位。从上面的图上可以看到，网关在架构的顶端，是流量的入口。它对每个一个请求进行监控，路由。使每一个合法的请求进入到对应的服务。
因为所有请求都会过网关，所以网关可以做一些全局的工作或者说类似AOP思想里切面的工作。比如认证、授权、限流、过滤等等。一旦网关服务崩溃往往会影响到整个微服务的工作，尽管它内部服务全部正常，但是它可能无法对外提供服务。
正因为网关所在的位置在架构中所承担的功能，所以我们需要网关组件的性能非常高，稳定性非常高。
常用的网关组件有：kong，zuul，Ocelot 等。在 .Net 领域用的比较多的是Ocelot。
微服务相关组件
很多网上的架构图都把微服务相关的这些组件写到业务服务层下面，叫做支撑服务。其实个人是不太认同的。所谓支撑的话可以说是桌子的腿，少了一条桌子就会翻了。事实上我觉得一个完整的微服务不一定非要上全了所有组件。这种都是视情况而定的，没有绝对的说法。比如说不上监控服务，微服务就不能跑了吗？显然不是的。不是说上了这些组件就叫微服务，不上就不是微服务。有了日志聚合、服务发现等等组件是为了更好的实施微服务，但不是必须的，所以我并没有把他们叫做支撑服务。
服务注册发现
在实施微服务之后，我们的调用都变成了服务间的调用。服务间调用需要知道IP、端口等信息。再没有微服务之前，我们的调用信息一般都是写死在调用方的配置文件里（当然这话不绝对，有些公司会把这些信息写到数据库等公共的地方，以方便维护）。又由于业务的复杂，每个服务可能依赖N个其他服务，如果某个服务的IP，端口等信息发生变更，那么所有依赖该服务的服务的配置文件都要去修改，这样显然太麻烦了。有些服务为了负载是有个多个实例的，而且可能是随时会调整实例的数量。如果每次调整实例数量都要去修改其他服务的配置并重启那太麻烦了。
为了解决这个问题，业界就有了服务注册发现组件。
假设我们有服务A需要调用服务B，并且有服务注册发现组件R。整个大致流程将变成3步：
服务B启动向服务R注册自己的信息
服务A从服务R拉取服务B的信息
服务A调用服务B
有了服务注册发现组件之后，当修改A服务信息的时候再也不用去修改其他相关服务了。
常用的服务注册发现组件有：Eureka，Consul 等等。
配置中心
看了上面的服务发现注册，也许你也想到了。其实配置中心跟服务发现注册解决的是同一类问题。那就是分布式系统对于修改配置这种事情实在是太麻烦。如果实例是部署在容器内的那一个个实例去修改配置简直是一场噩梦。
为了解决这个问题，就有了配置中心。配置中心把所有服务的配置都集中管理。并且提供配置热更新、权限管理、版本管理、灰度发布等高级功能。当服务启动的时候不再从本地配置文件读取配置，而是远程从配置中心读取配置。
常用配置中心组件有：Nacos 、Apollo 、AgileConfig 。
🌟🌟🌟打个广告：AgileConfig 是本人开源的一个轻量级配置中心。https://github.com/kklldog/AgileConfig 求🌟🌟🌟！
日志聚合
日志是我们写程序离不开的一个东西。在我们排查问题的时候日志就是我们的救命稻草。我们的每个服务都在不停的生产日志。但是实施微服务后，如果按照传统的写本地文件的日志方案，显然会面临跟修改配置一样麻烦的境地。不同的日志分散在各个服务器、容器内，这种情况下查日志简直是生不如死。
日志聚合组件为我们解决了这个问题。所有的服务通过接口发送日志到聚合服务，再由聚合服务进行统一存储，并且提供统一的查询、分析的能力。
日志聚合组件业界有比较重型的 ELK ，.Net 这边也有常用的Exceptionless 、SEQ 。
监控服务
由于微服务架构带来系统的复杂性，出了问题往往无法快速定位问题。那么这个时候就需要监控系统出场了。监控系统能够在故障发生之前防范于未然，在故障发生之后快速回溯问题，定位问题。
微服务监控一般分以下几个维度的监控：
硬件资源类监控
硬件资源是我们实施微服务的基石。CPU、内存、储存等指标在日常生产中是需要时刻关注的，不然很容易因为资源耗尽出现故障。应用类监控 这一类监控围绕对应用、服务、容器的健康监控，对接口的调用链、性能进行监控。这里着重提一下调用链监控。在我们实施微服务后，由于复杂的业务逻辑，服务之间的调用会像蜘蛛网一样复杂。有了调用链监控后服务之间的调用可以用图像的方式展示出来，每个请求的性能，响应等都会记录下来。对于提前防范问题，以及排查问题有非常大的意义。
这一类监控跟我们研发同学比较近，常用的组件有重量级的 SkyWalking APM ，轻量级的有 HttpReports 。运营类监控
这一类监控主要跟业务相关。运营的同学比较关注。比如监控每一天的流水，每天注册的会员人数，发放的优惠券等等。
微服务的组件还有很多，这里也就介绍几个常用的组件，其他不再多说。还是那句话这些组件是为了更好的实施微服务，用不用看情况。当你实施微服务的过程中发现了痛点，自然就会去找对应的方案、组件去解决它。
总结
以上通过一张微服务架构图，大概讲解了微服务架构常用的分层方案，每一层的意义，为什么要这么分。介绍了常用的微服务组件的作用功能等等。至此我们对微服务架构应该有一个比较全面的了解。但是记住一句话，架构没有固定的模板没有定式，你可以根据自己的情况来划分层次，自己的情况来决定使用哪些组件。
那么从下一篇开始我们就要正式开始使用.Net Core来一步步实现一个最简微服务项目啦，敬请期待。