后端架構演進

Flink_China 發布于2019-06-28 13:20 / 2553人閱讀

摘要：后端架構演進在公司已經走過很多個年頭，有幸能夠親手去創造架構組，甚至帶領團隊去完成部分架構的調整，驗證架構的想法。總結這個架構演進主要是為了解耦業務，釋放人力去將業務做得更加精細，提供業務質量。

后端架構演進

在公司已經走過很多個年頭，有幸能夠親手去創造架構組，甚至帶領團隊去完成部分架構的調整，驗證架構的想法。希望能夠得到大牛們的一些指引。

1.0 時代

傳統的 LNMP 架構，雜亂的應用體系，數不清的坑。單體應用的情況下還可以接受，一旦業務發展速度加快，人員不到位，就可能出現這種情況。

這個結構相當簡單，數據庫在本機，業務代碼也在本機，一臺機子上有不同的項目。

2.0 時代

雖然說 2.0 時代有了咱們自身的數據庫服務器，名義上將數據庫與業務代碼進行分離，但是服務器還有很多不同的業務代碼，還可能相互影響著。

隨著時間的推移，這樣的結構越來越復雜，每個業務中甚至還穿插著其他業務，維護尤其的累與危險。

3.0 時代

正式提出將業務進行模塊化處理，將公共的模塊獨立成一個基礎的組件運行，并由其負責獨立處理。

整個過程相關于是將很多業務進行調整，其中涉及的量還不少，并且需要推翻了部分業務的流程，可謂是一個大工程。

自從將業務組件拆分之后，維護起來也相對容易了一些，但是因為拆分了，說明數量增多了，維護的成本也相對較高。

4.0 時代

雖然將組建都拆分了處理啊，但是業務上還是相對雜亂的，于是，我們就重新將業務進行編排，并且加入了網關 + 內部DNS服務器，用來解決端口泛濫的問題。

咱么協議目前還是是用HTTP協議進行通信。

總結

這個架構演進主要是為了解耦業務，釋放人力去將業務做得更加精細，提供業務質量。但是解耦意味著人力投入的增加，所以需要適當考慮當前是否適合進行這樣的架構調整。

問題:

資源編排: 想要將業務做得更加獨立，就需要重新對資源進行編排，獨立的業務，獨立的資源

服務超時: 拆分之后的業務調用更加復雜，當其中一個鏈路出現問題的時候，可能會影響整個調用過程出現問題，所以適當的超時處理是必須的。

增加監控的難度: 因為服務多了，調用的關系鏈更加復雜，需要定位到具體服務器，具體代碼，則需要引入調用鏈監控的環節，目前使用到的是 fiery

GPU云服務器云服務器 CDN演進云計算演進云計算的演進 Redis多線程演進

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/25587.html

架構 - 收藏集 - 掘金

摘要：淺談秒殺系統架構設計后端掘金秒殺是電子商務網站常見的一種營銷手段。這兩個項目白話網站架構演進后端掘金這是白話系列的文章。淺談秒殺系統架構設計 - 后端 - 掘金秒殺是電子商務網站常見的一種營銷手段。不要整個系統宕機。即使系統故障，也不要將錯誤數據展示出來。盡量保持公平公正。實現效果秒殺開始前，搶購按鈕為活動未開始。秒殺開始時，搶購按鈕可以點擊下單。秒殺結束后，按鈕按鈕變...

Riddler 2019-06-24 17:54 評論0 收藏0
從應用到平臺 - 云服務架構的演進過程

摘要：應用的研發上線運維運營形成閉環，順利完成從對內服務到公共平臺的升級。從功能角度，只能支持靜態方式設置反向代理，然后，而平臺有服務對應的后端服務和端口是有動態調整需求。架構上是基礎組件需要進行升級，數據訪問層日志監控系統等。介紹 ? ? ? ?MaxLeap早期是一家研發、運營移動應用和手機游戲公司，發展過程中積累了很多通用組件。這些組件很大程度幫公司在移動研發過程中節省了時間和成本，...

LiangJ 2019-06-28 15:16 評論0 收藏0
服務端高并發分布式架構演進之路

摘要：架構演進單機架構以淘寶作為例子。隨著用戶數的增長，并發讀寫數據庫成為瓶頸第二次演進引入本地緩存和分布式緩存在同服務器上或同中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的頁面等。 1. 概述本文以淘寶作為例子，介紹從一百個并發到千萬級并發情況下服務端的架構的演進過程，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知，文章最后匯總了一些架構...

FrancisSoung 2019-06-24 18:22 評論0 收藏0