使用 Tye 輔助開發 k8s 應用竟如此簡單（二）

續上篇，這篇我們來進一步探索 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 作為其下游服務。

這樣我們便可以驗證服務發現的效果。

然後，使用 Tye.Configuration

新增包

執行以下命令，為 TyeTest 專案新增包：

dotnet add ./TyeTest/TyeTest.csproj package Microsoft.Tye.Extensions.Configuration --version 0.6.0-alpha.21070.5

新增 HttpClientFactory

由於我們需要使用 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" });
      });
  }

使用 HttpClient 呼叫服務

進入 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;
        }
    }
}

值得注意的是：

1. 建構函式中注入的 IConfiguration 是 Aspnet Core 的內在機制，無需特殊註冊。
2. _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 裡面試一下

若要釋出到 k8s 進行測試，只要按照前篇的內容，設定到 docker registry 和 ingress 便可以進行驗證了。

開發者可以自行配置並嘗試。

小結

本篇，我們已經順利完成了使用 Tye 來完成服務發現機制的使用。通過這種方式，我們便可以使用服務名對服務之間進行相互呼叫，從而遮蔽具體的部署細節，簡化開發。

不過，在實際生產實際中，服務之間並非僅僅只有主機和埠兩個資訊。有時還需要進行使用者名稱、密碼和額外引數的設定。典型的就是對資料庫連線字串的管理。

下一篇，我們將進一步在 Tye 中如何對資料庫進行連結。

最後但是最重要！

如果讀者對該內容感興趣，歡迎轉發、評論、收藏文章以及專案。

最近作者正在構建以反應式、Actor模式和事件溯源為理論基礎的一套服務端開發框架。希望為開發者提供能夠便於開發出 “分散式”、“可水平擴充套件”、“可測試性高” 的應用系統 ——Newbe.Claptrap

本篇文章是該框架的一篇技術選文，屬於技術構成的一部分。

聯絡方式：

• Github Issue
• Gitee Issue
• QQ 群 610394020

您還可以查閱本系列的其他選文：

理論入門篇

1. Newbe.Claptrap - 一套以 “事件溯源” 和 “Actor 模式” 作為基本理論的服務端開發框架

術語介紹篇

1. Actor 模式
2. 事件溯源（Event Sourcing）
3. Claptrap
4. Minion
5. 事件 （Event）
6. 狀態 （State）
7. 狀態快照 （State Snapshot）
8. Claptrap 設計圖 （Claptrap Design）
9. Claptrap 工廠 （Claptrap Factory）
10. Claptrap Identity
11. Claptrap Box
12. Claptrap 生命週期（Claptrap Lifetime Scope）
13. 序列化（Serialization）

實現入門篇

1. Newbe.Claptrap 框架入門，第一步 —— 建立專案，實現簡易購物車
2. Newbe.Claptrap 框架入門，第二步 —— 簡單業務，清空購物車
3. Newbe.Claptrap 框架入門，第三步 —— 定義 Claptrap，管理商品庫存
4. Newbe.Claptrap 框架入門，第四步 —— 利用 Minion，商品下單

樣例實踐篇

1. 構建一個簡易的火車票售票系統，Newbe.Claptrap 框架用例，第一步 —— 業務分析
2. 線上體驗火車票售票系統

開發工具篇

1. 使用 Tye 輔助開發 k8s 應用竟如此簡單（一）
2. 使用 Tye 輔助開發 k8s 應用竟如此簡單（二）

其他番外篇

1. 談反應式程式設計在服務端中的應用，資料庫操作優化，從 20 秒到 0.5 秒
2. 談反應式程式設計在服務端中的應用，資料庫操作優化，提速 Upsert
3. 十萬同時線上使用者，需要多少記憶體？——Newbe.Claptrap 框架水平擴充套件實驗
4. docker-mcr 助您全速下載 dotnet 映象
5. 十多位全球技術專家，為你獻上近十個小時的.Net 微服務介紹
6. 年輕的樵夫喲，你掉的是這個免費 8 核 4G 公網伺服器，還是這個隨時可用的 Docker 實驗平臺？
7. 如何使用 dotTrace 來診斷 netcore 應用的效能問題
8. 只要十步，你就可以應用表示式樹來優化動態呼叫

GitHub 專案地址：https://github.com/newbe36524/Newbe.Claptrap

Gitee 專案地址：https://gitee.com/yks/Newbe.Claptrap

您當前檢視的是先行釋出於 www.newbe.pro 上的部落格文章，實際開發文件隨版本而迭代。若要檢視最新的開發文件，需要移步 claptrap.newbe.pro。

------ 本文結束 ------

• 本文作者： newbe36524
• 本文連結： https://www.newbe.pro/Newbe.Claptrap/Try-Tye-2/
• 版權宣告： 本部落格所有文章除特別宣告外，均採用 BY-NC-SA 許可協議。轉載請註明出處！