前言

写这篇博客主要目的是记录一下自己的学习过程,只能是简单入门级别的,因为水平有限就写到哪算哪吧,写的不对之处欢迎指正。

什么是微服务?

关于微服务的概念解释网上有很多...

个人理解,微服务是一种系统架构模式,它和语言无关,和框架无关,和工具无关,和服务器环境无关...

微服务思想是将传统的单体系统按照业务拆分成多个职责单一、且可独立运行的接口服务,各个服务之间不耦合。至于服务如何拆分,没有明确的定义。

几乎任何后端语言都能做微服务开发。

创建项目



一个客户端,一个产品服务,一个订单服务。3个项目都是asp.net core web应用程序。创建项目的时候记得启用一下Docker支持,或者后面添加也行。

为产品、订单服务添加一些基础代码,就简单的返回一下 服务名称,当前时间,服务的ip、端口。

在Docker中运行服务

为了方便,我使用Docker来运行服务,不用Docker也行,关于docker的安装及基本使用就不介绍了。

  • build镜像:

在项目根目录打开PowerShell窗口执行:docker build -t productapi -f ./Product.API/Dockerfile .





Successfully代表build成功了。

  • 运行容器:

执行:docker run -d -p 9050:80 --name productservice productapi

执行:docker ps查看运行的容器:

没问题,使用浏览器访问一下接口:



也没问题,其中的ip端口是Docker容器内部的ip端口,所以端口是80,这个无所谓。

  • 产品服务部署好了,下面部署一下订单服务,也是同样的流程,就把指令简单贴一下吧:

build镜像:docker build -t orderapi -f ./Order.API/Dockerfile .

运行容器:docker run -d -p 9060:80 --name orderservice orderapi

浏览器访问一下:



OK,订单服务也部署完成了。

客户端调用

客户端我这里只做了一个web客户端,实际可能是各种业务系统、什么PC端、手机端、小程序。。。这个明白就好,为了简单就不搞那么多了。

  • 因为客户端需要http请求服务端接口,所以需要一个http请求客户端,我个人比较习惯RestSharp,安利一波:https://github.com/restsharp/RestSharp

  • 添加基础代码:

IServiceHelper.cs:

    public interface IServiceHelper
{
/// <summary>
/// 获取产品数据
/// </summary>
/// <returns></returns>
Task<string> GetProduct(); /// <summary>
/// 获取订单数据
/// </summary>
/// <returns></returns>
Task<string> GetOrder();
}

ServiceHelper.cs:

    public class ServiceHelper : IServiceHelper
{
public async Task<string> GetOrder()
{
string serviceUrl = "http://localhost:9060";//订单服务的地址,可以放在配置文件或者数据库等等... var Client = new RestClient(serviceUrl);
var request = new RestRequest("/orders", Method.GET); var response = await Client.ExecuteAsync(request);
return response.Content;
} public async Task<string> GetProduct()
{
string serviceUrl = "http://localhost:9050";//产品服务的地址,可以放在配置文件或者数据库等等... var Client = new RestClient(serviceUrl);
var request = new RestRequest("/products", Method.GET); var response = await Client.ExecuteAsync(request);
return response.Content;
}
}

Startup.cs:

    public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
} public IConfiguration Configuration { get; } // This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews(); //注入IServiceHelper
services.AddSingleton<IServiceHelper, ServiceHelper>();
} // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
}
}

HomeController.cs:

    public class HomeController : Controller
{
private readonly ILogger<HomeController> _logger;
private readonly IServiceHelper _serviceHelper; public HomeController(ILogger<HomeController> logger, IServiceHelper serviceHelper)
{
_logger = logger;
_serviceHelper = serviceHelper;
} public async Task<IActionResult> Index()
{
ViewBag.OrderData = await _serviceHelper.GetOrder();
ViewBag.ProductData = await _serviceHelper.GetProduct(); return View();
} public IActionResult Privacy()
{
return View();
} [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}

Index.cshtml:

@{
ViewData["Title"] = "Home Page";
} <div class="text-center">
<h1 class="display-4">Welcome</h1>
<p>
@ViewBag.OrderData
</p>
<p>
@ViewBag.ProductData
</p>
</div>

代码比较简单,这里就不用docker了,直接控制台启动,使用浏览器访问:

  • 一切正常。进行到这里,各个服务也独立运行了,客户端也能正常调用了,貌似算是完成一个简易的微服务了。但是,微服务架构最重要的原则就是——“高可用”。以上的做法明显不能满足高可用性,因为任何一个服务挂掉,所有依赖这个服务的业务系统都会受影响。

停止一下订单服务:docker stop orderservice





订单服务停止,导致客户端业务系统无法获取订单数据。

要解决这个问题,很容易想到:集群。

简单的服务集群

既然单个服务实例有挂掉的风险,那么部署多个服务实例就好了嘛,只要大家不同时全挂就行。

  • 使用docker运行多个服务实例:

    docker run -d -p 9061:80 --name orderservice1 orderapi

    docker run -d -p 9062:80 --name orderservice2 orderapi

    docker run -d -p 9051:80 --name productservice1 productapi

    docker run -d -p 9052:80 --name productservice2 productapi

现在订单服务和产品服务都增加到3个服务实例。

  • 那么稍微改造一下客户端代码吧:

    ServiceHelper.cs:
public class ServiceHelper : IServiceHelper
{
public async Task<string> GetOrder()
{
string[] serviceUrls = { "http://localhost:9060", "http://localhost:9061", "http://localhost:9062" };//订单服务的地址,可以放在配置文件或者数据库等等... //每次随机访问一个服务实例
var Client = new RestClient(serviceUrls[new Random().Next(0, 3)]);
var request = new RestRequest("/orders", Method.GET); var response = await Client.ExecuteAsync(request);
return response.Content;
} public async Task<string> GetProduct()
{
string[] serviceUrls = { "http://localhost:9050", "http://localhost:9051", "http://localhost:9052" };//产品服务的地址,可以放在配置文件或者数据库等等... //每次随机访问一个服务实例
var Client = new RestClient(serviceUrls[new Random().Next(0, 3)]);
var request = new RestRequest("/products", Method.GET); var response = await Client.ExecuteAsync(request);
return response.Content;
}
}

当然拿到这些服务地址可以自己做复杂的负载均衡策略,比如轮询,随机,权重等等 都行,甚至在中间弄个nginx也可以。这些不是重点,所以就简单做一个随机吧,每次请求来了随便访问一个服务实例。

  • 浏览器测试一下:



    可以看到请求被随机分配了。但是这种做法依然不安全,如果随机访问到的实例刚好挂掉,那么业务系统依然会出问题。

    简单处理思路是:

    1.如果某个地址请求失败了,那么换一个地址接着执行。

    2.如果某个地址的请求连续多次失败了,那么就移除这个地址,下次就不会访问到它了。

    。。。。。。

    业务系统实现以上逻辑,基本上风险就很低了,也算是大大增加了系统可用性了。

  • 然后思考另一个问题:

实际应用中,上层的业务系统可能非常多,为了保证可用性,每个业务系统都去考虑服务实例挂没挂掉吗?

而且实际应用中服务实例的数量或者地址大多是不固定的,例如双十一来了,流量大了,增加了一堆服务实例,这时候每个业务系统再去配置文件里配置一下这些地址吗?双十一过了又去把配置删掉吗?显然是不现实的,服务必须要做到可灵活伸缩。

  • 这时候就引入一个名词:服务注册与发现

未完待续...

.Net Core微服务入门全纪录(一)——项目搭建的更多相关文章

  1. .Net Core微服务入门全纪录(二)——Consul-服务注册与发现(上)

    前言 上一篇[.Net Core微服务入门全纪录(一)--项目搭建]讲到要做到服务的灵活伸缩,那么需要有一种机制来实现它,这个机制就是服务注册与发现.当然这也并不是必要的,如果你的服务实例很少,并且很 ...

  2. .Net Core微服务入门全纪录(三)——Consul-服务注册与发现(下)

    前言 上一篇[.Net Core微服务入门全纪录(二)--Consul-服务注册与发现(上)]已经成功将我们的服务注册到Consul中,接下来就该客户端通过Consul去做服务发现了. 服务发现 同样 ...

  3. .Net Core微服务入门全纪录(四)——Ocelot-API网关(上)

    前言 上一篇[.Net Core微服务入门全纪录(三)--Consul-服务注册与发现(下)]已经使用Consul完成了服务的注册与发现,实际中光有服务注册与发现往往是不够的,我们需要一个统一的入口来 ...

  4. .Net Core微服务入门全纪录(五)——Ocelot-API网关(下)

    前言 上一篇[.Net Core微服务入门全纪录(四)--Ocelot-API网关(上)]已经完成了Ocelot网关的基本搭建,实现了服务入口的统一.当然,这只是API网关的一个最基本功能,它的进阶功 ...

  5. .Net Core微服务入门全纪录(六)——EventBus-事件总线

    前言 上一篇[.Net Core微服务入门全纪录(五)--Ocelot-API网关(下)]中已经完成了Ocelot + Consul的搭建,这一篇简单说一下EventBus. EventBus-事件总 ...

  6. .Net Core微服务入门全纪录(七)——IdentityServer4-授权认证

    前言 上一篇[.Net Core微服务入门全纪录(六)--EventBus-事件总线]中使用CAP完成了一个简单的Eventbus,实现了服务之间的解耦和异步调用,并且做到数据的最终一致性.这一篇将使 ...

  7. .Net Core微服务入门全纪录(八)——Docker Compose与容器网络

    Tips:本篇已加入系列文章阅读目录,可点击查看更多相关文章. 前言 上一篇[.Net Core微服务入门全纪录(七)--IdentityServer4-授权认证]中使用IdentityServer4 ...

  8. .Net Core微服务入门全纪录(完结)——Ocelot与Swagger

    Tips:本篇已加入系列文章阅读目录,可点击查看更多相关文章. 前言 上一篇[.Net Core微服务入门全纪录(八)--Docker Compose与容器网络]完成了docker-compose.y ...

  9. 【新书推荐】《ASP.NET Core微服务实战:在云环境中开发、测试和部署跨平台服务》 带你走近微服务开发

    <ASP.NET Core 微服务实战>译者序:https://blog.jijiechen.com/post/aspnetcore-microservices-preface-by-tr ...

随机推荐

  1. 【python----发轫之始】【基础知识总结】

    python基础知识总结 一.自学感受 学完之后,,,感觉脑子里全是乱的,单词这么多,都要分不清什么时候该用什么,他到底属于哪一个数据类型里的函数,,,,,, 所以,我想着把笔记整理一下,方便自己和需 ...

  2. python3.x 基础三:装饰器

    装饰器:本质是函数,用于装饰其他函数,在不改变其他函数的调用和代码的前提下,增加新功能 原则: 1.不能修改被装饰函数的源代码 2.不能修改被装饰函数的调用方式 3.装饰函数对于被装饰函数透明 参考如 ...

  3. 接上一篇:vue零基础入门记录

    上一篇的vue项目已经搭建运行了起来,我用惯了idea这里也用的idea打开的项目.貌似其他软件写前端更好. 打开项目的项目路径是这样的 写惯了后台,第一眼看的时候感觉这个项目路径很乱,后面才知道我们 ...

  4. 苏浪浪 201771010120 面向对象程序设计(Java)第13周

    /实验十三  图形界面事件处理技术 1.实验目的与要求 (1) 掌握事件处理的基本原理,理解其用途: (2) 掌握AWT事件模型的工作机制: (3) 掌握事件处理的基本编程模型: (4) 了解GUI界 ...

  5. UVALive 3295

    题目大意:见刘汝佳<算法竞赛入门经典——训练指南>P173 解题思路: 每一个合法的三角形的三个顶点都不在同一直线上,那么问题其实就是在求所有不全在同一直线上的三点的组合数. 我们可以利用 ...

  6. 【MySQL】索引的本质(B+Tree)解析

    索引是帮助MySQL高效获取数据的排好序的数据结构. 索引数据结构 二叉树 红黑树 Hash表 B-Tree MySQL所使用为B+Tree (B-Tree变种) 非叶子节点不存储data,只存储索引 ...

  7. 一次 nginx 返回 302 问题解决

    1.问题描述: 应用服务器通过post方式向nginx服务器发送http请求,返回 302 2.问题解决过程 2.1.查询nginx日志,开始以为302错误会在nginx的错误日志error.log, ...

  8. Unity自定义Log

    有如下两种方式,第一种借助了Unity自身的LogType枚举型:第二种则是纯粹地自己定义: public class Log { public Log(string message, UnityEn ...

  9. Flink kuduSink开发

    1.继承RichSinkFunction (1)首先在构造方式传入kudu的masterAddress地址.默认表名.TableSerializationSchema.KuduTableRowConv ...

  10. dsPIC33EP单片机的PPS(外设引脚选择)

    利用dsPIC33EP单片机进行can通信的时候用到引脚复用 引脚复用通过查询数据手册: C1RX的寄存器为RPINR26.C1RXR=(设置为需要用到的引脚) 引脚设置为输入(C1RX),TRIS= ...