今天給大家分享一下架構方面的東西。都是一些相對基礎的東西，有錯誤的話請指正。

首先我們來介紹一下什麼是架構。架構一詞來源於建築，代表系統高層次的一些設計角色。比如建築領域的一棟大樓的架構，指的就是大樓有多高、每一層有多高、有多少層、每一層包括多少房間、有幾部電梯、消防通道在哪裡、哪裡是衛生間、哪裡走線路、給排水管道在哪裡等等。都是一些高層次的決策。這些高層次的決策從更高的層面為我們描述了這個系統的梗概、也可以說描繪了系統的藍圖。是對系統高層次的抽象。

架構也被稱為體系結構，有很多的定義。個人比較認可的一個定義：架構=構件+互動

這又引出來什麼是構件。所謂的構件是指具有一定功能，能獨立提供服務或者跟其他構件配合提供服務。構件可大可小，大的可以是獨立的服務、系統、子系統、元件。小的可以是模組、物件或方法。在不同的抽象層次上我們能夠得到不同的構件。這點跟面向物件中的物件很類似。

從上面架構的定義我們能知道，所謂的架構，就是用來定義軟體系統有哪些元件、如何劃分元件、元件的職責是什麼，同時還用來定義構件之間的互動方式。是通過MQ、RPC或者通過http、或者是直接呼叫。

上面說的是架構的定義，還要介紹另一個概念：架構風格，或者說體系結構風格。

說到風格，我們說一個人具有什麼樣的穿衣風格時就可以大概知道搭配方式。比如某人的穿衣風格很騷，我們很容易就想到齊逼短裙、低胸。。。

大家對架構風格不熟悉，但是一定熟悉設計模式。

所謂的設計模式就是前人針對特定問題的一套解決方案，或者說是套路。

架構風格也被稱為架構模式，換句話說是架構方面的套路。也可以說是前人在架構方面總結出來的，用以解決特定問題的方法。下面來看下官方定義：架構風格是用來描述某一特定應用領域軟體系統的組織方式的慣用法，反映了眾多系統所具有的結構和語義特性，指導如何使用構件構造一個完整的系統。

這個定義很好，看了跟不看一樣。。。都不懂。。總而言之就是針對架構方面的一些套路。總結這些模式的目的是什麼呢？是重用！

軟體方面的模式可以分為三個層次：程式碼模式、設計模式、架構模式。

程式碼模式也可以說是編碼時的套路，一些技巧。是最低層次的套路。只能影響某一方法或類中的一些細節。

設計模式解決了一般性的設計問題，影響一個模組內部。是中等層次的重用策略。

架構模式最高層層次的重用策略，實現定義好一些子系統、層，指定他們的責任，並給出把它們組織在一起的法則和指南。

下面我們來介紹一下一些常用的架構風格。包括：管道過濾器風格、面向物件風格、分散式架構、SOA風格、微服務風格等等。

今天我們主要介紹SOA和微服務風格。

SOA 是Service Orientated Architure的縮寫，即面向服務架構。表示每一個功能都是通過一個獨立的服務來提供，服務定義了明確的可呼叫介面，服務之間的編排呼叫完成一個完整的業務。

微服務是指可以部署在單個或多個伺服器上的具有一定業務功能的輕量的服務。

在介紹它們之前，先介紹一下架構風格的演化過程，就很容易理解架構風格了。

首先我們來介紹一下單體應用。針對單體的網路應用，我們一般會把它進行分層，比如這裡我們把它分成ui層、業務邏輯層和DAO層。

分層的好處是什麼呢？

1.通過分離關注點，降低複雜度。

人處理複雜問題的能力是有限的。通過分層可以把相同的職責劃分在一起，分析某一層時可以只關注當前層，而不用管其他層。這也是面向物件的一大優點。

2.各層只能與相鄰層互動，只要介面定義好，內聚性高耦合度小。功能集中。每一層可以很容易替換。

3.不同的層可以分別部署。

分層只是從邏輯檢視方面劃分系統有什麼邏輯元件。我們可以把不同的層放在不同的機器上。架構的物理檢視是用來描述邏輯元件部署到物理機器上的策略。

在單體式應用中，我們不但水平方向上進行分層，還會在垂直方向上對某一層劃分模組。

類似下圖。

下面來介紹下演化到分散式應用。

分散式應用將系統部署到多臺機器、多個位置。也是一種垂直緯度的劃分。

有以下幾種劃分的方法：

1.垂直方向不劃分，整體部署。前面通過負載均衡服務如ngix進行負載均衡處理。

缺點：

a.某些業務需要擴充，只能整體部署。

b.某個模組需要升級時只能整體部署。

2.垂直方向切分成多個應用。每個應用分別部署，共同組成完成的系統。

更進一步，如果我們在垂直方向上切分的很細。就變成了下面的結構。

細粒度切分之後就變成了SOA和微服務。

通過上面的單體式架構風格的演化過程能夠發現，SOA和微服務架構也是分散式架構的一種。但是各有側重。

SOA架構的幾個特點：

1.鬆耦合

呼叫者和服務提供者通過服務註冊定址和呼叫，耦合度小。

2.介面標準化

SOA中的每個服務遵循一定的介面規範。這些協議是跨平臺、跨語言的。

3.粗粒度

SOA中的服務應該儘量的面向業務，與一般定義api提供小粒度的介面的原則不同。

SOA是一種思想、一組規範。它的實現是通過WebService技術來實現的 。

不知道大家有沒有呼叫過Webservice介面。C++呼叫的話有以下幾個步驟：

1.獲得服務的wsdl檔案。

2.使用gsoap工具生成服務介面標頭檔案。

3.使用gsoap工具生成服務介面代理的實現。

4.在程式碼裡直接對第三步生成的實現進行呼叫即可。（要設定服務所在的地址）

在webservice中有以下協議棧

UDDI是Universal Description Discovery and Integration的縮寫。表示通用發現和描述協議。

SOA中包含三種角色：

服務提供者、服務呼叫者和服務註冊中心。

服務提供者提供服務，並將服務註冊到服務註冊中心。

服務呼叫者通過wsdl中的描述呼叫服務提供者介面。分兩次使用，第一次是在開發時通過wsdl獲得服務提供的介面進行開發。第二次是在執行時通過wsdl去服務註冊中心查詢服務位置。

服務註冊中心是連線服務提供者和服務呼叫者的紐帶。可選的角色。可選時服務呼叫者靜態繫結服務並呼叫。

以上是對SOA服務架構的簡單介紹。

下面介紹微服務架構。

微服務架構跟SOA架構是很像的，都是將一個粗粒度的應用拆分成細粒度的應用。拆分的粒度和方法不同。

相同點：

1.微服務是對SOA思想的昇華。

2.兩者都是語言無關、跨平臺的。

不同點：

1.微服務強調按照領域進行拆分應用，拆分後的應用可以敏捷開發和部署。

2.微服務倡導服務的細粒度，切分到不能再分為止。SOA只是在介面方面要求規範化，儘量粗粒度。

3.微服務把應用拆分成單個服務，藉助容器技術，應用從上至下完全獨立，甚至每個應用可以有自己獨立的DB。開發運維一體化。而SOA只要求介面獨立。內部實現可以不獨立。

4.微服務倡導去中心化，將所有的邏輯包括負載均衡、動態路由、服務發現、熔斷等通用邏輯放在服務內部。而SOA

微服務的service mesh

服務網格。用來治理微服務複雜性的技術和工具。與服務一起部署，但是對服務透明，形成一個分散式的代理網路。

以sidecar形式部署在服務的兩側，所有的服務通過sidecar進行通訊。

sidecar的中文意思是旁邊有箱子的摩托車，類似當年鬼子進村的摩托車。sidecar可以實現負載均衡、服務發現、動態路由、熔斷等。是去中心的化的核心。