部分闡述來自 : https://icyfenix.cn/architecture/architect-history/soa.html 半原創, 學習筆記
單體
所有模塊在一個應用裏面, 缺點很明顯. (這裏就不寫了)
SOA (Service-Oriented Architecture 面向服務架構 )
動機
既然單體不好, 那麼就進行拆分 ,如何拆分呢?
爲了對大型的單體系統進行拆分，讓每一個子系統都能獨立地部署、運行、更新，開發者們曾經嘗試過多種方案，這裏列舉以下三種較有代表性的架構模式，具體如下
煙囪式架構（Information Silo Architecture）
使用這種架構的系統也被稱爲孤島式信息系統或者煙囪式信息系統。它指的是一種完全不與其他相關信息系統進行互操作或者協調工作的設計模式。
微內核架構（Microkernel Architecture）
微內核架構也被稱爲插件式架構（Plug-in Architecture）。
事件驅動架構（Event-Driven Architecture）
基於事件的分發又可以分爲兩種不同的模式
Mediator Topology
Broker Topology
SOA 的概念最早由 Gartner 公司在 1994 年提出，當時的 SOA 還不具備發展的條件，直至 2006 年情況纔有所變化，由 IBM、Oracle、SAP 等公司共同成立了 OSOA 聯盟（Open Service Oriented Architecture），用於聯合制定和推進 SOA 相關行業標準。2007 年，在結構化資訊標準促進組織（Organization for the Advancement of Structured Information Standards，OASIS）的倡議與支持下，OSOA 由一個軟件廠商組成的鬆散聯盟，轉變爲一個制定行業標準的國際組織，聯合 OASIS 共同新成立了的Open CSA組織（Open Composite Services Architecture），這便是 SOA 的官方管理機構。
軟件架構來到 SOA 時代，許多概念、思想都已經能在今天微服務中找到對應的身影了，譬如服務之間的鬆散耦合、註冊、發現、治理，隔離、編排，等等。這些在今天微服務中耳熟能詳的名詞概念，大多數也是在分佈式服務剛被提出時就已經可以預見的困難點。SOA 針對這些問題，甚至是針對“軟件開發”這件事情本身，都進行了更加系統性、更加具體的探索。
微服務
What is microservices
Microservices is a software development technique — a variant of the service-oriented architecture （SOA） structural style.
微服務是一種軟件開發技術，是一種 SOA 的變體形式。
—— Wikipedia，Microservices
這個我們就熟悉了, 下圖中右邊 Spring Cloud 使用的應用框架就是微服務框架.
需要注意的是, 從單體到 SOA 再到微服務, 我們並沒有提到虛擬化和容器化技術, 但是假如我們真的要實現微服務, 例如某個應用需要的CPU資源比較多, 另外一個需要的內存比較多, 勢必需要虛擬化和容器化技術來實現.
後微服務架構
簡單來說就是以k8s爲代表的服務編排工具的誕生與運用使得微服務架構的搭建, 編排等更加得遍歷高效.
2017 年是容器生態發展歷史中具有里程碑意義的一年。在這一年，長期作爲 Docker 競爭對手的RKT 容器一派的領導者 CoreOS 宣佈放棄自己的容器管理系統 Fleet，未來將會把所有容器管理的功能移至 Kubernetes 之上去實現。在這一年，容器管理領域的獨角獸 Rancher Labs 宣佈放棄其內置了數年的容器管理系統 Cattle，提出了“All-in-Kubernetes”戰略，把 1.x 版本時就能夠支持多種容器編排系統的管理工具 Rancher，從 2.0 版本開始“反向升級”爲完全綁定於 Kubernetes 這單一種系統。在這一年，Kubernetes 的主要競爭者 Apache Mesos 在 9 月正式宣佈了“Kubernetes on Mesos”集成計劃，由競爭關係轉爲對 Kubernetes 提供支持，使其能夠與 Mesos 的其他一級框架（如HDFS、Spark 和Chronos等）進行集羣資源動態共享、分配與隔離。
在這一年，Kubernetes 的最大競爭者 Docker Swarm 的母公司 Docker，終於在 10 月被迫宣佈 Docker 要同時支持 Swarm 與 Kubernetes 兩套容器管理系統，也即在事實上承認了 Kubernetes 的統治地位。這場已經持續了三、四年時間，以 Docker Swarm、Apache Mesos 與 Kubernetes 爲主要競爭者的“容器編排戰爭”終於有了明確的結果，Kubernetes 登基加冕是容器發展中一個時代的終章，也將是軟件架構發展下一個紀元的開端。
動機
上節提到的分佈式架構中出現的問題，如註冊發現、跟蹤治理、負載均衡、傳輸通信等，其實在 SOA 時代甚至可以說從原始分佈式時代起就已經存在了，只要是分佈式架構的系統，就無法完全避免，但我們不妨換個思路來想一下，這些問題一定要由軟件系統自己來解決嗎？
如果不侷限於採用軟件的方式，這些問題幾乎都有對應的硬件解決方案。譬如，某個系統需要伸縮擴容，通常會購買新的服務器，部署若干副本實例來分擔壓力；如果某個系統需要解決負載均衡問題，通常會佈置負載均衡器，選擇恰當的均衡算法來分流；如果需要解決傳輸安全問題，通常會佈置 TLS 傳輸鏈路，配置好 CA 證書以保證通信不被竊聽篡改；如果需要解決服務發現問題，通常會設置 DNS 服務器，讓服務訪問依賴穩定的記錄名而不是易變的 IP 地址，等等。
經過計算機科學多年的發展，這些問題大多有了專職化的基礎設施去解決，而之所以微服務時代，人們選擇在軟件的代碼層面而不是硬件的基礎設施層面去解決這些分佈式問題，很大程度上是因爲由硬件構成的基礎設施，跟不上由軟件構成的應用服務的靈活性的無奈之舉。軟件可以只使用鍵盤命令就能拆分出不同的服務，只通過拷貝、啓動就能夠伸縮擴容服務，硬件難道就不可以通過敲鍵盤就變出相應的應用服務器、負載均衡器、DNS 服務器、網絡鏈路這些設施嗎？
當虛擬化的基礎設施從單個服務的容器擴展至由多個容器構成的服務集羣、通信網絡和存儲設施時，軟件與硬件的界限便已經模糊。一旦虛擬化的硬件能夠跟上軟件的靈活性，那些與業務無關的技術性問題便有可能從軟件層面剝離，悄無聲息地解決於硬件基礎設施之內，讓軟件得以只專注業務，真正“圍繞業務能力構建”團隊與產品。
是呀, 我們認真一想, 我們微服務中的熔斷, 負載均衡, 假如都由外部的設備去完成, 而容器本身完成業務邏輯就夠了. 那麼後時代的微服務到底解決的是什麼問題呢 ? 繼續往下看
筆者在表 1-1 列出了在同一個分佈式服務的問題在傳統 Spring Cloud 中提供的應用層面的解決方案與在 Kubernetes 中提供的基礎設施層面的解決方案，儘管因爲各自出發點不同，解決問題的方法和效果都有所差異，但這無疑是提供了一條全新的、前途更加廣闊的解題思路。
注意一個是應用層面 , 一個是基礎設施層面 , 曾經記得上操作系統課程的時候講到的內存管理章節, 老師講到的地址轉化過程是用硬件來做的, 無可否認的是硬件來做更加高效, 性能更好 .
上面的圖, 舉一個例子 ,例如在我們應用層面中定時任務是使用Quartz來編寫代碼, 然後作爲一個應用程序(例如一個 jar), 而 k8s 則是使用 k8s 中的 Job 來完成 ,而不是到應用層面去實現
雲原生
從軟件層面獨力應對分佈式架構所帶來的各種問題，發展到應用代碼與基礎設施軟、硬一體，合力應對架構問題的時代，現在常被媒體冠以“雲原生”這個頗爲抽象的名字加以宣傳。雲原生時代與此前微服務時代中追求的目標並沒有本質改變，在服務架構演進的歷史進程中，筆者更願意稱其爲“後微服務時代”。
這是理想的狀態呀 ! 相比於經常講到的雲原生這種高大上的叫法, 我更加同意鳳凰架構作者的叫法---"後微服務時代", 比較雲原生更像是一個最終的理想目標, 當前的"原生"還不夠原生.
服務網格 ( Service Mesh) 和邊車模式 (SideCar)
Kubernetes 成爲容器戰爭勝利者標誌着後微服務時代的開端，但 Kubernetes 仍然沒有能夠完美解決全部的分佈式問題——“不完美”的意思是，僅從功能上看，單純的 Kubernetes 反而不如之前的 Spring Cloud 方案。這是因爲有一些問題處於應用系統與基礎設施的邊緣，使得完全在基礎設施層面中確實很難精細化地處理。舉個例子，微服務 A 調用了微服務 B 的兩個服務，稱爲 B1和 B2，假設 B1表現正常但 B2出現了持續的 500 錯，那在達到一定閾值之後就應該對 B2進行熔斷，以避免產生雪崩效應。如果僅在基礎設施層面來處理，這會遇到一個兩難問題，切斷 A 到 B 的網絡通路則會影響到 B1的正常調用，不切斷的話則持續受 B2的錯誤影響。
圖 1-4 是否要熔斷對服務 B 的訪問？
以上問題在通過 Spring Cloud 這類應用代碼實現的微服務中並不難處理，既然是使用程序代碼來解決問題，只要合乎邏輯，想要實現什麼功能，只受限於開發人員的想象力與技術能力，但基礎設施是針對整個容器來管理的，粒度相對粗曠，只能到容器層面，對單個遠程服務就很難有效管控。類似的情況不僅僅在斷路器上出現，服務的監控、認證、授權、安全、負載均衡等都有可能面臨細化管理的需求，譬如服務調用時的負載均衡，往往需要根據流量特徵，調整負載均衡的層次、算法，等等，而 DNS 儘管能實現一定程度的負載均衡，但通常並不能滿足這些額外的需求。
爲了解決這一類問題，虛擬化的基礎設施很快完成了第二次進化，引入了今天被稱爲“服務網格”（Service Mesh）的“邊車代理模式”（Sidecar Proxy），如圖 1-5 所示。所謂的“邊車”是一種帶垮斗的三輪摩托，我小時候還算常見，現在基本就只在影視劇中才會看到了。這個場景裏指的具體含義是由系統自動在服務容器（通常是指 Kubernetes 的 Pod）中注入一個通信代理服務器，相當於那個挎鬥，以類似網絡安全裏中間人攻擊的方式進行流量劫持，在應用毫無感知的情況下，悄然接管應用所有對外通信。這個代理除了實現正常的服務間通信外（稱爲數據平面通信），還接收來自控制器的指令（稱爲控制平面通信），根據控制平面中的配置，對數據平面通信的內容進行分析處理，以實現熔斷、認證、度量、監控、負載均衡等各種附加功能。這樣便實現了既不需要在應用層面加入額外的處理代碼，也提供了幾乎不亞於程序代碼的精細管理能力。
圖 1-5 邊車代理流量示意
圖來自 Istio 的配置文檔，圖中的 Mixer 在 Istio 1.5 之後已經取消，這裏僅作示意
很難從概念上判定清楚一個與應用系統運行於同一資源容器之內的代理服務到底應該算軟件還是算基礎設施，但它對應用是透明的，不需要改動任何軟件代碼就可以實現服務治理，這便足夠了。服務網格在 2018 年才火起來，今天它仍然是個新潮的概念，仍然未完全成熟，甚至連 Kubernetes 也還算是個新生事物。但筆者相信，未來 Kubernetes 將會成爲服務器端標準的運行環境，如同現在 Linux 系統；服務網格將會成爲微服務之間通信交互的主流模式，把“選擇什麼通信協議”、“怎樣調度流量”、“如何認證授權”之類的技術問題隔離於程序代碼之外，取代今天 Spring Cloud 全家桶中大部分組件的功能，微服務只需要考慮業務本身的邏輯，這纔是最理想的Smart Endpoints解決方案。
爲了解決這一類問題，虛擬化的基礎設施很快完成了第二次進化，引入了今天被稱爲“服務網格”（Service Mesh）的“邊車代理模式”（Sidecar Proxy） 什麼問題呢? 基礎設施不好解決, 得由應用層面來解決, 但是又不想影響應用層面的邏輯("高內聚,低耦合") .
第一代 Service Mesh
第一代Service Mesh由一系列獨立運行的單機代理服務構成.
(整體圖有點像出租屋)
第二代 Service Mesh
第一代Service Mesh由一系列獨立運行的單機代理服務構成，爲了提供統一的上層運維入口，演化出了集中式的控制面板，所有的單機代理組件通過和控制面板交互進行網絡拓撲策略的更新和單機數據的彙報。這就是以Istio爲代表的第二代Service Mesh。
看一下 Istio 的介紹
總結
本片整理了應用架構變遷的過程 : 單體 -> SOA -> 微服務 -> 後微服務 (雲原生) , 理解這些感覺要從動機出發去理解 .明白了各種模式解決了哪些痛點.