.NetCore之微服务

目录

前言

什么是微服务

微服务的优势

微服务的原则

创建项目

在Docker中运行服务

 客户端调用

简单的集群服务

前言
写这篇文章旨在用最简单的代码阐述一下微服务

什么是微服务
微服务描述了从单独可部署的服务构建分布式应用程序的体系结构流程，同时这些服务会执行特定业务功能并通过 Web 接口进行通信，DevOps 团队通过将微服务（如构建块）组合在一起，从而将单个功能纳入微服务中以及构建更大的系统。

微服务的优势
微服务采用了某一开放/封闭原则：

它们会开放以便进行扩展（使用它们公开的接口）
它们会关闭以便进行修改（每个修改都会独立执行并进行版本控制）
微服务为整体体系结构提供了众多优势：

它们可以通过确保一个服务中的问题不会崩溃或影响应用程序的其他部分来移除单一故障点 (SPOF)。
可独立扩展单个微服务，以提供额外的可用性和容量。
DevOps 团队可通过添加新微服务来扩展功能，而无需不必要的影响应用程序的其他部分。
使用微服务可提高团队速度。微服务通过允许软件开发团队利用事件驱动的编程和自动缩放等场景，很好地补充基于云的应用程序体系结构。 微服务组件通常会通过 REST 协议公开 API（应用程序编程接口），以便与其他服务通信。

微服务的原则
        顾名思义，微服务体系结构是一种将服务器应用程序生成为一组小型服务的方法。 这意味着微服务体系结构主要面向后端，虽然该方法也会用于前端。 每个服务都在自己的进程中运行，并使用 HTTP/HTTPS、WebSocket 或 AMQP 等协议与其他进程进行通信。 每个微服务在特定的上下文边界内实现特定的端到端域或业务功能，每个微服务都必须自主开发，并且可以独立部署。 最后，每个微服务都应拥有其自己的相关域数据模型和域逻辑（主权和分散式数据管理），并且可以基于不同的数据存储技术（SQL、NoSQL）和不同的编程语言。

        微服务应该有多大？ 在开发微服务时，大小不应成为重点。 相反，重点应该是创建松散耦合的服务以便自主地为每个服务进行开发、部署和缩放。 当然，在标识和设计微服务时，只要与其他微服务不存在过多的直接依赖项，就应尝试让它们尽可能地小。 比微服务的大小更重要的是，它必须具有内部内聚，并且独立于其他服务。

创建项目
 我们在项目中新建两个文件夹，Client跟Service。Client文件夹用于管理我们的客户端，Service文件夹用于管理我们的Api.

项目结构目录如下：

三个项目都是Asp.Net Core Web API。

我们为ForumProductApi以及ForumOrderApi添加一些基础代码，我们返回接口名称以及当前时间，服务的IP地址，端口等信息，以让我们更好的区分接口。

我们修改OrderApi的代码如下：

[ApiController]
[Route("order")]
public class OrderController : ControllerBase
{
    private readonly ILogger _logger;
 
    public OrderController(ILogger logger)
    {
        _logger = logger;
    }
 
    [HttpGet(Name = "GetOrder")]
    public Task GetOrder()
    {
        return Task.FromResult(new OrderEntity()
        {
            date_time = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss"