華為架構(gòu)師8年經(jīng)驗(yàn)談：從單體架構(gòu)到微服務(wù)的服務(wù)化演進(jìn)之路-創(chuàng)新互聯(lián)

本次分享的技術(shù)大綱如下：

創(chuàng)新互聯(lián)專注于廣元企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站制作。廣元網(wǎng)站建設(shè)公司,為廣元等地區(qū)提供建站服務(wù)。全流程按需求定制設(shè)計(jì)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

• 傳統(tǒng)應(yīng)用開發(fā)面臨的挑戰(zhàn)

• 服務(wù)化實(shí)踐

• 服務(wù)化不是銀彈

• 服務(wù)化架構(gòu)的演進(jìn)方向

一 、傳統(tǒng)應(yīng)用開發(fā)面臨的挑戰(zhàn)

挑戰(zhàn)1-- 研發(fā)成本高

主要體現(xiàn)在如下幾個(gè)方面：

• 代碼重復(fù)率高

在實(shí)際項(xiàng)目分工時(shí)，開發(fā)都是各自負(fù)責(zé)幾個(gè)功能，即便開發(fā)之間存在功能重疊，往往也會(huì)選擇自己實(shí)現(xiàn)，而不是類庫共享，主要原因如下：

1. 從技術(shù)架構(gòu)角度看，傳統(tǒng)垂直架構(gòu)的特點(diǎn)是本地API接口調(diào)用，不存在業(yè)務(wù)的拆分和互相調(diào)用，使用到什么功能就本地開發(fā)，非常方便，不需要過度依賴于其它功能模塊；

2. 從考核角度來看，共享很難推行。開發(fā)只需要對(duì)自己開發(fā)的模塊交付質(zhì)量負(fù)責(zé)，沒有義務(wù)為他人提供并維護(hù)公共類庫，這個(gè)非常耗費(fèi)成本；

3. 時(shí)間依賴很難把控：對(duì)于公共類庫的使用者而言，依賴別人提供此功能，但是功能提供者可能有更重要的事情在做，提供時(shí)間無法滿足使用者。與其坐等別人提供，還不如自己開發(fā)效率高；

跨地域、跨開發(fā)小組協(xié)調(diào)很困難，業(yè)務(wù)團(tuán)隊(duì)可能跨地域研發(fā)，內(nèi)部通常也會(huì)分成多個(gè)開發(fā)小組，各開發(fā)小組之間的協(xié)調(diào)和溝通成本非常高。

• 需求變更困難

代碼重復(fù)率變高之后，已有功能變更或者新需求加入都會(huì)非常困難，以充值繳費(fèi)功能為例，不同的充值渠道開發(fā)了相同的限額保護(hù)功能，當(dāng)限額保護(hù)功能發(fā)生變更之后，所有重復(fù)開發(fā)的限額保護(hù)功能都需要重新修改和測(cè)試，很容易出現(xiàn)修改不一致或者被遺漏，導(dǎo)致部分渠道充值功能正常，部分存在Bug的問題，示例如下：

• 無法滿足新業(yè)務(wù)快速創(chuàng)新和敏捷交付

挑戰(zhàn)2-- 運(yùn)維效率低

在傳統(tǒng)的MVC架構(gòu)中，業(yè)務(wù)流程是由一長(zhǎng)串本地接口或者方法調(diào)用串聯(lián)起來的，臃腫而冗長(zhǎng)，而且往往由一個(gè)人負(fù)責(zé)開發(fā)和維護(hù)。隨著業(yè)務(wù)的發(fā)展和需求變化，本地代碼在不斷的迭代和變更，最后形成了一個(gè)個(gè)垂直的功能孤島，只有原來的開發(fā)者才理解接口調(diào)用關(guān)系和功能需求，一旦原有的開發(fā)者離職或者調(diào)到其他項(xiàng)目組，這些功能模塊的運(yùn)維就會(huì)變得非常困難：

當(dāng)垂直應(yīng)用越來越多時(shí)，連架構(gòu)師都無法描述應(yīng)用間的架構(gòu)關(guān)系，隨著業(yè)務(wù)的發(fā)展和功能膨脹，這種架構(gòu)很容易發(fā)生腐化。

• 測(cè)試、部署成本高：業(yè)務(wù)運(yùn)行在一個(gè)進(jìn)程中，因此系統(tǒng)中任何程序的改變，都需要對(duì)整個(gè)系統(tǒng)重新測(cè)試并部署

• 可伸縮性差：水平擴(kuò)展只能基于整個(gè)系統(tǒng)進(jìn)行擴(kuò)展，無法針對(duì)某一個(gè)功能模塊按需擴(kuò)展

• 可靠性差：某個(gè)應(yīng)用BUG，例如死循環(huán)、OOM等，會(huì)導(dǎo)致整個(gè)進(jìn)程宕機(jī)，影響其它合設(shè)的應(yīng)用

如何解決傳統(tǒng)單體架構(gòu)面臨的挑戰(zhàn)？

解決對(duì)策：1、拆分 2、解耦 3、透明 4、獨(dú)立 5、分層。

• 拆分：對(duì)應(yīng)用進(jìn)行水平和垂直拆分，例如商品中心、計(jì)費(fèi)中心、訂單中心等。

• 解耦：通過服務(wù)化和訂閱、發(fā)布機(jī)制對(duì)應(yīng)用調(diào)用關(guān)系解耦，支持服務(wù)的自動(dòng)注冊(cè)和發(fā)現(xiàn)

• 透明：通過服務(wù)注冊(cè)中心管理服務(wù)的發(fā)布和消費(fèi)、調(diào)用關(guān)系

• 獨(dú)立：服務(wù)可以獨(dú)立打包、發(fā)布、部署、啟停、擴(kuò)容和升級(jí)，核心服務(wù)獨(dú)立集群部署

• 分層：梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求

二、服務(wù)化實(shí)踐

服務(wù)的訂閱發(fā)布機(jī)制

它的核心理念是實(shí)現(xiàn)服務(wù)消費(fèi)者和服務(wù)提供者的解耦，讓服務(wù)消費(fèi)者能夠像使用本地接口一樣消費(fèi)遠(yuǎn)端的服務(wù)提供者，而不需要關(guān)心服務(wù)提供者的位置信息，實(shí)現(xiàn)透明化調(diào)用。

關(guān)鍵技術(shù)點(diǎn)：服務(wù)的訂閱、發(fā)布機(jī)制、服務(wù)的健康狀態(tài)檢測(cè)和高HA。

常用的服務(wù)注冊(cè)中心有Zookeeper、ETCD，以及基于數(shù)據(jù)庫的配置中心。

大家在技術(shù)選型的時(shí)候，需要根據(jù)自己的業(yè)務(wù)實(shí)際情況進(jìn)行選擇。例如超大規(guī)模集群，服務(wù)實(shí)例數(shù)超過10W，Zookeeper就會(huì)存在性能問題。

現(xiàn)在開源的分布式配置服務(wù)很多，如無特殊需求，建議選擇開源方案。

服務(wù)化實(shí)踐-零侵入

實(shí)際上，完全的零侵入很難做到，即使是聲明式配置，配置本身也是代碼的一部分，只不過相比于代碼類庫依賴，它不是編譯器依賴。

一種好的做法是，服務(wù)的發(fā)布和消費(fèi)通過聲明式或者注解的方式，而不是直接調(diào)用服務(wù)框架的接口，例如Thrift?？蛻舳诵枰{(diào)用Thrift提供的類庫訪問服務(wù)端，這就是代碼API級(jí)的依賴，對(duì)業(yè)務(wù)代碼侵入比較大。

一種比較成熟的實(shí)踐是 利用Spring的擴(kuò)展機(jī)制，通過XML的方式實(shí)現(xiàn)服務(wù)的發(fā)布和消費(fèi)。

服務(wù)化實(shí)踐-容錯(cuò)和路由

單體應(yīng)用服務(wù)化之后，通常采用分布式集群的部署模式。

這會(huì)帶來兩個(gè)問題：

1. 服務(wù)如何路由；

2. 遠(yuǎn)端服務(wù)訪問失敗之后，如果進(jìn)行容錯(cuò)。

大部分的容錯(cuò)和路由策略可以抽象到分布式服務(wù)框架中，通過策略配置的方式提供給用戶使用，降低用戶的開發(fā)成本。

從業(yè)務(wù)擴(kuò)展性角度看，服務(wù)框架通常會(huì)提供擴(kuò)展點(diǎn)，供業(yè)務(wù)做路由和容錯(cuò)定制。例如，業(yè)務(wù)希望根據(jù)手機(jī)號(hào)碼和地市進(jìn)行路由：

服務(wù)化實(shí)踐-本地短路策略

在電信行業(yè)中，小機(jī)還是很普遍，應(yīng)用通常會(huì)合設(shè)，例如服務(wù)提供者和消費(fèi)者部署到同一臺(tái)主機(jī)上。

為了提升性能，降低時(shí)延，往往會(huì)提供本地短路策略，具體策略如下：

服務(wù)化實(shí)踐-多樣化調(diào)用方式

服務(wù)的調(diào)用方式，主要有三種：同步服務(wù)調(diào)用、異步服務(wù)調(diào)用、并行服務(wù)調(diào)用。最常用、簡(jiǎn)單的就是同步服務(wù)調(diào)用。

異步服務(wù)調(diào)用的工作原理如下：

詳細(xì)步驟如下：

1. 消費(fèi)者調(diào)用服務(wù)端發(fā)布的接口，接口調(diào)用由分布式服務(wù)框架包裝成動(dòng)態(tài)代理，發(fā)起遠(yuǎn)程服務(wù)調(diào)用；

2. 通信框架異步發(fā)送請(qǐng)求消息，如果沒有發(fā)生I/O異常，返回；

3. 請(qǐng)求消息發(fā)送成功后，I/O線程構(gòu)造Future對(duì)象，設(shè)置到RPC上下文中；

4. 用戶線程通過RPC上下文獲取Future對(duì)象；

5. 構(gòu)造Listener對(duì)象，將其添加到Future中，用于服務(wù)端應(yīng)答異步回調(diào)通知；

6. 用戶線程返回，不阻塞等待應(yīng)答；

7. 服務(wù)端返回應(yīng)答消息，通信框架負(fù)責(zé)反序列化等；

8. I/O線程將應(yīng)答設(shè)置到Future對(duì)象的操作結(jié)果中；

9. Future對(duì)象掃描注冊(cè)的監(jiān)聽器列表，循環(huán)調(diào)用監(jiān)聽器的operationComplete方法，將結(jié)果通知給監(jiān)聽器，監(jiān)聽器獲取到結(jié)果之后，繼續(xù)后續(xù)業(yè)務(wù)邏輯的執(zhí)行，異步服務(wù)調(diào)用結(jié)束。

并行服務(wù)調(diào)用，目的是為了提升服務(wù)調(diào)用的并行度，降低E2E時(shí)延。

服務(wù)化實(shí)踐-高性能、低時(shí)延

服務(wù)框架的性能，主要強(qiáng)調(diào)三個(gè)要素：1、I/O通信；2、序列化框架；3、線程調(diào)用模型。

如果使用Java語言，I/O框架推薦 Netty。

序列化框架推薦：Thrift、Avro序列化框架、PB等。線程調(diào)度模型建議參考Reactor。

一種線程模型的參考實(shí)現(xiàn)方式：Netty的線程模型

無鎖化串行設(shè)計(jì)理念

服務(wù)化實(shí)踐-故障隔離

故障隔離非常重要，由于經(jīng)常會(huì)采用同步服務(wù)調(diào)用模式，核心服務(wù)和非核心服務(wù)共用同一個(gè)線程池和消息隊(duì)列，非核心服務(wù)處理慢往往會(huì)阻塞核心服務(wù)，導(dǎo)致雪崩現(xiàn)象。

故障隔離的核心技術(shù)點(diǎn)如下：

1. 支持服務(wù)部署到不同線程/線程池中

2. 核心服務(wù)和非核心服務(wù)隔離部署

服務(wù)化實(shí)踐-服務(wù)治理

隨著業(yè)務(wù)規(guī)模的不斷擴(kuò)大，小服務(wù)資源浪費(fèi)等問題逐漸顯現(xiàn)，需要能夠基于服務(wù)調(diào)用的性能KPI數(shù)據(jù)進(jìn)行容量管理，合理分配各個(gè)服務(wù)的資源占用，提高機(jī)器的利用率。

線上業(yè)務(wù)發(fā)生故障時(shí)，需要對(duì)故障業(yè)務(wù)做服務(wù)降級(jí)、流量控制、流量遷移等，快速恢復(fù)業(yè)務(wù)。

隨著開發(fā)團(tuán)隊(duì)的不斷擴(kuò)大，服務(wù)的上線越來越隨意，甚至發(fā)生功能相同、服務(wù)名不同的服務(wù)同時(shí)上線。上線容易下線難，為了規(guī)范服務(wù)的上線和下線，在服務(wù)發(fā)布前，需要走服務(wù)預(yù)發(fā)布流程，由架構(gòu)師或者項(xiàng)目經(jīng)理對(duì)需要上線的服務(wù)做發(fā)布審核，審核通過的才能夠上線。

為了滿足服務(wù)線下管控、保障線上高效運(yùn)行，需要有一個(gè)統(tǒng)一的服務(wù)治理框架對(duì)服務(wù)進(jìn)行統(tǒng)一、有效管控，保障服務(wù)的高效、健康運(yùn)行。

服務(wù)治理是分布式服務(wù)框架的一個(gè)可選特性，盡管從服務(wù)開發(fā)和運(yùn)行角度看它不是必須的，但是如果沒有服務(wù)治理功能，分布式服務(wù)框架的服務(wù)SLA很難得到保障，服務(wù)化也很難真正實(shí)施成功。

從架構(gòu)上看，分布式服務(wù)框架的服務(wù)治理分為三層：

第1層為服務(wù)治理展示層，它主要由服務(wù)治理Portal組成，提供可視化的界面，方便服務(wù)運(yùn)維人員進(jìn)行治理操作。

第2層為服務(wù)治理SDK層，它主要由如下幾部分組成：

1. 服務(wù)治理元數(shù)據(jù)：服務(wù)治理元數(shù)據(jù)主要包括服務(wù)治理實(shí)體對(duì)象，包括服務(wù)模型、應(yīng)用模型、治理組織模型、用戶權(quán)限模型、數(shù)據(jù)展示模型等。元數(shù)據(jù)模型通過Data Mapper和模型擴(kuò)展，向上層界面屏蔽底層服務(wù)框架的數(shù)據(jù)模型，實(shí)現(xiàn)展示層和服務(wù)框架的解耦，元數(shù)據(jù)也可以用于展示界面的定制擴(kuò)展；

2. 服務(wù)治理接口：服務(wù)治理Portal調(diào)用服務(wù)治理接口，實(shí)現(xiàn)服務(wù)治理。例如服務(wù)降級(jí)接口、服務(wù)流控接口、服務(wù)路由權(quán)重調(diào)整接口、服務(wù)遷移接口等。服務(wù)接口與具體的協(xié)議無關(guān)，它通?；诜植际椒?wù)框架自身實(shí)現(xiàn)，可以是Restful接口，也可以是內(nèi)部的私有協(xié)議；

3. 服務(wù)治理客戶端類庫：由于服務(wù)治理服務(wù)本身通常也是基于分布式服務(wù)框架開發(fā)，因此服務(wù)治理Portal需要集成分布式服務(wù)框架的客戶端類庫，實(shí)現(xiàn)服務(wù)的自動(dòng)發(fā)現(xiàn)和調(diào)用；

4. 調(diào)用示例：客戶端SDK需要提供服務(wù)治理接口的參數(shù)說明、注意事項(xiàng)以及給出常用的調(diào)用示例，方便前端開發(fā)人員使用；

5. 集成開發(fā)指南：服務(wù)治理SDK需要提供集成開發(fā)指南，指導(dǎo)使用者如何在開發(fā)環(huán)境中搭建、集成和使用服務(wù)治理SDK。

第3層為后臺(tái)服務(wù)治理服務(wù)層：它通常由一組服務(wù)治理服務(wù)組成，可以單獨(dú)部署，也可以與應(yīng)用合設(shè)?？紤]到健壯性，通常選擇獨(dú)立集群部署。治理服務(wù)的可靠性由分布式服務(wù)框架自身來保證，治理服務(wù)宕機(jī)或者異常，不影響業(yè)務(wù)的正常使用。服務(wù)治理服務(wù)通常并不隨服務(wù)框架發(fā)布，治理服務(wù)是可選的插件，單獨(dú)隨服務(wù)治理框架交付。

服務(wù)化實(shí)踐-高可靠性

關(guān)鍵技術(shù)點(diǎn)設(shè)計(jì)如下：

1. 服務(wù)無狀態(tài)設(shè)計(jì)

2. 服務(wù)注冊(cè)中心集群，宕機(jī)不影響業(yè)務(wù)運(yùn)行

3. 服務(wù)提供者集群，集群容錯(cuò)屏蔽服務(wù)提供者故障

4. 服務(wù)健康狀態(tài)檢測(cè)，基于時(shí)延等性能KPI指標(biāo)

5. 服務(wù)治理中心集群，宕機(jī)不影響業(yè)務(wù)運(yùn)行

6. 服務(wù)級(jí)故障隔離

7. 核心服務(wù)獨(dú)立部署和集群

8. 跨機(jī)房路由和異地容災(zāi)

三、服務(wù)化不是銀彈

服務(wù)化會(huì)帶來很多收益，但是它卻不是銀彈。

服務(wù)化不是銀彈-時(shí)延問題

在服務(wù)化之前，業(yè)務(wù)通常都是本地API調(diào)用，本地方法調(diào)用性能損耗較小。服務(wù)化之后，服務(wù)提供者和消費(fèi)者之間采用遠(yuǎn)程網(wǎng)絡(luò)通信，增加了額外的性能損耗。

服務(wù)化不是銀彈-問題定位

在分布式環(huán)境下，如何高效的進(jìn)行問題定界定位和日志檢索

服務(wù)化不是銀彈-事務(wù)一致性

服務(wù)化、分布式部署之后，有邏輯關(guān)聯(lián)關(guān)系的多個(gè)數(shù)據(jù)庫操作被打散到集群中各個(gè)獨(dú)立的服務(wù)實(shí)例中，引入分布式環(huán)境下的事務(wù)一致性問題。

服務(wù)化不是銀彈-前后臺(tái)直接通信問題

前后臺(tái)直接通信問題如下：

存在的問題如下：

1. 客戶端需求和每個(gè)微服務(wù)暴露的細(xì)粒度API不匹配

2. 微服務(wù)使用的RPC私有協(xié)議，不是瀏覽器友好或防火墻友好的

3. 微服務(wù)難以重構(gòu)。隨著時(shí)間推移，我們可能想要更改系統(tǒng)劃分成服務(wù)的方式。如果客戶端與微服務(wù)直接通信，那么執(zhí)行這類重構(gòu)就非常困難了

服務(wù)化不是銀彈-團(tuán)隊(duì)協(xié)作問題

• 共享服務(wù)注冊(cè)中心問題：為了方便開發(fā)測(cè)試，經(jīng)常會(huì)在線下共用一個(gè)所有服務(wù)共享的服務(wù)注冊(cè)中心，這時(shí)，一個(gè)正在開發(fā)中的服務(wù)發(fā)布到服務(wù)注冊(cè)中心，可能會(huì)導(dǎo)致一些消費(fèi)者不可用。

• 多團(tuán)隊(duì)進(jìn)度協(xié)同問題：服務(wù)提供者和消費(fèi)者相互依賴問題，開發(fā)依賴、測(cè)試依賴等。

• 接口前向兼容性問題：由于線上的Bug修復(fù)、內(nèi)部重構(gòu)和需求變更，服務(wù)提供者會(huì)經(jīng)常修改內(nèi)部實(shí)現(xiàn)，包括但不限于：接口參數(shù)變化、參數(shù)字段變化、業(yè)務(wù)邏輯變化和數(shù)據(jù)表結(jié)構(gòu)變化。在實(shí)際項(xiàng)目中經(jīng)常會(huì)發(fā)生服務(wù)提供者修改了接口或者數(shù)據(jù)結(jié)構(gòu)，但是并沒有及時(shí)知會(huì)到所有消費(fèi)者，導(dǎo)致服務(wù)調(diào)用失敗

四、未來演進(jìn)方向-微服務(wù)架構(gòu)

微服務(wù)的劃分原則是難點(diǎn)，根據(jù)華為的經(jīng)驗(yàn)：微服務(wù)劃分不是一步到位，而是不斷的迭代和演進(jìn)，最終找到適合自己團(tuán)隊(duì)和業(yè)務(wù)的微服務(wù)劃分原則。

未來演進(jìn)方向-基于Docker部署微服務(wù)

使用Docker部署微服務(wù)的優(yōu)點(diǎn)總結(jié)：

1. 一致的環(huán)境：線上線下環(huán)境一致

2. 避免對(duì)特定云基礎(chǔ)設(shè)施提供商的依賴

3. 降低運(yùn)維團(tuán)隊(duì)負(fù)擔(dān)

4. 高性能：接近裸機(jī)的性能

5. 多租戶

未來演進(jìn)方向-云端微服務(wù)

利用云平臺(tái)的彈性資源調(diào)度，動(dòng)態(tài)性等，可以實(shí)現(xiàn)微服務(wù)的Dev&Ops

最后我們一起回顧下服務(wù)化的演進(jìn)歷程：

Q&A

Q1：上面提到服務(wù)化缺點(diǎn)的第三條接口變更問題，請(qǐng)問微服務(wù)是如何解決這個(gè)問題的呢？或者說微服務(wù)相比之下什么優(yōu)勢(shì)會(huì)避免這個(gè)問題？

A1：根據(jù)我們團(tuán)隊(duì)的經(jīng)驗(yàn)，主要從如下幾個(gè)方面降低影響：1、微服務(wù)的接口就是契約，制定 接口兼容性規(guī)范；涉及到技術(shù)和管理兩個(gè)層面；2、微服務(wù)鼓勵(lì)只做一件事情，因此它更加穩(wěn)定；3、基于消費(fèi)者契約測(cè)試，快速發(fā)現(xiàn)兼容性問題。

Q2：微服務(wù)架構(gòu)里，分布式事務(wù)如何做的，對(duì)數(shù)據(jù)一致性要求較高的系統(tǒng)是否適合拆分成微服務(wù)，或者說微服務(wù)的粒度如何把握？

A2：分布式事務(wù)是難點(diǎn)，策略如下：1）如果業(yè)務(wù)上能夠承受非強(qiáng)一致性，建議通過事務(wù)補(bǔ)償?shù)姆绞阶鲎罱K一致性，可以基于MQ等中間件來實(shí)現(xiàn)；2）如果是轉(zhuǎn)賬、實(shí)時(shí)計(jì)費(fèi)、充值等對(duì)實(shí)時(shí)性要求高的，往往選擇強(qiáng)一致性事務(wù)，就需要引入TCC等分布式事務(wù)框架。無論如何，只要做分布式，事務(wù)一致性就會(huì)成為問題，跟是否是微服務(wù)沒必然關(guān)系。

Q3：生產(chǎn)環(huán)境中的服務(wù)注冊(cè)中心必然是共享的，那如何去做灰度發(fā)布或者A/B Test呢？

A3：一種比較好的服務(wù)灰度策略是：1）服務(wù)框架提供灰度規(guī)則框架，包括后臺(tái)引擎和前臺(tái)Portal，由業(yè)務(wù)配置灰度規(guī)則；2）分布式服務(wù)框架支持灰度規(guī)則推送和業(yè)務(wù)自定義路由；3）前端SLB ,例如Ngix做灰度插件，接收灰度規(guī)則。消息從前端門戶接入到后端服務(wù)路由，都支持基于規(guī)則的路由分發(fā)策略，實(shí)現(xiàn)灰度發(fā)布。

Q4：Netty的無鎖化串行會(huì)比有鎖的并行性能更高嗎？有案例嗎？華為現(xiàn)在都是用Docker部署應(yīng)用嗎？

A4：Netty的無鎖化串行性能問題：1）在實(shí)際項(xiàng)目中，線程池爭(zhēng)用模式和串行模式我們都使用過，Netty的無鎖化串行模式性能更高。Docker部署應(yīng)用：華為的公有云和私有云都支持基于Docker部署應(yīng)用，由客戶根據(jù)需要自主選擇。

Q5：IO通信是怎么保證每次連接成功的呢？

A5：NIO通信本身并不保證每次連接都成功，它的連接是異步的，你可以根據(jù)如下兩種策略獲得異步鏈接的結(jié)果：1）發(fā)起連接之后主動(dòng)調(diào)用同步方法等待結(jié)果返回，阻塞式；2）獲取異步連接Future，添加Listener監(jiān)聽器監(jiān)聽連接結(jié)果，這種模式是異步回調(diào)，不會(huì)阻塞當(dāng)前線程。

Q6：使用zk作為服務(wù)注冊(cè)中心，對(duì)與某個(gè)服務(wù)當(dāng)客戶端連接數(shù)很多時(shí)候節(jié)點(diǎn)變化會(huì)引起羊群效應(yīng)，怎么處理這種問題呢？或者說如何避免這種問題呢？

A6：這個(gè)問題真是好！通常而言，大家會(huì)使用服務(wù)注冊(cè)中心做服務(wù)可用性檢測(cè)，如果發(fā)現(xiàn)某個(gè)服務(wù)節(jié)點(diǎn)不可用，就會(huì)將其從注冊(cè)中心中刪除。但是，有一種場(chǎng)景是ZK檢測(cè)的結(jié)果跟客戶端和服務(wù)端實(shí)際的連接狀態(tài)不一致。從ZK看，服務(wù)提供者可以使用。但是由于服務(wù)消費(fèi)者跟提供者之間的鏈路已經(jīng)中斷，跟ZK的鏈路卻是正常，這種情況下就會(huì)出現(xiàn)狀態(tài)不一致問題。所以，只依靠ZK做狀態(tài)檢測(cè)還不夠，需要服務(wù)提供者和消費(fèi)者的鏈路層做雙向心跳檢測(cè)。

Q7：我現(xiàn)在做的系統(tǒng)是zk做注冊(cè)中心服務(wù)把地址注冊(cè)上去（臨時(shí)節(jié)點(diǎn)），客戶端拿地址請(qǐng)求，http的，現(xiàn)在發(fā)現(xiàn)如果是公網(wǎng)調(diào)用的話，對(duì)公網(wǎng)資源要求還挺多的，zk公網(wǎng)， 應(yīng)用公網(wǎng)；為了減少對(duì)公網(wǎng)需求，中間加一層nginx，把nx地址注冊(cè)上去，不過又得加個(gè)http探測(cè)監(jiān)控程序，異常還得刪掉注冊(cè)數(shù)據(jù)，不知道這種做法是否妥當(dāng)？

A7：Ng監(jiān)聽ZK注冊(cè)的服務(wù)提供者URL即可，問題不大。

Q8：用Netty做同通信框架，監(jiān)控上報(bào)應(yīng)該怎么設(shè)計(jì)更完善？

A8：建議的方式如下：Netty自身不用告警，監(jiān)聽Netty的異常事件，然后通過MQ吐出去，監(jiān)控系統(tǒng)訂閱通信框架的事件主題，實(shí)現(xiàn)通信框架和監(jiān)控系統(tǒng)解耦。

Q9：SOA和微服務(wù)架構(gòu)的區(qū)別和聯(lián)系是？看起來好像??！

A9：1) 服務(wù)拆分粒度：SOA首先要解決的是異構(gòu)應(yīng)用的服務(wù)化；微服務(wù)強(qiáng)調(diào)的是服務(wù)拆分盡可能小，最好是獨(dú)立的原子服務(wù)；

2) 服務(wù)依賴：傳統(tǒng)的SOA服務(wù)，由于需要重用已有的資產(chǎn)，存在大量的服務(wù)間依賴；微服務(wù)的設(shè)計(jì)理念是服務(wù)自治、功能單一獨(dú)立，避免依賴其它服務(wù)產(chǎn)生耦合，耦合會(huì)帶來更高的復(fù)雜度；

3) 服務(wù)規(guī)模：傳統(tǒng)SOA服務(wù)粒度比較大，多數(shù)會(huì)采用將多個(gè)服務(wù)合并打成war包的方案，因此服務(wù)實(shí)例數(shù)比較有限；微服務(wù)強(qiáng)調(diào)盡可能拆分，同時(shí)很多服務(wù)會(huì)獨(dú)立部署，這將導(dǎo)致服務(wù)規(guī)模急劇膨脹，對(duì)服務(wù)治理和運(yùn)維帶來新的挑戰(zhàn)；

4) 架構(gòu)差異：微服務(wù)化之后，服務(wù)數(shù)量的激增會(huì)引起架構(gòu)質(zhì)量屬性的變化，例如企業(yè)集成總線ESB（實(shí)總線）逐漸被P2P的虛擬總線替換；為了保證高性能、低時(shí)延，需要高性能的分布式服務(wù)框架保證微服務(wù)架構(gòu)的實(shí)施；

5) 服務(wù)治理：傳統(tǒng)基于SOA Governance的靜態(tài)治理轉(zhuǎn)型為服務(wù)運(yùn)行態(tài)微治理、實(shí)時(shí)生效；

6) 敏捷交付：服務(wù)由小研發(fā)團(tuán)隊(duì)負(fù)責(zé)微服務(wù)設(shè)計(jì)、開發(fā)、測(cè)試、部署、線上治理、灰度發(fā)布和下線，運(yùn)維整個(gè)生命周期支撐，實(shí)現(xiàn)真正的DevOps。

總結(jié)：量變引起質(zhì)變，這就是微服務(wù)架構(gòu)和SOA 服務(wù)化架構(gòu)的大差異。

Q10：如果要將現(xiàn)有單機(jī)服務(wù)重構(gòu)到微服務(wù)，應(yīng)該考慮哪些問題？數(shù)據(jù)遷移的安全問題怎么解決？有什么實(shí)踐方案嗎？

A10：需要考慮的問題如下：1）當(dāng)前單機(jī)應(yīng)用是否能夠滿足業(yè)務(wù)發(fā)展需要，有沒有必要做服務(wù)化改造和分布式部署；2）評(píng)估遷移的工作量，以及人員技能培訓(xùn)等。3）自研服務(wù)框架還是使用開源的方案。

數(shù)據(jù)遷移安全問題：如果內(nèi)網(wǎng)，通常不會(huì)涉及到復(fù)雜的安全控制問題；如果跨公網(wǎng)，建議加入API Gateway統(tǒng)一做安全管控。

實(shí)踐方案：公開的資料，可以參考淘寶的服務(wù)化實(shí)踐、京東的服務(wù)化實(shí)踐等。其實(shí)華為也有，不過遺憾的是目前政策不允許公開出來。

Q11：麻煩李老師介紹下你們?nèi)A為內(nèi)部基于netty做socke通信的協(xié)議設(shè)計(jì)的最佳實(shí)踐。

A11：這個(gè)問題很大，簡(jiǎn)單介紹下思路。在11年和13年的時(shí)候我分別主持設(shè)計(jì)了華為基于Mina和Netty的統(tǒng)一NIO通信框架。設(shè)計(jì)要點(diǎn)如下：

1）要熟悉Netty的線程調(diào)度模型、常用的類庫等，能夠熟練使用Netty；

2）NIO通信框架的分層原則，哪些該做、哪些不該做，需要識(shí)別出來；

3）擴(kuò)展點(diǎn)，預(yù)留足夠的擴(kuò)展點(diǎn)給上層應(yīng)用協(xié)議棧做擴(kuò)展；

4）可以內(nèi)置配置化的安全策略、握手認(rèn)證、心跳檢測(cè)等機(jī)制；

5）可服務(wù)性設(shè)計(jì)，包括日志、性能KPI指標(biāo)等。

讀者福利

加微信：haolagui521備注51CTO領(lǐng)取附送學(xué)習(xí)進(jìn)階架構(gòu)資料、PDF書籍文檔、面試資料

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國(guó)云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開啟，新人活動(dòng)云服務(wù)器買多久送多久。

文章題目：華為架構(gòu)師8年經(jīng)驗(yàn)談：從單體架構(gòu)到微服務(wù)的服務(wù)化演進(jìn)之路-創(chuàng)新互聯(lián)
路徑分享：http://muchs.cn/article36/dhigpg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、網(wǎng)站排名、微信公眾號(hào)、外貿(mào)建站、網(wǎng)站維護(hù)、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)