在討論應(yīng)用程序開發(fā)對現(xiàn)有已開發(fā)應(yīng)用程序的影響和過渡到微服務(wù)時，有五個問題以不同的形式不斷出現(xiàn)。無論組織的大小如何，它們都是相同的，并且在組織向微服務(wù)體系結(jié)構(gòu)發(fā)展的過程中，它們似乎成為稍后策略討論的一部分。

1.“當一個整體被拆分為分布式服務(wù)（微服務(wù)），例如從內(nèi)部調(diào)用到分布式REST API時，如何處理通信中的性能影響？”

該問題的基礎(chǔ)是將現(xiàn)有的單體應(yīng)用程序分解為微服務(wù)時（在可能的情況下）會發(fā)生什么，這方面存在不確定性。這里需要理解的是，拆分服務(wù)的目標是獲得比API調(diào)用速度更高的部署速度。

將微服務(wù)從現(xiàn)有的整體中分離出來，允許在與應(yīng)用程序開發(fā)團隊分離的團隊中隔離服務(wù)開發(fā)。該服務(wù)工程團隊可以按自己的時間間隔進行操作，每周、每天甚至每小時部署變更。

對于未知的網(wǎng)絡(luò)調(diào)用的代價是要權(quán)衡您整體的高度嚴格的部署需求，這種需求可能導(dǎo)致其部署間隔在2-3個月中產(chǎn)生波動。專業(yè)的微服務(wù)團隊意味著對業(yè)務(wù)、競爭和安全需求的更快響應(yīng)，使得更快的交付間隔成為可能。對于網(wǎng)絡(luò)調(diào)用而言，同樣重要的是檢查這種新的分布式體系結(jié)構(gòu)中網(wǎng)絡(luò)調(diào)用的粒度。

2.“我們要如何利用像OpenShift這樣的容器平臺的優(yōu)勢來處理從整體使用中分離出來的、具有狀態(tài)的服務(wù)？”

有狀態(tài)的應(yīng)用程序分為有兩種類型：

構(gòu)建使用內(nèi)存狀態(tài)或數(shù)據(jù)庫狀態(tài)的業(yè)務(wù)應(yīng)用程序。

構(gòu)建特定的數(shù)據(jù)庫引擎，需要對底層磁盤的高性能（甚至是低級別）訪問。

第一種是開發(fā)和部署云本地應(yīng)用程序及其有狀態(tài)組件的主流方式，同時仍然使用基于Kubernetes的OpenShift等容器平臺來生成微服務(wù)。

第二種通常最好留給專門的供應(yīng)商。這是因為這些類型的解決方案可以深入到維護操作系統(tǒng)內(nèi)核本身的擴展。關(guān)注特定領(lǐng)域的業(yè)務(wù)價值并將其交付給客戶更有意義。

3.“如何處理支持分布式服務(wù)的數(shù)據(jù)庫，從而使狀態(tài)成為整個系統(tǒng)中的單個狀態(tài)視圖？”

有很多方法可以處理您的整體狀態(tài)，這通常與其數(shù)據(jù)庫后端有關(guān)。在處理遷移到微服務(wù)時，有多種方法可供使用。

我們建議您考慮將狀態(tài)和數(shù)據(jù)從單體應(yīng)用程序集成到微服務(wù)架構(gòu)中。它涵蓋了將數(shù)據(jù)分發(fā)和集成到微服務(wù)中的關(guān)鍵要素。還提供了對提交、讀取、更新和刪除（CRUD）模式的理解，它包括對分布式系統(tǒng)中涉及的一致性模型的深入了解。

可供您參考的另一種方案是用于智能數(shù)據(jù)庫更改數(shù)據(jù)捕獲的開源工具Debezium。首先能夠遷移到微服務(wù)，而無需進行上述的深入更改。您可以構(gòu)造一些方法來捕獲和更新對狀態(tài)/數(shù)據(jù)的更改，特別是對您的微服務(wù)感興趣的更改，而不需要更改底層數(shù)據(jù)結(jié)構(gòu)。

4.“當生產(chǎn)中有許多與狀態(tài)服務(wù)相關(guān)的數(shù)據(jù)源時，如何將主應(yīng)用程序的狀態(tài)從生產(chǎn)轉(zhuǎn)移到測試環(huán)境？”

在微服務(wù)世界中，每個微服務(wù)的運作方式看起來就像它是組織外部的另一項業(yè)務(wù)的一部分。當您與企業(yè)之間建立業(yè)務(wù)關(guān)系時，微服務(wù)開發(fā)團隊被迫維護一個強大的API并擁有自己的測試套件。我們必須意識到，好的微服務(wù)應(yīng)該是一個黑匣子。

很少有外部業(yè)務(wù)合作伙伴擁有所有數(shù)據(jù)，而僅擁有測試所需的數(shù)據(jù)。同樣的原則也適用于在組織中開發(fā)和維護微服務(wù)的內(nèi)部團隊。在這個新的世界中，測試往往會在生產(chǎn)中發(fā)生更多，這就是為什么我們看到諸如Istio這樣的服務(wù)網(wǎng)格技術(shù)的價值的原因。

對您的解決方案進行進一步的改進，可以使用Debezium通過通用的Kafka主干來復(fù)制數(shù)據(jù)，匿名化數(shù)據(jù)并將其放置到各個獨立的微服務(wù)開發(fā)團隊（組織內(nèi)部的業(yè)務(wù)合作伙伴）所需的位置。

5.“如何使用API網(wǎng)關(guān)或服務(wù)網(wǎng)格將應(yīng)用程序遷移到更現(xiàn)代的工作方式？”

首先，讓我們定位一下API管理是如何使用的，請記住，我們之前討論過微服務(wù)開發(fā)團隊獨立的工作，就像企業(yè)對企業(yè)的合作伙伴一樣。這些開發(fā)團隊有一個API，它是他們特定微服務(wù)的前端。通過使用API管理工具，開發(fā)團隊將其微服務(wù)API發(fā)布到其組織管理的API層中供使用。

與之相對的是服務(wù)網(wǎng)格技術(shù)，它關(guān)注的是微服務(wù)能夠在其部署層中彼此通信?？紤]諸如微服務(wù)發(fā)現(xiàn)，負載平衡，故障恢復(fù)，指標和監(jiān)視之類的事情。服務(wù)網(wǎng)格以一種新穎的方式解決了分布式服務(wù)遇到的微服務(wù)內(nèi)部挑戰(zhàn)。

正如您所看到的，上面提到的每一種技術(shù)都可以發(fā)揮不同的作用，我們認為每一種技術(shù)都是成功的微服務(wù)策略的必要組成部分。

由于這些問題是基于在服務(wù)層現(xiàn)代化過程中與組織的交互，所以在您向交付應(yīng)用程序的現(xiàn)代體系結(jié)構(gòu)過渡時，這些問題既實際又相關(guān)。