怎么大大提升微服務的高可用性

本篇內容主要講解“怎么大大提升微服務的高可用性”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么大大提升微服務的高可用性”吧!

1、微服務架構中有哪些技術手段必須在設計階段就需要規劃進去?

互聯網的三板斧：熔斷、消息隊列、緩存、這個必須有要考慮進入，另外為了提高響應時間，并行化操作也需要提前考慮。

熔斷：保障服務高可用的重要手段，用戶的請求將不再直接訪問服務，而是通過線程池中的空閑線程來訪問服務，如果線程池已滿，則會進行降級處理，用戶的請求不會被阻塞，至少可以看到一個執行結果(例如返回友好的提示信息)，而不是無休止的等待或者看到系統崩潰。

消息隊列：消息隊列(MQ)是一種不同應用程序之間(跨進程)的通信方法，在微服務中引入消息隊列的目的就是為了減少鏈路，減少依賴。

緩存：為了提高QPS，減少數據庫壓力，分本地和遠程緩存;

2、 緩存是每個互聯網應用系統必備的組件，在微服務框架下如何用好緩存來提高系統的QPS?

在緩存的使用場景中，有一種2/8法則的說法，即20%的請求訪問DB(如有可能再少一點),80%的請求訪問緩存。在微服務場景下，本身是接口調用的現在變成了RPC遠程調用了，在一定程度上的確提高了單個接口的響應時間。但是從全局角度看，微服務提高了系統的QPS量級，所以從某種程度上來說，因為PRC的原因提高了單個接口的RT是可以忽略的。當然如果是為了最求極致，想盡可能的降低因為PRC帶來的接口響應時間，如果是涉及多個服務調用的，可以并行調用服務，同時將并行結果緩存在本地。后端每個原子服務都會對接緩存，這樣能有效提高系統的響應時間。

一般API接口發起請求到后端服務，如果涉及到會調用多個接口，那么會有一層聚合層，通常在聚合層做緩存，緩存分本地緩存(如JVM)或者遠端緩存(如Redis或Memcache)。由于是都是分布式架構，所以緩存一般采用TTL自動過期來清除緩存。如果業務量非常大，但是對于數據的不一致有比較高的要求，可以設置1秒。如果要求不高可以設置30秒或者分鐘級別都可以。但是在軟件架構中通常會使用讀寫分離來提高QPS，由于緩存會導致數據的不一致性，某些場景如需要數據強一致性，可以通過版本號的方式來處理。比如李四讀取A數據的時候version=1，同時有用戶張三對記錄A做了一次操作，那么version=2。這個時候李四是不能對于記錄A做變更操作的。

3、 消息隊列MQ在微服務中怎么用，有什么好的技巧?使用MQ一定要考慮冪等性嗎?

消息隊列(MQ)是一種不同應用程序之間(跨進程)的通信方法。消息隊列主要有：異步處理 - 增加吞吐量;削峰填谷 - 提高系統穩定性;系統解耦 -  業務邊界隔離;數據同步 -  最終一致性保證。在微服務中引入消息隊列的目的就是為了減少鏈路，減少依賴。舉例說，用戶注冊后系統會給用戶發積分，發優惠券，以及一些其他初始化操作。如果不用MQ的話，那么需要依賴積分服務，優惠券服務等其他服務。但是對于用戶服務來說，只管注冊不管其他的衍生服務，所以發送MQ后其他依賴方消費即可。微服務只要配置了重試機制寫入接口都需要考慮冪等性。因為需要考慮網絡的抖動，數據包會重復提交，如果沒有冪等性就會出現臟數據了。使用消息隊列也需要使用冪等性，因為消費端可能在某個環節失敗后沒有commit，導致消息會再次投遞的。

4、 使用熔斷降級技術需要考慮哪些方面?哪些參數需要調優?

所謂的降級或熔斷是針對非核心業務系統，當非核心業務系統因流量過大而出現響應慢，那么部分請求這個接口會出現降級，當達到一定策略之后就會變成熔斷。熔斷后可以是時候異步做處理。另外一種情況就是手動指定某個接口熔斷，例如某電商會在大促的時候把猜你喜歡或者為你推薦給屏蔽。如果沒有熔斷方式，那么就需要手動寫代碼，經過開發-測試-預發-線上環節，比較浪費時間。所有的策略都是為了高可用而做鋪墊的。一般使用hystrix來做降級熔斷功能，可配置的參數非常多，但是重點需要注意的點：circuitBreaker.requestVolumeThreshold  circuitBreaker.errorThresholdPercentage  execution.isolation.thread.timeoutInMilliseconds  hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds  另外，需要支持手動打開熔斷器，以防止特殊情況下需要主動打開熔斷器。

5、微服務面臨壓力過大怎么自動進行調整或臨時做到彈性增加服務?

流量基本上會分成2種：

1、正常業務流量，運營期間大流量(提前知曉)

2、被攻擊流量  大量用戶請求峰值基本上都會提前預知，比如運營做活動，會預估用戶量，根據這個預估的量來事先做容量擴充。如果是突發性的異常大流量，那就懷疑是否被攻擊了，需要做相關網絡層面的防護了。一般系統都會基本的保護措施，如，  限流：比如針對IP的限流 黑名單：針對IP的黑名單 通過上述方式基本上能攔截很大的非正常流量，然后系統層面對接口做限流以及降級和熔斷來保障平臺穩定。

彈性擴容是增加系統能支持的QPS量級。這里涉及到幾個需要做無狀態的核心組件：

1、緩存：緩存是否支持動態增加;

2、DB：這里的DB是指只讀叢庫  因為微服務天生支持多實例部署，由于能做到1,2了，那么可以根據營銷活動的用戶量初步預估下系統在高峰期的QPS會有多少，然后再去計算需要增加多少實例，緩存增加多少只讀只讀實例，DB增加多少只讀實例。

同時需要做好如下3點：

1、控制好限流和熔斷策略，以防止流量壓垮服務。

2、熱門活動場景，本地+遠端緩存一起使用;

3、活動期間把一些非核心流程先做熔斷處理;

6、微服務主要用什么方法保證高可用呢?硬負載均衡設備還是軟負載方式保證?

微服務框架本身就支持了同一個服務發布多個應用實例，且部署的應用和注冊中心都有心跳檢測，以保障應用都是在線狀態。同時框架本身會支持負載均衡以及重試機制，可以確保在單個應用宕機的情況下不影響應用，可以說微服務的框架通過軟負載的方式來保證了服務的高可用。

談到高可用，就想到了微服務，為什么說微服務難，其實并不是難在開發階段，而且對于整個團隊的整體性要求高了。其中包括：運維流程，監控體系。

運維流程：是否有持續集成，是否支持鏈式部署，支持版本回滾。

監控體系：慢響應，超時、ERROR能否及時的報警通知。

所有要提高微服務的高可用性，不僅僅是研發的事情，而是開發、運維一體才可以。

7、微服務框架部署時的業務連續性如何考慮?

近年金融行業，尤其是銀行業監管越來越嚴格，對業務連續性要求的更高，銀行系統對于由傳統架構遷移至微服務有較迫切的需求，目前在實際部署系統時，一般需要考慮系統的同城雙活或同城、異地多活，以保障業務連續性。那么在遷移至微服務架構的過程中，微服務架構上對于雙活、多活的需求是如何考慮的?如何實現異常情況下快速無中斷切換、不同中心間數據一致性等問題是否有解決建議?

解答1：

這個問題信息量比較大，同城雙活或同城、異地多活甚至目前跨云的多活都是大家所關注的話題。微服務的定義就是服務獨立化、動態擴容等一些優點,所以從微服務角度看并不關注多活，雙活，只要服務能正常允許即可。但是從架構角度來看，如需要支持多活，雙活，那么一些基礎設施是否具備了這些特性，比如Redis,Mysql是否支持雙主，是否支持主主自動切換，MQ的是否支持。這些工作量非常的大。個人建議在技術能力、人力都不足的情況下不要搞雙活，如非得考慮這方案因素，那還是建議去實施主備模式，即每個機房都部署一模一樣的系統，當主的出現問題后把流量切到備用上。

解答2：

目前應該還沒有微服務跨數據中心的合適技術，跨數據中心，需要解決微服務調度、服務發布的問題，還需要面對時延挑戰。所以比較好的方法是一個應用的微服務盡量都盡量在一個數據中心部署，考慮容災可以在另一個數據中心也部署統一套應用，前端通過負載均衡或者服務治理引流。

解答3：

這個問題其實展開說還是非常復雜的。底層不用區分上層是基于傳統的服務方式，還是微服務方式，只需要注意數據同步問題即可。在應用層面，拆分成微服務后，微服務應用數量大量增加，并且會使用到配置中心，注冊中心等微服務分布式組件，這些都對網絡要求比較高。所以比較好的方式是在一個業務請求在一個機房內完成，同時每個機房部署各自的微服務框架，減少跨機房流量。同時配置相應的微服務監控模塊，以及故障自愈。

8、微服務是否一定要Docker容器化?如果是，原因是什么?優缺點都有哪些?

成本角度：docker或者虛擬機將原本單體物理服務器拆分為多臺虛擬機，機器之間的資源也是隔離的，所以成本上有很大程度降低。

部署效率：簡單說docker和虛擬機都是一個概念，在服務化的場景下docker比虛擬機強的原因其實也很簡單，舉個例子，明天需要做一個非常大的影響活動，初步估算下每種核心節點服務需要增加10臺集群，目前核心服務有12個，即12*10=120臺，需要擴容120臺機器。虛擬機做法：開通120個虛擬機，配置環境，設置IP，端口，安裝應用，啟動，調試。按一個熟手沒部署一臺需要10分鐘，那么累計需要1200分鐘，約20個小時  docker做法：由于在部署的時候，每個應用都被做成了一個鏡像，所以要發布這120個應用，只需要通過腳本或者命令即可，整個過程約1個小時內完成。所以在服務數量不是很多的情況下，用虛機也是能符合要求的。

9、微服務架構下底層數據存儲的實現方式?

微服務的底層數據基本上都是異構的，如MySQL、HBase、Redis、ES、hive等等。業務處理都會先直接寫入MySQL，然后通過訂閱binLog的方式來做數據同步，一般會將binLog的數據寫入MQ，消費方在數據處理的時候需要考慮亂序問題。對于要求強一致性的數據一定要攜帶版號。

10、我們處在微服務+容器的轉型探索時期，如何選擇微服務框架，以及鏈路追蹤?

框架選擇：微服務框架目前比較火的有dubbo和spring cloud，他們各有利弊。spring  cloud個全家桶啥都全，但是真正能用好的并不多，無非是組件的堆疊。dubbo也從阿里自己運營轉向apache國際化方向，目前互聯網大部分公司都是使用dubbo框架，遇到問題也能通過社區快速解決，響應效率比較快，而且有各種技術沙龍可以學習。

鏈路追蹤：APM的選擇性比較多，有開源的，有收費的,目前市面的系統基本都是參考Google的Dapper論文來開發的。如果預算充足，可以選擇收費的企業版。好處是比較穩定，遇到問題有專人負責解答。如果研發資源充足，又想自己造輪子，可以選擇開源版本，如skywalking，Pinpoint,Zipkin,CAT。skywalking,Pinpoint：基本不用修改源碼和配置文件，只要在啟動命令里指定javaagent參數即可，對于運維人員來講最為方便;Zipkin：需要對Spring、web.xml之類的配置文件做修改，相對麻煩一些;CAT：需要在程序中硬編碼，侵入性比較大。具體選擇哪個，這個根據業務團隊的熟悉具體產品的程度來決定。

到此，相信大家對“怎么大大提升微服務的高可用性”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！