续上篇,这篇我们来进一步探索 Tye 更多的使用方法。本篇我们来了解一下如何在 Tye 中使用服务发现。
Newbe.Claptrap 是一个用于轻松应对并发问题的分布式开发框架。如果您是首次阅读本系列文章。建议可以先从本文末尾的入门文章开始了解。
服务发现,就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。 《深入了解服务注册与发现》 https://zhuanlan.zhihu.com/p/161277955
我们在调用微服务的过程中,假设在调用某个 REST API 或者 Thrift API, 为了完成某次调用请求,代码里面需要指定服务所在的 IP 地址和端口,在传统的应用中,网络地址和端口是静态的,一般不会改变,我们只需要把它们配到配置文件中,就可以通过读取配置文件来完成调用。但是,在现代基于 Cloud 的微服务架构中,这种方式将失效,因为服务的实例是动态分配的地址,网络地址也是动态的,这样做的好处是便于服务的自动伸缩,失败处理和升级. 《微服务架构中的服务发现机制》 https://www.imooc.com/article/details/id/291255
简单来说,通过服务发现,服务之间可以使用名称来代替具体的地址和端口甚至访问细节。这样可以使得服务更加容易适用于云原生这种应用程序实例多变的环境。
和前篇一样,我们使用命令行来创建两个服务。
dotnet new sln -n TyeTest dotnet new webapi -n TyeTest dotnet sln .\TyeTest.sln add .\TyeTest\TyeTest.csproj dotnet new webapi -n TyeTest2 dotnet sln .\TyeTest.sln add .\TyeTest2\TyeTest2.csproj |
---|
然后使用 tye init
创建 tye.yml
。
便可以在 tye.yml 中得到如下内容:
name: tyetest services: - name: tyetest project: TyeTest/TyeTest.csproj - name: tyetest2 project: TyeTest2/TyeTest2.csproj |
---|
这样我们就可以在本地使用 tye run
启动着两个服务。
接下来,我们会改造其中的 TyeTest 服务,使其调用 TyeTest2 作为其下游服务。
这样我们便可以验证服务发现的效果。
运行以下命令,为 TyeTest 项目添加包:
dotnet add ./TyeTest/TyeTest.csproj package Microsoft.Tye.Extensions.Configuration --version 0.6.0-alpha.21070.5 |
---|
由于我们需要使用 HttpClient 调用下游服务,因此需要使用到 HttpClientFactory。故而,在 TyeTest 项目的 Startup.cs 增加对 HttpClientFactory 的注册。
public void ConfigureServices(IServiceCollection services) { + services.AddHttpClient(); services.AddControllers(); services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo { Title = "TyeTest", Version = "v1" }); }); } |
---|
进入 WeatherForecastController, 我们使用 HttpClient 来调用下游服务,并且将得到的数据返回:
using System; using System.Collections.Generic; using System.Linq; using System.Net.Http; using System.Text.Json; using System.Threading.Tasks; using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Configuration; using Microsoft.Extensions.Logging; namespace TyeTest.Controllers { [ApiController] [Route("[controller]")] public class WeatherForecastController : ControllerBase { private readonly ILogger<WeatherForecastController> _logger; private readonly IConfiguration _configuration; private readonly HttpClient _httpClient; public WeatherForecastController(ILogger<WeatherForecastController> logger, IConfiguration configuration, HttpClient httpClient) { _logger = logger; _configuration = configuration; _httpClient = httpClient; } [HttpGet] public async Task<string> Get() { var serviceUri = _configuration.GetServiceUri("tyetest2"); Console.WriteLine(serviceUri); var httpResponseMessage = await _httpClient.GetAsync($"{serviceUri}WeatherForecast"); var json = await httpResponseMessage.Content.ReadAsStringAsync(); return json; } } } |
---|
值得注意的是:
IConfiguration
是 Aspnet Core 的内在机制,无需特殊注册。_configuration.GetServiceUri("tyetest2")
是本示例的关键点。其通过一个服务名称来获取服务的具体 Uri 地址,这样便可以屏蔽部署时,服务地址的细节。这样,就结束了。
接下来只要使用 tye run
便可以在本地查看已经改造好的服务。调用第一个服务的接口,并可以得到预期的从第二个服务返回的数据。
关于 Tye 中服务发现的真实运作机制可以前往官方文库进行了解: https://github.com/dotnet/tye/blob/master/docs/reference/service_discovery.md#how-it-works-uris-in-development
若要发布到 k8s 进行测试,只要按照前篇的内容,设置到 docker registry 和 ingress 便可以进行验证了。
开发者可以自行配置并尝试。
本篇,我们已经顺利完成了使用 Tye 来完成服务发现机制的使用。通过这种方式,我们便可以使用服务名对服务之间进行相互调用,从而屏蔽具体的部署细节,简化开发。
不过,在实际生产实际中,服务之间并非仅仅只有主机和端口两个信息。有时还需要进行用户名、密码和额外参数的设置。典型的就是对数据库连接字符串的管理。
下一篇,我们将进一步在 Tye 中如何对数据库进行链接。
如果读者对该内容感兴趣,欢迎转发、评论、收藏文章以及项目。
最近作者正在构建以反应式
、Actor模式
和事件溯源
为理论基础的一套服务端开发框架。希望为开发者提供能够便于开发出 “分布式”、“可水平扩展”、“可测试性高” 的应用系统 ——Newbe.Claptrap
本篇文章是该框架的一篇技术选文,属于技术构成的一部分。
联系方式:
您还可以查阅本系列的其他选文:
理论入门篇
术语介绍篇
实现入门篇
样例实践篇
开发工具篇
其他番外篇
GitHub 项目地址:https://github.com/newbe36524/Newbe.Claptrap
Gitee 项目地址:https://gitee.com/yks/Newbe.Claptrap
您当前查看的是先行发布于 www.newbe.pro 上的博客文章,实际开发文档随版本而迭代。若要查看最新的开发文档,需要移步 claptrap.newbe.pro。
------ 本文结束 ------
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。