自動化微服務(wù)治理
關(guān)于『設(shè)計一個微服務(wù)治理的工具』這個想法,我已經(jīng)醞釀很久了。但是,你懂的,又是因為種種原因,我擱置了蠻久了。最近,剛好因為在研究『架構(gòu)適應(yīng)度函數(shù)』,所以,我有了一個新的想法。微服務(wù)架構(gòu)治理,看似和架構(gòu)適應(yīng)度函數(shù)并沒有啥關(guān)系。但是,我設(shè)想的是一個用于『微服務(wù)治理的架構(gòu)適應(yīng)度函數(shù)』。
你可以把它想象為一個用于幫助更好開發(fā)微服務(wù)應(yīng)用的工具。順便一提,因為手頭上并沒有這樣的場景。所以,我先把我的相關(guān)思路記載下來,方便于后續(xù)集成。而且大部分功能已經(jīng)在 Coca 中實現(xiàn),我會將部分的功能再交由 Coca 來實現(xiàn)。如對于,數(shù)據(jù)庫的自動化分析 —— 已經(jīng)有 Tequila 進行了大量的自動化。
微服務(wù)粒度適應(yīng)度函數(shù)
對于微服務(wù)架構(gòu)來說,最令人頭疼的一個問題就是微服務(wù)粒度。從最源頭上,我們應(yīng)該遵循『兩個披薩團隊』這個定律,即:
單個服務(wù)的設(shè)計,所有參與人從設(shè)計、開發(fā)、測試、運維所有人加起來 只需要 2 個披薩就夠了。
但是,事實上從國內(nèi)大中小公司的實踐情況來看,并非如此。往往是一個團隊維護了超過其自身數(shù)量的微服務(wù),即 6 個開發(fā)人員可能維護了 8 個微服務(wù)。大家常犯的一個錯誤是:通過技術(shù)維度而非業(yè)務(wù)維度劃分微服務(wù)。關(guān)于這部分的自動化,我暫時找不到頭緒。但是,我們可以判斷兩個微服務(wù)是否可以合并:即基于 Git 日志的微服務(wù)粒度合理性分析。
- 服務(wù)提交人數(shù)。通過 git log 來查看單個微服務(wù)的提交情況
- 變更頻率。尋找多個模塊之間,是否存在大量同時變更的情況
- 需求關(guān)聯(lián)度。通過識別提交信息規(guī)范,來識別多個微服務(wù)、模塊、類是否存在經(jīng)常同時變更
- 前提:匹配提交規(guī)范。
在這個時候,我們只需要使用和 coca git 類似的解析函數(shù),就能達到類似的效果。
API 的適應(yīng)度函數(shù)
在 Coca 中已經(jīng)內(nèi)置了 API 分析相關(guān)的功能,可以支持識別 Spring 的 API 注解,以及服務(wù)聲明的 API 方式,同時分析調(diào)用關(guān)系等等。所以,我就不需要開發(fā)一個這樣的功能了,只需要稍微完善一下,補充一些分值情況。對于 API 設(shè)計來說,這個工具要做這么幾件事:
- API 命名的規(guī)范。如不一致的命名方式
- 參數(shù)合理性。如過多或者過少、是否不應(yīng)該出現(xiàn)在 URL 中。
- 是否符合 RESTful 規(guī)范。如 URL 中不應(yīng)該出現(xiàn) get 和 post 等字眼,是否所有的 API 都是 post。
- 是否出現(xiàn)跨服務(wù)使用相同的資源前綴。
對于大部分的公司來說,要做到 RESTful 的第一級都相當?shù)睦щy。
數(shù)據(jù)庫表適應(yīng)度函數(shù)
微服務(wù)把服務(wù)間調(diào)用從函數(shù)調(diào)用變成了遠程調(diào)用,這也意味著,我們并不能從 A 服務(wù)直接訪問 B 服務(wù)的數(shù)據(jù)庫,而是通過訪問 B 服務(wù)的接口,借助它去訪問數(shù)據(jù)庫。但是,在某些場景下,A 和 B 是需要共用數(shù)據(jù)庫(比如說,收費的 Oracle 數(shù)據(jù)庫實例),但是我們需要強制性的限制 A 和 B 服務(wù)對于表的訪問。所以,我們需要分析多個服務(wù)之間是否存在對于同一個表的修改,又或者是存在對于多個表的修改。
- 表和服務(wù)關(guān)系維護。掃描 MyBatis 等這一類的工具,生成表和服務(wù)關(guān)系維護
- 實現(xiàn)『數(shù)據(jù)庫表-映射服務(wù)』的快照測試。
簡單來說,我們的工具在這一部分所要做的事情是:每次代碼提交時,進行自動化地掃描,生成一個快照。剛其與存儲的快照進行對比,判斷數(shù)據(jù)庫是否有問題。隨后設(shè)置一個合理的調(diào)優(yōu)公式,也就是這部分的架構(gòu)適應(yīng)度函數(shù)。
分層架構(gòu)適應(yīng)度函數(shù)
在解決了表面的問題之后,我們可以嘗試達到整潔架構(gòu)這一目的。對于分層架構(gòu)來說,我們要做的事情可能會稍微復(fù)雜一下。不過,好在復(fù)雜的調(diào)用關(guān)系識別,已經(jīng)由 Coca 實現(xiàn)了。于是乎,對于我們的分層架構(gòu)適應(yīng)度函數(shù),只需要做到這么一些事情:
微服務(wù)之間是否存在函數(shù)調(diào)用?
- 單個服務(wù)的所有 API 是否在同一個包內(nèi),如 controller。
- 是否存在不合理的 common、util 模塊。
- 對于三層包架構(gòu)遷移到整潔架構(gòu)的改進可視化。
- 簡單來說,就是將《系統(tǒng)重構(gòu)與遷移指南》一書中記載的部分,通過自動化的方式進行識別。
數(shù)據(jù)結(jié)構(gòu)適應(yīng)度函數(shù)
關(guān)于數(shù)據(jù)結(jié)構(gòu)/數(shù)據(jù)模型,已經(jīng)有一些工具可以做類似的事情。對于微服務(wù)架構(gòu)來說,我們所要做的一些判斷是:
- 不合理的耦合。如果一個結(jié)構(gòu)體/類同時被大量的其它類調(diào)用,必然有一定的不合理之處。
- 過大的模型。值得注意的是,在一些大數(shù)據(jù)的場景下,這個反而是正確的
- 過于復(fù)雜的嵌套。
- 沒有行為的模型。
然后,針對于一些不同的使用情況,還存在一些不一樣的識別模式。
模型分析
在某些特定的場景之下,團隊會將共用的模型抽取到公共的模塊中,提供給多個微服務(wù)使用。這種模式本身可能是有問題的,因為在不同的限界上下文里,它些模型本身不應(yīng)該是一致的。
相似度分析
考慮到復(fù)用和耦合之間的關(guān)系,這里不會建議它們共用的。不同服務(wù)之間需要一定的 copy/paste,但是需要考慮更好的方式,如采用類似于 proto 這樣的 DSL 生成方式。同時,通過 DDD 的方式進行管理 —— 針對于不同的相似類型,有更好的命名方式。
其它細節(jié)
我們還要做好一些基礎(chǔ)設(shè)施,比如對于模塊的處理:
模塊標志
- build.xml
- gradle
- pom.xml
- bazel
- 模塊歸屬權(quán)
- 需求關(guān)聯(lián)
- 提交信息識別(可輸入式正則關(guān)系,配置化)
- 記錄包-需求-服務(wù)關(guān)系
- 聚類分析
- ……
嗯,這些都不是容易的事。
結(jié)論
你的微服務(wù)架構(gòu)適應(yīng)度函數(shù)呢?
本文轉(zhuǎn)載自微信公眾號「phodal」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號。