自動化微服務治理的優(yōu)點有哪些

本篇內(nèi)容介紹了“自動化微服務治理的優(yōu)點有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

微服務粒度適應度函數(shù)

對于微服務架構來說，最令人頭疼的一個問題就是微服務粒度。從最源頭上，我們應該遵循『兩個披薩團隊』這個定律，即：

單個服務的設計，所有參與人從設計、開發(fā)、測試、運維所有人加起來 只需要 2 個披薩就夠了。

但是，事實上從國內(nèi)大中小公司的實踐情況來看，并非如此。往往是一個團隊維護了超過其自身數(shù)量的微服務，即 6 個開發(fā)人員可能維護了 8  個微服務。大家常犯的一個錯誤是：通過技術維度而非業(yè)務維度劃分微服務。關于這部分的自動化，我暫時找不到頭緒。但是，我們可以判斷兩個微服務是否可以合并：即基于  Git 日志的微服務粒度合理性分析。

• 服務提交人數(shù)。通過 git log 來查看單個微服務的提交情況

• 變更頻率。尋找多個模塊之間，是否存在大量同時變更的情況

• 需求關聯(lián)度。通過識別提交信息規(guī)范，來識別多個微服務、模塊、類是否存在經(jīng)常同時變更

• 前提：匹配提交規(guī)范。

在這個時候，我們只需要使用和 coca git 類似的解析函數(shù)，就能達到類似的效果。

API 的適應度函數(shù)

在 Coca 中已經(jīng)內(nèi)置了 API 分析相關的功能，可以支持識別 Spring 的 API 注解，以及服務聲明的 API  方式，同時分析調(diào)用關系等等。所以，我就不需要開發(fā)一個這樣的功能了，只需要稍微完善一下，補充一些分值情況。對于 API 設計來說，這個工具要做這么幾件事：

• API 命名的規(guī)范。如不一致的命名方式

• 參數(shù)合理性。如過多或者過少、是否不應該出現(xiàn)在 URL 中。

• 是否符合 RESTful 規(guī)范。如 URL 中不應該出現(xiàn) get 和 post 等字眼，是否所有的 API 都是 post。

• 是否出現(xiàn)跨服務使用相同的資源前綴。

對于大部分的公司來說，要做到 RESTful 的第一級都相當?shù)睦щy。

數(shù)據(jù)庫表適應度函數(shù)

微服務把服務間調(diào)用從函數(shù)調(diào)用變成了遠程調(diào)用，這也意味著，我們并不能從 A 服務直接訪問 B 服務的數(shù)據(jù)庫，而是通過訪問 B  服務的接口，借助它去訪問數(shù)據(jù)庫。但是，在某些場景下，A 和 B 是需要共用數(shù)據(jù)庫(比如說，收費的 Oracle 數(shù)據(jù)庫實例)，但是我們需要強制性的限制 A 和  B 服務對于表的訪問。所以，我們需要分析多個服務之間是否存在對于同一個表的修改，又或者是存在對于多個表的修改。

1. 表和服務關系維護。掃描 MyBatis 等這一類的工具，生成表和服務關系維護

2. 實現(xiàn)『數(shù)據(jù)庫表-映射服務』的快照測試。

簡單來說，我們的工具在這一部分所要做的事情是：每次代碼提交時，進行自動化地掃描，生成一個快照。剛其與存儲的快照進行對比，判斷數(shù)據(jù)庫是否有問題。隨后設置一個合理的調(diào)優(yōu)公式，也就是這部分的架構適應度函數(shù)。

分層架構適應度函數(shù)

在解決了表面的問題之后，我們可以嘗試達到整潔架構這一目的。對于分層架構來說，我們要做的事情可能會稍微復雜一下。不過，好在復雜的調(diào)用關系識別，已經(jīng)由  Coca 實現(xiàn)了。于是乎，對于我們的分層架構適應度函數(shù)，只需要做到這么一些事情：

微服務之間是否存在函數(shù)調(diào)用?

1. 單個服務的所有 API 是否在同一個包內(nèi)，如 controller。

2. 是否存在不合理的 common、util 模塊。

3. 對于三層包架構遷移到整潔架構的改進可視化。

4. 簡單來說，就是將《系統(tǒng)重構與遷移指南》一書中記載的部分，通過自動化的方式進行識別。

數(shù)據(jù)結構適應度函數(shù)

關于數(shù)據(jù)結構/數(shù)據(jù)模型，已經(jīng)有一些工具可以做類似的事情。對于微服務架構來說，我們所要做的一些判斷是：

• 不合理的耦合。如果一個結構體/類同時被大量的其它類調(diào)用，必然有一定的不合理之處。

• 過大的模型。值得注意的是，在一些大數(shù)據(jù)的場景下，這個反而是正確的

• 過于復雜的嵌套。

• 沒有行為的模型。

然后，針對于一些不同的使用情況，還存在一些不一樣的識別模式。

模型分析

在某些特定的場景之下，團隊會將共用的模型抽取到公共的模塊中，提供給多個微服務使用。這種模式本身可能是有問題的，因為在不同的限界上下文里，它些模型本身不應該是一致的。

相似度分析

考慮到復用和耦合之間的關系，這里不會建議它們共用的。不同服務之間需要一定的 copy/paste，但是需要考慮更好的方式，如采用類似于 proto 這樣的  DSL 生成方式。同時，通過 DDD 的方式進行管理 —— 針對于不同的相似類型，有更好的命名方式。

其它細節(jié)

我們還要做好一些基礎設施，比如對于模塊的處理：

模塊標志

• build.xml

• gradle

• pom.xml

• bazel

• 模塊歸屬權

• 需求關聯(lián)

• 提交信息識別(可輸入式正則關系，配置化)

• 記錄包-需求-服務關系

• 聚類分析

• ……

嗯，這些都不是容易的事。

“自動化微服務治理的優(yōu)點有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！