如何將Java接口遷移到微服務？

Question

我正在研究微服務，以及將某些代碼遷移到該體系結構的可能性。 我了解一般概念，但正在努力查看它如何適用於我們的示例。

假如我有一個名為接口RatingEngine ，並呼吁實現RatingEngineImpl ，我的兩個單片應用程序內運行。 原理很簡單RatingEngineImpl可以在另一台機器上運行，並且可以通過（例如）REST API由單片應用程序訪問，並通過http上的json序列化DTO。 我們甚至有一個接口來幫助實現這種解耦。

但是我實際上該如何處理呢？ 據我所知，我需要為臀部整體（即現在的客戶端）創建接口的新實現，該接口接受對接口方法的調用，將其轉換為REST調用，然后通過網絡將其發送到新的“額定發動機服務”。 然后，我還需要實現一個新的http服務器，每個接口方法都有一個終結點，然后反序列化DTO（方法參數）並將調用路由到我們位於服務器內部的原始RatingEngineImpl 。 然后，它將響應序列化，並將其發送回客戶端。

因此，這似乎是很多管道代碼。 這也增加了維護開銷，因為如果您在界面中調整方法，則需要在另外兩個位置進行更改。

我想念什么嗎？ 有什么聰明的方法可以使這種樣板代碼構造自動化？

Answer 1

微服務模式不建議您將必須擁有的每項服務都移至其自己的可部署位置。 僅移動會從其自身的發布周期中受益的自我維持的邏輯。 即，如果您的RatingEngine每周需要進行等級邏輯更新，但是系統的其余部分則非常穩定-它可能會受益於自己的服務。

是的-微服務增加了復雜性，但並沒有真正增加HTTP服務器的樣板代碼。 有很多框架可以解決這個問題。 Vert.x是一個優點。 其他的包括Spring Boot，Apache Camel等。使用Vert.x，完整的微服務設置可能看起來像這樣。

 public class RatingService extends AbstractVerticle implements RatingEngine{
  public void start() {
    vertx.createHttpServer().requestHandler(req -> {
      req.response()
        .putHeader("content-type", "application/json")
        .end(computeCurrentRating().encodePrettily());
    }).listen(8080);
   }

   @Override
   public int getRating(){
        return 4; // or whatever.
   }

   protected JsonObject computeCurrentRating(){
     return new JsonObject().put("rating", getRating());
   }
 }

甚至Java內置框架JAX-RS都可以用很少的代碼行來幫助創建微服務。

微服務的真正工作是在客戶端中添加錯誤處理邏輯。 一些常見的陷阱

• 微服務可能會崩潰如果對RatingService的調用導致連接被拒絕異常-您可以處理嗎？ 您可以估計客戶端的“評分”以防止進一步處理嗎？ 您可以重用舊的響應來評估評分嗎？ ..或至少-您需要將錯誤信號告知支持人員。

• 反應性應用程式？ 您可以等待多長時間？ 對內存方法的調用將在十億分之一秒之內返回，對外部HTTP服務的調用可能需要幾秒鍾或幾分鍾的時間，具體取決於多種因素。 只要該應用程序是“反應性的”並且可以在沒有“評分”的情況下繼續工作-並在可用時向用戶顯示評分-很好。 如果您正在等待致電給評價服務的封鎖電話，則不止幾個毫秒。 -響應時間成為障礙。 在Java中創建響應式應用程序並不像在node.js中那樣方便/常見。 反應性方法可能會觸發整個系統的重做。

• 容忍的客戶單元/集成測試單個項目很容易。 測試復雜的微服務網絡不是。 您能做的最好的事情就是減少客戶打擾。 模式驗證等實際上是不好的事情。 在XML中，請使用單個XPath從響應中獲取所需的數據，而不是更多。 這樣，微服務響應中的更改將不需要更新所有客戶端。 在這方面，JSON比XML容易處理。

Answer 2

不，不幸的是，您不會錯過任何實質性的事情。 微服務架構需要自己付費。 引起您注意的代碼（樣板代碼）是列表中的一項眾所周知的項目。 這是馬丁·福勒（Martin Fowler）的一篇非常好的文章，解釋了該想法的各種優點和缺點。 它包括如下主題：

• 增加了復雜性
• 運營維護成本增加
• 努力保持一致性（同時允許以特殊方式處理特殊情況）

... 還有很多。

Answer 3

有一些框架可以減少這種樣板代碼。 我在當前項目中使用Spring Boot（盡管不適用於微服務）。 如果您已經有基於Spring的項目，那么它實際上可以簡化微服務（或任何其他基於Spring的非微服務應用程序）的開發。 查看一些示例： https : //github.com/spring-projects/spring-boot/tree/master/spring-boot-samples