除了微服務，我們還有其他選擇嗎？

你好，我是看山，

前面我們聊了微服務的話題，現在微服務已經是業內通識，但凡系統開發、系統設計，必然采用微服務架構，或者宣稱是微服務架構，

但大家有沒有想過，微服務架構不是一開始就有的，如果追溯歷史，微服務最早在 2005 的云計算博覽會，由 Peter Rodgers 博士提出（那時候稱為微 Web 服務（Micro-Web-Service）），到了 2014 年，Martin Fowler 與 James Lewis 共同提出微服務（Micron-Service）的概念，算是對概念歸納總結，天下一統，這一年也被稱為微服務元年，

那就要問了，在 2014 年之前呢？大家用啥架構？再往前呢？上次互聯網大潮的時候，大家又是用啥？我們今天來聊聊這段歷史，可能你會對現在習以為常的架構，產生一些新的看法，在架構上，可以有更多的選擇，

人人喊打的單體架構

單體架構，人人都說這種架構不好，為什么不好呢？真的不好嗎？可能真相并不是你認為的那樣簡單，

當前來說，如果有人說某個系統是單體架構，一定會有人投來懷疑的眼神，有的會帶著些許不可思議，甚至帶有一絲鄙夷，但是不得不說，單體架構（又稱巨石系統，Monolithic）是整個軟體發展程序中，出現時間最早、應用范圍最廣的一種架構風格，從另一個方面，原來本沒有單體架構這個稱呼，只是后來有了微服務架構，為了區分，才把所有“自包含”的系統稱為單體架構，

上面這個圖就是單體架構，所謂“自包含”，簡單說就是自給自足，所有業務功能靠自己，不依賴其他業務系統，其優點有下面這些：

• 不涉及行程間通信，效率可控；
• 不依賴網路通訊，可以規避不可靠的網路通訊帶來難以預知的故障；
• 開發生態良好，目前的 IDE 對單體架構的支持更好；
• 編碼重構容易，單體架構完全的自控制，只要修改自己即可，不需要上下游支持；
• 端到端測驗簡單，因為沒有上下游依賴，測驗起來更加方便，部署一套環境，就可以實作當前功能的完全測驗；
• 部署簡單，只要打包成 EAR、WAR、JAR 等需要的運行包，扔進服務器就能跑；
• 運維簡單，一個行程運行的服務，無論是日志還是運行態，都能夠很簡單的監控；
• 橫向擴展容易，前面一個負載均衡器做代理，后面可以無限擴展，

從這個角度，只要單機優勢明顯，就不該把單體架構視為地獄，

所謂“成也蕭何敗也蕭何”，統一“集中”成就了單體架構，難以“隔離”也稱為了單體架構最大的弊端，這里將隔離簡單分為開發期隔離和運行期隔離，

單體架構省去了行程間通信、性能損失這些麻煩事，但因為在一個行程中執行，如果內部的某處邏輯例外，可能會造成整個系統的崩潰，最常見的記憶體溢位，可能僅僅是一個不相干的功能查了全表，整個系統都都會宕掉，

運行期沒有辦法隔離，升級的時候也沒有辦法隔離，想要對某些模塊功能升級，只能重啟整個服務，還要擔心會不會有沒有覆寫測驗的點，提前做好預案，掛好停機維護頁，

因此，一個成功的單體架構系統隱含了一個要求，需要一個對系統完全了解的大腦（一個人或一組人），大腦可以總控系統的開發、升級、運行，把控這個系統的每個細節，實作系統中的各個組件、模塊有很高的品質，從而保障系統可在其生命周期內可以穩定的運行，

比如，SAP 和 Hyperion，妥妥的單體架構，作為國際化的軟體公司，為什么不對它們升級改造？是能力不行，還是技術不行？是沒有必要，所以，單體架構也不是一無是處，一切都要在合適的前提下評價，

開疆拓土的 SOA 架構

都說 SOA 架構太重，但他是開創服務化江山的鼻祖，

單體架構對團隊的要求較高，隨著團隊的擴大，必然會有短板或薄弱的環節，或者是組織、或者是個人，這樣就會給系統代理風險，于是，很多前輩就開始思考，一個龐然大物難以維護，那就分為治之，拆分成多個規模小一些的單體架構，彼此之間通過某種方式互動，這種方案被稱為面向服務架構（SOA，Service-Oriented Architecture），

SOA 在 1994 年就被提出，這種架構風格是自然演化來的，只不過當時沒有足夠的條件支持，一直只能處于理論階段，后來隨著 webservice 等技術的提出，才有了技術支撐，到 2006 年，OSOA 成立，共同指定 SOA 架構相關行業標準，這套架構有了理論、技術、規范等一系列約定，從而真正落地，

SOA 架構開疆拓土，開創了很多目前也在使用的概念，比如服務注冊/發現、服務治理、系統隔離、服務編排等，是不是覺得這些概念很熟悉，是的，在微服務架構中，同樣有這些概念的身影，SOA 架構又自己的一套風格，使用下面一些組件實作普適的方法論：

1. 采用 SOAP 作為遠程呼叫的協議；
2. 利用 ESB（Enterprise Service Bus，企業服務總線）實作各個子系統之間的通信互動；
3. 使用 BPM（Business Process Management，業務流程管理系統）實作業務流程編排；
4. 使用 SDO（Service Data Object，服務資料物件）來訪問和表示資料；
5. 使用 SCA（Service Component Architecture，服務組件架構）來定義服務封裝的形式和服務運行的容器；
6. ……

SOA 架構是各大軟體服務商共同愿景下的產物，總結出了一套自上而下的軟體研發方法論，期望能夠解決軟體開發程序中的所有問題，有些類似于八股文，規定好起承轉合，只要按照要求來，系統就不會出現太多問題，

愿景雖好，但是卻忽略了一點，一套大而全的架構體系，不是所有公司都能夠支撐起來的，有時候，大而全不如小而美，但是，我們不能否認 SOA 架構對于面向服務理論的貢獻，在某些場景下的企業內部，SOA 是能夠快速打破資訊孤島的重要手段，

另立門戶的微服務架構

本來是作為 SOA 的一種簡化方案，結果直接發動宣武門之變，逼著 SAO 禪讓，

如開篇所說，微服務架構是在 2005 年提出，在 2014 年崛起，經歷了將近 10 年的時間，之所以沒有得到太多重視，是因為 2014 年之前，微服務只是在作為 SOA 架構的簡化版出現，直到 2014 年才作為獨立的架構風格，與 SOA 架構劃清界限，

Martin Fowler 與 James Lewis 在合寫的 《Microservices》 對微服務下了定義：“微服務是一種通過多個小型服務組合來構建單個應用的架構風格，這些服務圍繞業務能力而非特定的技術標準來構建，各個服務可以采用不同的編程語言，不同的資料存盤技術，運行在不同的行程之中，服務采取輕量級的通信機制和自動化的部署機制實作通信與運維，”

文中還提出了微服務架構的 9 個核心特征：

1. 通過服務來實作獨立自治的組件（Componentization via Services）
2. 圍繞業務能力構建（Organized around Business Capability）
3. 產品化思維（Products not Projects）
4. 強終端弱管道（Smart Endpoint and Dumb Pipe）
5. 分散治理（Decentralized Governance）
6. 資料去中心化（Decentralized Data Management）
7. 基礎設施自動化（Infrastructure Automation）
8. 容錯性設計（Design for Failure）
9. 演進式設計（Evolutionary Design）

由于微服務架構是從 SOA 架構中演化而來，所以很多的表現形式都是一致的，從《Microservices》對微服務架構全面細致闡述之后，也算是將微服務架構與 SOA 架構徹底劃清界限，

在筆者看來，微服務架構與 SOA 架構最大的不同在于對于實作的約束，SOA 架構有一套完整的規約，微服務架構只有建議，追求的是根據實際情況自由變化，簡單的理解就是“想怎么玩就怎么玩”，比如通信協議，SOA 架構明確要求使用 SOAP 通信協議；微服務架構只要求使用輕量級的 RPC 協議，這個選擇就比較寬泛了，常見的就有 HTTP（一般采用 Restful 風格）、gRPC、Dubbo、Thrift、Motan2 等等，

自由意味著可以根據實際情況變化，需要什么引入什么，哪種技術能更好的解決問題就使用哪種技術，在 Java 堆疊中，也出現了 SpringCloud Netflix 和 SpringCloud Alibaba 之類的全家桶組件，作為開發者，只需要在需要的時候添加依賴即可，

從架構師的角度，自由帶來的是約束力的下降，同時也缺少了規約的指導性，我們需要更加了解系統本身，也要更加了解各種技術的優缺點，才能夠在架構設計時，更好的權衡利弊，做好取舍，加油，少年，

我們來看下微服務中的基礎組件：彈性伸縮、服務發現、配置中心、服務網關、負載均衡、服務安全、跟蹤監控、降級熔斷等等，其實從本質來說，這些組件都是業務無關的，實作軟體開發程序中，可以將這些與業務隔離開，也就是所謂的“透明化”，

比如服務發現，可選的方案包括 Nginx、HAProxy、DNS、Eureka、Nacos、KubeDNS，但是我們真的關心嗎？不需要，只需要知道我們要進行網路呼叫，有一個目標即可，至于這個目標是通過哪種方式發現、傳輸、尋址，都與我們要實作的功能無關，那就將服務發現與業務剝離，通過承載服務的運行環境處理，這就是所謂的邊車模型，

微服務之所以應用普及，不僅僅在于其獨特優勢，還與容器化技術的普及有密切關系，微服務與 Docker 虛擬化的高效結合，相當于給了微服務二次加速的動力，資源調度 Kubernetes 的成功，可以認為是直接實作了曲速推進，先進的理念還需要先進的技術實作，

有待成熟的無服務架構

有想要快，還想要簡單，那就不要服務了，隨便寫個函式跑跑得了，

就目前而言，絕大部分的系統開發都是為了解決業務問題，在這個程序中，我們需要選擇一些業務無關的技術組件，有時候，我們受限于研發環境，需要的某種技術組價不存在時，需要采購部署，或者使用替代方案，這就會分散我們的注意力，

于是，很多云服務商提出了無服務架構，無服務架構將系統開發涉及的資源分為兩部分：后端設施（Backend）、函式（Function），對應的就是 BaaS（Backend as a Service，后端即服務）和 FaaS（Function as a Service，函式即服務），

這種不能算是架構風格，只能算是一種系統開發程序中的美好愿景，讓開發者只需要關注業務，需要的基礎設施全部由云服務提供，不需要考慮運行容器、基礎設施的部署、服務器運行能力等，只要將開發好的代碼上傳，就可以擁有一個可運行的系統，

但是愿景雖好，但是與自己掌控部署的區別僅在于對于基礎設施的管控程度上，除非出現重大變革，否則這種架構很難像微服務架構一樣普適，但是對于小程式、小型 web 網站、咨詢平臺等模板化的小型系統，采用這種架構還是有很大優勢的，

文末總結

本文從架構演進的角度分析了單體架構、SOA 架構、微服務架構、無服務架構的適用場景，作為架構師，我們在選擇架構師，不應該一味追求主流，也不能盲從大廠的思路，我們要根據自身情況權衡利弊，找到適合的架構風格，

推薦閱讀

• 什么是微服務？
• 微服務編程范式
• 微服務的基建作業
• 微服務中服務注冊和發現的可行性方案
• 從單體架構到微服務架構
• 如何在微服務團隊中高效使用 Git 管理代碼？
• 關于微服務系統中資料一致性的總結
• 實作DevOps的三步作業法
• 系統設計系列之如何設計一個短鏈服務
• 系統設計系列之任務佇列
• 軟體架構-快取技術
• 軟體架構-事件驅動架構

你好，我是看山，游于碼界，戲享人生，如果文章對您有幫助，請點贊、收藏、關注，我還整理了一些精品學習資料，關注公眾號「看山的小屋」，回復“資料”即可獲得，

個人主頁：https://www.howardliu.cn
個人博文：除了微服務，我們還有其他選擇嗎？
CSDN 主頁：https://kanshan.blog.csdn.net/
CSDN 博文：除了微服務，我們還有其他選擇嗎？