.Net Core微服务入门全纪录(一)——项目搭建

内容纲要

前言

写这篇博客主要目的是记录一下自己的学习过程,只能是简单入门级别的,因为水平有限就写到哪算哪吧,写的不对之处欢迎指正。
代码放在:https://cfiles.51aspx.com/wp-content/uploads/2022/05/20220517195850875.zip

什么是微服务?

关于微服务的概念解释网上有很多...
个人理解,微服务是一种系统架构模式,它和语言无关,和框架无关,和工具无关,和服务器环境无关...
微服务思想是将传统的单体系统按照业务拆分成多个职责单一、且可独立运行的接口服务。至于服务如何拆分,没有明确的定义。
几乎任何后端语言都能做微服务开发。
微服务也并不是完美无缺的,微服务架构会带来更多的问题,增加系统的复杂度,引入更多的技术栈...

创建项目

20220517224818707

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

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

20220517224819940
20220517224819935

在Docker中运行服务

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

  • build镜像:

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

20220517224819503
20220517224819457

Successfully代表build成功了。

  • 运行容器:

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

20220517224820945

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

20220517224820127

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

20220517224820159

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

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

build镜像:docker build -t orderapi -f ./Order.API/Dockerfile .
运行容器:docker run -d -p 9060:80 --name orderservice orderapi
浏览器访问一下:

20220517224821447

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

客户端调用

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

20220517224821178
  • 添加基础代码:
20220517224821347

IServiceHelper.cs:

  1. public interface IServiceHelper
  2. {
  3. /// <summary>
  4. /// 获取产品数据
  5. /// </summary>
  6. /// <returns></returns>
  7. Task<string> GetProduct();
  8. /// <summary>
  9. /// 获取订单数据
  10. /// </summary>
  11. /// <returns></returns>
  12. Task<string> GetOrder();
  13. }

ServiceHelper.cs:

  1. public class ServiceHelper : IServiceHelper
  2. {
  3. public async Task<string> GetOrder()
  4. {
  5. string serviceUrl = "http://localhost:9060";//订单服务的地址,可以放在配置文件或者数据库等等...
  6. var Client = new RestClient(serviceUrl);
  7. var request = new RestRequest("/orders", Method.GET);
  8. var response = await Client.ExecuteAsync(request);
  9. return response.Content;
  10. }
  11. public async Task<string> GetProduct()
  12. {
  13. string serviceUrl = "http://localhost:9050";//产品服务的地址,可以放在配置文件或者数据库等等...
  14. var Client = new RestClient(serviceUrl);
  15. var request = new RestRequest("/products", Method.GET);
  16. var response = await Client.ExecuteAsync(request);
  17. return response.Content;
  18. }
  19. }

Startup.cs:

  1. public class Startup
  2. {
  3. public Startup(IConfiguration configuration)
  4. {
  5. Configuration = configuration;
  6. }
  7. public IConfiguration Configuration { get; }
  8. // This method gets called by the runtime. Use this method to add services to the container.
  9. public void ConfigureServices(IServiceCollection services)
  10. {
  11. services.AddControllersWithViews();
  12. //注入IServiceHelper
  13. services.AddSingleton<IServiceHelper, ServiceHelper>();
  14. }
  15. // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
  16. public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
  17. {
  18. if (env.IsDevelopment())
  19. {
  20. app.UseDeveloperExceptionPage();
  21. }
  22. else
  23. {
  24. app.UseExceptionHandler("/Home/Error");
  25. }
  26. app.UseStaticFiles();
  27. app.UseRouting();
  28. app.UseAuthorization();
  29. app.UseEndpoints(endpoints =>
  30. {
  31. endpoints.MapControllerRoute(
  32. name: "default",
  33. pattern: "{controller=Home}/{action=Index}/{id?}");
  34. });
  35. }
  36. }

HomeController.cs:

  1. public class HomeController : Controller
  2. {
  3. private readonly ILogger<HomeController> _logger;
  4. private readonly IServiceHelper _serviceHelper;
  5. public HomeController(ILogger<HomeController> logger, IServiceHelper serviceHelper)
  6. {
  7. _logger = logger;
  8. _serviceHelper = serviceHelper;
  9. }
  10. public async Task<IActionResult> Index()
  11. {
  12. ViewBag.OrderData = await _serviceHelper.GetOrder();
  13. ViewBag.ProductData = await _serviceHelper.GetProduct();
  14. return View();
  15. }
  16. public IActionResult Privacy()
  17. {
  18. return View();
  19. }
  20. [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
  21. public IActionResult Error()
  22. {
  23. return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
  24. }
  25. }

Index.cshtml:

  1. @{
  2. ViewData["Title"] = "Home Page";
  3. }
  4. <div class="text-center">
  5. <h1 class="display-4">Welcome</h1>
  6. <p>
  7. @ViewBag.OrderData
  8. </p>
  9. <p>
  10. @ViewBag.ProductData
  11. </p>
  12. </div>

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

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

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

20220517224822453
20220517224822466

订单服务停止,导致客户端业务系统无法获取订单数据。
要解决这个问题,很容易想到:集群。

简单的服务集群

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

  • 使用docker运行多个服务实例:
  1. docker run -d -p 9061:80 --name orderservice1 orderapi
  2. docker run -d -p 9062:80 --name orderservice2 orderapi
  3. docker run -d -p 9051:80 --name productservice1 productapi
  4. docker run -d -p 9052:80 --name productservice2 productapi

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

  • 那么稍微改造一下客户端代码吧:
    ServiceHelper.cs:
  1. public class ServiceHelper : IServiceHelper
  2. {
  3. public async Task<string> GetOrder()
  4. {
  5. string[] serviceUrls = { "http://localhost:9060", "http://localhost:9061", "http://localhost:9062" };//订单服务的地址,可以放在配置文件或者数据库等等...
  6. //每次随机访问一个服务实例
  7. var Client = new RestClient(serviceUrls[new Random().Next(0, 3)]);
  8. var request = new RestRequest("/orders", Method.GET);
  9. var response = await Client.ExecuteAsync(request);
  10. return response.Content;
  11. }
  12. public async Task<string> GetProduct()
  13. {
  14. string[] serviceUrls = { "http://localhost:9050", "http://localhost:9051", "http://localhost:9052" };//产品服务的地址,可以放在配置文件或者数据库等等...
  15. //每次随机访问一个服务实例
  16. var Client = new RestClient(serviceUrls[new Random().Next(0, 3)]);
  17. var request = new RestRequest("/products", Method.GET);
  18. var response = await Client.ExecuteAsync(request);
  19. return response.Content;
  20. }
  21. }

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

  • 浏览器测试一下:
20220517224823469
  • 可以看到请求被随机分配了。但是这种做法依然不安全,如果随机访问到的实例刚好挂掉,那么业务系统依然会出问题。
    简单处理思路是:
    1.如果某个地址请求失败了,那么换一个地址接着执行。
    2.如果某个地址的请求连续多次失败了,那么就移除这个地址,下次就不会访问到它了。
    。。。。。。
    业务系统实现以上逻辑,基本上风险就很低了,也算是大大增加了系统可用性了。
  • 然后思考另一个问题:

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

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

快速了解 ASP.NET Core Blazor

2022-5-11 18:21:11

.Net Core

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

2022-5-17 14:38:35

0 条回复 A文章作者 M管理员
欢迎您,新朋友,感谢参与互动!
    暂无讨论,说说你的看法吧
个人中心
今日签到
私信列表
搜索