你好，我是看山。
前面我們聊了微服務的話題，現在微服務已經是業内通識。但凡系統開發、系統設計，必然采用微服務架構，或者宣稱是微服務架構。
但大家有沒有想過，微服務架構不是一開始就有的。如果追溯曆史，微服務最早在 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 架構又自己的一套風格，使用下面一些元件實作普适的方法論：
采用 SOAP 作為遠端調用的協定；
利用 ESB（Enterprise Service Bus，企業服務總線）實作各個子系統之間的通信互動；
使用 BPM（Business Process Management，業務流程管理系統）實作業務流程編排；
使用 SDO（Service Data Object，服務資料對象）來通路和表示資料；
使用 SCA（Service Component Architecture，服務元件架構）來定義服務封裝的形式和服務運作的容器；
……
SOA 架構是各大軟體服務商共同願景下的産物，總結出了一套自上而下的軟體研發方法論，期望能夠解決軟體開發過程中的所有問題。有些類似于八股文，規定好起承轉合，隻要按照要求來，系統就不會出現太多問題。
願景雖好，但是卻忽略了一點，一套大而全的架構體系，不是所有公司都能夠支撐起來的。有時候，大而全不如小而美。但是，我們不能否認 SOA 架構對于面向服務理論的貢獻，在某些場景下的企業内部，SOA 是能夠快速打破資訊孤島的重要手段。
另立門戶的微服務架構
本來是作為 SOA 的一種簡化方案，結果直接發動宣武門之變，逼着 SAO 禅讓。
如開篇所說，微服務架構是在 2005 年提出，在 2014 年崛起。經曆了将近 10 年的時間，之是以沒有得到太多重視，是因為 2014 年之前，微服務隻是在作為 SOA 架構的簡化版出現。直到 2014 年才作為獨立的架構風格，與 SOA 架構劃清界限。
Martin Fowler 與 James Lewis 在合寫的 《Microservices》 對微服務下了定義：“微服務是一種通過多個小型服務組合來建構單個應用的架構風格，這些服務圍繞業務能力而非特定的技術标準來建構。各個服務可以采用不同的程式設計語言，不同的資料存儲技術，運作在不同的程序之中。服務采取輕量級的通信機制和自動化的部署機制實作通信與運維。”
文中還提出了微服務架構的 9 個核心特征：
通過服務來實作獨立自治的元件（Componentization via Services）
圍繞業務能力建構（Organized around Business Capability）
産品化思維（Products not Projects）
強終端弱管道（Smart Endpoint and Dumb Pipe）
分散治理（Decentralized Governance）
資料去中心化（Decentralized Data Management）
基礎設施自動化（Infrastructure Automation）
容錯性設計（Design for Failure）
演進式設計（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的三步工作法
系統設計系列之如何設計一個短鍊服務
系統設計系列之任務隊列
軟體架構-緩存技術
軟體架構-事件驅動架構