一、架構(gòu)基礎(chǔ)

• 架構(gòu)定義：有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)
• 常見軟件架構(gòu)
  • 單機(jī)：所有功能都實(shí)現(xiàn)在一個(gè)進(jìn)程里，進(jìn)程部署在單臺(tái)機(jī)器上，運(yùn)維時(shí)需要停服
    • C10K問題（Concurrent 10,000 Connection）：服務(wù)器如何支持10K個(gè)并發(fā)連接，進(jìn)行高性能網(wǎng)絡(luò)編程。解決方式：采用IO復(fù)用模型epoll方法，在調(diào)用返回時(shí)，只給應(yīng)用提供發(fā)生了狀態(tài)變化的文件句柄，不需要輪詢fd（文件描述符）
    • 單機(jī)架構(gòu)瓶頸：
      • 需要大量進(jìn)程 / 線程作為處理單元，需要占用大量?jī)?nèi)存空間
      • 進(jìn)程 / 線程切換，系統(tǒng)調(diào)度代價(jià)高
    • 解決方案：采用協(xié)程（Routine），一個(gè)線程中，存在多個(gè)協(xié)程。協(xié)程實(shí)現(xiàn)如Go語言的輕量級(jí)線程Goroutine。協(xié)程由程序控制，在用戶態(tài)中執(zhí)行，在線程的基礎(chǔ)上通過分時(shí)復(fù)用的方式運(yùn)行多個(gè)協(xié)程
      • 協(xié)程適用場(chǎng)景：IO密集型任務(wù)，異步IO型任務(wù)（異步IO型任務(wù)包括：主動(dòng)查詢是否有數(shù)據(jù)；被動(dòng)監(jiān)聽是否有數(shù)據(jù)狀態(tài)）
  • 單體：分布式部署，進(jìn)程部署在多臺(tái)機(jī)器上，具備水平擴(kuò)容能力（添加更多服務(wù)器），運(yùn)維不需要停服
    • CAP理論：一個(gè)分布式系統(tǒng)最多只能同時(shí)滿足一致性（Consistency）、可用性（Availability）、分區(qū)容錯(cuò)性（Partition tolerance）三項(xiàng)中的兩項(xiàng)
      • 一致性：所有節(jié)點(diǎn)同時(shí)看到相同的數(shù)據(jù)
      • 可用性：讀寫總是成功的
      • 分區(qū)容錯(cuò)性：盡管任意消息存在丟失或部分系統(tǒng)存在故障，系統(tǒng)繼續(xù)運(yùn)行
  • 垂直應(yīng)用：?jiǎn)误w架構(gòu)基礎(chǔ)上，將進(jìn)程按照應(yīng)用垂直切分開的單體，在一定程度上減少了后端進(jìn)程職責(zé)
  • 面向服務(wù)型架構(gòu)（SOA，Service Oriented Architecture）：將進(jìn)程按照不同的功能單元進(jìn)行抽象，拆分為服務(wù)。SOA為服務(wù)間通信提供標(biāo)準(zhǔn)，采用重量級(jí)協(xié)議，如SOAP及其他WS標(biāo)準(zhǔn)
  • 微服務(wù)（Micro-Service）：SOA的去中心化的演進(jìn)，每個(gè)服務(wù)都有自己的數(shù)據(jù)模型和數(shù)據(jù)庫
    • 注意事項(xiàng)：
      • 數(shù)據(jù)一致性
      • 高可用
      • 治理、容災(zāi)
      • 解耦 vs. 過微
      • 權(quán)衡運(yùn)維成本
• 架構(gòu)演進(jìn)方式：業(yè)務(wù)需求量逐漸增大、系統(tǒng)逐漸復(fù)雜
  • 水平切分：分層 / 模塊化
  • 垂直切分：分布式

二、企業(yè)級(jí)后端架構(gòu)

• 云計(jì)算：通過軟件自動(dòng)化管理，提供計(jì)算資源的服務(wù)網(wǎng)絡(luò)，是現(xiàn)代互聯(lián)網(wǎng)大規(guī)模數(shù)據(jù)分析和存儲(chǔ)的基石
  • 虛擬化技術(shù)：對(duì)計(jì)算機(jī)資源的抽象，實(shí)現(xiàn)資源隔離與共享，資源異構(gòu)性屏蔽，資源池化
    • 硬件層：VMware
    • 操作系統(tǒng)層：Docker
    • 網(wǎng)絡(luò)層：Open V Switch（OVS），基于軟件實(shí)現(xiàn)的開源虛擬交換機(jī)
  • 編排方案
    • VM：OpenStack（一款開源虛擬化平臺(tái)） / VMWare Workstation
      • OpenStack各組件：
        • Horizon，Web前端服務(wù)
        • Nova，計(jì)算服務(wù)
        • Neutron，網(wǎng)絡(luò)服務(wù)
        • Swift，對(duì)象存儲(chǔ)服務(wù)
        • Cinder，塊存儲(chǔ)服務(wù)
        • Keystone，認(rèn)證服務(wù)
        • Glance，鏡像服務(wù)
        • Ceilometer，監(jiān)控服務(wù)
        • Heat，集群服務(wù)
        • Trove，數(shù)據(jù)庫服務(wù)
    • Container：Kubernetes、Docker Swarm
• 云架構(gòu)
  • IaaS：Infrastructure as a Service，基礎(chǔ)設(shè)施即服務(wù)，對(duì)底層硬件資源池的抽象。消費(fèi)者在其中的角色是開發(fā)者或系統(tǒng)管理員。如阿里云的ECS云主機(jī)、Amazon EC2（2006年推出）
  • PaaS：Platform as a Service，平臺(tái)即服務(wù)，基于資源池抽象，云中有完整開發(fā)和部署環(huán)境。消費(fèi)者在其中的角色是開發(fā)者。如Google App Engine、Windows Azure Platform
  • SaaS：Software as a Service，軟件即服務(wù)，基于彈性資源平臺(tái)，一切不需要本地化部署的云服務(wù)軟件產(chǎn)品。消費(fèi)者在其中的角色是終端用戶。如OA、CRM、E-mail服務(wù)
  • FaaS：Function as a Service，函數(shù)即服務(wù)，更輕量級(jí)的函數(shù)服務(wù)。開發(fā)者只需要編寫業(yè)務(wù)代碼，無需關(guān)注服務(wù)器，并且代碼的執(zhí)行由事件觸發(fā)。如LeetCode的Online Judge系統(tǒng)、AWS Lambda
• 云原生（Cloud Native）：構(gòu)建和運(yùn)行可彈性拓展的應(yīng)用
  • 彈性資源
    • 彈性計(jì)算資源：虛擬化容器、快速擴(kuò)縮容
      • 服務(wù)資源調(diào)度
        • 微服務(wù)
        • 大服務(wù)：調(diào)用量多
      • 計(jì)算資源調(diào)度
        • 在線計(jì)算：互聯(lián)網(wǎng)后端服務(wù)，如熱銷榜單
        • 離線計(jì)算：大數(shù)據(jù)分析，MapR / Spark / Flink，如熱銷榜單更新
      • 消息隊(duì)列
        • 在線隊(duì)列：削峰、解耦
        • 離線隊(duì)列：結(jié)合數(shù)據(jù)分析的一整套方案，如ELK
    • 彈性存儲(chǔ)資源：將存儲(chǔ)資源當(dāng)成服務(wù)一樣
      • 經(jīng)典存儲(chǔ)
        • 對(duì)象存儲(chǔ)：視頻、圖片等
        • 大數(shù)據(jù)存儲(chǔ)：應(yīng)用日志、用戶數(shù)據(jù)等
      • 關(guān)系型數(shù)據(jù)庫
      • 元數(shù)據(jù)：
        • 服務(wù)發(fā)現(xiàn)：程序如何通過一個(gè)標(biāo)志來獲取服務(wù)列表，并且這個(gè)服務(wù)列表能夠隨著服務(wù)的狀態(tài)而動(dòng)態(tài)變更
      • NoSQL
        • KV存儲(chǔ)：Redis
        • 文檔存儲(chǔ)：MongoDB
  • 微服務(wù)架構(gòu)：提供業(yè)務(wù)功能單元解耦，提供統(tǒng)一的通信標(biāo)準(zhǔn)。微服務(wù)將單一應(yīng)用程序劃分成一組小的服務(wù)，每個(gè)服務(wù)域進(jìn)行在獨(dú)立的進(jìn)程中。云原生場(chǎng)景下，微服務(wù)不必在業(yè)務(wù)邏輯中實(shí)現(xiàn)符合通信標(biāo)準(zhǔn)的交互邏輯，而是交給框架來做
    • 通信協(xié)議：輕量級(jí)的通信機(jī)制
      • HTTP（RESTful API）
      • RPC（Thrift，gRPC）
    • 微服務(wù)中間件RPC和HTTP：選用時(shí)從性能（RPC提供大量壓縮方案）、服務(wù)治理、協(xié)議可解釋性（HTTP的JSON格式）來考慮
    • 微服務(wù)的部署方式
      • 虛擬機(jī)
      • 容器
        • 解決了應(yīng)用程序運(yùn)行環(huán)境依賴
        • 實(shí)現(xiàn)計(jì)算資源、網(wǎng)絡(luò)、存儲(chǔ)的隔離
        • 提高部署密度和計(jì)算資源的利用率
      • 無服務(wù)器模式（Serverless）：由開發(fā)者實(shí)現(xiàn)的服務(wù)端邏輯運(yùn)行在無狀態(tài)的計(jì)算容器中，由事件觸發(fā)，完全被第三方管理
        • 無需管理基礎(chǔ)設(shè)施
        • 事件驅(qū)動(dòng)
        • 自動(dòng)化構(gòu)建部署
        • 無服務(wù)器計(jì)算 = FaaS + BaaS（Function as a Service + Backend as a Service）
  • DevOps：貫穿整個(gè)軟件開發(fā)周期
    • 敏捷開發(fā)
    • CI / CD（Continuous Integration / Continuous Delivery，持續(xù)集成 / 持續(xù)交付）：實(shí)現(xiàn)應(yīng)用開發(fā)中高度持續(xù)自動(dòng)化和持續(xù)監(jiān)控
  • 服務(wù)網(wǎng)格（Service Mesh）：微服務(wù)之間通信的中間層，一個(gè)高性能的四層網(wǎng)絡(luò)代理，數(shù)據(jù)平面代理與業(yè)務(wù)進(jìn)程采取進(jìn)程間通信的模式，將流量層面的邏輯（包含治理）與業(yè)務(wù)進(jìn)程解耦
    • 業(yè)務(wù)與治理解耦，生命周期易于管理
    • 異構(gòu)系統(tǒng)的治理統(tǒng)一化
    • 具有復(fù)雜治理能力

三、后端架構(gòu)的挑戰(zhàn)

• 基礎(chǔ)設(shè)施層面
  • 存在問題：
    • 離線任務(wù)（主要為CPU密集型，非實(shí)時(shí)性）和在線任務(wù)（主要為IO密集型，潮汐性、實(shí)時(shí)性）的物理資源用量峰期不同。
    • 物理資源有限、帶寬有限，資源利用率受限于部署服務(wù)
  • 解決思路：
    • 離在線資源并池：采用混合資源池，按時(shí)間段劃分離線資源池和在線資源池，提高物理資源利用率
    • 同一個(gè)機(jī)器上的離在線隔離：使用容器對(duì)CPU核心做隔離，使用cgroup統(tǒng)一對(duì)離在線進(jìn)程進(jìn)行分組
    • 利用在線業(yè)務(wù)潮汐性自動(dòng)擴(kuò)縮容，擴(kuò)縮容的依據(jù)指標(biāo)：如CPU使用率的P50數(shù)值（中位數(shù)值）、內(nèi)存利用率等
• 用戶層面
  • 存在問題：
    • 網(wǎng)絡(luò)抖動(dòng)導(dǎo)致運(yùn)維成本提高
    • 異構(gòu)環(huán)境中，不同實(shí)例間的算力差異（CPU型號(hào)差異、網(wǎng)絡(luò)請(qǐng)求差異）
  • 目標(biāo)：打平異構(gòu)環(huán)境算力差異，為自動(dòng)擴(kuò)縮容提供正向輸入
  • 解決思路：如何屏蔽異構(gòu)環(huán)境的算力差異？CPU水位負(fù)載均衡
    • IaaS：提供資源探針（Probe）
    • 服務(wù)網(wǎng)格：動(dòng)態(tài)負(fù)載均衡
• 微服務(wù)層面
  • 存在問題1：微服務(wù)間的高通信成本
  • 目標(biāo)：降低業(yè)務(wù)成本，提高服務(wù)可用性
  • 解決思路：微服務(wù)親和性部署，滿足親和性條件的容器微服務(wù)中間件采用IPC（Inter-Process Communication）通信，不滿足親和性條件的容器通過服務(wù)網(wǎng)格RPC（Remote Procedure Call），從而減少網(wǎng)絡(luò)通信。
    • 將滿足親和性條件（調(diào)用關(guān)系緊密、通信量大的服務(wù)）的容器部署到一臺(tái)宿主機(jī)
    • 微服務(wù)中間件與服務(wù)網(wǎng)格通過共享內(nèi)存通信
    • 服務(wù)網(wǎng)格控制面實(shí)施靈活、動(dòng)態(tài)的流量調(diào)度
  • 存在問題2：流量治理問題
  • 目標(biāo)：提高微服務(wù)調(diào)用容錯(cuò)性、提供容災(zāi)、DevOps提高開發(fā)效率
  • 解決思路：基于微服務(wù)中間件和服務(wù)網(wǎng)格的流量治理
    • 熔斷、重試
    • 單元化
    • 復(fù)雜環(huán)境（功能、預(yù)覽）的流量調(diào)度

四、后端架構(gòu)實(shí)戰(zhàn)

• 如何做架構(gòu)設(shè)計(jì)
  • 需求先行：?jiǎn)栴}定義
  • 業(yè)界調(diào)研：可參考的業(yè)界解決方案
  • 技術(shù)選型：內(nèi)部 / 社區(qū)中的基礎(chǔ)組件
  • 考慮異常情況：考慮某服務(wù)不行了怎么辦
• 基本概念
  • 負(fù)載均衡（Load Balancing）：將工作負(fù)載分布到多個(gè)服務(wù)器來提高服務(wù)的性能和可靠性
  • 服務(wù)發(fā)現(xiàn)（Service Discovery）：容器部署在集群時(shí)，服務(wù)地址（IP和端口）是集群動(dòng)態(tài)分配的。服務(wù)發(fā)現(xiàn)解決了在微服務(wù)中如何精確的定位需要調(diào)用的服務(wù)IP及端口
  • 服務(wù)注冊(cè)（Service Registry）：服務(wù)提供者將自己的服務(wù)地址等信息登記到服務(wù)注冊(cè)中心
  • 注冊(cè)中心：服務(wù)提供者和服務(wù)消費(fèi)者之間的橋梁，提供管理和查詢服務(wù)注冊(cè)信息的API。當(dāng)服務(wù)提供者的實(shí)例發(fā)生變更時(shí)，服務(wù)注冊(cè)表更新最新的狀態(tài)列表，并通知服務(wù)消費(fèi)者
    • 如Zookeeper、Netflix Eureka
  • 宿主機(jī)（Host）：可以是物理機(jī)或虛擬機(jī)
  • 容器（Container）：包含了完整的運(yùn)行時(shí)環(huán)境，基于內(nèi)核的輕量級(jí)虛擬化技術(shù)。容器允許同一物理或虛擬服務(wù)器上毫不沖突地運(yùn)行多項(xiàng)工作負(fù)載
  • 時(shí)序數(shù)據(jù)（Times Series）：與時(shí)間序列相關(guān)的數(shù)據(jù)，如哨兵監(jiān)控的指標(biāo)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)（JVM GC、時(shí)延）
  • 一致性哈希（Consistent Hash）：由于HTTP協(xié)議的無狀態(tài)，服務(wù)器可能選擇存儲(chǔ)會(huì)話日志來記住用戶，從而減少身份驗(yàn)證。因此，在添加或刪除服務(wù)器時(shí)，需要盡可能減少對(duì)其他服務(wù)器的影響
    • 一致性哈希算法的步驟：
      • 將服務(wù)器節(jié)點(diǎn)哈希映射到[0, 2^32-1]的整數(shù)圓環(huán)上
      • 將請(qǐng)求哈希映射到圓環(huán)上
      • 從請(qǐng)求哈希映射的順時(shí)針方向找到其右側(cè)最近的服務(wù)器
    • 作用：增加 / 刪除服務(wù)器時(shí)，最多只有一臺(tái)服務(wù)器會(huì)受到服務(wù)器數(shù)量變化的影響
• 問題：如何設(shè)計(jì)一個(gè)根據(jù)主機(jī)層面的資源信息，實(shí)時(shí)進(jìn)行流量調(diào)度的系統(tǒng)，屏蔽不同宿主機(jī)異構(gòu)環(huán)境的算力差異？
  • 輸入
    • 服務(wù)網(wǎng)格數(shù)據(jù)面：支持帶權(quán)重的負(fù)載均衡策略，服務(wù)發(fā)現(xiàn)，流量調(diào)度
    • 注冊(cè)中心：存儲(chǔ)所有容器的權(quán)重信息
    • 宿主機(jī)：提供容器的資源使用情況、物理資源信息（如CPU型號(hào)）
  • 關(guān)鍵點(diǎn)
    • 緊急回滾能力
    • 大規(guī)模場(chǎng)景中使用：主要考慮系統(tǒng)穩(wěn)定性和計(jì)算瓶頸
    • 極端場(chǎng)景
• 架構(gòu)演進(jìn)方向
  • 方案一：自適應(yīng)靜態(tài)權(quán)重。采集宿主機(jī)物理資源信息，調(diào)權(quán)代理調(diào)整容器注冊(cè)的權(quán)重，缺少緊急回滾能力
  • 方案二：自適應(yīng)動(dòng)態(tài)權(quán)重。動(dòng)態(tài)權(quán)重決策中心從注冊(cè)中心獲取和更新服務(wù)注冊(cè)信息，從配置中心獲取服務(wù)在注冊(cè)中心的名字，通過計(jì)算賦予服務(wù)運(yùn)行時(shí)自適應(yīng)動(dòng)態(tài)權(quán)重，具備緊急回滾能力
  • 方案三：在服務(wù)網(wǎng)格層面上報(bào)RPC指標(biāo)（e.g. 實(shí)例：X:9090，延遲P50:10ms，延遲P99:100ms），防止權(quán)重調(diào)節(jié)過于偏頗。動(dòng)態(tài)權(quán)重中心除了方案二的作用以外，還采集所有服務(wù)容器指標(biāo)，使得極端場(chǎng)景處理成為可能，但時(shí)序數(shù)據(jù)庫壓力較大
  • 方案四：構(gòu)建更復(fù)雜的動(dòng)態(tài)權(quán)重決策中心
    • 微服務(wù)化進(jìn)行拆分（如分為入口層、離線分析層、在線分析層等）
    • 引入消息隊(duì)列削峰、解耦
    • 離在線鏈路切分
    • 梳理強(qiáng)弱依賴

?參考文獻(xiàn)

[1]蘭新宇. 架構(gòu)初探-誰動(dòng)了我的蛋糕.?參考鏈接文章來源地址http://www.zghlxwxcb.cn/news/detail-801420.html

到了這里，關(guān)于第三屆字節(jié)跳動(dòng)青訓(xùn)營(yíng)——架構(gòu)學(xué)習(xí)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！