91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

微服務劃分的方法有哪些

發布時間:2021-12-14 15:47:25 來源:億速云 閱讀:161 作者:iii 欄目:大數據

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

一、拆分姿勢

1、姿勢一

新浪微博微服務專家胡忠想從縱橫兩個維度來劃分,簡單粗暴:

1.1 縱向拆分

從業務維度進行拆分。標準是按照業務的關聯程度來決定,關聯比較密切的業務適合拆分為一個微服務,而功能相對比較獨立的業務適合單獨拆分為一個微服務。

1.2 橫向拆分

從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務調用,且依賴的資源獨立不與其他業務耦合。

縱向以業務為基準,關系鐵的在一起;橫向功能獨立的在一起。我想如果拆分這么簡單,你有底氣拆,敢拆嗎?所以我們又繼續比對一下其他專家的言論。

微服務劃分的方法有哪些

2、姿勢二

阿里的小伙伴從綜合的維度來看,部分維度和上面會有重合。

2.1 服務拆分要迎合業務的需要

充分考慮業務獨立性和專業性,避免以團隊來定義服務邊界,從而出現“土匪”搶地盤,影響團隊信任。

這個維度和上面的類似,但是強調的是業務和團隊成員的各自獨立性,對上面是一種很好的補充。

2.2 拆分后的維護成本要低于拆分前

這里的維護成本包括:人力、物力、時間。

這里的成本對大部分中小團隊來說都是必須要考慮的重要環節,如果投入和收益不能成正比,或者超出領導的預算或者市場窗口,那么先進的技術就是絆腳石,千萬不要迷戀技術,所謂工程師思維千萬要不得。

2.3 拆分不僅僅是架構的調整,組織結構上也要做響應的適應性優化

確保拆分后的服務由相對獨立的團隊負責維護。

這句話怎么理解呢?傳統的團隊劃分是按照產品部、前端、后端橫向劃分,微服務化以后的團隊可能就會是吃一張披薩餅的人數,產品、前端、后端被歸類到服務里面,以服務為中心來分配人數。《微服務為什么選Spring Cloud?》推薦大家閱讀。

2.4 拆分最有價值的結果是提高了系統的可擴展性

把具有不同擴展性要求的服務拆分出來,分別進行部署,降低成本,提高效率。比如全文搜索服務。

這點和上面的按功能獨立性來拆分有點類似,功能獨立其實就是面向可擴展性。

2.5 考慮軟件發布頻率

比如把20%經常變動的部分進行抽離,80%不經常變動的單獨部署和管理。說白了就是按照8/2原則進行拆分。這個拆分的好處很明顯,可以盡可能的減少發布產生的后遺癥,比如用戶體驗、服務相互干擾等。推薦閱讀:微服務架構如何保證安全性?

但是這里有一個問題,假如20%的服務分屬于不同的業務層面,那該怎么辦?所以這里的拆分應該有個優先級,在拆分相互沖突的時候應該要優先考慮權重比較高的那個。

微服務劃分的方法有哪些

3、姿勢三

資深技術專家李運華在他的架構書中給出的拆分:

3.1 基于業務邏輯

將系統中的業務按照職責范圍進行識別,職責相同的劃分為一個單獨的服務。這種業務優先的方式在前面兩種姿勢當中都出現過,可見是最基本,最重要的劃分方式(沒有之一)。

3.2 基于穩定性

將系統中的業務模塊按照穩定性進行排序。穩定的、不經常修改的劃分一塊;將不穩定的,經常修改的劃分為一個獨立服務。比如日志服務、監控服務都是相對穩定的服務,可以歸到一起。這個很類似上面提到的2/8原則,80%的業務是穩定的。

至此你會發現服務的拆分真的沒有絕對的標準,只有合理才是標準。

3.3 基于可靠性

同樣,將系統中的業務模塊按照可靠性進行排序。對可靠性要求比較高的核心模塊歸在一起,對可靠性要求不高的非核心模塊歸在一塊。

這種拆分的高明可以很好的規避因為一顆老鼠屎壞了一鍋粥的單體弊端,同時將來要做高可用方案也能很好的節省機器或帶寬的成本。

3.4 基于高性能

同上,將系統中的業務模塊按照對性能的要求進行優先級排序。把對性能要求較高的模塊獨立成一個服務,對性能要求不高的放在一起。比如全文搜索,商品查詢和分類,秒殺就屬于高性能的核心模塊。

微服務劃分的方法有哪些

4、姿勢盤點

以上不同拆分姿勢各有千秋,異曲同工!

  • 對業務邏輯均不約而同的放在第一位。

  • 對業務模塊的穩定性和可靠性,對功能的獨立性、可擴展性都有相似的看法

  • 強調拆分應該是多選,而不是單選。具體情況具體分析,可以自由靈活排列組合。

**二、題外話

如果你把上面的劃分角度背下來了拿去現場套,可能還會遇到矛盾或爭議。

1、業務矛盾

假如我們按照業務來劃分,根據粒度大小,可能存在以下兩種:

  • 第一種分為商品、交易、用戶3個服務;

  • 第二種分為商品、訂單、支付、物流、買家、賣家6個服務。

3 VS 6,這該怎么辦?

如果你的團隊只有9個人,那么分成3個是合理的,如果有18個人,那么6個服務是合理的。這里引入團隊成員進行協助拆分。

可見拆分的姿勢不是單選,而是多選的。這個時候必須要考慮團隊成員數量。

在拆分遇到爭議的時候,一般情況下我們增加一項拆分條件,雖然不是充要條件,但至少我們的答案會更加接近真理。

除了業務可能存在爭議,其他的劃分也會有爭議,比如一個獨立的服務到底需要多少人員的配置?

2、三個火槍手(人員配置)

上面提到的人員數量配置,這里為什么是9和18呢?(這里的團隊配置參考李云華前輩提到的三個火槍手的觀點)

換一種問法,為什么說是三個人分配一個服務(當然,成員主要是后端人員)?

  • 假設是1個人,請個假、生個病都不行。一個人會遇到單點的問題,所以不合理。

  • 假設是2個人,終于有備份了,但是抽離一個后,剩下1個壓力還是很大,不合理。

  • 假設是3個人,抽離一個還有2個在。而且數字3是個穩定而神奇數字,用得好事半功倍。特別是遇到技術討論,3個人相對周全,如果是2個可能會各持己見,帶有自我的偏見和盲區。

那么這個3是不是就是穩定的數量呢?

假設你做的是邊開飛機邊換引擎的重寫工作,那么前期3個人都可能捉襟見肘。但是到了服務后期,你可能1個就夠了。

所以3在我的理解應該是一個基準線,不同的時間段會有上下波動,但是相對穩定。

到此,相信大家對“微服務劃分的方法有哪些”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

偏关县| 定日县| 无为县| 东城区| 塔城市| 台江县| 额尔古纳市| 建湖县| 昭平县| 侯马市| 安化县| 噶尔县| 遂平县| 彭山县| 固阳县| 茂名市| 广宗县| 宿州市| 松阳县| 德化县| 丽水市| 耒阳市| 鄢陵县| 田林县| 崇左市| 兴业县| 临朐县| 赤壁市| 盐城市| 新疆| 娄烦县| 沙河市| 威信县| 枣庄市| 万荣县| 丹寨县| 建平县| 昆明市| 新巴尔虎右旗| 阿克苏市| 惠安县|