做爲Java開發,你真的瞭解系統嗎?技術架構又要解決什麼問題?

本文已收錄GitHub,更有互聯網大廠面試真題,面試攻略,高效學習資料等前端

對於開發人員來講,咱們天天都在用技術。但你要知道,咱們寫的代碼,其實只是系統的一小部分,咱們瞭解的技術,也只是系統用到的一小部分。要深刻掌握技術架構,咱們就須要瞭解總體的系統。git

面對一個複雜的系統,我想你可能常常會有如下困擾:github

  1. 不清楚系統總體的處理過程,當系統出問題時,不知道如何有針對性地去排查問題。
  2. 系統設計時,常常忽視非業務性功能的需求,也不清楚如何實現這些目標,常常是付出慘痛的教訓後,纔去亡羊補牢。

不知你是否還記得,在以前的文章中,我已經說過,技術架構是從物理層面定義系統,並保障系統的穩定運行。那麼今天,我會先分析下系統在物理上由哪些部分組成,讓你能夠從全局的角度看一個系統;而後再和你一塊兒討論,技術架構會面臨哪些軟硬件的挑戰,以及它都有哪些目標,讓你可以深刻地瞭解技術架構。面試

系統的物理模型

對於大部分開發人員來講,咱們主要的工做是寫業務相關的代碼,保證業務邏輯正確、業務數據準確,而後,這些業務代碼通過打包部署後,變成實際可運行的應用。但咱們寫的代碼只是系統的冰山一角,爲了保證應用能正常運行,咱們須要從端到端系統的角度進行分析。數據庫

咱們先看下一個系統的具體組成,這裏我爲你提供了一個簡化的系統物理模型,你能夠了解一個系統大體包含哪些部分。緩存

做爲Java開發,你真的瞭解系統嗎?技術架構又要解決什麼問題?

從用戶請求的處理過程來看,系統主要包括五大部分。安全

首先是接入系統,它負責接收用戶的請求,而後把用戶的請求分發到某個 Web 服務器進行處理,接入系統主要包括 DNS 域名解析、負載均衡、Web 服務器這些組件。性能優化

接下來,Web 服務器會把請求交給應用系統進行處理。通常來講,咱們是基於某個開發框架來開發應用的,好比 Java 應用通常是基於 Spring MVC 框架。服務器

這個時候,開發框架首先會介入請求的處理,好比對 HTTP 協議進行解析,而後根據請求的 URL 和業務參數,轉給咱們寫的業務方法。接下來,咱們的應用代碼,會調用開發語言提供的庫和各類第三方的庫,好比 JDK 和 Log4j,一塊兒完成業務邏輯處理。在這裏,咱們會把開發框架、應用代碼,還有這些庫打包在一塊兒,組成一個應用系統,做爲獨立的進程在Web 服務器中進行部署和運行。網絡

到這裏,整個系統要作的事情就完了嗎?

尚未呢,在咱們的應用系統底下,還有基礎平臺,它由好幾個部分組成:首先是各個語言的運行時,好比說 JVM;而後是容器或虛擬機;下面還有操做系統;最底下就是硬件和網絡。

接入系統、應用系統、基礎平臺就構成一個最簡單的系統

在大多數狀況下,應用系統還要藉助大量外部的中間件來實現功能和落地數據,好比數據庫、緩存、消息隊列,以及 RPC 通信框架等等。這裏,我統稱它們爲核心組件,它們也是系統不可缺乏的一部分。

除此以外,還有大量周邊的支撐系統在支持應用的正常運行,包括日誌系統、配置系統,還有大量的運維繫統,它們提供監控、安全、資源調度等功能,它們和核心組件的區別是,這些系統通常不參與實際的用戶請求處理,但它們在背後默默保障系統的正常運行。

到這裏,你能夠發現,一個端到端的系統是很是複雜的,它包含了大量的軟硬件。爲了保障咱們的應用代碼可以正常運行,咱們就須要保證這裏的每一個組件不出問題,不然一旦組件出問題,極可能就致使系統總體的不可用。

技術架構的挑戰

應用代碼怎麼組織(好比模塊劃分和服務分層),那主要是業務架構的事,這部分在前面咱們已經討論過不少了;而技術架構的職責,首先是負責系統全部組件的技術選型,而後確保這些組件能夠正常運行

咱們知道,系統是由硬件和軟件組成的。接下來,咱們就分別從軟硬件的角度來看下,技術架構都會面臨什麼挑戰,咱們須要如何應對。

硬件的問題

硬件是一個系統最基礎的部分,負責真正幹活的,但它有兩方面的問題。

首先是硬件的處理能力有限。對於服務器來講,它的 CPU 頻率、內存容量、磁盤速度等等都是有限的。雖說按照摩爾定律,隨着製造工藝的發展,大概每隔 18 個月,硬件的性能

能夠提高一倍,但仍是趕不上快速增加的系統處理能力的要求,特別是目前許多互聯網平臺,面向的都是海量的 C 端用戶,對系統處理能力的要求能夠說是沒有上限的。

從技術架構的角度,提高硬件的處理能力通常有兩種方式。

Scale Up

也就是垂直擴展,簡單地說就是經過升級硬件來提高處理能力。CPU 不夠快,升級內核數量;內存不夠多,升級容量;網絡帶寬不夠,升級帶寬。因此說,Scale Up 其實是提高硬件的質量。

Scale Out

也就是水平擴展,經過增長機器數量來提高處理能力。一臺機器不夠,就增長到 2 臺、4臺,以及更多,經過大量廉價設備的疊加,加強系統總體的處理能力。因此說,Scale Out是提高硬件的數量。

垂直擴展是最簡單的方式,對系統來講,它看到的是一個性能更強的組件,技術架構上不須要任何改造。若是碰到性能有問題,垂直擴展是咱們的首選,但它有物理上的瓶頸或成本的問題。受硬件的物理限制,機器的性能是有天花板的;或者有時候,硬件超出了主流的配置,它的成本會指數級增加,致使咱們沒法承受。

水平擴展經過硬件數量彌補性能問題,理論上能夠應對全部服務器處理能力不足的狀況,並實現系統處理能力和硬件成本保持一個線性增加的關係。

但水平擴展對於系統來講,它看到的是多個組件,好比說多臺 Web 服務器。如何有效地管理大量的機器,一方面,使得性能上能夠實現相似 1+1=2 的效果;另外一方面,要讓系統各個部分可以有效地銜接起來,穩定地運行,這不是一件容易的事情。咱們須要經過很複雜的技術架構設計來保障,好比說,經過額外的負載均衡,來支持多臺 Web 服務器並行工做。

硬件的第二個問題是,硬件不是 100% 的可靠,它自己也會出問題

好比說,服務器斷電了,網絡電纜被挖斷了,甚至是各類天然災害致使機房總體不可用。尤爲是一個大型系統,服務器規模很大,網絡很複雜,一旦某個節點出問題,整個系統均可能受影響,因此,機器數量變多,也放大了系統出故障的機率,致使系統總體的可用性變差。咱們在作技術架構設計時,就要充分考慮各類硬件故障的可能性,作好應對方案。好比說針對天然災害,系統作異地多機房部署。

軟件的問題

接下來咱們說下軟件的問題,這裏的軟件,主要說的是各類中間件和系統級軟件,它們配合咱們的應用代碼一塊兒工做。

軟件是硬件的延伸,它主要是解決硬件的各類問題,軟件經過進一步封裝,給系統帶來了兩大好處。

  • 首先是彌補了硬件的缺陷。好比 Redis 集羣,經過數據分片,解決了單臺服務器內存和帶寬的瓶頸問題,實現服務器處理能力的水平擴展;經過數據多副本和故障節點轉移,解決了單臺服務器故障致使的可用性問題。
  • 其次,封裝讓咱們能夠更高效地訪問系統資源。好比說,數據庫是對文件系統的增強,使數據的存取更高效;緩存是對數據庫的增強,使熱點數據的訪問更高效。

但軟件在填硬件的各類坑的同時,也給系統挖了新的坑。舉個例子,Redis 集羣的多節點,它解決了單節點處理能力問題,但同時也帶來了新的問題,好比節點內部的網絡有問題(即網絡分區現象),集羣的可用性就有問題;Redis 數據的多副本,它解決了單臺服務器故障帶來的可用性問題,但同時也帶來了數據的一致性問題。

咱們知道,分佈式系統有個典型的 CAP 理論,C 表明系統內部的數據一致性,A 代碼系統的可用性,P 表明節點之間的網絡是否容許出問題,咱們在這三者裏面只能選擇兩個。對於一個分佈式系統來講,網絡出問題是比較常見的,因此咱們首先要選擇 P,這意味着咱們在剩下的 C 和 A 之間只能選擇一個。

CAP 理論只是針對一個小的數據型的分佈式系統,若是放大到整個業務系統,C 和 A 的選擇就更加複雜了

好比有時候,咱們直接對訂單進行寫庫,這是傾向於保證數據一致性 C,但若是數據庫故障或者流量太大,寫入不成功,致使當前的業務功能失敗,也就是系統的可用性 A 產生了問題。若是咱們不直接落庫,先發訂單數據到消息系統,再由消費者接收消息進行落庫,這樣

即便單量很大或數據庫有問題,最終訂單仍是能夠落地,不影響當前的下單功能,保證了系統的可用性,但可能不一樣地方(好比緩存和數據庫)的訂單數據就有一致性的問題。

魚和熊掌不能兼得,系統沒法同時知足 CAP 的要求,咱們就須要結合具體的業務場景,識別最突出的挑戰,而後選擇合適的組件,並以合理的方式去使用它們,最終保障系統的穩定運行,不產生大的業務問題。

技術架構的目標

好,如今你已經瞭解了系統的複雜性和軟硬件的問題,那技術架構就要選擇和組合各類軟硬件,再結合咱們開發的應用代碼,來解決系統非功能性需求。

什麼是系統非功能性需求呢?這是相對於業務需求來講的,所謂的業務需求就是保證業務邏輯正確,數據準確。好比一個訂單,咱們要保證訂單各項數據是準確的,訂單優惠和金額計算邏輯是正確的。而一個訂單頁面打開須要多少時間,頁面是否是每次都能打開,這些就和具體的業務邏輯沒有關係,屬於系統非功能性需求的範疇。產品經理在通常狀況下,也不會明確提這些需求。非功能性需求,有時候咱們也稱之爲系統級功能,和業務功能相區分。

那對於一個系統來講,技術架構都要解決哪些非功能性需求呢

系統的高可用

可用性的衡量標準是,系統正常工做的時間除以整體時間,一般用幾個 9 來表示,好比 3個 9 表示系統在 99.9% 的時間內可用,4 個 9 表示 99.99% 的時間內可用,這裏的正常工做表示系統能夠在相對合理的時間內返回預計的結果。

致使系統可用性出問題,通常是兩種狀況:

  • 一種是軟硬件自己有故障,好比機器斷電,網絡不通。這要求咱們要麼及時解決當前節點的故障問題,要麼作故障轉移,讓備份系統快速頂上。
  • 還有一種是高併發引發的系統處理能力的不足,軟硬件系統常常在處理能力不足時,直接癱瘓掉,好比 CPU 100% 的時候,整個系統徹底不工做。這要求咱們要麼提高處理能力,好比採起水平擴展、緩存等措施;要麼把流量控制在系統能處理的水平,好比採起限流、降級等措施。

系統的高性能

咱們這裏說的高性能,並非指系統的絕對性能要多高,而是系統要提供合理的性能。好比說,咱們要保證前端頁面能夠在 3s 內打開,這樣用戶體驗比較好。

保證合理的性能分兩種狀況:

  • 一種是常規的流量進來,但系統內部處理比較複雜,咱們就須要運用技術手段進行優化。好比針對海量商品的檢索,咱們就須要構建複雜的搜索系統來支持。
  • 第二種是高併發的流量進來,系統仍舊須要在合理的時間內提供響應,這就更強調咱們作架構設計時,要保證系統的處理能力可以總體上作水平擴展,而不只僅是對某個節點作絕對的性能優化,由於流量的提高是很難準確預計的。

系統的可伸縮和低成本

系統的業務量在不一樣的時間點,有高峯有低谷,好比餐飲行業有午高峯和晚高峯,還有電商的大促場景。咱們的架構設計要保證系統在業務高峯時,要能快速地增長資源來提高系統處理能力;反之,當業務低谷時,能夠快速地減小系統資源,保證系統的低成本。

高可用、高性能、可伸縮和低成本,這些技術架構的目標不是孤立的,相互之間有關聯,好比說有大流量請求進來,若是系統有很好的伸縮能力,它就能經過水平擴展的方式,保證系統有高性能,同時也實現了系統的高可用。若是系統的處理能力沒法快速提高,沒法保證高性能,那咱們仍是能夠經過限流、降級等措施,保證核心系統的高可用。

我在前面也提到,這些目標不少時候會衝突,或者只能部分實現,咱們在作技術架構設計時,不能不顧一切地要求達到全部目標,而是要根據業務特色,選擇最關鍵的目標予以實現。

好比說,一個新聞閱讀系統,它和訂單、錢沒有關係,即便短期不可用,對用戶影響也不大。但在出現熱點新聞時,系統要能支持高併發的用戶請求。所以,這裏的設計,主要是考慮知足高性能,而不用太過於追求 4 個 9 或 5 個 9 的可用性。

相關文章
相關標籤/搜索