偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

面試基操:微服務(wù)拆分需要考慮什么因素?

開發(fā) 項目管理
在實際互聯(lián)網(wǎng)項目開發(fā)中,分布式事務(wù)不宜設(shè)計得太重,通常來說異步的場景使用事務(wù)性MQ來解決,

面試官:微服務(wù)如何拆分?需要考慮什么因素?

候選人:一般按照功能拆分

面試官:還有嗎?

候選人:唔……

要拆分微服務(wù),首先我們要了解微服務(wù)拆了會有什么問題?怎么合理拆服務(wù)?

拆分服務(wù)會帶來什么問題?

舉個電商系統(tǒng)下單扣庫存的例子。

對于單體應(yīng)用,通訊在進程內(nèi)部進行,下單方法調(diào)用扣庫存方法,有問題就回滾事務(wù),利用數(shù)據(jù)庫同一個Session會話的ACID特性干活,保證數(shù)據(jù)的強一致性,即使在調(diào)用下單方法成功后應(yīng)用崩潰,數(shù)據(jù)也不會提交到數(shù)據(jù)庫,不會產(chǎn)生臟數(shù)據(jù)。

而拆分成各個微服務(wù)后,代碼、數(shù)據(jù)庫進行了隔離,下單扣庫存邏輯變成了訂單服務(wù)通過RPC調(diào)用庫存服務(wù),由于不受同一個數(shù)據(jù)庫Session會話控制,就必然會存在因業(yè)務(wù)處理失敗、應(yīng)用崩潰、網(wǎng)絡(luò)通訊異常等一系列問題導(dǎo)致的數(shù)據(jù)不一致。

這是一個典型的復(fù)雜度轉(zhuǎn)移的例子——單體應(yīng)用的代碼復(fù)雜度轉(zhuǎn)移到了微服務(wù)之間的通訊復(fù)雜度,整體的復(fù)雜度并沒有降低。

回到經(jīng)典的分布式CAP定理:數(shù)據(jù)一致性、可用性、分區(qū)容錯性,三者取其二。

CAP是分布式系統(tǒng)中三個維度的“客戶承諾”:

  • 一致性:要么我給你返回一個錯誤,要么我給你返回絕對一致的最新數(shù)據(jù),強調(diào)數(shù)據(jù)正確。
  • 可用性:我一定會給你返回數(shù)據(jù),不會給你返回錯誤,但不保證數(shù)據(jù)最新,強調(diào)的是服務(wù)不出錯。
  • 分區(qū)容錯性:我會一直運行,不管我的內(nèi)部出現(xiàn)何種數(shù)據(jù)同步問題,強調(diào)的是不掛掉。

為了解決數(shù)據(jù)一致性問題,業(yè)界又引入了各種一致性保障機制,比如BASE理論(基本可用、軟狀態(tài)、最終一致)、分布式事務(wù)DTP模型(XA協(xié)議、TCC協(xié)議)、JTA模型等等,根據(jù)對數(shù)據(jù)一致性的要求又劃分為強一致性、弱一致性、最終一致性的方案,在分布式系統(tǒng)中通過一系列措施來保證ACID。

在實際互聯(lián)網(wǎng)項目開發(fā)中,分布式事務(wù)不宜設(shè)計得太重,通常來說異步的場景使用事務(wù)性MQ來解決,比如RabbitMQ、Kafka、RocketMQ等;同步的場景使用業(yè)務(wù)狀態(tài)機來規(guī)避它們,比如訂單分正向銷售單、逆向售后單,單據(jù)有不同維度的狀態(tài),比如支付狀態(tài)、退款狀態(tài)、物流狀態(tài)、開票狀態(tài)等等,對于出錯的環(huán)節(jié)進行客戶干預(yù)、系統(tǒng)告警或客服干預(yù),暫時停留在異常節(jié)點,這里的“狀態(tài)”可以理解為BASE理論中的軟狀態(tài)。

說到底還是用BASE理論指導(dǎo)生產(chǎn)。

說那么多,我們通過拆分微服務(wù),提高了系統(tǒng)的分區(qū)容錯性與可用性,卻犧牲了單體應(yīng)用的一致性優(yōu)勢,所以說,不要為了拆而拆,拆服務(wù)也需要合理“動機”,那什么樣的“動機”是合理的呢?

如何合理拆分微服務(wù)?

OK,了解了服務(wù)拆分帶來的問題后,我們拆服務(wù)就得更加嚴(yán)謹(jǐn)了,那怎么合理拆呢?

這里提供一些思路。

一、按單一職責(zé)拆

還是以我們的電商平臺舉例,一開始我們最核心的OMS訂單系統(tǒng)做了特別多事情,包括:用戶、下單、商品、庫存、出入庫、營銷……

隨著公司業(yè)務(wù)快速增長,OMS代碼激增,新增/修改一個功能就要影響幾乎整個鏈路,穩(wěn)定性降低,也大大增加了風(fēng)險,運維變得十分困難,這時不得不把各個模塊剝離出來,獨立成為UC用戶服務(wù)、PMS商品服務(wù)、CIS中央庫存服務(wù)、WMS出入庫服務(wù)、MCS營銷中心等等。

我們按照單一職責(zé)的劃分原則,每一個獨立的服務(wù)只提供該業(yè)務(wù)領(lǐng)域的核心功能,繼而每個獨立的服務(wù)演化出更為豐富的功能,數(shù)據(jù)庫也進行垂直拆分提供應(yīng)用獨立訪問,并且每個服務(wù)提供雙節(jié)點保證高可用。

二、按團隊組織架構(gòu)拆

這里必須提一提軟件架構(gòu)設(shè)計中的第一定律——康威定律。

康威定律是馬爾文·康威1967年提出的:“設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計的組織的溝通結(jié)構(gòu)?!蓖ㄋ椎貋碇v:產(chǎn)品必然是其(人員)組織溝通結(jié)構(gòu)的縮影。

康威定律可總結(jié)為以下四個定律:

第一定律:組織溝通方式會通過系統(tǒng)設(shè)計表達出來。

這條定律重點是講組織架構(gòu)和溝通對系統(tǒng)設(shè)計的影響。

組織的溝通和系統(tǒng)的設(shè)計之間緊密相連,特別是復(fù)雜系統(tǒng),解決好人與人的溝通才能有一個更好的系統(tǒng)設(shè)計。

溝通的問題會帶來系統(tǒng)設(shè)計的問題,進而影響整個系統(tǒng)的開發(fā)效率和最終產(chǎn)品結(jié)果,這也是為什么互聯(lián)網(wǎng)公司都追求小團隊的原因之一。

第二定律:時間再多一件事情也不可能做得完美,但總有時間做完一件事情。

人手永遠(yuǎn)是不夠的,事情永遠(yuǎn)是做不完的,但可以一件一件來。

這不就是軟件行業(yè)中“敏捷開發(fā)”模式所解決的問題嗎,面對這樣的狀況,敏捷開發(fā)可以做到不斷迭代、持續(xù)交付、快速驗證和反饋,并持續(xù)改進。

再牛的開發(fā)也會寫出BUG,再全面的測試覆蓋率也無法測出所有的問題,解決方案不是消滅這些問題,是容忍一些問題的存在,然后通過適當(dāng)?shù)脑O(shè)計(冗余、監(jiān)控、高可用設(shè)計),當(dāng)問題發(fā)生時能夠快速解決。

幾個開發(fā)人員的小公司,去追求微服務(wù)、中臺架構(gòu)、這是追求完美嗎?

不是,這是找死。

好的架構(gòu)不是買來的,也不是設(shè)計出來的,而是根據(jù)業(yè)務(wù)落地生根長期演化來的。

第三定律:線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。

這一定律是第一定律的具體應(yīng)用。

想象一下如果公司的架構(gòu)是這樣的:

團隊是分布式,每個團隊都包含產(chǎn)品、研發(fā)、測試、運維等角色,而此時系統(tǒng)是單體應(yīng)用,那項目溝通和協(xié)調(diào)的成本是巨大的,弄不好還會打起來。

如果將單塊的系統(tǒng)拆分成微服務(wù),每個團隊負(fù)責(zé)自己的部分,對外提供對應(yīng)的接口即可,互不干擾,系統(tǒng)效率將得到提升,這與軟件設(shè)計中的高內(nèi)聚、低耦合是相通的。

直白地說就是想要什么樣的系統(tǒng)就搭建什么樣的團隊,有什么樣的團隊就搭建什么樣的系統(tǒng),需要前后端分離的系統(tǒng)就搭建前后端分離的團隊;反之,擁有前后端分離的團隊就可以設(shè)計前后端分離的系統(tǒng)。

第四定律:大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。

“話說天下大勢,分久必合,合久必分?!毕到y(tǒng)越復(fù)雜,越需要增加人手,人手越多,溝通成本也呈指數(shù)增長,分而治之便是大多數(shù)公司選擇的解決方案,分不同的層級,分不同的小團隊,讓團隊內(nèi)部完成自治理,然后統(tǒng)一對外溝通。

我們試著從康威定律來推導(dǎo)系統(tǒng)的架構(gòu)演進方向,自然知道微服務(wù)的拆解粒度了。

SOA 也好、微服務(wù)也好,解決的根本問題是團隊分工問題,這是大型軟件發(fā)展的必然,不因為人的喜好而改變,當(dāng)你讀懂康威定律,就會發(fā)現(xiàn)“服務(wù)拆分粒度難以準(zhǔn)確把握”根本不是本質(zhì)問題,你有幾個 2 pizza 團隊,最好就拆成幾個微服務(wù)。

只有一個開發(fā)人員時,盡量就做單體應(yīng)用,不要沒事找刺激拆成 10 個微服務(wù),最終這個開發(fā)人員還會把他合成一個。

微服務(wù)要求縱向的 2 pizza 團隊(無數(shù)個小團隊,包含開發(fā)、測試、運維),如果團隊還是處在橫向結(jié)構(gòu)的場景下(開發(fā)、運維、測試各是一個團隊),比如說一些傳統(tǒng)大型企業(yè),去實施微服務(wù)會讓他們很痛苦,尤其是運維團隊。

總結(jié)一下

具體實踐建議:

我們要用一切手段提升溝通效率,比如slack,github,wiki。能2個人講清楚的事情,就不要拉更多人,每個人每個系統(tǒng)都有明確的分工,出了問題知道馬上找誰,避免踢皮球。

通過MVP的方式來設(shè)計系統(tǒng),通過不斷的迭代來驗證優(yōu)化,系統(tǒng)應(yīng)該是彈性設(shè)計的。

你想要什么樣的系統(tǒng)設(shè)計,就架構(gòu)什么樣的團隊,能扁平化就扁平化。最好按業(yè)務(wù)來劃分團隊,這樣能讓團隊自然的自治內(nèi)聚,明確的業(yè)務(wù)邊界會減少和外部的溝通成本,每個小團隊都對自己的模塊的整個生命周期負(fù)責(zé),沒有邊界不清,沒有無效的扯皮,inter-operate, not integrate。

做小而美的團隊,人多會帶來溝通的成本,讓效率下降。亞馬遜的Bezos有個逗趣的比喻,如果2個披薩不夠一個團隊吃的,那么這個團隊就太大了。事實上一般一個互聯(lián)網(wǎng)公司小產(chǎn)品的團隊差不多就是7,8人左右。

總之,只要說得清楚,運維能力又能跟上,服務(wù)拆分一般就是合理的!

責(zé)任編輯:姜華 來源: 今日頭條
相關(guān)推薦

2024-11-06 16:27:12

2019-04-04 12:59:03

微服務(wù)企業(yè)數(shù)字化

2012-07-25 09:08:02

SaaS云計算云開發(fā)

2022-03-31 08:15:38

微服務(wù)服務(wù)拆分架構(gòu)

2013-05-27 09:21:05

虛擬化IT企業(yè)應(yīng)用

2013-06-03 09:50:27

虛擬化虛擬化解決方案

2014-03-07 09:25:00

2010-08-10 13:05:23

選擇IT培訓(xùn)機構(gòu)

2012-12-03 10:22:49

Linux服務(wù)器

2021-06-10 11:12:23

微服務(wù)微服務(wù)架構(gòu)

2012-11-22 10:23:21

服務(wù)器虛擬化

2013-06-06 10:19:23

虛擬化解決方案虛擬化

2021-12-02 05:58:11

物聯(lián)網(wǎng)云平臺物聯(lián)網(wǎng)IOT

2018-07-27 10:46:47

存儲系統(tǒng)因素

2013-08-28 09:38:15

SDN軟件定義網(wǎng)絡(luò)部署

2018-11-26 05:01:07

物聯(lián)網(wǎng)安全物聯(lián)網(wǎng)IOT

2016-01-20 09:54:51

微服務(wù)架構(gòu)設(shè)計SOA

2024-09-03 09:31:41

微服務(wù)面試官系統(tǒng)

2022-03-07 08:13:06

MQ消息可靠性異步通訊

2011-08-30 10:54:48

遠(yuǎn)程服務(wù)器服務(wù)器管理工具服務(wù)器虛擬化
點贊
收藏

51CTO技術(shù)棧公眾號