互聯網之整體架構設計篇

著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。

什麼是架構

架構一直以來都被認爲是高階技術人員的代名詞，但什麼是架構，什麼樣的架構人員才稱得上一個好的架構師，這是很難評判的。可是，要提升架構能力, 只寄但願於代碼層級是遠遠不夠的, 代碼只能幫助咱們解決執行力的問題，但架構的高度更多的是依賴戰略（業務洞察力）以及戰術問題（技術視野）來解決問題。

但架構的高度究竟是在一個什麼層面上呢？架構的高度（既架構戰略和架構技術，也就是架構格局）。

在設計一個架構的時候，一般都須要完整的解決方案去解決實際問題，這些問題包括根據具體業務場景選擇合適的系統架構形態；針對所選擇的架構形態應該如何去設計實現；在這之中若是有困難如何去折中處理；系統的架構若是在線上運行中出現問題該如何解決...等等一系列問題都是在架構設計之初都須要考慮到的問題。這就很須要架構師的架構格局來作支撐。其實在架構的背後，更多的是思考，思考爲何這麼設計，爲何其它方案不優雅不合適等等一系列的爲何。

因此若是要作好一個架構，須要有絕對的理論支撐，實際的項目架構落地實踐。拒絕忽悠，拒絕空理論、空概念。

總結：

架構完整解決方案

• 具體業務場景
• 架構如何選型
• 架構如何設計
• 架構如何折中
• 架構線上問題如何解決

架構背後哲學思考

• 爲何要這樣設計
• 其它方案爲何不優雅

架構的實踐

• 拒絕空理論、空概念
• 實際項目架構落地經驗
• 拒絕忽悠

互聯網發展三階段

在互聯網的發展之路上，正在經歷這3個階段，過去的PC互聯網，如今的移動互聯網，將來的物聯網。

在PC互聯網時代，咱們暫且稱之爲互動1.0時代。在這個階段，之內容在線爲主要核心，但資源之間的互動方式沒有發生太多的變化，仍是一箇中心對多點的廣播模式，好比過去的三大門戶網站（百度，搜狐，網易）。

在PC互聯網後期，移動互聯網時代早期，也就是互動2.0時代。這個階段以互動爲核心，比較有表明性的產品有微博，Twitter。這些產品有了「關注」，由於「關注」產生了互動，產生了網絡效應，說的人越多，看的人也越多，反之亦然。這讓網絡由於「關注」這個機制有了自成長的一個可能性，一個契機。

在移動互聯網後期，暫稱互動3.0時代，由於「關注」把一對一的關係變成了更普遍的多對多關係，造成了真正的交互網絡形態，人和信息都在線了。網越織越密，纔有了用更高效的方式實現原來很難實現的功能，網絡文明再一次進步。

將來物聯網將帶來更廣闊的天空，更難以想象的生活方式。

在這過程當中，互聯網發展的特色也愈來愈明顯，好比：

• 業務功能愈來愈多、愈來愈複雜
• 萬物互聯數據量愈來愈大
• 請求量愈來愈大，更高的用戶體驗要求
• 業務快速迭代，持續交付的能力等

互聯網架構演進之路

更具體的說明參考 單體架構,SOA架構,微服務架構,分佈式架構,集羣架構

單體架構設計與實踐

單一架構通常都是一個普通的java war文件，其內部的java代碼目錄層次結構單一。一個單體架構系統的架構圖大體如圖所示：

單體架構的優勢

• 開發簡單
• 測試簡單
• 部署簡單
• 規模結構簡單

若是單體架構承載不了更高的壓力怎麼辦？單體架構的擴張就是使用nginx作反向代理，基於不一樣負載均衡策略把請求壓力發送到其它單體應用上。單體架構的應用是一個war包部署在Tomcat上，擴展只須要再搞一臺機器使用Tomcat部署war包就能夠了，如圖所示：

單體架構適用場景

• 業務場景簡單、功能不復雜、研發人員較少的項目
• 創業公司初期
• 性能要求極其嚴苛

說完了單體架構的一些優勢，其實單體架構也存在一些缺點：

• 系統耦合度高
• 技術選型單一
• 開發效率愈來愈低下

隨着系統的使用愈來愈久，公司發展成長愈來愈迅速。系統的數據量及訪問量也愈來愈大，針對這種情況若是應對解決呢？

• 針對數據庫，能夠有垂直拆分（分庫）和水平拆分（分表）解決方案
• 針對系統也有垂直拆分（業務維度）和水平拆分（功能維度）的概念

水平分層架構設計與實踐

水平分層架構是把系統向水平方向物理分紅多個進程來運行，每層都有本身的邏輯，實現邏輯解耦。好比：網關層、業務邏輯層、數據訪問層、數據存儲層。下圖是一個水平分層的系統架構圖：

水平分層架構拆分的設計原則

• 單獨的頁面展現服務
• 單獨的網關服務
• 單獨的業務邏輯服務
• 單獨的數據服務
• 根據系統職能單獨劃分服務（相似公司職能部門劃分一個道理）

在根據水平分層架構設計的時候，也會遇到一些技術選項的問題，下圖展現一個網關層技術選項對比維度圖，其它的技術選項對比維度圖也相似如此：

業務邏輯層應該具有的基本功能

• 業務邏輯判斷
• 根據不一樣邏輯判斷實現不一樣功能

數據訪問層應該具有的基本功能

• CRUD 業務增刪改查接口
• ORM 框架
• Sharding 支持分庫分表
• 屏蔽底層存儲庫的差別性（redis/mysql/mongodb)
• 針對以上功能的聚合可使用NewSql替代

水平分層架構雖然解決了一些問題，但其終究仍是同步架構的一種，爲了讓水平架構的處理能力更上一個臺階，能夠將其改形成一個異步架構的水平分層架構，以下圖所示：

經過引入MQ消息中間件實現分層的異步處理，提高系統吞吐量。

水平分層架構的設計事項

設計過多

• 請求路徑變長
• 平均響應延遲變高
• 定位問題變的複雜化
• 運維成本增長

設計過少

• 和單體架構基本相似

設計合理適中

• 同步架構（四層）
  • 網關層
  • 業務邏輯層
  • 數據訪問層
  • 數據存儲層
• 異步架構（五層）
  • 網關層
  • 異步消息隊列層
  • 業務邏輯層
  • 數據訪問層
  • 數據存儲層

即使使用了水平分層架構，也仍是存在缺點的，這樣的分層方式仍是粒度過粗，咱們看看最後水平分層架構的全貌圖

App客戶端先訪問DNS域名解析服務器得到服務器IP；而後經過靜態資源服務器獲取CSS、JS等靜態資源；最後調用服務器動態接口獲取數據展現。

面向服務架構設計與實踐

參考 SOA（Service-Oriented Architecture）面向服務的分佈式架構詳解

微服務架構設計與實踐

參考 微服務架構設計

微服務架構有利也有弊，很差的設計會出現一些問題。由於微服務中業務關注服務局「通訊」，業務迭代須要多方業務支持，致使業務迭代速度慢；基礎設施組件升級困難，影響交付能力和交付速度；多語言通訊之間的問題，業務服務每種語言一套基礎設施、成本大。

下圖是關於上述問題的圖示：

服務網格架構設計與實踐

參考 服務網格 Pattern: Service Mesh

應用程序A部署在一臺機器上，一樣的sidecarA也一樣部署在這樣機器上，sidecarA是基礎設施組件，其實現了服務發現，配置管理，熔斷限流，各類服務治理的功能，這使得應用程序不用再關注服務治理的相關編碼實現，只須要注重業務編碼的實現，關注點拆分（而在微服務架構中是須要同時兼顧考慮的）。打個比方須要修重試策略，修改註冊中心，修改服務調用路由規則，這些在微服務架構中須要修改應用編碼從新部署才能生效，而在服務網格架構中只須要修改技術設施組件，在不影響業務功能代碼的狀況下進行修改發佈升級。

下圖是一個服務網格架構圖：

• 請求：應用程序A將req發送到SidecarA，SidecarA將req發送到SidecarB，SidecarB將req發送到應用程序B
• 響應：應用程序B將resp發送到SidecarB，SidecarB將resp發送到SidecarA，SidecarA將resp發送到應用程序A

官方服務網格架構圖

Service Mesh的優勢

• Service Mesh獨立進程、獨立升級
• 業務團隊專一於業務邏輯自己
• 一套基礎設施支持多語言開發
• 業務團隊和基礎設施團隊物理解耦

Service Mesh的技術框架

框架	開發語言	開發公司
Linkerd	Scala	Buoyant
Conduit	Rust	Buoyant
Envoy	C++	Lyft
Nginmesh	Go	Nginx
Istio	Go/C++	Goole,IBM,Lyft

因爲Istio是集大成這於一身，因此這裏介紹一下Istio，更多詳細的內容能夠參考 Istio官方文檔

Istio

整體架構

• Istio服務網格邏輯上分爲數據面板（執行者）和控制面板（指揮者）
• 數據面板由一組智能代理（Envoy）組成，代理部署sidecar，調解和控制微服務之間全部的網絡通訊
• 控制面板負責管理和配置代理來路由流量，以及在運行時執行策略

數據面板Envoy

• 動態服務發現，負載均衡，TLS鏈接終止，HTTP/2 & gRPC代理
• 熔斷器，健康檢查
• 基於百分比流量灰度，故障注入和豐富指標
• Envoy被部署爲sidecar，和對應服務在同一個kubernetes pod 中

  

Mixer

• 負責在服務網格上執行訪問控制和使用策略，並從Envoy代理和其它服務收集metric信息
• Central component

  

Pilot

• pilot特爲sidecars提供服務發現
• 智能路由的流量管理功能（例如...A/B測試、canary部署等）
• 彈性（超時、重試、斷路器等）
• 鬆耦合容許Istio在多個環境中運行（例如...Kubernetes（Consul/Nomad））同時維護相同的操做員界面進行通訊管理

Citadel

• 提供強大的服務間認證和終端用戶認證，使用內置身份和證書管理
• 它能夠用於升級服務網格中的未加密流量，並未操做人員提供了基於服務標識而不是網絡控制執行策略的能力
• 從0.5版本開始，Istio支持基於角色的訪問控制來控制誰能夠訪問你的服務

流量控制

• 請求路由
  • Request Routing
  • 版本控制V1/V2

  • 

• 服務發現與負載均衡
  • 三種負載均衡模式：輪詢、隨機和帶權重的最少請求
  • 當爲定實例的健康檢查失敗次數超過預約閥值時，它將從負載均衡池中彈出。當經過的健康檢查數超過預約閥值時，該實例將被添加回負載均衡池

  • 

流量控制/處理故障

• Envoy提供了一套開箱即用，選擇加入的故障恢復功能，能夠在應用程序中受益。功能包括：
  • 超時
  • 帶超時預算有限重試以及重試之間的可變抖動
  • 併發鏈接數和上游服務請求數限制
  • 對負載均衡池的每一個成員進行主動（按期）運行健康檢查
  • 細粒度熔斷器（被動健康檢查），適用於負載均衡池中的每一個實例

流量控制/錯誤注入

• 錯誤配合的故障恢復策略（例如：跨服務調用的不兼容/限制性超時）可能致使應用程序中關鍵服務持續不可用，從而致使用戶體驗不佳
• 能夠注入兩種類型的故障：延遲和停止
  • 延遲是計時故障，模擬增長的網絡延遲或過載的上游服務
  • 停止是模擬上游服務的崩潰故障。停止一般以HTTP錯誤代或TCP鏈接失敗的形式表現

千億真實案例設計與實踐

這個章節從真實案例入手講解架構的演進之路，給予同窗們更多的思考。

水平分層架構的案例一

「百度空間」維護的推送系統用於展示好友動態，且服務於百度衆多的產品線（好比百度空間、知道、經驗、旅遊、ting、IM等等），80、90後應該對下面這張圖比較熟悉，這就是那個時候的百度空間。

咱們假設它的系統性能吞吐量爲 100000 QPS, 平均響應延遲： 100ms

若是要設計這樣的系統，它的設計難點會是什麼？

• 消息內容是使用Push仍是Pull方式
• 架構模式選擇同步仍是異步方式呢

下面簡單的看一張整體架構圖：

該架構選取了Pull方式減輕系統壓力與異步方式提高系統處理能力。在這個場景下，消息內容並不須要全部關注者都及時看到最新消息，能夠在用戶上線後再去拉去被關注者新發布的內容，以此來減輕瞬時大數據量發送的問題，微博就相似如此。

若是不少人都在同時發佈內容，服務器處理須要時間，但爲了讓用戶避免過長等待，能夠先把內容保存至消息隊列中，以後將內容緩存在用戶客戶端上告知處理成功。在這中間下游業務服務器會從消息隊列中取出內容繼續處理，若是處理失敗能夠通知客戶端失敗，成功則不做通知用戶的操做。以此來提高用戶體驗與系統處理能力。

水平分層架構的案例二

換個例子，好比58同城中的IM聊天功能，用於知足用戶與商戶溝通，獲取信息，系統如圖所示：

咱們假設該系統包含模塊 30+個，使用了多種開發語言，好比Java/Go。日請求在10億（IM）和30億（非IM），同時在線用戶數突破 100w+。

若是要設計這樣的系統，它的設計難點會是什麼？

• 如何解決百萬千萬同時在線問題
• 架構模式上選用同步仍是異步

下面簡單的看一張整體架構圖：

由於IM設計爲異步過於複雜，考慮IM聊天實時性，採用同步水平分層架構；那如何保持百萬/千萬鏈接數，後面的內容會繼續介紹。

微服務架構的案例三

這是一個買賣雙方交易平臺 在網站早期時候，系統設計方面只有：

• 網關一個
• 業務邏輯層一個（業務代碼聚合在一個工程）
• 數據訪問層多個
• DB/cache多個

下面簡單的看一張整體架構圖：

對於上圖的架構，仍是存在着一些問題，好比：

• 業餘邏輯層的粒度粗，全部業務邏輯耦合在一個物理進程內部
• 後期開發迭代效率低下

那麼對於這些問題能夠如何解決呢？能夠考慮使用垂直拆分（業務維度）來進行進一步的系統結構優化。看案例四

微服務架構的案例四

結合上述微服務架構的案例三，把業務邏輯層按照垂直拆分的概念拆分出來了多個獨立維度的業務邏輯層服務，各自使用不一樣的物理進程，如圖所示：

但對於該架構仍是存在某些問題，好比：

• 公共邏輯層之間關係耦合，每一個業務都會有其它服務相似的代碼

那麼對於這些問題能夠如何解決呢？能夠採用組件化依賴jar包方式，對業務邏輯層再深度優化，抽取公共部分下沉爲獨立服務，提供兼容接口，使用水平拆分（功能維度）策略。

微服務架構 & Service Mesh 的案例五

最後能夠看到拆分出來的公共邏輯層也造成了一個服務進程，下沉在業務邏輯層和數據訪問層之間，這樣既能夠減小業務邏輯層同級之間互相調用循環依賴的問題，也能夠更好的抽離冗餘代碼。最後再結合Service Mesh的架構設計理念，就將成爲一個更強大更高效的軟件系統架構。

下圖是一張簡單的整體架構圖：

擴展知識

1. HTTP/HTTPS
2. TCP
3. Protobuf學習
4. 系統的高可靠性計算

做業思考

針對本文內容，思考本身公司所在的業務線若是優雅實施微服務架構，要求以下：

1. 選取一個具體業務場景，給出微服務的具體拆分方案；
2. 在拆分的基礎上給出合理的系統架構設計；
3. 給出每一個微服務的功能流程圖，並給出具體的接口詳細設計；
4. 給出每一個微服務選用的框架；
5. 給出每一個微服務至少達到4個9的高可用方案；
6. 給出微服務的服務治理方案和快速部署方案；