微服務架構現(xiàn)在是個熱門話題，微服務的高可用性自然也是企業(yè)非常關注的。眼下互聯(lián)網(wǎng)的架構秘籍三板斧“高可用可擴展，緩存提速，消峰減流去并發(fā)”，在微服務架構體系中有著不一樣的詮釋。

[[335459]]

在微服務中消息隊列不僅用來消峰，還可以通過消息隊列來解決微服務之間的多耦合，把同步調用轉化為異步調用，減少調用鏈路，提升系統(tǒng)穩(wěn)定性。單體應用拆分為獨立的多個無形中增加了系統(tǒng)的響應時間，可以通過本地緩存、分布式緩存相結合的方式來彌補性能的損耗。以前通過內部接口調用的方法變成RPC調用多個服務，服務與服務之間還有依賴關系，每個服務接口響應時間也都不一樣，簡單的設置單個接口的超時時間已解決不了問題，可通過服務定級，哪些服務不能出問題，哪些服務允許有異常，采用降級、熔斷的方式來解決問題，以達到系統(tǒng)的高可用。這三種方式如能合理運用，微服務的高可用性大大提升，所以說緩存、隊列、熔斷降級成了微服務架構中的新三板斧。

以下是相關技術應用中的一些難點解答，供大家參考。

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

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

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

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

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

2、 緩存是每個互聯(lián)網(wǎng)應用系統(tǒng)必備的組件，在微服務框架下如何用好緩存來提高系統(tǒng)的QPS?

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

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

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

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

4、 使用熔斷降級技術需要考慮哪些方面?哪些參數(shù)需要調優(yōu)?

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

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

流量基本上會分成2種：

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

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

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

1、緩存：緩存是否支持動態(tài)增加;

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

同時需要做好如下3點：

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

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

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

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

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

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

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

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

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

7、微服務框架部署時的業(yè)務連續(xù)性如何考慮?

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

解答1：

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

解答2：

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

解答3：

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

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

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

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

9、微服務架構下底層數(shù)據(jù)存儲的實現(xiàn)方式?

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

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

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

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