bl双性强迫侵犯h_国产在线观看人成激情视频_蜜芽188_被诱拐的少孩全彩啪啪漫画

如何基于Nacos和Sentinel，實現灰度路由和流量防護一體化

Nepxion Discovery框架在實現灰度發布和路由功能前提下，結合Nacos和Sentinel，對流量再實施一層防護措施，更能達到企業級的流量安全控制的目的。它的功能包括：
  • 封裝遠程配置中心和本地規則文件的讀取邏輯，即優先讀取遠程配置，如果不存在或者規則錯誤，則讀取本地規則文件。動態實現遠程配置中心對于規則的熱刷新
  • 封裝NacosDataSource和ApolloDataSource，支持Nacos和Apollo兩個遠程配置中心，零代碼實現Sentinel功能。更多的遠程配置中心，請參照Sentinel官方的DataSource并自行集成
  • 支持原生的流控規則、降級規則、授權規則、系統規則、熱點參數流控規則
  • 支持擴展LimitApp的機制，通過動態的Http Header方式實現組合式防護機制，包括基于服務名、基于灰度組、基于灰度版本、基于灰度區域、基于機器地址和端口等防護機制，支持自定義任意的業務參數組合實現該功能，例如，根據傳入的微服務灰度版本號+用戶名，組合在一起進行熔斷
  • 支持微服務側Actuator、Swagger和Rest三種方式的規則寫入
  • 支持控制臺側基于微服務名的Actuator、Swagger和Rest三種方式的批量規則寫入
  • 支持開關關閉上述功能spring.application.strategy.sentinel.enabled=true，默認是關閉的
[ Nacos] 阿里巴巴中間件部門開發的新一代集服務注冊發現中心和配置中心為一體的中間件。它是構建以“服務”為中心的現代應用架構 (例如微服務范式、云原生范式) 的服務基礎設施，支持幾乎所有主流類型的“服務”的發現、配置和管理，更敏捷和容易地構建、交付和管理微服務平臺
[ Sentinel] 阿里巴巴中間件部門開發的新一代以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性的分布式系統的流量防衛兵。它承接了阿里巴巴近10年的雙十一大促流量的核心場景，例如秒殺（即突發流量控制在系統容量可以承受的范圍）、消息削峰填谷、集群流量控制、實時熔斷下游不可用應用等

環境搭建及依賴引入

服務端在Discovery框架原有依賴的基礎上，再引入如下依賴
<dependency>
    <groupId>com.nepxion</groupId>
    <artifactId>discovery-plugin-strategy-starter-service-sentinel</artifactId>
    <version>${discovery.version}</version>
</dependency>
<dependency>
    <groupId>com.nepxion</groupId>
    <artifactId>discovery-plugin-strategy-sentinel-starter-nacos</artifactId>
    <!-- <artifactId>discovery-plugin-strategy-sentinel-starter-apollo</artifactId> -->
    <version>${discovery.version}</version>
</dependency>

原生Sentinel注解

參照下面代碼，為接口方法增加@SentinelResource注解，value為sentinel-resource，blockHandler和fallback是防護其作用后需要執行的方法
@RestController
@ConditionalOnProperty(name = DiscoveryConstant.SPRING_APPLICATION_NAME, havingValue = "discovery-guide-service-b")
public class BFeignImpl extends AbstractFeignImpl implements BFeign {
    private static final Logger LOG = LoggerFactory.getLogger(BFeignImpl.class);
    @Override
    @SentinelResource(value = "sentinel-resource", blockHandler = "handleBlock", fallback = "handleFallback")
    public String invoke(@PathVariable(value = "value") String value) {
        value = doInvoke(value);
        LOG.info("調用路徑：{}", value);
        return value;
    }
    public String handleBlock(String value, BlockException e) {
        return value + "-> B server sentinel block, cause=" + e.getClass().getName() + ", rule=" + e.getRule() + ", limitApp=" + e.getRuleLimitApp();
    }
    public String handleFallback(String value) {
        return value + "-> B server sentinel fallback";
    }
}

原生Sentinel規則

Sentinel在配置中心訂閱的Key格式，如下：
1. Nacos的Key格式：Group為元數據中配置的[組名]，Data Id為[服務名]-[規則類型]
2. Apollo的Key格式：[組名]-[服務名]-[規則類型]
Sentinel規則的用法，請參照Sentinel官方文檔

流控規則

增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-flow，規則內容如下：
[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "grade": 1,
        "count": 1,
        "strategy": 0,
        "refResource": null,
        "controlBehavior": 0,
        "warmUpPeriodSec": 10,
        "maxQueueingTimeMs": 500,
        "clusterMode": false,
        "clusterConfig": null
    }
]
如圖所示

降級規則

增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-degrade，規則內容如下：
[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "count": 2,
        "timeWindow": 10,
        "grade": 0,
        "passCount": 0
    }
]
如圖所示

授權規則

增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下：
[
    {
        "resource": "sentinel-resource",
        "limitApp": "discovery-guide-service-a",
        "strategy": 0
    }
]
如圖所示

系統規則

增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-system，規則內容如下：
[
    {
        "resource": null,
        "limitApp": null,
        "highestSystemLoad": -1.0,
        "highestCpuUsage": -1.0,
        "qps": 200.0,
        "avgRt": -1,
        "maxThread": -1
    }
]
如圖所示

熱點參數流控規則

增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-param-flow，規則內容如下：
[
    {
        "resource": "sentinel-resource",
        "limitApp": "default",
        "grade": 1,
        "paramIdx": 0,
        "count": 1,
        "controlBehavior": 0,
        "maxQueueingTimeMs": 0,
        "burstCount": 0,
        "durationInSec": 1,
        "paramFlowItemList": [],
        "clusterMode": false
    }
]
如圖所示

基于灰度路由和Sentinel-LimitApp擴展的防護機制

該方式對于上面5種規則都有效，這里以授權規則展開闡述
授權規則中，limitApp，如果有多個，可以通過“,”分隔。"strategy": 0 表示白名單，"strategy": 1 表示黑名單

基于服務名的防護機制

修改配置項Sentinel Request Origin Key為服務名的Header名稱，修改授權規則中limitApp為對應的服務名，可實現基于服務名的防護機制
配置項，該配置項默認為n-d-service-id，可以不配置
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-id
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示所有discovery-guide-service-a服務允許訪問discovery-guide-service-b服務
[
    {
        "resource": "sentinel-resource",
        "limitApp": "discovery-guide-service-a",
        "strategy": 0
    }
]

基于灰度組的防護機制

修改配置項Sentinel Request Origin Key為灰度組的Header名稱，修改授權規則中limitApp為對應的組名，可實現基于組名的防護機制
配置項
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-group
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示隸屬my-group組的所有服務都允許訪問服務discovery-guide-service-b
[
    {
        "resource": "sentinel-resource",
        "limitApp": "my-group",
        "strategy": 0
    }
]

基于灰度版本的防護機制

修改配置項Sentinel Request Origin Key為灰度版本的Header名稱，修改授權規則中limitApp為對應的版本，可實現基于版本的防護機制
配置項
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-version
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示版本為1.0的所有服務都允許訪問服務discovery-guide-service-b
[
    {
        "resource": "sentinel-resource",
        "limitApp": "1.0",
        "strategy": 0
    }
]

基于灰度區域的防護機制

修改配置項Sentinel Request Origin Key為灰度區域的Header名稱，修改授權規則中limitApp為對應的區域，可實現基于區域的防護機制
配置項
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-region
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示區域為dev的所有服務都允許訪問服務discovery-guide-service-b
[
    {
        "resource": "sentinel-resource",
        "limitApp": "dev",
        "strategy": 0
    }
]

基于機器地址和端口的防護機制

修改配置項Sentinel Request Origin Key為灰度區域的Header名稱，修改授權規則中limitApp為對應的區域值，可實現基于機器地址和端口的防護機制
配置項
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-address
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示地址和端口為192.168.0.88:8081和192.168.0.88:8082的服務都允許訪問服務discovery-guide-service-b
[
    {
        "resource": "sentinel-resource",
        "limitApp": "192.168.0.88:8081,192.168.0.88:8082",
        "strategy": 0
    }
]

自定義業務參數的組合式防護機制

通過適配類實現自定義業務參數的組合式防護機制
// 版本號+用戶名，實現組合式熔斷
public class MyServiceSentinelRequestOriginAdapter extends DefaultServiceSentinelRequestOriginAdapter {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        String version = request.getHeader(DiscoveryConstant.N_D_SERVICE_VERSION);
        String user = request.getHeader("user");
        return version + "&" + user;
    }
}
在配置類里@Bean方式進行適配類創建
@Bean
public ServiceSentinelRequestOriginAdapter ServiceSentinelRequestOriginAdapter() {
    return new MyServiceSentinelRequestOriginAdapter();
}
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則內容如下，表示版本為1.0且傳入的Http Header的user=zhangsan，同時滿足這兩個條件下的所有服務都允許訪問服務discovery-guide-service-b
[
    {
        "resource": "sentinel-resource",
        "limitApp": "1.0&zhangsan",
        "strategy": 0
    }
]
運行效果
  • 當傳遞的Http Header中user=zhangsan，當全鏈路調用中，API網關負載均衡discovery-guide-service-a服務到1.0版本后再去調用discovery-guide-service-b服務，最終調用成功
如圖所示

  • 當傳遞的Http Header中user=lisi，不滿足條件，最終調用在discovery-guide-service-b服務端被拒絕掉
如圖所示

  • 當傳遞的Http Header中user=zhangsan，滿足條件之一，當全鏈路調用中，API網關負載均衡discovery-guide-service-a服務到1.1版本后再去調用discovery-guide-service-b服務，不滿足version=1.0的條件，最終調用在discovery-guide-service-b服務端被拒絕掉
如圖所示

基于Swagger的Sentinel規則推送

分為基于單個服務實例和基于服務名對應的多個服務實例的Sentinel規則推送

基于單個服務實例的Sentinel規則推送

直接訪問該服務實例的Swagger主頁即可
如圖所示

基于服務名對應的多個服務實例的Sentinel規則推送

需要開啟discovery-console服務，并訪問其Swagger主頁即可
如圖所示

本文作者：任浩軍， 10 多年開源經歷，Github ID：@HaojunRen，Nepxion 開源社區創始人，Nacos Group Member，Spring Cloud Alibaba & Nacos & Sentinel Committer ，曾就職于平安銀行平臺架構部，負責銀行 PaaS 系統基礎服務框架研發。 王偉華， 10 余年 Java 開發，Github ID：@vipweihua，對微服務架構研究多年，當前更多關注于微服務中的網關、限流熔斷、灰度路由等，現就職于平安銀行平臺架構部，從事銀行 PaaS 系統基礎服務框架研發。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

分享題目：如何基于Nacos和Sentinel，實現灰度路由和流量防護一體化
文章出自：http://vcdvsql.cn/article38/pcdcpp.html

成都網站建設公司_創新互聯，為您提供網站設計、響應式網站、品牌網站建設、移動網站建設、面包屑導航、云服務器

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯

營銷型網站建設