對于業(yè)務系統(tǒng)，基于業(yè)務量、數(shù)據(jù)量、穩(wěn)定性要求等，選擇合適的架構是產(chǎn)品開發(fā)的第一步。 如果架構沒選好，系統(tǒng)很快就可能面臨各種問題。
01 1、單臺數(shù)據(jù)庫/Redis等，查詢等待時間長 2、部分業(yè)務系統(tǒng)壓力大，或是突增流量，系統(tǒng)不穩(wěn)定 3、單一故障的傳播，造成更大范圍的系統(tǒng)故障
4、系統(tǒng)故障影響大，需要人工馬上介入，缺少故障轉移機制 在業(yè)務成長的過程中，多方面系統(tǒng)瓶頸問題，不一一列了，需要結合架構來做優(yōu)化升級。 作為一個軟件開發(fā)人員，需要了解軟件構建的演進，熟悉常用的軟件架構。02 軟件行業(yè)最初流行的是單體架構，整個項目包含的模塊非常多。 典型的有三級架構，前端(Web/客戶端) + 業(yè)務服務層 + 數(shù)據(jù)庫層。常見的開發(fā)框架比如有Java Spring MVC。 單體架構的應用比較容易部署、測試，在項目的初期，可以很好地運行。隨著需求的不斷增加， 越來越多的人加入開發(fā)，代碼庫也同時在膨脹。 產(chǎn)品功能做大后，單體應用變得越來越臃腫，可維護性、靈活性逐漸降低，維護成本越來越高。03 分布式應用是中級架構，中間層和數(shù)據(jù)層都為分布式，是并發(fā)擴展單體架構。 經(jīng)歷過單體應用開發(fā)的人員，自然會想到拆分多個業(yè)務系統(tǒng)，每個系統(tǒng)部署在不同的服務器上，各個服務模塊之間通過接口做數(shù)據(jù)交互。 數(shù)據(jù)層也大量采用分布式數(shù)據(jù)庫，比如Redis、ES、MongoDB。通過Nginx等代理應用，將用戶請求均衡分發(fā)到不同的服務器。 相對于單體架構來說，還是水平擴展系統(tǒng)，提供了負載均衡的能力，可以大大提高系統(tǒng)負載能力，解決高并發(fā)的需求。 缺點是系統(tǒng)之間的交互要使用遠程通訊，接口的開發(fā)量變大，不過嘛，這點問題不大。
04 微服務架構，主要是分解中間層，將系統(tǒng)拆分成很多微服務，微服務可以部署在不同的系統(tǒng)，也可以部署在相同服務器上的不同容器。 單個應用的負載和故障不直接影響其他應用，常見的框架有 Spring Cloud、Dubbo等。典型的微服務部署架構可參考下圖。
微服務帶來很多優(yōu)點 1、易于開發(fā)和維護：每個服務關注一個指定的業(yè)務板塊，業(yè)務清晰，微服務之間設計的解耦。
2、按單個服務部署：每個服務代碼量較少，一般只改了某個服務，就只要重新部署這個服務，啟動比較快。
3、服務治理更專業(yè)：可以做更細粒度的服務治理，更精確的流量管控等。 4、技術棧不受限：每個服務可選不同的技術棧和中間件，甚至支持不同的開發(fā)語言。
微服務帶來一些挑戰(zhàn) 微服務可便于項目做大做強，同時日常要面臨以下挑戰(zhàn) 1、分布式的復雜性：系統(tǒng)各方面設計需要考慮分布式，處理網(wǎng)絡延遲、系統(tǒng)容錯、分布式事務等帶來的挑戰(zhàn)。
2、接口調整成本高：微服務之間通過接口通訊，一個接口修改可能所有調用該接口的服務都需要同步調整。
3、運維要求較高：微服務的部署數(shù)量常見的幾十到幾百，要保證相互正常運行和協(xié)作，以及容器的自動伸縮，運維技能要求很可能上升到使用 K8s。
05 系統(tǒng)高可用包含很多個方面，主要有以下方面 各個業(yè)務中間件做高可用部署，比如MySQL數(shù)據(jù)庫主從、Redis集群部署等，同時代碼層面要做的處理。 基于用戶的請求，從業(yè)務上游、中游到下游，Nginx負載均衡、微服務網(wǎng)關、服務負載均衡等。
并發(fā)流量大情況下，如何保證系統(tǒng)穩(wěn)定的一些考量，比如消息隊列、服務降級、限流、超時機制等。 今天開始新增加一個分享主題，關于架構高可用的技術選型、搭建、使用等。 主要基于微服務架構，有需要分享的同學點個贊，讓我知道你需要。
|
