來自ThoughtWorks的主管Neal Ford在最近的一次演講中表達了他對企業軟件系統架構轉型的看法，他認為從單體架構轉向基于服務的架構要比轉向微服務架構來得容易。Ford在UberConf 2016大會上做了一次關于基于服務架構的演講，基于服務架構是介于面向服務架構和微服務架構之間的一個中間地帶。這里可以下載演講幻燈片（PDF格式）。
微服務架構有很多優點，不過Ford建議應該把這些優點應用在新開發的項目上。對于已經采用了單體架構的組織來說，轉向微服務架構有很多問題需要解決：分離代碼，分離單體數據庫，采用DevOps方法，監控網絡，管理分布式事務等。但是轉向基于服務架構就不需要做這么多改變，只需要把系統代碼分割成若干個以領域為中心的塊?；诜占軜嬁梢杂蓭资畟€可部署的服務組成，并非像微服務支持者們所主張的成百上千個。這些服務可以有獨立的數據庫，也可以分享單個數據庫。Ford認為這是最為關鍵的不同點，因為他深知在轉向微服務架構過程中，拆分數據庫是最為復雜的部分。而微服務架構的優點只有在一定條件下才能得以體現，比如每個微服務對它們的數據具有獨占所有權，或者有屬于自己的數據庫存儲。
Ford指出，微服務架構也會帶來一些復雜性，比如調用關系鏈以及網絡調用隱含的性能問題。單個微服務不管從業務領域方面還是從性能方面來說都很簡單，易于理解。但如果是一群微服務，就不是這么回事了?；诜占軜嫲凑疹I域把更大的代碼塊組合在一起，減少了網絡調用，這樣會帶來更好的性能。原來可能需要若干個相關微服務的調用變成了單個服務的方法調用。
這種處在中間地帶的架構方式是一種折衷的解決方案。微服務架構通過采用DevOps方法，把代碼拆分成更小的可部署單元，在交付速度和伸縮性方面得到優化?；诜占軜嫳葐误w架構或面向服務架構具有更快的交付速度，它使用微服務架構和面向領域開發擁護者們所推崇的以領域為中心的方式對代碼進行拆分。面向服務架構主張根據層而不是領域來對整體架構進行拆分，導致一個簡單的業務變更會影響到多個層，需要更多的測試才能發布出去。以領域為中心的架構把測試范圍減少到單個要發布的組件上，相比單體架構或面向服務架構交付得更快。要發布的組件越小，測試范圍就越小，這就是微服務優化的目標?；诜占軜嬙谔嵘浖桓端俣确矫嬉沧坑谐尚?。
最后，Ford在多個方面對幾種不同的架構進行了對比。他建議在高度集成的環境里使用面向服務架構，在新開發的項目上使用微服務架構，而基于服務架構主要用于對單體架構系統進行遷移。他認為單體架構不是最終狀態。另一個資深的企業架構師Mark Richards，在UberConf上也帶來了關于基于服務架構的演講，他的演講PPT可以從這里下載（PDF格式）。他們和O'Reilly合作制作了一個深入探討這個主題的視頻。
查看英文原文： Service-Based Architecture As an Alternative to Microservice Architecture
京公網安備 11010502049343號