微服务网关Ocelot
微服務網關是微服務架構中的核心組件,它是客戶端請求的門戶,它是調用具體服務端的橋梁.下面我們將使用開源項目Ocelot（https://github.com/geffzhang/Ocelot）搭建一款輕量級服務網關,不過在此之前我們將對微服務網關做個詳細介紹,以便大家更加清晰的了解什么是微服務網關。
7.1什么是微服務網關
微服務網關類似于經典設計模式的Fa?ade模式，它將底層的復雜細節進行屏蔽，對外提供簡單而統一的調用方式，通常使用HTTP的RESTful API服務。此時，對于客戶端而言，可以是PC端網頁，也可以是移動設備，客戶端通過HTTP方式調用微服務網關。
???????? 微服務網關也稱為服務網關（ServiceGateway）或API網關（API Gateway），下面通過一張架構圖來表達服務網關與客戶端以及服務端的關系。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
我們使用服務網關（Service Gateway）來建立客戶端和服務端之間的聯系。當客戶端發送請求時，請求首先進入服務網關，隨后服務網關將服務請求路由轉發到具體的服務端。在路由的過程中，會涉及到具體的路由算法，最簡單的做法是在服務網關中解析客戶端請求中的路徑或請求頭，從而路由到具體的服務端。
???????? 在微服務模式網站上也對服務網關進行了說明，可以通過以下地址了解API Gateway模式的具體信息。
???????? APIGateway：http://microservices.io/patterns/apigateway.html
???????? 實際上，服務網關的路由過程我們稱之為“反向代理”。如果大家曾經使用過Nginx，對反向代理這個概念不會陌生。說白了就是請求不會直接發送到目的地，而是通過一個中間件進行轉發，這個中間件就是Nginx，它充當了反向代理的角色。
???????? 在什么樣場景下我們會考慮使用反向代理技術呢？
使靜態資源與動態資源分離
實現AJAX跨域訪問
搭建統一服務網關接口
下面我們將使用Ocelet 實現一個服務網關的重要特性之一：反向代理。
?
7.2 使用Ocelot 實現一個反向代理
???????? Ocelot是一個使用.NET Core平臺上的一個API Gateway，這個項目的目標是在.NET上面運行微服務架構，它很好的和Identity Server集成，由Identity Server負責驗證授權。
???????? 使用Ocelot 搭建一個反向代理，僅需要三步：
???????? 第一步，使用VisualStudio 2017 創建一個ASP.NET Core空項目FitApiGateway，通過Nuget安裝Ocelot
Install-PackageOcelot
第二步使用ASP.NET Core應用宿主Ocelot，在Startup.cs中配置，代碼如下：
???publicclassStartup
???{
???????public Startup(IHostingEnvironment env)
???????{
??????????? var builder = newConfigurationBuilder()
???????????????.SetBasePath(env.ContentRootPath)
??????????????? .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
??????????????? .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
???????????????.AddJsonFile("configuration.json")
??????????????? .AddEnvironmentVariables();
?
??????????? Configuration = builder.Build();
???????}
?
???????// This method gets called by theruntime. Use this method to add services to the container.
???????// For more information on how toconfigure your application, visithttps://go.microsoft.com/fwlink/?LinkID=398940
???????publicvoid ConfigureServices(IServiceCollection services)
???????{
??????????? Action<ConfigurationBuilderCachePart> settings = (x) =>
??????????? {
??????????????? x.WithMicrosoftLogging(log=>
??????????????? {
??????????????????? log.AddConsole(LogLevel.Debug);
??????????????? })
??????????????? .WithDictionaryHandle();
??????????? };
?
???????????services.AddOcelotOutputCaching(settings);
???????????services.AddOcelotFileConfiguration(Configuration);
??????????? services.AddOcelot();
???????}
?
???????publicIConfigurationRoot Configuration { get; }
?
???????// This method gets called by theruntime. Use this method to configure the HTTP request pipeline.
???????publicvoid Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
???????{
???????????loggerFactory.AddConsole(Configuration.GetSection("Logging"));
??????????? app.UseOcelot();
???????}
??? }
上面代碼使用json配置作為Ocelot的配置，配置文件的詳細說明參看 https://github.com/TomPallister/Ocelot/blob/develop/configuration-explanation.txt，配置主要分兩部分，路由和全局的配置：
路由是Ocelot的核心配置，Ocelot的核心功能就是將到達的Http請求轉發給下游的服務，目前還只能是Http請求，將來支持其他任何傳輸機制。一條路由規則如下：
{
? "ReRoutes": [
???{
?????"DownstreamPathTemplate": "/api/values",
?????"DownstreamScheme": "http",
?????"DownstreamHost": "localhost",
?????"DownstreamPort": 9030,
?????"UpstreamPathTemplate": "/api/values",
?????"UpstreamHttpMethod": "Get",
?????"FileCacheOptions": { "TtlSeconds": 15 }
???}
?],
?
? "GlobalConfiguration": {
???"RequestIdKey": "OcRequestId",
???"ServiceDiscoveryProvider": {
?????"Provider": "Consul",
?????"Host": "localhost",
?????"Port": 8500
???}
? }
}
DownstreamPathTemplate, DownstreamScheme,DownstreamPort 和DownstreamHost組成請求被轉發的URL，UpstreamPathTemplate是Ocelot 用于識別轉發請求，UpstreamHttpMethod用于識別相同的URL請求的不同操作。可以在模板里使用占位符{something}，要同時出現在DownstreamPathTemplate 和UpstreamPathTemplate.。
Ocelot默認不區分大小寫，可以在配置中指定區分大小寫：
? "ReRouteIsCaseSensitive": true
????????
RequestIdKey
除了記錄訪問記錄外, 在處理每個用戶請求過程中, 涉及業務邏輯處理和后端服務調用等, 對某些操作也需要記錄相應日志和錯誤.對每個請求, 都生成一個唯一的requestID. 在這個請求的生命周期中, 所有打印的日志都會帶上requestID信息，通過RequestI還可以構建Http請求路徑，前端一個請求，可能要經過后端好幾個服務，可以在http頭上加上RequestId和RequestIndex，把這些服務串起來，例如 A->B->C，A服務調用B服務的時候，如果發現http head里面沒有RequestId，則可以通過GuId生成一個，同時RequestIndex加1 ，B服務調用Ｃ服務端時候， 因為RequestId已經有了，就直接傳遞下去，同時RequestIndex加1 ，把這些信息記錄到日志中，通過分析，整個調用就串起來了，通過完整的數據就可以繪制出整個服務的調用鏈路圖。
?
Ocelot從實現上來說就是一系列的中間件組合，在HTTP請求到達Ocelot，經過一系列的中間件的處理轉發到下游的服務。
至此，一個ASP.NET Core 反向代理服務器就搭建完畢，下面我們使用Apache Bench對其性能做個簡單的測試。我們模擬了1000 個用戶，每次并發100個請求，以下是測試結果，機器的配置是CPU：Intel i5 2核， 4G內存的機器上測試：
D:\Workshop\ab>ab.exe -n 1000 -c 100 http://localhost:5800/api/values/
This isApacheBench, Version 2.3 <$Revision: 1757674 $>
Copyright 1996Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to TheApache Software Foundation, http://www.apache.org/
?
Benchmarkinglocalhost (be patient)
Completed 100requests
Completed 200requests
Completed 300requests
Completed 400requests
Completed 500requests
Completed 600requests
Completed 700requests
Completed 800requests
Completed 900requests
Completed 1000requests
Finished 1000requests
?
?
ServerSoftware:??????? Kestrel
ServerHostname:??????? localhost
ServerPort:??????????? 5800
?
DocumentPath:????????? /api/values/
DocumentLength:??????? 19 bytes
?
ConcurrencyLevel:????? 100
Time taken fortests:?? 0.230 seconds
Completerequests:????? 1000
Failedrequests:??????? 0
Totaltransferred:????? 178000 bytes
HTMLtransferred:?????? 19000 bytes
Requests persecond:??? 4345.52 [#/sec] (mean)
Time perrequest:?????? 23.012 [ms] (mean)
Time perrequest:?????? 0.230 [ms] (mean, acrossall concurrent requests)
Transferrate:????????? 755.37 [Kbytes/sec]received
?
Connection Times(ms)
????????????? min? mean[+/-sd] median?? max
Connect:??????? 0???0?? 0.3????? 0??????4
Processing:???? 5??21?? 9.6???? 19?????66
Waiting:??????? 4??18?? 9.8???? 17?????65
Total:????????? 6??21?? 9.6???? 20?????66
?
Percentage ofthe requests served within a certain time (ms)
? 50%????20
? 66%????22
? 75%????27
? 80%????30
? 90%????34
? 95%????39
??98%????44
? 99%????48
?100%????66 (longest request)
?
?可見，平均每秒請求數（吞吐率）為4345.52, 從不同分布下的請求數來看，響應時間也比較平穩, 相比直接訪問接口的性能相差不大。
?
ab.exe -n 1000 -c 100http://localhost:9030/api/values/
This is ApacheBench, Version 2.3 <$Revision:1757674 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.zeustech.net/
Licensed to The Apache Software Foundation,http://www.apache.org/
?
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
?
?
Server Software:??????? Kestrel
Server Hostname:??????? localhost
Server Port:??????????? 9030
?
Document Path:????????? /api/values/
Document Length:??????? 19 bytes
?
Concurrency Level:????? 100
Time taken for tests:?? 0.200 seconds
Complete requests:????? 1000
Failed requests:??????? 0
Total transferred:????? 158000 bytes
HTML transferred:????? ?19000 bytes
Requests per second:??? 5011.40 [#/sec] (mean)
Time per request:?????? 19.954 [ms] (mean)
Time per request:?????? 0.200 [ms] (mean, across all concurrentrequests)
Transfer rate:????????? 773.24 [Kbytes/sec] received
?
Connection Times (ms)
?????????????min? mean[+/-sd] median?? max
Connect:???????0??? 0?? 0.3?????0?????? 1
Processing:????3?? 19?? 3.4????19????? 29
Waiting:???????2?? 13?? 4.8????13????? 25
Total:?????????3?? 19?? 3.4????20????? 29
?
Percentage of the requests served within acertain time (ms)
?50%???? 20
?66%???? 20
?75%???? 21
?80%???? 21
?90%???? 22
?95%???? 23
?98%???? 25
?99%???? 25
?100%????29 (longest request)
?
???????? Asp.netcore的性能絕不亞于Nginx，但擴展性卻遠高于Nginx，我們可以動態的指定被代理的目標地址，而在Nginx中配置的目標地址是靜態的，這一點對于我們將來實現服務發現功能及其重要，因為我們需要從ServiceRegistry中獲取需要代理的微服務信息（例如IP和端口），并執行反向代理操作，調用相應的微服務REST API。
???????? 以上實際上是服務網關的基礎框架，將來我們會在此基礎上進行擴展，實現一個具有反向代理和服務發現的服務網關。當然服務網關并非僅提供反向代理與服務發現特性，此外還需要具備安全認證、性能監控、數據緩存、請求分片、靜態響應等眾多特性，我們可以根據實際情況進行擴展。
相關文章：
API網關Ocelot 使用Polly 處理部分失敗問題
微服務的誤讀與誤解
微服務（Microservices）
Fabio 安裝和簡單使用
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的微服务网关Ocelot的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [认证授权] 2.OAuth2授权（续）
- 下一篇： NuGet社区使用体验调查