<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          為什么微服務一定要有網關?

          共 2149字,需瀏覽 5分鐘

           ·

          2020-07-28 17:21

          作者:趙計剛?

          鏈接:cnblogs.com/java-zhao/p/6716059.html






          正文







          一、什么是服務網關

          服務網關 = 路由轉發(fā) + 過濾器

          1、路由轉發(fā):接收一切外界請求,轉發(fā)到后端的微服務上去;

          2、過濾器:在服務網關中可以完成一系列的橫切功能,例如權限校驗、限流以及監(jiān)控等,這些都可以通過過濾器完成(其實路由轉發(fā)也是通過過濾器實現的)。

          二、為什么需要服務網關

          上述所說的橫切功能(以權限校驗為例)可以寫在三個位置:

          • 每個服務自己實現一遍
          • 寫到一個公共的服務中,然后其他所有服務都依賴這個服務
          • 寫到服務網關的前置過濾器中,所有請求過來進行權限校驗

          第一種,缺點太明顯,基本不用;第二種,相較于第一點好很多,代碼開發(fā)不會冗余,但是有兩個缺點:

          • 由于每個服務引入了這個公共服務,那么相當于在每個服務中都引入了相同的權限校驗的代碼,使得每個服務的jar包大小無故增加了一些,尤其是對于使用docker鏡像進行部署的場景,jar越小越好;
          • 由于每個服務都引入了這個公共服務,那么我們后續(xù)升級這個服務可能就比較困難,而且公共服務的功能越多,升級就越難,而且假設我們改變了公共服務中的權限校驗的方式,想讓所有的服務都去使用新的權限校驗方式,我們就需要將之前所有的服務都重新引包,編譯部署。

          而服務網關恰好可以解決這樣的問題:

          • 將權限校驗的邏輯寫在網關的過濾器中,后端服務不需要關注權限校驗的代碼,所以服務的jar包中也不會引入權限校驗的邏輯,不會增加jar包大小;
          • 如果想修改權限校驗的邏輯,只需要修改網關中的權限校驗過濾器即可,而不需要升級所有已存在的微服務。

          所以,需要服務網關!!!

          三、服務網關技術選型

          引入服務網關后的微服務架構如上,總體包含三部分:服務網關、open-service和service。

          1、總體流程

          • 服務網關、open-service和service啟動時注冊到注冊中心上去;
          • 用戶請求時直接請求網關,網關做智能路由轉發(fā)(包括服務發(fā)現,負載均衡)到open-service,這其中包含權限校驗、監(jiān)控、限流等操作
          • open-service聚合內部service響應,返回給網關,網關再返回給用戶

          2、引入網關的注意點

          • 增加了網關,多了一層轉發(fā)(原本用戶請求直接訪問open-service即可),性能會下降一些(但是下降不大,通常,網關機器性能會很好,而且網關與open-service的訪問通常是內網訪問,速度很快);
          • 網關的單點問題:在整個網絡調用過程中,一定會有一個單點,可能是網關、nginx、dns服務器等。防止網關單點,可以在網關層前邊再掛一臺nginx,nginx的性能極高,基本不會掛,這樣之后,網關服務就可以不斷的添加機器。但是這樣一個請求就轉發(fā)了兩次,所以最好的方式是網關單點服務部署在一臺牛逼的機器上(通過壓測來估算機器的配置),而且nginx與zuul的性能比較,根據國外的一個哥們兒做的實驗來看,其實相差不大,zuul是netflix開源的一個用來做網關的開源框架;
          • 網關要盡量輕。

          3、服務網關基本功能

          • 智能路由:接收

            外部

            一切請求,并轉發(fā)到后端的對外服務open-service上去;

            • 注意:我們只轉發(fā)外部請求,服務之間的請求不走網關,這就表示全鏈路追蹤、內部服務API監(jiān)控、內部服務之間調用的容錯、智能路由不能在網關完成;當然,也可以將所有的服務調用都走網關,那么幾乎所有的功能都可以集成到網關中,但是這樣的話,網關的壓力會很大,不堪重負。
          • 權限校驗:只校驗用戶向open-service服務的請求,不校驗服務內部的請求。服務內部的請求有必要校驗嗎?

          • API監(jiān)控:只監(jiān)控經過網關的請求,以及網關本身的一些性能指標(例如,gc等);

          • 限流:與監(jiān)控配合,進行限流操作;

          • API日志統(tǒng)一收集:類似于一個aspect切面,記錄接口的進入和出去時的相關日志

          • 。。。后續(xù)補充

          上述功能是網關的基本功能,網關還可以實現以下功能:

          • A|B測試:A|B測試時一塊比較大的東西,包含后臺實驗配置、數據埋點(看轉化率)以及分流引擎,在服務網關中,可以實現分流引擎,但是實際上分流引擎會調用內部服務,所以如果是按照上圖的架構,分流引擎最好做在open-service中,不要做在服務網關中。
          • 。。。后續(xù)補充

          4、技術選型

          筆者準備自建一個輕量級的服務網關,技術選型如下:

          • 開發(fā)語言:java + groovy,groovy的好處是網關服務不需要重啟就可以動態(tài)的添加filter來實現一些功能;
          • 微服務基礎框架:springboot;
          • 網關基礎組件:netflix zuul;
          • 服務注冊中心:consul;
          • 權限校驗:jwt;
          • API監(jiān)控:prometheus + grafana;
          • API統(tǒng)一日志收集:logback + ELK;
          • 壓力測試:Jmeter;
          • 。。。后續(xù)補充

          在后續(xù)的介紹中,會逐漸介紹各個知識點,并完成一個輕量級的服務網關!!!


          -END-


          視頻號開通啦,

          是關于國外程序員題材的視頻號

          長按二維碼關注

          瀏覽 68
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  好吊操色| 囯产精品久久久久久久久久久久 | 欧美性爱网站在线 | 欧美A区| 中国一级毛片免费播放 |