前言：由於目前網飛系的停更，國內阿里系微服務生態的大火，在這次公司級的微服務選型我們選擇了springcloud alibaba生態。結合原有netflix的架構做一個本地預研。

目前預研進度：

　　1.只保留原有元件庫下的common、log、restful（swagger3,exception fallback）、feign（含各個微服務的feignClient）與 netflix相關的及資料庫快取等解耦先不引入後續基礎框架成型後一次引入。本次我們重點關注放在分散式註冊中心、配置中心及服務間的呼叫。

　　2.註冊中心由Eureka 配置中心由apollo 替換成alibaba-nacos

　　3.路由閘道器由zuul-gateway 替換成spring自己的springcloud-gateway

　　4.服務間的呼叫沿用feign+ribbon，相對alibaba-dubbo的上手複雜度及價效比,綜合考慮團隊及業務體量，仍然選用前者。

　　5.微服務的高可用性主角擔當（限流與熔斷）將hystrix替換成alibaba-sentinel 。滿眼都是sentinel的優點。方法級的細顆粒度控制、搭配直觀的控制平臺、極易可讀api、實時檢視實時修改的規則。相對hystrix簡單粗暴的針對一個微服務做訊號量或執行緒數的配置。前者顯得更加的人性化。值得一提，生產環境下的sentinel使用必須做到配置規則持久化這是一個大前提。

　　6.未完待續：既然決定了全面擁抱阿里巴巴生態，當然不能放過一些已有的優秀元件。

　　服務級：分散式事務seata、任務排程服務Alibaba Cloud SchedulerX、訊息中介軟體rocketmq的封裝

　　業務級：Alibaba Cloud OSS: 阿里雲物件儲存服務、Alibaba Cloud SMS: 覆蓋全球的簡訊服務（ps啥時候把自己的支付業務也整合開源下 免得我們自己抽離）

遇到的坑：

　　1.1 Nacos作為註冊中心，swagger2升級3中間遇到的問題

　　2.1 Nacos部署 服務註冊 配置中心引用

　　3.1 路由部署 gateway的各個服務配置（需要在同一個名稱空間）

　　4.1 feign ribbon的配置及優化

　　5.1 sentinel部署 資源的簡單使用

　　5.2 sentinel持久化到nacos

　　5.3 sentinel與nacos的雙向同步改造

　　5.4 對feignClient資源的sentinel使用

　　5.5 sentinel異常統一攔截處理（不再增加冗餘的fallbackHandler和blockHandler）只要宣告@SentinelResource即可

　　6 未完待續