① API網關從入門到放棄
假設你正在開發一個電商網站，那麼這里會涉及到很多後端的微服務，比如會員、商品、推薦服務等等。
那麼這里就會遇到一個問題，APP/Browser怎麼去訪問這些後端的服務? 如果業務比較簡單的話，可以給每個業務都分配一個獨立的域名(https://service.api.company.com)，但這種方式會有幾個問題:
更好的方式是採用API網關，實現一個API網關接管所有的入口流量，類似Nginx的作用，將所有用戶的請求轉發給後端的伺服器，但網關做的不僅僅只是簡單的轉發，也會針對流量做一些擴展，比如鑒權、限流、許可權、熔斷、協議轉換、錯誤碼統一、緩存、日誌、監控、告警等，這樣將通用的邏輯抽出來，由網關統一去做，業務方也能夠更專注於業務邏輯，提升迭代的效率。
通過引入API網關，客戶端只需要與API網關交互，而不用與各個業務方的介面分別通訊，但多引入一個組件就多引入了一個潛在的故障點，因此要實現一個高性能、穩定的網關，也會涉及到很多點。
API 注冊
業務方如何接入網關?一般來說有幾種方式。
協議轉換
內部的API可能是由很多種不同的協議實現的，比如HTTP、Dubbo、GRPC等，但對於用戶來說其中很多都不是很友好，或者根本沒法對外暴露，比如Dubbo服務，因此需要在網關層做一次協議轉換，將用戶的HTTP協議請求，在網關層轉換成底層對應的協議，比如HTTP -> Dubbo, 但這里需要注意很多問題，比如參數類型，如果類型搞錯了，導致轉換出問題，而日誌又不夠詳細的話，問題會很難定位。
服務發現
網關作為流量的入口，負責請求的轉發，但首先需要知道轉發給誰，如何定址，這里有幾種方式:
服務調用
網關由於對接很多種不同的協議，因此可能需要實現很多種調用方式，比如HTTP、Dubbo等，基於性能原因，最好都採用非同步的方式，而Http、Dubbo都是支持非同步的，比如apache就提供了基於NIO實現的非同步HTTP客戶端。
因為網關會涉及到很多非同步調用，比如攔截器、HTTP客戶端、bbo、redis等，因此需要考慮下非同步調用的方式，如果基於回調或者future的話，代碼嵌套會很深，可讀性很差，可以參考zuul和spring cloud gateway的方案，基於響應式進行改造。
優雅下線
性能
網關作為所有流量的入口，性能是重中之重，早期大部分網關都是基於同步阻塞模型構建的，比如Zuul 1.x。但這種同步的模型我們都知道，每個請求/連接都會佔用一個線程，而線程在JVM中是一個很重的資源，比如Tomcat默認就是200個線程，如果網關隔離沒有做好的話，當發生網路延遲、FullGC、第三方服務慢等情況造成上游服務延遲時，線程池很容易會被打滿，造成新的請求被拒絕，但這個時候其實線程都阻塞在IO上，系統的資源被沒有得到充分的利用。另外一點，容易受網路、磁碟IO等延遲影響。需要謹慎設置超時時間，如果設置不當，且服務隔離做的不是很完善的話，網關很容易被一個慢介面拖垮。
而非同步化的方式則完全不同，通常情況下一個CPU核啟動一個線程即可處理所有的請求、響應。一個請求的生命周期不再固定於一個線程，而是會分成不同的階段交由不同的線程池處理，系統的資源能夠得到更充分的利用。而且因為線程不再被某一個連接獨占，一個連接所佔用的系統資源也會低得多，只是一個文件描述符加上幾個監聽器等，而在阻塞模型中，每條連接都會獨佔一個線程，而線程是一個非常重的資源。對於上游服務的延遲情況，也能夠得到很大的緩解，因為在阻塞模型中，慢請求會獨佔一個線程資源，而非同步化之後，因為單條連接所佔用的資源變的非常低，系統可以同時處理大量的請求。
如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不錯的非同步網關選型，另外也可以基於Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的非同步支持進行自研。
緩存
對於一些冪等的get請求，可以在網關層面根據業務方指定的緩存頭做一層緩存，存儲到Redis等二級緩存中，這樣一些重復的請求，可以在網關層直接處理，而不用打到業務線，降低業務方的壓力，另外如果業務方節點掛掉，網關也能夠返回自身的緩存。
限流
限流對於每個業務組件來說，可以說都是一個必須的組件，如果限流做不好的話，當請求量突增時，很容易導致業務方的服務掛掉，比如雙11、雙12等大促時，介面的請求量是平時的數倍，如果沒有評估好容量，又沒有做限流的話，很容易服務整個不可用，因此需要根據業務方介面的處理能力，做好限流策略，相信大家都見過淘寶、網路搶紅包時的降級頁面。
因此一定要在接入層做好限流策略，對於非核心介面可以直接將降級掉，保障核心服務的可用性，對於核心介面，需要根據壓測時得到的介面容量，制定對應的限流策略。限流又分為幾種:
穩定性
穩定性是網關非常重要的一環，監控、告警需要做的很完善才可以，比如介面調用量、響應時間、異常、錯誤碼、成功率等相關的監控告警，還有線程池相關的一些，比如活躍線程數、隊列積壓等，還有些系統層面的，比如CPU、內存、FullGC這些基本的。
網關是所有服務的入口，對於網關的穩定性的要求相對於其他服務會更高，最好能夠一直穩定的運行，盡量少重啟，但當新增功能、或者加日誌排查問題時，不可避免的需要重新發布，因此可以參考zuul的方式，將所有的核心功能都基於不同的攔截器實現，攔截器的代碼採用Groovy編寫，存儲到資料庫中，支持動態載入、編譯、運行，這樣在出了問題的時候能夠第一時間定位並解決，並且如果網關需要開發新功能，只需要增加新的攔截器，並動態添加到網關即可，不需要重新發布。
熔斷降級
熔斷機制也是非常重要的一項。若某一個服務掛掉、介面響應嚴重超時等發生，則可能整個網關都被一個介面拖垮，因此需要增加熔斷降級，當發生特定異常的時候，對介面降級由網關直接返回，可以基於Hystrix或者Resilience4j實現。
日誌
由於所有的請求都是由網關處理的，因此日誌也需要相對比較完善，比如介面的耗時、請求方式、請求IP、請求參數、響應參數(注意脫敏)等，另外由於可能涉及到很多微服務，因此需要提供一個統一的traceId方便關聯所有的日誌，可以將這個traceId置於響應頭中，方便排查問題。
隔離
比如線程池、http連接池、redis等應用層面的隔離，另外也可以根據業務場景，將核心業務部署帶單獨的網關集群，與其他非核心業務隔離開。
網關管控平台
這塊也是非常重要的一環，需要考慮好整個流程的用戶體驗，比如接入到網關的這個流程，能不能盡量簡化、智能，比如如果是bbo介面，我們可以通過到git倉庫中獲取源碼、解析對應的類、方法，從而實現自動填充，盡量幫用戶減少操作；另外介面一般是從測試->預發->線上，如果每次都要填寫一遍表單會非常麻煩，我們能不能自動把這個事情做掉，另外如果網關部署到了多個可用區、甚至不同的國家，那這個時候，我們還需要介面數據同步功能，不然用戶需要到每個後台都操作一遍，非常麻煩。
這塊個人的建議是直接參考阿里雲、aws等提供的網關服務即可，功能非常全面。
其他
其他還有些需要考慮到的點，比如介面mock，文檔生成、sdk代碼生成、錯誤碼統一、服務治理相關的等，這里就不累述了。
目前的網關還是中心化的架構，所有的請求都需要走一次網關，因此當大促或者流量突增時，網關可能會成為性能的瓶頸，而且當網關接入的大量介面的時候，做好流量評估也不是一項容易的工作，每次大促前都需要跟業務方一起針對介面做壓測，評估出大致的容量，並對網關進行擴容，而且網關是所有流量的入口，所有的請求都是由網關處理，要想准確的評估出容量很復雜。可以參考目前比較流行的ServiceMesh，採用去中心化的方案，將網關的邏輯下沉到sidecar中，
sidecar和應用部署到同一個節點，並接管應用流入、流出的流量，這樣大促時，只需要對相關的業務壓測，並針對性擴容即可，另外升級也會更平滑，中心化的網關，即使灰度發布，但是理論上所有業務方的流量都會流入到新版本的網關，如果出了問題，會影響到所有的業務，但這種去中心化的方式，可以先針對非核心業務升級，觀察一段時間沒問題後，再全量推上線。另外ServiceMesh的方案，對於多語言支持也更友好。
② 什麼是微服務架構主流的微服務如何實現
簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
1、SpringCloud
Spring Cloud , 來自Spring，具有Spring 社區的強大支撐，還有Netflix強大的後盾與技術輸出。Netflix作為一家成功實踐微服務架構的互聯網公司在幾年前就把幾乎整個微服務框架棧開源貢獻給了社區，這些框架開源的整套服務架構套件是Spring Cloud的核心。
- Eureka:服務注冊發現框架；
- Zuul:服務網關；
- Karyon：服務端框架；
- Ribbon：客戶端框架；
- Hystrix：服務容錯組件；
- Archaius：服務配置組件；
- Servo：Metrics組件；
- Blitz4j：日誌組件；
2、Dubbo
Dobbo是一個分布式服務框架，是阿里開放的微服務化治理框架，致力於提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分(官網)
- 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式；
- 集群容錯: 提供基於介面方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持；
- 自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
Dubbo 也是採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 侵入，只需用 Spring 載入 Dubbo的配置即可，Dubbo 基於 Spring 的 Schema 擴展進行載入。當然也支持官方不推薦的 API 調用方式。
3、lstio
lstio 作為用於微服務聚合層管理的新銳項目，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵），首個共同聯合開源的項目，提供了統一的連接，安全，管理和監控微服務的方案。
目前首個測試版是針對Kubernetes環境的，社區宣稱在未來幾個月內會為虛擬機和Cloud Foundry 等其他環境增加支持。lstio將 流量管理添加到微服務中，並為增值功能（如安全性、監控、路由、連接管理和策略）創造了基礎。
- HTTP、gRPC 和 TCP 網路流量自動負載均衡；
- 提供了豐富的路由規則，實現細顆粒度的網路流量行為控制；
- 流量加密、服務件認證，以及強身份聲明；
- 全范圍（Fleet-wide）的策略執行；
- 深度遙測和報告。
③ 高並發網站架構的設計方案是怎樣的
技術這玩意兒，你不深入使用它，你就不知道它有多牛，更不知道會有多難！
並發:指定時間段內的請求數！
高並發:指定時間段內的超多請求數！
比如tomcat，單機最大支持並發數為8000左右，redis理論值可達到幾萬！
那麼怎麼設計一套可支持高並發的系統呢？使用技術如下:
1，分布式系統，微服務:使用springcloud家族包括eureka，zuul，feign，hysrix等或者bbo搭建一套微服務框架！
2，前後端分離:使用node.js搭建前端服務系統！
3，靜態化處理:將頁面，後台枚舉，資料庫定義表等使用靜態處理方式做處理！
4，文件伺服器剝離:採用單獨的文件伺服器，防止頁面載入的阻塞！
5，緩存:使用redis，memcache等將運行時數據緩存，代替頻繁的操作資料庫！
6，資料庫:讀寫分離或者分庫分表，採用druid等有性能監控系統的資料庫連接框架！
7，消息中間件:使用xxxmq，kafka等消息中間件，解耦服務，而且非同步處理效率更高！
8，反向代理:使用nginx等負載均衡服務！
9，代碼層:避免大量創建對象，避免阻塞IO，避免多層for循環，避免線程死鎖，避免大量同步！
10，各種優化:包括jvm優化，表結構優化，sql優化，關鍵欄位加索引（注意避免索引失效），連接池優化等等！
11，搜索引擎:sql有大量的like語句，有必要切換成solr等搜索引擎！
12，cdn:使用CDN技術將請求分發到最合適的主機上，避免網路傳輸的延遲！
13，使用batch:增刪改能一次做的別分為兩次，但要注意batch合理設計，防止數據丟失！
14，限流，削峰！
大型網站遇到的挑戰，主要是大量的用戶，高並發的訪問，就算一個簡單的增刪查改的功能，如果面對的是百萬、千萬甚至億級的用戶，都是一件難度很大的事情。
數據從資料庫到瀏覽器的過程：資料庫->應用數據集->內存對象->動態頁面->HTTP伺服器->用戶瀏覽器。 那麼我們可以把高並發的設計分成幾個層次：
前端是指，用戶的請求還沒有到服務前的環節。
系統架構大了，部署的伺服器多了，很多事情不可能通過人工完成了，比如一個介面調用發生了錯誤，不可能人工登錄到伺服器上去查日誌吧，所以這些東西也是必不可少的。
都是說個大概，後面有機會的話，會把每一項都展開詳細說明。
希望我的回答能夠幫助到你！
我們通過這些架構要素來衡量我們整體系統架構設計的優劣，來判斷是否達到了我們的要求。
性能是大型網站架構設計的一個重要方面，任何軟體架構設計方案都必須考慮可能帶來的性能問題，也正因為性能問題幾乎無處不在，在請求鏈路的任何一個環節，都是我們去做極致性能優化方案中的切入點。
衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一台或者多台伺服器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。
網站的伸縮性是指不需要改變伺服器的硬體設計，僅僅靠改變應用伺服器的部署數量，就可以擴大或縮小伺服器的處理能力。
網站快速發展，功能不斷擴展，如何設計網站的架構使其能夠快速響應需求變化，是網站可擴展架構的主要目標。
互聯網跟傳統軟體不同，它是開放的，任何人在任何地方都可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。
安全性架構，具體來說說就是保證數據的保密性、完整性、真實性、佔有性。
要完全掌握大型網站的架構設計方案，或許你可以點擊我頭像，進入我的專欄"深入大型網站核心架構實戰"。
這期專欄是筆者總結了當下這些互聯網行業中相對成熟且經過大型網站檢驗的技術和方案，內容涵蓋構建大型互聯網系統服務所需的關鍵技術。
④ Spring微服務灰度發布（熱部署）的實現（二）
接著上篇說，我們微服務中用到的nepxion discovery主要採用了三種灰度發布方式，一種是web圖形化界面發布，二是zuul過濾器灰度發布，三是業務參數策略灰度發布。下面將重點介紹三種方式的實現。
一、web圖形化界麵灰度發布
因為我們項目用到了eureka注冊中心，所以選擇web圖形化界麵灰度發布比較合適。
1） 首先需要建立一個discovery控制台工程console, 埠為2222，控制台工程負責web圖形化界面請求的處理，運行console工程。
2） 下載discovery ui,地址：https://github.com/Nepxion/DiscoveryUI，運行discovery UI，埠為8090
3）瀏覽器中輸入localhost:8090,即可打開控制台，如下
注意：全鏈路灰度發布需要在「配置中心」下才可用。灰度發布配置中心，負責存儲全鏈路灰度發布規則，並將規則推送到各個微服務中。而配置中心可用nacos，redis等，Discovery 中提供了相應配置中心的插件包。
二、zuul網關過濾器灰度發布
通過網關過濾器傳遞Http Header的方式傳遞全鏈路灰度路由規則。下面代碼只適用於Zuul和Spring Cloud Gateway網關，Service微服務不需要加該方式。
三、業務參數在策略類中自定義灰度路由規則
通過策略方式自定義灰度路由規則。下面代碼既適用於Zuul和Spring Cloud Gateway網關，也適用於Service微服務，同時全鏈路中網關和服務都必須加該方式
上面說了具體灰度規則發布方式，那究竟怎麼定義灰度規則呢？？
規則是基於XML或者Json為配置方式，存儲於本地文件或者遠程配置中心，可以通過遠程配置中心修改的方式達到規則動態化。其核心代碼參考discovery-plugin-framework以及它的擴展、discovery-plugin-config-center以及它的擴展和discovery-plugin-admin-center等，規則示例
XML示例（Json示例見discovery-springcloud-example-service下的rule.json）
黑/白名單的IP地址注冊的過濾規則
微服務啟動的時候，禁止指定的IP地址注冊到服務注冊發現中心。支持黑/白名單，白名單表示只允許指定IP地址前綴注冊，黑名單表示不允許指定IP地址前綴注冊。規則如何使用，見示例說明
最大注冊數的限制的過濾規則
微服務啟動的時候，一旦微服務集群下注冊的實例數目已經達到上限（可配置），將禁止後續的微服務進行注冊。規則如何使用，見示例說明
黑/白名單的IP地址發現的過濾規則
微服務啟動的時候，禁止指定的IP地址被服務發現。它使用的方式和「黑/白名單的IP地址注冊的過濾規則」一致
版本訪問的灰度發布規則
版本權重的灰度發布規則
全局版本權重的灰度發布規則
區域權重的灰度發布規則
全局區域權重的灰度發布規則
網關端全鏈路路由策略的灰度發布規則
注意 路由策略的入口有三個（以{"discovery-springcloud-example-a":"1.0", "discovery-springcloud-example-b":"1.0", "discovery-springcloud-example-c":"1.0;1.2"}）為例：
其作用的優先順序為外界傳入>網關Filter指定>配置中心或者本地rule.xml配置
您可以根據自己需求，自由定義灰度發布規則，靈活實現微服務的灰度發布。
源碼位置：https://github.com/Nepxion/Discovery