溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
JHipster微服務架構是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
使用 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 gateway。 這是一個普通的JHipster 應用,在使用yo jhipster時第一個問題可以選擇生成，你可以像開發一個普通應用來開發它。它在微服務架構中扮演一個入口的角色，提供了http 路由，負載均衡，api 文檔、保障服務質量和安全的功能。
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網絡令牌）是現在的一個業界標準，簡單易用，可以為微服務應用提供安全保障。
JHispter使用 JJWT library 庫，由Stormpath提供，用來實現具體的jwt。
所有的toekn都由網關生成，并傳送給底層微服務應用。因為它們共享一個公共的密鑰，所以微服務應用能夠驗證該令牌，并且使用該令牌認證用戶。
這些令牌是自給自足的：它們具有認證和授權的信息，所以微服務應用不需要查詢數據庫或外部系統。這是點保證了微服務的可擴展性，所以很重要。
為了保證服務的安全運行，一個token必須在所有應用程序之間共享：
對于每個應用，其默認的token是獨一無二的，并通過JHipster產生，被存儲在 .yo - rc.json 文件
令牌的值可以通過修改在 src /mian/resources/config/application.yml 文件中的 jhipster.security.authentication.jwt.secret 的值來進行配置
一個好的實踐是在生產環境和開發環境采用不同的token
此功能目前處于 BETA 階段，因此它的文檔還沒有完成。
JHipster提供生成一個基于Srping security 的"UAA(用戶賬號和認證信息)"的服務 。這項服務采用Oauth3 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 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 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 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 會產生網關上的前端代碼（相當于是在網關應用中通過頁面來管理微服務應用實體）。
如果你的應用采用了 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)
只有微服務應用可以創建無數據庫的程序。這是因為微服務應用可以很小，可以沒有用戶管理的代碼。
一個沒有數據庫的微服務應用很小，可用于連接到一個遺留的后端系統。
開發微服務系統，意味著你可能需要在幾個不同的 services 和 databases 上同時工作，而 Docker Compose 則是一個針對此情況，管理開發，測試和生產環境的絕佳工具。
為此我們有一篇專門的文檔來介紹 [Docker Compose documentation]({{ site.url }}/docker-compose#microservices) ，我們強烈建議在開發微服務架構的系統前閱讀這篇文章，熟悉這方面的知識。
當你使用 docker-Compose sub-generator 的時候，會詢問你是否需要為你的應用添加監控。如果選擇是，它將會在你的 docker-compose.yml 文件下添加 JHipster-Console。當你啟動系統后，就可以有通過訪問 http://localhost:5601 來獲取系統應的日志和各種指標。更多關于監控的東西，可以參見 monitoring documentation
對比一體化應用，網關和微服務監視器提供了一些額外的功能，可以幫助你有效地監控微服務集群。例如查看日志，它可以具體到日志對于的應用程序的名稱，主機，端口和Eureka ServiceId ，這樣可以讓你追蹤到具體的service。此外，JHipster Console帶有默認的儀表板，讓你在同一時間查看所有的服務。
Docker Swarm (Docker 集群管理工具) 底層使用的API 和Docker Machine (Docker管理工具) 是一樣的，所以使用Docker Swarm 發布微服務應用和在你本機上發布是一樣的。更多關于Docker和Docker Swarm的文檔請參考 [Docker Compose documentation ]({{ site.url }}/docker-compose/)。
使用 [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 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來加密通信通道。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
