目錄結構
微服務架構相關
大型網站架構演變過程
網站架構演變演變過程
傳統架構 → 分佈式架構 → SOA架構 → 微服務架構
什麼是分佈式架構
分佈式架構就是將傳統結構按照模塊進行拆分，不同的人負責不同的模塊，不會產生代碼衝突問題，方便開發。
什麼是SOA架構
SOA架構就是將業務邏輯層提取出來，將相似的業務邏輯形成一個服務，提供外部訪問接口，服務之間訪問通過RPC調用實現。
什麼是微服務架構
微服務類似於SOA架構，但是比SOA架構粒度更細，更輕量。
微服務架構與SOA架構區別
SOA基於WebService和ESP實現，底層基於HTTP協議和使用XML方式傳輸，XML在網絡傳輸過程中會產生大量冗餘。微服務由SOA架構演變而來，繼承了SOA架構的優點，同時對SOA架構缺點進行改善，數據傳輸採用JSON格式，相比於XML更輕量和快捷，粒度更細，更加便於敏捷開發。SOA數據庫會存在共享，微服務提倡每個服務連接獨立的數據庫。
微服務框架SpringCloud
什麼是SpringCloud
SpringCloud是微服務的一種解決方案，依賴SpringBoot實現。包含註冊中心(eureka)、客戶端負載均衡(Ribbon)、網關(zull)、分佈式鎖、分佈式會話等。
爲什麼要使用SpringCloud
SpringCloud是一套非常完整的微服務解決方案，俗稱"微服務全家桶"，幾乎內置了微服務所使用的各種技術，可以不必集成第三方依賴。
SpringCloud服務註冊發現原理
每個SpringCloud服務器啓動後向註冊中心註冊本服務器信息，如服務別名、服務器IP、端口號等，其他服務進行請求時先根據服務別名從註冊中心獲取到目標服務器IP和端口號，並將獲取到的信息緩存到本地，然後通過本地使用HttpClient等技術進行遠程調用。
SpringCloud 支持那些註冊中心
Eureka、Consul、Zookeeper
現在Eureka閉源了，可以通過什麼註冊中心替代Eureka呢？
Consul或Zookeeper
談談你對微服務服務治理的思想
Eureka如何實現高可用
啓動多臺Eureka服務器，然後作爲SpringCloud服務互相註冊，客戶端從Eureka集羣獲取信息時，按照註冊的Eureka順序對第一個Eureka進行訪問。
@LoadBalanced註解的作用
開啓客戶端負載均衡。
Nginx與Ribbon的區別
Nginx是反向代理同時可以實現負載均衡，nginx攔截客戶端請求採用負載均衡策略根據upstream配置進行轉發，相當於請求通過nginx服務器進行轉發。Ribbon是客戶端負載均衡，從註冊中心讀取目標服務器信息，然後客戶端採用輪詢策略對服務直接訪問，全程在客戶端操作。
Ribbon底層實現原理
Ribbon使用discoveryClient從註冊中心讀取目標服務信息，對同一接口請求進行計數，使用%取餘算法獲取目標服務集羣索引，返回獲取到的目標服務信息。
SpringCloud有幾種調用接口方式
使用Feign和RestTemplate
DiscoveryClient的作用
可以從註冊中心中根據服務別名獲取註冊的服務器信息。
談談服務雪崩效應
雪崩效應是在大型互聯網項目中，當某個服務發生宕機時，調用這個服務的其他服務也會發生宕機，大型項目的微服務之間的調用是互通的，這樣就會將服務的不可用逐步擴大到各個其他服務中，從而使整個項目的服務宕機崩潰.發生雪崩效應的原因有以下幾點
1.單個服務的代碼存在bug. 2請求訪問量激增導致服務發生崩潰(如大型商城的槍紅包，秒殺功能). 3.服務器的硬件故障也會導致部分服務不可用.
在微服務中，如何保護服務?
一般使用使用Hystrix框架，實現服務隔離來避免出現服務的雪崩效應，從而達到保護服務的效果。當微服務中，高併發的數據庫訪問量導致服務線程阻塞，使單個服務宕機，服務的不可用會蔓延到其他服務，引起整體服務災難性後果，使用服務降級能有效爲不同的服務分配資源,一旦服務不可用則返回友好提示，不佔用其他服務資源，從而避免單個服務崩潰引發整體服務的不可用.
服務雪崩效應產生的原因
因爲Tomcat默認情況下只有一個線程池來維護客戶端發送的所有的請求，這時候某一接口在某一時刻被大量訪問就會佔據tomcat線程池中的所有線程，其他請求處於等待狀態，無法連接到服務接口。
談談Hystrix服務保護的原理
通過服務降級、服務熔斷、服務隔離爲高併發服務提供保護。
談談服務降級、熔斷、服務隔離
服務降級：當客戶端請求服務器端的時候，防止客戶端一直等待，不會處理業務邏輯代碼，直接返回一個友好的提示給客戶端。
服務熔斷是在服務降級的基礎上更直接的一種保護方式，當在一個統計時間範圍內的請求失敗數量達到設定值（requestVolumeThreshold）或當前的請求錯誤率達到設定的錯誤率閾值（errorThresholdPercentage）時開啓斷路，之後的請求直接走fallback方法，在設定時間（sleepWindowInMilliseconds）後嘗試恢復。
服務隔離就是Hystrix爲隔離的服務開啓一個獨立的線程池，這樣在高併發的情況下不會影響其他服務。服務隔離有線程池和信號量兩種實現方式，一般使用線程池方式。
服務降級底層是如何實現的？
Hystrix實現服務降級的功能是通過重寫HystrixCommand中的getFallback()方法，當Hystrix的run方法或construct執行發生錯誤時轉而執行getFallback()方法。
分佈式配置中心有那些框架？
Apollo(阿波羅)、zookeeper、springcloud config。
分佈式配置中心的作用？
動態變更項目配置信息而不必重新部署項目。
SpringCloud Config 可以實現實時刷新嗎？
springcloud config實時刷新採用SpringCloud Bus消息總線。
什麼是網關?
網關相當於一個網絡服務架構的入口，所有網絡請求必須通過網關轉發到具體的服務。
網關的作用是什麼
統一管理微服務請求，權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等
網關與過濾器有什麼區別
網關是對所有服務的請求進行分析過濾，過濾器是對單個服務而言。
常用網關框架有那些？
Nginx、Zuul、Gateway
Zuul與Nginx有什麼區別？
Zuul是java語言實現的，主要爲java服務提供網關服務，尤其在微服務架構中可以更加靈活的對網關進行操作。Nginx是使用C語言實現，性能高於Zuul，但是實現自定義操作需要熟悉lua語言，對程序員要求較高，可以使用Nginx做Zuul集羣。
既然Nginx可以實現網關？爲什麼還需要使用Zuul框架
Zuul是SpringCloud集成的網關，使用Java語言編寫，可以對SpringCloud架構提供更靈活的服務。
如何設計一套API接口
考慮到API接口的分類可以將API接口分爲開發API接口和內網API接口，內網API接口用於局域網，爲內部服務器提供服務。開放API接口用於對外部合作單位提供接口調用，需要遵循Oauth2.0權限認證協議。同時還需要考慮安全性、冪等性等問題。
ZuulFilter常用有那些方法
Run()：過濾器的具體業務邏輯
shouldFilter()：判斷過濾器是否有效
filterOrder()：過濾器執行順序
filterType()：過濾器攔截位置
如何實現動態Zuul網關路由轉發
通過path配置攔截請求，通過ServiceId到配置中心獲取轉發的服務列表，Zuul內部使用Ribbon實現本地負載均衡和轉發。
Zuul網關如何搭建集羣
使用Nginx的upstream設置Zuul服務集羣，通過location攔截請求並轉發到upstream，默認使用輪詢機制對Zuul集羣發送請求。
SpringBoot快速開發框架
什麼是SpringBoot
SpringBoot是快速開發的Spring框架，能夠快速整合主流框架，簡化xml配置，採用全註解化，內置Http服務器（如tomcat、jetty等），通過java部署運行。
爲什麼要用SpringBoot
快速開發，快速整合，配置簡化、內嵌服務容器
SpringBoot啓動方式
主類@SpringBootApplication註解或添加@ComponentScan和@EnableAutoConfiguration註解，使用@SpringBootApplication時注意自動掃描當前包
SpringBoot與SpringMVC 區別
SpringMVC是SpringBoot的Web開發框架
SpringBoot與SpringCloud 區別
SpringBoot是快速開發的Spring框架，SpringCloud是完整的微服務框架， SpringCloud依賴於SpringBoot。
SpringBoot中用那些註解
@EnableAutoConfiguration作用
自動掃描並添加jar包依賴
@SpringBootApplication原理
是一個組合註解，相當於@EnableAutoConfiguration和@ComponentScan
SpringBoot熱部署使用什麼？
devtools
熱部署原理是什麼？
熱部署的實現原理主要依賴java的類加載機制，在實現方式可以概括爲在容器啓動的時候起一條後臺線程，定時的檢測類文件的時間戳變化，如果類的時間戳變掉了，則重新加載整個應用的class文件，同時重啓服務，重新部署。
熱部署原理與熱加載區別是什麼
熱加載是在運行時重新加載class文件，不會重啓服務。
你們項目中異常是如何處理
在web項目中，使用全局捕獲異常返回統一錯誤信息。
SpringBoot如何實現異步執行
在啓動類添加@EnableAsync表示開啓對異步任務的支持，在異步服務上添加@Async
SpringBoot多數據源拆分的思路
先在properties配置文件中配置兩個數據源，創建分包mapper，使用@ConfigurationProperties讀取properties中的配置，使用@MapperScan註冊到對應的mapper包中
SpringBoot多數據源事務如何管理
第一種方式是在service層的@TransactionManager中使用transactionManager指定DataSourceConfig中配置的事務
第二種是使用jta-atomikos實現分佈式事務管理
SpringBoot如何實現打包
進入項目目錄在控制檯輸入mvn clean package，clean是清空已存在的項目包，package進行打包
SpringBoot性能如何優化
如果項目比較大，類比較多，不使用@SpringBootApplication，採用@Compoment指定掃包範圍
在項目啓動時設置JVM初始內存和最大內存相同
將springboot內置服務器由tomcat設置爲undertow
SpringBoot執行流程
使用SpringApplication.run()啓動，在該方法所在類添加@SpringBootApplication註解，該註解由@EnableAutoConfiguration和@ComponentScan等註解組成，@EnableAutoConfiguration自動加載SpringBoot配置和依賴包，默認使用@ComponentScan掃描當前包及子包中的所有類，將有spring註解的類交給spring容器管理
SpringBoot底層實現原理
使用maven父子包依賴關係加載相關jar包，使用java操作Spring的初始化過程生成class文件，然後用java創建tomcat服務器加載這些class文件
SpringBoot裝配Bean的原理
通過@EnableAutoConfiguration自動獲取配置類信息，使用反射實例化爲spring類，然後加載到spring容器
分佈式協調工具
什麼是ZooKeeper
ZooKeeper是Java語言編寫的開源框架，用以協調分佈式的一個工具。
ZooKeeper存儲結構與特性
類似於樹形結構，同一層節點名稱不能重複。節點類型分爲臨時節點與持久節點
Zookeeper以節點方式進行存儲，類似於xml樹狀結構；
a. 節點又分爲節點名稱（全路徑不能重複）和 節點值
節點類型有持久節點（持久化在硬盤上）和臨時節點（會話與臨時節點同死同生）
b、節點功能：每個節點都有通知功能，當這個節點增刪改的時候都會有事件通知
Zookeeper主要有一下特性
a、一致性：數據按照順序分批入庫；
b、原子性：事務要麼成功要麼失敗，不會局部化；
c、單一視圖：客戶端連接集羣中任何一個zk節點，數據都是一致的；
d、可靠性：每次對zk的操作狀態都會保存在服務端；
e、實時性：客戶端可以讀取到zk服務器的 新數據；
ZooKeeper中臨時節點與持久節點區別
持久節點是持久化在硬盤上，會話斷開後節點也能查到；
臨時節點與會話保持連接，會話在節點在，會話斷開，節點也會刪除；
ZooKeeper應用場景
A. 服務註冊與發現的中心
B、利用臨時節點特性解決分佈式鎖
C、分佈式配置中心
D、基於哨兵機制實現選舉策略
E、實現本地負載均衡
F、基於節點事件通知特性可做消息中間件
G、分佈式事務
什麼場景下會導致ZooKeeper發生延遲通知
watch事件延遲：節點被修改後，會有事件通知發往觀察者，直到接收到watch事件，觀察者纔會知道節點被修改了；當管擦着接到watch事件的那一刻，該節點又被其他修改者修改了，而 近的watch事件還沒有通知到觀察者，就會造成延遲通知。
分佈式鎖有那些實現方案
a. 基於setNx實現分佈式鎖（麻煩，需要考慮死鎖及釋放問題）
b、redission實現分佈式鎖
c、zookeeper實現分佈式鎖（基於臨時節點，實現簡單，效率高，失效時間容易控制）
ZooKeeper實現分佈式鎖的原理
多個jvm在同一個zookeeper上創建同一個節點（臨時節點），哪個jvm能創建成功，就表示它拿到了鎖，剩下的jvm保持對這個節點的監聽，一旦發現這個節點被刪除了，那麼剩下的jvm就重新再創建這個節點，誰能創建成功誰能拿到鎖，依次循環下去。
ZooKeeper實現分佈式鎖與Redis實現分佈式鎖區別
Zookeeper通過創建臨時節點和利用監聽事件實現分佈式鎖，Redis使用setnx命令創建相同的key，因爲Redis的key保證唯一，先創建的先獲取鎖。
不斷的去嘗試，去獲取鎖，比較耗性能
Zookeeper實現分佈式鎖，即使獲取不到鎖，創建對鎖的監聽即可，不需要不斷去嘗試獲取 鎖，性能開銷小
Redis實現分佈式鎖，如果客戶端獲取到鎖的時候遇到bug或掛了，還需要等到超時時間過了以後才能重新獲取鎖
Zookeeper實現分佈式鎖，創建的是臨時節點，客戶端掛了，節點自然刪除，也就達到了自動釋放鎖的效果
使用Zookeeper實現服務Master選舉原理
多個服務器在啓動時候，會在Zookeeper上創建相同的臨時節點，誰如果能夠創建成功，誰就爲主。如果主服務器宕機，其他備用節點獲取監聽信息，重新創建節點，選出主服務器。
ZooKeeper集羣選舉原理
每臺Zookeeper服務器啓動時會發起投票，每次投票後，服務器統計投票信息，如果有機器獲取半數以上的投票數則leader產生。
微服務常用解決方案
談談網站跨域解決方案
a、使用jsonp 缺點只能發送get請求
b、使用httpclient進行轉發，效率低
c、設置響應頭允許跨域
d、使用Nginx搭建api網關
e、使用Zuul微服務搭建api接口網關
分佈式Session一致性問題
a、使用Nginx反向代理，即IP綁定，同一個ip只能在同一個機器上訪問
b、使用數據庫，但性能不高
c、tomcat內置了對session同步的支持，但可能會產生延遲
d、使用Spring-Session框架，相當於把session放到redis中
e、使用token令牌代替session
分佈式鎖解決方案
分佈式事務解決方案
分佈式任務調度平臺解決方案
分佈式事務解決方案
分佈式日誌收集解決方案
分佈式全局id生成方案
分佈式服務追蹤與調用鏈系統解
分佈式消息系統與中間件
消息中間件產生的背景
傳統的Web項目採用http協議基於請求和響應傳輸信息，請求發出後必須等待服務器端響應，如果服務器端不會及時響應客戶端會一直等待。
Http協議同步接口調用失敗了怎麼做？
採用消息補償機制重新發送請求。
消息隊列異步通訊與同步通訊區別
同步通訊是客戶端直接將請求發往服務器，等待服務器處理完請求並返回響應信息後纔會繼續向下執行。消息隊列獨立於客戶端和服務器端，單獨架設消息隊列服務器，對於不必立即獲取響應和處理過程複雜的請求，客戶端可以將請求發往消息隊列然後立即返回，指定的消費者處理請求，這樣客戶端不必持續等待。
JMS消息通訊模型有那些
消息隊列：點對點，發佈訂閱
消息中間應用場景
發送郵件或短信的服務、秒殺、運行過程複雜耗時的服務。
發佈訂閱與點對點通訊的區別
發佈訂閱是生產者發佈一個主題，所有訂閱該主題的消費者都會參與消費，消息會被重複消費。點對點通訊是一個消息只能有一個消費者消費，需要保證數據的冪等性。
如何保證JMS可靠消息
ActiveMQ採用消息簽收機制保證數據的可靠性，消息簽收有三種方式：自動簽收、手動簽收、事務，默認自動簽收。如果是帶事務的消息，事務執行完畢後自動簽收，事務回滾則重新發送。
ActiveMQ服務端宕機了，消息會丟失嗎？
生產者可以通過setDeliveryMode方法設置消息模式，當設置未非持久化時服務器宕機後消息將銷燬，重啓服務器後無法繼續消費。當設置爲持久化時服務器宕機後消息將保存到服務器中，重啓後消費者還可以繼續消費未處理完畢的消息。
RabbitMQ與其他MQ有什麼不同？
RabbitMQ是用erlang語言實現，安裝RabbitMQ之前需要先安裝erlang環境。RabbitMQ只支持AMQP協議，用於對穩定性要求比較高的企業。
RabbitMQvirtualHost的作用
VirtualHost相當於是虛擬的RabbitMQ服務器，每個VirtualHost都是獨立的，起到隔離交換機、隊列的作用，不同的項目組可以連接到不同的VirtualHost不會互相影響。
談談RabbitMQ五種列隊形式
點對點模式：生產者生成的消息由一個消費者消費；
工作模式：在消費者集羣的情況下，可以根據消費者服務器的性能分配消息，即性能好的服務器多消費，性能次的少消費。
發佈訂閱模式：在生產者和隊列之間插入一個交換機，由交換機轉發到與該交換機綁定的隊列；
路由模式：路由模式是基於發佈訂閱模式，只是在生產者向交換機生產消息時板頂一個routingkey，交換機向綁定同一個routingkey的隊列轉發消息；
通配符模式：是對路由模式的補充，使用通配符進行routingkey匹配，通配符有#和*，#代表匹配多個，*代表匹配一個。
RabbitMQ四中交換機類型
Fanout：以這種方式連接到交換機的隊列都可以獲得交換機的轉發；
Direct：生產者綁定direct類型的交換機，在向交換機發送消息時綁定routingkey，交換機會將這條消息發送到相同routingkey的隊列。
Topic：和Direct相似，可以在routingKey中使用通配符，#代表多個匹配，*代表單個匹配，routingkey使用"."作爲分隔符。
Headers：類似Direct，使用多個消息代替路由鍵建立路由規則，通過消息頭匹配來轉發消息。
RabbitMQQMAP協議原理
在RabbitMQ中，生產者將消息發送到交換機，交換機將消息根據路由策略將消息發送到綁定的消息隊列，消費者通過消息隊列獲取並消費消息。
高併發解決方案
高性能Nginx+Lua
什麼是DNS解析域名
DNS域名解析就是講域名轉化爲不需要顯示端口（二級域名的端口一般爲80）的IP地址，域名解析的一般先去本地環境的host文件讀取配置，解析成對應的IP地址，根據IP地址訪問對應的服務器。若host文件未配置，則會去網絡運營商獲取對應的IP地址和域名.
你用過那些外網映射工具
花生殼,natapp,ngrok。
什麼是Nginx
Nginx是一個高級的輕量級的web服務器,由俄羅斯科學家開發的，具有如下優點:
1.佔用內存少，併發量強，支持多種併發連接，效率高.
2.能夠作爲負載均衡服務器和(內部直接支持 Rails 和 PHP)代理服務器。Nginx用C編寫開銷和CPU佔有小.
3.安裝啓動簡單，配置簡潔，bug少，一般幾個月不需要重新啓動且不會宕機，穩定性和安全性好.
Nginx的作用
反向代理、負載均衡、配置主備tomcat、動靜分離
Nginx 應用場景
做HTTP服務器、反向代理服務器、靜態資源服務器
什麼是反向代理
代替真實服務器接收網絡請求，然後將請求轉發到真實服務器
反向代理的作用
隱藏真實服務器，使真實服務器只能通過內網訪問，保護了真實服務器不被攻擊。配置負載均衡，減輕單臺真實服務器的壓力。配置主備服務器，保持服務穩定運行。
Nginx如何配置反向代理
首先到DNS服務器做域名解析，如果是局域網在hosts文件中配置IP和域名對應關係。編輯nginx的nginx.conf文件，配置server_name爲指向nginx服務器的域名，location攔截請求，如果是訪問nginx本地資源則配置root，如果是反向代理到真實服務器則配置proxy_pass爲服務器地址
說說常用Nginx的相關配置
upstream 負載均衡配置
server [IP] [weight] [backup] 配置tomcat集羣
proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout 連接時間、真實服務器響應時間、返回結果時間
location 匹配用戶請求的url
root 配置本地資源路徑
proxy_pass 配置真實服務器地址
請畫圖展示反向代理流程
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-oooNmxq4-1593756720458)(media/image2.png)]{width=“3.6356725721784775in” height=“2.0592016622922134in”}
LVS與Nginx區別
LVS是四層反向代理，基於TCP和UDP協議，可用於管理Nginx集羣，抗負載能力強。Nginx是七層反向代理，基於HTTP協議，用於管理真實服務器集羣。
location的作用
匹配用戶請求url，根據不同請求轉發到不同的服務器。
Nginx中如何配置負載均衡
在upstream中配置多個server，在location的proxy_pass配置爲http://+upstream名稱
四層負載均衡與七層負載均衡區別
四層負載均衡基於TCP和UDP協議，通過IP+端口號接受請求並轉發到服務器。七層負載均衡基於HTTP協議，通過url或主機名接收請求並轉發到服務器。
四層負載均衡有那些實現方案
LVS、F5
負載均衡有那些算法
輪詢算法:按照時間順序分配到不同的服務器，當其中一臺服務器宕機則被自動剔除，切換到正常的服務器。
權重算法:按照分配給服務器的權重比例來分發到不同服務器，權重比例越高，則訪問機率越大。
IP綁定(ip_hash):根據訪問的IP的哈希結果來判定，使同一個IP訪問一臺固定的後端服務器，同時解決動態頁面的session問題.
服務器集羣后，會產生了那些問題
分佈式鎖
分佈式全局ID
分佈式Session一致性問題
分佈式事務
分佈式任務調度
分佈式日誌收集
分佈式配置中心
什麼是動態負載均衡
一般情況下，使用nginx搭建服務器集羣，每次修改nginx.conf配置文件都需要重啓nginx服務器。動態負載均衡就是修改nginx.conf配置文件後不必重啓nginx而使配置生效。
Nginx如何實現動態負載均衡
搭建Nginx+Consul+Upsycn環境。Nginx實現服務的反向代理和負載均衡。Consul是一個開源的註冊中心和服務發現的框架，通過HTTP API來發現服務，註冊服務。同時支持故障發現，K/V存儲，多數據中心，Raft算法等多中高可用特性。Consul在Nginx動態負載均衡作用是
通過Http api註冊和發現服務.Upsycn是新浪微博的開源框架，在Nginx動態負載均衡的作用是Consul的後端的server列表，即獲取Nginx的上游服務器(Upstream server）信息,並動態更新Nginx的路由信息.
什麼是Http協議
超文本傳輸協議
Http協議組成部分
Http協議是基於TCP協議封裝成超文本傳輸協議，包括請求(request）和響應(response),http協議請求（request）分爲請求參數（request params）和方法類型(request method）、請求頭（request hearder）、請求體(request body) ，
響應(response)分爲 響應狀態(response state）、響應頭（response header）、響應體(response body）等.
TCP與UDP區別
udp:
a、是面向無連接, 將數據及源的封裝成數據包中,不需要建立連接
b、每個數據報的大小在限制64k內
c、因無連接,是不可靠協議
d、不需要建立連接,速度快
tcp：
a、建議連接，形成傳輸數據的通道.
b、在連接中進行大數據量傳輸，以字節流方式
c 通過三次握手完成連接,是可靠協議
d 必須建立連接m效率會稍低
談談七層網絡模型
應用層：客戶端的各種應用、app；
表示層：進行數據的格式區分，如圖片、編碼；
會話層：本地主機與遠程主機的會話管理；
傳輸層：定義傳輸數據的協議端口號，TCP和UDP是這一層的協議；
網絡層：進行邏輯地址尋址；
數據鏈路層：建立邏輯連接，進行硬件地址尋址；
物理層：建立物理連接；
Nginx如何實現TCP四層負載均衡
在nginx.conf文件中配置tcp模塊，在upstream塊中定義socket服務器負載均衡，其餘與nginx配置七層負載均衡相同。
tcp {
\#\#\# 定義多個上游服務器
upstream itmayeidu{
\#\#\# 定義TCP模塊上游服務器
server 192.168.5.165:80001;
server 192.168.5.165:80002;
}
server {
listen 9999;
server\_name 192.168.212.137;
\#\#\# 反向代理upstream
proxy\_pass itmayeidu;
}
}
lvs 與Nginx 區別
lvs工作在網絡第四層，nginx工作在網絡第七層；lvs比nginx抗負載能力強；lvs對網絡依賴性強，nginx對網絡依賴性弱；lvs幾乎可以對所有應用做負載均衡，比如數據庫。
lvs與keepalived區別
Lvs可以實現負載均衡，但是無法實現健康檢查。Keepalived可以進行健康檢查實現高可用。
keepalived 作用
keepalive 軟件可以進行健康檢查，而且能同時實現 LVS 的高可用性，解決 LVS 單點故障的問題
如何實現雙機主從熱備
Nginx+Tomcat：在upstream中配置多臺服務器，從服務器後加backup
Keepalived+Nginx：在多臺nginx服務器上安裝keepalived，將主服務器的state設置爲MASTER，從服務器設置爲BACKUP，主服務器的優先級要高於從服務器
lvs+Keepalived+Nginx架構流程圖
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-SXJCriGW-1593756720471)(media/image3.png)]{width=“4.000077646544182in” height=“2.238073053368329in”}
項目發佈如何不影響到正常用戶訪問，實現7*24小時訪問
可以兩臺機子互爲熱備，平時各自負責各自的服務。在做上線更新的時候，關閉一臺服務器的tomcat後，nginx自動把流量切換到另外一臺服務的後備機子上，從而實現無痛更新，保持服務的持續性，提高服務的可靠性，從而保證服務器7*24小時運行。
項目如何發生故障宕機了，如何處理。
使用lvs+keepalived+Nginx做主從熱備，lvs管理nginx集羣，nginx管理服務器集羣，在服務器宕機的情況下keepalived啓動健康檢測，多次重啓無果可以短信通知運維人員及時維護。
動態網站與靜態網站區別
在瀏覽器中打開一個網站，點擊鼠標右鍵查看源碼，多次請求後如果源碼不產生變化就是靜態網站，變化就是動態網站。
動態頁面靜態化的作用
便於搜索引擎抓取和排名
什麼是動靜分離架構模式
靜態頁面與動態頁面分開不同系統訪問的架構設計方法，靜態頁面與動態頁面以不同域名區分。
如何搭建動靜分離
以nginx服務器作爲靜態資源服務器，靜態資源和動態資源訪問分開配置，靜態資源在location中使用本地文件路徑配置方式，動態資源使用proxy_pass配置到後臺服務器。
如：
\#\#\#靜態資源訪問
server {
listen 80;
server\_name static.itmayiedu.com;
location /static/imgs {
root F:/;
index index.html index.htm;
}
}
\#\#\#動態資源訪問
server {
listen 80;
server\_name www.itmayiedu.com;
location / {
proxy\_pass http://127.0.0.1:8080;
index index.html index.htm;
}
}
動靜分離與前後分離區別
動靜分離是將靜態資源和動態資源存放在不同服務器中，前後分離是將前端和後臺分離，前端通過api調用後臺接口
如何控制瀏覽器靜態資源緩存
靜態資源存在緩存的原因是項目上線時，瀏覽器緩存中的靜態資源導致與服務器將淘汰資源的代碼發生衝突(或者是頁面訪問頻繁訪問同一資源，導致一些瀏覽器如IE(本人開發親身經歷過)返回默認的響應結果，與實際響應結果不符合)，
一般的服務器是強制F5進行刷新或者是清除緩存，最有效的解決方法就是在請求資源後面加上變量(如時間戳,隨機數)
Http狀態碼304的作用
表示瀏覽器存在靜態資源緩存就不從服務器獲取靜態資源
高併發服務限流特級
高併發服務限流特技有哪些算法?
傳統計算器算法，滑動窗口計數器算法,令牌桶算法和漏桶算法。
傳統計數器限流算法有什麼弊端?
傳統計數器限流方式不支持高併發，存在線程安全問題.若大量訪問請求集中在計數器最後時刻，計數器極易發生臨界問題，訪問的請求無法完成.
什麼是滑動窗口計數器?
滑動窗口計數器是一種服務限流的算法,相對於計數器方法的實現，滑動窗口實現會更加平滑，並自動消除毛刺。其原理是當有訪問進來時，會判斷若干個單位來的請求是否超過
設置的閥值，並對當前時間片的請求數+1.
令牌桶算法的原理?
向一個存放固定容量令牌的同，以固定速率往桶裏添加令牌，當桶已經裝滿時，新增的令牌會被丟棄或者拒絕,當一個固定數目的數據包到達時，會在
桶中刪除同等數量的令牌，數據包會發到網絡上，當這個固定數目超過桶中的令牌數，不會刪除桶中的令牌數目，則該數據包會被限流(丟棄或者存入緩衝區等待)
漏桶算法的原理?
向一個存放固定容量的桶，以任意速率滴入水滴(請求)，以固定速率滴出水滴，當滴入水滴量超過桶中設置固定容量，則會發生溢出，溢出的水滴的請求是無法訪問的，直接走
服務限流降級，桶中的容量不發生任何變化。
令牌桶與漏桶算法的區別?
令牌桶和漏桶算法的區別是令牌桶會根據請求的令牌數與桶中的令牌數做對比，倘若桶中令牌數小於請求令牌數則多餘的令牌數的請求被拒絕。漏桶算法則是向桶中添加請求，當
請求數大於桶中容量發生溢出，溢出的請求直接被拒絕訪問。主要區別是漏桶算法是強行限制數據的傳輸速率，而令牌桶在能夠限制數據的平均傳輸速率外，還允許某種程度的突發傳輸，使用於搶紅包等高併發的場景。
Web前端優化方案
Web前端有哪些優化方案
1.網站框架實行動靜分離，動態資源和和靜態資源部署到不同的服務器上面，使用nginx訪問本地靜態資源，通過nginx代理轉發到tomcate訪問動態資源
2.在訪問靜態資源時在Url後綴加上時間戳，防止訪問資源的與瀏覽器本地緩存資源存在衝突.
3.頁面減少HTTP請求，合併靜態資源(如js或者css）並進行壓縮。
4.使用CDN內容分發，緩存靜態資源，讓用戶訪問最近的服務器，減少寬帶之間的傳輸.
什麼是CDN內容分發?
CDN內容轉發是指在用戶和服務器之間加上一個緩存機制，一組分佈在不同的靜態資源服務器，儲存靜態資源，動態獲取用戶IP，並讓用戶訪問最近的靜態資源服務器,防止出現網絡延遲阻塞，
提高訪問速度。CND服務器部署在網絡運營商的機房，用戶請求首先會訪問CND服務器，如果CND服務器中沒有緩存會自動把創建緩存，當用戶再次訪問時，直接獲取緩存資源，並返回給前端，提高靜態
資源的訪問速度。
CDN內容加速原理?
1)用戶向瀏覽器提供要訪問的域名.
2)瀏覽器從本地host文件中解析域名,如何host文件沒有做任何配置，則瀏覽器調用域名解析庫對域名進行解析,析函數庫一般得到的是該域名對應的CNAME記錄,從中獲取真正的IP地址,此過程中,根據地理位置信息解析對應的IP地址，使得用戶能就近訪問靜態資源服務器。
3)此次解析的CDN服務器的IP地址，瀏覽器根據這個地址，向緩存服務器發出請求。
4)緩存服務器根究瀏覽器訪問的域名，通過緩存內部獲得此域名的真實IP地址，再有緩存服務器提交該IP地址的訪問請求。
5)緩存服務器從服務器的ip地址獲取內容備用,並將數據返回給用戶，完成服務過程.
6)客戶端將服務器返回的數據展示給前端
互聯網高併發解決方案
首先在談到高併發解決方案的時候，很多學員可能都會想到服務器應該做集羣、負載均衡。
那麼服務器集羣，一定能解決高併發嗎？這其實不一定。
首先要分清楚高併發影響用戶的源頭？是因爲帶寬不夠還是服務內存不足？
服務帶寬指的是：客戶端與服務器傳輸的寬度的速度，1m 等於 128kb。
服務內存指的是：服務器端處理業務能力。
那麼解決高併發的入口是客戶端與服務器端傳輸帶寬速度, 如果帶寬速度不足的情況，可能會導致客戶端延遲等待。
一個網站核心 分爲靜態資源(css、img、js)和動態資源（jsp、ftl）組合，絕大數的情況下靜態資源佔了整個網站帶寬傳輸， 這時候應該採用網站動靜分離架構，將動態資源與靜態資源分開服務器存放，注意：網站跨域問題。
動靜分離可以使用 nginx，或者是使用第三方靜態資源服務器比如七牛雲、阿里雲等。
還要對靜態資源實現壓縮、減少帶寬的傳輸，使用 CDN 實現內容分發，從最近服務器訪問。
如何對靜態資源實現壓縮呢？ 使用 nginx 開啓 gzip、maven 打包壓縮 min 格式、或者使用 cdn 自帶壓縮
以上這些屬於 Web 前端優化。
如果客戶端發送請求已經達到服務器端的話，服務端處理響應產生延遲，那麼開始採用後端優化方案。
.可以對服務器實現集羣 、加服務配置、採用 MQ 異步傳輸、使用 Redis 做緩存，減輕數據庫訪問壓力、代碼優化、數據庫採用:讀寫分離和分表分庫，程序採用多線程、jvm 參數調優，服務實現保護機制（服務降級、服務隔離、服務熔斷、服務限流）等。
Web 前端優化大多數情況下，屬於公司運維乾的事情，後端優化屬於架構師做的事情，如果一個網站中靜態資源非常多的情況下，不要將靜態資源和動態資源在同一個服務器存放，一定要採用動靜分離架構，提高網站的吞吐量。
最後總結下，如果服務器帶寬不足的情況下，服務器接受客戶端請求資源，可能會產生延遲，服務器做集羣、加配置，效果不會很明顯，因爲服務器集羣只能提高服務器的業務處理能力，不能提高服務器的帶寬傳輸，
所以可以採用以上總結的 Web 前端優化方案，減少客戶端與服務器端帶寬傳輸。
.如果在帶寬的足夠的情況下，客戶端發送請求已經到達了後端服務器，服務器端處理能力產生延遲，那麼採用以上總結 後端優化方案
服務器集羣、加服務器配置等。
之前有一位學員問，app 客戶端遇到高併發，是採用後端優化還是前端優化，app 屬於 cs 架構，靜態資源在打包的時候已經在安裝包裏面，不需要遠程獲取，業務邏輯需要遠程調用接口，獲取 json 數據進行解析，讓後展示數據，所以 app 客戶端產生的高併發，核心在於後端優化。
架構，將動態資源與靜態資源分開服務器存放，注意：網站跨域問題。
動靜分離可以使用 nginx，或者是使用第三方靜態資源服務器比如七牛雲、阿里雲等。
還要對靜態資源實現壓縮、減少帶寬的傳輸，使用 CDN 實現內容分發，從最近服務器訪問。
如何對靜態資源實現壓縮呢？ 使用 nginx 開啓 gzip、maven 打包壓縮 min 格式、或者使用 cdn 自帶壓縮
以上這些屬於 Web 前端優化。
如果客戶端發送請求已經達到服務器端的話，服務端處理響應產生延遲，那麼開始採用後端優化方案。
.可以對服務器實現集羣 、加服務配置、採用 MQ 異步傳輸、使用 Redis 做緩存，減輕數據庫訪問壓力、代碼優化、數據庫採用:讀寫分離和分表分庫，程序採用多線程、jvm 參數調優，服務實現保護機制（服務降級、服務隔離、服務熔斷、服務限流）等。
Web 前端優化大多數情況下，屬於公司運維乾的事情，後端優化屬於架構師做的事情，如果一個網站中靜態資源非常多的情況下，不要將靜態資源和動態資源在同一個服務器存放，一定要採用動靜分離架構，提高網站的吞吐量。
最後總結下，如果服務器帶寬不足的情況下，服務器接受客戶端請求資源，可能會產生延遲，服務器做集羣、加配置，效果不會很明顯，因爲服務器集羣只能提高服務器的業務處理能力，不能提高服務器的帶寬傳輸，
所以可以採用以上總結的 Web 前端優化方案，減少客戶端與服務器端帶寬傳輸。
.如果在帶寬的足夠的情況下，客戶端發送請求已經到達了後端服務器，服務器端處理能力產生延遲，那麼採用以上總結 後端優化方案
服務器集羣、加服務器配置等。
之前有一位學員問，app 客戶端遇到高併發，是採用後端優化還是前端優化，app 屬於 cs 架構，靜態資源在打包的時候已經在安裝包裏面，不需要遠程獲取，業務邏輯需要遠程調用接口，獲取 json 數據進行解析，讓後展示數據，所以 app 客戶端產生的高併發，核心在於後端優化。