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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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