近日，Tareq Abedrabbo在倫敦2017 μCon微服務大會上說，SOA對微服務架構設計的殘余影響仍然存在，包括技術選型和組織方面的問題。最直接的一個例子就是大多數企業仍然區分對待架構師和開發人員，架構師負責出規范，開發人員負責實現。

OpenCredo CTO Abedrabbo在大公司和小公司都工作過，這些公司在向微服務架構遷移的過程中仍然受到SOA的影響。他在演講中對SOA和微服務進行了有趣的對比，不過他也強調，盡管SOA存在問題，但不能把全部責任都推給SOA。

重用性與變更管理。Abedrabbo認為，重用性之所以對SOA來說十分重要，主要是因為SOA缺乏成熟的變更管理工具。服務一旦部署好了，就不太愿意做出變更，因為成本太高。而微服務在變更管理方面具有一定的優勢，因為對微服務做出變更的成本要小得多。

集成與組合。SOA架構強調的是集成，客戶端可以向服務器端發送任何格式的數據，包括XML，服務器端負責解析和處理這些數據。而在微服務架構里則恰好相反，微服務注重組合，服務調用端需要自己知道如何調用其他服務。Abedrabbo對此總結說，集成增加復雜性，而組合降低復雜性。

技術重用與功能重用。SOA注重技術重用，我們總是希望盡可能多地重用一個服務，盡管對服務做出變更有很大阻力。而微服務架構更注重讓小型的服務專注于特定的業務功能上。

靜態與動態。SOA需要處理所有的事情，一個SOAP調用不僅要處理業務邏輯，還要處理安全和事務方面的問題。而微服務更加動態，微服務生態系統的不同部分負責處理不同的問題。

有SOA背景的開發人員在構建微服務時容易使用反模式，比如分布式單體，他們只是對一個邊界進行無機拆解。對一個已有的單體進行解耦時，如果不考慮邊界問題就很容易犯這個錯。在與遺留系統進行集成時太過關注底層的解耦，但沒有考慮到通信保證、冪等性等因素，這也是很常見的問題。這樣的系統只會增加復雜性，體現不出微服務的優勢。

Abedrabbo給出了一些建議用于解決這方面的問題：

采用領域驅動設計。使用微服務實現領域邏輯，避免單純地從技術角度設計可重用的微服務。不要使用規范的數據模型。規范的數據模型只會阻礙微服務系統的演化，所以我們應該使用局部數據視圖。正常化元數據，并將它們從其他數據中分離出來。使用正確的工具。比如，每個微服務都應該有自己的數據庫。多個服務共享一個數據庫是一種反模式，不過如果使用圖數據庫或許會是個好辦法。

明年的微服務大會將于2018年11月5號至6號召開。

查看英文原文：About the SOA Heritage Impact on Microservices