JHipster微服務架構

摘要

1. 微服務架構 vs 一體化架構
2. 概覽
3. JHipster 的API 網關

• 使用網關進行HTTP路由
• 安全
• 自動生成文檔
• 請求速率限制
• 訪問控制策略

4. JHipster 的註冊中心

• JHipster 註冊中心概覽
• JHipster 註冊中心的安全保障
• 在JHipster 上註冊你的應用

5. 建立微服務應用

• 爲微服務應用生成實體對象
• 使用HazelCast作分佈式緩存
• 不帶數據庫的微服務應用

6. 使用 Docker Compose
7. 使用JHipster Console 和ELK技術棧來監控服務
8. 生產環境

• 部署到 Docker Swarm
• 部署到 CloudFoundry
• 部署到 Heroku

微服務架構 vs 一體化架構

使用 JHipster 生成應用時，第一個問題就是讓你選擇你要的生成的應用(目前有4個選項)，但實際上你是在兩種架構風格里面作選擇：

• 一體化架構，用來建立單獨的一個應用，包含前端 AngularJS 代碼和後端 spring boot 相關代碼，項目中全部代碼都在一個應用中。
• 微服務架構，進行了先後端分離，優勢是它可讓你很容易的控制單個應用的規模，並處理好這些應用中一些簡單細小的問題。

相對來講，一體化架構是比較容易上手，官網默認推薦這個，若是是剛接觸 JHipstert，建議從這個入手，熟悉後，若是項目有要求，則再選擇微服務架構應用。

下面部分則主要講解下使用JHipster進行微服務架構。

概覽

JHipster 微服務架構的工做方式以下：

• JHipster gateway ，是一個能夠經過生成器直接生成的(在第一個問題裏面選擇 microservice gateway)完整應用，包含來服務端和前端，用來處理web請求。一個微服務架構裏面能夠同時有幾個網關，若是你遵循 Backends for Frontends pattern這種模式，固然這不是強制性的。

• JHipster Registry JHipster的註冊中心，能夠在github上 獲取，全部的微服務應用和網關都是從註冊中心獲取配置，因此它必需要先運行起來。

• JHipster的微服務應用實例，能夠經過生成器直接生成(在第一個問題裏面選擇microservice application)，它們是提供服務的具體實現。它們是無狀態的。能夠同時並行運行好幾個相同的實例，來處理海量的請求。

• JHipster Console，JHipster的控制檯，提供了服務監控和警報的功能，基於ELK 技術棧。

在下圖中，綠色的組件表明你的特定應用，藍色組件表明的底層基礎架構：

JHipster 的API 網關

JHipster 能夠生成API gateway。 這是一個普通的JHipster 應用,在使用yo jhipster時第一個問題能夠選擇生成，你能夠像開發一個普通應用來開發它。它在微服務架構中扮演一個入口的角色，提供了http 路由，負載均衡，api 文檔、保障服務質量和安全的功能。

使用網關進行HTTP路由

JHipster 的網關和服務應用啓動以前，須要先啓動 JHipster register 項目做爲註冊中心。應用在配置註冊中心地址時候，只須要修改 eureka.client.serviceUrl.defaultZone key 對應的值 （在 src/main/resources/config/application.yml 文件中）。

網關將自動代理全部請求的服務，並沿用應用程序的名稱，例如：當微服務應用APP1在註冊中心註冊後，能夠經過/APP1網址來訪問。

再舉個例子，若是你的網關運行在localhost:8080，你能夠經過 http://localhost:8080/app1/rest/foos 得到經過微服務APP1服務提供的的foos資源。

另外，JHipster中REST接口資源都是受保護的，在經過瀏覽器訪問這些接口時，你須要帶上正確JWT(在請求頭的header上，下面安全章節的時候還會在提到)，或在MicroserviceSecurityConfiguration類中註釋掉相關代碼。

若是有多個相同的服務實例在同時運行，網關能夠從JHipster的註冊中心獲取這些實例，而且：

• 使用 Netflix Ribbon 進行負載均衡。

• 採用 Netflix Hystrix 提供的熔斷機制，這樣能夠將掛的運行實例快速安全地移除。

每一個網關應用都提供了http 路由和服務實例監控的功能，在後臺"管理員>網關"菜單中能夠看到。

安全

JWT (JSON Web Token)

JWT（JSON網絡令牌）是如今的一個業界標準，簡單易用，能夠爲微服務應用提供安全保障。

JHispter使用 JJWT library 庫，由Stormpath提供，用來實現具體的jwt。

全部的toekn都由網關生成，並傳送給底層微服務應用。由於它們共享一個公共的密鑰，因此微服務應用可以驗證該令牌，而且使用該令牌認證用戶。

這些令牌是自給自足的：它們具備認證和受權的信息，因此微服務應用不須要查詢數據庫或外部系統。這是點保證了微服務的可擴展性，因此很重要。

爲了保證服務的安全運行，一個token必須在全部應用程序之間共享：

• 對於每一個應用，其默認的token是獨一無二的，並經過JHipster產生，被存儲在 .yo - rc.json 文件

• 令牌的值能夠經過修改在 src /mian/resources/config/application.yml 文件中的 jhipster.security.authentication.jwt.secret 的值來進行配置

• 一個好的實踐是在生產環境和開發環境採用不一樣的token

OAuth2

此功能目前處於 BETA 階段，所以它的文檔尚未完成。

JHipster提供生成一個基於Srping security 的"UAA(用戶帳號和認證信息)"的服務 。這項服務採用Oauth2 token機制，來保證服務網關的安全。

在這基礎上，服務網關利用Spring Security對jwt的支持來傳遞token給其它底層的微服務應用。

自動生成文檔

JHipster 的網關整合了swagger API，因此咱們能夠很方便的使用 Swagger UI 和 swagger-codegen。在管理後臺的"admin> API"的菜單中，能夠看到網關的API，以及全部註冊了微服務的API。

經過下拉列表，能夠查看有Swagger 生成的API文檔，這些API均可以在線測試。測試的時候token會自動添加到Swagger UI 的接口中去，因此全部的請求都是在沙盒外進行。

請求速率限制

這是一個高級功能，須要創建一個Cassandra 集羣（經過Docker Compose configuration 能夠比較容易的搭建起來）。

網關提供限速的功能，因此REST請求的次數能夠被限制：

• 經過IP地址（匿名用戶）

• 用戶登陸（登陸用戶）

JHipster將使用Cassandra 集羣存儲的請求數據，而且對超出限制請求將發送HTTP 429 （太多請求）錯誤。每一個用戶的默認限速爲每小時10萬API調用。

這是一個重要的功能，能夠保護微服務不被一些特殊的的用戶請求拖垮服務器。

JHipster register 做爲一個管理 REST 接口資源的關卡，它對用戶的安全信息擁有絕對控制權，所以它能夠很容易擴展，以提供根據用戶角色來進行特定速率限制。

爲開啓速率限制，須要在 application-dev.yml 或 application-prod.yml 中進行配置

jhipster:
    gateway:
        rate-limiting:
            enabled: true

固然 Cassandra 集羣也須要搭建並配置好. 若是採用 JHipster’s Docker Compose 的配置(在 src/main/docker 中)，則能夠正常運行。想本身手動設置羣集，這裏有些步驟要注意下：

• 首先要有一個可用的Cassandra集羣。

• 須要配置好JHipster特定的限速表，相關的 create_keyspace.cql 和 create_tables.cql 腳本，在 src/main/resources/config/cql 目錄下。

• 該羣集必須在 application-*.yml文件中進行配置，其對應的鍵爲spring.data.cassandra（已生成了默認配置）

若是你想添加更多的規則，或修改現有規則，你須要修改RateLimitingFilter類。好比說，若是你要進行如下狀況的限制：

• 下降HTTP調用的限制

• 添加每分鐘或每日限制

• 刪除了"管理員"用戶的全部限制

訪問控制策略

默認狀況下全部已註冊的微服務均可以經過網關訪問。若是你想從經過網關排除特定的API ，你可使用網關的訪問控制過濾器來對具體的訪問進行控制。在 application-*.yml 文件中對 jhipster.gateway.authorized-microservices-endpoints 進行配置，默認配置爲：

jhipster:
    gateway:
        authorized-microservices-endpoints: # Access Control Policy, if left empty for a route, all endpoints will be accessible
            app1: /api,/v2/api-docs # recommended dev configuration

若是你只想微服務bar的 /api/foo 接口能夠被訪問，那麼你只須要進行以下配置：

jhipster:
    gateway:
        authorized-microservices-endpoints:
            bar: /api/foo

JHipster 的註冊中心

JHipster 註冊中心概覽

JHipster Registry 是一個可運行的應用，由JHipster 的團隊開發。和JHipster generator同樣，也是開源的，遵循Apache 2-licensed，也放在github上，點此查看。

能夠在github上clone或者下載Registry的源碼，若是使用了JHipster generator，則建議使用使用和它相同tag的Registry，它的運行方式和其它的應用同樣：

• 開發環境下，直接運行 ./mvnw，它默認採用開發環境下的配置文件，Eureka Registry 將能夠經過 http://127.0.0.1:8761/ 進行訪問。

• 生產環境下，使用./mvnw -Pprod打包生成可執行WAR文件。

若是想經過docker鏡像來運行JHipster Registry，Docker Hub 中也有提供，在JHipster Registry，固然這個鏡像是預先配置好。

• 運行 docker-compose -f src/main/docker/jhipster-registry.yml up 來啓動JHipster Registry. 而後 Eureka Registry 就會監聽你8761 端口 , 由此即可以經過 http://127.0.0.1:8761/ 來訪問

更多關於docker和JHipster Registry的問題，能夠參見[docker Compose documentation ]({{ site.url }}/docker-compose/)

JHipster 註冊中心的安全保障

JHipster Registry 默認是受保護的，須要使用帳戶和密碼來登錄，默認帳號密碼爲"admin/admin"。

微服務應用固然也是以admin的角色在Registry上進行註冊，可是是經過HTTP Basic 認證。因此若是你的微服務應用不能鏈接到註冊中心，你會收到"401 authentication error"的錯誤信息，由於你配置錯了某些東西。

爲了保障JHipster Registry 的安全：

• 你必須修改admin的密碼。此密碼能夠在Spring boot 的 application-*.yml 文件中經過修改 security.user.password 對應的值來實現，或者你也能夠新建一個 SECURITY_USER_PASSWORD 環境變量。在[Docker Compose sub-generator]({{ site.url }}/docker-compose/)中，用到了這個變量。

• 由於你的應用程序是經過HTTP鏈接到Registry，因此保障鏈接通道的安全性很重要，其中一個比較簡單的方式是採用HTTPS。

在JHipster 上註冊你的應用

JHipster Registry 是採用了 Netflix Eureka server 和 Spring Config Server。 當微服務應用和或者微服務網關啓動的時候，它們會首先鏈接到JHipster Registry去獲取配置信息。

這些配置是指spring boot 的配置，也就是 application-*.yml 文件。但它們存儲在中央服務器上，易於管理。

當整個服務啓動時，微服務應用或者網關會從Registry上獲取服務的配置信息而且覆蓋它們原來存儲在本地的配置文件。

如下兩種配置信息是能夠用的：

• 開發環境下的本地配置文件（使用 dev profile），使用本地的文件系統。

• git 配置信息，用在生產環境下（使用 JHipster prod profile），存儲在git 服務中。使用git能夠創建tag、分支，或者回滾配置信息，這是生產環境下很是實用。

爲了集中管理微服務的配置，你須要按照 application-*.yml 的格式建立配置文件，並放在Registry 的config 文件下。要求 appname 和 profile 你的微服務應用同名和profile對應。

舉個例子，添加了一個 gateway-prod.yml 文件將對全部的名爲gateway的應用採用生產環境下的配置文件。此外，定義在 application[-dev|prod].yml 配置將對全部的應用產生效果。

上面提到網關路由是經過Spring boot 來配置，它們其實也能夠經過Spring Config Server 來管理。舉個例子，你能夠在 v1 分支上，將應用 app1-v1 路由到 /appl 的url上，而在 v2 分支，將 app1-v2 路由到 /app1 的url上。這是一種無縫升級微服務的好方式，以達到不須要中止服務就能夠升級的效果。

建立微服務應用

微服務應用實例是能夠經過 JHipster 生成的，沒有前端（生成的微服務網關會有前端，用到了angularJS ），它要配合着 JHipster Registry 才能正常運行。

爲微服務應用生成實體對象

在用 [entity sub-generator]({{ site.url }}/creating-an-entity/)爲微服務應用中生成entity時，和在一體化架構應用中生成entity的方式有點不同，由於微服務實現了先後端分離，微服務應用後臺只須要提供接口，不須要前端代碼，所以它也就不須要生成前端代碼。

首先，在微服務的應用中生成實體，能夠採用在一體化應用中生成實體對象的方法，也可使用 [JHipster UML]({{ site.url }}/jhipster-uml/) 或者 [JDL Studio]({{ site.url }}/jdl-studio/) 來生成更加複雜的實體以及關係。固然這不會生成AngularJS代碼。

而後，在微服務網關應用中，再次運行[entity sub-generator]({{ site.url }}/creating-an-entity/)，會在開始時多出一個問題，這是專門針對網關應用的：

• 有兩個選項：要麼像在一體化架構應用中生成實體方式那樣，正常生成一個新的實體（微服務網關應用自己是一個完整的 JHipster 應用，這點上它有點像是個一體化應用），要麼是利用已有的 JHipster 配置信息來生成。

• 若是選擇後者，你須要輸入微服務應用的路徑，而後 JHipster 會產生網關上的前端代碼（至關因而在網關應用中經過頁面來管理微服務應用實體）。

使用HazelCast作分佈式緩存

若是你的應用採用了 SQL 的數據庫，JHipster 針對微服務 給出了不一樣的，支持二級緩存的解決方案：

• JHipster 的默認微服務緩存解決方案是採用 Hazelcast
• 你也能夠採用 Ehcache(一體化應用默認支持的方案) ，或者乾脆不適用緩存。

默認的 Hazelcast 解決方案是支持微服務的，它能夠很好的支持你拓展服務：

• 使用本地緩存，你是單個服務沒有一個能夠同步的緩存，可能致使數據不一致。

• 不使用任何緩存，隨着服務的拓展增長，系統的負擔都放到來數據庫，這也不是個很好的方案。

採用 Hazelcast作緩存，須要作些特別的配置：

• 在啓動時，應用程序會鏈接到 JHipster 註冊服務中，找到和他相同的服務實例。
• 若是使用了 dev profile，JHipster 將在本地主機上 127.0.0.1 上建立這些實例的羣集 ，使用每一個實例不一樣的端口。默認狀況下， Hazelcast端口是 你的應用程序的端口+ 5701 (因此若是你的應用程序的端口是 8081，Hazelcast將使用端口 13782)
• 若是使用了 prod profile，JHipster 用它找到的全部其餘節點來構建一個羣集，使用Hazelcast默認的端口 (5701)

不帶數據庫的微服務應用

只有微服務應用能夠建立無數據庫的程序。這是由於微服務應用能夠很小，能夠沒有用戶管理的代碼。

一個沒有數據庫的微服務應用很小，可用於鏈接到一個遺留的後端系統。

使用 Docker Compose

開發微服務系統，意味着你可能須要在幾個不一樣的 services 和 databases 上同時工做，而 Docker Compose 則是一個針對此狀況，管理開發，測試和生產環境的絕佳工具。

爲此咱們有一篇專門的文檔來介紹 [Docker Compose documentation]({{ site.url }}/docker-compose#microservices) ，咱們強烈建議在開發微服務架構的系統前閱讀這篇文章，熟悉這方面的知識。

使用JHipster Console 和ELK技術棧來監控服務

當你使用 docker-Compose sub-generator 的時候，會詢問你是否須要爲你的應用添加監控。若是選擇是，它將會在你的 docker-compose.yml 文件下添加 JHipster-Console。當你啓動系統後，就能夠有經過訪問 http://localhost:5601 來獲取系統應的日誌和各類指標。更多關於監控的東西，能夠參見 monitoring documentation

對比一體化應用，網關和微服務監視器提供了一些額外的功能，能夠幫助你有效地監控微服務集羣。例如查看日誌，它能夠具體到日誌對於的應用程序的名稱，主機，端口和Eureka ServiceId ，這樣可讓你追蹤到具體的service。此外，JHipster Console帶有默認的儀表板，讓你在同一時間查看全部的服務。

生產環境

部署到 Docker Swarm

Docker Swarm (Docker 集羣管理工具) 底層使用的API 和Docker Machine (Docker管理工具) 是同樣的，因此使用Docker Swarm 發佈微服務應用和在你本機上發佈是同樣的。更多關於Docker和Docker Swarm的文檔請參考 [Docker Compose documentation ]({{ site.url }}/docker-compose/)。

部署到 CloudFoundry

使用 [CloudFoundry sub-generator]({{ site.url }}/cloudfoundry/) 搭建爲微服務的應用原理和以前是同樣的，只是你須要部署更多的應用：

• 使 sub-generator 發佈你的 JHipster Registry

• 拿到JHipster Registry 的url,你須要在你的其它應用裏面配置這個地址：

  • 在 bootstrap-prod.yml 文件中，設置 spring.cloud.config.uri 值爲 http://<your_jhipster_registry_url>/config/

  • 在 application-prod.yml 文件中，設置 eureka.client.serviceUrl.defaultZone 值爲 http://<your_jhipster_registry_url>/eureka/

• 發佈你的網關應用和微服務應用

• 拓展你的應用

一個重要的點是 JHipster Registry 默認是不受保護的，而微服務應用也不該該直接經過外網訪被訪問到，用戶只有經過網關才能訪問到你的服務。針對此問題有兩種解決方案：

• 經過使用特定的路由來保護你的的 Cloud Foundry。

• 所有應用都使用 Https，並經過使用 Spring Security 的 basic authentication 來保護你的 JHipster Registry。

部署到 Heroku

使用 [Heroku sub-generator]({{ site.url }}/cloudfoundry/) 的原理和以前也是是同樣的，只是你須要部署更多的應用：

經過下面的按鈕能夠在 Heroku 上一鍵部署 JHipster Registry：

爲了保障註冊中心的安全，請參考 [Heroku sub-generator documentation]({{ site.url }}/heroku/)

在獲取註冊中心的地址後，你的所有應用都要在 application-prod.yml 中配置這個地址：

eureka:
    instance:
        hostname: <your_jhipster_registry_url>.herokuapp.com
        non-secure-port: 80
        prefer-ip-address: false

配置好後你就能夠部署你的網關應用和微服務應用。使用 Heroku sub-generator 會詢問你 JHipster Registry 的地址，這個可讓你的應用程序直接到 Spring Cloud Config server 上獲取它們的配置。

注意 以上的配置是經過http協議，可是在生產環境上，建議使用HTTPS來鏈接到你的JHipster Registry。由於管理員的密碼是經過HTTP來進行傳輸的，因此極力建議經過HTTPS來加密通訊通道。

歡迎掃碼加入咱們,內有大量資料,翻譯,視頻,文檔.歡迎加入咱們GITHUB翻譯組