微服務架構組件梳理之Netflix停更之後該何去何從
自2018年底，Netflix陸續宣布Eureka、Hystrix等框架進入維護狀態，不再進行新功能的開發。
恰逢最近我打算對公司的辦公項目進行微服務架構升級，所以惡補了一番微服務相關知識，在這裡進行一個小小的總結梳理。
2020年的微服務項目，應該用啥子框架呢？
一、微服務基本概念
保持對知識的敬畏，這裡還是先複習下，微服務架構的基本概念。
引用wiki如下：
2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，
與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的程式語言與資料庫等組件實現。
落實到程式碼上，就是將原來的各個業務包、業務模組，拆分成可以獨立部署的一個個業務服務。
這樣做好處很明顯，業務分開之後，我們可以針對各個業務的訪問量，細粒度的進行性能優化，擴容，針對性的提高項目的性能。
但是也會隨之帶來一些問題，如微服務之間相互調用性能、分散式事務、服務限流降級熔斷、服務配置等。
所以，要做好一個微服務項目，就要使用框架來幫助我們解決上述問題，使開發人員更好的面向業務。
二、微服務架構應該考慮的問題
那麼微服務架構中，如何滿足上述所說，讓開發人員更好的面向業務，應該考慮哪些問題呢？前輩們早就思考過了，這裡梳理一下。
1、微服務的註冊與發現
微服務的註冊與發現是什麼？
我理解，當你有一堆微服務時，一定涉及對每個微服務進行管理。
如何管理呢？首先，應該有個微服務花名冊，有多少個微服務，都叫啥名，都住哪，這些基本資訊統統記錄在案。如果這些都不清楚，何談管理？
怎麼實現呢？
現微服務的註冊和發現，一般都使用註冊中心來統一管理。
現在註冊中心框架有哪些？都有啥子區別呢？網上一大把資料，參考網路整理如下：
| Nacos | Eureka | Consul | Zookeeper | |
| 一致性協議 | CP+AP | AP | CP | CP |
| 健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | Keep Alive |
| 雪崩保護 | 有 | 有 | 無 | 無 |
| 訪問協議 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
| SpringCloud集成 | 支援 | 支援 | 支援 | 支援 |
| Dubbo集成 | 支援 | 不支援 | 不支援 | 支援 |
| K8S集成 | 支援 | 不支援 | 支援 | 不支援 |
| 自動註銷實例 | 支援 | 支援 | 不支援 | 支援 |
上述表中有一個一致性協議，涉及到CAP理論，此理論是分散式架構中的重要理論，描述了一致性、可用性、分區容忍性，這裡不展開描述了。
2、微服務調用
當把一個個的業務模組拆分成單個服務時，就會出現服務之間的互相調用問題。
這裡要吐槽一下我們原始的項目，微服務之間調用，是通過訪問一個單獨服務，拿到目標服務的ip+port，然後通過RestTemplate請求。
這種方式弊端含淚整理如下：
（1）這種方式會產生大量的重複程式碼；
（2）單獨服務很容易成為性能瓶頸，因為所有的項目在調用其他服務之前，都要先請求這個服務，這個問題線上已經爆發了/(ㄒoㄒ)/~~
（3）若微服務地址發生變化，需要重新登記配置；
（4）已經配置的微服務，不支援擴容，對！沒有看錯！不支援！
前人挖坑後人填，吐槽完成之後，言歸正傳，用什麼框架可以解決微服務的調用問題呢？
Ribbon : 一個客戶端負載均衡的工具，由Netflix公司開發，很不幸，已經進入了維護狀態，不再進行新的功能開發。詳情見官方github：//github.com/Netflix/ribbon
Feign ：內集成了Ribbon，可以通過註解，像本地調用似的跨域調用微服務介面。
OpenFeign ：Spring Cloud在Feign的基礎上，支援了SpringMvc的註解。
3、服務的限流、降級、熔斷
首先，什麼是服務限流、服務降級、服務熔斷呢？
服務限流：限流就是限制流量，服務就是微服務，服務限流，即限制微服務的訪問流量。流量是個抽象概念，具體到項目介面上，就是請求數或者執行緒數。
服務降級：
把服務分成多個等級，比如我是開飯店的，客人就餐，我提供的三檔服務。
一檔：點菜服務、入座服務、上菜服務、餵食服務、加飯服務；
二檔：點菜服務、上菜服務、加飯服務；
三檔：點菜服務、上菜服務。
服務降級，就是所有客人默認都是一檔服務，但是當我忙不過來的時候，我將服務等級下調至二檔或三檔，保障我飯店能正常點菜、上菜就行了，其餘的非核心服務先不提供。
服務熔斷：
還是拿餐館舉例子，我的飯店只能容納100人同時就餐，忽然有一天，一下來了1000人吃飯。
為了不把我的餐館擠爆，我決定，先不對外提供服務，來一個客人，我就趕走一個，等一段時間過後，我嘗試著接納一些人就餐，確認沒問題了，我再正常營業。
概念梳理完畢，我們發現，不管是服務熔斷還是降級，對於用戶來說，都是非常不好的體驗，那我們為啥還要這樣做呢？回答這個問題，我們還是以開飯店來舉例子：
先說明，我們現在的項目，是微服務項目，對應到「飯店例子」中，我們開的是連鎖飯店，而不是一個小餐館。
屁股決定思維，既然我們開的是連鎖飯店，就得以大局為重。一個飯店暫停營業了，雖然少了當天的營業額，但是對於我們整個的品牌影響不大。反過來，如果不進行服務熔斷等措施，用戶強行就餐之後，體驗不好，回頭上網就是一個差評，這樣影響的就不只是一個飯店的營業額，而是整個品牌的價值，後果嚴重的很。
從連鎖飯店回到微服務項目，一個微服務不好用了，我們進行熔斷降級，可減少其對我們整個微服務框架的影響，但是，如果不進行處理，可能由於一個節點失效，到時所有微服務雪崩，到最後整個微服務項目癱瘓，這顯然是我們無法承受的，所以，服務熔斷、限流、降級，在微服務架構中，很重要，必須做。
話又說回來了，咋做？
前輩們早就想好，現在人們大多數使用如下兩個框架：
Hystrix : 由Netflix公司開發的一個進行服務熔斷、降級的框架，但是很不幸，進入維護狀態了
sentinel : 阿里開發的開源框架，提供可視化介面，多語言支援的服務熔斷降級限流框架
4、微服務網關
微服務項目，首先他得是對外提供服務的，上面幾個視角我們多是從微服務之間相互調用這一場景來考慮，這一小節，我們得轉變視角，由內部看到外部，當客戶端或者是用戶，調用微服務的應用介面時，我們需要考慮哪些問題呢？
（1）首先需要考慮的是定址，微服務伴隨著服務升級，擴容等，其IP、埠一定是在變著的，微服務內部之間調用尚可以通過註冊中心+Feign來進行，但是客戶端的請求介面調用地址如何處理呢？
（2）其次是許可權認證，微服務如何知道該次請求的客戶端是合法的呢？
有人說，可以每個微服務節點都寫一套許可權認證邏輯（現在我們原始項目就是這麼做的/(ㄒoㄒ)/~~），這種方法是不可取的，會造成程式碼膨脹，同時，若許可權認證邏輯變更，得挨個修改每個項目中的程式碼，要瘋掉了。
或者寫一個統一許可權認證工具，通過jar包形式集成在各個項目中。這種方式尚可，但是如果我要進行版本升級，得所有微服務挨個停止、升級、重啟，運維同事估計要提著大刀來砍你了。
（3）對於外部的請求，我想知道哪些請求是比較熱門的，每天有多少客戶端請求，並記錄日誌，這個需求如何處理呢？
問題一旦可以明確，就相當於解決了一半。這個時候，很明顯需要一個大管家，管理客戶端到伺服器的請求，來解決我們上述這些問題，所以微服務網關這個概念出現了。
微服務網關概念，摘自wiki百科：
轉發其他伺服器通訊數據的伺服器，接收從客戶端發送來的請求時，它就像自己擁有資源的源伺服器一樣對請求進行處理。有時客戶端可能都不會察覺，自己的通訊目標是一個網關。
微服務網關主要職能：
請求接入：作為所有 API 介面服務請求的接入點，管理所有的接入請求；
業務聚合：作為所有後端業務服務的聚合點，所有的業務服務都可以在這裡被調用；
中介策略：實現安全、驗證、路由、過濾、流控，快取等策略，進行一些必要的中介處理；
統一管理：提供配置管理工具，對所有 API 服務的調用生命周期和相應的中介策略進行統一管理。
（參考//www.jianshu.com/p/a2f292221b5c）
微服務網關框架：
Zuul : 由Netflix公司開發，已經進入維護狀態了。
Zuul2 : 還在開發過程中，多次跳票。
Spring Cloud GateWay ：Spring Cloud開發，在SpringMvc上構建的API網關框架。
5、配置統一管理
原來的單應用項目，一個項目的配置文件集中的寫在幾個配置文件中，由於項目文件不多，維護、配置起來都比較方便，不能算作問題。但是微服務架構下，單個服務都擁有著自己的配置文件，當服務變多，再考慮到開發、測試、生產環境使用不同的配置文件，配置工作一下就變得複雜了起來，需要進行統一管理，方便配置修改及部署上線。
現在開源的配置管理框架：
Spring Cloud Config : Spring開發的配置服務，可以從github、支援JDBC的資料庫或者其他文件系統中拉取配置。
Nacos ：nacos除了有註冊中心的功能之外，還可以提供配置管理服務。
6、分散式事務
在單應用的項目中，我們的事務一般交給數據取進行處理，但是微服務項目，不同的微服務連接著不同的資料庫，原來的事務處理模式已經不可行了，那麼在分散式微服務的項目中，我們該如何進行事務管理呢？
現在有通用的四種解決思路：
兩階段提交（2PC）
TCC（Try-Confirm-Cancel）
可靠的消息最終一致性
最大努力通知
分散式事務知識點很多，這裡對四種思路不進行詳細的介紹，有興趣的同學自行學習。這裡直接給出參考結果：Seata。下面借用seata官網一句話：
Seata 是一款開源的分散式事務解決方案，致力於提供高性能和簡單易用的分散式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分散式解決方案。
三、整理
回到本文的最一開始，自2018年底，Netflix陸續宣布Eureka、Hystrix等框架進入維護狀態，不再進行新功能的開發，那麼2020年，微服務項目該用啥子框架呢？推薦整理如下：
微服務的註冊與發現：Nacos、Consul、Zookeeper
微服務調用：OpenFeign
服務降級、限流、熔斷：Sentinel
微服務網關 ：Spring Cloud Gateway
配置統一管理：Nacos
分散式事務：Seata
本文從上述六個角度進行了微服務常用框架的梳理，一個好的微服務項目，需要考慮的點多的很，各位看官，僅供參考。
