1.5 微服務(wù)實施

微服務(wù)改造過程中會面臨很多挑戰(zhàn)，接下來從服務(wù)拆分、服務(wù)通信以及服務(wù)穩(wěn)定性設(shè)計這幾個維度出發(fā)，討論微服務(wù)實施過程中需要著重注意的問題。

1.5.1 微服務(wù)拆分

服務(wù)拆分是微服務(wù)改造的第一步，也是最為關(guān)鍵的一步，拆分是否合理，決定了整個微服務(wù)化過程的成敗，因此，需要有科學的拆分原則和拆分方法，保證拆分過程有序進行。

1.拆分原則

微服務(wù)拆分前，需要確定拆分的基本原則，微服務(wù)拆分的一個非常重要原則是無狀態(tài)，無狀態(tài)服務(wù)方便擴展和運維，所以無狀態(tài)設(shè)計需要貫穿到微服務(wù)架構(gòu)設(shè)計的全局層面進行思考。

服務(wù)拆分粒度并不是越細越好，需要結(jié)合當前團隊的人員情況而定，比如當前團隊只有5個人，如果拆分后的微服務(wù)個數(shù)超過50，和人員的數(shù)量嚴重不匹配，不僅不會帶來效率的提升，反而會導致效率的下降，建議拆分后每個人維護的微服務(wù)不要超過3個，并且每個微服務(wù)都有相應(yīng)的備用負責人，規(guī)避可能的突發(fā)風險；針對多團隊異地開發(fā)的情況，最好拆分后每個子團隊負責的微服務(wù)相對獨立，盡量減少異地團隊的直接溝通成本。

微服務(wù)拆分時經(jīng)常會遇到一些問題，比如是否需要拆分、拆分粒度的問題等，一般原則是遇到痛點問題時才進行拆分，非拆分不可時才啟動微服務(wù)拆分，不要為了拆分而拆分。對于拆分方案拿捏不準的場景，盡量先不進行拆分，等想清楚了再定，避免拆分不合理，帶來大量返工。

拆分后的微服務(wù)組織上層次不要過深，一個請求的處理過程中經(jīng)過的微服務(wù)個數(shù)不要超過5個，鏈路太深會導致定位和追查問題特別麻煩，同時也會帶來一定的性能損耗。

對于拆分后的子服務(wù)來說，盡量避免相互依賴的場景，子服務(wù)調(diào)用時相互依賴會導致升級和維護時特別麻煩，增加很多不必要的運維成本。

2.拆分方法

微服務(wù)拆分的總體思想是根據(jù)高耦合、低內(nèi)聚的原則識別出各個微服務(wù)的邊界。具體拆分思路和業(yè)務(wù)形態(tài)緊密相關(guān)，沒有絕對的標準，下面介紹微服務(wù)架構(gòu)拆分中使用比較多的兩種拆分方式。

（1）以數(shù)據(jù)為維度進行拆分

按照數(shù)據(jù)拆分，是微服務(wù)拆分中最常見的一種方式，沒有特殊考慮時一般根據(jù)領(lǐng)域?qū)嶓w數(shù)據(jù)進行拆分，拆分出來的服務(wù)負責處理給定的數(shù)據(jù)/資源的所有操作。

以電商系統(tǒng)為例，大體可分為訂單系統(tǒng)、用戶系統(tǒng)、庫存系統(tǒng)等。以訂單系統(tǒng)為例，訂單系統(tǒng)就負責訂單核心數(shù)據(jù)的維護、訂單數(shù)據(jù)的增刪查改，確立了主要實體數(shù)據(jù)后可以根據(jù)數(shù)據(jù)的查詢、修改等確定服務(wù)的接口，如訂單的各種查詢接口以及訂單狀態(tài)更新接口。

根據(jù)數(shù)據(jù)維度把系統(tǒng)可以拆分出若干個子服務(wù)，但這些數(shù)據(jù)之間會有不少關(guān)聯(lián)關(guān)系。

以百度貼吧為例，貼吧中的人、吧、帖是三個最重要的實體數(shù)據(jù)，這些實體數(shù)據(jù)可以分別放到不同的服務(wù)中。但是一些常見的實體關(guān)系，比如人發(fā)過的帖子、人收藏的吧，以及吧的會員、吧的帖子列表等，這些實體關(guān)系數(shù)據(jù)的維護，原則上放在哪個實體上維護沒有標準的答案，某個人發(fā)過的帖子放在人服務(wù)和帖服務(wù)都可以，反復在這些地方糾結(jié)也不會帶來太多的收益，可以人為地指定一個約束，如某個人發(fā)過的帖子就放在帖服務(wù)里面。

（2）按照使用場景拆分服務(wù)

按照使用場景進行服務(wù)拆分，這種拆分方式也比較常見，如順風車的所有后端查詢操作之前都在一個單體服務(wù)里面，有固定路線/臨時路線查詢順路訂單，有根據(jù)路線查詢附近訂單，還有查詢跨城訂單，以及后續(xù)的需求乘客查詢附近司機，乘客查詢順路司機等。之前這些在線查詢接口都在一個單體服務(wù)中，多個RD會同時負責和修改這個服務(wù)的代碼，開發(fā)效率低下，測試、上線都會相互影響，維護起來比較困難，后來把這些查詢按照功能都拆分為不同的子服務(wù)，每個RD單獨負責，大大提高了開發(fā)、測試以及運維效率。

（3）重要和非重要的拆分

將核心邏輯和非核心邏輯拆分為不同的微服務(wù)，然后采用不同的高可用處理方案，比如核心服務(wù)盡量做到機房、集群等多維度的冗余和隔離；非核心服務(wù)則可以適當降低可用性標準，出現(xiàn)問題時只要能夠及時降級和熔斷即可。

（4）變和不變的拆分

按照變更頻次對服務(wù)進行拆分，盡量將變化聚集到少部分微服務(wù)上面，系統(tǒng)的絕大多數(shù)服務(wù)變更很少，可以減少變更對整個系統(tǒng)的沖擊和影響。

1.5.2 微服務(wù)通信

為了保證拆分之后的微服務(wù)能夠通力合作，共同對外提供服務(wù)能力，需要通過一定的機制將拆分之后的微服務(wù)合起來，也就是微服務(wù)通信，接下來討論微服務(wù)通信過程中常見的一些問題。

1.微服務(wù)通信方式選擇

微服務(wù)通信時，首先需要考慮的是通信方式的選擇，對一些不需要返回業(yè)務(wù)數(shù)據(jù)的微服務(wù)來說，究竟是采用同步方式還是異步方式呢？同步方式架構(gòu)層面要求比較高，異步方式架構(gòu)層面比較優(yōu)雅，但運維成本比較高，出現(xiàn)問題時排查起來不太方便。之前公司中有過一次不成功的架構(gòu)升級實例，業(yè)務(wù)形態(tài)完全圍繞訂單狀態(tài)流轉(zhuǎn)進行，當前的架構(gòu)初衷是構(gòu)建一套基于事件驅(qū)動的基礎(chǔ)設(shè)施，所有微服務(wù)均以事件驅(qū)動的方式進行觸發(fā)，最后不僅對業(yè)務(wù)人員的挑戰(zhàn)比較大，同時運維、高可用和問題追查的成本比較高。因此微服務(wù)化時，核心服務(wù)推薦均采用同步通信的方式，一些非核心服務(wù)可以采用異步通信的方式。

2.微服務(wù)編排

微服務(wù)編排上，一些可以并行調(diào)用的場景推薦采用并行調(diào)用的方式，可以減少請求的整體耗時，提高用戶體驗。

當然對于有些場景來說，直接采用并行調(diào)用不一定是最好的方式，需要綜合考慮和分析。比如，對于搜索和廣告引擎來說，整個系統(tǒng)會有大量的過濾子服務(wù)組成，如果完全采用串行的方式，并且有著良好的漏斗模型設(shè)計，這時請求的整體耗時可能會上升，但整體的調(diào)用量會減少不少，成本上有很大的節(jié)省；如果采用完全并行的方式，整體耗時會有很大的改善，但無法充分利用漏斗模型，成本上會有一定的浪費。面對這種場景，需要有一套完善的微服務(wù)編排引擎，能夠同時兼顧性能和成本上的需求，做到微服務(wù)編排的最優(yōu)化。

3.API接口設(shè)計

API接口設(shè)計上，需要盡可能簡單易用，一個接口只實現(xiàn)一個確定的功能，不要設(shè)計復雜或者含義不明確的接口，避免濫用；同時接口設(shè)計時做好前后向兼容，以及冪等性設(shè)計。

4.合理設(shè)置超時和重試

微服務(wù)通信上，需要合理設(shè)置超時和重試，超時和重試設(shè)置不要只考慮當前鏈路，而要從請求全鏈路的角度，對超時和重試進行統(tǒng)一梳理。

除非有特殊原因，建議在調(diào)用的入口統(tǒng)一進行重試，請求過程中不再進行重試，避免故障時的多級重試導致的整體雪崩。

5.數(shù)據(jù)一致性設(shè)計

同時操作多個微服務(wù)的場景，需要保證不同微服務(wù)之間的數(shù)據(jù)一致性，數(shù)據(jù)一致性設(shè)計盡量遵循簡單的原則，除非特別場景，不要使用分布式事務(wù)。

多個微服務(wù)操作時，成功或失敗需要以核心數(shù)據(jù)為準，當同時對多個核心數(shù)據(jù)進行操作時，可以以其中一個為準，遇到個別數(shù)據(jù)不一致的場景，可以采用線下對賬的方式對不一致的數(shù)據(jù)進行校對和修正。

1.5.3 微服務(wù)穩(wěn)定性保障

微服務(wù)改造中，挑戰(zhàn)最大的就是拆分之后的穩(wěn)定性保障，拆分之后鏈路復雜、故障點眾多，需要一套體系化的穩(wěn)定性保障機制。

1.穩(wěn)定性保障的目標

微服務(wù)穩(wěn)定性保障需要從事前、事中和事后全方位進行考慮。微服務(wù)架構(gòu)下，應(yīng)用程序、依賴服務(wù)、網(wǎng)絡(luò)、硬件等都有可能出現(xiàn)故障，穩(wěn)定性設(shè)計和保障的具體目標如下。

故障預(yù)防，盡可能減少故障的產(chǎn)生，絕大多數(shù)穩(wěn)定性問題和穩(wěn)定性故障發(fā)生都有一定的誘因，并且一般是在多種攔截手段均失靈的情況下故障才會發(fā)生，如果我們在故障發(fā)生前制定完備的穩(wěn)定性保障措施，可以最大限度地減少穩(wěn)定性故障的發(fā)生。

故障快速定位，完全不出故障的業(yè)務(wù)是不存在的，關(guān)鍵是出故障時能夠快速發(fā)現(xiàn)故障，只有及時發(fā)現(xiàn)，才能在最短時間內(nèi)采取相應(yīng)的解決措施。

故障快速止損，發(fā)生故障后第一時間要進行業(yè)務(wù)止損，恢復業(yè)務(wù)的正常運行，故障深層次的具體原因可以事后再分析和復盤解決。

2.穩(wěn)定性保障的6個維度

系統(tǒng)故障點很多，穩(wěn)定性保障就是對故障點進行管理的過程。可以從故障點管理的角度將整個穩(wěn)定性設(shè)計和保障分為如下隔離、冗余、容災(zāi)容錯、變更管理、時間相關(guān)故障管理與運維友好6個維度。

（1）隔離

影響系統(tǒng)穩(wěn)定性的不穩(wěn)定性因素和故障點很多，從穩(wěn)定性保障的角度看，很自然的想法就是，如何盡量減少如此多的故障點給系統(tǒng)穩(wěn)定性帶來的隱患，比如某電商業(yè)務(wù)有200個微服務(wù)組成，如果這100個微服務(wù)中的任何一個出問題，導致業(yè)務(wù)不可用，那么系統(tǒng)的可用性就會很低。業(yè)務(wù)層面如果能夠梳理和抽象出保障業(yè)務(wù)核心運行的最小系統(tǒng)（比如上面提到的電商業(yè)務(wù)最小系統(tǒng)包含的服務(wù)可能會小于50個，其他都是增值和支撐性的服務(wù)），同時將最小系統(tǒng)之外的不穩(wěn)定性因素從最小系統(tǒng)中隔離出來，就可以大大增強系統(tǒng)的穩(wěn)定性和健壯性。因此，穩(wěn)定性設(shè)計的第一個原則就是“隔離”，通過各種隔離機制，將核心服務(wù)之前的故障點隔離出去，保證核心服務(wù)的可用性。

（2）冗余

通過隔離，可以減少絕大多數(shù)不穩(wěn)定性因素對系統(tǒng)穩(wěn)定性的影響，但如果核心服務(wù)或核心服務(wù)所在的環(huán)境出問題，就無法從隔離中受益。我們需要有相應(yīng)的機制保證核心業(yè)務(wù)的部分單元出問題時，業(yè)務(wù)整體運行不受大的影響，這種機制就是冗余。通過服務(wù)級別、機器級別、集群級別、機房級別等多種維度的冗余，我們可以保證：即便核心服務(wù)出問題，也可以通過相應(yīng)的流量切換策略，將流量切到冗余節(jié)點上，保證業(yè)務(wù)不受影響。

（3）容災(zāi)容錯

通過冗余可以保證核心服務(wù)及其部署環(huán)境變化時的系統(tǒng)穩(wěn)定性，但如果系統(tǒng)外部輸入有變化，比如遇到突然大流量、異常流量或者突發(fā)的安全攻擊，而系統(tǒng)事先沒有相應(yīng)的應(yīng)對機制，則業(yè)務(wù)很可能瞬間被擊垮。因此，穩(wěn)定性設(shè)計的第三個原則是“容災(zāi)容錯”，通過構(gòu)建多維度的容災(zāi)容錯體系，保證系統(tǒng)面對異常輸入時，仍然能夠提高穩(wěn)定的輸出能力。

（4）變更管理

通過隔離、冗余與容災(zāi)可以排除和應(yīng)對業(yè)務(wù)最小子系統(tǒng)的各種外部穩(wěn)定性風險，變更管理、時間相關(guān)故障管理是為了解決核心系統(tǒng)自身的穩(wěn)定性問題。絕大部分穩(wěn)定性故障都是由變更引起，系統(tǒng)如果長時間沒有任何變更，很少會有穩(wěn)定性問題，因此服務(wù)穩(wěn)定性保障的關(guān)鍵一環(huán)是嚴把變更這一關(guān)，保證變更質(zhì)量。

（5）時間相關(guān)故障管理

服務(wù)沒有變更時，有一類故障很少發(fā)生并且很難發(fā)現(xiàn)，就是隨時間變化而產(chǎn)生的ID越界和溢出，這類故障平常測試時很難發(fā)現(xiàn)，并且發(fā)生時會對整個系統(tǒng)產(chǎn)生很大的影響，需要從設(shè)計層面開始把控，比如隨時間變化的ID字段盡量使用int64。

（6）運維友好

隔離、冗余和容災(zāi)減少了核心服務(wù)的外部穩(wěn)定性風險，變更管理和時間相關(guān)故障管理保證了核心服務(wù)自身的穩(wěn)定性。上述5種措施構(gòu)成了業(yè)務(wù)穩(wěn)定性預(yù)防的整個閉環(huán)，但即使設(shè)計得再好，也不能完全杜絕穩(wěn)定性故障，穩(wěn)定性風險只能最大限度地減少，因此服務(wù)的研發(fā)生命周期中，還需要加上運維友好的考慮。設(shè)計時需要針對穩(wěn)定性問題的快速發(fā)現(xiàn)進行特別考慮，如日志怎么輸出，統(tǒng)計信息如何收集等。通過運維友好設(shè)計，比如log、metric和trace等方式的良好設(shè)計與運用，建立全方位多維度的故障發(fā)現(xiàn)機制，保證出現(xiàn)問題時可以快速發(fā)現(xiàn)和快速止損，最大程度上減少穩(wěn)定性風險的影響。

3.穩(wěn)定性保障的設(shè)計建議

總之，隔離、冗余和容災(zāi)、變更管理、時間相關(guān)故障管理和運維友好構(gòu)成了整個的穩(wěn)定性保障體系，下面會對這幾個維度詳細展開討論。

（1）隔離機制

隔離機制的指導原則是將變和不變、重要和非重要區(qū)分開來，變更是穩(wěn)定性故障的最主要的來源，將容易發(fā)生變化的部分從核心服務(wù)和核心流程中剝離開來，減少核心部分的變更，可以保障核心系統(tǒng)的穩(wěn)定性。

隔離機制的一大手段就是解耦，通過解耦可以把核心服務(wù)和非核心服務(wù)隔離開來，同時核心服務(wù)訪問非核心服務(wù)時，通過熔斷、超時和重試等機制，最大限度地保障非核心服務(wù)故障不會影響整體的穩(wěn)定性。

異步化是流程隔離的主要方式，為了減少非核心服務(wù)故障對核心服務(wù)的影響，可以將一些非核心流程異步化處理。

為了減少對核心服務(wù)的影響，核心服務(wù)建議單獨部署，如果特殊情況下需要和其他服務(wù)混部，一定要保證有精細的資源隔離機制，保證不會因為其他服務(wù)資源使用不當，影響核心服務(wù)的穩(wěn)定性；同時核心服務(wù)用到的一些關(guān)鍵基礎(chǔ)服務(wù)、關(guān)鍵數(shù)據(jù)服務(wù)也建議隔離開來，分開部署，避免其他服務(wù)出問題對核心流程的影響。

（2）冗余

為了保證故障時冗余機制的可用性，事先需要進行完善的冗余容量規(guī)劃，各級故障發(fā)生后，剩余容量足夠承載峰值流量，一個大體的原則是：機房內(nèi)盡量滿足N+2冗余，2用來冗余（應(yīng)急變更故障和其他故障），機房間N+1冗余，1個機房掛掉后，剩余機房能承載所有流量。

為了盡量避免冗余同時失效的情況，冗余副本之間需要相互獨立，完全對等，不能相互依賴，機房內(nèi)副本跨交換機部署（此時一般也能保證跨機柜），如果有多機房冗余的情況，各機房獨立，不能有完全相同的依賴。

系統(tǒng)為了構(gòu)建完善的冗余機制，服務(wù)設(shè)計時盡量無狀態(tài)，無狀態(tài)的服務(wù)隨時可部署啟動，方便水平擴展。

為了用好冗余，常態(tài)下，需要支持靈活的流量調(diào)度策略，具體包含服務(wù)發(fā)現(xiàn)、流量路由、負載均衡等；節(jié)點故障時，通過健康檢查、故障節(jié)點剔除、動態(tài)路由切換等機制，可以平滑地將流量從故障節(jié)點切到冗余節(jié)點，保證節(jié)點故障不會影響系統(tǒng)整體穩(wěn)定性。

（3）容災(zāi)容錯

為了減少異常流量對系統(tǒng)的影響，服務(wù)開發(fā)和設(shè)計時需要采取防御性編程，提前想到可能面臨的種種異常情況，并針對性地進行防御和解決。

服務(wù)可以通過降級和限流，減少突發(fā)大流量對系統(tǒng)的沖擊，保證系統(tǒng)穩(wěn)定輸出，為了保證降級和限流操作的即時性，系統(tǒng)需要支持配置的動態(tài)修改和生效。

（4）變更管理

為了提高變更的質(zhì)量，減少變更帶來的穩(wěn)定性風險，需要從測試、上線和規(guī)范等多角度進行保障。

測試上，通過建設(shè)線上/線下多級測試環(huán)境，比如線下的聯(lián)調(diào)環(huán)境、集成環(huán)境、仿真環(huán)境，線上的預(yù)發(fā)布環(huán)境，通過不同用途的環(huán)境，提高各種場景的模擬能力，提高故障攔截率。

針對變更，需要制定完善的變更規(guī)范，變更時嚴格按照規(guī)范進行，再小的變更都可能會產(chǎn)生穩(wěn)定性隱患，因此變更時一定要加強穩(wěn)定性意識，變更的每一步操作都要進行各項監(jiān)控項檢查，如果出現(xiàn)問題立即進行回滾。

對所有變更操作，不管是服務(wù)變更、配置變更和數(shù)據(jù)變更，均要采用灰度機制，灰度觀察沒有問題后再放量，關(guān)鍵特性需要設(shè)置相應(yīng)的特性開關(guān)，方便根據(jù)需要靈活地對特性進行開啟和關(guān)閉。

最后，針對變更過程中比較容易遇到的問題，可以梳理出一套變更反模式出來，供其他人作為反面例子參考，下面是梳理的之前線上服務(wù)遇到的典型變更反模式。

1）代碼搭車上線。

比如由于缺乏有效的代碼修改管理機制，某產(chǎn)品線由于代碼搭車上線，出現(xiàn)過多次線上故障，并且由于變更時涉及的修改比較多，導致問題定位和追查時非常困難。

2）服務(wù)回滾時遺漏回滾代碼。

某業(yè)務(wù)隱私頁面改動，首頁浮層上線有問題，導致呼叫量下降，上線回滾后恢復；回滾后沒有第一時間把代碼回滾掉，其他人上線時將未回滾的問題代碼再次帶上線，導致連續(xù)兩天出現(xiàn)系統(tǒng)故障。

因此，服務(wù)回滾的時候，必須第一時間回滾代碼，保證主線代碼任何時候都是干凈沒有問題的。

3）服務(wù)啟動或者回滾時間過長。

某產(chǎn)品計價服務(wù)上線異常，回滾時單個服務(wù)回滾時間太長，導致未能短時間內(nèi)快速止損。經(jīng)排查，回滾過程中部署系統(tǒng)和服務(wù)都存在耗時過長的現(xiàn)象，由于服務(wù)回滾速度比較慢，產(chǎn)生了較大的線上服務(wù)故障。定期檢查和優(yōu)化服務(wù)的啟動和回滾時間，保證出現(xiàn)故障時可以第一時間完成回滾操作。

4）配置文件缺少有效的校驗機制。

配置文件由模型產(chǎn)出，數(shù)據(jù)配送系統(tǒng)實時配送到線上服務(wù)，模型產(chǎn)生的配置文件有問題，引發(fā)線上故障。因此，針對配置文件，尤其是策略模型產(chǎn)出的配置文件，需要建立嚴格的檢查和校驗機制。

5）小流量后的修改沒有經(jīng)過嚴格的測試和灰度驗證。

某服務(wù)經(jīng)過小流量灰度后，代碼又有少量修改，再次上線時未灰度，導致線上故障。再小的變更，都要進行測試、灰度和雙重檢查（double check）。修改一行代碼，也可能導致線上的穩(wěn)定性故障。

（5）運維友好

為了實現(xiàn)運維友好的系統(tǒng)設(shè)計，系統(tǒng)需要將故障分析和定位時涉及的所有相關(guān)信息監(jiān)控起來，構(gòu)建完善的監(jiān)控閉環(huán)，對系統(tǒng)層、服務(wù)層、接口層、業(yè)務(wù)層等維度進行監(jiān)控收集和告警。

為了減少系統(tǒng)的穩(wěn)定性隱患，微服務(wù)架構(gòu)設(shè)計中盡量遵循簡單的設(shè)計原則，從業(yè)務(wù)的真實需求出發(fā)，避免純粹從技術(shù)角度出發(fā)的高大上技術(shù)方案，如果不是業(yè)務(wù)的核心功能，必要時可以進行一定的折中和裁剪，盡量保證系統(tǒng)的簡單和簡潔性。

另外，盡量使用一些驗證過的技術(shù)，對于沒有充分驗證過的新技術(shù)的引入需要特別謹慎，如果一定要引入，需要控制好節(jié)奏，循序漸進。