上次我们简要介绍什么是微服务（带有微位置的.NET核心 - 什么是微服务）。介绍微服务的来源和出现，这是一些基本概念。一些大型人在评论领域指出，这根本不是微服务。因为我有限，所以我只能理解这个水平。无论它是否是微服务，由于开始是开始的，然后用头皮编写此系列。我认为看到官员对自己有点有帮助。

建筑学

本文将从架构图开始（在开始时启动图片，内容都依赖于）。

许多有关微服务架构的文章比这张图片更为复杂。我根据自己的理解和实践对修订和精简。

最后一个评论区说，.NET仅出现在标题上一次，因此这次，它只会出现一次标题。从下一篇文章的开头，它将正式介绍如何逐步使用.NET核心以实现最简单的微服务系统。让我们从此体系结构图开始。

基本服务层

基本服务层是一个抽象概念。我们对服务进行分类，以将基本的业务处理功能提高到此级别。我们根据模块\字段的概念对服务进行划分，最后构建了独立的部署服务。他们提供一些基本的服务功能并提供一些API接口。每个服务都有自己的独立数据库独立操作。每个服务都可以根据压力扩展。可以说这一层是微服务体系结构中的核心层。

例如，酒店管理系统通常可以分为：“酒店基本信息服务”，“订单服务”，“会员服务”，“支付服务”和其他基本服务。每项服务都提供一些API，例如订单服务提供查询服务，例如下订单，付款服务以提供微信支付付款能力等。

当然，如何将其划分为情况，这就是一个例子。

聚合服务层

我们已经有基本服务，为什么我们有一层聚合服务？假设用户现在根据订单号查询订单详细信息的功能。此功能可能需要多个API，例如订单的基本信息，用户基本信息，会员资格信息，付款信息和房间类型信息。如果前端直接称为基本服务层，则可以发送多个HTTP请求。因此，为了提高效率，通常需要进行汇总和调整的服务，并将合并合并为请求，然后为前端提供服务。这将在前端相对较高，并且开发要简单得多。

例如，我们当前的系统通常访问许多终端，以及PC，应用程序和小程序。由于设备的不同，我们需要展示外界的内容也将有所不同。我们可以使用API​​在聚合层中进行剪切和调整，并根据不同的设备返回不同的响应。

网关

微服务网关在此微服务架构中起着至关重要的地位。从上图可以看出，在体系结构的顶部，网关是流量的入口。它监视每个请求和路线。每个法律请求都进入相应的服务。

由于所有请求都将通过网关，因此网关可以从事一些整体工作或类似于在AOP思想中切面的工作。例如认证，授权，当前限制，过滤等。一旦网关服务的崩溃通常会影响整个微服务的工作，尽管其内部服务是正常的，但它可能无法在外部提供服务。

由于网关的功能在体系结构中，因此我们需要网关组件的性能很高，并且稳定性非常高。

常用的网关组件是：Kong，Zuul等。.NET领域中还有更多。

微服务相关组件

许多在线体系结构图编写了与商业服务层下的微服务相关的这些组件，称为支持服务。实际上，个人不同意。可以说SO被称为桌子的腿，并且将翻转桌子。实际上，我认为完整的微服务不必使用所有组件。这取决于情况，没有绝对的言论。例如，如果没有监视服务，您不能跑步吗？显然不是。当您进入这些组件时，并不是说您被称为微服务。借助日志汇总，服务发现等，组件将更好地实现微服务，但这不是必需的，因此我没有称它们为支持服务。

服务注册发现

实施微服务后，我们的呼叫已成为呼叫室。呼叫室电话需要了解IP，端口和其他信息。在没有微服务之前，我们的呼叫信息通常以呼叫方的配置文件写入（当然，这不是绝对的，有些公司会将此信息写入公共场所，例如数据库，以促进维护）。由于业务的复杂性，每种服务都可以依靠其他服务。如果服务的信息已更改，则必须修改依赖服务服务的配置文件，这显然太麻烦了。某些服务具有多个负载实例，并且可以随时进行调整。修改其他服务的配置并在每次调整实例数时重新启动是太多麻烦。

为了解决这个问题，该行业有服务注册并找到了组件。

假设我们需要服务a来调用服务b，并且有一个服务注册发现组件R。整个一般过程将成为3个步骤：

服务b启动信息服务r登记处到服务R.服务r选择服务B信息服务呼叫服务B服务B服务

使用服务注册发现组件，在修改A服务信息时，您不再需要修改其他相关服务。

常见的服务注册发现的组件是：，等等。

配置中心

查看上面的服务后，我发现您已经想到了。实际上，配置中心和服务发现注册是通过相同类型解决的。也就是说，分布式系统太麻烦了，无法修改配置。如果将实例部署在容器中以修改配置，则这是一场噩梦。

为了解决此问题，有一个配置中心。配置中心集中管理所有服务的配置。并提供高级别功能，例如配置热更新，权限管理，版本管理和灰色释放。服务启动后，请从本地配置文件中读取配置，但远程读取配置中心的配置。

通用配置中心组件包括：，。

播放广告：这是我开源的轻量级配置中心。

求！

粘合剂

日志是我们不编写程序就无法做的事情。当我们调查问题时，原木就是我们的生命 - 挽救稻草。我们的每种服务都是不断生产日志。但是，在实施微服务之后，如果按照传统文件撰写本地文件的日志方案，显然，它将面临与修改配置的麻烦相同的情况。不同的日志散布在各种服务器和容器中。在这种情况下，检查比死亡更好。

日志聚合组件为我们解决了此问题。所有服务通过接口将日志发送到聚合服务，然后将聚合服务统一存储，以及通过统一查询和分析查询和分析的能力。

对数聚集组件行业的麋鹿相对较重，并且.NET也常用于Seq。

监视服务

由于微服务体系结构带来了系统的复杂性，因此问题通常无法快速找到问题。然后，您目前需要监视系统。监视系统可以在发生故障之前防止问题，并在失败后迅速回顾问题。

微型服务监视通常会划分以下维度的监视：

硬件资源监视

硬件资源是我们实施微服务的基石。 CPU，内存，存储和其他指标需要注意日常生产，否则由于资源耗尽而容易失败。应用程序类监视应用程序，服务和容器的健康监控，并监视呼叫链和界面的性能。这是致电连锁监督的重点。在实施微服务之后，由于复杂的业务逻辑，服务之间的呼叫与蜘蛛网一样复杂。通过呼叫和控制链和控制之间的呼叫，服务之间的呼叫可以显示在图像中。将记录每个请求的性能，响应等。这对于早期预防和调查问题具有重要意义。

这种监测相对接近我们的研发同学。常用的组件包括重量级APM，轻量级。操作类别监视

这种监视主要与业务有关。经营的学生更加担心。例如，每天监视水流，每天注册的会员人数，张开券等等。

微服务有许多组成部分。这是一些常用的组件，其他组件不会说更多。尽管如此，这些组件仍然是为了更好地实施微服务，而不需要看到这种情况。当您在实施微服务过程中找到一个疼痛点时，您会自然会找到相应的解决方案和组件来解决它。

总结

通过上面的微服务体系结构图，解释了微服务体系结构中常用的分层方案。为什么要分开每一层的意义，为什么要分割它。介绍常用的微服务组件的功能，依此类推。在这一点上，我们应该对微服务架构有更全面的了解。但是请记住，在架构中没有固定的模板，您可以根据自己的情况将级别分配，并且可以确定要使用哪些组件。

因此，从下一篇文章的开头，我们必须正式开始使用.NET Core来逐步实现最简单的微服务项目，因此请继续关注。

原始链接：