Joris Kuipers在一次演講中聲稱，將現有系統遷移到微服務與構建一個新的系統迥然不同。該演講描述了一個正在進行中的將大型單片應用重構成更加分布式的或基于微服務的架構的過程。

Kuipers是Trifork Amsterdam的一名架構師，他所描述的應用是一個醫療保障的電子病歷系統。它于六年前創建，頭兩年是一個帶有少量B2B集成的單片應用。從一開始，它就是使用Trifork開發的開源框架Axon基于命令查詢責任隔離（CQRS）構建的。它運行得很好，但是隨著系統和用戶數量的增長，新需求出現了，包含針對保險開支的需求，保險開支必須是一個單獨的應用，但是仍然需要使用當前應用的數據。因為他們現在不得不轉向共享狀態的多個應用，這是一個巨大的改變。

今天，核心應用仍然相當龐大，周圍圍繞著三個獨立的保險開支應用，在十多個可部署的應用中，一共包含了近40個第三方集成功能。它擁有約65個租戶和12,000個用戶。

許多集成的生命周期比核心應用短得多，所以他們轉向微服務的主要原因是因為需要擴展開發以適應集成的不同的生命周期。擴展開發團隊和加大開發步伐是這一轉變的真實動力。

因為在開始重構的時候他們的應用是基于CQRS和事件的，他們決定使用事件作為集成點，通過消息代理向其它集成應用廣播所有事件。他們將所有存在的B2B集成相關的代碼抽取到單獨的應用中，將它們連接到代理上以獲取所有發送的事件。針對抽取出來的應用，需要與核心應用通信的，他們使用了核心應用中已經存在的CQRS命令。

數據流的典型例子是用戶使用核心應用更新一些數據。該更新進而會引起事件的發布，然后集成應用異步讀取事件，基于這種邏輯，這會發送通知給外部應用。Kuipers把這看作一個軸輻式架構，核心應用是hub，被幾個更小的應用圍繞。他指出這種通過消費者解藕的方式是一種非常適合他們的轉向微服務的方式。

對于Kuipers來講，事件對于拆分一個系統有非常大的幫助，因為它們本質上是異步的，描述已經發生的事情，并且其它系統能夠監聽并響應它。他指出使用事件也會引入一些挑戰，當事件成為集成的支柱時，考慮這些挑戰尤其重要。這些挑戰有：

作為結論，Kuipers指出，他們現在能快速開發和部署與主應用隔離的新集成功能，這也意味著風險的降低，因為核心系統沒有被動過，Kuipers聲稱所有這些讓他們有了重要的競爭優勢。

查看英文原文：Moving a Monolithic Application towards a Microservices Architecture