1. 程式人生 > >spring cloud+.net core搭建微服務架構:Api閘道器(三)

spring cloud+.net core搭建微服務架構:Api閘道器(三)

前言

國慶假期,一直沒有時間更新。
根據群裡面的同學的提問,強烈推薦大家先熟悉下spring cloud。文章下面有純潔大神的spring cloud系列。
上一章最後說了,因為服務是不對外暴露的,所以在外網要訪問服務必須通過API閘道器來完成,而spring cloud 提供了現成的Api閘道器元件zuul。它包含了路由,授權,壓力測試等一系列功能。如下圖所示,Api閘道器在整個應用環境的位置。
image

業務場景

我們先模擬一個業務場景,客戶端(web,ios,android...)通過Api閘道器訪問訂單服務,訂單服務有兩個節點,為了模擬叢集效果,這兩個節點分別返回不同的資料。那麼我們一共需要建立4個應用程式。服務中心(Java)、Api閘道器(Java)、訂單服務1(.NET Core)、訂單服務2(.NET Core)。

程式碼部分

服務中心

使用intellij idea建立一個spring boot專案,建立服務中心。設定埠為5000。
pom.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

ServiceCenterApplication.java

@EnableEurekaServer
@SpringBootApplication
public class ServiceCenterApplication {

    public static void main(String[] args) {
        SpringApplication.run(ServiceCenterApplication.class, args);
    }
}

application.properties

spring.application.name=service-center
server.port=5000

Api閘道器

使用intellij idea建立一個spring boot專案,建立Api閘道器服務。設定埠為5555。
pom.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>

ServiceGatewayApplication.java

@SpringBootApplication
@EnableZuulProxy
public class ServiceGatewayApplication {

    public static void main(String[] args) {
        SpringApplication.run(ServiceGatewayApplication.class, args);
    }
}

application.properties

spring.application.name=service-gateway
server.port=5555
eureka.client.serviceUrl.defaultZone=http://localhost:5000/eureka/

#下面的程式碼可以註釋
zuul.routes.order.path=/order/**
zuul.routes.order.serviceId=order

上面配置是不是和nginx很像。zuul還提供了預設規則,http://ZUUL_HOST:ZUUL_PORT/serviceId/**,滿足這一規則的會自動代理,如上面的配置完全可以不用寫,這樣大量的服務就不用一個一個配置了。

訂單服務1

使用vs2017建立 .NET Core Web Api應用程式

appsettings.json
{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "spring": {
    "application": {
      "name": "order"
    }
  },
  "eureka": {
    "client": {
      "serviceUrl": "http://localhost:5000/eureka/"
    },
    "instance": {
      "port": 8010
    }
  }
}
ValuesController.cs
[Route("/")]
public class ValuesController : Controller
{
    [HttpGet]
    public string Get()
    {
        return "order1";
    }
}

訂單服務2

同訂單服務1的建立過程,修改埠為8011和返回結果。

appsettings.json
{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "spring": {
    "application": {
      "name": "order"
    }
  },
  "eureka": {
    "client": {
      "serviceUrl": "http://localhost:5000/eureka/"
    },
    "instance": {
      "port": 8011
    }
  }
}
ValuesController.cs
[Route("/")]
public class ValuesController : Controller
{
    [HttpGet]
    public string Get()
    {
        return "order2";
    }
}

篇幅有限,以上程式碼均有精簡,完整程式碼請去Github上獲取。

我們現在一共有4個應用程式:

  1. eureka服務中心,埠5000,應用名稱service-center
  2. zuul閘道器服務,埠5555,應用名稱service-gateway
  3. 訂單服務1,埠8010,應用名稱order
  4. 訂單服務2,埠8011,應用名稱order

其中訂單服務1和訂單服務2組成了訂單服務叢集

分別啟動這4個應用程式。開啟eureka服務:http://localhost:5000/,
如下圖所示都註冊成功。

image

開啟http://localhost:5555/order,返回"order1"

image

重新整理後返回"order2",反覆多次重新整理,"order1"和"order2"依次返回。

image

後記

通過上面的例子說明Api閘道器服務已經生效,並且實現了負載均衡。結合具體的業務場景,我們的生產環境只對外暴露5555埠,客戶端訪問Api閘道器,由Api閘道器去路由到各個服務節點,這樣所有的客戶端呼叫都統一了入口。

示例程式碼

所有程式碼均上傳github。程式碼按照章節的順序上傳,例如第一章demo1,第二章demo2以此類推。
求推薦,你們的支援是我寫作最大的動力,我的QQ群:328438252,交流微服務。

傳送門

參考資料

java部分

.net部分

相關推薦

spring cloud+.net core搭建服務架構Api

前言 國慶假期,一直沒有時間更新。 根據群裡面的同學的提問,強烈推薦大家先熟悉下spring cloud。文章下面有純潔大神的spring cloud系列。 上一章最後說了,因為服務是不對外暴露的,所以在外網要訪問服務必須通過API閘道器來完成,而spring cloud 提供了現成的Api閘道器元件zuul

spring cloud+dotnet core搭建服務架構Api

前言 國慶假期,一直沒有時間更新。 根據群裡面的同學的提問,強烈推薦大家先熟悉下spring cloud。文章下面有純潔大神的spring cloud系列。 上一章最後說了,因為服務是不對外暴露的,所以在外網要訪問服務必須通過API閘道器來完成,而spring cloud 提供了現成的Api閘道器元件z

spring cloud+.net core搭建服務架構服務註冊

背景 公司去年開始使用dotnet core開發專案。公司的總體架構採用的是微服務,那時候由於對微服務的理解並不是太深,加上各種元件的不成熟,只是把專案的各個功能通過業務層面拆分,然後通過nginx代理,專案最終上線。但是這遠遠沒達到微服務的要求,其中服務治理,斷路器都沒有。我個人理解,我們談微服務實際上更多

spring cloud+.net core搭建服務架構服務發現

前言 上篇文章實際上只講了服務治理中的服務註冊,服務與服務之間如何呼叫呢?傳統的方式,服務A呼叫服務B,那麼服務A訪問的是服務B的負載均衡地址,通過負載均衡來指向到服務B的真實地址,上篇文章已經說了這種方式的缺點。那麼下面講如何在spring cloud+dotnet core的應用下進行服務呼叫。 程式碼實

spring cloud+.net core搭建服務架構配置中心

前言 我們專案中有很多需要配置的地方,最常見的就是各種服務URL地址,這些地址針對不同的執行環境還不一樣,不管和打包還是部署都麻煩,需要非常的小心。一般配置都是儲存到配置檔案裡面,不管多小的配置變動,都需要對應用程式進行重啟,對於分散式系統來說,這是非常不可取的。所以配置中心就在這種場景孕育出來,能夠適配不同

跟著園內spring cloud+.net core搭建服務架構 服務消費出錯問題

bubuko product xxx alt 我沒 .dll 端口 sin 無法 http://www.cnblogs.com/longxianghui/p/7561259.html 最近在跟隨著園區內的這個博客做服務發現的時候,發覺在vs 上調整了端口

手把手教你使用spring cloud+dotnet core搭建服務架構 服務治理-

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!        

spring cloud + .net core實現服務架構

1.新建spring boot專案 2.新增spring-cloud-starter-eureka-server依賴(需提供版本資訊) <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-star

談談服務中的 API API Gateway

前言 又是很久沒寫部落格了,最近一段時間換了新工作,比較忙,所以沒有抽出來太多的時間寫給關注我的粉絲寫一些乾貨了,就有人問我怎麼最近沒有更新部落格了,在這裡給大家抱歉。 那麼,在本篇文章中,我們就一起來探討一下 API 閘道器在整個微服務分散式架構中的一個作用。 背景 我們知道在微服務架構風格中,一個大應用被

Spring Cloud Alibaba+Nacos搭建服務架構

1. Spring Cloud Alibaba 簡介    Spring Cloud Alibaba是阿里巴巴為分散式應用提供的一站式解決方案,能夠更方便快捷地搭建分散式平臺,nacos擁有著替換eureka server ,spring cloud config等元件的目標和意圖,旨在能夠更簡便快速地去管理

.Net Core服務入門全紀錄——Ocelot-API

# 前言 上一篇【[.Net Core微服務入門全紀錄(三)——Consul-服務註冊與發現(下)](https://www.cnblogs.com/xhznl/p/13096891.html)】已經使用Consul完成了服務的註冊與發現,實際中光有服務註冊與發現往往是不夠的,我們需要一個統一的入口來連線客戶

.Net Core服務入門全紀錄——Ocelot-API

# 前言 上一篇【[.Net Core微服務入門全紀錄(四)——Ocelot-API閘道器(上)](https://www.cnblogs.com/xhznl/p/13092535.html)】已經完成了Ocelot閘道器的基本搭建,實現了服務入口的統一。當然,這只是API閘道器的一個最基本功能,它的進階功能

認證鑑權與API許可權控制在服務架構中的設計與實現

引言: 本文系《認證鑑權與API許可權控制在微服務架構中的設計與實現》系列的第三篇,本文重點講解token以及API級別的鑑權。本文對涉及到的大部分程式碼進行了分析,歡迎訂閱本系列文章。 1. 前文回顧 在開始講解這一篇文章之前,先對之前兩篇文章進行回憶下。在第一篇 認證鑑權與AP

服務架構中整合、許可權服務

前言:之前的文章有講過微服務的許可權系列和閘道器實現,都是孤立存在,本文將整合後端服務與閘道器、許可權系統。安全許可權部分的實現還講解了基於前置驗證的方式實現,但是由於與業務聯絡比較緊密,沒有具體的示例。業務許可權與業務聯絡非常密切,本次的整合專案將會把這部分的操作許可權校驗

服務架構下的資料一致性保證補償模式

在微服務架構下,一個典型的業務操作往往由一系列自治的微服務步驟組成,如果某個步驟發生了業務異常(比如支付時賬戶餘額不足等)時就出現了資料不一致。我們採用補償模式來撤銷已經完成的步驟,從而實現最終一致性。 今天分享的還是關於微服務架構下的資料一致性保證的話題,是資料一

360搜尋在服務架構下的技術平臺實踐 -- Thor

為什麼要做Thor? 360搜尋有多個團隊,幾百號人。每個團隊各自有多個平臺工具,但各團隊各自為戰,帶來的問題是沒有統一的開發、管理規範,不論是交接還是擴充套件,做的人都很痛苦。當老人離開,新人接手會掉入無盡的坑中 Thor的目標 重新定義工具&

Spring Cloud 系列之 Gateway 服務

本篇文章為系列文章,未讀第一集的同學請猛戳這裡: Spring Cloud 系列之 Gateway 服務閘道器(一) Spring Cloud 系列之 Gateway 服務閘道器(二) 本篇文章講解 Gateway 閘道器過濾器和全域性過濾器以及自定義過濾器。    過濾器      Spring Clo

從零搭建Spring Cloud Gateway——報文結構轉換

## 背景 作為閘道器,有些時候可能報文的結構並不符合前端或者某些服務的需求,或者因為某些原因,其他服務修改報文結構特別麻煩、或者需要修改的地方特別多,這個時候就需要走閘道器單獨轉換一次。 ## 實現 話不多說,直接上程式碼。 首先,我們定義好配置: ```java package com.lifeng

服務API : Kong能為我們做什麼?

本系列內容是來自Mashape.com的Marco在nginx.conf上的一次演講。 本系列第一部分(上集)主要介紹了單體和微服務之間的差別,以及為什麼我們需要一個API閘道器等等。 本系列的第二部分(也就是本集)主要關注Mashape.com的AP

構建服務之使用API

對於設計、構建和部署微服務系列七篇文章的第一篇,我們介紹了微服務架構風格,討論了微服務的優勢和劣勢,儘管微服務有些複雜,但仍然是構建複雜應用的一個明智選擇,第二篇文章將討論使用API閘道器構建微服務。 當我們選擇把應用構建成一組微服務的時候,我們需要決定應用的客戶端