架構設計基礎-軟件架構設計學習次日（非原創）

時間 2019-11-12

原文原文鏈接

文章大綱

1、架構需求分析
2、架構願景分析
3、架構設計原則
4、必備設計-API網關
5、參考文章前端

1、架構需求分析

1. 需求收集與分析

需求分析的前期工做是願景描述及願景分析, 即願景分析就是需求的前期調研.
從軟件過程來看，需求分析是一個承上啓下的階段–「上承」願景，「下接」設計。需求分析的工做內容包含以下三方面：
1.1 需求捕獲: 理解溝通
需求捕獲: 從各個方面收集需求, 並理解需求.典型的需求捕獲是使用「需求採集卡」：需求描述、需求提出者、需求記錄者、需求類型等。java

1.2 需求分析:作什麼,有哪些問題
需求分析:需求捕得到到的是「原始需求」，而需求分析則對各方面收集到的需求進行分析、整理、概括、論證造成明確的需求。好比, 產品經理說,如今系統不穩定, 須要重構架構保證系統穩定. 這只是一個願景, 咱們須要把這個需求造成一個明確的需求: 可行性99.99%, 要完成這個指標,須要作哪些工做.算法

1.3 系統分析:緣由是什麼, 怎麼作
三者不是獨立無關的階段，而是相互伴隨、交叉進行的。數據庫

2. 需求分類

需求可分類爲三類：
（1）功能需求：更多體現各級直接目標要求,系統具體要作什麼. 有哪些功能點.
（2）質量需求：運行期質量 + 設計質量+用戶質量+系統質量.
（3）約束需求：業務環境因素 + 使用環境因素 + 構建環境因素 + 技術環境因素.編程

ADMEMS矩陣，可做爲需求梳理和需求評審的工具:後端

3. 需求優先排序

架構設計的本質目的是爲了解決業務，架構設計也並非面面俱到，而是識別問題有針對性的解決, 因此要先了解系統最須要解決的是什麼。設計模式

例如系統的複雜度來源於業務邏輯複雜，功能耦合度嚴重，架構師設計TPS達到50000/s的高性能架構沒有意義。api

出現問題主要爲了知足「高可用」「高性能」「可擴展」三個方面，就算老闆拍腦殼要求同時知足三高,也要分優先級。跨域

好比線上運行的系統可能存在的問題:緩存

運行效率低下，升級複雜，容易出錯。

開發效率低下。

小問題不斷，很差定位。

解決方法：

列出主要的複雜度問題

根據業務、技術、團隊等狀況進行排序

優先解決最主要的複雜度問題.

4. 需求分析總參考圖

2、架構願景分析

1. 架構設計流程

2. 願景和目標區別

有時候咱們常常把願景和目標混爲一談,咱們首先須要區別願景和目標:
（1）願景籠統,目標具體，。好比：架構設計作作到高可用，高性能，高可擴展，這些是籠統的概念，沒有具體的指標要求。
（2）目標是即將實現，可以經過努力實現的規劃，願景是一幅前景，可以指引咱們前進的理想。
（3）願景有助於肯定發展目標，發展目標爲實現願景服務。
（4）架構願景：是一種團隊心裏的願望，是腦筋的一幅圖畫，是一種驅動力，願意實踐、追求，來達到某一個境界，能追求到某一種成就。是團隊成員但願架構往哪一個方向發展，包括具體目標、設計原則、質量要求。
（5）架構目標：架構達成某些具體的指標，好比可用性達到99.99%等。
（6）所以我這裏認爲架構的願景分析是包含目標.

3. 架構願景的層次

架構的願景是相對於一個範圍來講的，在一個特定的軟件功能範圍以內，談架構願景纔有實際的意義，例如針對軟件的全局或某個子系統/模塊。在這個特定的範圍中，訂立了架構願景以後，這個範圍內的全部設計原則將不能違背架構願景。這是很是重要的，是架構願景的最大的用處。有了這樣的保證，咱們就能夠保證設計的一致性和有效性。任何一項設計的加入，都可以融入到原先的架構中，使得軟件更加的完善，而不是更加的危險。

咱們根據架構適用範圍的不一樣，把架構願景分爲幾個類別討論：

3.1 軟件系統全局(架構模式)
軟件全局的架構是咱們所最關心的，所以也會花費最多的筆墨。
軟件全局中的架構願景通常很難具體化到代碼級別，其實你會發現，就算是具體化到了代碼級別，也會由於實際中存在的問題，致使代碼沒有太多的價值。所以，爲軟件全局設置的架構願景能夠以原則、或是架構模式的方式體現，並用天然語言或僞代碼描述。例如，能夠爲一個系統規定三層架構做爲其願景，並指出三層的分類原則和具體目標。注意，咱們須要指出分類原則，不然規定三層架構並無太大的意義，由於三層架構隨着實現平臺的不一樣、開發人員的不一樣而有很大的差別，若是不可以規定一個可操做的規範，那麼願景是沒有意義的。

3.2 子系統/模塊級、或是子問題級的架構願景
這時候的架構願景已是比較明確的了，由於已經存在明確的問題域。例如界面的設計、領域模型的設計、持久層的設計等。這裏的願景制定本質上和全局的願景制定差很少，具體的例子咱們也再也不舉了。可是要注意一點，你不可以和全局願景所違背。在操做上，全局願景是設計團隊共同制定出來的，而子/系統模塊級的架構願景就能夠分給設計子團隊來負責，而其審覈則仍是要設計團隊的共同參與。這有兩個好處，一是確保各個子模塊（子問題）間不至於相互衝突或出現空白地帶，二是每一個子設計團隊能夠從別人那裏吸收設計經驗。

在設計時，一樣咱們能夠參考其它的資料，例如相關的模式、或規範（界面設計指南）。在一個有開發經驗的團隊，通常都會有開發技術的積累，這些也是可供參考的重要資料。

咱們在這個層次的願景中主要談一談子模塊（子問題）間的耦合問題。通常來講，各個子模塊間的耦合程度相對較小，例如一個MIS系統中，採購和銷售模塊的耦合度就比較小，而子問題間的耦合程度就比較大，例如權限設計、財務，這些功能將會被每一個模塊使用。那麼，咱們就須要爲子模塊（子問題）制定出合同接口（Contact Interface）。合同的意思就是說這個接口是正式的，不可以隨意的修改，由於這個結構將會被其它的設計團隊使用，若是修改，將會對其它的團隊產生沒法預計的影響。合同接口的制定、修改都須要設計團隊的經過。此外，系統中的一些全局性的子問題最好是提到全局願景中考慮，例如在源自需求模式中提到的信貸賬務的例子中，咱們就把一個利息計算方式的子問題提到了全局願景中。

3.3 代碼級的願景 (代碼設計模式)
嚴格的說這一層次的願景已經不是真正的願景，而是具體設計了。可是咱們爲了保證對架構設計理解的完整性，仍是簡單的討論一下。這一個層次的願景通常能夠使用類圖、接口來表示。但在類圖中，你不須要標記出具體的屬性、操做，你只須要規定出類的職責以及類之間的相互關係就能夠了。該層次願景的審覈須要設計子團隊的經過。

而設計細分到這個粒度上，執行願景設計的開發人員可能就只有一兩個左右。可是比較重要的工做在於問題如何分解和如何歸併。分解主要是從兩個維度來考慮，一個是問題大小維，一個是時間長短維。也就是說，你（設計子團隊負責人）須要把問題按大小和解決時間的長短分解爲更細的子問題，交給不一樣的開發人員。而後再把開發人員提出的解決方法組合起來。

4. 架構目標

4.1 提出指望目標
指望目標也是來源於需求，主要指客戶(多是老闆)或其餘利益相關人提出的項目（產品）願景。願景表達了客戶的目標以及對系統的指望。從願景中咱們能夠得到許多架構分析所須要知道的知識，例如明確客戶最指望達到的目標，以此能夠肯定場景與風險的優先級；瞭解客戶的不一樣目標，能夠由此識別系統客戶的不一樣角色，明確不一樣的利益相關人的態度。
（1）業務響應能力:
下降系統耦合，提高對變化的響應速度。
改善系統架構，更好地支持業務擴展。
創建流程引擎，更靈活地支持業務流程變化。

（2）系統質量:
合理地增長或減小系統間交互及補償，提高系統性能、穩定性。

（3）開發效率:
合理劃分系統，經過系統職責的分離，對開發組的職責進行合理分配，同時創建更完整的公共平臺、基礎框架、基礎類庫，提升開發效率。

（4）運維水平:
完善配置、監控、預警、日誌系統，提高系統運維配置效率及排查問題的速度.

4.2 架構具體目標:衡量系統好壞的標準
具體目標指標以下:
（1）正確性:系統首先須要正確，運行穩定
（2）可用性: 系統必須很是可靠，通常業界更傾向用 N 個9 來量化可用性，最常說的就是相似「4個9(也就是99.99%)」的可用性。
（3）開發效率: 下降開發成本和下降公司在快速鉅變的行業裏面的時間和機會成本。互聯網目前是一個快魚吃慢魚的時代，已經不是大魚吃小魚了。由於小魚在一晚上之間就長大了，把大魚吃掉了。
（4）伸縮性: 用戶激增的時候，系統能夠伸縮來支持用戶的增加或流量高峯。
（5）安全性:安全也是一個商業公司的命脈，攻擊、泄密、破解，前一段鬧的沸沸揚揚的各類用戶信息泄露，足以說明安全的重要性。
（6）擴展性:在增長新模塊或者新的技術時，能比較容易的擴展。
（7）高性能:性能其實也是用戶體驗的一部分，尤爲是用戶量不斷增多，性能是節省成本的重要手段。
（8）可維

4.3 肯定架構質量要求

3、架構設計原則

如何設計出一個好的架構，不像數據公式或者定律，很難一律而就。不少時候是設計者（架構師）的各類設想，各類權衡折中而符合系統需求的智慧輸出。但咱們掌握前人總結的經驗，讓咱們站在巨人的肩膀上高山遠矚。一些好的架構設計原則能夠確保設計決策在必定程度上可以知足需求。

1. 造成架構原則的過程

造成架構原則的過程：

架構原則要SMART

2. 常見的架構設計原則

2.1 N+1設計
開發的系統在發生故障時，至少有一個冗餘的實例
普遍地應用在從數據中心設計到應用服務的部署：
在發生故障時，系統至少要有一個冗餘的實例。
必須確保一個爲本身，一個爲客戶、一個爲失敗

2.2 回滾設計
確保系統能夠向後兼容
若是好久才能修復服務，那麼就要在必定的時間範圍內完成回滾。
災難性的事故，例如損壞客戶數據，每每在部署後好幾天纔出現。
系統最好按照預先的設計，經過發佈或回滾解決問題。

2.3 禁用設計
能夠關閉任何發佈功能
當設計系統，特別是與其餘系統或服務通信的高風險系統時，要確保這些系統可以經過開關來禁用。這將爲修復服務提供額外的時間，同時確保系統不由於錯誤引發詭異需求而宕機。

2.4 監控設計
在設計階段就要考慮監控，而不是在部署完成後，經過監控發現系統的可用性問題。
（1）經過監控使系統自我診斷、自我修復成爲可能。
（2）經過監控肯定系統可預留空間的使用狀況。
（3）經過監控掌握系統之間的交互關係，發現瓶頸
若是監控作的好，不只能發現服務的死活，檢查日誌文件，還能收集系統相關的數據，評估終端用戶的響應時間。若是系統和應用在設計和構建時就考慮好監控，那麼即便不能自我修復，也至少能夠自我診斷。

2.5 多活數據中心設計
數據是否所有集中在一個數據中心？
讀寫是否分離？
是否全部的客戶信息都共享同一個數據結構？
服務調用是否容許延時的存在

2.6 採用成熟的技術
（1）工程師傾向於學習和實施性感時髦的新技術。由於新技術能夠下降成本、減小產品上市時間、提升性能。不幸的是，新技術也每每有較高的故障率。若是把新技術應用在架構的關鍵部分，可能會對可用性產生顯著的影響。
（2）最好爭取在多數人採用該技術的時候進入，先把新技術用在對可用性要求不高的功能上，一旦證實它能夠可靠地處理平常的交易，再將此技術移植到關鍵任務領域中去。

2.7 故障隔離
避免單一業務佔用所有資源。避免業務之間的相互影響 2. 機房隔離避免單點故障。
不共享原則：理想狀況是負載均衡、網絡前端、應用服務器、數據庫，毫不共享任何服務、硬件和軟件。
不跨區原則：不一樣隔離區之間無通信，全部服務調用必須發生在同一個故障隔離區。

2.8 水平擴展
什麼是水平可擴展？平臺的水平擴展是指隨着業務的發展，當須要擴大平臺的服務能力時，沒必要重構軟件系統，經過增長新的設備來知足業務增加的須要。

X軸擴展：服務器拆分。平臺的服務能力能夠在不改變服務的狀況下，經過添加硬件設備來完成擴容。
Y軸擴展：數據庫拆分。平臺的服務能力經過不斷地分解和部署服務來完成擴容。
Z軸擴展：功能拆分。平臺的服務能力能夠按照客戶不斷分解和部署來機器完成容量的擴展。（好比按用戶uid來分表分庫等）

2.9 非核心則購買
工程師每每有本身研發全部系統的衝動。
系統研發要投入資源，系統維護更要長期投入。
影響核心產品到市場的速度。
若是能夠造成差別化的競爭優點，那麼本身作，不然外購。

2.10 使用商品化硬件
在大多數狀況下，便宜的是最好的。
標準、低成本、可互換、易於商品化是商品化硬件的特徵。若是架構設計得好，就能夠經過購買最便宜的服務器輕鬆地實現水平擴展，前提是全部商品化硬件的總成本要低太高端硬件的總成本。

2.11 快速迭代
小構建：小構建的成本較低，能夠確保投資能夠產生價值。
小發布：發佈的失敗率與變動數量相關，小發布失敗率較低。
快試錯：可依市場反饋，快速迭代，加快TTM，優化用戶體驗

2.12 異步設計
同步系統中個別子系統出現故障會對整個系統帶來影響。
同步系統中性能最慢的子系統成爲整個系統性能的瓶頸。
同步系統中擴展性最差的子系統是整個系統擴展的瓶頸。

2.13 無狀態設計
無狀態的系統更利於擴展，更利於作負載均衡。
狀態是系統的吞吐量、易用性、可用性、性能和可擴展性的大敵，要盡最大可能避免。

2.14 前瞻性設計
Now ：目前正使用系統的架構、設計、能力、性能和擴展性。
Now+1: 下一代預研系統的架構、設計、能力、性能和擴展性。
Now+2: 下一代規劃系統的架構、設計、能力、性能和擴展性

2.15 自動化
設計和構建自動化的過程。若是機器能夠作，就不要依賴於人. 人常犯錯誤，更使人沮喪的是，他們每每會以不一樣的方式屢次犯一樣的錯誤。

3. 架構設計的關鍵原則

3.1 一個好的設計擁有如下幾點
（1）解決現有需求和問題
（2）把控現實的進度和風險
（3）預測和規劃將來，不要過分的設計，從迭代中演進和完善。
在開始設計以前，思考一下關鍵的原則，將會幫助你建立一個最小花費、高可用性和擴展性的架構。

3.2 分離關注點
將應用劃分爲在功能上儘量不重複的功能點。主要的參考因素就是最小化交互，高內聚、低耦合。可是，錯誤的分離功能邊界，可能會致使功能之間的高耦合性和複雜性

3.3 職責單一
每個組件或者是模塊應該只有一個職責或者是功能，功能要內聚。

3.4 最小知識原則
一個組件或者是對象不該該知道其餘組件或者對象的內部實現細節。

3.5 不重複原則
你只須要在一個地方描述目的。例如，特殊的功能只能在一個組件中實現，在其餘的組件中不該該有副本。

3.6 最小化預先設計
只設計必須的內容。在一些狀況，你可能須要預先設計一些內容。另一些狀況，尤爲對於敏捷開發，你能夠避免設計過分。若是你的應用需求是不清晰的，最好不要作大量的預先設計。

3.7 低耦合、高內聚
防止變異（使用接口和適配器防止變異）、關注分離。

3.8 關注分離
橫向分層、縱向分區
(1) 將有關事務模塊化，封裝到單獨的構件（例如子系統）中，而且調用其服務；
(2) 使用裝飾者，將所關注的事物（例如安全）置入Decrator對象中，Decorator對象包裹內部類並提取其服務，裝飾者在EJB技術中被稱爲容器，EJB容器圍繞內部對象的業務邏輯，在外部的裝飾者中增添安全檢查；
(3) 使用後便以和麪向方面的技術（Aspect-oriented），好比AspectJ以對開發者透明的方式支持在編譯以後將橫切面關注織入代碼。

3.9 關注點分離之道
好的架構設計必須把變化點錯路有致地封裝到軟件系統的不一樣部分，爲此，必須進行關注點分離。關注點相互分離，也就是說系統中的一部分發生變化，不會影響其餘部分。即便須要改變，也可以清晰地識別出哪些部分須要改變。若是須要擴展架構，影響將會最小化，已經能夠工做的每一個部分均可以繼續工做。

首先，能夠經過職責劃分來分離關注點。面向對象設計的關鍵所在，就是職責的識別和分配。每一個功能的完成，都是經過一系列職責組成的協做鏈條完成的，當不一樣職責被合理分離以後，爲了實現新的功能只需構建新的協做鏈條，而需求變動頁每每只會影響到少數職責的定義和實現。

其次，能夠利用軟件系統各部分的通用性的不一樣進行關注點分離。不一樣的通用程度意味着變化的可能性不一樣，將通用性不一樣的部分分離有利於通用部分的重用，頁便於對專用部分進行修改。

另外，還能夠先考慮大粒度的子系統，而暫時忽略子系統是如何經過更小粒度的模塊和類組成的。在實際中，軟件架構師經常將系統劃分爲一組子系統，併爲子系統定義明確的藉口，其中的細節將隨其後的開發工做慢慢展開。

根據職責分離關注點、根據通用性分離關注點、根據不一樣粒度級別分離關注點是三種不一樣維度的思惟方式。

3.10 非侵入性原則
那麼什麼是架構的侵入性呢？所謂侵入性就是指的這個架構設計出來的部件對系統的影響範圍，好比框架的侵入性就很高，由於在一個工程中引入一個框架，你的整個設計都必須圍繞這個框架來進行，一旦使用了，框架的可替代性幾乎爲0，這樣子就是搞侵入性。組件的侵入性就比較低,好比ibaties，他能夠在任何java框架下使用，甚至能夠和其餘ORM組件共存，你僅僅須要引入，配置，而後就能夠使用了，你也能夠用其餘的ORM替換他，因此......這個體驗應該是很愉快的。
因此話說回來講到若是咱們在設計一個通用架構的時候就應該注意到這個一個很是重要的地方，除非咱們只是本身拿來用用，不然咱們不該該假設咱們的設計的用戶已經具有怎麼怎麼樣的環境或者是須要作什麼特殊的設計纔可以使用。
這裏打個比方，假如說咱們在設計一個通用權限管理什麼什麼的時候咱們就要想好，這是一個組件，仍是框架，仍是一個現成系統（複用經過改改代碼實現，其實我的以爲這種設計很低級，雖然有的這樣子的東西功能確實豐富）。肯定了目標以後咱們纔好開始下一步，好比肯定是一個框架的話可能發揮要自由一些，由於不須要高度的內聚，不過可能由於框架要設計的方方面面太多了，因此總是以爲我的的力量不足以搞這種東西出來。若是是組件的話就須要高度的內聚來實現非侵入式，好比引入DLL的時候還須要讓全部頁面繼承自某個基類頁就不算是一個good idear。

4、必備設計-API網關

1. 網關概念介紹

API Gateway（API GW / API 網關），顧名思義，是企業 IT 在系統邊界上提供給外部訪問內部接口服務的統一入口。在微服務概念的流行以前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統，它也是解決訪問認證、報文轉換、訪問統計等問題的。

百度百科：API網關是一個服務器，是系統的惟一入口。從面向對象設計的角度看，它與外觀模式相似。API網關封裝了系統內部架構，爲每一個客戶端提供一個定製的API。它可能還具備其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。

API網關方式的核心要點是，全部的客戶端和消費端都經過統一的網關接入微服務，在網關層處理全部的非業務功能。一般，網關也是提供REST/HTTP的訪問API。服務端經過API-GW註冊和管理服務。

2. API網關分析設計

2.1 宏觀分析要素
安全性問題
企業在把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對公司業務的影響，特別是涉及交易方面的服務，更是要全面考慮安全性。爲確保安全，須要考慮在通信鏈路的創建、通信數據的加密、數據的完整性、不可抵賴性等方面。

性能問題
做爲企業API的入口，全部的請求都會通過API網關進行轉發，可想而知，對API網關的訪問壓力是巨大的，有的網站甚至達到每分鐘上千萬的訪問量。特別是在一些互聯網企業，海量的移動終端每時每刻都須要與後端的服務進行交互，若是不能保證網關的高性能，企業在網關層須要投入大量的設備和成本。曾在一家互聯網公司發生過，因爲網關性能問題，網關的機器數量，須要與後臺服務器的數量保持同步增加。這種狀況顯然是企業服務忍受的。

高可用問題
API網關做爲邏輯上的單點，一旦發生問題，將形成企業服務的不可用，對企業來講可能形成的致命的影響。計算短期的不可用，也會給企業帶來直接的經濟損失。因此，如何保證API網關的7*24小時的穩定運行，網關的自動伸縮、API的熱更新等問題，都是企業級的網關須要考慮的。

擴展性問題
前面說到，企業網關提供了一個腳手架，一些非功能性的問題，例如日誌、安全、負載均衡策略、鑑權等。這些插件會隨着企業業務規模等的變化進行不斷的強化與調整。這就須要網關層提供這樣一種機制，使得能夠靈活地進行這些調整和變化，而不用頻繁對網關層進行改動，確保網關層的穩定性。

API高效運維的問題
API在上線、發佈過程當中，都須要涉及到網關層的配合，例如，須要網關層知道API發佈的地址，API的接口形式、報文格式，也須要網關層對後臺API進行封裝。在API調整後，須要做出相應的修改。因此，API網關設計時，須要明確網關層與服務層的職責切分與協做模式，使得API的管理、發佈更加高效。

API全生命週期的管理
API服務的全生命週期，包括服務的開發、測試、上線發佈；服務使用的申請、開通；服務分類分級別的管理、服務使用狀況的監控、計費等等。
一個企業可能會暴露成百上千個API，平常也會常常進行API的發佈、升級、改造、下架等操做。對不一樣的服務，不一樣的訪問者，須要提供不一樣的服務訪問策略。有的商業API公司，還須要對API的使用進行付費。因此，與API網關配套的，須要一套完善的自助系統，提供給服務的提供者、管理者、使用者，來對服務的發佈、使用、和運營。

2.2 具體狀況分析
功能需求
一、API 生命週期管理功能：
覆蓋 API 的定義、測試、發佈的整個生命週期管理，便捷的平常管理、版本管理，支持熱升級和快速回滾

二、開發和使用支持功能：
提供頁面調試工具，自動生成 API 文檔和 SDK，大大下降人力成本。

三、安全防禦功能：
API 請求到達網關須要通過嚴格的身份認證、權限認證，才能到達後端服務。支持算法簽名，支持 SSL 加密。

四、流量控制功能：
可控制單位時間內 API 容許被調用次數。用來保護企業的後端服務，實現業務分級和用戶分級。支持對 API 流控，您能夠根據 API 的重要程度來配置不一樣流控，從而保障重要業務的穩定運行；支持用戶、應用和例外流控，您能夠根據用戶的重要性來配置不一樣流控，從而能夠保證大用戶的權益；流控粒度：分鐘、小時、天。

五、請求管理功能：
可根據配置進行參數類型、參數值（範圍、枚舉、正則、Json Schema）的校驗，減小後端對非法請求、無效請求的資源消耗和處理成本。能夠在 API 網關定義參數映射規則，網關經過映射規則將後端服務經過映射翻譯成任何形式，以知足不一樣用戶的不一樣需求，從而避免功能重複開發。

六、監控告警功能：
提供實時、可視化的 API 監控，包括：調用量、調用方式、響應時間、錯誤率，讓您可以清楚的瞭解 API 的運行情況和用戶的行爲習慣。
支持自定義報警規則，來針對異常狀況進行報警，下降故障處理時間。
提供可訂閱的數據分析報表和智能分析。

高性能設計
傳統的基於線程的併發模型（Thread-based concurrency），爲每個請求分配一個線程或進程。這種模型編程簡單，能夠將處理一個完整請求的代碼編寫在一個代碼路徑中。這種模型的弊端是，隨着線程(進程)數的上升，操做系統在這些線程(進程)之間的頻繁切換，將急劇下降系統的性能。

高可用設計
一、無狀態設計原則。
網關層爲保證高能夠，易於伸縮，快速啓動，須要設計成無狀態的。用戶的狀態數據咱們一般使用session對象來封裝，網關層要設計成無狀態的，也就是說，不能由網關來負責session的維護。那由誰來維護session相關的信息呢？咱們是採用cookie+session服務器的方式;
a) 用戶在登陸頁完成登陸操做後，服務器會生成一個登陸session信息，保存起來，設置個失效時間，並設置到用戶的cookie裏
b) 用戶後續的每次請求裏會帶着這個cookie信息，服務端會對這個cookie信息進行校驗，經過了就認爲是合法用戶，執行請求操做

二、優雅下線原則
當須要撤掉一臺網關服務的時候，不是直接結束網關進程，而是先關閉監聽套接字，可是繼續爲當前鏈接的客戶提供服務，全部客戶端的服務完成後，在把進程關閉。

三、Slow start特性
當網關監聽到有一臺新的服務註冊上來時，考慮到有些服務啓動後，剛開始會有許多初始化的工做，此時服務對請求的響應速度是比較慢的。若是一開始就給這臺服務分配太多的壓力，有可能致使服務瞬間被壓垮。爲了不這種狀況，網關層須要考慮支持Slow Start特性。即，通過一段時間，逐漸把壓力增長到預設的值。

四、擴展性設計
咱們知道，網關對請求的處理，能夠分爲三個階段：接受請求、路由並轉發請求、接受服務的返回數據並返回給請求者，除此以外，還有一種狀況是處理錯誤。因此咱們也能夠在這四個地方添加擴展點。
（1）接受到請求後
（2）定位到一個服務，並準備轉發以前
（3）接受到服務的返回數據，返回給客戶端以前
（4）當服務調用失敗後
攔截器的處理順序，能夠分爲兩大類：一類爲網關平臺自帶的攔截器，例如安全校驗、日誌記錄等；一類爲網關層邏輯開發的，例如格式轉換等。通常來講，網關先執行網關平臺自帶的攔截器，再執行爲了業務邏輯編寫的攔截器。固然，網關也須要提供一種機制，能夠較容易地調整攔截器的執行順序。最簡單的一種方法，就是給每一個攔截器定義一個優先級，網關按優先級順序依次調用各攔截器。
對網關層來講，它接收和處理的數據都是Request對象，網關層在接收到請求後，把請求封裝爲Request對象，爲了讓後續的filter可以得到這個對象，能夠考慮把Request對象保存在線程變量中。
有些攔截器，例如一些調試日誌的攔截器，一般狀況下都是關閉的，只有在出現問題的時候才須要打開。爲了保證網關的高可用，網關層必須具有在線啓用或關閉攔截器的能力。通常，網關須要提供restful接口方式，來關閉和啓用一個攔截器。相似這樣的命令：PUT /apigateway/v1/filters/filterName?enable=value

五、API管理與動態發佈設計
對服務管理來講，分爲前端服務管理與後端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API，後端服務指的是服務層提供的業務服務API。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外，還須要配置前端服務與後端服務的映射關係。
網關層API調用服務層API，有多種方式。例如，能夠由按照服務層API的服務契約，生成一段客戶端代碼，發佈給網關層使用。這種方式的弊端是，網關層代碼依賴於服務層代碼，服務層頻繁修改和調整接口時，致使網關層的代碼很難維護。
能夠經過配置先後端服務映射的方式，解耦網關層對服務層的依賴。當服務層的API（例如服務名、參數名等）發生變化時，只需調整映射關係，無需對網關層的代碼進行調整。網關層按照映射，自動裝配服務層API所須要的數據格式。這樣，網關層團隊與服務層團隊能夠相互不受干擾地開發各自的服務。

3. 優缺點介紹

3.1 優勢
（1）解耦做用：它封裝了應用的內部結構，客戶端直接和網關通訊，而沒必要調用特定的服務。
（2）提供給每種客戶端特定優化的API。
（3）減小請求環路、簡化客戶端邏輯。好比說，API Gateway使得客戶端用一次請求就能夠從多個service處獲取數據。

3.2 缺點
（1）必須被開發、部署和管理成一個高度可用的組件，也有成爲開發瓶頸的危險。
（2）爲了暴露出每一個微服務的，開發者必須更新API網關。
（3）Partner OpenAPI：
轉發路由做用：對外提供的接口服務，通常直接把請求轉發到合適的service，可是此時的API GW須要增長配額、限流、令牌等一系列安全管控功能。對外提供隔離做用：請求路由，安全認證，負載均衡，限流、監控、權限控制等等。

4. 業界經常使用的API網關方案

一般狀況下， API 網關要作不少工做，它做爲一個系統的後端總入口，承載着全部服務的組合路由轉換等工做，除此以外，咱們通常也會把安全，限流，緩存，日誌，監控，重試，熔斷等放到 API 網關來作，那麼能夠試想在高併發的狀況下，這裏可能會出現一個性能瓶頸。
另外，若是沒有開源項目的支撐前提下，本身來作這樣一套東西，是很是大的一個工做量，並且還要作 API 網關自己的高可用等，若是一旦作很差，有可能最早掛掉的不是你的其餘服務，而就是這個API網關。
4.1 基於OpenResty 的 Nginx
性能和高可用性
Nginx性能極高，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機制、極少的進程間切換以及許多優化設計，都使得Nginx天生善於處理高併發壓力下的互聯網請求。Nginx的穩定性也在各大網站獲得驗證。官方提供的經常使用模塊都很是穩定，每一個worker進程相對獨立，master進程在1個worker進程出錯時能夠快速「拉起」新的worker子進程提供服務。支持熱部署，能夠不停機更新配置文件、更新日誌文件、更新服務器程序版本。

擴展性上
Nginx的設計極具擴展性，它徹底是由多個不一樣功能、不一樣層次、不一樣類型且耦合度極低的模塊組成。所以，當對某一個模塊修復Bug或進行升級時，能夠專一於模塊自身，無須在乎其餘

易用性上
Nginx使用最自由的BSD許可協議，容許用戶在本身的項目中直接使用或修改Nginx源碼，有大量的插件能夠利用。可是，Nginx模塊須要用C開發，並且必須符合一系列複雜的規則。雖然經過第三方模塊，能夠支持Nginx與Perl、Lua等腳本語言集成工做，但對使用者的要求仍是很高。

4.2 Spring Cloud Zuul

基本功能
驗證與安全保障: 識別面向各種資源的驗證要求並拒絕那些與要求不符的請求。
審查與監控: 在邊緣位置追蹤有意義數據及統計結果，從而爲咱們帶來準確的生產狀態結論。
動態路由: 以動態方式根據須要將請求路由至不一樣後端集羣處。
壓力測試: 逐漸增長指向集羣的負載流量，從而計算性能水平。
負載分配: 爲每一種負載類型分配對應容量，並棄用超出限定值的請求。
靜態響應處理: 在邊緣位置直接創建部分響應，從而避免其流入內部集羣。
Netflix公司還利用Zuul的功能經過金絲雀版本實現精確路由與壓力測試。
雖然提供的功能還算豐富，但都比較弱，很難知足高要求的場景。

性能和高可用性
Zuul處理每一個請求的方式是針對每一個請求是用一個線程來處理。一般狀況下，爲了提升性能，全部請求會被放處處理隊列中，從線程池中選取空閒線程來處理該請求。2016年末，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul 2將HTTP請求的處理方式從同步變成了異步，以提高其處理性能。除了Netflix公司，目前Zuul在企業中用的還比較少，性能和穩定性方面還有待進一步觀察。

擴展性上
從Zuul的架構圖上能夠看出，Zuul更像是一個過濾器框架，其自身的路由、日誌、反向代理、ddos預防等功能都是經過過濾器實現的。提供了PRE、ROUTING、POST和ERROR四個擴展點，能夠很容易的添加自定義的過濾器。

易用性上
Zuul的搭建很是簡便，使用和配置也很簡單。Zuul的開源社區比較活躍，一直在更新狀態，但版本不算太穩定，在使用的過程當中，還有一些坑要踩。例如重定向問題、異常處理問題，尚未解決的很好，須要本身重寫一些filter。

4.3 Mashape Kong

Kong的一個很是誘人的地方就是提供了大量的插件來擴展應用，經過設置不一樣的插件能夠爲服務提供各類加強的功能。Kong默認插件插件包括：

身份認證
Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication認證明現。

安全
ACL（訪問控制）、CORS（跨域資源共享）、動態SSL、IP限制、爬蟲檢測實現。

流量控制
請求限流（基於請求計數限流）、上游響應限流（根據upstream響應計數限流）、請求大小限制。限流支持本地、Redis和集羣限流模式。

分析監控
Galileo（記錄請求和響應數據，實現API分析）、Datadog（記錄API Metric如請求次數、請求大小、響應狀態和延遲，可視化API Metric）、Runscope（記錄請求和響應數據，實現API性能測試和監控）。

請求轉換、響應轉換
Kong自己也是基於Nginx的，因此在性能和穩定性上都沒有問題。Kong做爲一款商業軟件，在Nginx上作了很擴展工做，並且還有不少付費的商業插件。Kong自己也有付費的企業版，其中包括技術支持、使用培訓服務以及 API 分析插件。
從對上面三種方案的比較中能夠看到，Spring Cloud Zuul很是適合創業初期的團隊，快速搭建一個「基本可用」的API網關。Nginx適合有較強研發團隊，自主開發企業本身的API網關。Kong適合於沒有自身研發團隊，但須要擁有企業級API網關能力的公司。