一、系統架構的演變
1、技術架構發展歷史時間軸
①單機垂直拆分：應用間進行了解耦，系統容錯提高了，也解決了獨立應用發布的問題，存在單機計算能力瓶頸，
②集群化負載均衡可有效解決單機情況下并發量不足瓶頸，
③服務改造架構
雖然系統經過了垂直拆分，但是拆分之后發現有重復的功能，比如，用戶注冊、發郵件等等，一旦專案大了，集群部署多了，這些重復的功能無疑會造成資源浪費，所以會把重復功能抽取出來，名字叫"XX服務（Service）"，為了解決服務跟服務如何相互呼叫，需要一個程式之間的通信協議，所以就有了遠程程序呼叫（RPC），作用就是讓服務之間的程式呼叫變得像本地呼叫一樣的簡單，
優點：在垂直架構的基礎上解決了業務重用的問題，
④服務治理
隨著業務的增大，基礎服務越來越多，呼叫網的關系由最初的幾個增加到幾十上百，造成了呼叫鏈路錯綜復雜，需要對服務進行治理，服務治理要求：當服務節點數幾十上百的時候，需要對服務有動態的感知，引入了注冊中心，當服務鏈路呼叫很長的時候如何實作鏈路的監控，單個服務的例外，如何能避免整條鏈路的例外（雪崩），需要考慮熔斷、降級、限流，服務高可用：負載均衡，典型框架比如有：Dubbo，默認采用的是Zookeeper作為注冊中心，
⑤微服務時代
微服務是在2012年提出的概念，微服務的希望的重點是一個服務只負責一 個獨立的功能， 拆分原則，任何一個需求不會因為發布或者維護而影響到不相關的服務， 一切可以做到獨立部署運維， 比如傳統的“用戶中心”服務，對于微服務來說，需要根據業務再次拆分，可 能需要拆分成“買家服務”、“賣家服務”、“商家服務”等， 典型代表：Spring Cloud，相對于傳統分布式架構，SpringCloud使用的是 HTTP作為RPC遠程呼叫，配合上注冊中心Eureka和API網關Zuul，可以做到細 分內部服務的同時又可以對外暴露統一的介面，讓外部對系統內部架構無感， 此外Spring Cloud的config組件還可以把配置統一管理，
Spring Cloud微服務架構存在的不足： Spring Cloud屬于侵入式框架，在專案中需要添加spring cloud maven 依賴，加上spring cloud組件注解，寫配置，打成jar的時候還必須要把非業務的代碼也要融合在一起， 微服務中的服務支持不同語言開發，也需要維護不同語言和非業務代碼 的成本； 業務代碼開發者應該把更多的精力投入到業務熟悉度上，而不應該是非 業務上，Spring Cloud雖然能解決微服務領域的很多問題，但是學習成本還是較大的， 互聯網公司產品的版本升級是非常頻繁的，為了維護各個版本的兼容 性、權限、流量等，因為Spring Cloud是“代碼侵入式的框架”，這時候 版本的升級就注定要讓非業務代碼一起，一旦出現問題，再加上多語言之間的呼叫，工程師會非常痛苦， 我們已經感覺到了，服務拆分的越細，只是感覺上輕量級解耦了，但是維護成本卻越高了，
⑥服務網格新時期 （Service Mesh）
Service Mesh主要解決的問題就希望開發人員對于業務的聚焦，服務發 現、服務注冊、負載均衡等對于開發人員透明，可以更加專注業務邏輯的實 現， 如果將為微服務提供通信服務的這部分邏輯從應用程式行程中抽取出來， 作為一個單獨的行程進行部署，并將其作為服務間的通信代理，可以得到如下 圖所示的架構：
當服務大量部署時，隨著服務部署的Sidecar代理之間的連接形成了一個如下圖所示的網格，該網格成為了微服務的通訊基礎設施層，承載了微服務之間的所有流量，被稱之為Service Mesh（服務網格），
服務網格中有數量眾多的Sidecar代理，如果對每個代理分別進行設定，作業量將非常巨大，為了更方便地對服務網格中的代理進行統一集中控制，在服務網格上增加了控制面組件，
服務網格用來描述組成這些應用程式的微服務網路以及它們之間的互動，隨著服務網格的規模和復雜性不斷的增長，它將會變得越來越難以理解和管理，它的需求包括服務發現、負載均衡、故障恢復、度量和監控等，服務網格通常還有更復雜的運維需求，比如 A/B 測驗、金絲雀發布、速率限制、訪問控制和端到端認證，
Istio
2017年5月24日，Google, IBM 和 Lyft 共同發布 Istio 的第一個公開版本(0.1)，Istio為一款開源的為微服務提供服務間連接、管理以及安全保障的平臺軟體，支持運行在Kubernetes、Mesos等容器管理工具，但不限于Kubernetes、Mesos，其底層依賴于Envoy，Istio提供一種簡單的方法實作服務間的負載均衡、服務間認證、監控等功能，而且無需應用層代碼調整，其控制平面由Pilot、Citadel 和 Galley組成，資料平面由Envoy實作，通常情況下，資料平面代理Envoy以sidecar模式部署，使得所有服務間的網路通信均由Envoy實作，而Istio的控制平面則負責服務間流量管理、安全通信策略等功能，
istio架構
實際上Istio 就是 Service Mesh 架構的一種實作，服務之間的通信（比如這里的 Service A 訪問 Service B）會通過代理（默認是 Envoy）來進行，而且中間的網路協議支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以說覆寫了主流的通信協議，代理這一層，稱之為資料平面，控制平面做了進一步的細分，分成了 Pilot、Citadel 和 Galley，它們的各自功能如下：Pilot：為 Envoy 提供了服務發現，流量管理和智能路由（AB 測驗、金絲雀發布等），以及錯誤處理（超時、重試、熔斷）功能，Citadel：為服務之間提供認證和證書管理，可以讓服務自動升級成 TLS協議，Galley：Galley 是 Istio 的配置驗證、提取、處理和分發組件，它負責將其余的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細節隔離開來，資料平面會和控制平面通信，一方面可以獲取需要的服務之間的資訊，另一方面也可以匯報服務呼叫的 Metrics 資料，
為什么使用 Istio？
通過負載均衡、服務間的身份驗證、監控等方法，Istio 可以輕松地創建一個已經部署了服務的網路，而服務的代碼只需很少更改甚至無需更改，通過在整個環境中部署一個特殊的 sidecar 代理為服務添加 Istio 的支持，而代理會攔截微服務之間的所有網路通信，然后使用其控制平面的功能來配置和管理Istio，這包括：為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡，通過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制，可插拔的策略層和配置 API，支持訪問控制、速率限制和配額，集群內（包括集群的入口和出口）所有流量的自動化度量、日志記錄和追蹤，在具有強大的基于身份驗證和授權的集群中實作安全的服務間通信，Istio 為可擴展性而設計，可以滿足不同的部署需求，
二、架構特點分析
1 單體應用架構（ALL IN ONE）
單體應用架構應用大部分都是一個WAR包或者JAR包，包含前端頁面，后端三層架構（web層，service層，dao層），即將所有的功能模塊打包到一起并放在一個web容器中（如tomcat）運行，
優點： 所有功能集成在一個專案工程中，專案架構簡單，前期開發成本低，要快速增加新功能或部署發布都比較簡單，小型專案的首選，專案初期是一種比較好的方案，
缺點： 對于大型專案不易擴展， 系統性能受限，系統性能擴展只能通過擴展集群節點的方式，成本高，技術堆疊受限，有瓶頸，
2 垂直應用架構
隨著用戶量越來越多，系統的壓力也隨之增長，當并發訪問量提高到一定程度，單一應用通過增加機器提高性能的方式瓶頸越來越明顯，在系統不能支撐當前的用戶量后，需要將專案按照不同的業務來做拆分，拆分為多個子系統，系統之間通過Webservice或者HTTP介面來進行互動，系統不再那么臃腫了，當其中某一個模塊使用的頻率比較高，就對這個模塊進行擴展，即多部署幾個節點，再加一個Nginx用于負載均衡，剛開始還沒什么大問題，當子系統越來越多的時候，每個子系統前面都要加一層負載，對運維人員來說作業量就增加了，因為要維護的也增多了，
優點： 通過垂直拆分，可在一定程度上突破原來單體應用的并發訪問瓶頸，不同的子專案可采用不同的技術，技術堆疊相對豐富，
缺點：①隨著用戶量的增加及系統性能的提升，需要拆分的子專案越來越多，運維成本大幅度提升，
②按照業務拆分的子系統，各個子系統之間存在重合的服務，如用戶注冊、郵件發送等，重復的功能會造成資源浪費，需要進一步抽取公共功能作為獨立服務，
3 分布式SOA架構
3.1 SOA
SOA 全稱為 Service-Oriented Architecture，即面向服務的架構，它可以根據需求通過網路對松散耦合的粗粒度應用組件(服務)進行分布式部署、組合和使用，一個服務通常以獨立的形式存在于作業系統進 程中， 站在功能的角度，把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實作業務的快速再生，目的是把原先固有的業務功能轉變為通用的業務服務，實作業務邏輯的快速復用， 即SOA 有如下幾個特點：分布式、可重用、擴展靈活、松耦合，
當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的回應多變的市場需求
優點： 抽取公共的功能為服務,提高開發效率對不同的服務進行集群化部署解決系統壓力 基于ESB/DUBBO減少系統耦合，
缺點： 抽取服務的粒度較大 服務提供方與呼叫方介面耦合度較高，
3.2 微服務架構
優點： 通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付周期將縮短，運維成 本也將大幅度下降 微服務遵循單一原則，微服務之間采用Restful等輕量協議傳輸，
缺點： 微服務過多，服務治理成本高，不利于系統維護， 分布式系統開發的技術成本高（容錯、分布式事務等），
3.3 SOA與微服務的關系
SOA（ Service Oriented Architecture ）“面向服務的架構”：是一種設計方法，其中包含多個服 務，服務之間通過相互依賴最終提供一系列的功能，一個服務通常以獨立的形式存在與作業系統行程中，各個服務之間 通過網路呼叫，
微服務架構：其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用， 這些小應用之間通過服務完成互動和集成，
4 分布式核心知識
1） 分布式中的遠程呼叫
在微服務架構中，通常存在多個服務之間的遠程呼叫的需求，遠程呼叫通常包含兩個部分：序列化和通信協議，常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的遠程呼叫技術有基于HTTP的RESTful介面以及基于TCP的RPC協議，
（1）RESTful介面 REST，即Representational State Transfer的縮寫，如果一個架構符合REST原則，就稱它為RESTful架 構，
資源（Resources）
所謂"資源"，就是網路上的一個物體，或者說是網路上的一個具體資訊，它可以是一段文本、一張圖 片、一首歌曲、一種服務，總之就是一個具體的實在，你可以用一個URI（統一資源定位符）指向它， 每種資源對應一個特定的URI，要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地 址或獨一無二的識別符，REST的名稱"表現層狀態轉化"中，省略了主語，
"表現層"其實指的是"資 源"（Resources）的"表現層"，
表現層（Representation） "資源"是一種資訊物體，它可以有多種外在表現形式，我們把"資源"具體呈現出來的形式，叫做它的"表 現層"（Representation），比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格 式表現，甚至可以采用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現，URI只代表資源 的物體，不代表它的形式，嚴格地說，有些網址最后的".html"后綴名是不必要的，因為這個后綴名表示 格式，屬于"表現層"范疇，而URI應該只代表"資源"的位置，
狀態轉化（State Transfer） 訪問一個網站，就代表了客戶端和服務器的一個互動程序，
在這個程序中，勢必涉及到資料和狀態的變 化，互聯網通信協議HTTP協議，是一個無狀態協議，這意味著，所有的狀態都保存在服務器端，因 此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）， 客戶端用到的手段，只能是HTTP協議，具體來說，就是HTTP協議里面，四個表示操作方式的動詞： GET、POST、PUT、DELETE，它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源 （也可以用于更新資源），PUT用來更新資源，DELETE用來洗掉資源，
綜合上面的解釋，我們總結一下什么是RESTful架構： 每一個URI代表一種資源； 客戶端和服務器之間，傳遞這種資源的某種表現層； 客戶端通過四個HTTP動詞，對服務器端資源進行操作，實作"表現層狀態轉化"，
（2）RPC協議
RPC（Remote Procedure Call ） 一種行程間通信方式，允許像呼叫本地服務一樣呼叫遠程服務，RPC 框架的主要目標就是讓遠程服務呼叫更簡單、透明，RPC框架負責屏蔽底層的傳輸方式（TCP或者 UDP）、序列化方式（XML/JSON/二進制）和通信細節，開發人員在使用的時候只需要了解誰在什么 位置提供了什么樣的遠程服務介面即可，并不需要關心底層通信細節和呼叫程序，
（3）區別與聯系
1、HTTP相對更規范，更標準，更通用，無論哪種語言都支持http協議，如果你是對外開放API，例如 開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持 的幾個協議都包含RESTful，
2、 RPC 框架作為架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高呼叫方與服務提供方的研發效率，屏蔽跨行程呼叫函式（服務）的各類復雜細節，讓呼叫方感覺就像呼叫本地函式一樣 呼叫遠端函式、讓服務提供方感覺就像實作一個本地函式一樣來實作服務，
2） 分布式中的CAP原理
現如今，對于多數大型互聯網應用，分布式系統（distributed system）正變得越來越重要，分布式系統的最大難點，就是各個節點的狀態如何同步，CAP 定理是這方面的基本定理，也是理解分布式系統的 起點， CAP理論由 Eric Brewer 在ACM研討會上提出，而后CAP被奉為分布式領域的重要理論，分布式系統的 CAP理論，首先把分布式系統中的三個特性進行了如下歸納：
Consistency（一致性）：資料一致更新，所有資料的變化都是同步的，
Availability（可用性）：在集群中一部分節點故障后，集群整體是否還能回應客戶端的讀寫請求
Partition tolerance（磁區容忍性）：某個節點的故障，并不影響整個系統的運行，
通過學習CAP理論，我們得知任何分布式系統只可同時滿足二點，沒法三者兼顧，既然一個分布 式系統無法同時滿足一致性、可用性、磁區容錯性三個特點，所以我們就需要拋棄一樣：
需要明確一點的是，在一個分布式系統當中，磁區容忍性和可用性是最基本的需求，所以在分布是系統中，我們的系統最當關注的就是A（可用性）P（容忍性），通過補償的機制尋求資料的一致性，
感謝閱讀，借鑒了不少大佬資料，如需轉載，請注明出處，謝謝！https://www.cnblogs.com/huyangshu-fs/p/12865955.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/508127.html
標籤：架構設計
上一篇：從系統架構分析安全問題及應對措施
下一篇：設計模式之迭代器模式